(this post was inspired by this question on the developer works forum)
One of the important concepts to grasp in creating complex Business Processes in IBM BPM is the idea of event correlation. I’m going to try to help with some of the complexity here.
Definition
When your business user is talking to you about their process and they indicate that the process needs to either wait for something external to the process to occur or react to something that happens outside of the process, we will likely need to model this as an Intermediate Message Event (IME).
For example if you were working on a corporate relocation process the business user might say “Of course, at any time in this process the person relocating may call up and say that they changed their mind and are canceling the relocation and the process needs to then stop everything and we need to follow a flow to undo the work thus far.”
The customer canceling their relocation can be modeled as an IME in your process. (I’ll deal with the details of modeling and triggering this in a later post).
Correlation Defined
The next thing to figure out when one of these events triggers is “Which BPD instance needs to react to this”. This is handled in the product through a “correlation” value. Your Under Cover Agent (UCA) service that triggers the IME will need to have at least 1 data output associated with it. In your IME on the BPD you will tell the system to compare this output value to the value of a variable on your BPD and, if they match (and if your IME is listening) trigger the IME.
Your UCA/IME is not limited to mapping only the correlation value. You can also tell it to map other output values to variables in the BPD and this mapping will occur when the correlation values match. This allows you to update BPD values when the IME triggers. In our relocation example this might contain the reason the person cancelled their relocation, or other important details.
Complex Correlation
Sometimes it is difficult to use a single value for the correlation in your IME. In that case there are 2 approaches you can follow for your correlation. There is one that is explicitly supported by the product and then there is the one that has seen the most use in the field
Product supported option
In the IME UI there is a “Condition” value that can be used to examine variable values on the BPD Instance and determine if the process should move the token from the IME to the next step. While this sounds great in theory, the reality falls a bit short.
Ideally what you would want to be able to do is to check a value on the BPD against a value in the message and see if they meet some criteria, and, if they do then move forward. However in my testing it seems the logic can only check the current values on the BPD and there is no way to access the data in the IME payload, even if you have it mapped, until after the correlation is successful. This means this conditional is only really a good idea if you want to check if the BPD data is in a certain state before you allow correlation to occur.
Real World Option
So if you do need to use multiple variables to determine if your IME should correlate, what do people do? One easy answer is using a complex key. Lets say you have a business process that kicks off a Multi Instance Loop (MIL). For example lets say it is approval for a number of things, and each of the items requires an approval. Now lets say the user wants to cancel one of the items from their request. Your IME is inside the loop, but if you use, say, the request ID for the message, all of the requests will be cancelled. Compound keys to the rescue!
In our scenario there is one request id with any number of linked instances kicked off in a MIL and we want to cancel one of them. One option would be to have the IME that is listening for the cancel use a compound key for it’s correlation value. This could be, for example, the request id and the MIL number. We would create a string that has those 2 options separated by a delimiter (I typically use | ) so the if our request id is 1654 then the 3rd MIL instance would have a correlation value of 1654|2 (the MIL list is zero based so the 3rd item has a value of 2 for its count).
Now as long as the sender can determine this data (and MIL’s do spin up in a predictable order when handed a list, first to last) you can send the cancel signal to a specific IME even though many were listening for that event.
Other examples
To be honest, I know that I’ve used this technique many times in the field, but when I sat down to write this post, I couldn’t come up with any real world scenarios better than the one mentioned above. I hope that this might aid you in the future with complex event correlation scenarios.
