58

Drools: How Can We Overcame the Drastic Conditions Evaluation?

 5 years ago
source link: https://www.tuicool.com/articles/hit/3EbaE3i
Go to the source link to view the article. You can view the picture content, updated content and better typesetting reading experience. If the link is broken, please click the button below to view the snapshot at that time.

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.

Free Resource

Join the DZone community and get the full member experience.

Verify, standardize, and correct the Big 4 + more – name, email, phone and global addresses – try our Data Quality APIs now at Melissa Developer Portal!

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.

FjmQBnq.png!web

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.

7rIvEvY.png!web

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:

NZnEbeV.jpg!web

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

YfaaEvb.png!web 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() > 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 .

Znm6VzR.png!web

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!

Developers! Quickly and easily gain access to the tools and information you need! Explore, test and combine our data quality APIs at Melissa Developer Portal – home to tools that save time and boost revenue. Our APIs verify, standardize, and correct the Big 4 + more – name, email, phone and global addresses – to ensure accurate delivery, prevent blacklisting and identify risks in real-time.


About Joyk


Aggregate valuable and interesting links.
Joyk means Joy of geeK