DMN is a modeling language and notation for the precise specification of business decisions. DMN is easily readable by the different types of people involved in decision management. Red Hat Process Automation Manager supports the DMN open standards.
Handling effective date and expiry date of decisions is a common requirement across businesses. While it is entirely possible to handle the validity of decisions with different versions of the decision model, oftentimes there is a requirement to add variation at an individual decision node.
In this article, we will show how to achieve that with a practical example.
Let us assume that we have a Card Approval Decision as shown below
As you can see, we are calculating the Card Score based on Annual Income and Assets. This then determines if an Automatic Approval can be performed.
The Standard card score decision is expressed as a Decision Table:
Let us say we now want a new condition for row 1, “When Annual Income < 50 and Assets < 100” starting with a specific date. Red Hat Process Automation Manager supports built-in functions to make this possible.
|now()||Current Date Time|
Let us now modify this decision table to add the date expiry condition.
Notice how we have added the date condition to the decision row to decide it should be fired.
Notice that since the effective date for Condition “When Annual Income < 50 and Assets < 100” matches the first row, the card Score evaluates to 312. Let us now change the rule to be effective from the beginning of this year and see what happens.
You can now see that the rule matched the second row based on the date condition.
Another way to define date validity is by defining it as a decision node so that one or more decisions can make use of it, it also allows you to make sure the logic is confined to one place. We will now use a combination of the built in date functions(today()/now()), as well as the temporal built-in functions to make this possible.
Let us now create a new decision node called Date Validity.
Notice how we are using the temporal built-in function “after” in conjunction with “today” to determine validity. Now we will add this node to the existing DMN.
The Standard card score now uses the Date Validity as defined by the decision node earlier. Let us now run this DMN. The DMN artifact from this example is available here.
Since the effective date for the decision was next year, row 2 was fired yielding the card score result of 350.
Test scenarios in Red Hat Process Automation Manager enable you to validate the functionality of business rules and business rule data before deploying them into a production environment. With a test scenario, you use data from your project to set given conditions and expected results based on one or more defined business rules. It is important to note that, while the test scenario by default maps the input data to the condition columns, it is possible to add a decision point as a condition column for better testability.
For instance, in the following scenario, you can see that Date Validity, which is a decision node in the DMN, is also pulled in as a condition column.
If there needs to be a granular control of date checks, the decision node can be split up to reference date as an input column too.
Now we can reference Today with different dates to test edge conditions seamlessly.
– "Red Hat Decision Manager Supported Standards": https://access.redhat.com/articles/3645412
- KIE Live 24: Squeezing the most out of DMN features, by Matteo Mortari.