Drools - How we overcame the drastic conditions evaluation

One year ago, we started a project called keystone, a rules evaluation engine based on spring-boot. The high level architecture as follows [1]. It exposes several REST endpoints to evaluate some business rules. When a request hits the engine, several parallel calls hit the described endpoints based on the input parameters. ( We use RxJava to handle the async calls and zip out the results.) Then we have various IF ELSE blocks to evaluate the rules. And sent back the results back to the client after the rule evaluation.

At the beginning the rules were quite simple and everyone was happy with the architecture and the evaluation of the rules. There was a manageable number of rules with simple if else blocks, and the changes to existing rules were quite minimum at that time.

But when time passed by, there were many requests from partner teams and the rules engine team was asked to implement more logical evaluations, so new REST endpoints were introduced. Now the problem became more complex and hard to manage the rules in our code as well as presenting the rules. When some business users ask what happens if we use the REST endpoint X, we have no way to easily explain all the conditions and evaluation paths in a simple manner.

Then the drools comes into the picture to address this problem. We evaluate the drools and did POC for both the drl file and decision table approaches. The code becomes much more simpler and lean since all the evaluation tree was derived from the decision table. Then we presented both the drl file and decision table to the business people and they were really admired the decision table approach since it became more easy to present to other partner teams.

See below for an example decision table which is being used. It contains 10 decision points before the evaluation.

Let’s look into a sample which use a decision table to evaluate some rules. 

Sample use case.
We are going to evaluate the loan rate given by ABC bank depending on the customer is a GOVERNMENT or a PRIVATE worker and currently a retired person or not. Decision table for the above scenario is as follows.

Decision table for the above use case.

Maven dependencies.

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15

<dependency> <groupId>org.drools</groupId> <artifactId>drools-core</artifactId> <version>7.0.0.Final</version> </dependency> <dependency> <groupId>org.kie</groupId> <artifactId>kie-spring</artifactId> <version>7.0.0.Final</version> </dependency> <dependency> <groupId>org.drools</groupId> <artifactId>drools-decisiontables</artifactId> <version>7.0.0.Final</version> </dependency>

Load the Configurations

1 2 3 4 5 6 7 8 9 10 11 12 13 14

public KieContainer getKieContainer() { KieServices kieServices = KieServices.Factory.get(); KieFileSystem kieFileSystem = kieServices.newKieFileSystem(); kieFileSystem.write(ResourceFactory.newFileResource(drlFile)); KieBuilder kieBuilder = kieServices.newKieBuilder(kieFileSystem); kieBuilder.buildAll(); KieModule kieModule = kieBuilder.getKieModule(); KieContainerkieContainer = kieServices.newKieContainer(kieModule.getReleaseId()); return kieContainer }

We use the ExecutionBase class to hold the facts and the conditions. Fact is of course the Customer object and isGovernmentWorker() and is Retired() conditions.

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24

public class ExecutionBase { private Customer customer; public Customer getCustomer() { return customer; } public void setCustomer(Customer customer) { this.customer = customer; } public boolean isGovermentWorker() { return this.customer.getWorkType().equals(WorkType.GOVERNEMNT); } public boolean isRetired() { return this.customer.getAge() > 60; } public void execute(String result) { System.out.println(result); } }

After the execution we get the entitlement loan rate for a bank customer. Try out the sample code link.

To summarize the post, we discussed how we can leverage the drools decision tables to overcome if there are drastic conditions evaluations in your program and you want to change those conditions without touching the code. Other advantage is the decision table can be used as a tool to describe your execution flow for non technical people. That’s it for this post and hope to see you in another exciting post.