Use BPEL Correlation Sets for repeated (synchronous) access to long running BPEL processes

Standing on the shoulders of Anthony Reynolds and Matt Wright, I finally managed to get the Correlation Sets feature in Oracle BPEL PM to do what I intended: I can instantiate BPEL process instances, with an identifier of my choosing and immediately receive their first response. Then at some later moment in time, I can invoke one of these already existing instances to return the same or additional data to me. I can use these instances as a temporary data cache, as the foundation for a RESTFul WebService or allow them to collect data at their own pace, with me regularly checking up on them. Anything really I might want to ask a BPEL process at some later point in time can be made accessible in this way. And now that it works, it is all so very easy.

The steps are: 

1. Create the new BPEL Process based on the Synchronous Process Template
2. Create a property called InstanceIdentifier (created in a separate Process_Properties.wsdl file)
3. Define a Correlation Set called Correlation_InstanceIdentifier (in the .BPEL file)
4. Associate the Correlation Set with the initial Receive (set initiate to yes)
5. Associate the Correlation Set with the initial Reply (set initiate to no)
6. Associate  the Correlation Set with every subsequent Receive (set initiate to no)
7. Create Property Aliases, in the process WSDL file, that associate the InstanceIdentifier property with relevant section in the input message passed into the initial Receive activity, with the relevant section in the initial Reply and with the relevant sections of the input messages associated with all subsequent Receive activities

With all this in place, we can deploy the BPEL process, and try it out. Note: it turns out that the correlation will only be made for the subsequent Receive activities when the call from the BPEL Console is made from the XML Source option – and not using the HTML Form!

I will show a very simple example of a BPEL Process that is initiated, sets a counter to zero and returns a message to that effect. Then, instead of expiring, it continues to hang around to listen for additional invocations ‘associated with the same correlation set value’. Thus I can start up as many parallel instances of this process and then retrieve counter values from each of them individually. No one in his right mind would be interested in that kind of thing, but it proves some very interesting points with the BPEL Correlation mechanism.

Step by Step implementation

1. Create the new BPEL Process based on the Synchronous Process Template
2. Create a property called InstanceIdentifier (created in a separate Process_Properties.wsdl file)

<definitions
     name="properties"
     targetNamespace="http://xmlns.oracle.com/CachedServer/correlationset"
     xmlns="http://schemas.xmlsoap.org/wsdl/"
     xmlns:bpws="http://schemas.xmlsoap.org/ws/2003/03/business-process/"
     xmlns:plnk="http://schemas.xmlsoap.org/ws/2003/05/partner-link/"
     xmlns:xsd="http://www.w3.org/2001/XMLSchema"
     xmlns:pns1="http://xmlns.oracle.com/CachedServer"
    >
    <bpws:property name="InstanceIdentifier" type="xsd:string"/>
</definitions>

3. Define a Correlation Set called Correlation_InstanceIdentifier (in the .BPEL file)

  <correlationSets>
    <correlationSet name="Correlation_InstanceIdentifier"
                    properties="ns1:InstanceIdentifier"/>
  </correlationSets>

4. Associate the Correlation Set with the initial Receive (set initiate to yes)

    <!-- Receive input from requestor. (Note: This maps to operation defined in CachedServer.wsdl) -->
    <receive name="receiveInput" partnerLink="client"
             portType="client:CachedServer" operation="process"
             variable="inputVariable" createInstance="yes">
      <correlations>
        <correlation initiate="yes" set="Correlation_InstanceIdentifier"/>
      </correlations>
    </receive>

5. Associate the Correlation Set with the initial Reply (set initiate to no)

6. Associate  the Correlation Set with every subsequent Receive (set initiate to no)

        <receive name="Receive_UpdateRequest" partnerLink="client"
                 portType="client:CachedServer" operation="Update"
                 variable="Receive_UpdateRequest_Update_InputVariable"
                 createInstance="no">
          <correlations>
            <correlation initiate="no" set="Correlation_InstanceIdentifier"/>
          </correlations>
        </receive>

7. Create Property Aliases, in the process WSDL file, that associate the InstanceIdentifier property with relevant section in the input message passed into the initial Receive activity, with the relevant section in the initial Reply and with the relevant sections of the input messages associated with all subsequent Receive activities

    <bpws:propertyAlias propertyName="pns1:InstanceIdentifier" messageType="client:CachedServerRequestMessage"
    part="payload" query="/client:CachedServerProcessRequest/client:input"
    />
    <bpws:propertyAlias propertyName="pns1:InstanceIdentifier" messageType="client:CachedServerResponseMessage"
    part="payload" query="/client:CachedServerProcessResponse/client:instanceId"
    />
    <bpws:propertyAlias propertyName="pns1:InstanceIdentifier" messageType="client:CachedServerUpdateRequestMessage"
    part="payload" query="/client:CachedServerUpdateRequest/client:instanceId"
    />

Demonstration of the Repeated Calls into a long running Process instance

The first call with a new instance id will start a brand new process instance, that on subsequent calls can be access again, as we will see.

Here we assign an instance id value of P1. When I press Post XML Message, the following message appears:

A new instance has been created, the counter variable is set to zero. Now I click on the hyperlink to initiate another test instance. However, as I will be using the same instance id value, there will not be a new instance; instead, the existing instance P1 will be reused.

Note that I will now call the Update operation – instead of process that we used before. Also notice that I have activated the radio button XML Source as opposed to HTML Form. I found  that using the HTML Form, I could not get the correlation to work.

After pressing the Post button, this message appears – showing the synchronous reply from the correlated process instance, that has increased its counter value and returned to the client:

At this point, there is only a single Process Instance – for identifier P1, There are two other open instances I had started earlier on with idenrifiers A and B. Now we can take a look at the process flow for Process Instance P1:

Once in the WHILE, the process will increase the counter, wait for another incoming call for the Update operation, return the current Counter value and re-enter the loop, until Counter is over 20.

We can see visual evidence of the repeated calls we have made from the BPEL console into the P1 process instance of this CachedServer process:

And this is the grail of the day: starting a process instance, have it perform some work and collect some data and have repeated access to it from potentially various clients.

Resources

Download JDeveloper 10.1.3.3 Project with the CachedServer that you can deploy to the Oracle BPEL PM: CachedServer.zip.

Blog Post Matt Wright on creating a Singleton BPEL Process Instance – that explained a lot about Correlation that I found very helpful.

Article by Anthony Reynolds, also explaining Correlation concepts (though not as practical for my purpose).