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

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

Предупреждение об использовании сигналов BPMN

Рассмотрим процессную диаграмму, позаимствованную мною (с некоторыми упрощениями) из книги Stephen White, Derek Miers, “BPMN Modeling And Reference Guide” (стр. 113):

Диаграмма иллюстрирует фрагмент процесса создания книги. Процесс распадается на два подпроцесса, исполняемых параллельно: написание текста и разработка обложки. Причем обложку можно начать делать только после того, как автор определился с концепцией книги.

Сложность тут в том, что мы не можем реализовать эту логику при помощи потока управления (sequence flow), так как он не может пересекать границы подпроцессов. (Оставим в стороне вопрос зачем нам тут понадобились подпроцессы; будем считать, что зачем-то они нужны.) Сообщения (message) использовать тоже нельзя, так как мы находимся в пределах одного пула.

Стандартная рекомендация - использовать в подобной ситуации механизм сигналов BPMN (signal event):

  • когда концепция готова, первый подпроцесс шлет соответствующий сигнал
  • второй процесс до этого момента находится в ожидании сигнала; получив его, он переходит к задаче “Разработать дизайн обложки”

Это так называемый процессный паттерн “этап” (milestone). Аналогичный пример использования сигнала BPMN приведен в книге Bruce Silver, “BPMN Method and Style” (стр. 98).

В чем тут подвох?

Пока мы рассматриваем написание одной книги (один экземпляр процесса), все в порядке. Но предположим, что одновременно в работе находится несколько книг. Вспоминаем, что сигнал BPMN - это широковещательное сообщение, которое получают все, кто его ожидают в данный момент. Значит, как только будет готова концепция первой книги, дизайнеры всех книг получат сигнал о том, что можно приступать к работе над обложкой - явно не то, чего мы ожидали.

Для того, чтобы приведенная диаграмма сработала, нам необходимо как-то ограничить распространение сигнала. Как это можно было бы сделать?

  1. Первое, что приходит в голову - предусмотреть атрибут сигнала, который будет ограничивать его распространение границами данного экземпляра процесса. Но к сожалению, такого атрибута стандарт не предусматривает. Причем если в рамках BPMN 1.x еще можно сказать, что это вопрос реализации, то в BPMN 2.0 метамодель процесса специфицирована полностью. Смотрим страницу 281 документа OMG, датированного июнем 2010 г.: у сигнала есть единственный атрибут - имя. Значит, сигнал всегда будет распространятся по всем экземплярам процесса.
  2. Что ж, раз у сигнала есть только имя, то будем использовать то что есть. Рассматриваемая схема сработает, если мы сможем динамически, т.е. в процессе исполнения процесса, задать его имя. Если имя сигнала будет не “Концепция готова”, а “Процесс 9999 Концепция готова”, то все будет в порядке. Но это, конечно, приемчик так себе, и рассчитывать на него сложно. Движки BPMS позволяют что-то менять в процессе исполнения (например, задавать время срабатывания таймера), но название - вряд ли.

Почему это важно.

В зависимости от того, можем мы или нет использовать сигналы для координации потоков внутри одного экземпляра процесса, мы должны ориентироваться на ту или иную процессную архитектуру:

  • если распространение сигнала можно ограничить, то можно смело использовать подпроцессы - если возникнет необходимость их синхронизовать, это можно будет сделать при помощи сигнала
  • если сигналы распространяются неограниченно, то единственный вариант - запускать для каждой ветви отдельный процесс (благо процессы можно синхронизовывать при помощи сообщений), примерно так:

Выводы:

  1. В стандарте BPMN не хватает атрибута, ограничивающего распространение сигнала.
  2. В отсутствии стандартного способа ограничить распространение сигнала для реализации процессного паттерна “этап” следует использовать сообщения.
05.11.10 | Статьи | , , ,    

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

  1. Thomas Allweyer 05.11.10 15:33

    Yes, it is strange that you can synchronize two separate processes, but not two sub-processes within the same parent process.

    I don’t like the workaround with separate pools, because this is rather artificial if you actually want to model one process. It also adds complexity, since you need to use a correlation mechanism. Communication within the same instance can be accomplished more easily, e.g. by using process variables.

    How about this workaround: Use a conditional event instead of the catching signal event. In the upper process you don’t need a throwing event, or you use a none event just to mark the place where the concept reaches the ready state. The actual communication would take place by a flag attribute that is defined in the parent process. Variables defined in the parent process are visible in all sub-processes. “Develop book concept” would set the “concept ready” flag to true, and the conditional event which has waited, would be triggered.

    I agree that it would be good to have an attribute in the signal event that could be used for correlating the signal to a specific process instance. Of course, you could define your own attribute using the BPMN extension mechanism. However, this again is an individual extension, but not the standard. I would like to draw a line between such signal events that are bound to a specific instance (maybe a specific type of association). After all, you can draw a line for the message flow so that you can connect the corresponding message events of different processes. The same should be possible for sub-processes (equal rights for sub-processes …!).

  2. Anatoly Belychook 05.11.10 22:23

    Thomas

    Thank you for valuable input. I like the idea to use conditional event.

    The separate pool workaround is artificial indeed but let’s take into account that the whole case is artificial. There is no real need to use subprocesses here hence launching external processes looks like an overkill.

  3. Anatoly Belychook 05.11.10 23:15

    But look, with the conditional event we fall into the same trap. The “concept ready” flag won’t help by the same reason as the “concept ready” signal. The “process 9999 concept ready” would work but you’ll need to create a business rule dynamically which may be a non-trivial task.

  4. Thomas Allweyer 06.11.10 11:56

    According to the BPMN specification, a conditional event has an expression which can be used for this purpose. If a signal is regarded as something that is usually independent from a certain process instance, the assignment to a specific instance may indeed be non-trivial. However, if we define a process instance variable “concept ready” in the parent process, the rule of the condition event is rather simple: It triggers when “concept ready” becomes true. There is no need to identify the right process instance, because a process instance variable always exists in the context of a process instance.

    Well, I just looked it up in the spec: There is only one instance variable in the spec: “state”. However, you can assign data to a process instance via data input and output, so it’s possible to solve the problem as I state above.

  5. Anatoly Belychook 06.11.10 12:17

    Guess you are right. The BPMN 2.0 spec says:

    “The Condition Expression of a Conditional Start Event MUST NOT refer to the data context or instance attribute of the Process (as the Process
    instance has not yet been created). Instead, it MAY refer to static Process attributes and states of entities in the environment. The specification
    of mechanisms to access such states is out of scope of the standard.”

    So it’s safe to assume that unlike a start event expression, intermediate conditional event expression may refer to the process instance attributes.

  6. Denis Oleynikov 15.11.10 16:01

    Good day :) What about using Link, like in pattern WCP-18 (site http://diveintobpm.org/index.jsp)?

  7. Anatoly Belychook 15.11.10 16:22

    Denis

    Thank you for the good question.

    Link event doesn’t add anything to the process semantic, it’s just a way to represent a process graphically. One can draw a sequence flow from Task3 to the parallel merge on the diagram you refer as well. Both ways will work for this process indeed but in our case we are trying to synchronize different subprocesses. Links won’t help here: a pair of links creates a virtual sequence flow so it’s plain wrong to place them at different process levels or in different processes.

    A.B.

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

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