BPEL Correlations introduced using Sun CAPS

It has been a while since my last post, so let me start with a quick update on my real world SOA journey. As I had mentioned previously, I was able to get some Sun Java CAPS training and was temporarily putting Cape Clear on the back burner. Well, I have been working with CAPS now for about a month and I find it very interesting. Fortunately, some of the issues I ran into with Cape Clear are no different on CAPS. In reality, they are more SOA issues than product issues. For example, invoking a web service that uses SOAP encoding (as discussed here). That being said, I could reuse much of the experience I gained with Cape Clear during my CAPS implementation.

Enough history (you can read my previous posts to catch up), this post is supposed to be about correlations. If you are familiar with JMS, correlation is probably nothing new. Basically you are associating one message with another message via some identifier. In JMS you typically use the correlationID message header attribute and create the appropriate logic in your application. CAPS (and Cape Clear, as well as others) provides a correlation mechanism within a Business Process (using BPEL). BPEL correlation allows a process to be persisted while waiting for a correlating response. This is usually required when dealing with asynchronous exchanges.

A typical example is a purchase order and corresponding invoice (related via the PO number). A business process may receive a PO, do some processing, and then wait for the associated invoice. Once the invoice is received, the business process does some more processing using the PO and Invoice data, and eventually completes. While waiting for the Invoice, the process can be persisted either to memory or some more permanent store to survive server reboots, etc. The magic here is retrieving the correct business process instance once the corresponding invoice is received. This is accomplished via the correlation set. A correlation set is defined different ways for different products, but it essentially represents some combination of message parts that are available to activities within the business process. So in this example, the PO number in the purchase order message and the PO number in the invoice message would comprise this correlation set. These message parts are typically called aliases.

Within CAPS, you define what is called a correlation key, which is made up of the aliases described above. Then you define a correlation set based off of the correlation key. I'm not really sure why the extra step of creating a correlation key, but that is the mechanics involved. As shown below, this correlation key/correlation set is defined on the properties sheet of the business process.


In this example, the correlation key is made up of a single alias, the message correlation ID. In reality, the alias can be made up of one or more message parts that exist in the business process.


Once defined, the correlation set needs to be applied to activities within the business process. One activity should initialize the correlation set, while another process should use the correlation set.


The difference being the value for the "Initialize Set" field. Also, depending on the type of activity for which you are using correlation sets, you may get the following dialog:


On this dialog, you need to select where the application of the correlation set should take place, at the input of this activity, the output, or both. I'm not really sure what it means to use "both", but I hope to experiment with this sometime in the future.

In order to have the business process use the correlations, there must be a receive activity somewhere in the midst of the business where we are waiting for a message. So in the typical example above, we may be waiting for the invoice to arrive on a message queue somewhere after the PO has arrived in our business process.

So here is how the process works, using a simple business process shown below:

A PO comes in via JMS (PO number 123). The business process is instantiated. This receive activity is configured to initialize a correlation set as shown previously. Execution of the various activities and business rules will continue until the next receive activity is encountered (JMS.receive Invoice). At this point the business process is persisted using the identifier specified in the correlation set. In our example this would be the correlation message header property of the inbound JMS message (123). At some future time, an invoice shows up on the appropriate message queue for PO 123. This invoice has the correlation Id of the JMS message header set to the purchase order, so the BPEL engine looks for a business process instance with a correlation identifier which includes the name of the correlation set (corrSetCorrelationID) and a value of 123. If this is found, the business process instance is retrieved (with its state intact) and the process continues to completion.

This is a real simple example which uses the JMS message header as the correlation set alias. This requires the applications creating the messages to populate this field prior to sending the message. A more elegant solution is to use actual message values to correlate on, but the goal of this post was to introduce the basics of correlation.

You can find tutorials that show how easy this is to do on many of the SOA product suites. Tutorials are great, but they hardly translate to real world problems. Here is where my real world "challenge" came into play. The CAPS tutorials that I found really didn't explain the entire correlation configuration and mechanics. In my next post, I'll discuss the challenges I encountered applying correlation to my business process (described here) and the final implementation. Although this will present correlation relative to CAPS, I believe this will translate well into other product implementations of correlation.