Skip to Content

Correlation – Runtime Behavior of BPM.

Correlation is a very important feature of BPM. It is often used in scenarios where more then one systems are delivering data to XI. I have come across different runtime behaviors of BPM with respect to correlation. With the help of this blog I would like to share my experience about this behavior of BPM.


I have taken a very basic scenario to explain this concept.

Two files are delivered to XI. First file consists of Employee PsNo and Name while the second file consists of PsNo, Salary and Cadre. In this scenario both the information is merged based on the PsNo and delivered in form of third file to the ftp

  imageBPM Design:- 

Step 1) First receive Step:- abstract asynchronous interface to receive first file.

Step 2) Second Receive Step:- abstract asynchronous interface to receive second file.

Step 3) Transformation Step:- To merge the files received in the first and the second step.

Step 4) Send Step:- abstract asynchronous interface to send the merged file.




We know that whenever a receive step is encountered a process instance is generated.

But, in this case we have two receive steps. We want to have the same process instance for both the receive steps. Hence we need to correlate the data that is received in first and second receive step.


Steps to define correlation:-




Switch Container window to Correlation List.

Define a Correlation Name in the Correlation List.


Step 2)


Switch the Graphical Definition to Correlation Editor.

Select the Correlation Name that you defined in the previous step.

Define a variable in the Correlation Container. Its type should be same as that of the field on which you want to define the correlation.

Select the message interfaces on which you want to define correlation in the Involved Messages area.

In the Properties area, for each message interface that is involved select the field from the message type for which you want to define correlation.




We will now see the runtime behavior of BPM.


Case 1:-


In this case the first file is placed on the ftp. As the First Receive step is encountered a process instance for the BPM is triggered. As the second file is not yet placed on the ftp the Second receive step will wait for the file and hence the BPM appears in the wait state.

Go to SXI_MONITOR  to check the status of BPM.




When the second file (with the same PsNo as that of First file) is placed on the ftp, a new process instance would not be triggered, instead the file is delivered to the Second receive step. This is possible because of correlation. The data is then merged in the mapping and the merged file is placed on the ftp.





Case 2:-


In this case the second file is placed without the first file being placed on the ftp. The file adapter picks up the second file. However as there is no process instance triggered for this file by the first receive step, message will go into SYSFAIL.






Case 3:-


In case if both the files have different PsNo, and the first file will be placed before the second file, a process instance will be triggered for the first file but it will keep waiting for the second file and the BPM will appear in the wait state. The file adapter will pick up the second file but the message will go into SYSFAIL as no process instance is triggered for it.




This behavior is encountered because the correlation is defined on the field PsNo.

You must be Logged on to comment or reply to a post.