Often in decision models you need to calculate a date or duration. For example, an application must be submitted within 90 days of some event, or a vaccine should not be administered within 120 days of a previous dose. DMN has powerful calendar arithmetic features. This post will illustrate how to use them. ISO 8601 Format The FEEL expressions for dates, times, and durations may look strange, but don't blame DMN for that.
Recently I received a note from a longtime colleague newly employed at a financial services firm. "We've finally got our DMN server running, and we're looking now for user training," he writes. "I'm thinking a half to full day at our site." Hmmm... Even with a full day, you can't teach more than DRDs and decision tables. And if you want your team to do more than create business requirements for DMN to be handed off to developers, that's simply not enough.
We all learned in junior high school math class about sets and Venn diagrams. Which elements of set A are also members of set B? This concept comes up in decision logic as well, and you would expect DMN to be able handle it. It can, but it's a little complicated, because technically DMN does not have the notion of a set, an unordered collection of elements without duplicates. Instead it has lists, ordered collections that could include duplicates.
One of the great things about the DMN standard is it is continually being updated with new features that make it more powerful and easier to use. As soon as the DMN Revision Task Force (RTF) submits a new version for OMG approval, it immediately begins on the next revision. That approval process, for some reason, is exceptionally slow. While DMN 1.4 was just recently released to the public, DMN 1.
When we create a decision model, we imagine we can design the input data in a way that is most convenient for our logic. But that is not always the case. It could be that the input to our model is required to be XML in some industry-defined format, and we need to convert that to FEEL. Trisotech Decision Modeler is great at that. Importing XML schema automatically generates FEEL item definitions equivalent to it, and assigning DMN input data to the top-level item definition allows the input data to be submitted as XML and converted automatically to FEEL.
In a post last summer, I began to question the value of assigning constraints like a range of allowed values to datatypes in DMN, in favor of performing data validation using a decision table inside the decision model. There were a few reasons for this: Data values violating the constraint behaved differently in decision tables and literal expressions. Decision tables produced a runtime error, while the same value in a literal expression might be ignored or simply generate a null result.
DMN's most widely used boxed expression type is the decision table. It's popular because its meaning is intuitive and generally understood without training. The DMN spec imposes certain constraints on the format - what expressions are allowed in a condition cell, for instance. Even when these are ignored by legacy rule engine vendors, the intent of the logic is, for the most part, understood. There is one element of DMN decision tables that is not well understood without a bit of education, however: the hit policy code in the upper left corner.
A primary design goal of the DMN standard was accessibility to subject matter experts and other "business users", i.e. non-programmers. DMN promises executable decision logic without programming, and it achieves that through a combination of standard diagrams (DRDs), standard tabular formats (boxed expressions), and a business-friendly expression language (FEEL). Nevertheless, you constantly hear that it's too hard for non-programmers. Absolutely not true, but what is true is that not all business users can do it.
I have made the point on multiple occasions (for example, here) that DMN is both more business-friendly and more powerful than better-known Low-Code languages such as Microsoft's Power FX. One reason for that is DMN's context boxed expression, which breaks down a complex bit of business logic (or decision logic, if you prefer) into multiple simple pieces, without cluttering up the DRD with dozens of little decisions. A context is a two-column table, the first column naming a new variable local to the context, and the second column a FEEL expression for its value.
[This post is my presentation at Decision Camp 2022, delivered September 27, 2022.] As a longtime DMN practitioner and from the beginning one of its biggest boosters, I am what you call a true believer. But while DMN continues to gain traction, even I would have to admit it has so far underperformed in the marketplace. The industry analysts say, "OK, we're aware of it... But what's the killer app?" It may not be what you think.