This month we return to a topic I've written about twice before, data validation in DMN models. This post, in which I will describe a third method, is hopefully the last word. Beginning decision modelers generally assume that the input data supplied at execution time is complete and valid. But that is not always the case, and when input data is missing or invalid the invoked decision service returns either an error or an incorrect result.
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.
In my BPMN Method and Style training, I show the following BPMN and ask students, "What does this diagram say?" You really cannot tell. It says something happens and then either the process ends or something else happens. Not very informative. But if you run Validation against the rules of the BPMN spec... no errors! As far as the spec is concerned, it's perfect. But if the goal is to communicate the process logic, it's useless.
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.