В своей недавней заметке Брюс Силвер поделился соображениями относительно условного события в BPMMN.

Для тех, кто недостаточно погружен в BPMN 2.0, условное событие ставит процесс на паузу до того момента, как заданное логическое условие становится истинным (точнее, меняет свое значение с “ложь” на “истина”). Сейчас на дворе октябрь, так что вот вам подходящий пример стартового события-условия:

Рис. 1. Пример стартового события-условия.

Процесс стартует, когда указанное логическое условие становится истинным, т.е. когда зима вступает в свои права. (К слову, это реальное правило, действующее в Москве.)

Типичный пример промежуточного события-условия::

Рис. 2. Пример промежуточного события-условия.

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

Брюс пишет, что он предпочитает не пользоваться событием-условием и исключил его из “Method and Style” - сборника лучших практик моделирования, который он создал, поддерживает и рекламирует своей знаменитой книгой (лучше книгой по BPMN, на мой взгляд).

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

Мы начнем сценарии моделирования процессов для целей автоматизации, а затем рассмотрим моделирование для целей регламентации.

Брюс аргументирует свою позицию следующим образом:

1. Промежуточно событие-условие, базирующееся на данных процесса, в большинстве случаев избыточно, т.к. его можно заменить развилкой, что является более интуитивно-понятным и потому предпочтительным решением.
2. Чтобы от события-условия была какая-то реальная польза, оно должно базироваться на данных вне контекста процесса. Однако спецификация BPMN оставляет вопрос о механизме обращения к таким данным за рамками. Брюс интерпретирует “оставить за рамками” как некую магию, а магии в солидной методологии конечно же нет места.
3. Срабатывание события-условия можно было бы привязать к хранилищу данных потоком данных, но такую связь можно устанавливать только внутри процесса, по крайней мере в моделере Trisotech. (Брюс в течение нескольких лет продуктивно сотрудничает с этой компанией.)

Я полностью согласен с первым аргументом, но довод относительно магии мне представляется сомнительным. Я считаю, что одним из базовых допущений BPMN является то, что 1) существует некоторая информационная среда помимо собственных (транзакционных) данных процесса, 2) процессные данные каким-то образом связаны с сущностями в этой среде (например, внешними ключами БД, глобальными идентификаторами, бизнес-идентификаторами и т.п.) и 3) существует некоторый механизм доступа к этим данным (например, SQL select или вызов сервиса oData). Было бы странным разъяснять это в каждом разделе стандарта, поэтому я предпочитаю трактовать фразу в стандарте “the specification of mechanisms is out of scope of the standard” как “используйте подходящий механизм”.

Третий аргумент относится скорее не к логике моделирования, а к конкретному программу обеспечению. Действительно, существующие средства моделирования BPMN не очень хорошо умеют обращаться с событиями-условиями. Я бы хотел, чтобы вендоры позволили изображать потоки данных от хранилища данных к событию так, как показано на этом фрагменте, сделанном в Visio:

Рис. 3. Событие-условие, срабатывающее по изменению данных в хранилище.

К сожалению, пока этого нет. Весьма популярный Bizagi Modeler в принципе не позволяет соединять поток данных с событием-условием. Другой популярный инструмент bpmn.io изображает поток данных в обратном направлении:

Рис. 4. Изображение события-условия в bpmn.io (ошибочное).

К слову, моделеры BPMN к сожалению не позволяют также прикреплять потоки данных к пулам-”черным ящикам”, как на рис. 11 ниже.

Чем же может быть полезно промежуточное событие-условие? Рассмотрим бизнес-сценарий, схожий с тем, который использовал Брюс:

1. Клиент присылает запрос на обслуживание.
2. Менеджер рассматривает запрос, и если он его одобряет, то создается счет, который отправляется клиенту.
3. Если в течении срока действия счета проходит платеж, процесс переходит к оказанию услуги, в противном случае завершается.
4. Теперь самое интересное: предполагается, что клиент оплачивает счет банковским переводом. Наш финансовый отдел регулярно (например, дважды в день) запускает программное обеспечение клиент-банк и получает выписку исходящих и входящих платежей - таким способом наша компаний узнает, что клиент оплатил счет.

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

Взаимодействие через событие-сообщение

Этот способ самый популярный, он же - единственный известный новичкам.

Рис. 5. Взаимодействие через событие-сообщение.

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

Такой алгоритм не очень надежен, поскольку клиент мог не указать номер счета в платежном поручении, что в реальной жизни случается достаточно часто. Обычно в такой ситуации платеж можно идентифицировать по названию/ИНН плательщика и сумме платежа. Чтобы реализовать такую более продвинутую бизнес-логику, процесс обработки выписки банка должен иметь доступ к счетам, что означает межпроцессное взаимодействие через общие данные:

Рис. 6. Взаимодействие через события-сообщения и общие данные.

Хранилище данных “выставленные счета” можно реализовать, например, с помощью таблицы базы данных, содержащей все атрибуты, с помощью которых можно идентифицировать платеж (номер счета, название клиента, номер заказа, сумма счета и т.д.), а также идентификатор экземпляра процесса, который будет использоваться в качестве корреляции.

Взаимодействие через событие-сигнал

Рис. 7. Взаимодействие через событие-сигнал (ошибочное).

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

Взаимодействие через событие-условие

Рис. 8. Взаимодействие через событие-условие.

Центральную роль здесь играет хранилище данных “Выставленные счета”, которое может быть реализовано, например, одноименной таблицей БД.

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

Процесс обработки выписки банка использует эту таблицу чтобы идентифицировать платеж и, в случае успеха, чтобы присвоить атрибуту статус значение “оплачено”, что вызовет срабатывание триггера во клиентском процессе.

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

Fig. 9. Multiple messages.

С архитектурной точки зрения это не очень хорошо: какое вообще дело процессу обработки выписки банка до того, как устроен процесс обработки клиентского заказа? Если в какой-то момент у нас появится еще одно бизнес-направление, придется вносить правки в процесс обработки выписки?

Это фундаментальная проблема сообщений в BPMN: они приводят к тесно связанным диаграммам. Вы не можете просто отправить сообщение - вы должны показать в какой процесс и в какой элемента процесса оно должно попасть.

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

Рис. 10. Сторона-инициатор взаимодействия.

Рис. 11. Сторона-обработчик.

Мы можем развить этот пример дальше, так что у нас появится не только несколько процессов-обработчиков, но и несколько процессов-инициаторов. Это произойдет, если мы дополним платеж банковским переводом альтернативными методами. Такое расширение задачи не приведет к усложнению - хранилище данных останется единственной точкой взаимодействия, о которой надо знать каждому из процессов.

Неисполняемые модели

До сих пор мы говорили об исполняемых моделях, т.е. обрабатываемых процессным движком.

Относительно неисполняемых моделей Брюс замечает, что для них данные процесса не определены. А поскольку событие-условие по определению имеет дело с данными, в таких моделях его стоит избегать.

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

Я раньше уже объяснял, что событие-условие можно реализовать комбинацией развилки и таймера. Вот как это может выглядеть:

Рис. 12. Неисполняемая модель: событие-условие заменено задачей, развилкой и таймером.

Хранилище данных “счета выставленные” можно реализовать множеством способов, начиная с SAP и заканчивая сетевым Excel и канбан-доской.

Рис. 13. Пример канбан-доски.

Выводы

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