This article will walk you through the integration of Mulesoft and Drools rule engine.

Drools is an open-source rules engine that can perform some complex rules outside your codebase. In many scenarios, business logic changes more often than the code. So, it makes sense to have frequently changing logic at some external location. This is where Drools comes to the rescue.

Use Case

Let's take an example in which we would want to let only some flows to execute based on some condition in the rules file.

Implementation

We will have to add a BPM namespace and the schema location in our Mule XML file.

Then, we need to add a <bpm:drools/> tag to declare Drools to work with Mule. The rules file ends with a .drl extension and has to be placed in the classpath of your Mule project. We can reference the rules file within our Mule XML file with the syntax <bpm:rules rulesDefinition="myRules.drl"/>.

From the rules file, we can generate Mule messages or modify the properties of various components associated with Mule.

In this example, we will have two logger flows, a main rules logic flow that will decide which flow to run based on conditions in the rules file, a Java class to hold the values of the flow name, and a boolean property to decide whether to run the flow or not.

Our project's main rule execution flow will look like this:

In this flow, we have a Groovy component at the start that will initialize our POJO. It will take the value of next flow name, store it in the POJO's property, and return it. This is how our POJO looks:

public class DecideFlow {

public String flowName;
public boolean allowFlow=false;

public boolean isAllowFlow() {
return allowFlow;
}

public void setAllowFlow(boolean allowFlow) {
this.allowFlow = allowFlow;
}

public String getFlowName() {
return flowName;
}

public void setFlowName(String flowName) {
this.flowName = flowName;
}
}

After this, it goes to BPM rules component. This is where the rule logic will get executed. The code is as follows:

dialect "mvel"

global org.mule.module.bpm.MessageService mule;

import DecideFlow

declare DecideFlow
@role( event )
end

rule "Allow flow to execute"
lock-on-active true
when
$decide : DecideFlow( flowName == "loggerFlow1")
then
modify( $decide ) { setAllowFlow(true) }
end

As you can see above, we have set the dialect to Mule. We have set a global Mule variable and imported out POJO DecideFlow. We have added a rule where flowName is checked with loggerFlow1, and if it matches, then it sets the property of POJO to the true value. This means that regardless of how many flows are there in the project, it only allows loggerFlow1 to run.

We can set the value of flow variable by extracting the value of this property from POJO with the Mule expression language #[payload.object.allowFlow].

We can have a check against this value and decide if the next flow can be executed or not.

Conclusion

This is a simple example onf how to integrate Drools with Mulesoft. We have added all the rules outside the code in a .drl file and we need not change our application code even if the rules change frequently.

This example can be enhanced further to add your complex business rules.