Introduction
A business rules engine (BRE) is an application that manages decision processes using pre-defined logic to determine outcomes. BREs enable precise decision-making and are especially useful for complex dependencies, as well as in instances where regulatory or organizational rule changes frequently require logic changes. Automation can mean the difference between rules changes taking months vs. hours. The benefits of having Business Rules Engines are huge, some of them being improved compliance, improved quality of work, reduced manual work, and chances for human errors.
SnapLogic platform does not support any rules engine so, we have decided to try to connect the SnapLogic platform with Drools as a rule engine and try to execute business rules with them.
In this blog post, we will present the Drools Transformer custom-developed snap. As I said, we have decided to make a connection between SnapLogic and Drools as a rule engine and develop a snap which can centralize the business logic of the clients and make the whole process much faster and cheaper. It means when some client has defined specific business rules with a lot of conditions we can use Drools rule engine to resolve these kinds of conditions without writing a huge amount of code with many nested if-else statements.
Drools
Let’s say a couple of words about Drools. Drools is a Business Rule Management System (BRMS) solution. It provides a rule engine, which processes facts and produces output as a result of rules and facts processing. The centralization of business logic makes it possible to introduce changes fast and cheaply.
It also bridges the gap between the Business and Technical teams by providing a facility for writing the rules in a format that is easy to understand.
Use-case scenario
We have defined a real case scenario about discount offers as an example of some business rules. For that purpose, we have defined some rules and those are:
- 0% of discount for standard users
- 15% of discount for premium users
- 10% of additional discount for first purchase
Getting started
To make the connection between SnapLogic and Drools, we have defined a real case scenario explained above. We will simulate the solution of that use-case scenario building a simple pipeline that will contain:
- JSON Generator snap which will contain the expected input data
- Mapper snap will be used to map the wanted values
- Drools Transformer snap will be expecting .drl file where we will write our rules based on the requirements (input data) modify and output the data after resolving the conditions
Step by Step
In this section, we will explain the entire process of simulating the solution for this use-case scenario.
First, we need to analyze the input that we are expecting:
You can see that here we have a list of Users and Products they want to buy. Based on this information and previously defined rules we can start and write our rules into a .drl file.
As you can see in this example the .drl (the rules file) has its own syntax. First, we need to declare the types that we have in this case Product and User and after that, we have to write the rules that we have defined. So, these types will be mapped according to the input document that we expect in JSON format and after that, all rules will be fired and the data will be modified, transformed, and sent as an output document in JSON format. Also, we want to point out that the .drl file is the most important because here we are defining the rules for the conditions that we want to resolve and we can easily modify the file and define new rules based on the input that we are expecting.
When we are finished with analyzing the expected input data and writing the rules we need to prepare the pipeline and enter all the data that is needed and simulate the solution of the use case.
The first component will be the JSON Generator where we will put the sample input data in JSON format.
Click on Edit JSON and add the sample input data:
After adding the JSON click OK and save.
The next step is to map the wanted values:
You can see we are mapping the input values under User and here we also have the information about the product that the user wants to buy. You can map the values as you want it depending on how the data should be processed.
The next step is to upload the .drl file where we have defined our rules in the Drools File section and specify the Fact Type that we want to map and display on output (in this case User) in the Fact Types section. Also, we can have multiple Fact Types, which is based on the mapping we are doing and the data we want to display according to the client’s requirements.
In the end, after doing all of these steps we can run this pipeline and check the output document:
After the successful execution of the pipeline, we can check out the output by clicking on the document image at the end of the pipeline.
When we expand the output, we can see that all of the requirements and rules that we have defined above are successfully attached and all of the conditions are resolved.
Conclusion
In the end, after successfully simulating the solution of this use-case scenario we can say that now we can easily resolve any kind of use-cases like this using the Drools Transformer snap and Drools as a rule engine to centralize the business logic of the clients and make the whole business process much faster and cheaper.
