Inter-operating between a BPMN process and an SCA module

When we think of a BPMN process contained in a BPD which is itself contained within a Process Application, we realize that it can "call out" to a variety of back-end systems using its supplied Java implemented connectors that are found in BPM Services supplied by IBM. However, these are secondary capabilities in the overall story. The more robust and powerful integration engine is contained within an SCA module. As such, we want to be able to define a step within a BPD as being implemented by an SCA module.

Let us look at a simple example.

Here is a BPD which has a step called Billing. We wish this to be implemented by a call to an SCA module. In PD, we create a new artifact of the type called the Advanced Integration Service (AIS).

A wizard is started which prompts us for a name for this new component:

Once the name has been entered, we can then supply additional details for this AIS instance:

Primarily, these are its expected input and output parameters.

Once the AIS panel has been completed, we find we have a new artifact available to us in the Process Application library under the Implementation category:

In the BPD, we can now associate the Billing AIS with the BPD activity we also called Billing:

With all of these PD changes made and saved back to Process Center, we can now open an ID session.

In ID, we see the Billing AIS that was defined in PD as being un-implemented.

We can now right-click on this and select "Implement":

A wizard appears asking us for what we would like the base implementation to contain. The choices available to us include:


Selecting "Empty implementation" is my recommended selection. This is the most flexible and allows us to take control from the outset for what we want to achieve.

At the conclusion of these steps, an SCA interface is created for the Billing service:

and the Assembly Diagram is updated with an SCA Export for the Billing function. Once the implementation in the SCA Assembly has been built, we can publish the solution back to Process Center which will now include the SCA implementation. If we now run the Process App, we will see control being passed to the SCA module when the billing component is reached. This simple example has achieved a top-down implementation of an AIS. We say top-down because the nature of the service was described in the high-level BPMN diagram in the BPD while its concrete (lower-level) implementation was handled in the ID. Schematically, the following shows what we have achieved:

A bottom-up solution can also be achieved by creating an interface and exposing that interface in an Assembly Diagram with an Export with SCA bindings. It appears that the name of the AIS created has the same name as the Interface. This doesn't feel right and is being investigated further.

When ID is started for the first time, we are prompted to define a connection to Process Center:

To see the currently selected Process Center URL open the ID preferences and navigate to Business Integration > Process Center. The URL and userid/password to access Process Center can be found there.

See also:


Interface Types Exchange

When we define a new AIS in PD what we are in fact doing is describing a new named interface that can be called from BPM that is implemented by SCA. The input, output and error definitions defined in PD show up as a new interface in ID. However, some thought is required on this.


In addition, an AIS that only has input parameters is mapped to a two-way operation in ID. For example:

If a one-way operation is required, ID provides the capability to re-factor the interface to be one-way. Clicking on the operation and looking at the Details tab, we can choose the operation type:

Data Types Exchange

In PD, data types are defined as Complex Data Types. For example.

When an ID Workspace import is created, the corresponding Business Object for these data types is created.

Note that the name of the Business Object is the same. The Namespace on the business object is, by default, the same as the Acronym value for the Process App that defines the data type.

BPDs exposed to an AIS

Each BPD process in a Process App appears in the Processes section of the Business Integration view of ID.

These processes can be dragged to an Assembly Diagram which will generate an SCA Import allowing the process to be invoked. For each process, two interfaces are created. One for a request/response call and one for a one-way call. When the process is dropped onto the assembly diagram, a dialog appears asking us which interface type should be used:

Once added to the diagram, the import looks as follows:

Invoking this import will result in an instance of the BPD being created and started. Since this otherwise behaves like a normal SCA import, we have all the power that SCA provides in terms of wiring and usage.

It should be noted that a BPD exposed to be called from an SCA assembly diagram is going to be invoked asynchronously. What this means is that any caller of this SCA Import that expects the provider to be synchronous will fail. This shows us (for example) if one adds an SCA Export with Web Services bindings (over HTTP) and wires that into the BPD SCA Import. A Web Service Export will always be invoked synchronously and will not be allowed to connect to an asynchronous provider.

BPD Waiting Events invoked from SCA

From IBM BPM 8.5.5 an additional capability was introduced. When we think about a BPD definition, we see that it can be started or woken up (after it falls asleep) by the arrival of an incoming event. If we look at the following image, we see three distinct places where externally originated events (to the BPD) can cause an effect on that BPD instance:

We see that a new instance of the process can be started, we see that an event arriving while Task A is in existence can be handled and we see that once Task A completes, the process will wait for a new incoming message before completing.

For a BPD that is already running (this means that one which is NOT started by the arrival of a new message) then we need a correlation value to be associated with the incoming event so that the correct instance of the BPD will be woken.

Prior to v8.5.5, incoming messages were exclusively only available via UCAs. With 8.5.5 and beyond, SCA modules can use SCA Imports that when invoked result in a message event arriving at a process.

To understand this better, let us look in more detail at an Event Start activity. If we examine its Implementation section, we find the following: