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

Оригинал блога: https://mainthing.ru/ru/item/328

Рассмотрим процессную диаграмму, позаимствованную мною (с некоторыми упрощениями) из книги 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.   В отсутствии стандартного способа ограничить распространение сигнала для реализации процессного паттерна «этап» следует использовать сообщения.