BPMPatternCollectMessage

[former_member474221]

Hi

I am trying to understand the BPMpatternCollectMessage which is inside the SAP Basis SWC.

http://wiki.sdn.sap.com/wiki/display/ProcessCollection/BpmPatternCollectMessage+Explained+(Step+by+S...)

1. Here there is a FORK ( with 2 branches and  necessary branches  = 1 )

2. In one branch there is an infinite loop which keeps on collecting messages ( START messages )

3. There is a second branch which has a receive step which receives a STOP message...

     i.e. the collection of the START messages in first branch should stop when the STOP message in second branch arrives

4. Transformation step to collect the START messages and then SEND step

My question is -

1. here the correlation is defined between START message in the first branch and STOP message in second branch

    So a new BPM instance should be created only when the field ( ID ) of the START and STOP message is same

    So how  in this case a separate instance is created when field ( ID ) in one START message matches with another START message

   and not STOP message

2. What is the significance of "neccessary branches = 1 " as the fork will be completed only when the STOP message arrives...

     so neccessary branches = 2 should also work ....Isn;t it ??

[robertot4s · Accepted solution]

Hi,

Some of these patterns are difficult to understand...

About your questions:

1. Correlation:

     - A new instance should be created the first time a different ID is received (Activate Correlation).

     - Next times a START message arrives with the same ID, the same instance process the message (Use Correlation). In this case the Activate Correlation doesn't applies.

     - When a STOP message arrives with the same ID, this instance process the message and finish.

2. "Necessary braches = 1": This pattern collect messages until one specified message arrives (STOP message). This can be done in BPMN with events, but ccBPM doesn't have events 😞 So, the unique way to achieve this, is creating two branches:

     - First branch to collect the messages. This branch is infinite.

     - Second brach that receive the STOP message. This branch is the only one that could finish its execution.

The fork will be complete when a branch finish, and then the process will continue.

I hope this helps.

Regards,

Roberto

[former_member474221 · Accepted solution]

Hi Roberto,

That was a very useful answer...

One more query...

when we say that the necessary branch = 1....it means that fork can finish even if one of the branches get completed...

So in this case if a STOP message arrives first instead of START ....should not the FORK complete without waiting for the START messages ??  OR if the STOP message arrives first the FORK will still wait for the START messages

[robertot4s · Accepted solution]

Hi,

If the STOP message arrives first:

- With buffering: The STOP message will wait until the first START message arrives and creates the instance.

- Without buffering: The STOP message will fail.

Have a look to this document http://scn.sap.com/docs/DOC-16152

Regards,

Roberto

[former_member474221 · Accepted solution]

Hi Roberto,

Then will not keeping necessary branches = 2 be a better option ?

[robertot4s · Accepted solution]

Hi,

When the fork step starts, both branches are always executed. The "necessary branches" are the number of finished branches that the process needs to continue. With "necessary branches = 2" the process will not finish, because one of the branches never finish (the one that collects the messages).

Regards,

Roberto

[former_member474221 · Accepted solution]

Hi Roberto,

Will not the first branch with infinite loop finish when a  STOP message with matching ID arrives.

That means both the branch will complete when the ID in START and STOP message matches....Won't both the branches complete ?

[robertot4s · Accepted solution]

Hi Hema,

Yes, both branches finish at the same time when the STOP message arrives. But the infinitive loop finish because the condition of the fork is completed (necessary branches = 1).

With necessary branches = 1:

1. STOP message arrives -> branch complete

2. Fork's condition complete -> Every branch of the fork is finished (infinite loop finished)

With necessary branches = 2:

2. STOP message arrives -> branch complete

2. Fork's condition not complete -> Wait until the second branch (infinite loop) finish by its own, and this never will happen.

Thanks for the points!

Regards,

Roberto

[former_member474221 · Accepted solution]

hi Roberto,

One last question...

I tried with setting "buffering possible" for my BPM in SWF_INB_CONF still when I send the STOP message first ( where there is no active corelation ) it goes in error saying "there is no active correlation"

should not it wait for the START message ?

[robertot4s · Accepted solution]

Hi Hema,

I have read the document http://scn.sap.com/docs/DOC-16152 again and I was wrong. The message will fail because there isn't any queue created for this correlation ID. The buffering only works if the correlation was already activated.

So, in the case you are testing, the message will always fail.

Sorry about that.

Regards,

Roberto

[former_member474221 · Accepted solution]

Hi Roberto,

But when I go through the document your previous understanding seems correct -

Buffering possible - if there is no active corelated instance then the message will be buffered till it finds active instance

Without buffering - The message will fail with error " no corelated instance found "

If this is not correct than what is the use of buffereing ??

[robertot4s · Accepted solution]

Hi Hema,

From the document: If you choose the delivery mode “Buffering Possible” using transaction SWF_INB_CONF, all messages that fit to an active correlation are taken up by a running process instance. They are associated to a running process instance, regardless if there is or will be an active receive step in this process instance.

If your process receives lots of START messages at the same time, probably it needs buffering. In the document you have other use cases in 3.1.2.

You can test the buffering adding a wait step after the START messages receive step.

Regards,

Roberto