OpenRules-based decision models can be considered as a Glossary surrounded by decision tables that implement business logic for different goals and sub-goals (see above image).
Decision Tables
All OpenRules tables start with a keyword in the top left corner:
- Decision or DecisionTableSequence
- DecisionTable or DecisionTableSingleHit
- DecisionTableMultiHit
All decision tables execute their rules in top-down order.
Tables of the type Decision execute all satisfied rules and actions of previously executed rules may effect the conditions of the rules executed after them. These tables allow rules overrides. They frequently use to specify decisions and a sequence of sub-decisions.
Tables of the type DecisionTable stop rules execution after they hit the first rule which conditions are satisfied – that’s why they are called single-hit.
Tables of the type DecisionTableMultiHit are similar to the tables “Decision” but they first evaluate conditions of all rues and only then executes all satisfied rules. It means that previously executed rules cannot affect the execution of the rules below them. They rarely used and mainly in the situations when the same decision variables are present in both conditions and conclusions.
Simple Decision Tables
Let’s consider how to represent business logic for decision model “Vacation Days“:
To calculate Vacation Days we may use this table of the type “Decision” that executes all satisfied rules in the top-down order:
First, this table will unconditionally assign 22 to the decision variable “Vacation Days”. Being a table of the type “Decision”, it will continue to execute other rules by adding 5, 3, and/or 2 days when the proper conditions are satisfied.
This singe-hit decision table describes business logic for eligibility for extra 5 days:
Similarly we may describe business logic for eligibility for extra 3 and 2 days:
All these tables use keywords “Condition” and “Conclusion” in the second rows. You also may use their synonyms: Condition=If and Conclusion=Action=Then. All conditions are connected by the logical “AND“, e.g. the last rule in the above table “CalculateVacationDays” will be executed only when both the first and the third conditions are satisfied. You may use multiple conclusion columns but they also will be connected by the logical “AND“.
If you want to add an OR-condition, you simply add another rule. All above rules inside decision tables are connected by the logical “OR”.
Default Values
Note that in the table DecisionTable the default value is usually defined by the last rule. For instance, all the above singe-hit decision tables use FALSE in the last row as the default when previous rules are not satisfied.
Contrary, in the table Decision or DecisionTableMultiHit the default value is usually defined by the first rule. For instance, the Decision table “CalculateVacationDays” uses 22 in the first row as the default value for Vacation Days, and all consecutive rules (if satisfied) may change this value.
Glossary
The described decision model “VacationDays” uses the following glossary to “glue” all decision tables together:
It describes all decision variables used in the above tables. Thus, the complete decision model consists of the glossary surrounded by decision tables for all goals:
Operators in Separate Sub-Columns
The above tables use operators in the expressions as < 18 or >= 60. But you also may put operators in special sub-columns like below:
Note that in such cases the title cells such as “Conditions” and “Age in Years” should be merged. By the way, in the very first row all cells are always merged.
There are many predefined operators like Is, Is Not, Is One Of, Is Not One Of, Incudes, Add, etc. – see User Manual p. 36.
Sequential Decision Tables
A table of the type “Decision” or “DecisionTableSequence” executes satisfied rules one-by-one in the top-down order. Already executed rules can affect the execution of the rules below them. They work more like a sequence of traditional programming statements. For example, consider a situation when the first rule may change a decision variable used in a condition of the second rule:
The first rule unconditionally executes a sub-decision “DecisionValidate” that sets the decision variable “1040EZ Eligible” to TRUE or FALSE. The second sub-decision “DecisionCalculate” will be executed only when 1040EZ Eligible is TRUE.
Another example:
This sequential decision table determines a maximum of 3 dates Date1, Date2, and Date3 and assigns it to Maximum Date.
The table of the type “DecisionTableMultiHit” is similar to “Decision” with one important difference:
- First, it evaluates conditions of ALL rules
- Then it executes only satisfied rules
It means already executed rules cannot affect the execution of the rules below them. For example, this table will correctly swap the value of the variable X from 1 to 2 or from 2 to 1:
If X is 1, the first rule is evaluated as “to be executed” and the second rule is evaluated as “to be skipped”. If X is 2, the first rule is evaluated as “to be skipped” and the second rule is evaluated as “to be executed”. So, this table will produce the correct results. If you change “DecisionTableMultiHit” to “Decision” this table will fail to produce the correct results because if X is 1, the first rule will make it 2 and then the second rule will make it 1 again.
Summary
OpenRules offers two major types of decision tables: DecisionTable and Decision. Used in Excel, they provide business users with a very powerful while intuitive way to represent their business logic. In special situation you also may use tables DecisionTableMultiHit. OpenRules customers rely on many predefined types of conditions and conclusions with various operators described in the User Manual. At the same time, they may easily add new domain-specific conditions and conclusions to make the representation of their business logic even more intuitive.
User Manuals
Decision Intelligence Software 