BPM Module Reference

BPM stands for Business Process Management and simplistically can be thought of as a system which automates business processes. Typically a BPM system has a graphical interface which allows you to model your business processes visually so that a business analyst or other non-programmer can easily understand them and verify that they indeed reflect the reality of your business.

Mule’s support for BPM allows you to send/receive messages to/from a running process. A message from Mule can start or advance a process, the message can be stored as a process variable, and a running process can send messages to any endpoint in your Mule application.

Important: The jBPM module was removed from Mule 3.8.0 and later. If you need to use BPMS or jBPM, use Mule 3.7 or earlier.

Considerations

If the business logic for your Mule application is relatively simple, does not change very often, and is mostly stateless, you are probably best off implementing it using Mule’s orchestration functionality such as flows, routers, and custom components.

However, you might consider using BPM to model your business logic in the following cases:

If the execution in your flow has many discrete steps and/or multiple paths based on decision criteria, modeling it as a process may help better visualize it.
If your business logic is in constant flux, BPM might be a good way to decouple the logic from your integration.
If your business logic or processes need to be reviewed or updated by non-programmers, BPM makes that possible.
If a flow does not go from start to finish within a few minutes, it’s probably a good candidate for BPM because intermediate process state is persisted so it does not need to be held in memory.
If your integration requires human input, BPM lets you add a human step to your process via task management and a web app.
If your application needs a step-by-step audit trail, BPM might be a good option because process history is kept in a database.

It is likely that a BPM engine would add some performance overhead. If high-performance is critical to your application, you should consider using Mule’s orchestration instead to model your process.

Namespace and Syntax

XML namespace:

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

XML Schema location:

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

Syntax:

<bpm:process processName="myProcess" processDefinition="myProcess.xml" />

Features

Incoming Mule events can launch new processes, advance, or terminate running processes.
A running process can send synchronous or asynchronous messages to any Mule endpoint.
Synchronous responses from Mule are automatically fed back into the running process and can be stored into process variables.
Mule can interact with different running processes in parallel.

Usage

Import the XML schema for this 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"

Then you can use the <bpm:process> element as follows, generally preceded by an inbound endpoint. See the example configuration, below.

<bpm:process processName="myProcess" processDefinition="myProcess.xml" />

At a minimum, when triggering a BPM process, you must specify the processName and processDefinition attributes in the <bpm:process> element.
Incoming Mule messages and properties can be stored as process variables, and process variables can be sent as Mule messages.

Configuration Examples

Example configuration

<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/current/mule-bpm.xsd" ...>

  <spring:bean id="testBpms" class="com.foo.FooBPMS" /> (3)

  <flow name="MessagesToProcess">
      <jms:inbound-endpoint queue="queueA" /> (1)
      <bpm:process processName="myProcess" processDefinition="myProcess.xml" /> (2)
  </flow>

  <flow name="SomeSynchronousService">
      <inbound-endpoint ref="callService" exchange-pattern="REQUEST-RESPONSE" /> (4)
      <component class="com.foo.SomeService" /> (5)
  </flow>
</mule>

1	JMS queue: In this configuration, an inbound message on the JMS queue triggers the process defined by the file "myProcess.xml".
2	Process definition: The process that the inbound message on the JMS queue triggers.
3	Store process variable: The inbound message is stored as a process variable.
4	Exchange pattern: Since there is only one implementation in the application, no explicit reference is required. A step in the process definition might send a message to the endpoint `callService`.
5	Component class: The step in #4 sends a message to the endpoint `callService`, in which case the synchronous response from `com.foo.SomeService` could be also be stored as a process variable. Note that since this logic occurs in the process definition, it is not visible in the Mule configuration.

Multiple BPM Systems

<spring:bean id="bpms1" class="com.foo.FooBPMS" />

<spring:bean id="bpms2" class="com.bar.BarBPMS" />

<flow name="ProcessFlow1">
    ...cut...
    <bpm:process processName="process1" processDefinition="process1.def"
      bpms-ref="bpms1" /> (1)
</flow>

<flow name="ProcessFlow2">
    ...cut...
    <bpm:process processName="process2" processDefinition="process2.cfg"
      bpms-ref="bpms2" /> (2)
</flow>

1	This configuration snippet illustrates how to use the `bpms-ref` attribute in #1 and #2 to disambiguate between more than one BPM systems. If there is only one BPMS available, this attribute is unnecessary.
2	The other disambiguated BPM.

Notes

This module is for BPM engines that provide a Java API. If you need to integrate with a BPEL engine, you can do so using standard web services.
The recommended way to interact with a BPM system is via the <bpm:process> component and message processor.