Correlation Sets

BPEL Correlation  Where Did I Put That Process? A BPEL process is initiated and makes a call to an ERP system to raise a purchase order, generating a purchase order number.  Later that purchase order causes another system to raise an invoice and send the invoice to the BPEL process.  How does the BPEL engine know which BPEL process should receive this invoice and process it.  This is dealt with a thing called correlation. From e-mails and phone calls that I receive it appears a lot of people struggle with BPEL correlation.  It seems that the questions falls into two categories, why would I want it, and how do I do it? What is Correlation? Correlation is basicallly the process of matching an inbound message to the BPEL engine with a specific process.  Normally this matching is hidden from us.  Synchronous calls have no need of correlation because the conversation context is maintained on the stack or across a TCP connection.  Consenting BPEL processes will usually correlate messages using WS-Addressing headers to pass around magic tokens that act like the session cookies in a web application. Why Do I Need Worry About It? Well most of the time you don't!  As I mentioned before, calling another BPEL process or using a synchronous call will mean you don't have to think about it.  You do need to worry about it in the following situations amongst others. When using an asynchronous service that doesn't support WS-Addressing When receiving unsolicited messages from another system When communicating via files In these casess we need to be able to tell BPEL to look at some content of the message in order to select the correct process instance to receive the message. How Do I Get the Right Process Instance? BPEL provides a construct called a correlation set to allow for custom correlation.  A correlation set is a collection of properties used by the BPEL engine to identify the correct process to receive a message.  Each property in the correlation set may be mapped to an element in one or more message types through property aliases as shown below. Things to Remember About Correlation I see some common misunderstandings about custom correlation.  So lets knock them off now. Only the process receiving the messsage needs to worry about correlation <BR/>As long as the sending service includes sufficient information in the message to be able to correlate it with previous activities there is no need for the sender to even be aware that correlation is occuring. Correlation properties must be unique for the duration of the life of the BPEL process that set them. <BR/>Make sure that you can't have two processes working with the same correlation tokens, for example using social security numbers to correlate an expense claims process would be a bad idea if an individual could kick off two seperate instances of the process. Properties can be made up values or actual business identifiers such as purchase orders or numbers.  They don't have to be strings, they can be any reasonable XML type. A Quick Guide to Custom Correlation Enough of the theory, how does it work in practice?  Consider a process A that call a process B that calls a process C that calls a process A.  This is one of the scenarios (113) in the BPEL samples distributed with Oracle BPEL PM. So we have a cycle A->B->C->A.  Three different asynch calls. Note only process A needs correlation because only A receives more than one call. On the invoke from A to B we add a correlation in the correlation tab for the invoke using BPEL Designer.  In here we will create the correlation set and create a property to correlate the exchange.  We set this to initiate the correlation, meaning that it will associate this process with the given value. On the receive from C to A we add the same correlation set with its property as we did for the invoke from A to B.  However this time we mark the receive as not to initiate the correlation, meaning that the BPEL PM will use this to select the right process instance. We now go to the BPEL structure diagram in the BEL Designer and add the property alias.  We create two property aliases maping to appropriate elements in each message that will have the same value in message from A to B, as in the message from C to A.  Note that the elements can be different names and in different structures in the two messages, but they must contain the same value if correlation is to work. At this point BPEL designer has done almost everything.  We need to manually edit the bpel.xml file and add the following XMl fragment to each partner link that will participate in the correlation. <property name="correlation">correlationSet</property> Note that " correlationSet" is a fixed value. I have uploaded a sample of this process.  Note deploying it may be tricky due to circular dependencies.  How to deploy it is left as an exercise to the reader, but if the worst comes to the worst deploy an empty version of the process B, then deploy process A, then process C and then the real process B.