Last year BBC-2017 organizers gave me 20 minutes to introduce DMN to business analysts at the “Technology Theater”, an open space in the Expo hall. Based on the positive feedback from people who attended my presentation, I decided to share it with more people. You may look at my slides in the PDF format. Below I will describe an example I believe is very useful to introduce major DMN concepts in 15 minutes.
After a brief standard introduction
I said: the best way to learn DMN capabilities is to build and test real Decision Models. Let’s build and execute a working decision model for a quite popular business problem known as “Vacation Days”:
The rules 1), 2) and 3) considered separately look relatively simple. The most tricky part is the relationship between different rules, e.g. “2 extra days cannot be combined with the 5 extra days”.
To build and to test the proper decision model we will use only MS Excel and OpenRules.
We start with drawing a Decision Requirement Diagram (DRD):
The top-level decision will determine the total Vacation Days for an Empoyee using the results of 3 sub-decisions which determine eligibility of the employee to extra 2, 3, and 5 days. Obviously these sub-decisions depend on the employee’s Age and Years of Service.
The top-level decision “CalculateVacationDays” can be implemented using the following decision table:
Note that this is a multi-hit decision tables (a keyword “DecisionTableMultiHit” at the top left corner) meaning that all satisfied rules will be executed. The very first (unconditional) rules will assign bas 22 days to the target decision variable called “Vacation Days” (in the title of the Conclusion column). The second rule will increment (operator +=) this variable by 5 if the employee is Eligible for Extra 5 Days. Similarly, the rules 3 and 4 may increment this variable by 3 or 5 days. Note that, the 4th rule will add 2 days only when the employee is NOT eligible to the extra 5 days. A very clear implementation of the inter-rule relationship!
Now we just need to specify the eligibility decision tables. Here is the one for 2 extra days:
It determines the intermediate decision variable “Eligible for Extra 2 Days” as TRUE if either Years of Service in between 15 years (including) and 30 years (not including) or Age in Years is more or equal to 45. Otherwise, it is FALSE – the default value defined at the end of this decision table. This is an example of the most popular, single-hit decision table (defined by the keyword “DecisionTable” at the top left corner). When such a table “hits” a rule, all rules below this rule will be ignored.
Similarly we may implement two remaining sub-decisions:
This complete the representation of the business logic. However, we want to test our decision model using some test cases. To make this model executable, we need to define a business glossary:
We simply copy-pasted all decision variables used in the above decision tables to the first column of our Glossary table. In this case, all this variable represent some attributes of the business concept (object) Employee (the second column). The third column specifies the technical names of these attributes which are used mainly for integration with the actual IT system.
Now we may create our test cases. First, we define a data type Employee:
Then we will create 6 employees in the array “employees” of the type “Employee”:
And finally, we will use the table of the type “DecisionTableTest” to define expected results:
Here for the very first employee A (defined as the first element of the array employees), the expected value of the decision variable “Vacation Days” is 27.
Now we are ready to execute our decision model defined in Excel by double-clicking on the standard OpenRules batch “run.bat”. It will execute our models against all 6 test cases and will compare the actual and expected results. Here is the execution protocol for the Test A:
OpenRules also generates the execution report with explanation in the HTML-format:
This completes our introduction to DMN with OpenRules.
Note that there are many other ways to represent business decision logic. For example, instead of 4 above decision tables we could use only one, compact decision table:
It uses formulas (also called DMN FEEL expressions) to calculate Vacation Days for different combinations ff Are in Years and Years of Service. However, it is hard to recognize the plain English description of our business logic and it will be very difficult to change or add more rules, e.g. extra 4 days for a certain range of Years of Service. So, doing decision modeling, compactness is not always your friend!
This example demonstrates a relatively simple decision model. Real-world decision models can contain many more decision tables more complex structures and located in multiple Excel files. However, our top-down test-driven decision modeling approach remains the same. See more examples of decision models in this book.