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

Выводы:
- В стандарте BPMN не хватает атрибута, ограничивающего распространение сигнала.
- В отсутствии стандартного способа ограничить распространение сигнала для реализации процессного паттерна “этап” следует использовать сообщения.