Oracle BPEL Process Manager's implementation of BPEL 2.0 does not support simultaneous onMessage branches of a pick activity.

When a process has a pick activity with two onMessage branches as its starting activity (both with initiate set to join in their correlation definitions) and an invoking process that posts the invocations one after the other, it is assumed that both invocations reach the same instance of the invoked process. However, in Oracle BPEL Process Manager's implementation of BPEL 2.0, two instances of the invoked process are created for each invocation.

This is the expected behavior, but it differs from what is described in the BPEL 2.0 specification.

For example, assume you have synchronous BPEL process A, which has a flow activity with two parallel branches:

• Branch one invokes operation processMessage1 on asynchronous BPEL process B.

• Branch two invokes operation processMessage2 on asynchronous BPEL process B. The invocation occurs after a five second wait. BPEL process A then waits on a callback from BPEL process B and returns the output back to the client.

The idea is to create one instance of the invoked process and ensure that the second invocation happens after the first instance is already active and running.

BPEL process B has a pick activity with createInstance set to yes. The pick activity has two onMessage branches within it:

• One branch is for the processMessage1 operation. For this operation, it goes to sleep for about 10 seconds.

• The other branch is for the processMessage2 operation. For this operation, it waits for five seconds.

Both operations have the same input message type and correlation is defined with initiate set to join.The expectation is that the processMessage1 invocation is invoked immediately and the BPEL process B instance is created, which should sleep for ten seconds. After five seconds, the invoking process should then post the processMessage2 invocation to BPEL process B and this invocation should go to the already existing instance instead of creating a new one (since the correlation ID is the same and initiate is set to join).

However, for each invocation, a new instance of BPEL process B is created and the result cannot be predicted.

• If the processMessage2 operation branch finishes first, then the subsequent assign operation fails because the input variable from processMessage1 is assumed to be null (for that instance).

• If the processMessage1 operation branch finishes first, then the process returns callback data with only partial information (does not include the input from processMessage2).

In Oracle BPEL Process Manager's implementation, either one of the two operations (processMessage1 or processMessage2) creates a new instance. This is implemented so that database queries do not need to be made to see if there are already instances created.

The workaround is to create two processes that are initiated by the two different operations.