While working with the DMN editor, you may have noticed that a big amount of modeling logic lives on the expressions, boxed in a few kinds of DMN nodes.
The Boxed Expressions are crucial for modeling decision logic. On that side, there is an ongoing effort from the engineering team to improve the user experience of the Boxed Expression Editor, which will be described in a series of articles that will clarify reasons, solutions, and the next steps.
This first article will briefly explore Boxed Expressions from their specification perspective, looking at how they are currently leveraged in the DMN editor.
WHAT ARE BOXED EXPRESSIONS
A Decision Requirements Diagram (DRD) is a graphical representation of the decision model structure. In such a diagram, you can define decision nodes and each of them has a value expression (or decision logic) that determines its output based on its current inputs. The logic defined in such expressions is expressed in tabular formats called boxed expressions.
The DMN editor supports a variety of decision logic types:
- Decision Table: it is the most familiar type of boxed expression. Its logic is based on rules. It is basically a table where the columns on the left represent the inputs, and the column on the right, instead, is the output. Each row is a decision rule. If all cells belonging to the input columns of a decision rule match the input data, then the output of the decision rule gets selected. On the top-left corner of the table, there is a hit policy, which specifies what the result of the Decision Table is in cases of overlapping rules.
Below, a possible layout for the Decision Table, taken directly from the spec.
- Literal Expression: a single cell that represents a formula, using the FEEL expression language.
Below, an example of Literal Expression.
- Invocation: it’s an expression that maps inputs to parameterized decision logic.
In the example below, the invoked decision logic is a business knowledge model.
- List: a collection of items.
When cells are arranged vertically, the layout is similar to:
- Context: a collection of entries (name, value) with an optional result value. It can have nested values.
The context when it is in a vertical layout looks like the following:
- Relation: it’s a table representing only values. Quite simple.
A collection of columns and rows represent a Relation:
- Function: it’s a notation for parameterized boxed expressions. It has three cells: the function kind, the list of parameters, and the function body.
Below you can find a Function layout:
BOXED EXPRESSIONS IN THE CURRENT DMN EDITOR
I am sure you have already used the DMN Editor to edit a Boxed Expression. By the way, let’s take one step at a time.
First of all, let’s go to the well-known dmn.new website.
Here, there is a ready-to-use online version of the DMN editor:
You have two ways for editing a Boxed Expression:
- Edit a Business Knowledge Model node. In this case, you are able to edit only its Function definition.
- Edit a Decision Service node. In this way, it is possible to specify the desired expression logic type by using a selector.
Editor look & feel is very close to what the spec says.
Let’s take, as an example, the Literal Expression, which is the most minimal logic type.
You can navigate back to the DMN Diagram by clicking the link on the top.
The section below contains both the decision node name and the selected logic type. On the bottom, we have the boxed expression itself, with the header containing the value expression’s name and type ref, and a body containing the text field, that you can fill with FEEL code.
I suggest you play with the editor, trying to select other logic types.
For example, what happens if you need to represent a Context table, where one entry maps to a Literal Expression, and another maps to a List of Literal Expressions? Well, you can find out that there are several business cases where it is necessary to specify nested expressions and we have few logic types that suit such cases well.
CONCLUSION
We have covered just a few topics related to Boxed Expressions. The main goal here was to communicate how crucial they are for the DMN ecosystem.
You will find more information about DMN modeling and related use-cases on the official Kogito Documentation.
The existing Boxed Expressions editor already looks great, so what may you expect from the new one?
The answer will be part of the next article! We will talk about the state of the art for this editor, exploring rooms for enhancements, and how we’re improving the overall user experience in the new one.
