When OpenRules customers build complex decision support applications, they usually avoid using large monolithic decision models. Instead, they build libraries of small decision microservices that cover the majority of domain-specific business functions. Then they use these microservices to assemble larger decision services. Like in LEGO you construct large objects (vehicles, buildings, etc.) from smaller interlocking parts, with OpenRules you construct large decision services out of small decision microservices which can be reused to build other decision services. Sometimes such microservices requires domain-specific decision tables and even supporting Java libraries.
The general architectural schema of a domain-specific library of decision microservices is shown above. It includes multiple decision models that automate smaller business goals and being tested as stand-alone apps and deployed as loosely-coupled decision services. It also includes a special Orchestration Decision Model that describes how to orchestrate other decision services.
OpenRules provides a sample of such library in for the Loan Origination domain using an example from the DMN Section 11. You may freely download, analyze, and and execute it from here:
- LoanServices_9.1.0.zip – a workspace with simple and complex decision models for Windows
- LoanServices_9.1.0.tar.gz – the same for Mac or Linux
This library implement the following services:
There are many business goals and sub-goals, but the goal “Loan Origination Result” depends on two main business goals “BureauStrategy” (defined during Pre-Bureau Processing) and “Routing” (defined during Post-Bureau Processing).
Below we describe how we created the library of small loosely-coupled decision microservices and used them to configure two larger services PreBureauProcessing and PostBureauProcessing. We deployed these two services AWS Lambda functions and used them to configure the high-level decision service “LoanOriginationResult“.
How Decision Services are Organized – Rules and Tests Repository
If you open the file structure of the downloaded workspace “loan.services” you will see its repository folder:
This repository has two main sub-folders:
- “rules” that includes one sub-folder with business rules for each decision microservice does not mater how big or small it is.
- “tests” that includes similar sub-folders with test cases for each decision microservice.
All services have a similar organization with two Excel files “DecisionModel.xls” and “Rules.xls”. They all share the common global Glossary located in the file rules/Common/Glossary.xls:
All services include a reference to the file rules/Common/DecisionModel.xls that refers to this Glossary in the Environment table:
Here are the files DecisionModel.xls and Rules.xls for the very simple decision service “ApplicationRiskScore”:
The test case for this service are described in the file tests/ApplicationRiskScore/Test.xls using the following tables:
How Decision Services are Built – Decision Projects
Every decision service such as ApplicationRiskScore can be built, tested, and deployed as a stand-alone service that later can be used by other services. For each decision service we created a separate OpenRules project. Here are the list of the all projects and ApplicationRiskScore being expanded:
There are only two unique files inside each project: “pom.xml” and “project.properties”. All pom.xml files use the same groupId, dependencies, and plugins, and only artifactId is unique:
The properties specify locations of the corresponding files “DecisionModel.xls” and “Test.xls”:
You can run ApplicationRiskScore/build.bat to build the decision models and ApplicationRiskScore/test.bat to test it. Using ApplicationRiskScore/explore.bat you may open OpenRules Explorer for the selected decision model, see its graphical diagram, test, and debug your model.
Similarly you should run “build.bat” to install all other services except “LoanOriginationResult”.
How to Resolve Name Duplication
There is the decision variable “Risk Category” that should be calculated differently during Pre-Bureau Processing and Post-Bureau Processing. We did not want to use different names for the same decision variable and make decision services who use this variable (such as Affordability) to “be aware” from where they are being invoked (Pre- or Post-Processing ). So, in the RulesRepository we created two sub-folders “RiskCategoryPreBureau” and “RiskCategoryPostBureau”. Their files “Rules.xls” contain different decision tables for Risk Category calculation during Pre- and Post-Processing:
It means we may continue to use the same decision variable “Risk Category” and only use the decision model “RiskCategoryPreBureau” for pre-processing and “RiskCategoryPostBureau” for post-processing.
Assembling New Decision Services from the Existing Microservices
Let’s assume that all the above decision microservices have been completed and successfully tested as stand-alone services. Now we may use them to assemble two larger services PreBureauProcessing and PostBureauProcessing.
We added the folder PreBureauProcessing into RulesRepository and created only one file DecisionModel.xls in it. It uses the following table to specify which decision microservices should be invoke in the top-down order:
The next table describes the type and location of these decision microservices:
And finally, the Environment table
along with usual reference to the Common’s DecisionModel.xls and the model’s name and goal uses “import.java” that includes references to all Java packages automatically generated for decision microservices.
Now we can execute PreBureauProcessing/build.bat and/or PreBureauProcessing/test.bat to test this newly assembled decision model.
Similarly we assemble the decision model PostBureauProcessing using these decision microservices:
Now we will deploy our already created and tested services PreBureauProcessing and PostBureauProcessing on clous as AWS Lambda functions and then use them to build the top-level service “LoanOriginationResult”.
Deploying Decision Services on Cloud
We may deploy both decision projects PreBureauProcessing and PostBureauProcessing on cloud by configuring different cloud properties for different cloud vendors such as AWS or MS Azure – read more. We use the standard batch file “deployLambda.bat” added to these project and adding the corresponding deployment properties to the file “project.properties”:
It will deploy this decision model as AWS Lambda function and will provide us with the Invoke URL such as Invoke URL: https://ca08uihagc.execute-api.us-east-1.amazonaws.com/test/pre-bureau-processing.
Now we can test this lambda function using the generated file “testLambda.bat”. Alternatively, we may test it using POSTMAN with our test cases being automatically converted to the JSON format and saved in the folder “jsons”. Here is an examples of the JSON test:
Similarly we deploy the decision model “PostBureauProcessing” as an AWS Lambda function.
Orchestrating Decision Services
Now we can create the final decision service “LoanOriginationResult“ by orchestrating decision services “PreBureauProcesssing” and “PreBureauProcesssing” already deployed as AWS Lambda functions. Here are the orchestrating rules from the file LoanOriginationResult/rules/Rules.xls:
They use two services described in this table:
Alternatively, we may describe the same services by using their names defined in their Environment tables:
The optional column “Business Objects” allows you to define exactly which objects are required by these services, e.g. PreBureauService does not need BureauData.
To test our top-level service we created the file LoanOriginationResult/tests/Test.xls with the following test cases:
Then we created a regular OpenRules project “LoanOriginationResult“, used “build.bat” to build it, and tested it using the standard “test.bat”. During the execution , this service invokes our both lambdas on as needed basis. Here are the final results:
If we run OpenRules Explorer by calling LoanOriginationResult/explore.bat, we will see the following diagram:
We may debug this service with OpenRules graphical degugger:
If you wish your may deploy this top-level service as AWS Lambda by calling LoanOriginationResult/deployLambda.bat. It also can be deployed as MS Azure function or a Docker image.
Open Your Rules! 
