Recently I needed to look over drools and I will go over what I learned in a series of posts. This is the first one. Its aim is focused on practicality rather than theoretical learnings. Drools is a business rule engine. This means when you need rules in your application your mind should at least think of drools for a bit. If it’s a good fit or not that’s to be determined. Here are some tips in helping you decide that:
- there are a few rules and they are static; they do not change ; don’t use rule engine
- you need to be able to change rules dynamically, maybe at runtime; a rule engine may be a good idea
- you need a visual tool for changing rules in production, rule engine might help
- rules will be maintained by non-technical people, use rule engine
- you are on a thigh deadline, don’t use a rule engine unless you are familiar with it
- you are using excel for documenting the rules, rule engine will help
My use case was the following. I had to implement initially 20ish rules all of them being static. Most of them were fairly easy, maybe 3 or 4 more complex. But another requirement was for non-technical guys to be able to add new rules using an interface. When asked roughly how many the answer I got was hundreds. Moreover these guys kept all the rules in excel spreadsheets and created macros and function that simulates a rule engine. It was obvious at this point that I need a rule engine and drools was the choice.
Drools Workbench
I started with Drools workbench as a way to add my rules. I recommend to start with the showcase docker image as we want to focus on the rules and the configuration can come later on. Or if you are impatient you can use this repo for inspiration. If everything is installed correctly you will the the workbench page.

After login you can start adding your rules. At this point you will need to be familiar on how to write rules. For this the documentation page is more than enough.

From the above picture we notice the obvious. Drools can do more than rules. These includes BPMN, optaplanner. Well to be exactly not Drools, but KIE. By the way KIE stands for Knowledge Is Everything. I needed only the rules engine from this group and didn’t care about the others. In this post we’re gonna interact with Design and Deploy pages.
I would recommend to start with the samples just to get you going, or if you are already familiar with drools project you could import your project from the your git repository. If you choose the latter remember that your project must be a maven project and you should have in src/main/resources a kmodule.xml file. Let’s start by defining a problem statement.
We want to import some products from an external system into our system. Not all the products should be imported, only the ones with a OK status. For all the products in the same category we want to calculate the average price.
The main thing that I want to highlight here is the type of objects that can be part of a knowledge base. At this point you should be familiar with Drools Engine (Phreak) and how to write rules. Depending on the use case, you might work with Data Objects, DRL files, Guided Decision Tables, Guided Rules. More on how to create assets you can find by accessing authoring rule assets.
We need a Data object that represents the import structure.

Per the statement two rules must be added.
package com.test.importproducts;
rule 'not_ok'
salience 2
when
$ip: ImportProduct( status!="OK" )
then
delete( $ip );
end
package com.test.importproducts;
rule "average"
salience 1
when
$categories: Object() from accumulate(ip: ImportProduct();
collectSet(ip.getCategory()))
$category: String() from $categories
accumulate(ip : ImportProduct(category == $category);
$avgPrice: average(ip.getPrice()));
then
System.out.println("Category "+$category);
System.out.println("Price "+$avgPrice);
System.out.println("-------------------");
end
After all the rules and data objects are created(aka the knowledge base is ready) it’s time to deploy them somewhere. Before going onto that, we need to understand how the projects are packages by the workbench(and generally). You will see in the top right corner of the workbench

If you think you recognise the words build and deploy you might be right. If you though of maven you’re a winner. Yes, there are packages as maven jars, more specifically knowledge jar (kjar). And yes there is a .m2 directory inside the workbench. We will come back to this later.
KIE Server
By now we’ve found how to create rules. Now let’s focus on how to deploy them. Before going forward you should be somewhat familiar with it. Let’s start with the showcase docker image as well, but we’re gonna change it a little bit. By using the showcase image directly we assume that the workbench and kie server will live in the same docker instance. It’s fine for testing purposes but when going to production you might want to scale the kie server. A docker setup example can be found here.
docker run -p 8180:8080 -d --name kie-server2 \
-e KIE_SERVER_LOCATION=http://172.17.0.3:8080/kie-server/services/rest/server \
-e KIE_SERVER_CONTROLLER=http://172.17.0.2:8080/business-central/rest/controller \
-e KIE_SERVER_CONTROLLER_USER=admin \
-e KIE_SERVER_CONTROLLER_PWD=admin \
-e KIE_SERVER_PWD=kieserver1! \
-e KIE_SERVER_USER=kieserver \
-e KIE_MAVEN_REPO=http://172.17.0.2:8080/business-central/maven2 \
-e KIE_MAVEN_REPO_USER=admin \
-e KIE_MAVEN_REPO_PASSWORD=admin \
my-kie:latest
The following properties realise the connection with drools workbench.
- KIE_SERVER_CONTROLLER – tells KIE server the location of the controller, which is the workbench. In the above example it communicates through rest, but websockets in another option.
- KIE_SERVER_CONTROLLER_USER and KIE_SERVER_CONTROLLER_PWD – the authentication required to communicate with the controller
- KIE_MAVEN_REPO – the location of the workbench repository
- KIE_MAVEN_REPO_USER and KIE_MAVEN_REPO_PASSWORD – the credentials required to access the above repository
Remember that I mentioned that I will come back to the workbench repo earlier. This is it. KIE server will access the repo and will download the kjars and deploy them into the residing Wildfly server.

From the picture you might notice that the server has only decision capabilities. These can be controller by setting up the following program arguments:
-Dorg.jbpm.server.ext.disabled=true
-Dorg.jbpm.ui.server.ext.disabled=true
-Dorg.optaplanner.server.ext.disabled=true
-Dorg.kie.executor.disabled=true
If everything is setup correctly you will see
Whatever changes you make to your project you will need to hit Deploy in order for those changes to propagate to KIE server. Or you might use a scanner.

By setting a cron expression (eg 5 seconds) it will trigger the scanning of the maven repo for changes.
Now we are ready to integrate with our application. But this is a topic for a future post. You can find this example in my repo. In order to import it just hit import button in the projects workspace.

1 thought on “Drools – Workbench and KIE Server”