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:

Notice specifically that there is an option called "Triggering Mechanism". To use this as a source of events from SCA, we have to select the "SCA Service" radio button. From there, we will be able to enter a "Service Identifier". The Service Identifier is used to name an SCA Service Interface that will be generated inside IID. Within Process Designer, we are told that the name of the generated interface will be "P1MyStartOneWay". This is made up of a sequence of parts:


In general, the format of the Interface name will be:

<BPD><ServiceIdentifier>OneWay

If we look at the corresponding interface built for us and seen within IID, we find that it looks like:

To be able to use this interface from an SCA module, we need to associate an SCA Import component with the interface and with the process. We achieve this by dragging and dropping the process icon into the Assembly Diagram:

When we do that, we will see the interface available to us:

Completing the wizard will add an SCA import which, when invoked, will send the appropriate and corresponding event to the BPD.

For events that are to be sent to already running process instances, we need to supply a correlation value. This is also known as a "process identifier". It will be a value which, when supplied by an SCA call, will be used by the run-time to select the correct corresponding BPM process instance.

Deploying for testing from ID

To deploy a module for testing, we must define a Process Server definition in the servers tab. Right click in the blank space for a context menu. Select New > Server.

From the wizard, select "IBM Process Server v8.0". I recommend doing this irrespective of whether or not we are connecting to a Process Center or a Process Server. Both have worked just fine for me.

Next we must tell IID where the local installation image of Process Server can be found. We point to the AppServer root directory of the BPM install:

Finally we select which profile we will use and also enter the associated userid and password for connections.

Returning faults from an AIS

In principle a called AIS can fail for a variety of reasons such as a system error (a service it depends upon not being available) or a business error (insufficient funds to perform the debit). In these instances, what we would like to happen is for the AIS to raise a fault and for that fault to be captured by the calling BPMN process. Unfortunately, in 7.5, the InfoCenter documentation explicitly states that interfaces with faults are simply not supported. This appears to raise a dilemma. One possible solution is to add an extra parameter to the interface that will be used to hold a return code from the execution of the AIS. After the BPMN process invokes the AIS, it should then check the value of this response and handle appropriately. This is not as elegant as being able to use the BPMN Intermediate Exception mechanisms but it does appear to be a solution.

In v8 of the product, this issue is claimed resolved.

Manually un-deploying an SCA module

When we deploy a Process App to a Process Server, the SCA module associated with the project starts up. On occasion, we may wish to stop or un-deploy such a module. This can be achieved through the WAS admin console in the Applications > SCA modules area:

No Comments
Back to top