Libraries of Decision Microservices

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:

After download, run LoanServices/build.bat.

The DMN diagram looks large and complex:

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 them as AWS Lambda functions and used to configure the final 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:

Rules Repository

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:

Common/Glossary.xls

All services include a reference to the file rules/Common/DecisionModel.xls that refers to this Glossary in the Environment table:

Common/DecisionModel.xls

Here are the files DecisionModel.xls and Rules.xls for the very simple decision service “ApplicationRiskScore”:

ApplicationRiskScore/Rules.xls
ApplicationRiskScore/DecisionModel.xls

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:

Decision projects (one per service)

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”:

project.properties

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.

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:

Different Implementations 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:

Assembling decision service PreBureauProcessing

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:

Assembling decision service PostBureauProcessing

We can assemble the final “LoanOriginationResult” out of our already created and tested services PreBureauProcessing and PostBureauProcessing. However, below we will explain how to deploy these two services on cloud and then orchestrate them to build 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:

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:

Service Orchestration Rules

They use two services described in this table:

To test this final service we created the file LoanOriginationResult/tests/Test.xls with the folliwing test cases:

Then we created a regular OpenRules project “LoanOriginationResult“ and tested our final service using the standard test.bat. Here are the final results:

If we run OpenRules Explorer by calling LoanOriginationResult/explore.bat, we will see the following diagram: