I had a scenario in which I had to receive two files from ftp. The two files, which comprised of two different messages, didn’t have any common field. These files were supposed to be delivered to a BPM instance. As there were two receive steps (i.e. to receive two files), correlation was required between them. As I was short of a common field between the two messages, it was difficult for me to define correlation in conventional way. Then I came across the use of Constant in Correlation. The use of Constant made it convenient to correlate both the messages.
Instead of using X-Path in which the common key field of message is used, I used Constant in Correlation Properties. Hence the correlation condition was always true and message was delivered to the running process instance.
With the help of this blog, I would like to elaborate on utilization of Constant in Correlation Properties. Before getting started with this topic, I would give a brief explanation of Correlation.
We can understand correlation as Semantic Relationships Between Messages in BPM. When defining integration processes (ccBPM), we use correlations to establish relationships between messages. For example, we could correlate a purchase order and the corresponding invoice by means of the purchase order number. The Business Process Engine takes any semantic relationships into account when controlling an integration process.
In any ccBPM, if you are having more than one receive steps, then we have to necessarily define and use correlation based on key field(s). Correlation ensures the delivery of messages to appropriate BPM instance.
Refer Milan’s blog Correlation – Runtime Behavior of BPM. to understand the use of correlation in BPM.
By now you would have got an idea of correlation, so I will explain my scenario.
Two files will be picked from FTP and delivered to XI by file adapter. First file consist of Header info and Second file consist of Item info. Using this scenario, information from both the files will be merged and will send information into third file on FTP.
Design of BPM
1) Receive step: abstract asynchronous interface used to receive a file
2) Receive step: abstract asynchronous interface used to receive a another file
3) Transformation step: To merge two messages.
4) Send step: To send merged message.
Here I have used three messages, which are Header info, Item info and Header Detail and referred them as Message1, Message2 and Message3 respectively. Messsage1 and Message2 are received by BPM. Message1 and Message2 do not have any common (key) field. Transformation step is used to combine Header info and Item info into Header Detail. Using file adapter, I am sending two files, which contain Header info and Item info.
Define a correlation under correlation list.
Switch to Correlation editor. And do the following: –
- Select the correlation.
- Define a Correlation Container.
- Mentioned Involved Messages.
- Define Properties for both the message as shown in Fig. 5.
Activate the Correlation in First Receive step and use correlation in Second Receive step. Properties windows of both the Receive steps are as follows: –
Follow the same procedure as shown in figure 5 to provide value to the correlation container.
Configuration in Integration Directory needs to be done as per standard configuration procedure, according to scenario.
Now we will see the runtime behavior of the above BPM.
File adapter will pick first file comprising the Header Info. It will trigger a BPM instance.
Now this BPM instance will be in wait stage, as it has to wait for the message for second receive step. When we paste the second file, which comprises of Item info, on ftp, file adapter will pick the file and BPM will execute thoroughly.
As we have seen in above example, we have used correlation for messages that do not have any common key fields. Hence by utilizing the constant, we can avoid the necessity of the common field in involved messages.
For the constant correlation, correlation will always be true. Hence there is a limitation of using Constant Correlation. It can be used only when we ensure that at a time only one BPM instance will be running. The reason behind it is, when second message will arrive at BPE then it will be delivered to all the running processes, as the correlation condition is always true for every instance.