DMN – The Power of Rules

Author: Jan Ohlhoff

Let’s talk about DMN. No, I’m not talking about the Dallas Morning News, I’m talking about Decision Model & Notation, which is published by the OMG, the Object Management Group. They also publish other exciting notations like the Business Process Model & Notation (BPMN) and the Case Management Model & Notation (CMMN).

But who is the OMG and why should we listen to them? They are an “international, open membership, not-for-profit technology standards consortium, founded in 1989”. The standards are driven by vendors, end-users, academic institutions and government agencies. But enough of the theory. If you want to read more about them, you can find all at the Object Management Group.

Why should you care about DMN? Remember the times when you had to model a process and it ended up looking like the one below? In the first instance, DMN helps bring focus during requirements gathering and modeling on a certain aspect of a problem. Decision criteria can be discussed and changed without having to think about the complete process logic and vice versa.

“Since the model conforms to a defined structure and rules, it can define decision requirements more precisely, completely, and consistently than a business requirements document ever could.” (DMN Method and Style 2nd)

Let’s look at an example:

Now imagine if you could do something like this:

Not only is the process simpler, but you also separate the process logic from the business logic. This means that you can change the DMN without needing to change the process itself. Otherwise, there would be lots of gateways (BPMN) or entry sentries (CMMN) for each decision. “It’s better to replace a chain of gateways in your process model with a single decision task that invokes a routing decision modeled in DMN. Each sequence flow out of a gateway is called a gate.” (DMN Cookbook 2018)

Let’s have a look at a DMN table: “A DMN decision does not take an action. It merely specifies an output value, which could then be used – for example, by a BPMN process – to direct a particular action.” (DMN Cookbook 2018)

Granted, this doesn’t look that much of a change, but let’s get more into the possibilities of DMN. Let’s say, you have different categories of restaurants and they can be categorised by price and spiciness.

You don’t need any change in the process. The only change necessary would be in the DMN table:

And the process itself would still look exactly the same:

But how does a DMN table work exactly? According to the DMN specification, there are multiple types: rule-as-row, rule-as-column and crosstable.  For this blog post, we will look at the default one – the rule-as-row, which means that each row is representing one rule. The columns on the left-hand side represent the input conditions and those on the right the output conclusions. Every column has an operator (for example, `==`, `<=`, `>=`, `<`, `>`) and a value. Each input column will be evaluated in turn and all the input columns need to evaluate to true (logical AND) for the conclusions of the rule to be executed, so if you look at one rule (row), there is no OR logic. An example of an input cell condition is `taste == italian`, which needs to evaluate to `true` for the rule to continue. If the cell contains only a hyphen `-`, this means it’s automatically evaluated as `true` and therefore it doesn’t matter what value the variable has. 

Let’s have a look at the first rule in our DMN table. If the variable `taste` has the value `italian` AND we want to have a less spicy dish (`< 3`) AND we don’t want to spend a lot of money (`$`), the first rule will be true and therefore the output of the DMN will set the variable `restaurant` with the value `Mario’s Pizza`.

Input: `taste=='italian' && spiciness<3 && price==3`Output: `restaurant=='Mario's Pizza'`

But how can an OR rule be represented in a DMN table?The DMN specification only allows AND logic on the columns in a rule, which means if we have an OR rule, we need to separate the rule into several AND rules. This may sound abstract at first but it’s easy once you know how it works. Especially as there is no exception to this rule when looking at other DMN tables.

Maybe we have a restaurant that offers Italian and also Thai food. In order to represent this in a DMN table, we add two rules. The first rule has `taste==’italian’` and the second rule has `taste==’thai’`. We will have a look at this when we have a closer look at Hit Policies. For now, we can say that the hit policy alters the way the DMN rules are triggered and therefore which output the table will take when multiple input conditions are true.

Datatypes

When looking at the input variables, there are five different datatypes: String, Number, Date, Boolean and Collection. Those datatypes change how the variable is evaluated and will also change which operators are available. The common operations for all datatypes are `==` and `!=`.

Overview matrix of operations for the datatypes:

Collection

Let’s look at the Collection operation a bit in more detail as the other datatypes are more or less self explanatory. Say we have a variable `selectedTastes` that contains a list of tastes. From this list, the user can choose one or more tastes they fancy. In our example, the user selected taste `italian` and `thai`. What happens?

For our DMN table rule 1, 4, 5, 6 rows would result in true.

Let’s look at each operation:

Try it out!

Now to try it out, download the Flowable Modeler from Flowable and start it with a Tomcat installation or via Docker. When opening Flowable Modeler, you can try to model it yourself, or download the example here and import it.

Stay tuned for an introduction to Hit Policies and how to model more complex decision model processes and expressions.

Order Food DMN App: Download

no_DMN_process.bpmn20.xml: Download

order-food.dmn: Download