OpenRules provides business users with abilities to build and deploy operational decision microservices. Now we empowered business users with an ability to assemble new decision services by orchestrating existing decision services independently of how they were built and deployed. The service orchestration logic is a business logic too, so it’s only natural to apply the decision modeling approach to orchestration. In this post I will explain how to orchestrate different services by creating a special orchestration decision model that describes under which conditions such services should be invoked and how to react to their execution results.

These days a microservices architecture became highly popular mainly because it allows the individual services to be deployed and scaled independently, worked on in parallel by different teams, built in different programming languages across the broadest range of multi-cloud and multi-device deployment options. Microservices are loosely coupled services but their orchestration logic could be quite complex and is frequently implemented using BPM engines or AWS Steps functions. However, this is business logic too and, like with regular  decisioning logic, it’s much better to represent it using business decision modeling. We may place this logic in a separate Orchestration Decision Model. Below I’ll describe how to do it with OpenRules Decision Manager.

OpenRules decision tables have special action-columns of the type “ActionExecute” that is usually used to execute other decision tables. To be able that to execute different services upon certain conditions, we expended “ActionExecute” with an ability to execute different external services by their unique names without worrying about their implementation and deployment. To describe such external services OpenRules added a special new table “DecisionService“. I will explain how it works using the Loan Origination example from the DMN Section 11.

The latest OpenRules release include a workspace “openrules.loan” that implements this example as a library of decision models with several intermediate goals and two main goals “BureauStrategy” and “Routing” deployed as external decision services:

The high-level goal “Loan Origination Result” is an example of the orchestration decision models. The orchestration logic here is relatively simple:

Execute decision service “BureauStrategy” that should determine the goal “Bureau Strategy”. If Bureau Strategy is DECLINE, then set Loan Origination Result to DECLINE, and stop. If Bureau Strategy is not DECLINE, then execute decision service “Routing” that will determine the goal “Routing”. If Routing is DECLINE, then set Loan Origination Result to DECLINE. If Routing is REFER, then set Loan Origination Result to REFER. If Routing is ACCEPT, then set Loan Origination Result to ACCEPT.

This logic can be naturally presented in the following table:

Here the third column “ActionExecute” may execute two decision services: “BureauStrategyService” and “RoutingService”. The actual implementation of these services is described in the following table:

The column “Service Type” defines these services as REST web services and provides their endpoints – in this particular case both services were deployed as AWS Lambda functions, the default OpenRules deployment destination (it was done with an instant click). The table “DecisionService” may have the 4th (optional) column

that describes the parameters of each service that correspond to the business concepts defined in eth common Glossary. If the column “Business Objects” is omitted (like in the above table), all business objects will be passed to all decision services even if “BureauStrategyService” doesn’t need BureauData.

Along with REST web services, we support other types of services. For example, you may get essentially faster execution by taking advantage of the fact that your services are deployed as AWS Lambdas by using their ARN addresses as endpoints:

If your decision services are deployed as AWS Lambda functions you even don’t have to provide the complete ARN addresses, and can simply write their names as in the following table:

OpenRules will automatically expand the name like “BureauStrategy” to “arn:aws:lambda:us-east-1:395608014566:function:BureauStrategy”.

Another supported type of services is regular Java classes automatically generated by OpenRules from decision models:

You also may invoke any static Java method, e.g. use Service Type “JavaMethod” and Service Endpoint “loan.origination.EmailService:send” to send an automatically generated email to the Applicant.

The general architectural schema with a special Orchestration Decision Model is presented below:

I will provide the detailed description of this schema during my upcoming BBC-2020 presentation “BUILDING, DEPLOYING, AND ORCHESTRATING COMPLEX DECISION SERVICES” on Oct. 22 at 2:00 PM PST.