OpenRules already can read and execute decision models represented in the DML XML format. To test new DMN-to-OpenRules capabilities I decided to implement DMCommunity’s June-2017 Challenge using the DMN Modeling tool from Trisotech that allows non-technical people to create DMN-compliant decision models and import them to the DMN XML format. My objective was to create DMN XML for the Loan Origination problem described in the Section 11 of the DMN specification and then execute this DMN XML using OpenRules.
A solution for this challenge that uses OpenRules directly has been already described in my previous post. It explains how this problem can be decomposed into 7 small, loosely coupled decision models which then can be integrated in one executable solution. So, below I describe how I built similar small decision models using Trisotech, then automatically converted them to OpenRules xls-files, and finally imported them into an integrated decision model that can be executed by the OpenRules engine as end-to-end solution.
— Top-Down Decomposition —
The objective of top-down decomposition of the end-to-end decision logic is to build a “library” of relatively small, loosely coupled decision models which could be tested and executed independently. Then we can link various decision models from this library together to model our “big” problem as long as many other related problems. In my post I’ve already described how we did top-down decomposition of our “big” Loan Origination decision model into 7 loosely coupled decision models. Now I will describe how I implemented all of them using Trisotech graphical interface. All 7 models were created as separate decision models placed in the Trisotech folder “Loan Origination”:
— Decision Model “Loan Origination Result” — top
I will start with a very simple top-level decision model that should determine “Loan Origination Result” as “ACCEPT”, “DECLINE” or “REFER”. This decision model contains only one decision table that works with several decision variables defined in one data structure “Application”. So, here is its simple DRD:
The decision table is defined as
I created the Data Type “Application” for this decision model using Data Modeler:
Then I selected the menu “IMPORT-EXPORT” + DMN 1.1. to export this model to the file “LoanOriginationResult.dmn”. I placed this DMN XML file in my own repository “LoanOrigination” (a folder on my hard drive).
To convert and execute this DMN XML file I also needed test data. I decided to use DMN TCK test format, and created the following test-file “LoanOriginationResult-test.xml” in the same folder:
Then I run the standard batch file “runLoanOriginationResult.bat” :
@echo of cd %~dp0 set MODEL_FOLDER=LoanOrigination set MODEL_NAME=LoanOriginationResult set DECISION_NAME=DetermineLoanOriginationResult call %~dp0.\run pause
This file specifies a MODEL_FOLDER where the dmn- and xml-files are located, MODEL_NAME and DECISION_NAME under which the converted decision model will be known. This batch file executes OpenRules DMN XML Engine that does the following:
- Parses the files <MODEL_NAME>.dmn and <MODEL_NAME>-test.xml and checks them for possible errors
- Generates two Excel files <MODEL_NAME>.xls and <MODEL_NAME>-test.xls
- Creates an OpenRules Decision based on the generated xls-files and executes all test cases comparing the actual and expected results.
In out case, the generated file “LoanOriginationResult.xls” contains the following OpenRules constructs:
The generated file “LoanOriginationResult-test.xls” contains the following OpenRules constructs:
As you can see, the generate Excel files have a “friendly-enough” structure and taken together constitute a ready to be executed OpenRules decision model. So, being executed by OpenRulesEngine this converted decision model produces the following results:
The conversion and testing processes for all other decision models are similar to this one, so I will show only initial decision models in the Trisotech format.
— Decision Model “Bureau Strategy” — top
The DRD for the decision model “Bureau Strategy” looks as follows:
It consists of the following decision tables:
The corresponding data types look as below:
Then I exported this model to the same local repository “LoanOrigination” under the name “BureauStrategy.dmn”, converted and tested it against “BureauStrategy-test.xml”. The generated decision model received the name “DetermineBureauStrategy”.
— Decision Model “Routing” — top
The DRD for the decision model “Bureau Strategy” looks as follows:
It contains one decision table:
Here are two related data types:
This decision model was converted and tested under the name “DetermineRouting”.
— Decision Model “Affordability” — top
The DRD for the decision model “Affordability” looks as follows:
It contains 3 decision tables:
and one literal expression:
I also defines 3 data types that cover all decision variables used in the above tables:
This decision model was converted to Excel-based decision tables in the OpenRules formats. In particular, the literal expression that calculates Application.pmt was converted into an unconditional decision table:
The execution sequencing of sub-decisions for this and all other models was defined automatically utilizing information requirements provided by the DRD and transformed into DMN XML format. The converted decision model “DetermineAffordability” was tested using DMN TCK test cases.
— Decision Model “Pre-Bureau Risk Category” — top
The DRD for the decision model “Pre-Bureau Risk Category” looks as follows:
It has only one decision table:
Note that it defines the variable “Application.Risk Category” (not “Application.Pre-Bureau Risk Category”).
This decision model was converted to Excel and tested under the name “DeterminePreBureauRiskStrategy”.
— Decision Model “Post-Bureau Risk Category” — top
The DRD for the decision model “Post-Bureau Risk Category” looks as follows:
Note that it uses the same decision variable “Application.Risk Category” as the decision model “Pre-Bureau Risk Category” but its decision logic is different.
This decision model was converted to Excel and tested under the name “DeterminePostBureauRiskStrategy”.
— Decision Model “Application Risk Score” — top
The DRD for the decision model “Application Risk Score” looks as follows:
It has only one decision table:
This decision model was converted to Excel and tested under the name “DetermineApplicationRiskScore”.
— Linking Loosely Coupled Decision Models Together — top
So, now I have 7 small, loosely coupled decision models in the DMN XML format, which were successfully converted to OpenRules and tested using DMN TCK test cases. My local repository looks as follows:
It is possible to link these models together with a BPM engine. However, I wanted to use OpenRules for composing an end-to-end decision model out of these automatically generated models. I decided to import our 7 decision models into one “big” OpenRules-based decision model “DetermineLoanOrigination”. While DMN specifies an importing mechanism, nobody (including Trisotech) supports it yet. So, I decided to use a native importing mechanism provided by OpenRules.
— Importing Decision Models — top
I created a new file “LoanOriginationDecision.xls” that contains the following table:
The first column refers to the full path for every decision model I want to import into the integrated decision model. The second column contains the names of the imported decision models, under which they will be known to the “big” decision.
— Integrated Decision — top
I also need to define the main table of the type “Decision” for our “big” decision:
This decision first will execute the common decision model “DetermineApplicationScore” and then “SubDecisionBureauStrategy”. This sub-decision supposed to assign a value ACCEPT, THROUGH, or DECLINE to the decision variable “Bureau Strategy”. If Bureau Strategy Is Not DECLINE, then (and only then) this table will execute “SubDecisionRouting”. And finally this table will (unconditionally) execute the decision “DetermineLoanOriginationResult” to define the main output variable “Loan Origination Result”. Here are these two sub-decisions:
The glossary for our integrated decision will simply combine automatically generated glossaries from our 7 decision models and will look as below:
— Test Data — top
To test the integrated decision, I created the file “LoanOroginationDecision-test.xls” that integrated tables for the datatype “BusinessObject”, data objects, and test cases with expected results. Here they are:
Now I have everything necessary to execute the integrated decision model using the standard OpenRules batch-file “runLoanOriginationDecision.bat”.
— Execution Results — top
Here are the execution results of the Test 1.
We can see how different decision models were actually executed along with produced values for related decision variable. The final output Loan Origination Result is ACCEPT as expected.
CONCLUSION. Instead of building one big decision model for the Challenge’s Loan Origination problem, first I used top-down decomposition to create 7 small, loosely coupled decision models. All these models are 100% DMN compliant being created with Trisotech DMN Modeler and exported into DMN XML format. Then I used the latest OpenRules DMN Engine to convert DMN XML files into Excel files with all models being presented in OpenRules DMN format. I utilized DMN TCK format to test these decision models independently. Then I used the decision model importing mechanism provided by OpenRules to create an integrated decision model “LoanOriginationDecision” and successfully tested it as the end-to-end solution. This approach allowed me to avoid any duplication for decision variables or decisioning constructs. I specifically used only the core DMN decision tables and avoided parameterized functions or boxed expressions. The proposed solution shows the power of the DMN core and considering that the same DMN XML can be executed by other DMN-compliant tools we demonstrated the interchangeability of DMN-based decision models.
OpenRules - Decision Intelligence Platform 