Over a million developers have joined DZone.
{{announcement.body}}
{{announcement.title}}

Drools: How Can We Overcame the Drastic Conditions Evaluation?

DZone's Guide to

Drools: How Can We Overcame the Drastic Conditions Evaluation?

Want to learn how to overcome drastic conditions evaluations with drool? Check out this tutorial to learn more about the drools decision table.

· Java Zone ·
Free Resource

Download Microservices for Java Developers: A hands-on introduction to frameworks and containers. Brought to you in partnership with Red Hat.

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.


In 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 come 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 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 really admired the decision table approach, since it became easier to present to other partner teams. See below for an example decision table that is being used. It contains ten decision points before the evaluation.

Image title


Let’s look into a sample that uses a decision table to evaluate some rules. 

Sample Use Case

We are going to evaluate the loan rate given by ABC bank, depending on if the customer is a GOVERNMENT or a PRIVATE worker and currently a retired person or not. The decision table for the above scenario is as follows:


The decision table for the above use case is as follows:

Maven Dependencies

 <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

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. The fact is, of course, the Customer object, isGovernmentWorker() , and isRetired()  conditions will look like the following:

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() &gt; 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 this 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. Another 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! I hope to see you in another exciting post soon!

Download Building Reactive Microservices in Java: Asynchronous and Event-Based Application Design. Brought to you in partnership with Red Hat

Topics:
java ,maven ,drools ,condition ,tutorial ,if else

Published at DZone with permission of

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}