OpenRules empowers 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. OpenRules allows business analysts to create a special orchestration decision model that describes under which conditions such services should be invoked and how to react to their execution results.
OpenRules decision tables support special action columns of the type “ActionExecute” which are usually used to execute other decision tables. But they also can execute different external services by calling them using their unique names without worrying about their implementation and deployment.
This library has two major decision services “BureauStrategy” and “Routing” deployed as AWS Lambda functions. We would define a new decision model “Result” that orchestrates these two services in accordance with the following logic:
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:
The first rule executes the decision service “BureauStrategyService” unconditionally – see the column “ActionExecute”. This service is supposed to define the decision variable “Bureau Strategy”. The second rule will check if Bureau Strategy is DECLINE, and if it is, it will set the Loan Origination Result to DECLINE and do nothing. Otherwise, the 3rd rule will execute the decision service “RoutingService” that will define the decision variable “Routing” and then the remaining rules will assign the same value to the final Loan Origination Result.
How do these external decision services are defined? Using a special new table of the type “DecisionService“:
The first column specifies service names exactly as they are used in the previous table. The column “Service Type” tells OpenRules that these services are actually REST web services, and the third column provides their endpoint URLs automatically generated during the one-click deployment of these as AWS Lambda functions.
The table “DecisionService” include the 4th (optional) column “Business Objects”
that describes the parameters of each service that correspond to the business concepts defined in the 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 service 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.
When you click on “explorer.bat”, it will show the live diagram of this decision model: