DMN Tutorial
DMN Online Simulator
Learning by Doing: You can use our free online simulator to execute DMN decision tables that you create.
Why should I care about DMN?
Standard
DMN is not owned by a certain enterprise but by an institution (OMG), which is already established through other world-wide standards, e.g., BPMN and UML. The DMN standard is supported by several software products; you are less dependent on any particular vendor’s products.
Direct Execution
In DMN, decisions can be modeled and executed using the same language. Business analysts can model the rules that lead to a decision in easy to read tables, and those tables can be executed directly by a decision engine (like Camunda). This minimizes the risk of misunderstandings between business analysts and developers, and it even allows rapid changes in production.
Experience
DMN as a standard is young, but it was developed by people having decades of experience with business rule management. Even though, the standard does not dictate any special implementation patterns, allowing for more modern and lightweight implementations than traditional business rule engines.
This tutorial provides a quick introduction into DMN, as it is defined in version 1.1.
A simple decision table
We should begin our DMN tutorial with a rather simple decision table:
Let’s assume we have invited some guests for dinner. The question is, which dish we should prepare. In this example, we follow a very simple decision logic: Depending on the current season, we decide on the dish. If it’s Fall, we will go for spareribs, in Winter for roastbeef and so on.
Let’s look at the elements in this example:
Simple enough, isn’t it? Of course there is more to DMN, but the basic principles are indeed very straight forward.
Combining Conditions
In many cases a rule will not only consist of one condition, but a combination of conditions. We can express that by adding input columns to the decision table:
In this case we may want to consider guests that are vegetarian. Regardless of the season, we cannot serve them any meat. Fortunately, we always have some pasta available. By combining the two input columns “Season” and “Vegetarian Guests”, we have made sure that the first four rules can only evaluate to true, if the guests are not vegetarian. Rule number 5 has a “-” in the input entry that checks the season, and this means that it can be any season, as long as the guests are vegetarians, they will get pasta.
As you can see, the combination of input entries in a rule (i.e. a table row) always follow an AND logic: “If it’s fall and my guests are not vegetarian, I will serve spareribs.”
Introducing FEEL
Now that you have a basic understanding of a decision table structure, let’s take a closer look at possible input entries. It’s quite simple to say that certain data should be compared to certain strings (like the fact, that the season should be summer). But DMN offers more advanced concepts for checking input entries. Part of the DMN standard is the Friendly Enough Expression Language (FEEL).
FEEL defines a syntax for expressing conditions that input data should be evaluated against. For example, you can describe in FEEL that a certain input data should be
To get a first idea, please have a look at the example below:
The first thing you’ll notice are two additional rows with grey cells. These rows describe technical details that the decision engine needs in order to execute the decision. The first one contains expressions that – in this case – simply refer to variable names, namely season, guestCount and desiredDish. The second one tells the engine the type of the respective outcome of the expression, in this case string and integer.
In the first examples those rows were hidden, in order to not overwhelm you right upfront. But in fact, those types are important, because they determine which FEEL expressions are available for the input entries.
Let’s look at each rule, i.e. at each row:
As you probably guess already, this is just the tip of the iceberg. There is much more that you can express in DMN decision tables, as we describe in the DMN Reference Guide.
For Developers: You can find an implemented version of this example on GitHub.
DMN and BPMN Processes
Perhaps you’re thinking:
Hey, why should I use DMN anyway, I can express those rules with BPMN gateways!
If we express the example above in BPMN, it looks like this:
The sorrow is obvious: It’s way more verbose to express rules in BPMN, especially when there are several conditions to consider. The diagram becomes complex and hard to maintain.
That is why BPMN includes a so-called business rule task, which should better be named decision task in a later version of the BPMN standard: That task refers to a decision that needs to be made, and the outcome of the decision allows the subsequent exclusive gateway to route the flow, as you can see in the example below.
During modeling as well as execution, we can link the task “Decide Dish” to the DMN decision table, that will be executed when the decision should be made, and the result will then determine the further flow in BPMN.
In this particular example, you could question the use of the flow routing anyway. There are six tasks that are about preparing a meal, the only difference being the kind of meal. There is not apparent advantage of having those six distinct tasks. An alternative pattern would be below:
It’s too easy, right? But in this case, it’s in fact an appropriate pattern.
Combining BPMN with DMN is a very reasonable approach. Unfortunately, it is not yet standardized by OMG. This means, that a reference from a BPMN business rule task to a DMN decision is always vendor specific.
Decision Requirements Diagrams
If you want to discuss and analyze complex decisions, that may be composed of other decisions, decision requirements diagrams (DRD) can be helpful. This is a quite simple notation defined in the DMN standard, that basically concists of
There are a few more symbols in the DRD notation, however the most relevant ones are these three. We should look at an example:
Let’s assume that for our dinner, we also need to decide the beverages we want to serve. This decision should be based on the dish we will prepare and also consider children. The decision table could look like this:
You will notice that this table has a “C” in the upper left corner, instead of the “U” you have seen in the previous examples. The C stands for Collect, which is an other hit policy, and it means that more than one rule could be true, which would lead to a list of output values.
For example, if we will have spareribs, and our guests come with children, we will serve water, apple juice and the famous Aecht Schlenkerla Rauchbier.
Obviously, we need to determine the dish we will prepare, before we can decide the beverages. And this relation is what you can describe in a DRD, like we did in this example:
DMN и бизнес-правила для «чайников»
DMN — это набор значков и их определений в XML. С помощью этих значков можно описывать решения, принимаемые бизнесом. Что за значки, что такое решение и какое вам до этого всего дело — читайте в этой статье.
DMN — удобная нотация для правил
DMN можно использовать, чтобы явно описывать из каких соображений принимаются решения. Как и в BPMN (который можно начать учить по моей бесплатной рассылке), DMN имеет 2 способа применения:
DMN придумали в 2015 году те же ребята, что и BPMN — эти 2 нотации отлично сочетаются друг с другом. Но можно использовать и отдельно.
DMN помогает избежать кучи лесенок внутри программного кода
Основная идея DMN заключается в том, что решениями можно так же управлять, как и другими частями своих приложений. Например, у вас есть решение по расчету премии. Вы можете менять только его, когда меняется способом расчёта этой премии, не трогая другие элементы приложения.
DMN — это таблица
В терминах DMN решение — это таблица.
Представьте, что вы решили устроить вечеринку и позвали гостей на ужин. Вам нужно понять, что приготовить. В этом примере у нас будет очень простая логика — в зависимости от времени года будем готовить разную еду: если осень, то готовим рёбрышки. Если зима — то ростбиф.
Решение состоит из:
DMN — таблица принятия решений
Несколько условий в DMN
Во многих случаях правила содержат не одно условие, а несколько. Мы можем это выразить, добавляя колонки входных данных в таблицу
Несколько условий в таблице
В этом примере мы хотим проверить, если среди гостей вегетарианцы. Несмотря на время года, мы всегда должны готовить пасту для вегетарианцев. Правило №5 имеет «-» во входных значениях времени года. Это значит, что несмотря на время года, если среди гостей вегетарианцы, то мы готовим пасту.
Комбинация входных параметров в правиле всегда работает по логике И.
Язык FEEL для работы с входными данными
В DMN встроен FEEL ( Friendly Enough Expression Language). Это специальный “язык” для проверки выражений на входных данных. Эти проверки выполняются до правил.
С помощью FEEL можно:
Язык FEEL для обработки входных данных для правил
В первую очередь, вы увидите серые строки. Эти строки описывают технические детали, которые нужны движку (в моём случае Camunda) для выполнения решения. Первая строка описывает название переменной. Вторая — тип переменной, возвращаемой из выражения. Это важно, чтобы понимать, какие FEEL выражения можно применять к входных переменным.
Выражений FEEL достаточно, чтобы полноценно работать со входными переменными, не прибегая к коду:
DMN и BPMN
BPMN без бизнес-правил может выглядеть так:
BPMN без бизнес-правил
А с DMN может выглядеть так:
BPMN с бизнес-правилами
С помощью решений можно значительно улучшить ваши BPMN-схемы.
Поиграться руками
Как работают правила на практике, вы можете посмотреть по этой ссылке. Напишите в комментарии — имеет ли право на жизнь DMN в вашей практике? Использовали ли уже? Или используете другой подход?
Если вы нашли ошибку, пожалуйста, выделите фрагмент текста и нажмите Ctrl+Enter.
