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

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

Внимание, тест!

Вопрос: какие элементы BPMN позволяют моделировать межпроцессное взаимодействие (отметьте все правильные варианты ответа) -

1. поток управления (sequence flow)
2. сообщение (message flow)
3. сигнал (signal event)
4. триггер по данным (conditional event)
5. ассоциация (association)

Ответ: кликните, чтобы увидеть правильные варианты ответа

Комментарии к ответам:

» читать дальше

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

Небольшое дополнение к предыдущей заметке “Применение для сигнала BPMN“.

Отмеченная в ней специфика события типа “сигнал” - получение сигнала всеми экземплярами процесса-получателя, находящимися на шаге ожидания данного сигнала - относится к промежуточным событиях (intermediate event).

В случае стартового события (start event) все более спокойно: в одном процессе инициировали сигнал, в результате какой-то другой процесс стартовал. Правда, возникает вопрос: зачем тут использовать сигнал, когда то же самое можно сделать сообщением?

Во-первых, сигнал позволяет инициировать не один, а несколько процессов.

Во-вторых, у схемы с сигналом есть концептуальное преимущество:

• Пусть определенный сигнал, инициированный процессом А, вызывает старт процесса Б.
• Теперь вспомним, что BPM - это не просто управление бизнес-процессами, а управление процессами, меняющимися во времени, и предположим, что мы решили назначить обработчиком сигнала процесс В вместо процесса Б.
• В схеме с сообщением получатель указан в процессе А, т.е. чтобы заменить обработчик, нам придется изменить схему А. При этом возникнет проблема: что делать с уже запущенными экземплярами А?
• В схеме с сигналами мы просто инсталлируем процесс В и деинсталлируем Б. Менять схему А не требуется, проблем с запущенными экземплярами А не возникает.

Таким образом, сигнал позволяет реализовать позднее связывание: обработчик можно назначать и переназначать не на этапе разработки, а на этапе исполнения.

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

Я бы выделил два уровня вопроса: 1) формальный и 2) содержательный. Одно дело - дать правильное определение, а другое - понимать, чем данный тип события отличается от других и в каких ситуациях им следует воспользоваться.

В этой заметке я остановлюсь на событии типа “сигнал”.

» читать дальше