IBM BPM as a source of events

IBM BPM is IBM’s Business Process Management product that can be used to build and execute business processes. Within this environment we can describe the sequence of steps that are executed for each instance of the process. As we navigate from step to step, we could imagine the emission of events from BPM for examination.

There are as many different uses of business processes as anyone could possible imagine. We will look at some simple ones.

Imagine a shopping process that is started when a consumer places items in a web-based shopping cart. Upon submission, the process handles the order including warehousing (to ensure that the items requested are actually in stock), billing and shipping.

There are a couple of ways in which IBM BPM can emit events for processing by ODM Advanced – Decision Server Insights (DSI). The first we will look at is the “Performance Data Warehouse”.

Emit events from BPM Performance Data Warehouse

The BPM Performance Data Warehouse (PDW) is a database with tables that are written to during the normal operation. The data written can be thought of as a history of the BPM processes operations. This includes time stamps, the identity of which steps were executed and who performed any particular task.

What we would like to model an event or series of events after the data found here. When new records are written to the database by the operation of IBM BPM, we could execute a database trigger that would send the events onwards to DSI for consumption.

Emit events from BPM Services within the process flow

Within a BPM solution we can define BPD processes that can call BPM services. These services can be coded in Java. Within Java we can emit events to a DSI environment through REST and JMS. Therefore, we can emit events from BPM destined for DSI.

An event arriving at DSI will consist of an event type as well as an event payload. In BPM data is represented as Business Objects. A Business Object can be converted to an XML representation using its toXMLString() method. For example, a Business Object defined as:

will be serialized to XML as a document that looks like:

<variable type="BO1">
  <a type="String"><![CDATA[A Value]]></a>
  <b type="Integer"><![CDATA[123]]></b>
  <c type="Date"><![CDATA[2015/02/02 18:55:19.37 CST]]></c>
  <d type="Boolean"><![CDATA[false]]></d>

Now let us contrast this with how we might model a DSI event. Imagine we created the following definition in a BMD:

a BPMBO is a business event.
a BPMBO has an 'a' (text).
a BPMBO has a 'b' (integer).
a BPMBO has a 'c' (date & time).
a BPMBO can be 'd'.

The corresponding XML for an event would be:

<?xml version="1.0" encoding="UTF-8"?>
<m:BPMBO xmlns:m=""
	xmlns:p="" xmlns:p1=""
	xmlns:tns="" xmlns:xsi=""
namespace1/model.xsd ">

Obviously the XML exposed by BPM is not the same XML expected by DSI so how can we handle this? Fortunately, DSI supports XSLT transformation. If we can build an XSLT stylesheet, we can map from the BPM generated XML to the expected DSI XML. The XSLT stylesheet mechanisms for the connectivity definition can be leverage for this.

An example piece of Java code for an implementation of a Java service might be:

package kolban;


public class DSISendEvent {
	public static void sendEvent(String urlStr, String message) {
		try {
			URL url = new URL(urlStr);
			HttpURLConnection conn = (HttpURLConnection) url.openConnection();
			conn.setRequestProperty("Content-Type", "application/xml");
			OutputStream out = conn.getOutputStream();
			Writer writer = new OutputStreamWriter(out, "UTF-8");
			if (conn.getResponseCode() != 200) {
				throw new IOException(conn.getResponseMessage());
		} catch (Exception e) {
	} // End of sendEvent
} // End of class
// End of file

This Java code can then be packaged in a Jar and the Jar added to a BPM Process App as a server managed file. Next we can define a BPM integration service (in this case called BPM Send Event) which contains a Java component:


The configuration of the Java component can then point to the Java code:


The signature if the Integration service can be:


Where the url variable is the URL of the endpoint of the DSI api call and the message is an XML document.
Now, from within a BPM BPD, we can invoke the Integration Service as a step in the process:


where the parameters to the integration service could be:


It is important to note that the Java coding and the creation of the Integration Service are a one-time deal which can be easily imported as-is from the IBM samples. A designer of a BPM solution can simply “use” the BPM Send Event service without ever having to know how it works.

The XSLT mapping still has to be performed by hand to map the fields in the BPM business object to the fields in the expected incoming event, but that is not a complex procedure. If demand became high enough, it is likely that task could even be automated with some code that was given both a BPM business object definition and a DSI event definition … but we aren’t going to go any further down that path here.

IBM BPM as a destination for events from ODM Advanced – Decision Server Insights

When DSI publishes events, what does it mean to direct them to IBM BPM? From a BPM perspective, there are two meaningful possibilities:

  • Start a new instance of a process
  • Signal an existing process

BPM exposes the ability to perform both of these tasks as REST exposed APIs. To start a new process instance we have:

For sending messages to existing processes :

BPM requires that REST requests be authenticated when they arrive. As such we must set up outbound HTTP request user/password.

Starting a BPM Process from an emitted event – REST

If we look carefully at the REST API used to start a process instance, we find that it consists of a few parts that can be quite easily scripted or coded. However, we will also find that it does not lend itself to a direct call from the HTTP outbound connectors of DSI. This appears to pose us a problem. How then can we submit a request to BPM to start a new process? One possible solution is to use the MDB pattern. In this pattern, we have DSI publish a message to a JMS queue and have an MDB process the resulting message. The MDB will receive the content we need to send and then make the appropriate REST calls to BPM to get the work done.


The design of the MDB is the interesting part. It will receive a JMS TextMessage that will contain the XML representation of the emitted event. BPM can receive either XML or JSON encoded data. My preference would be to pass JSON to BPM which will mean that we will have to convert the XML to a JSON string.

Starting a BPM Process from an emitted event – SCA Module

IBM BPM Advanced has extremely powerful integration capabilities provided by the Service Component Architecture (SCA). Included in this capability is the ability for BPM to listen for incoming messages on a variety of inbound transports including HTTP, JMS, MQ, files and many others. When a message arrives, the message can be transformed via a rich mediation transformation engine and then emitted onwards. The destination of the message can be a variety of targets including the BPM process runtime. Putting this another way, BPM Advanced can receive messages over a variety of protocols, transform the content of those messages and then use the arrival of the message plus its content to start a BPM process.

This sounds very much like what we need in order to start a process instance from a DSI emitted event.

Let us now look at a schematic of how this would work. We start be realizing that an SCA module can be deployed as part of a BPM process app. Here is an example:


This schematic illustrates an SCA module that listens on an incoming HTTP transport and, when a message arrives, its content is transformed and then used as the input to a new instance of a BPD process.

This is helpful, because when an event is emitted from DSI, it can be emitted over an HTTP transport. If the endpoint of the DSI HTTP connection is mapped to the input of the SCA module’s HTTP SCA Export, then when an event is emitted by DSI, an instance of this SCA module will be fired up and given the event XML document as input.

Now, how can the event payload of the emitted event from DSI can be used as input to the BPM process? This is actually extremely simple and elegant. When we model an event in DSI, we can then export the model of that event as an XML Schema Definition (XSD). That schema can then be imported into BPM Advanced and used as the model for data arriving at the SCA module. Since we will already have the modeled data that is expected to be supplied as input into the BPM process, the mediation transformation can be used to map the DSI event data to the BPM process input data. This is achieved using graphical modelers.


Because we are doing the transformation at “receiver makes good”, there is no need to use XSLT transformation at the DSI side of the house.

Join The Discussion

Your email address will not be published. Required fields are marked *