Nav
You are viewing an older version of this section. Click here to navigate to the latest version.

Drools Module Reference

Drools is a best-of-breed open source http://www.jboss.org/drools/drools-expert.html[Rules Engine] which also offers http://www.jboss.org/drools/drools-fusion.html[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, e.g. "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.

Complex Event Processing

Complex Event Processing (CEP) refers to an application where a stream or cloud of multiple events is analyzed by business rules in order to detect complex patterns or relationships within those events, generally in real-time.

Namespace and Syntax

XML namespace:


         
      
1
xmlns:bpm "http://www.mulesoft.org/schema/mule/bpm"

XML Schema location:


         
      
1
http://www.mulesoft.org/schema/mule/bpm/3.4/mule-bpm.xsd

Syntax:


         
      
1
2
3
<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.

The Drools libraries are bundled with the Mule distribution. Drools 5.0 is the latest supported version.

Usage

Import the XML schema for the general BPM module as follows:

Import schema


         
      
1
2
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/3.4/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:

Declare Drools as the Rules Engine


         
      
1
<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:

Rules element


         
      
1
<bpm:rules rulesDefinition="myRules.drl" />

Create a Rules Definition file and (optionally) generate Mule messages from it:

Rules Definition file


         
      
1
2
3
4
5
6
7
8
9
10
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


         
      
1
2
3
4
5
6
7
8
9
10
11
<mule ... 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/3.4/mule-bpm.xsd" ...>
 
    <bpm:drools />
 
    <flow name="RulesInput">
        <jms:inbound-endpoint queue="input.queue" /> ❶
        <bpm:rules rulesDefinition="myRules.drl" /> ❷
    </flow>
</mule>

This is a simple config where incoming JMS messages on a queue (❶) are inserted as facts into the Drools working memory (❷).

CEP configuration


         
      
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
<mule ... 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/3.4/mule-bpm.xsd" ...>
 
    <spring:bean name="companies" class="org.mule.example.cep.CompanyRegistry" factory-method="getCompanies" /> ❷
 
    <bpm:drools />
 
    <flow name="processStockTicks">
        <inbound-endpoint ref="stockTick" />
        <bpm:rules rulesDefinition="broker.drl"
         cepMode="true"  entryPoint="StockTick stream" 
         initialFacts-ref="companies"  />
    </flow>
</mule>

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 are 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.

Attributes of <rules…​>

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).

Child Elements of <rules…​>

Name Cardinality Description

XML Schema

Complete http://www.mulesoft.org/docs/site/current3/schemadocs/namespaces/http_www_mulesoft_org_schema_mule_bpm/namespace-overview.html[schema reference documentation].

Maven

If you are using Maven to build your application, use the following groupId/artifactIds to include the necessary modules:


         
      
1
2
3
4
5
6
7
8
<dependency>
  <groupId>org.mule.modules</groupId>
  <artifactId>mule-module-bpm</artifactId>
</dependency>
<dependency>
  <groupId>org.mule.modules</groupId>
  <artifactId>mule-module-drools</artifactId>
</dependency>