This topic applies only to the IBM Business Process Manager Advanced configuration.

Using Service Component Architecture to interact with processes

There are several ways to start and interact with business process definition (BPD) instances using Service Component Architecture (SCA). You can use receiving message events to create or interact with BPD instances.

You can also use SCA to create a BPD instance without the use of a receiving message event. In that scenario, the inputs of the BPD and optionally its outputs define the service interface for the SCA interaction.

To interact with receiving message events, you can use SCA as the triggering mechanism as an alternative to using undercover agents (UCA). A receiving message event can be a start message event, intermediate message event, boundary message event, or the start event of an event subprocess.

The use of SCA as the triggering mechanism makes it possible to use instance-based correlation that always delivers the message to exactly one event of one instance. By contrast, correlation that is supported by undercover agent invocations permits multiple instances and events (of the same or different models) to receive the same message.

Supported interaction patterns that use receiving message events

You can use SCA messages to invoke the following BPD event types. These interactions are one-way interactions.

Message Start Event: The start event causes a new instance of the BPD to be created. If your BPD includes more than one start event, each one should use a different SCA service identifier. Otherwise, if multiple start events specify the same SCA service identifier, the start event that receives the start message is selected arbitrarily.
Start Event of a Message Event Subprocess: The Start Event of a Message Event Subprocess requires correlation. A message that invokes a message event subprocess must be correlated with the BPD instance that then invokes the event subprocess. Optionally, this event type can be configured to be repeatable or to interrupt the parent process instance.
Intermediate Message Event: An intermediate message event requires correlation to ensure that the message triggers the intermediate message event that belongs to the correct BPD instance.
Boundary Message Event: A boundary message event is an intermediate message event that is attached to an activity. A boundary message event requires correlation to ensure that the message triggers the boundary message event that belongs to the correct BPD instance. Optionally, this event type can be configured to be repeatable or to interrupt the activity that the event is attached to.

Supported interaction patterns that use input and output variables

The input and output variables of the BPD define the parameters of the SCA request message and SCA response message. They are used to store the parameter data of the request message and the response message that are exchanged by means of SCA. There are two interaction patterns:

One-way interface: You create a BPD instance using the one-way interface of the BPD. The message parameters are automatically assigned to the input variables when the BPD instance receives the SCA message.
Request-response interface: You create a BPD instance and upon the completion of the BPD, you receive a response message that uses the request/response interface of the BPD. The request message parameters are automatically assigned to the input variables when the BPD instance receives the SCA request message. The SCA response message is constructed from the output variables when the BPD instance ends.

The one-way interface and the two-way interface are derived from the input and output variables. Both interfaces are available in IBM® Integration Designer for use as an SCA module.

Instance-based correlation

If a request message must be received by an existing instance of a BPD, you must specify a correlation variable to identify the intended instance that receives the message.

SCA message correlation requires that at least one of the BPD's variables is marked as being a process instance identifier. The correlation variable can be written to only once. The value that is assigned to the correlation variable must uniquely identify the instance. Normally, business data is assigned to a process instance identifier variable. For example, the correlation variable might be assigned an employee number from the start message. All messages that are intended for the same instance must include the same value for the correlation variable to identify the appropriate process instance. The value that is used to identify a process instance cannot be reused to identify a new instance until after the first instance is in the completed or terminated state, or the instance is deleted.

Important: You must ensure that the process instance identifier variable is initialized before any message is sent for the instance. Because the correlation matching is only performed when the message arrives, if a message arrives before the process instance identifier variable is initialized, it can never match with a process instance, and can never trigger a receiving message event.

If a message is posted before the a suitable message receive event is in a waiting state, the message is stored. The message will be received by the first matching message receive event that goes into the waiting state.

Note: The pattern of starting multiple parallel subprocess instances which should receive different SCA messages is not supported. The reason is that when a variable that is marked as a process instance identifier is set in a subprocess, this variable actually identifies the overall parent process instance and not the specific subprocess instance. By setting the same variable in multiple instances of the same subprocess, multiple process instance identifiers with the same name but different values are created. However, all of them identify the same parent process instance. Therefore, when an SCA message is sent that is intended for one of the parallel subprocess instances, all of the subprocess instances can potentially receive it, as the instance-based correlation identifies the same parent process instance as the target. In this case, one of the subprocesses is chosen arbitrarily.

To avoid the arbitrary selection, when you model a process in IBM Process Designer that invokes a subprocess by using a Linked Process activity, mark the Linked Process activity as Run Sequential instead of Run in Parallel.

Defining a service that can trigger different events in a BPD

In general, when receiving message events are used with SCA, the corresponding service interfaces of the BPD are derived from the message event's service identifier and message object type.

You can specify that the BPD exposes only one service, which is implemented by different receiving message events of the BPD. To do so, specify the same service identifier and message object type for different message events in the BPD. When a message is received, one of the receiving message events will process it. Which event receives the message depends on whether a correlating process instance is found, and if so, which event is active, or reached first.

If a process instance matches the instance identifier value in the message, then the following rules are applied:
- If the instance has exactly one matching event (intermediate, boundary, or a start event for an event subprocess) that is in the waiting state, the matching event receives the message.
- If the instance has multiple matching events that are in the waiting state, one of them is selected arbitrarily to receive the message.
- If the instance does not have any matching event in the waiting state, the message is stored until an event that can receive the message becomes active.
If no process instance matches the instance identifier value in the message and there is a start process message event that matches the message type, a new instance of the BPD is created, and the start message event receives the message.

Warning: It is possible to define unintentionally the same service interface for multiple events. For example, if different events have identical names (which is shown as an error on the General tab), or if different service identifiers map onto identical NMToken strings, then different events share the same service interface. If this naming conflict happens, you can break the naming conflict by renaming the duplicate event names and then restoring the default service identifier name.

Rules for instance migration

To allow instance migration of BPDs that contain SCA message events and variables that are marked as process instance identifiers, you must conform to the rules for what cannot be changed or deleted when you create a new version of a BPD that is already deployed. The rules are described in Strategies for migrating instances.

Task overview

To use SCA to interact with a BPD, you must complete the following actions:

Using Process Designer:
You can either use the implicitly provided services of the BPD, or use the services that are provided for a receiving message event in which SCA is specified as the triggering mechanism. For the former you do not have to do anything, for the latter you must specify the corresponding receiving message events.
1. If SCA messages interact with existing BPD instances, use instance-based correlation for the message event subprocess, intermediate receiving message events, or boundary message events. For that, you must mark one or more of the process variables as process instance identifiers. See Declaring variables for a BPD or a service in Process Designer.
2. Ensure that the process variable that identifies a BPD instance is assigned a suitable value. The value must be assigned before any SCA message can arrive for the instance.
3. Optional: Add a start message event to your process. See Using start message events.
4. If you want message event subprocesses or receiving message events in a process to be able to receive SCA messages:
  1. Add intermediate receiving message events and boundary message events as necessary. See Using intermediate and boundary message events to receive messages.
  2. Add a message event subprocess, with a corresponding start message event where required. See Using start message events.
  3. For each receiving message event, as a part of the data mapping, select the variable that uniquely identifies each process instance. See Mapping input and output data for an activity or step.
Switch to using IBM Integration Designer, and complete the following actions:
1. Drag the BPD onto the design canvas, and select which interfaces to include in the SCA import. See Creating an import to start a business process definition.
2. In the assembly editor, you can use the SCA import to invoke and communicate with a BPD instance using SCA messages.