Decision Tables are a powerful technique to represent a set of related business rules in the form of a multi-dimensional matrix. They are exceptionally useful in modeling and maintaining complex business situations in a simple manner.
A Decision Table supports entering a multi-axis grid combining multiple Conditions with resulting Actions. The resulting matrix of Conditions/Actions is displayed in a precise yet compact tabular manner, as rows of Decisions, which can be easily managed by business users. The Decision Table evaluates from the top down until it finds a path a where all conditions resolve to True. Business experts can easily check the logic represented in a Decision Table for Consistency, Completeness, and Correctness.
It is generally beneficial to use a Decision Table in order to avoid repeating conditional logic in nested “If” statements. Every row created in the Decision Table includes a column for each defined Condition and Action.
The Decision Table has it's own Tab with a ribbon with buttons to add, edit, delete, and organize the decisions, as well as check/generate your rows against all possible permutations of the conditions and actions.
Specifies the name of the Decision Table.
When checked, the identity of conditions that evaluate and actions that execute will include the row identifier (e.g. Row3).
This means that any expression or action whose identity influences its execution may be affected by this setting:
- GetElementId() syntax function will include the Row identifier (e.g. Entity1:1/RuleSet1/ DecisionTable1/Row3/SetValue1 as opposed to Entity1:1/RuleSet1/DecisionTable1/SetValue1)
- FireNotification action will fire for each row that matches (if Exit at first true is unchecked), even if multiple notifications is unchecked
- The identity of rules and actions in the Rule Engine Feedback in irVerify (Rule Execution Log) will include the row identity
The downside of Compatibility mode is that the rule application cold-start will be significantly longer, and rule execution will be slower.
If unchecked, row identifiers are not included in the above scenarios resulting in identifiers for conditions and actions to appear relative to the table, not the current row. This results in much shorter cold-start and faster rule execution.
Note: If the Run Mode of the parent rule set is auto optimized, Compatibility mode is the only option and must be used.
Exit at first true
When checked, the Decision Table will stop evaluating rows after a row matches its conditions and executes its actions.
If unchecked, execution continues to evaluate the remaining rows in the table and executes actions for any row whose conditions match.
Conditions may be built for each Field value that is desired to compare individual values or ranges of values.
Actions are created to assign a Field a value as the result of a decision table match.
Rows of decisions are various conditions combined with actions.
Please sign in to leave a comment.