xmlns:bpm "http://www.mulesoft.org/schema/mule/bpm"
Drools Module Reference
Drools is a best-of-breed open source Rules Engine which also offers Complex Event Processing.
This module provides integration between Mule and a Java Rules Engine, namely Drools.
Business Rules
In many applications, the business logic changes more frequently than the rest of the application code. A Rules Engine executes business rules that have been externalized from the rest of the application. This externalization of business logic makes the application more adaptable to change, and may even allow non-technical personnel to update the business logic without the intervention of an developer.
Rules engines introduce a lot of terminology which can be confusing for users not familiar with the Business Rules "world":
Facts are stored in a working memory (something like an in-memory database). A fact is a piece of data, such as "age = 40", or in an object-oriented rules engine, it may be a Java object with properties.
Rules are defined in a knowledge base. A rule consists of conditions (which typically depend on facts in the working memory) and actions which are executed when the conditions are true (similar to an "if-then" statement). The action executed by a rule may change facts in the working memory which then cause other rules to fire.
Considerations
If the business logic for your Mule application is relatively simple, you are probably best off implementing it using Mule’s orchestration functionality such as flows, routers, and custom components.
However, you might consider using Rules to model your business logic in the following cases:
-
The business logic is overly complex or time-consuming when defined procedurally
-
The business logic contains a lot of if-then-else statements
-
The business logic changes often
-
The business logic needs to be maintained by people who don’t (or shouldn’t) have access to the application itself (to recompile/redeploy it)
You also might consider modeling your business logic as a process, depending on the nature of the algorithms involved.
Namespace and Syntax
XML namespace:
XML Schema location:
http://www.mulesoft.org/schema/mule/bpm/current/mule-bpm.xsd
Syntax:
<bpm:drools />
<bpm:rules rulesDefinition="myRules.drl" />
Features
-
Incoming Mule messages are asserted as new facts in Drools' working memory.
-
Mule messages can be generated as a result of Rules firing.
-
In CEP mode, Mule messages can be received as an event stream and used to trigger complex operations such as temporal reasoning and pattern detection.
Starting in Mule 3.9.1, Drools libraries are no longer bundled with the Mule distribution. Drools 5.0 is the latest supported version. To add the Drools module along with its libraries to 3.9.1 or later, follow this Knowledge Base article. Notice that this will not be supported in CH because of security concerns in drools distributions. |
Usage
Import the XML schema for the general BPM module as follows:
xmlns:bpm="http://www.mulesoft.org/schema/mule/bpm"
xsi:schemaLocation="http://www.mulesoft.org/schema/mule/bpm http://www.mulesoft.org/schema/mule/bpm/current/mule-bpm.xsd"
Since they are closely related, the BPM namespace/schema is shared between the Drools module and the BPM module. |
Declare Drools as the Rules Engine to use with Mule:
<bpm:drools />
Just as with BPM, Rules integration in Mule is based on a pluggable interface such that any Java Rules Engine which implements this interface could be used instead of Drools. However, the only such implementation currently available is Drools. |
Add Rules to your Mule application, generally (though not necessarily) preceded by an inbound-endpoint:
<bpm:rules rulesDefinition="myRules.drl" />
Create a Rules Definition file and (optionally) generate Mule messages from it:
global org.mule.module.bpm.MessageService mule;
...cut...
rule "sudden drop"
when
$st : StockTick( $dt : delta >= $threshold )
then
mule.generateMessage("alerts", "Some alert message", null, MessageExchangePattern.ONE_WAY);
end
Configuration Examples
Basic configuration |
---|
|
This is a simple config where incoming JMS messages on a queue (❶) are inserted as facts into the Drools working memory (❷).
CEP configuration |
---|
|
Here a Collection of initial facts (❶) is inserted into the working memory at startup. The Collection is provided by the factory-method of a Spring bean (❷). Drools is set to CEP mode (❸), which means that messages will be inserted as an Event Stream rather than Facts. The Entry Point for the Event Stream is also specified (❹).
Configuration Reference
Rules
A service backed by a rules engine such as Drools.
Name | Type | Required | Default | Description |
---|---|---|---|---|
rulesEngine-ref |
string |
no |
A reference to the underlying Rules Engine. |
|
rulesDefinition |
string |
yes |
The resource containing the rules definition. This will be used to deploy the ruleset to the Rules Engine. |
|
initialFacts-ref |
string |
no |
A reference to a collection of initial facts to be asserted at startup. |
|
cepMode |
boolean |
no |
Are we using the knowledge base for CEP (Complex Event Processing)? (default = false) |
|
entryPoint |
string |
no |
Entry point for event stream (used by CEP). |
No Child Elements of <rules…>
XML Schema
Complete schema reference documentation.
Maven
If you are using Maven to build your application, use the following groupId/artifactIds to include the necessary modules:
<dependency>
<groupId>org.mule.modules</groupId>
<artifactId>mule-module-bpm</artifactId>
</dependency>
<dependency>
<groupId>org.mule.modules</groupId>
<artifactId>mule-module-drools</artifactId>
</dependency>