Do not use the same conversion ID for different revisions of a SOA composite application. When correlation sets are used in a BPEL process, you have explicit control over the conversation ID value. Oracle SOA Suite does not interfere or add restrictions on conversation ID value generation. This situation means that even though it appears that Oracle SOA Suite is generating the same conversation ID for different revisions, you actually control this behavior. Oracle SOA Suite does not restrict you from using the same conversation ID for different instances of different revisions.

If you do not use correlation sets, the conversation ID generated is unique and this is not a problem because Oracle SOA Suite decides which conversation ID to generate, and not you.

Oracle SOA Suite does not execute a revision check for callback routing. Routing of callback messages is only based on the following:

• Conversation ID: This is calculated based on the input value and correlation set. If you use the same correlation set for two revisions of processes and enter the same input when creating an instance, both revisions subscribe using the same conversation ID. This causes confusion when a callback for one revision is delivered to another revision.

• Operation name (is the same for both revisions).

• BPEL service component name (is also the same for both revisions).

The concept of a revision number is applicable to Oracle SOA composite applications, and is not part of the BPEL specification. This is why it is not used as part of the routing decision.

There is another complication in which adding a revision as part of callback routing causes problems. When sending a callback, you also specify the endpoint URL. If the endpoint URL does not contain the composite revision (which is extremely likely), the message is assumed to be routed to the default revision. If Oracle SOA Suite runtime adds a revision check as part of callback routing, the callback for the nondefault revision instance is never possible.

For example, assume you have the following BPEL process:

• An entry receive activity named receive_1 (on which a correlation set is used)

• An invoke activity, which invokes a web service

• A receive activity named receive_2

Assume you perform the following steps:

1. Deploy revision 1.0 of composite_A, which includes a BPEL component.

2. Create an instance of revision 1.0, which is using a correlation set, and input a value of 123, which generates conv_id = "123".

   This process now invokes a web service through a one-way invoke activity and then waits on the receive_2 activity for a callback to arrive.

3. Deploy revision 2.0 of composite_A, which now becomes the default revision.

   A web service sends a callback for the instance for revision 1.0. However, as a part of its URL, it does not specify the revision number. You typically create a callback so that the URL does not use the revision number. This is because web services are external and you cannot change web service settings to continue using a revision tag because it is internal to Oracle SOA Suite and is a concept that the external world does not understand.

   Since a revision number is not specified, the SOA server assumes that the revision number must be 2.0 and, if the routing of the callback takes the revision number into account, it cannot forward this callback intended for 1.0 to the correct revision 1.0. Instead, it attempts to route it to the default revision of 2.0, which does not have any instance waiting for the callback.

   You cannot route callback messages based on revisions. You only receive the option to route callback messages based on the conversion ID (if the correlation set is not used, then even this is not under your control), operation name, and component name.

   For these reasons, different instances must use different conversation IDs (which means different input is used for creating a conversion ID) to avoid confusion, and routing should be solely based on a conversation ID.