Implicit Correlations


Introduction

BPEL process instances are stateful. Therefore, a client interacting with the BPEL engine must identify the particular instance with which it intends to interact in all of its communications. The BPEL specification defines a mechanism (correlation) which allows the process designer to specify which parts of an incoming message (i.e. a message going from a client to the BPEL server) should be used to identify the target process instance. Correlation is a powerful mechanism, however it is a bit complicated and relies on "in-band" message data to associate a messages with a process instance.

To keep simple cases simple, WSO2 Business Process Server provides an alternative correlation mechanism — implicit correlation — that automatically handles correlation through "out-of-band" session identifiers. The mechanism is simple: a unique session identifier is associated with every partner link instance. When a message is sent on a partner link, the session identifier is sent along with the message. The recipient is then able to use the received session identifier in subsequent communications with the process instance. Messages received by the BPEL engine that have a session identifier are routed to the correct instance (and partner link) by that session identifer.

There are two major use cases for the implicit correlation mechanism requiring different levels of familiarity with the mechanism's details: process to process and process to service interactions. The former case deals with situations where the WSO2 Business Process Server BPEL process instance is communicating with another WSO2 Business Process Server process instance. The latter deals with situations where a WSO2 Business Process Server BPEL process instance is communicating with an external service.


Process to Process Interaction Use Case

When an WSO2 Business Process Server process needs to communicate with other WSO2 Business Process Server processes, using implicit correlations is quite simple. Simply omit the <correlations> element from the <receive>, <pick>, and <invoke> activities. The following is an example showing one process (processA) starting another (processB) and then being called back:

  • ProcessA
            .
            .
            .
            <invoke name="initiate" partnerLink="responderPartnerLink" portType="test:MSResponderPortType"
                    operation="initiate" inputVariable="dummy"/>
            <receive name="callback" partnerLink="responderPartnerLink"
                     portType="test:MSMainPortType" operation="callback" variable="dummy"/>
            .
            .
            .
        
  • ProcessB
            .
            .
            .
            <receive name="start" partnerLink="mainPartnerLink" variable="dummy"
                         portType="resp:MSResponderPortType" operation="initiate" createInstance="yes"/>
            <invoke name="callback" partnerLink="mainPartnerLink"
                       portType="resp:MSMainPortType" operation="callback" inputVariable="dummy"/>
            .
            .
            .
        

In the above example, WSO2 Business Process Server will use the implicit correlation mechanism because no explicit correlations are specified. Communication between the two processes will reach the correct instance as long as the same partner link is used.


Process to Service Interaction Use Case

TODO