Process Is The Main Thing

@ Anatoly Belaychuk’s BPM Blog

Another Warning About BPMN Message

A process A sends BPMN message to a process B. What if A sent the message before B has become ready to receive it, i.e. before a token arrived to B2?

Possible answers:

  1. The message will be lost and B will wait for the next message, probably forever.
  2. Process engine will store the message sent and B will receive it when ready.

BPMN 2.0 doesn’t provide an answer. BPMS vendors didn’t come to consensus - some follow (1), others (2).

Under such circumstances if an analyst wants to stay within pure В, he/she should better follow (1) as a safer option: “not promised - can’t rely”.

Couple of thoughts on the matter.

1. The envelope-like BPMN marker is misleading. An envelope sent by convenient mail will wait in the mailbox until someone would get it from there - it’s behavior  (2). A phone-like marker would be more adequate: if an addressee didn’t accept the call, it’d be lost - it’s behavior  (1).

2. Try to completely avoid a situation when message is sent before an addressee is ready to receive it.

The next example is more or less safe - process B jumps to awaiting response message without delay:

Now let’s assume that B should continue as soon as some activity B2 is over and response from A is received:

It’s not safe: if B2 delays, the response message could be lost and B would be stuck at B3 forever.

So it’s better this way:

Or this:

Links:

01/22/13 | Articles |    

Comments (7)

  1. Scott Francis 01/23/13 02:18 AM

    Interestingly, IBM BPM makes this a configuration option for the listener. I don’t think the way the listening is configured is “right” from a style perspective, but it is basically functionally complete. You can model for either listening only to messages sent after you arrive at the listener, or you can model for listening to messages that may have arrived before you arrive at the listener. (option 1 or 2 - either one can be handled).

    Sometimes the genius of the “and” is the right answer :)

  2. Anatoly Belychook 01/23/13 08:36 AM

    Scott

    Sure it’s the best solution.

  3. Bruce Silver 01/26/13 03:49 AM

    Are there really engines that follow 1? I think queuing of the message is assumed. Also, I believe that Process A implicitly does not know the state of Process B. If knowledge of the state is required, better to use shared data (data store) than message.

  4. Anatoly Belychook 01/26/13 10:33 AM

    Bruce

    There are systems that implement only (1), there are systems that implement only (2), there are systems that let user to choose between (1) and (2), there are systems that let user set up the expiration time for the message - setting it to zero means (1). The funniest part is that all these vendors are members of BPMN standard committee.

    From pure modeling perspective I don’t think queueing is a good idea. The reason is this: if we assume queueing for messages then it’d be logical to expect the same for signals - if the process B came late to signal catcher event then it might get it from the queue just as a message. But this would be obviously a bad idea because a signal may be received anywhere - shall we keep the signal in the queue forever? Therefore signals must be synchronous; messages should better too for the sake of consistent behaviors of messages and signals.

    Communication via data is of limited use here because it doesn’t generate an event. Well there is a conditional event in theory but I didn’t see it implemented in a process engine yet.

  5. Bernd Ruecker 02/05/13 04:20 PM

    We currently support both possibilities in some way. But the interesting question in scenario 2 is: What happens if the process now will never catch the message from the queue (because it took a different path, it was canceled, correlation was corrupt, ….). I think this is hard to solve in a generic way serving all use cases.

    But it is a pretty important discussion when going down to implementation details. We therefor described exactly that pattern in our book as well.

    But actually I like the idea of having a phone icon instead of a message :-)

  6. Вадим 11/13/14 06:17 PM

    А если в ProcessB расположить B1 не на одной из линий потока управления, выходящих из шлюза, а на линии, входящей в этот шлюз?

  7. Anatoly Belychook 11/13/14 06:23 PM

    Можно и так.

What do you think?

Captcha

Copyright © 2008-2014 Anatoly Belychook. Thanks to Wordpress and Yahoo.  Content  Comments