I am facing a problem with the definition of my decision tables.
The following screenshot shows a simple example of what I want to do. Based on the input in a table I want to call a function:
But the problem I am having is, that the expression of EVERY rule that evaluates to true is executed. The Hit Policy is set to “First”, so as a result I get the right output of the table. But despite getting the right return value, every expression is evaluated.
So if I input the value “a” to the example table, it returns the value “a” corretly, but still prints out “a”, “b”, “c”, and “d”. For this example I would expect, that the evaluation only executes the first rule, so that the value “a” is returned and the only value printed out is also “a”.
Does somebody know why the expressions get executed even if the specific rule is not the actual rule that will be the result of the table?
Thanks in advance.
your assumption is not aligned with the specification. In the spec, it says that a decision must be side-effect free.
So, it is up to the implementation if the output entries are evaluated or not. You only have the guarantee that the first output entry is returned.
Currently, the Camunda DMN engine evaluates all output entries. The hit policy is evaluated afterward.
thanks for your detailed reply.
My use case is, that I want to achieve some kind of mapping with the usage of the DMN tables.
Let’s say I have a data structure of type A and want to transfer it into a data structure of type B. Basically it’s just a mapping from one attribute name to another. If the name of an object in format A is called “Element A”, I want to change the name to “Element B”, so that it fits to the data structure of type B.
Here you can see a basic example:
Do you have any suggestions if / how this can be done with DMN tables?
If I work without explicit expressions in the output tables to set new values (like I did in the first post) I have to return the values as a String and set them in an extra End-Listener. When setting all these things in a Listener, it seems like this pushes too much logic into the Listener.
Thanks for your advice.
I’m not sure if this is the best use case for DMN
Your solution (DMN + transformation in BPMN) sounds good. In DMN, you have the mapping logic in a nice table. The actual transformation happens in BPMN (i.e. a script) - maybe after multiple mappings.
thanks for the reply.
I know it’s not actually the use case for which DMN was specified
But yeah I like the idea of having the mapping rules in a clean and well-structured table. In the first examples it may cause some confusion when multiple persons in the team need to be aware of the listeners and their importance. But I guess we will give this solution a try anyway.
The more work you can delegate to the engine, the better