BPM Process pipeline gets overwritten if multiple message of same type come in different order

Hello All,

We are using webMethods 9.9

We are facing an issue related to Intermediate messages merge in BPM’s. Please find the problem statement below.

? As described below, Assume that I have below messages in the process
• Initiate Message (Which initiates the BPM)
• Intermediate Message1 (Which comes and Joins as per correlation)
• Intermediate Message2 (Which comes and Joins as per correlation)
• In Runtime properties Express Pipeline is Unchecked

? We have pushed Initiate Message to BPM Queue and My process Initiated

  1. We have pushed Intermediate Message1 Once my process is reached to Message Event2 as described above. Now my process is reached to Message Event3.
  2. We have pushed Intermediate Message1 to Message Event4 when my process is waiting for Message Event3
  3. Now I have pushed Intermediate Message2 to continue my process from Message Event3.
    ? My process is completed as expected.

Now the problem is coming at step number 2. Since Express pipeline is not enabled and my Intermediated Message1 (For Step Message Event4) is sent before my process is reached to that point. Data which is available in Intermediate message 1 is getting over written with Intermediate Message1 which is pushed in Message Event2 in step number1 .

Usually My Problem should be resolved with Express Pipeline Enable. But even though the express pipeline is enabled, with specific Input and output signature. Still we are facing the same issue.

Do we have any issues with Express Pipeline in version 9.9. Can you please let us know whether any fix is provided from Software SG for these issues.

The Integration server has the following patches

  • OPT_9.9.0_Fix12

I have also attached the process image for reference

If any of the Above statements are not clear please do let us know on the same

The problem is IMO that the PRT (or, rather, the Designer when it builds and uploads the process model) can’t know that message1 should be dropped as you think it should. This is because it is used in the downstream.

Look into the generated fragment file, there you will see what is preserved after each step.

To make the process behaviour unambiguous you should drop message1 from the pipeline explicitly, e.g. via a dedicated process step.

Hm… Maybe you (or I) should scratch what I’ve written. The real cause might be that when you publish message1 for the first time, both steps waiting for it will be in the waiting state. When the process gets to the Event4 it already has data from the first publish. The second published message still sits in the step inbound queue, but the second incoming transition (Task2 → Event4) is never activated again.

thanks for your inputs but if you find something more which we can explore would be really appreciated.

Thanks for the inputs yap agreed to the point the BPM still gets triggered because the co-relation id is same for all events

We also tried to use express pipeline to see if we can use specific elements but even for version 9.9 express pipeline doesnt seem to behave the way it should as per documentation.

Also since all intermediate documents are referring to the same type so we tried changing the event type document but as you said might hold good .

Again if the BPM process engine orchestra-tor cannot handle this scenario might be a big tricky then the whole concept of orchestration in BPM add very less value except the work flow visualization . As the same can be handled as pure ESB flows as well except visualization.

I still remember an old saying on BPM
“BPM is a luxury to use not a basic necessity”

thanks again for looking into the issue and points you mentioned in case you find something more which we can explore would be really appreciated