Decision Model and Notation (DMN) is an industry standard managed by the Object Management Group (OMG) for modeling and executing decisions that are determined by business rules.
What is the role of DMN?
Based on the DMN specification, “the primary goal of DMN is to provide a common notation that is readily understandable by all business users, from the business analysts needing to create initial decision requirements and then more detailed decision models, to the technical developers responsible for automating the decisions in processes, and finally, to the business people who will manage and monitor those decisions. DMN creates a standardized bridge for the gap between the business decision design and decision implementation. DMN notation is designed to be usable alongside the standard BPMN business process notation. Another goal is to ensure that decision models are interchangeable across organizations via an XML representation.”
What is a DMN decision table?
A DMN decision table is a tabular representation of the decision logic. You can think of a decision table as a spreadsheet that allows you to define a row for each business rule.
Decision tables in Alfresco Process Services & Activiti 6
Here is a simple DMN decision table to determine the price of a single public transportation ticket (right column) depending on the type of passenger (left column).
The left column in light blue refers to possible input data. In this example, there is only one input column (Type of passenger) but you can have as many columns as different type of inputs you have (i.e. type of passenger, area, time of the day…). The cells under the input column header (called input entries) refer to the possible conditions regarding the input. MVEL is the expression language we support for conditions. For each possible input entry, we define corresponding output entry in the output column cell next to it. The right column in light green refers to possible output data. Each row defines a possible input value and the corresponding output value. In the example here, if the passenger is a child under age 4 then the transportation ticket is free.
If you download the simple decision table presented here as a DMN file, the decision table is represented by a decisionTable element inside a decision XML element.
In DMN, the hit policy specifies how many rules can be satisfied and what the results of the evaluation of a decision table consist of. The hit policy is set in the hitPolicy attribute on the decisionTable XML element. In the top left corner of the Decision Table Editor, you can select from 2 hit policies: first (single pass) and any (single pass). Both hit policieswill always return a maximum of one satisfied rule although multiple rules can be satisfied. When first (single pass) is selected, the execution of the table will stop and return the output of the first satisfied rule. When any (single pass) is selected, all valid rules are executed. However, all satisfied rules must generate the same output. The execution returns only the output of one of the satisfied rules.
Let’s play with a sample app
To help you get started with DMN decision tables, we designed a sample app using Alfresco Process Services (powered by Activiti). We also built the same example using Activiti 6. The use case is an employee annual bonus with the decision logic to evaluate the bonus being defined in a decision task referencing a DMN decision table.
Import & publish the app
Import the Annual bonus.zip app into Alfresco Process Services from the menu App Designer > Apps > Import App. If you are using Activiti 6, please import this app. When done importing, publish and deploy the app on the dashboard.
Run the sample app
Click on the Annual bonus app and start the process.
In this form used to start the process and thus referenced on the start event, the user is submitting his yearly achievements details. The submitted information is going to be used as input data entries for the decision task calculate annual bonus. Once the process has been started, the user can check the results of the executed DMN decision table by selecting the executed decision tables.
The decision table displayed is showing the execution path highlighted in light blue. Based on the input values submitted by the user, the first row is the one that satisfied all the conditions displayed in each cell of the 3 input columns. Since the hit policy is set to First, it was the only row executed to return the result.
The user can also see the name and values of the input entries and output result.
Let’s now submit an empty form and check the resulting execution and bonus result.
This time the conditions that didn’t match are highlighted in red.
Because we didn’t check the box for the completed obligations, the first 4 rows were not executed since the condition of the first column was never satisfied. The fifth row was executed since an empty expression was considered as a matching condition.
Sign in to the admin console
From the administration console (activiti-admin.war), administrators have access to the process instance details including the variables and the executed decision tables via the action Show Decision Audit.
For debugging purposes for example, administrators can modify the values of the variables on a running instance. To keep the instance running on our example, we added a timer after the decision table with a 5min duration period.
DMN decision tables provide a natural and visual way to specify decision logic. This simple example is showing you how to use them within a process app for automated-decision making. Typical use cases include calculating discounts, credit ratings, who to assign tasks to, what service level (SLA) to use, and so on.
Here are other resources that you might find useful:
using a custom data model integrating with a DMN decision table (blog post)
using a DMN decision table to define the next best action (blog post)