Главное не результат, главное процесс

BPM-блог Анатолия Белайчука

Еще одно предупреждение относительно сообщений в BPMN

Пусть процесс A шлет сообщение (BPMN message) процессу B. Вопрос: что будет, если процесс A хронологически отправит сообщение раньше, чем процесс B будет готов его принять, т.е. раньше, чем поток управления достигнет B2?

Варианты ответа:

  1. Отправленное сообщение пропадет, и B будет ждать следующего сообщения, которое, вероятно, не придет никогда.
  2. Процессный движок сохранит отправленное A сообщение, и B получит его, когда будет готов.

Спецификация BPMN 2.0 ответа на этот вопрос не дает, производители BPMS во взглядах разделились.

В этой ситуации, если аналитик хочет оставаться в рамках чистого BPMN, ему лучше следовать варианту (1) как более безопасному, по принципу “что не обещано - на то нельзя полагаться”.

Что в связи с этим хочется заметить.

Первое: используемый в BPMN маркер в виде конверта вводит в заблуждение. Ведь конверт, отправленный обычной почтой, будет лежать в почтовом ящике, пока кто-то его оттуда не достанет, то есть это вариант (2). Более подходящей визуальной метафорой для BPMN-сообщения была бы телефонная трубка: если в момент звонка адресата нет на месте, звонок пропадет - это соответствует варианту (1).

Второе: постарайтесь полностью исключить возможность ситуации, когда сообщение отправляется раньше, чем получатель готов его принять.

Следующий пример относительно безопасен - процесс B переходит к ожиданию ответного сообщения от A незамедлительно:

Теперь предположим, что процесс B должен продолжить работу после того, как выполнена какая-то собственная активность B2 и получен ответ от A:

Такая схема не безопасна: если выполнение B2 затянется, ответное сообщение от A может пропасть, и процесс B навечно зависнет на шаге B3.

Поэтому лучше так:

Или так:

Ссылки:

22.01.13 | Статьи |    

Комментарии (7)

  1. Scott Francis 23.01.13 02:18

    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 23.01.13 08:36

    Scott

    Sure it’s the best solution.

  3. Bruce Silver 26.01.13 03:49

    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 26.01.13 10:33

    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 05.02.13 16:20

    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. Вадим 13.11.14 18:17

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

  7. Anatoly Belychook 13.11.14 18:23

    Можно и так.

Комментирование закрыто

Copyright © 2008-2024 Анатолий Белайчук. Спасибо Wordpress и Yahoo.  Контент  Комментарии