Skip to Content

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.

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.

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.

 

image

Fig.1

 

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.

image

Fig.2

 

Define a correlation under correlation list.

image

Fig.3 

 

Switch to Correlation editor. And do the following: –

  1. Select the correlation.
  2. Define a Correlation Container.
  3. Mentioned Involved Messages.
  4. Define Properties for both the message as shown in Fig. 5.

image

Fig.4 

 

image

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: –

image

Fig.6

 

image

Fig.7

 

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.

Runtime

File adapter will pick first file comprising the Header Info. It will trigger a BPM instance.

image

Fig.8 

 

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.

image

Fig.9

Conclusion:-

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.

To report this post you need to login first.

6 Comments

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

  1. Prateek Raj Srivastava
    Nice work Sami.
    This is an easy to understand technique that is often overlooked by developers.
    The most important was the conclusion where you have clearly mentioned the limitation of using this.

    Best Regards,
    Prateek

    (0) 
  2. Beena Thekdi
    simple and easy solution!!!
    One may think of using context object using interface name and service name but  same result can be achieved easily using constants…great solution.
    (0) 
    1. Samiullah Qureshi Post author
      Ron,

      You are right, timing is most important here. Thats why I mentioned in the conclusion that use “constant correlation” very carefully as correlation is true for every running BPM instances when second message will arrive at BPE.

      Sami

      (0) 

Leave a Reply