WS-BPEL-What is Correlation, message Property, Property Alias, and Correlation Set

WS-BPEL

What is a BPEL Correlation?

At the start of a Business Process, a new process instance is created and it lives for the lifetime of the business process. Since there might be multiple business-process instances active at the same time in the BPEL Engine, all messages sent to the business process have to be delivered to the correct business process instance. BPEL process instances communicate with each other by invoking partner web services. The structure of the application-data passed around is transparent to the BPEL engine since BPEL partner services do not address each other by an identifier. However, the messages passed around contain key fields that can be correlated for the lifetime of the exchange. Since multiple business-process instances are active at the same time, business-application-specific data (like social security numbers, insurance-claim numbers, tax payer IDs, or any business-application-specific identifiers) available in the exchanged messages are used to maintain references to specific business process instances. This idea of associating business-application-specific data found in the messages to maintain references to specific business process instances is termed BPEL Correlation.

Any business-application-specific data used for correlation is contained in the messages exchanged by the BPEL partner services. The exact location of the correlation identifier varies from message to message and is specific to a business process. To specify which business-application-specific data to use for correlation, message properties defined in the WSDL file are used. To brook an analogy, think of how you define and use a primary key to access all records associated with this key from your domain model.

Message Properties (<property>) defined in WSDL files

Messages exchanged by partner services in a BPEL Engine usually contain business-application-specific or application-specific data which are used by the business processes. Message Properties defined in the WSDL file using the WSDL extensibility element mechanism, create an association between relevant business-application-specific data to a name that can have an important role to play in the global context of the business process and can therefore be used for Correlation. Since these message properties are mapped to multiple messages, it makes sense to name them with global property names.

<?xml version="1.0" encoding="UTF-8"?>
<definitions ...    
             xmlns:bpws="http://schemas.xmlsoap.org/ws/2004/03/business-process/"
             ...>
  ...
  <bpws:property name="claimNumberProperty" type="xsd:string"/>
  ...
</definitions>

<propertyAlias> defined in WSDL files

Property Aliases are used to map properties to messages. Message parts contain business-application-specific properties. A property alias maps a specific property to a specific element or attribute in a message part. Once defined, it is possible to use the property name as an alias for the message part and the location of the property within the message. Property Aliases are defined in the WSDL file using the WSDL extensibility element mechanism. The query expression used to access the relevant element or attribute is written in the selected query language, the default being XPath 1.0.

<?xml version="1.0" encoding="UTF-8"?>
<definitions ...    
             xmlns:bpws="http://schemas.xmlsoap.org/ws/2004/03/business-process/"
             ...>
  ...
  <bpws:propertyAlias propertyName="tns:claimNumberProperty"
                      messageType="ns1:getClaimNumberResponse"
                      part="parameters">
    <bpws:query>/getClaimNumberResponse/return</bpws:query>
  </bpws:propertyAlias>
  ...
</definitions>

<correlationSet> defined in BPEL files

Correlation sets are used to tie together a partner conversation and are used to associate messages with business processes. A set of properties shared by all exchanged messages and used for correlation is called a Correlation Set. Each correlation set has a name as can be seen in the skeletal listing below. A message can be related to one or more correlation sets.

<?xml version="1.0" encoding="UTF-8"?>
<process ...>
  ...
    <correlationSets>
        <correlationSet name="claimNumber" 
                        properties="ns1:claimNumberProperty"/>
    </correlationSets>
  ...
</process>

There are two roles that can be defined when correlated messages are exchanged between different BPEL partner processes:

• Initiator of the Correlation: The partner process that sends the first message is the initiator of the correlation. This is normally either a <receive> or <invoke> activity. The values obtained from this initiating step is used to populate the correlation set. If this is an <invoke> activity, the values correspond to those sent by the partner process, or the values received back from the partner process (if this is a synchronous invoke), or both. If this is <receive> activity, the values correspond to the ones that came from the inbound message. These values determine the property values for the correlation set.
• Followers of the Correlation: All other partner processes are followers of the correlation and get the property values for their correlation sets from incoming messages. These subsequent steps match the data in the correlation set with the initialized data. A <receive> activity is triggered only if the data in the incoming message matches the values in the correlation set. An <invoke> or <reply> activity must send out data that matches the data in the correlation set. Both Initiators and Followers must mark their first activity that binds the correlation sets.

Correlation Sets can be used in multiple BPEL activities like <receive>, <reply>, <invoke>, <onMessage> parts of <pick> activities, or event handlers. The <correlation> activity that is present inside of any of the above mentioned activities is used to specify which correlation set to use. By default the value of the initiate attribute is set to ‘no’. When correlations are used with the <invoke> activity, a pattern attribute is also required. These pattern attributes can have one of these values:

• in – specifies that the correlation applies to inbound messages
• out – specifies that the correlation applies to outbound messages
• out-in – specifies that the correlation applies to both inbound and outbound messages

 ...
<sequence>
  ...
  <invoke name="InvokeClaimNumberer" 
          partnerLink="ClaimNumberer" 
          operation="getClaimNumber" 
          portType="ns3:ClaimNumberer" 
          inputVariable="GetClaimNumberInput" 
          outputVariable="GetClaimNumberOutput">
    <correlations>
      <correlation set="claimNumber" initiate="yes" pattern="in"/>
    </correlations>
  </invoke>
  ...
</sequence>
...

 ...
<sequence>
  ...
  <invoke name="InvokeAddNewAdjustmentJob" 
          partnerLink="Adjuster" 
          operation="addNewAdjustmentJob" 
          portType="ns4:Adjuster" 
          inputVariable="AddNewAdjustmentJobInput"/>
  
  <receive name="ReceiveSubmitAdjustment" 
           partnerLink="AdjusterCallback"
           operation="submitAdjustment" 
           portType="ns2:IAdjusterCallback" 
           variable="SubmitAdjustmentInput" 
           createInstance="no">
      <correlations>
          <correlation set="claimNumber"/>
      </correlations>
  </receive>        
  ...
</sequence>
...

Note: All examples use the Insurance Claim Composite Application Scenario described in this blog entry.