Last time I mentioned that FEEL is just an expression language not a programming language. It does not have statements. It cannot create variables. But, of course, you need those to define executable decision logic! So where do they come from?
What makes DMN business-friendly is that variables and their value expressions are created graphically, in diagrams and tables. We’ve already seen how each decision node in the DRD defines a variable of the same name, and how a decision table provides its value. But decision logic is more than decision tables. It’s also literal expressions and function definitions and data mappings. Those are modeled graphically, too.
DMN provides a simple tabular format for all of those things, called boxed expressions. A boxed expression is basically a two-column table. The first column is the name of a variable or a component of a structured variable. The second column is its value, a FEEL expression. That’s it: name, value. Pretty simple. The rows of the table, from top to bottom, act like the statements in a programming language. Here, for example, is the boxed expression for a BKM, Installment calculation. Because a BKM represents a function definition, the first row of the boxed expression lists its parameters: Product Type, Rate, Term, Amount. Then come the name/value pairs: A new variable Monthly Fee takes its value from the FEEL expression in the right column. A second new variable, Monthly Repayment, takes its value from the right column as well, here defined as the invocation of another function called PMT, defined elsewhere. The last row, called the final result box, is another FEEL expression for the output value of the BKM, a simple sum of the new new variables.
Required monthly installment, the decision that invokes Installment calculation, maps its inputs to the BKM parameters using the same boxed expression format:
The names of the four parameters are in the left column. The value expressions for each, here just a component of the input data element Requested product, are in the right column.
In essence, the combination of a diagram – the DRD – and a bunch of 2-column tables defines the “programming language” of DMN, accessible to business people but – in principle – executable on a decision engine. I say “in principle” because, like FEEL, boxed expressions have not been adopted by first-generation DMN tools. And unlike FEEL, this isn’t even hard to do! Boxed expressions should be considered an essential part of the DMN notation.
Massively agree with this Bruce,
One of the things that DMN offers that goes beyond what Sapiens TDM does is the flexibility for things other than decision tables (which presents its own set of challenges – best practice in DMN will require use of the appropriate method of logic expression at the right time). Therefore it would have been great to see boxed expressions appear in the initial offerings as the power of a simple ‘if, then, else’ statement as a literal expression is more appropriate than having to work that into a decision table.
Hopefully we’ll see this aspect picked up quite quickly
Thanks
Nick
if..then..else is a FEEL expression. It is very useful in a context, a multi-line boxed expression for a single decision node. (You could jam a decision table into a context entry, but graphically that gets nasty.) Without contexts, end-to-end DRDs will have more than 30 decision nodes, which Larry Goldberg says is the manageability limit. So you really can’t get away from the need for an equivalent to boxed expressions and FEEL. In that case, why have each tool vendor do its own proprietary “equivalent”? Which is what will happen unless customers demand something better.