Pascal On BPMS

I’m not going to argue that BPEL Correlations are complex and hard to use. I think what you have to do to setup a correlation speaks for itself.

I’m not going to explain how you can setup a correlation either. I’ve already covered this in Setting up a Correlation, but I’m going to use the generated BPEL Process to walk you through how the correlation actually works, and in doing so show you how each piece fits into the whole.

But just to summarize, so you know what are all the pieces needed, here is what you need for the simplest correlation example.

The Process

The 2 messages:

<xs:element name="Message1">
  <xs:complexType>
    <xs:sequence>
      <xs:element name="Name" type="xs:string"/>
      <xs:element name="Age" type="xs:string"/>
    </xs:sequence>
  </xs:complexType>
</xs:element><xs:element name="Message2">
  <xs:complexType>
    <xs:sequence>
      <xs:element name="Name" type="xs:string"/>
      <xs:element name="Address" type="xs:string"/>
    </xs:sequence>
  </xs:complexType>
</xs:element>

Then you need to define

- at least a Property

<bpel:property name="name" type="xs:string"/>

- a correlationSet

<bpel:correlationSets>
  <bpel:correlationSet properties="tns:name" name="name-correlation"/>
</bpel:correlationSets>

- 2 property aliases (one for each message)

<bpel:propertyAlias propertyName="this:name" messageType="Client:msg1" part="Message1">
  <bpel:query>Correlation:Name</bpel:query>
 </bpel:propertyAlias>

<bpel:propertyAlias propertyName="this:name" messageType="Client:msg1" part="Message2">
  <bpel:query>Correlation:Name</bpel:query>
 </bpel:propertyAlias>

- And attach the correlation to each receive

<bpel:receive bpmn:id="ID-5938e518-bfcf-1004-8cce-0438cf81d0f0"
  name="Receive1-Receive"
  partnerLink="Client_And_Correlation_PLink"
  portType="Client:Client_To_Correlation_PortType"
  operation="Receive1" variable="msg1" createInstance="yes">
  <rdfs:label xml:space="preserve">Receive1</rdfs:label>
  <bpel:correlations>
    <bpel:correlation set="name-correlation" initiate="yes"/>
  </bpel:correlations>
</bpel:receive>

<bpel:receive bpmn:id="ID-593b12e8-bfcf-1004-8cce-0438cf81d0f0"
  name="Receive2-Receive"
  partnerLink="Client_And_Correlation_PLink"
  portType="Client:Client_To_Correlation_PortType"
  operation="Receive2" variable="msg2" createInstance="no">
  <rdfs:label xml:space="preserve">Receive2</rdfs:label>
  <bpel:correlations>
    <bpel:correlation set="name-correlation" initiate="no"/>
  </bpel:correlations>
</bpel:receive>

That’s it.

First message arrives

So now that all the pieces are in place, let’s see how they each contribute to get the right message back to the right process instance. For this, let’s walk through an actual execution and examine what happens.

A message of type Message1 is received.

A new process instance is triggered (Correlation) and while executing the first receive (Receive1-Receive), the BPEL engine finds the correlation “name-correlation“, looks up its definition, figures out that it contains a property “name“, and since the message received is of type “Message1″, finds the property alias for this message type, part and property.

From there, it will use the query for that Property Alias to know which element of the message to use. This query can be any XPath expression. Finally, since this first correlation has the attribute initiate=”yes” , the engine will initialize the property name with the value of the <name> element in the incoming message. Phew, still with me?

Correlation -> property -> property alias (for the message type) -> query -> value stored.

Second message

From there, this is easy When a message of type Message2 arrives, we can go through the same steps. Except for 2 main differences: the message type and part is different, so the BPEL engine will use the second property alias. And the correlation has “initiate=”no”, which means that instead of setting the property value, it will match the value of the property with the value of the element found by resolving the query of the property alias. In this case, it is also a <name> element, but it could be anything. The value found is what matters for matching with the right process instance.

Correlation -> property -> property alias (for the message type) -> query -> match (or not).

So are BPEL Correlations complex? You bet. Are they impossible to understand? Not if you take the time to understand each piece and how it relates to the others.

Now you are ready to tackle bigger and more complex correlations! Use more than one correlation per process, add more properties to the correlation, do more than 2 message exchanges, the possibilities are limitless…