Defining decision logic¶
To obtain a decision, you must provide a decision logic in your DMN diagram. The decision logic is defined in a decision table. In decision tables, columns are used for input and output data, while the rows define decision rules.
In this section you will learn how to define decision logic.
To create a decision logic table, proceed as follows:
Select the decision element from the shape repository and drop it on the canvas as described above.
To deposit a decision logi, open the decision table, click the table icon in the upper left corner of the element. The Decision logic dialog opens.
In the tab Decision Table you can define the decision logic through creating inputs and mapping them to outputs. First, click New Input to give the input a label.
Now, define the type of the input by clicking Text and selecting the type of your choice, e.g. Enumeration of Values.
In case you chose ‘enumeration’, you need to define possible values.
If you chose Enumeration of values as your input/output, you can sort the values by clicking the move up and move down buttons at the right of the value. Additionally, you can have the values sorted automatically in alphanumerical order by clicking the Sort values button:
More inputs and outputs can be created by clicking Add Input, respectively Add Output:
Once you have defined a new input, the input is added as an input data element to the canvas:
Now, create a rule by clicking Add rule.
Now, define the relation between input and output: to do this, operators and input values are set. Double-click on the respective line.
Select input values:
- Optionally, you can add documentation to the new rule in the column Annotations,
Importing decision rules¶
You might have parts of your decision rules already defined in a spreadsheet. Then, you can import these decision rules into your DMN decision table, for example as a list of comma-separated values.
1. Open the decision table editor and click Import/Export - Text Import in the top-right corner:
- Now, you can insert a set of decision rules, for example by copy and paste.
In the example below, we import a set of rules to determine a customer discount:
Import the decision rules.
The rules need to comply with the following structure:
Depending on the delimiter you choose, the entry fields of a decision table rows (rule) need to separated by a tab, semicolon or comma. Relational operators like
<=must be part of the field they relate to.
For each rule, you need to start a new line.
The import only supports the following literal expressions:
not(value1, ..., valueN)
not(Premium, Gold, Platinum)can exclude all customers with corresponding bonus cards.
An import doesn’t overwrite existing rules. After you have imported the rules, they are appended to the decision table.
The rules are appended to the decision table.
Defining a literal expression as decision logic¶
As an alternative to the logic defined in the decision table for more experienced users, you can define a literal expression. Literal expressions represent pre-defined logical algorithms or rules that can be used to automatically create output results for decisions, often but not necessarily in a formal expression language. They are most commonly used in cases where the output of a decision is a the result of complex calculations or logical algorithms, or when the logic of the decision does not have much variation in their outputs with regards to its inputs.
Literal expressions are written in FEEL, the ‘friendly enough expression language’ specified as part of the DMN standard, which you can download along with examples for literal expression use cases at http://www.omg.org/spec/DMN/1.0/PDF.
Read more about literal expressions in the chapter Using literal expressions instead of decision tables.
If a literal expression is defined, it supersedes the decision logic in the decision table.
Referencing a decision of another DMN diagram¶
You have also the possibility to reference a decision logic ofanother DMN diagram.
Switch to the Link tab. The Establish link dialog opens.
Now, identify the target diagram and select a decision element.
In an older version of the Decision Manager you could reference a diagram without specifying a decision. Such a reference is semantically incomplete and cannot be interpreted by the Simulation and Test Lab.
Referencing decisions in business knowledge models¶
When a business knowledge model links to a decision, referencing decision elements can reuse its logic. Such a reference is called a boxed invocation.
Boxed invocations provide decision logic and input type information as a generic function, whereas decisions that are referenced in DMN elements simply link to a decision and apply not only the input data types, but the specific input data objects.
In the following example, an insurance premium is calculated based on the applicant’s and their spouse’s risk level. For both persons, the same decision logic determines separate risk levels. A reference via a business knowledge model allows calling the linked decision model with different data inputs. In contrast, a direct link to a decision diagram would fail to distinguish between the two data sources.
Reuse decision logic via business knowledge models.
You can reference decisions in business knowledge models in the same way you link them in decision elements. To apply a business knowledge model’s decision logic, proceed as follows:
- Open the referencing decision.
- Switch to the Invocation tab.
- Set up a mapping between the referencing and the invoked decision’s input data:
Apply a business knowledge model in a decision element.
Configuring hit policies and completeness¶
With the help of hit policies you define how your decision table manages inputs that are handled by several rules and inputs for which no rules are defined.
There are single hit policies and multiple hit policies. Single hit policies produce one result per input, while multiple hit policies produce an array of outputs, which is then aggregated according to an aggregation scheme.
The completeness settings define whether your table is producing outputs for every possible input.
For further details, please consult the DMN specification document: http://www.omg.org/spec/DMN/1.0/PDF/
To define the hit policies and the aggregation and completeness settings, proceed as follows:
1. Click the UC label in the upper left corner of the table (UC stands for unique hit policy and a complete table).
2. In the Decision logic dialog, you can configure the hit policy, aggregation and completeness settings.
- Click Save to save your settings.
Verifying decision tables¶
Signavio Process Manager offers an automatic verification feature for decision tables to automatically check the completeness and consistency of rules.
To execute the automatic verification check, click the Verify button in the upper right corner of the decision table dialog:
Verify the decision table.
In our example, one combination of input values is not covered by a decision rule:
The verification function found an error: For one input combination, no rule exists.