The latest June-2018 DMCommunity Challenge”Credit Card Application” gives me a good chance to demonstrate the new upcoming OpenRules Release 7.0.0. I remember that Nick Broom was one of the first who published a real-world decision model right after the DMN introduction. I also remember that at the same day I implemented and published  Nick’s model using only Excel and OpenRules  available at that time (it was release 6.2.6). It would be interesting to compare this old implementation with a new one below that takes advantages of new OpenRules-7.

For simplicity of references, here are the links to Nick’s business process and DRD (DMN Decision Requirements Diagram). DRD as a top-level graphical representation of a DMN-based decision model can be very useful to visualize the model, however it quickly becomes messy for relatively large decision models. The mess is mainly caused by necessity to represent complex relationships between decisions, sub-decisions and decision tables using DRD’s arrows which may intersect. Last year in the post “Defining DMN Knowledge and Information Requirements Automatically” I explained that it is not necessary for a human modeler to define all those arrows-requirements: they can be defined automatically when all decision tables (BKMs) are already specified! OpenRules-7 does exactly that essentially simplifying the decision modeling process.

If we don’t have to worry about the arrows, instead of DRD we may create a simple hierarchy of decision variables that defines major building blocks of the future decision model. Here is a simple hierarchy for Nick’s decision model “Credit Card Application”:

       Application Status 

• • Applicant Demographic Suitability
    • Applicant Private Credit Card Demographic Suitability
    • Applicant Student Credit Card Demographic Suitability

• • Applicant Credit Card Eligibility
    • Applicant Credit Score
    • Applicant Balance Transfer Credit Card Eligibility

This hierarchy defines key decision variables which should be calculated by decision tables (or other BKMs) in the top-down fashion. For example, on the top-level we need a decision table that defines Application Status as Accepted or Rejected. I added the variable Application Status as it corresponds to Nick’s business process. This decision variable depends on two other decision variables:  Applicant Demographic Suitability and Applicant Credit Card Eligibility. Then we need to construct a decision table that calculates Applicant Demographic Suitability using variables Applicant Private Credit Card Demographic Suitability and Applicant Student Credit Card Demographic Suitability, etc. When all decision tables are constructed, OpenRules-7 will find a way to correctly execute the decision model without forcing a user to manually provide arrows that define “who should be executed after whom” and “which data to be used”.

Here is the decision table that determines  Application Status and also explains why Accept/Reject status was reached:

All other decision tables are almost one-to-one representations of Nick’s decision tables in the DMN formats supported by OpenRules. All decision tables were created in Excel. Here they are:

Now, all pieces of business logic are defined. Let’s create a glossary by copying/pasting decision variables from the above decision tables and distributing them between two business concepts “Applicant” and “Application”:

In what order should thee decision tables to be executed? Previously we need a human to tell us this by either defining knowledge requirements in the DRD or by using OpenRules tables of the type “Decision” to specify an execution path. However, all output decision variables are defined in conclusions of our decision tables and the variables, which they depend on can be found inside decision table conditions (and potentially in FEEL formulas inside their cells). Using this fact OpenRules-7 builds the execution path automatically. It can do it on the fly or use the standard batch file “build.bat” to generate the execution path in the form of the following Excel table:

(automatically generated by OpenRules)

Our decision model is almost ready for testing – we just need to add test cases. Here are datatypes for business concepts “Applicant” and “Application” as defined in the glossary:

To test our decision model, we create a Data table with 4 test applicants (click on it to enlarge):

Here is a Data table with corresponding applications for these applicants:

Here are 4 test cases with expected results:

We can execute these test cases using the standard batch file “run.bat”. Here is an execution protocol for the Test 1:

To understand WHY all intermediate and final decisions were made, we may look at the automatically generate HTML report (click on it to enlarge):

CONCLUSION. The new OpenRules release 7.0.0 allows a business analyst to concentrate of defining business logic and its tests and not to worry about the execution order or knowledge/ information requirements presented with DRD’s arrows. OpenRules users will especially appreciate the ability of OpenRules-7 to automatically generate an execution path if they compare the described decision model with the old one: many unnecessary decisioning constructs simply disappeared.

P.S.  I’d like to clarify that DMN DRDs are very helpful decision constructs especially if you create them using such graphical tools such as Trisotech DMN Modeler or DecisionsFirst Modeler and associate a lot of useful information with different decision nodes. But these decision modelers similarly to OpenRules should be able to automatically define all arrows (such as knowledge requirements) or at the very least they may validate the arrows manually drawn by a user as more decision tables (BKMs) become implemented.

P.S.S. Making DMN knowledge and information requirements optional will also essentially simplify the DMN interchange format and its interpretation by different execution tools.