Drools Integration: Moving away from JS engine

In Hrvatska Telekom, we provide customers a range of offers, combo offers, benefits, options & additional services, etc. All offers are stored in a product catalogue DB. To provide these offers to customers, an aggregator service is used that validates & filters these offers and runs a complex rule & price engine on it. Over a while, this service has become a fat monolith with overloaded features. Now, any additional business condition causing the increase in API latency is complex & hard to debug codebase. As a solution, we started to explore an independent microservice that extract business rules & execution from existing monolith service. To improve API latency, will use distributed cache (Redis), in-memory cache, and Drools as a rule engine.

Problem:

Aggregator service is overloaded with many functionalities & implemented business use cases.

Rules are stored in catalog DB, hard code JS rules are embedded in database.

Rules are compiled and executed at runtime using JS engine.

Rule engine is tightly coupled with aggregator service and any modification is nightmare.

Current architecture

Solution:

Splitting aggregator service and developing an independent rule service.

Separate repo (Rules DB) to store all business rules.

A simple & intuitive UI client to add/modify/delete rules.

Moving from JS rule engine to Drools for decoupling application code & business logic.

Architecture after Solution

Drools introduction:

Drools is a business rule management system which is open source with a forward-chaining and backwards-chaining inference-based rules engine, allowing fast and reliable evaluation of business rules.

● It provides template base rule definitions

● It is implemented using JSR-94

● It has a decision table facility

● It is integrated with Spring

Bringing Drools into the ecosystem as it provides us with the following benefits:

Journey So far..

Drools can be implemented in two ways:

1. Embedded Java application
2. Standalone Drool Server (KIE) deployment

We started with the embedded option, there are 3 different ways to write rules in Drool.

● Drool interface

● Spreadsheet

● Simply create a file with DRL extension and writing rules in a declarative manner using MVEL language.

We started replacing JS Rules & converted complex JS Into MVel. After converting all rules from JS to Drools, the benefits which we found in our system were as follows:

● It is working more efficiently as compared to JS Rule Engine.

● Clean & easy to understand the codebase. Reduction in code bloat.

Further Improvement (Drool as standalone service)…

In the Second phase our main goals are:

Drools As a Standalone service.

Business driven drool UI integration.

Rule versioning.

Integration with Drool Service.

Final Impl architecture

• Container 1: Embedded rule engine using drool
• ** Container 2: Drool as standalone service

Drools As a Standalone service: KIE Server

Drool provides KIE (Knowledge is everything) Server. The KIE Server is a modular, standalone server component that can be used to instantiate and execute rules and processes. It exposes this functionality via REST, JMS and Java interfaces to the client applications. It also provides seamless integration with the KIE Workbench.

● We can create as many instances as we want and integrate it with Business central.

● As we can see in the Image there are 3 running KIE Servers and Business central is communicating with all of them

● We can Deploy KJar to KIE Server using Rest Client, Business Central or Our Application as well

● We can Tell KIE Server to continuously check for the up-gradation if there is any in artefact repo for KJar

Business driven drool UI integration: Business Central

It’s a full-featured web application for the visual composition of custom business rules and processes. It provides us with a lot of features like developing rules projects, using UI deploying them on different KIE Server, managing versioning, managing server and many more functionalities.

● We can develop and publish Kjar to artifact Repo.

● We can deploy diff Kjar versions to different KIE servers which are integrated to Business central.

● We can integrate diff KIE server to Business central as in pic above KIE server is integrated to Business central.

Rule Versioning: Kjar(knowledge Jar)

Kjar is a Drools project which contains a list of DRL files (Rules) and other Drools artifacts that define the rule base together with some pre-generated classes implementing the constraints and the consequences. This Jar can be developed using UI (business Central) or developing Tools IDE and can be stored to any artifact repository.

● Versioning can be maintained using the Artifact repository.

● As we can see in the image there are three KIEContainers which are deployed to KIE Server 1.

● We can deploy as many versions as we want on the same KIE server and while communicating to KIE Server we can tell Which version we want to calculate the rules.

● At any time we can do changes and deploy to repo.

Integration with Drool Service

Develop a drool service which communicates with Drools (KIE Server) using core KIE Apis via KIE Server rest Commands.

Future Scope

● Security using Keycloak.

● Prometheus to collect and store metrics related to business asset activity in Drools.

Resources:

https://docs.jboss.org/drools/release/7.66.0.Final/drools-docs/html_single/#_wb.quickstartimportexamples