Kraken Rules & Decision Tables

© Copyright EIS Software Limited. Please do not use or duplicate without express authorization.
 Training Overview

Agenda:
▸ Business Rules Approach in V20
▸ Kraken Rule Engine
▸ Decision Table Framework
▸ Kraken and DT Integration in V20 Stack

2 © Copyright EIS Software Limited. Please do not use or duplicate without express authorization.
 Business Rules Approach in V20

3 © Copyright EIS Software Limited. Please do not use or duplicate without express authorization.
 Business Rules in V20

Three different rules frameworks are used

This presentation focuses on first two topics

Kraken Rule Engine Decision Table Framework OpenL Tablets

Rule driven data validation on Lightweight Decision Table Engine, Full blown rule engine, used for
backend and client side used to organize and externalise complex business rules and
rule logic in tabular fashion invoked as stand alone service

4 © Copyright EIS Software Limited. Please do not use or duplicate without express authorization.
 Business Rules for Validation: Why?

Why are we using business rule engine for data We need to externalize validation logic from
validation? code, and have defined in centralized manner, so
it is accessible for non-developers
There are already dozens of validation
frameworks, that can be applied on UI, REST We need ability rearrange and reuse the same
endpoint, service code or persistence layer validation logic in different places and different
use cases
Why increase complexity, when “it’s just simpler
to code”? We need support variability of validation logic
based on some parameters

Validation logic will have different lifecycle -from

the rest of application implementation

5 © Copyright EIS Software Limited. Please do not use or duplicate without express authorization.
 Building our own Rules Engine: Why?
Why we decided to build rules validation engine As a rule of thumb, typically 90% of complexity is
from scratch? not in engine itself, but in it’s integration

There are lots of different rule engine We needed ability to evaluate same validation
implementations of varying complexity rules on backend and UI

We already have BLS engine from V12 High variability of validation logic prevents using
static model based implementations

Validation logic will have different lifecycle -from

the rest of application implementation

Avoid data mapping and overhead per each

validation invocation use case

Leverage experience from V12

6 © Copyright EIS Software Limited. Please do not use or duplicate without express authorization.
 Kraken Rule Engine

7 © Copyright EIS Software Limited. Please do not use or duplicate without express authorization.
 What is Kraken?

• Greenfield implementation of Business Rule Engine for data

validation

• Rules are defined on domain attributes

• Iterative sequential execution model (in contrast to RETE,

etc.)
• Provides engine implementations for backend and UI

• Same rules applied on same data will yield same results

• Decoupled rule model, using late binding during execution

• “Pure Logic” approach

8 © Copyright EIS Software Limited. Please do not use or duplicate without express authorization.
 Kraken: Design Overview

• Business Logic is defined in design time in Rules

Model, typically using DSL

• Application invokes rule engine and specifies

entry point and data to be validated

• In runtime, Kraken Engine uses repository to

resolve which rules should be applied

• Rule evaluation process is split into two parts -

engine invocation and reducer

• Kraken Engine evaluates rules and provides use

case agnostic results

• Reduced interprets rule results to provide use

case specific result (e.g. generate errors, provide
metadata for UI, etc).

9 © Copyright EIS Software Limited. Please do not use or duplicate without express authorization.
 Kraken Design Time Model

10 © Copyright EIS Software Limited. Please do not use or duplicate without express authorization.
 Kraken Designtime Model

• In order to be used by Kraken engine, validation logic must be

defined using Kraken DSL language

• There are three main model elements

– Rules, which specify actual validation logic

– Context definitions, which specify info about data structure

– Entry Points, which specify which rules should be evaluated on rule engine
invocation

• Rule model information is defined in *.rules files

• These files are loaded by Kraken repository during system
startup

11 © Copyright EIS Software Limited. Please do not use or duplicate without express authorization.
 Kraken Rule: Structure

Rule is a definition of logic to be executed Rule Header identifies rule. It consist of these parts:
against its target attribute under specific ▸ rule name
conditions. ▸ target context name
▸ target attribute
Rule name semantically identifies rule.
Rule Metadata contains customisable information about the
rule:

▸ dimension values
Condition is a boolean expression to determine if rule is
active for particular context instance. If condition is omitted,
rule will be always active.
Rule Payload defines action to be performed if rule is active.

12 © Copyright EIS Software Limited. Please do not use or duplicate without express authorization.
 Kraken Rule: Payload Types

• Validation payloads define that a certain validation

logic should be performed on target attribute
– Also they provide error message, code and severity

• UI Metadata payload only affect field

representation in UI:
– Visibility payload allows to hide field

– Accessibility payload allows to disable field

• Default value payload allows to define expression

which would set value to field, if it is null
– Defining default payload with reset keyword allows
to overwrite existing value

13 © Copyright EIS Software Limited. Please do not use or duplicate without express authorization.
 Validation Payload Types
Payload Type Description Sample Can Be Defined On

Assertion Asserts custom validation logic in form of Rule "AssertRule" On Coverage.limitAmount Any primitive field
boolean expression. Field is valid only Assert limitAmount > 100
expression evaluates to true Error "code" : "Limit Amount must be more than 100"

RegExp Asserts that text matches regular expression Rule "RegExpRule" On Account.name String field
Assert Matches "^[a-zA-Z]*"
Error "code" : "Name must contain only letters"

Length Specifies maximum length of the string Rule "LengthRule" On Account.name String field
Assert Length 31
Error "code" : "Name must not be longer than 31"

Usage Asserts that field is mandatory (not empty) Rule "MandatoryRule" On Account.name Any non-collection
Set Mandatory field
Error "code" : "Name must be entered"

Asserts that field is empty Rule "EmptyRule" On Account.secretCode Any non-collection

Assert Empty field
Error "code" : "Secret code must not be entered"

Size Asserts size of collection Rule "SizeEquals" On Policy.drivers { Collection field

Assert Size 2
Error "code" : "must have 2 elements"
}

Size Range Asserts range of size for collection. One of Rule "SizeRange" On Policy.drivers { Collection field
boundaries (min or max) can be omitted to have Assert Size Min 2 Max 3
open range }

14 © Copyright EIS Software Limited. Please do not use or duplicate without express authorization.
 Kraken Model: Entry Point

• Entry Point defines what rules should be evaluated

on particular call
• Entry Point is identified by unique name
• References a list of rules to be evaluated
• Decoupled from implementation by soft references
using rule name, actual rule body is resolved in
runtime using rule repository
• Entry Points can be nested up to two levels
• Entry Point can be restricted for backed execution
only
• Defines a contract between code developer and rule
developer

15 © Copyright EIS Software Limited. Please do not use or duplicate without express authorization.
 Entry Point Samples

▸ Entry Points are defined in Kraken DSL:

EntryPoint "Presentational" { EntryPoint "ValidationOnSubmit" { @ServerSideOnly

EntryPoint "Combined” {
"MarketValueVisibility", "MinLimitAmount",
EntryPoint "Presentational",
"MarketValueAccessibility", "PreviouRevisionCheck"
EntryPoint "ValidationOnSubmit",
"RestrictCoverageCodes", }
“SomeSecretRule”
"AZStateCoverateVisibility" }
}

16 © Copyright EIS Software Limited. Please do not use or duplicate without express authorization.
 Kraken Model: Context Definition
▸ Context Definitions define how data to be validated should be accessed by rule engine

▸ They are used to create abstract data model, against which rules are defined and executed - a vocabulary for rules
model

▸ Each Context Definition defines an entity to be validated by rules, is identified by context name, and can define
list of child context names, forming a tree structure

▸ For each child context a navigation expression must be defined

▸ Such structure allows to have decoupled and implementation agnostic representation of target domain model.
Rules can be executed on any data, corresponding to this representation model

▸ Context Model instructs Kraken rule engine, how to navigate the data image to access entities on which rules
need to be executed

17 © Copyright EIS Software Limited. Please do not use or duplicate without express authorization.
 Context Definition Mapping

Same contexts can be mapped differently for

different target environments

This ensures rule portability, as same rule will

yield same results in different environments, as
long as data corresponds to logic model

Context definitions can be defined manually or

generated from target environment (e.g. V20
domain DSL)

In runtime ContextInstanceInfoResolver SPI

needs to be implemented in each target
environment to match data entities to
respective ContextDefinitions

18 © Copyright EIS Software Limited. Please do not use or duplicate without express authorization.
 Context Definition Mapping

Context Definition can be declared as inheriting another

context - for example GarageAddress inherits Address

All rules defined against parent Address item context

definition, are inherited and evaluated against
GarageAddress and HomeAddress too.

This approach greatly reduces the number of rules for

cases where there is repetitive components with the same
or similar validation rules.

19 © Copyright EIS Software Limited. Please do not use or duplicate without express authorization.
 Context Definition Samples

▸ Context Definitions are defined in Kraken DSL:

Context PersonInfo { Context PersonalPolicySummary Is PolicySummary {

String country
String firstName
String currencyCd
String lastName String policyNumber
String genderCd PersonalVehicle* vehicles
Decimal mainVehicleTotalLimitAmt
String fullName String state
String middleName AutoCOMPCoverage* autoCOMPCoverageCoverages
String salutation AutoMEDCoverage* autoMEDCoverageCoverages
MainCOLLCoverage mainCOLLCoverageMainCoverage
Date birthDate String riskState
String maritalStatus String productCd
Date effectiveDate
}
Child MainCOLLCoverage : mainCOLLCoverageMainCoverage
Child* AutoCOMPCoverage : autoCOMPCoverageCoverages
Child* AutoMEDCoverage : autoMEDCoverageCoverages
Child Insured
Child PersonalInfo
}

20 © Copyright EIS Software Limited. Please do not use or duplicate without express authorization.
 Kraken Expression Language (KEL)

21 © Copyright EIS Software Limited. Please do not use or duplicate without express authorization.
 Kraken Expression Language

▸ Kraken uses custom Kraken Expression

Language to define all logic expressions
▸ The same language is used in Decision
Table Framework as well
▸ It has formal model and is fully
introspectable, which allows full compile
time analysis to avoid syntax and
semantic errors
▸ It is translated to MVEL for execution in
Java environment, and to Javascript for
execution on UI
▸ This approach allows to support same
language feature set despite different
environments

22 © Copyright EIS Software Limited. Please do not use or duplicate without express authorization.
 Kraken Expression Language: Features

▸ All expressions are defined against data in context definition

▸ All expressions are “pure logic”, no external service calls are allowed
▸ Both simple and complex (quantifiers, projection, predicates, iteration over collections)
constructs are supported
▸ A set of inbuilt functions is provided in Kraken function library
▸ Custom functions can be added by providing implementation for Java and TypeScript
▸ Full description of functionality is available in specification

23 © Copyright EIS Software Limited. Please do not use or duplicate without express authorization.
 Referencing Context Definition Fields

▸ Each rule is applied on one Context Coverage {

Decimal limitAmount
specific Context Definition (CD) Decimal deductibleAmount
}
and validates a single field of
each CD instance. Rule "demo-rule" On Coverage.limitAmount {
Assert deductibleAmount > limitAmount
▸ Rule can reference all CD fields Error "ec1" : "Deductible must be bigger than Limit Amount"
}
that it is applied on.
▸ Reference the required fields by
field name.

24 © Copyright EIS Software Limited. Please do not use or duplicate without express authorization.
 Cross Context References

▸ A Cross Context Reference is a Context RiskItem {

Decimal maxLimitAmount
reference to other Context }
Child Coverage

Definition by its name. Context Coverage {

Decimal limitAmount
▸ Cross Context Reference is always }
relative to the Context Definition Rule "demo-rule" On Coverage.limitAmount {
Assert RiskItem.maxLimitAmount >= limitAmount
that the rule is applied on Error "demo-rule-error" : "Limit Amount is bigger maxLimitAmount in RiskItem"
}
▸ Use path syntax to reference a
particular field of another
Context Definition.
In this example, Coverage is a child of RiskItem . Kraken Engine can navigate between
▸ If there are more than one Context Definitions allowing for easily reference to other Context Definition by its
occurrence of referenced Context business name without having to specify the navigation logic.

Definition in context mode,

Kraken engine will try to
determine correct one

25 © Copyright EIS Software Limited. Please do not use or duplicate without express authorization.
 Resolving Cross Context Reference Candidates
▸ This diagram depicts the order in
which Kraken engine will try to resolve
Cross Context Reference
▸ For sake of simplification, context
inheritance is not displayed
▸ The numbers depict priority by which
reference will be treated by
unambiguous
▸ If there will be two candidates with
same priority, error will be reported
(e.g. Address in this case)
▸ This graph is traversed starting from
each component on which rule with
CCRs is defined

26 © Copyright EIS Software Limited. Please do not use or duplicate without express authorization.
 Referencing a Collection of Context Definitions

▸ If there are more than one Context RiskItem {

instance of referenced Context Boolean premiumMultiCoverageMember
Decimal maxLimitAmount
Child* Coverage
Definition, the rule references a }
collection of instances. Context Coverage {
Decimal limitAmount
▸ Kraken Exception Language }

allows to work with collections, Rule "demo-rule" On RiskItem.premiumMultiCoverageMember {

When premiumMultiCoverageMember != true
but rules are defined on single Assert Count(Coverage) <= 10
Error "demo-error" : "For regular member no more than 10 coverages are allowed "
attributes }

▸ Therefore, any reference to

collection need to be processed Coverage is a multiple child of RiskItem. It means that each RiskItem instance has
in expression to result in single multiple Coverage instances. In this case Kraken Engine provides all Coverage instances
for a particular RiskItem instance as a Cross Context reference. As a result, a Coverage
value reference is a reference to a collection of Coverage instances. Therefore it can be used
in function Count(<collection>) to calculate how many elements are in the collection of
Coverages .

27 © Copyright EIS Software Limited. Please do not use or duplicate without express authorization.
 Handling Rule Variability

28 © Copyright EIS Software Limited. Please do not use or duplicate without express authorization.
 Rule Variability and Dimensions

▸ When rule logic needs to be varied based ▸ Rule Dimension - named external
on one or multiple external parameters parameter by which value rule’s contents
▸ Essentially can be represented by “if - need to be varied
else if - else if -...- else” conditions ▸ Referenced in “if-else if-.....-else”
▸ Moving this conditions out of rule conditions from the rule body
definition, and varying rule ▸ Multiple dimensions can be used
implementation itself is desirable ▸ Used to support variability for packages
approach from maintenance and and versioning
readability perspective ▸ Dynamic vs static approach
▸ Kraken Engine achieves this by using
dimensions and dimension aware rule
repositories

29 © Copyright EIS Software Limited. Please do not use or duplicate without express authorization.
 Handling Multiple Dimensions

Examples of:
non dimensional (top left),
one dimensional (top right),
two dimensional (bottom left)
rule variability spaces

30 © Copyright EIS Software Limited. Please do not use or duplicate without express authorization.
 Handling Multiple Dimensions

▸ Rule Dimension - named external parameter

by which value rule’s contents need to be
varied
▸ In real scenarios, variability of single rule will
be very little, if any, and will fill only portion
of matrix
▸ Complete rule set variability may look like
previous slide
▸ Static approach becomes infeasible with
more than one dimension

31 © Copyright EIS Software Limited. Please do not use or duplicate without express authorization.
 Dynamic Rule Resolution and Variability

▸ It is possible to define multiple variations @Dimension("packageCd", "Pizza")

on Entry Point or Rule with same name, Rule "Rule001" On Coverage.limitAmount {

by assigning different dimension values Default To 100

@Dimension("packageCd", "Barber")

▸ Rule engine will resolve correct Rule "Rule001" On Coverage.limitAmount {

variation, based on data in runtime When Address.zip = 90210

Default To 200

▸ Dimension values must be passed to rule Dimension("packageCd", "Kiosk")

engine during invocation time Rule "Rule001" On Coverage.limitAmount {

When Address.zip = 90210

Default To 250

32 © Copyright EIS Software Limited. Please do not use or duplicate without express authorization.
 Rule Variability - Visualisation

33 © Copyright EIS Software Limited. Please do not use or duplicate without express authorization.
 Kraken Runtime

34 © Copyright EIS Software Limited. Please do not use or duplicate without express authorization.
 Kraken Evaluation Flow

▸ All Kraken model elements are loosely coupled, using semantic names
▸ This allows to resolve actual model configuration in runtime, just before rule execution
▸ Model elements are resolved by KrakenRuntimeRepository, which provided compiled rule
model data, loaded from DSL
▸ This approach can be extended by using Dynamic Rule Repository
35 © Copyright EIS Software Limited. Please do not use or duplicate without express authorization.
 Kraken Evaluation Flow

36 © Copyright EIS Software Limited. Please do not use or duplicate without express authorization.
 Interpreting Rule Evaluation Results

Core rule engine is use-case agnostic:

▸ Input for evaluation is entry point name, data to be evaluated and dimension values
▸ Output will be tree like structure containing raw results for all evaluated results
▸ It is contained in EntryPointResult

Raw Results are interpreted by Kraken Reducer:

• Interface for class which takes raw Kraken rule results and produces use case specific data:
@FunctionalInterface
public interface EntryPointResultReducer<T> {
T reduce(EntryPointResult results);
}

• Sample implementations:
– Validation status reducer
– Field metadata reducer (UI)
• Documentation in wiki

37 © Copyright EIS Software Limited. Please do not use or duplicate without express authorization.
 Designtime to Runtime Translation

▸ DSL files are loaded and validated by

KrakenProjectRepository

▸ For execution, translation to runtime

representation is made on startup time

▸ For UI, rule data is exposed through

REST endpoint

▸ UI is caching a copy of rules for each

entry point, update is requested only if
dimension values change

38 © Copyright EIS Software Limited. Please do not use or duplicate without express authorization.
 Decision Table Framework

39 © Copyright EIS Software Limited. Please do not use or duplicate without express authorization.
 What is a Decision Table?

Decision Table are representation of decision logic in tabular

INPUT COLUMNS OUTPUT COLUMN
format
Decision Tables contain input and output columns and rows
▸ Input columns represent a decision logic condition
▸ Output columns represent decision logic result
▸ Each row represents a single decision rule
When decision table is invoked, input parameters are matched with conditions
expressed in input columns. If the row matches, the output columns of that
row are returned as result.
Decision Tables is very popular way to represent rules, especially when they
follow certain patterns and can be represented in a table.

40 © Copyright EIS Software Limited. Please do not use or duplicate without express authorization.
 Decision Table Framework

▸ Lightweight Decision Table Engine Implementation

▸ Primary use case - compact representation of dimensional Kraken Rules
▸ Also used for externalizing decision logic where use of full blown engine is impractical or too
expensive
▸ Why building our own?
– Provides tight integration with Kraken Rules Engine
– Used V20 domain model directly
– Formal model for table structure, fully introspectable programmatically
– Splitting decision table structure and data into separate artifacts with separate lifecycle
– Aspect column support and aspect based invocation

41 © Copyright EIS Software Limited. Please do not use or duplicate without express authorization.
 Decision Table Parts

@EntryPoint("dataGather", "issue", "propose") ▸ In DTF, decision table is split into Table

@Category("KrakenRules") Structure and Table Data
Table "Limit Amounts" {
▸ Table Structure is defined in DSL and
InputColumn "EntryPoint" : entryPoint
AspectColumn "Entity" : entity
compiled at compile time
AspectColumn "Attribute" : attribute ▸ Decision Table Data is specified in Excel and
AspectColumn "Min" : min is deployed to repository during
AspectColumn "Max" : max
AspectColumn "Default" : default
deployment time
} ▸ This separates concerns, and avoid that
somebody might break table structure (and
invoking application code) by updating
table data
▸ During Decision Table invocation in
runtime, engine loads model, loads table
data from repository and evaluates table

42 © Copyright EIS Software Limited. Please do not use or duplicate without express authorization.
 Anatomy of Decision Table

43 © Copyright EIS Software Limited. Please do not use or duplicate without express authorization.
 Decision Table Structure
From the point of rule, input column is part of rule condition. All input columns together form a composite rule
condition.
Input columns are defined by:
▸ Name: Human readable, unique column name
▸ Input Expression: Will be evaluated and the result is a subject for that input column. Input Expressions are
written in Kraken Expression Language

From the point of rule, output column is part of rule result.

Decision table output consists of:
▸ Name: Human readable column name
▸ Property Name: Variable name that the output result will be assigned to
▸ Data Type: Type of output result—can be any supported primitive data type.

44 © Copyright EIS Software Limited. Please do not use or duplicate without express authorization.
 Aspect Columns

Aspect is Decision Table output that models some known property in the system that has explicit support for decision
tables. In other words, aspect is decision table output that the system knows how to interpret.
Aspect column works as output for the purpose of determining Decision Table evaluation result according to HitPolicy.
Example of Aspects:
▸ Kraken Rule Payload Aspects (e.g., default, min, reset, etc.)
▸ Policy specific aspects:
– applicability
– relationshipType
– entryPoints

Another special feature of aspect is that Decision Table Framework allows to call decision tables
by aspect, thus evaluating multiple decision tables at once.
This feature is key for Kraken Integration.

45 © Copyright EIS Software Limited. Please do not use or duplicate without express authorization.
 Defining Kraken Rules in Decision Tables

▸ Kraken is integrated with Decision Table @EntryPoiint(“dataGather”)

Table "Example Table With All Aspects" {
Framework. InputColumn "Package Code" as String : dimensions.packageCd
AspectColumn "Entity" : entity
▸ It provides certain aspects that can be AspectColumn "Attribute" : attribute
AspectColumn "Min" : min
used when configuring Decision Table AspectColumn "Max" : max
AspectColumn "Mandatory" : mandatory
Structure DSL. AspectColumn "Visible" : visible

▸ If aspect is used, then Kraken Validation AspectColumn "Accessible" : accessible

AspectColumn "Default" : default
Service will automatically interpret }

decision tables and validate them

together with other business rules.

46 © Copyright EIS Software Limited. Please do not use or duplicate without express authorization.
 Kraken Aspects

47 © Copyright EIS Software Limited. Please do not use or duplicate without express authorization.
 Kraken and DT Integration in V20 Stack

48 © Copyright EIS Software Limited. Please do not use or duplicate without express authorization.
 Rules Component In V20

49 © Copyright EIS Software Limited. Please do not use or duplicate without express authorization.
 Product Rules Configuration: Rules Model
Due dynamic behavior, Kraken rules are not assigned directly to the product. Instead Rules Model is defined for particular
product domain model, in *.grules DSL file. It specifies Kraken entry points and decision tables which are required for
particular product.

Model RulesAutoPolicy
Namespace AutoRules

EntryPoints [
"Validation",
"Presentational",
"Issue"
]

Decision Tables [
"ValueList",
"UserRole" from common,
"IceCreamPrice" from common
]

VersioningConfiguration [
"Package Code"
"Plan Code"
]

ExternalContext {
context : {
external : {
prev : PrevRevisionProjection
}
securityContext : SecurityContext
}
}

50 © Copyright EIS Software Limited. Please do not use or duplicate without express authorization.
 Integration with Domain Model
▸ Dimensions are defined in domain model using
@Dimension annotation:

@Dimension("vehiclePlanCd")
Attr planCd: String

▸ Entities from domain can be used as parameters

for decision table
▸ Kraken context model is generated from domain
model using maven plugin
▸ Annotations on domain elements to control how
they are exposed to Kraken:
– @KrakenField - generate non-primitive element as field
– @KrakenChild - generate non-primitive element as child
context (default)
– @KrakenSuppress - hide element from Kraken

51 © Copyright EIS Software Limited. Please do not use or duplicate without express authorization.
 Decision Table and Kraken Integration
▸ Implementation of
DynamicRulesRepository is provided,
which calls DecisionTable engine, and
generates Kraken rules from DT
response

▸ Only those DTs are called which have

Kraken rules and have current entry
point assigned

▸ Heavy caching and optimizations are

employed to avoid performance hit

52 © Copyright EIS Software Limited. Please do not use or duplicate without express authorization.
 Integrating rules into new project

Following two guides describe procedure how to integrate Kraken and Decision Tables into new
V20 based project from scratch:
▸ Kraken integration guide
▸ Decision Table integration guide

53 © Copyright EIS Software Limited. Please do not use or duplicate without express authorization.
 Invoking Rules From V20

▸ Kraken Rule Engine is invoked from backend code and UI

▸ DTF framework is invoked:
– Directly from code using API - e.g. applicability rules, configuration lookup, decisions
– In Kraken Rule Repository - return package information to Kraken engine
– Though the REST API from UI
▸ Same context map with dimension values is used for both invocation
▸ Dimension values are resolved using DimensionResolver API from annotations on Genesis
domain model DSL
▸ In typical integration scenario, Kraken rules are invoked from command handler as base
functionality of particular subsystem

54 © Copyright EIS Software Limited. Please do not use or duplicate without express authorization.
 Dimension Value Resolver

▸ DimensionResolver
– Resolves dimension values for decision table inputs from domain entity by dimension annotations

Entity Driver { AppliesTo PersonalAuto 1

Attr name : String
@RuleOrder
@Dimension("age") Table "DriverAgeCreditScore" {
Attr age : Integer DimensionResolver Column "Driver Age" : dimension.age
Column "Score" : aspect.score
@Dimension("maritalStatus") }
Attr maritalStatus : String
@RuleOrder
@Dimension("gender") Table "PersonalCreditScore" {
Attr gender : String Column "Marital Status" : dimension.maritalStatus
} Column "Gender" : dimension.gender
Column "Score" : aspect.score
}

▸ Same dimension values are passed to Kraken engine

▸ If there are multiple @DimensionRoot annotations in domain model, validation for each part
must be performed separately, and rule results merged before processing with reducer

55 © Copyright EIS Software Limited. Please do not use or duplicate without express authorization.
 Release and Packaging

56 © Copyright EIS Software Limited. Please do not use or duplicate without express authorization.
 Anatomy of Rules Component
▸ All rules related functionality,
is packaged in Rules
component
▸ Rules component is
configured to have matching
versions of Kraken backend
and UI
▸ Other subsystems must
integrate through Rules
component
▸ It must be ensured, that
same Rules component
version is used on backend
and UI

57 © Copyright EIS Software Limited. Please do not use or duplicate without express authorization.
 Rules Component Dependencies in V20 Stack

58 © Copyright EIS Software Limited. Please do not use or duplicate without express authorization.