Decision Modeling Notation
-
Introduction
-
Overview
DMN Decision Table:
-
Using Decision Table inside Business Processes
Business Rules can be embedded in BPMN Processes using Business Rules Task as above. The results of the decision will determine the actions to be taken further in the process.
-
Part of Model validation
Rules can respond to business events, providing validation the business objects without programming.
Multiple Rules Set can be attached to Business Object Events
-
Rule structure:
-
Decision Table:
Rule Id
Input Entries; can be one of the following
Numeric value;
String Constant; “Winter”
Expression; < 8
-
Output Entries
Numeric value;
String Constant; “Wine and Cheese”
Expression;
Annotation (optional)
Priority (optional)
-
Expression Limitations in Decision Tables:
Decision Table Rules should be treated as a stand-alone logic, in other words should not refer to any values or variable outside the input value provided.
Therefore, Input Expression cannot refer to any variable , Output Expression can only refer to input variables.
If there are requirements for more complex rules, the following options should be considered:
1. Prepare values before the Rules, for example if Rules refer to Age, you should calculate Age from Date of Birth prior to running the Rule and have the Age as a variable instead of Date of Birth.
2. Chain DT, by having one DT compute one result to be used in another DT
Implementation Details:
Decision Table is node in the process
Input and Result Variables are same as process variables (see variable mapping)
Gets executed as a step
Matched Rule(s) are recorded in the Case Item Status
Can be a separate process on its own and called as sub-process by various processes passing data
-
Matching Rules and producing results
Single hit policies for single output decision tables are:
1. Unique: no overlap is possible and all rules are disjoint. Only a single rule can be matched. This is the default.
2. Any: there may be overlap, but all of the matching rules show equal output entries for each output, so any match can be used. If the output entries are non-equal, the hit policy is incorrect and the result is undefined.
3. Priority: multiple rules can match, with different output entries. This policy returns the matching rule with the highest output priority. Output priorities are specified in the ordered list of output values, in decreasing order of priority. Note that priorities are independent from rule sequence.
4. First: multiple (overlapping) rules can match, with different output entries. The first hit by rule order is returned (and evaluation can halt). This is still a common usage, because it resolves inconsistencies by forcing the first hit. However, first hit tables are not considered good practice because they do not offer a clear overview of the decision logic. It is important to distinguish this type of table from others because the meaning depends on the order of the rules. The last rule is often the catch-remainder. Because of this order, the table is hard to validate manually and therefore has to be used with care.
A multiple hit table may return output entries from multiple rules. The result will be a list of rule outputs or a simple function of the outputs. Multiple hit policies for single output decision tables can be:
5. Output order: returns all hits in decreasing output priority order. Output priorities are specified in the ordered list of output values in decreasing order of priority.
6. Rule order: returns all hits in rule order. Note: the meaning may depend on the sequence of the rules.
7. Collect: returns all hits in arbitrary order. An operator (‘+’, ‘’, ‘#’) can be added to apply a simple function to the outputs. If no operator is present, the result is the list of all the output entries. Collect operators are: a) + (sum): the result of the decision table is the sum of all the distinct outputs. b) < (min): the result of the decision table is the smallest value of all the outputs. c) > (max): the result of the decision table is the largest value of all the outputs. d) # (count): the result of the decision table is the number of distinct outputs. Other policies, such as more complex manipulations on the outputs, can be performed by post-processing the output list (outside the decision table).
-
OmniWorkflow Implementation of DMN
-
Defining Decision Tables
-
Defining Decision Table Using DMN Diagram:
-
Defining Decision Table using Google Docs
-
Process Design
Once the Process is run: the Case would have the result values of the decision table:
Sample DT
Sample Test Scenario for DT using Behat:
Sample Test Scenarios and Analysis:
Detailed Logging:
From Google Docs
