Background
HTTP is stateless in nature, and thus provides no support for conversations requiring the exchange of multiple messages. With synchronous interactions, this is not an issue, as the response message for a particular request can be returned in the HTTP response. However, with asynchronous interactions, this is a more serious limitation. Take below use case ..
Use case
A BPEL process "A" calls asynchronous process "B", and Process-B returns (callback) the result to Process-A after some significant amount of time (B is asynchronous process). Assume multiple instances of process A and B running at the same time, once we have routed the message to the correct service endpoint, how does the service engine at that endpoint know which instance of "A" to route the response from "B" to? For this similar kind of situations where WS-Addressing not works, BPEL provides a cool feature called "Correlation".
Correlation in BPEL
6)- click, "receive" activity of "calling process" (this activity receives result from "called process") -> go to correlations tab -> you can see the correlation-set created in above step-4.
7)- Select the "predefined" correlationset -> click on "edit" icon (which opens correlation-set in edit mode) -> click on edit icon related to correlation-property (which opens the correlation-property in edit mode) -> click on "+" to create "new" alias (which is mapping) to map KEY of "result message".
now click on + sign to create new alias ->
Make sure that, the filed "Query" in above screen should have an xpath expression to point exact "Key" element. Now you all set with correlation functionality with your integration, just test it.
HTTP is stateless in nature, and thus provides no support for conversations requiring the exchange of multiple messages. With synchronous interactions, this is not an issue, as the response message for a particular request can be returned in the HTTP response. However, with asynchronous interactions, this is a more serious limitation. Take below use case ..
Use case
A BPEL process "A" calls asynchronous process "B", and Process-B returns (callback) the result to Process-A after some significant amount of time (B is asynchronous process). Assume multiple instances of process A and B running at the same time, once we have routed the message to the correct service endpoint, how does the service engine at that endpoint know which instance of "A" to route the response from "B" to? For this similar kind of situations where WS-Addressing not works, BPEL provides a cool feature called "Correlation".
Correlation in BPEL
The key components in defining the Correlation functionality are : 1)- Correlation-set 2)- Correlation properties 3)- Correlation Aliases.
Correlation set is a kind of pointer/setup that groups the correlation-properties and associated correlation-aliases. That means, if an engineer assigns a correlation set to a process then, all the underneath correlation-properties and aliases are available to that process.
Correlation sets can be attached at process level as well as limit to a particular scope. In majority of integrations, correlation sets are attached at process level.
Lets take an example :
A client application calls ProcessA with a message:
<customer>
<ssn>xxx</ssn>
<address></address>
</customer>),
ProcessA calls ProcessB with the above same customer message,
ProcessB gets/calculate customer credits-score and returns score back to ProcessA in below message format :
<customer>
<ssn>xxxx</ssn>
<creditscore>xxx</creditscore>
</customer>
In this scenario, if correlation-set is defined then, bpel-service-engine performs below steps (internally) -
1)- At the time of INVOKING ProcessB from ProcessA, bpel-service-engine serialize (or dehydrate) the state of that particular ProcessA Instance in to database.
2)- If you compare this database with "Hash-table" then, "hash-value" is Instance/state of ProcessA, and "Hash-key" (which is SSN) is identified based on the correlation-set (correlation-property -> correlation-alias) attached to "INVOKE" activity.
3)- Once credit-score is returned by ProcessB, bpel-service-engine holds that return message, identifies the "key" in that message based on the correlation-set setup defined at "RECEIVE" activity (correlation-property -> correlation-alias), and finds appropriate processA instance/object in database (hash-table mentioned in step2) to handover the return message.
Correlation set is a kind of pointer/setup that groups the correlation-properties and associated correlation-aliases. That means, if an engineer assigns a correlation set to a process then, all the underneath correlation-properties and aliases are available to that process.
Correlation sets can be attached at process level as well as limit to a particular scope. In majority of integrations, correlation sets are attached at process level.
Lets take an example :
A client application calls ProcessA with a message:
<customer>
<ssn>xxx</ssn>
<address></address>
</customer>),
ProcessA calls ProcessB with the above same customer message,
ProcessB gets/calculate customer credits-score and returns score back to ProcessA in below message format :
<customer>
<ssn>xxxx</ssn>
<creditscore>xxx</creditscore>
</customer>
In this scenario, if correlation-set is defined then, bpel-service-engine performs below steps (internally) -
1)- At the time of INVOKING ProcessB from ProcessA, bpel-service-engine serialize (or dehydrate) the state of that particular ProcessA Instance in to database.
2)- If you compare this database with "Hash-table" then, "hash-value" is Instance/state of ProcessA, and "Hash-key" (which is SSN) is identified based on the correlation-set (correlation-property -> correlation-alias) attached to "INVOKE" activity.
3)- Once credit-score is returned by ProcessB, bpel-service-engine holds that return message, identifies the "key" in that message based on the correlation-set setup defined at "RECEIVE" activity (correlation-property -> correlation-alias), and finds appropriate processA instance/object in database (hash-table mentioned in step2) to handover the return message.
In detail (with screen shots):
1)- "calling" Synch process is invoking "called" asynch-process.
2)- Create Correlationset (at process level).
For this, Open Calling Bpel process -> Open Invoke activity -> go to "correlations tab" -> click on + sign in the "correlation tab form" -> click on "..." -> click on + sign -> Provide correlation name ->
3)- Create a Correlation property
For this, click the + sign of above screen (correlation set screen) ->
hightlight properties -> click on + -> provide property name -> provide type (string) -> click ok
4)- Now create Alias (for "request message")
For this, click + sign in the "Alias" tab of "property form" -> select the "unique identifier" of the request (which is input message to "sub bpel process")
Make sure that, the filed "Query" in above screen should have an xpath expression to point exact "Key" element.
Thats it, you have created the mapping to find/capture the "Key" related to the "input" message of "Called process".
5)- Now, attach the mapping (correlation set) to the RECEIVE activity.
