The Need for Business Rules Engine
Nowadays, world markets are full of regulatory requirements. Numerous business rules and decisions are made within all kinds of industries to process claims, validate transactions, compute benefits, determine rates, and deal with exceptions. These types of policies or rules would be easy to manage if they were fixed. Still, most of the business world has intricate processes that are continuously evolving. As a result of this kind of change, businesses keep changing, and with it also the business rules, placing strains on the system, processes, and employees in a given industry. Using business rule engines, businesses can minimize the entanglement of complex systems and separate them from the rest of the application enabling them to better progress in changes with business policies while at the same time minimizing the implementation and support time.
Rules Engines (Buzzwords)
For many senior developers, rules engines are something to be feared or admired from a distance. Rules engines are often seen as buzzwords, mystery boxes on an architectural level, and it’s difficult to know how to apply or when to apply a technology until being confronted with it first-hand. Rules engines separate the management of business rules from the rest of the application. Business rules are a collection of statements that define the behavior and operations of a business. At this point, someone might still be buzzed as to why rules are something useful. In terms of one rule or a few, it might still be considered to go directly with the imperative style. Developers are used to breaking down the requirements into smaller steps and having to give away that control to the declarative style can sometimes be intimidating.
Rules engines let us define rules in a declarative way, compared to the imperative programming type that is used by languages such as Java, where the sequence of instructions is explicitly defined and when code execution should happen.
Declarative style programming, on the other hand, doesn’t allow direct control of the sequence instructions, instead, it lets the data be inserted in the rule that should be executed.
The main strength of business rules doesn’t come from one rule or a small group of rules, it comes from a very large number of rules, an ever-changing group of rules that define a complex system, which implemented in imperative style would require extensive work to maintain.
A collection of rules can work together to define complex systems as the growth of the business rules can grow exponentially, whether the need to implement new functionality, change existing ones, or replace or change the system behavior in new unexpected ways occurs, the only modification needed with rule engines is to remove the unnecessary rules and apply the new ones. This is possible because business rules work independently, they can be easily updated, and each rule has minimal control of the information that it needs, allowing more business people (developers) of different backgrounds to collaborate and write rules.
Over the course of this blog, the spotlight will be on the Drools rules engine and an imperative implementation based on Java using the MuleSoft integrations platform.
MuleSoft BPM Support
In Mule 3.x, Drools business rules could be executed by the out-of-the-box bpm component. Starting from Mule 4 the bpm component has been dropped.
See References for more information about Mule 4 changes: https://docs.mulesoft.com/mule-runtime/4.1/mule-4-changes
The preferred way now is to use Drools as a standalone installation and expose the rules interface as REST APIs to integrate with the Mule flow. Here Drools is implemented as custom Java code to execute the Drools rules and call it from a Mule flow, later also shown as a custom module developed with the Mule SDK.
Business Rules and MuleSoft API-led connectivity
MuleSoft is known for its API-led connectivity methodology to connect data to applications through reusable APIs. These APIs are developed to unlock data from systems, compose data into processes, and deliver an experience.
Today API is not just a technical interface used by developers to define some methods, their scope is not just limited to internal use, API interfaces define new business models. Nowadays API developers are exposing the interfaces for external uses, for example, Google, Uber, Amazon, etc…
APIs provide a way to integrate, connect, and innovate old through new platforms. APIs turn out to be one of the key decision-makers as APIs provide the infrastructure to be able to build systems around their products.
Using business rules engines as APIs to accommodate the needs of programmers, businesses, and industry standards, opens new kinds of change and transformation. APIs scope allows businesses and their clients to accumulate most of the business agreements through API platforms. These agreements are bound to business processes. Business Rules Management System like Drools allows the implementation of these processes into executable business rules.
MuleSoft and Drools Integration
Drools have a Workbench in which the rules are defined in a spreadsheet-like form (Guided Decision Tables) which can also be defined in a standard drools rule definition (*.drl) file. To be more simple in the installation process we used Business Central (formerly known as Drools Workbench).
The Business Central Workbench is a web application for designing and deploying Kie assets, such as Drools rules, processes, and data models. It is an exceptional tool to bridge the gap between developers and business people with little technical knowledge of the specifics of implementation into the development cycle because it provides a user-friendly environment for rule writing.
In the example implementation of a working Mule flow and integrated Drools Processes, a POJO class is created to represent the facts that will be matched against the rules, like the following:
After the POJO is created, start the JBPM server, during the time of writing the JBPM version is 7.42.0, the same goes also for the Drools dependencies. When the server is started log in to the application, add the newly created POJO model .jar file to the repository for using it later in the rules, create a project add a Guided Decision Table asset, and create the rules definition there.
The above-guided Decision Table (rules) should not be hard to interpret. Once the writing of the rules is done, continue with the Build and Install process. This will build the .jar file in the .m2 local repository and install it. From there it will be used in the next Mule flow.
Next, go to Anypoint Studio and create a Mule Project. First, in the pom file add the following dependencies:
After that in the src/main/java a class is created, which in this case is named RulesExecutor.java, and a static method is written so it can be invoked by the Invoke Static connector of the Java module.
The xml configuration for the mule flow looks like the following:
The xml configuration should be easy to read and recreate. When everything is set and configured, the mule application can be started and a request from Postman can be made:
MuleSoft Custom Drools BPM Module
Instead of cluttering the project structure with custom Java classes to integrate Drools as a service to the mule flow, there is a possibility to create a custom Drools module connector which can be added like any other module in the Mule palette by providing it as a dependency in the pom.xml file and classifying it as a mule-plugin.
From there it will appear in the Mule palette, and it can be used like any other connector:
The first connector seen here in the mule palette is for a file-based rules implementation (*.drl file) and the other is for a .jar base implementation like the one previously seen in the code.
Conclusion
Even though MuleSoft has dropped the support for BPM and Drools, it can still be integrated in many ways. This blog showed only 2 ways, the first being implemented as Java code in the project structure of the Mule Project and the later one as a custom Mule module added as a dependency to the project.
MuleSoft over the years has proven its flexibility to be extended by third-party technologies regardless if they are supported by MuleSoft or not, they can be implemented in various ways.
