Over a million developers have joined DZone.

Using Drools in Mule ESB

DZone 's Guide to

Using Drools in Mule ESB

Drools is a powerful rules engine that executes statements that might modify the state of objects depending on which rules definitions satisfy the input.

· Integration Zone ·
Free Resource

Drools is a rules engine supported by JBoss and Red Hat. It executes statements that might modify the state of the objects depending on which rules satisfy the input. It is a very powerful tool that we can use to change the state of an object by specifying various condition-based statements through which the object passes and a refined and cleaned object is achieved. Drools is a best-of-breed, open-source rules engine that also offers Complex Event Processing.

Within Mule, input is fed to the rules engine from within a flow, and the rules execute to modify the state of that input. Below is the sample of one such flow. We will be covering more about it and how to achieve Drools implementation in Mule ESB.


Before we start, I would like to mention that using Drools should only be considered if the business logic of your application is complex. If the business logic for your Mule application is relatively simple, the first consideration should be given to implementing it using Mule’s orchestration functionalities such as flows, routers, and custom components.

You should only use Drools if the business logic...

  • Is overly complex or time-consuming when defined procedurally.
  • Contains a lot of if-then-else statements.
  • Changes often.
  • Needs to be maintained by people who don’t (or shouldn’t) have access to the application itself (to recompile/redeploy it).

Business Case

Today, we will be implementing an business case where, based on the customer’s purchase history, we will be giving him or her a grade or rating. There are three main logics of our business case.

  1. If purchase is greater than equal to $10,000, they are a Platinum customer.
  2. If purchase is less than $10,000 but greater than equal to $5,000, they are a Gold customer.
  3. If purchase is less than $5,000, they are a Silver.

It is a very simple business case but it will give us a good idea how to implement it in Mule. Our Mule flow will be receiving JSON data and we will use that JSON data object to pass through our rules statement in rules engine.

{"name": "Harish Kumar","age":30,"purchase":19000}

Create a Mule project named droolsdemo. You can choose any runtime starting from 3.6. A video tutorial of same implementation and explanation is available at Drools in Mule ESB.


Before we start writing let’s add the namespace and schema location to our mule config file droolsdemo.xml:

xsi:schemaLocation="http://www.mulesoft.org/schema/mule/bpm http://www.mulesoft.org/schema/mule/bpm/3.7/mule-bpm.xsd">

Initialization of BPM

Add the below tag to your droolsdemo.xml. This tag will tell Mule that you will be using rules engine and will start up Drool's’\ working memory and all your rules and keep them ready to be called:


Mule Flow

As explained earlier, we will be getting a JSON object and we will convert it into a Java object using Mule's JSON to object transformer. Our Java class represents the customer object and looks like this:

package com.drools.demo;

import java.math.BigDecimal;

public class Customer {
 private String name;
 private int age;
 private BigDecimal purchase;
 private String customerType;

 public String getName() {
  return name;

 public void setName(String name) {
  this.name = name;

 public int getAge() {
  return age;

 public void setAge(int age) {
  this.age = age;

 public BigDecimal getPurchase() {
  return purchase;

 public void setPurchase(BigDecimal purchase) {
  this.purchase = purchase;

 public String getCustomerType() {
  return customerType;

 public void setCustomerType(String customerType) {
  this.customerType = customerType;

Rule Definiton Statements

In Drools, we write our logic in a file with the extension of .drl. This file contains your business logic in plain text format that can be easily changed and loaded at runtime if the need be. This file should be available at your project classpath to be loaded by Mule at project startup.

package com.drools.demo
import org.mule.MessageExchangePattern;
import com.drools.demo.Customer;
global org.mule.module.bpm.MessageService mule;
dialect "mvel"

declare Customer

rule "Decide Platinum Customer"
lock - on - active when
$customer: Customer(purchase >= 10000) then
modify($customer) {

rule "Decide Gold Customer"
lock - on - active when
$customer: Customer(purchase >= 5000 && purchase < 10000)
modify($customer) {

rule "Decide Silver Customer"
lock - on - active when
$customer: Customer(purchase < 5000)
modify($customer) {

In the starting part of this rule file, we define the general things like imports and packages. Then, we create a object of our customer to be used by our rule statements. Then comes the juicy part of rules: a when condition that, if passes, means that the object is given a new state.

Usage of DRl in flow: 

<bpm:rulesrulesDefinition="customerGroup.drl"initialFacts-ref="NoFactsBean"doc:name="BPM Rules"/>

Complete Flow

Here, we use the DRL file that we created and implement the rules in middle of our flow. Now, we are done with the setting of flow the complete droolsdemo.xml. It will looks like this:

<?xml version="1.0" encoding="UTF-8"?>
<mule .>
	<http:listener-config name="HTTP_Listener_Configuration"
host="" port="8081" doc:name="HTTP Listener Configuration" />
	<bpm:drools />
		<spring:bean name="NoFactsBean" class="java.util.ArrayList" />
	<flow name="droolsdemoFlow">
		<http:listener config-ref="HTTP_Listener_Configuration"
path="/brtest" allowedMethods="POST" doc:name="HTTP" />
		<object-to-string-transformer doc:name="Object to String" />
returnClass="com.drools.demo.Customer" doc:name="JSON to Object" />
		<bpm:rules rulesDefinition="customerGroup.drl"
initialFacts-ref="NoFactsBean" doc:name="BPM Rules" />
		<set-payload value="#[payload.object]" doc:name="Set Payload" />
doc:name="Object to JSON" />


We will be sending three different JSON inputs to our flow inbound HTTP endpoint, and hopefully, will get the correct rules fired and proper grade back for our customer.

  • Purchase above $10,000.

  • Purchase above $5,000 and below 10,000.

  • Purchase below $5,000.



We can see for all three cases that the correct rule was applied and a proper grading or customer type was given to our customer object.

Video Tutorial


More details about Drools in Mule is available here.

I hope that you found this blog interesting and that it helps you with your integration of Mule and JBoss Drools. If you liked this blog, please comment and follow this site. If you liked the video of the tutorial, please share and subscribe. It will encourage me to write and create more awesome blogs!

mulesoft ,drools ,mule esb ,integration ,tutorial

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}