Correlation Sets

What is Correlation Set ::

-----------------------

Correlation Set is a mechanism with the help of which incoming messages meant for a port of BPEL process is routed to a specific instance of the BPEL process

based on the content of the inbound message.

In other word we can say that correlation set is a collection of properties used by the BPEL engine to identify the correct bpel process instance to receive a message. Each property in the correlation set may be mapped to an element in one or more message types through property aliases as will be discussed below.

When should I Use Correlation Set ::

---------------------------------------

There is no need to use it in synchronous interaction. Normal asynchronous interactions in BPEL use WS-Addressing with the help of SOAP headers for correlation and it is not required in case of normal invoke and receive patterns.

A bit abt WS-Addressing :: In this case whenever a BPEL process component calls an asynchronous service, it creates a correlation ID and send it as part of SOAP header to the invoked service. The service when execute callback invoke activity to send back the response uses this correlationId to identify which instance this response should be returned back.

But in cases like A- > B - > C - > A, C does not have a clue to which instance of A it should send the response. So in such type of scenarios we need correlation set to uniquely identify an instance of a BPEL process component.

So when should I use them. Following are the cases.

a) When you need to interact with an aynchronous service that does not support correlation.

b) For cases where we can expect unsolicited messages(i.e. messages for which we did not ask for ex: A->B->C->A or when an already initiated BPEL instance waits on a receive activity for further inputs without executing an invoke activity to invoke some service. So in this latter case the instance has not invoked any service but still waiting for some inbound message.

Some misconception about the correlation set

--------------------------------------------

1) Only the process receiving the messsage needs to worry about correlation. As long as the sending service includes sufficient information in the message to be able to correlate it with previous activities there is no need for the sender to even be aware that correlation is occuring.

2) Correlation properties must be unique for the duration of the life of the BPEL process that set them. Make sure that you can't have two processes working with the same correlation tokens, for example using social security numbers to correlate an expense claims process would be a bad idea if an individual could kick off two seperate instances of the process.

Properties can be made up values or actual business identifiers such as purchase orders or numbers. They don't have to be strings, they can be any reasonable XML type.

Correlation Set can be used in invoke,reply,receive,onMessage branches. In receive, reply and OnMessage branches they are defined in the same way. But

in case of invoke activity, the definition of correlation set includes a property called pattern.

In the case of invoke, when the operation invoked is synchronous

request/response, a pattern attribute is used to indicate whether the correlation applies to the outbound (request) message, the inbound (response) message, or both

I will go through an example to show how we can use correlation set to uniquely identify a particular BPEL process instance.

As an overview in this BPEL process we will have an initial receive activity that will receive an inbound request message to the BPEL process, will initiate a correlation set and after that it will loop and inside the loop it will wait on receive activity for incoming correlated messages

Steps

1) First create an async BPEL process named CorrProcess.

2) Define the following elements in XSD....

3) Define the following messagetypes in your wsdl.

4) Define the operations as follows

Here we have defined the operation update and stop apart from the by default available operation process on PortType CorrProcess.

Note that

If you try to use the same operation, on the same partner link with same port type, for the correlated receive activity and then you try to invoke this waiting instance on the same operation set again by passing the same req value for the field in message type for which correlation set is defined then the BPEL process throws ConflictingReceive fault.

5) Now in the CorrProcess BPEL, double click the first receive activity which is bounded to operation 'process' on CorrProcess portType and on correlation tab (refer to fig below), create your first correlation set.

</correlationSets>

The pop window (as shown above) will ask you to define the global property. So define a property with name OrderIdProp and in turn you have to specify the property alias.

Use the /client:process/client:OrderId value in the incoming message payload as the property alias for this.

After doing this, it will create CorrProcess_Properties.wsdl file containing the definition of global properties as below

<bpws:property name="OrderIdProp" type="xsd:string"/>

and definition of property alias in CorrProcess.wsdl file as follows

<bpws:propertyAlias propertyName="pns1:OrderIdProp" messageType="client:CorrProcessRequestMessage" part="payload"

query="/client:process/client:OrderId"/>

Make sure to check CreateInstance property and set initiate property of correlation set to 'yes'. If the value of CreateInstance is checked in a receive activity then this means that this receive activity will create a new instance of BPEL process whenever invoked. If the value of initiate property of the correlation set associted with this receive activity is yes, then it initialze the value of the property associated with this correlation set with the value of property alias (/client:process/client:OrderId of inbound message payload which receive activity receives.). Here in this case it will initialze the value of the global property OrderIdProp with the value of OrderId in the inbound message payload.

So this value will be used to uniquely identify this instance in future communications.

So the receive activity will look like this.

</correlations>

</receive>

6) After this send an initial reponse back to the caller of this process using invoke activity. (I observed that using correlation set that we have just defined in this activity does not have any impact that is even if we don't correlate the reponse message we are sending back to the caller from this process still consumer of this process is able to call the right instance of the BPEL process with the help of correlation set. The reason might be the fact that correlation set is already initialzed by receive activity.)

7) Now create a receive activity in a loop which is waiting on operation Update of portType CorrProcess. Associate this activity to already defined correlation set 'OrderIdSet'. Make sure to uncheck createInstance (because we don't want to create a new instance here) and initiate property of correlation set to 'no'. Edit the propery alias value to /client:processUpdate/client:OrderId.

Now because we kept intiate = 'no', so when a client calls this process on update operation then it will not again initiate the correlation set with new value of property OrderIdProp based on the property alias value we defined for this property over here. Instead it will match the value of property OrderIdProp against the value of property alias /client:processUpdate/client:OrderId and if it is same then it will invoke the instance corresponding to this correlation set.

<receive name="ReceiveUpdatedInfo" createInstance="no"

variable="UpdateVar" partnerLink="corrprocess_client"

portType="client:CorrProcess" operation="update">

</correlations>

</receive>

8) In the same way we will define and associate the correlation set OrderIdSet with OnMessageHandler branch (Pls refer to fig below) on operation 'stop' on the port type 'CorrProcess' and will edit the value of property alias to /client:processStop/client:OrderId

So when user invokes the operation stop on porttype ‘CorrProcess’ then OnMessageHandler branch gets executed and a termintae activity which is defined into that gets executed thereby terminating the instance.

Following is the snapshot of the defined property OrderIdProp and its corrresponding aliases from Structure pane.