How to Route a Message to a New or Existing Instance when Using Correlation Sets

For a BPEL process using correlation sets, the correct routing is performed. The message can be either of the following:

An invoke message creating a new instance
A callback message continuing an existing instance

Figure 9-19 shows entry and midprocess receive activities using the same operation (process).

Figure 9-19 Routing a New Message to a New or Existing Instance

Description of "Figure 9-19 Routing a New Message to a New or Existing Instance"

The following provides an example of the entry and midprocess receive activities using the same operation (process).

<receive name="receiveInput" partnerLink="client" portType="client:BPELProcess1"
 operation="process" variable="inputVariable" createInstance="yes">
 <correlations>
  <correlation initiate="yes" set="CorrelationSet_1"/>
 </correlations>
</receive>

<!-- some business logic -->

<while name="While_1" condition=*loop for 3 iterations*>
 <sequence name="Sequence_1">
  <receive name="Continue_Receive" partnerLink="client"
 portType="client:BPELProcess1" operation="process" variable="inputVariable"
 createInstance="no">
   <correlations>
    <correlation initiate="no" set="CorrelationSet_1"/>
   </correlations>
  </receive>

<!-- some business logic -->

 </sequence>
</while>

In the initial scenario in the preceding example, the following actions occur in BPEL process P1:

A partner provides four messages (message 1, message 2, message 3, and message 4) for the same partner (correlation ID 101).
Message 1 creates a new instance of BPEL process P1. This message is marked as an invoke message.
Messages 2, 3, and 4 are received using the Continue_Receive activity. These messages are marked as callback messages.
The instance closes because three iterations of the while loop are expected.

Assume now that additional messages are routed, which can potentially cause race conditions to occur. Table 9-13 provides details.

Table 9-13 Message Delivery Scenarios

Scenario Description Marked as Invoke Message Marked as Callback Message

Scenario	Description	Marked as Invoke Message	Marked as Callback Message
1	Assume the partner now provides message 5 for the same correlation ID (`101`). Message 5 creates a new instance of BPEL process P1 and waits on the `Continue_Receive` activity inside the `while` loop for three more messages (6, 7, and 8).	Message 1 Message 5	Message 2 Message 3 Message 4 Message 6 Message 7 Message 8
2	If messages 4 and 5 are received within a small time window, it is possible that message 4 is closing the instance BPEL process P1 and message 5 is routed as a callback to that instance. This scenario can cause a race condition. For example: When message 6 arrives, it is routed to the entry receive activity of the new instance. Messages 7 and 8 are routed to the `Continue_Receive` activity. Message 5 is routed to the `Continue_Receive` activity only by the recovery part of the BPEL process service engine. This is because it initially was routed to a closed instance and could not be handled.	Message 1 Message 6	Message 2 Message 3 Message 4 Message 5 Message 7 Message 8
3	This is similar to scenario 2. However, in this case, messages 7, 8, and 9 are not received. For example: Message 5 becomes an unhandled callback message waiting for a subscriber. BPEL process service engine recovery tries to process message 5 and fails because there is no subscriber available. There are several options for message recovery. Limit recovery of callback messages with the System MBean Browser property maxRecoverAttempt in Oracle Enterprise Manager Fusion Middleware Control. This count specifies the number of attempts made by automatic recovery to recover an invoke/callback message. Once the number of recover attempts exceeds this count, the state of the message is changed to exhausted. For more information, see Section "Configuring Automatic Recovery Attempts for Invoke and Callback Messages" in Administering Oracle SOA Suite and Oracle Business Process Management Suite. Write a custom SQL script to check that the `criteriaCallback` has `state` set to `0`. The correlation value for this callback exists in `CORRELATION_GROUP` in a closed state (`state` = `0`). This indicates that the callback message is marked for a closed aggregation instance. You can cancel/purge these instances based on business logic. Note: BPEL is designed as a conversation-based system. At any point in which unsolicited messages are not being handled, the application is always aware of the messages coming as part of correlation aggregation and chooses to subscribe and process or ignore the message as required by business needs.	Message 1 Message 6	Message 2 Message 3 Message 4 Message 5

Assume the partner now provides message 5 for the same correlation ID (101). Message 5 creates a new instance of BPEL process P1 and waits on the Continue_Receive activity inside the while loop for three more messages (6, 7, and 8).

Message 1
Message 5

Message 2
Message 3
Message 4
Message 6
Message 7
Message 8

If messages 4 and 5 are received within a small time window, it is possible that message 4 is closing the instance BPEL process P1 and message 5 is routed as a callback to that instance. This scenario can cause a race condition. For example:

When message 6 arrives, it is routed to the entry receive activity of the new instance.
Messages 7 and 8 are routed to the Continue_Receive activity.
Message 5 is routed to the Continue_Receive activity only by the recovery part of the BPEL process service engine. This is because it initially was routed to a closed instance and could not be handled.

Message 1
Message 6

Message 2
Message 3
Message 4
Message 5
Message 7
Message 8

This is similar to scenario 2. However, in this case, messages 7, 8, and 9 are not received. For example:

Message 5 becomes an unhandled callback message waiting for a subscriber.
BPEL process service engine recovery tries to process message 5 and fails because there is no subscriber available.

There are several options for message recovery.

Limit recovery of callback messages with the System MBean Browser property maxRecoverAttempt in Oracle Enterprise Manager Fusion Middleware Control. This count specifies the number of attempts made by automatic recovery to recover an invoke/callback message. Once the number of recover attempts exceeds this count, the state of the message is changed to exhausted. For more information, see Section "Configuring Automatic Recovery Attempts for Invoke and Callback Messages" in Administering Oracle SOA Suite and Oracle Business Process Management Suite.
Write a custom SQL script to check that the criteriaCallback has state set to 0. The correlation value for this callback exists in CORRELATION_GROUP in a closed state (state = 0). This indicates that the callback message is marked for a closed aggregation instance. You can cancel/purge these instances based on business logic.

Note: BPEL is designed as a conversation-based system. At any point in which unsolicited messages are not being handled, the application is always aware of the messages coming as part of correlation aggregation and chooses to subscribe and process or ignore the message as required by business needs.

Message 1
Message 6

Message 2
Message 3
Message 4
Message 5