I consider myself among the initiators and big supporters of the DMN standard, and I do my best to help bringing the standard to the real-world business decision modeling. Naturally, the current release of DMN includes some constructs with which I strongly disagree but I am trying not to criticize DMN too much as the standard itself is not mature enough yet and I hope it will be gradually improved based on the real-world acceptance.
DMN is oriented to business people and is supposed to allow them to create, test and deploy practical business decision models without programming. In particular, DMN FEEL language was designed not as a programming language but rather a “friendly enough” expression language. However, people who actually started to use DMN unavoidably ask the question: “why do we see programming constructs such as if-then-else statements, for-loops, and functions with formal parameters in the DMN?”
In this post I will discuss DMN for-loops and their possible alternatives. Usually programmers use for-loops to iterate over arrays of objects and do something with elements of these arrays. DMN also includes loops that look like in the examples below:
for car in Application.Cars return AutoPremium(car) for n in ValidationRules return validate(n.Condition,n.Message) distinct ( for car in cars return make and model(car) )
Was it necessary for DMN to include for-loops in the standard? It is certainly necessary for business people, who create and test business decision models, to have an ability to deal with arrays of business objects like employees, cars, drivers, or passengers. So, DMN should provide a “friendly” facility to iterate through such arrays and to apply certain rules to all or selected elements of these arrays. At the same time, it was not necessary to explicitly introduce typical programming loops called “for..return“.
Even some members of the DMN committee think they should be replaced in new DMN releases. In particular, Bruce Silver in his book “DMN Method and Style” (see pp. 195-196, 288) expressed his disappointment with DMN for..return expressions and suggested several alternatives. He wrote: “One way is to remove iteration from decision logic and put it in the process logic. You won’t be surprised to learn that I am not especially fond of this alternative“. Me too because “the problem with this solution is that the meaning of decision logic is described by BPMN, not DMN“.
Bruce suggested the future releases of DMN to look at more business friendlier iteration patterns similar to those that are already provided by different vendors. In particular, Bruce pointed out to Signavio’s “Multi-Instance Decisions”, SAPIENS “repeating groups”, and OpenRules decision table actions defined on arrays. All 3 vendors offer different implementations of loops but one thing is common – they all are trying to represent iterations “graphically” without explicit for-loops.
Now I want to explain how OpenRules iterates through arrays of business objects. Let’s consider a quite complex example called “DecisionUServ” and described in this DMCommunity’s Challenge. You may analyze 8 different submitted solutions for the “UServ Product Derby” problem, but let’s look at this problem from the array iteration perspective. There is a client that may have multiple cars and drivers included in his/her insurance policy, and it is necessary to apply quite complex rules to each car and each driver to calculate the overall insurance premium. A complete OpenRules solution is described here. I just want to show you how the iteration over arrays of drivers and cars has been represented in this decision table:
This is a special decision table of the type “DecisionTableIterate” defined in the top-left corner. This table iterates over arrays of objects defined in the first column applying the rules defined in the third column to every element of these arrays. The second column defines the type of each element of the array that corresponds to the business concept describing these elements in the Glossary. For example, the first row executes the rules “DefineDriverEligibilityRating” for all elements of the array “Drivers”, which elements have type “Driver”.
This is a quite common and frequently used iteration method that allows our customers to tell OpenRules that certain rules (decision tables) should be executed for all elements of the defined arrays.
Whichever graphical representation for loops will be selected by DMN in the future, it should provide a name of the array/list that is a regular decision variable and a name of the rules (BKMs) that should be executed for every element of this array.
P.S. In the new book “DMN in Action with OpenRules” my fictional and very inquisitive READER complains immediately when I, as an AUTHOR, just try to mention any programming construct. We, READER and AUTHOR, had quite interesting conversations about “loops” – so you may find good examples of iterations without explicit loops in the Dialog-Sessions 6 and 7.