События (events) в нотации BPMN - одновременно и самая мощная, и самая сложная в изучении составляющая. Их много (все новые виды событий появляются в новых версиях BPMN), и сразу не очень понятно когда, как и для чего использовать то или иное событие. В результате не только пользователи, но и разработчики BPMS делают ошибки - реализуют события не так, как предписано стандартом.
Я бы выделил два уровня вопроса: 1) формальный и 2) содержательный. Одно дело - дать правильное определение, а другое - понимать, чем данный тип события отличается от других и в каких ситуациях им следует воспользоваться.
В этой заметке я остановлюсь на событии типа “сигнал”.
Сигнал, как и сообщение (message) служит для синхронизации и обмена информацией между разными частями процесса. Отличаются друг от друга они тем, что:
- Траектория сообщения явно рисуется на диаграмме пунктирной стрелкой (message flow), в то время как в случае сигнала источник и приемник неявно связываются друг с другом по имени сигнала. То есть если у вас на диаграмме (или на разных диаграммах) изображен источник сигнала (throw - закрашенный треугольник), под которым написано “мы победили”, то ищите приемник (catch - незакрашенный треугольник) с такой же подписью на этой и/или других диаграммах.
- Сообщения могут ходить только между разными пулами (читай - между разными процессами), а для сигналов такого ограничения нет.
- И самое главное различие: сообщение идет от точки к точке: от экземпляра процесса-отправителя к одному определенному экземпляру процесса-получателя (забудем на минуточку о стартовых событиях, start events). Соответственно, чтобы процессный движок смог отправить сообщение, необходимо задать идентификатор процесса-получателя - например, через атрибут процесса. Сигнал же идет от одного экземпляра процесса ко многим: ко всем экземплярам, ожидающих сигнала с данным именем в текущий момент. То есть message - это адресное, а signal - широковещательное сообщение.
ОК, с формальной стороной дела разобрались. А что с содержательной?
Стандарт BPMN 2.0 дает такой комментарий: “Сигнал BPMN похож на сигнальную ракету, выстрелянную в небо для любого, кому интересно ее увидеть и среагировать.” Я бы предпочел пример хоть как-то относящийся к букве “B” в BPMN, т.е. к бизнесу.
Я не сразу смог придумать применение для сигнала. Сложность в том, что отправитель обязан быть уникальным в том смысле, что в любой момент времени может существовать только один экземпляр такого процесса. Т.е. это должен быть процесс, играющий особую роль в жизни организации - роль координатора или триггера для множества других процессов.
В итоге я нашел примеры таких процессов в планировании.
Например, пусть компания принимает заказы от клиентов, менеджер согласует поступивший заказ с клиентом и размещает его в очередь производственных заказов. Ежедневно в конце дня запускается процедура планирования, которая анализирует поступившие заказы и рассчитывает производственный график на завтра. По завершению планирования все связанные с клиентским заказом процессы получают сигнал о том, что график составлен, и могут, например, уведомить об этом клиента. Постановка пусть очень упрощенная, но весьма типичная для планирования.
Процессная диаграмма:
Эту задачу можно решить и при помощи сообщений, но тогда вместо одного сигнала нам придется послать множество сообщений - по одному каждому клиентскому процессу:
На первый взгляд, вариант с сигналом выглядит проще, и это можно считать его преимуществом, но только на первый взгляд.
Ведь ввообще говоря, заказов может оказаться больше, чем мы способны произвести в течении дня, и тогда часть их останется в очереди. Чтобы это учесть, надо в клиентском процессе проверить, попал ли наш заказ в график и если нет, вернуться к ожиданию сигнала:
Как видите, схемы получаются примерно одинаковые по сложности, и какую из них предпочесть - дело вкуса.
Отлично написано, но событий там куча! будет еще что то про них?
А еще расскажите пожалуйста по какому принципу вы выставляете типы процессов.
Так это же здорово, когда куча событий! Как говорится, нет повода не выпить
В октябре я буду проводить тренинг по BPMN, там будет подробнее и про события, и про типы задач.
Анатолий, в процессе “От заказ до оплаты” перед действием “Отправить заказ в производство” стОит ли добавить промежуточное событие “Ждать запрос от производства”? Ведь отправка произойдёт лишь в конце рабочего дня…
Ещё вариант реализации примера - экземпляр процесса “От заказа до оплаты” после согласования заказа выдаёт сигнал типа “Есть согласованный заказ”, и тогда процесс “Планирование производства” обращается за согласованными заказами только к этим экземплярам процессов в конце рабочего дня (но он должен фиксировать полученные сигналы).
Третий вариант - после согласования все заказы помещаются в отдельное хранилище/буфер/очередь (можно реализовать отдельным процессом?), к которому в конце рабочего дня обращается процесс планирования и выбирает заказы согласно некоторым правилам (объёмы, приоритеты, сроки, …).
Чётвёртый вариант - сам процесс планирования может послать сигнал экземплярам процессов “От заказа до оплаты” о списке попавших в график заказов.
Сергей
В моей схеме заказ отправится в производство сразу после того, как он успешно согласован. Отправка эта заключается в том, что в таблицу базы данных “Очередь заказов” добавляется запись. А производство (диспетчер-планировщик) прочтет заказы в конце дня. Причем не один, а сразу все накопившиеся заказы. Это похоже на Ваш третий вариант, только без отдельного процесса (зачем он?).
По второму варианту: фиксировать полученные сигналы, и что с ними делать? Наверное, складывать в базу данных? А зачем так сложно, когда можно сразу складывать в базу безо всяких сигналов.
А.Б.
В третьем варианте я стал добавлять отдельный процесс для буфера как раз потому, что про записи в базу данных никакой информации на диаграммах нет (реализация при просмотре диаграммы неочевидна, а часто возникает вопрос, куда же делись заказы).
По второму варианту - просто ещё один из способов реализации, пусть и неоптимальный
За пример - отдельно спасибо!
Как это нет информации на диаграммах? А что означает data object, подписанный “Заказы на производство”, и входящие-выходящие в него стрелки?!
Это какое-то массовое умопомрачение: люди рисуют процессные диаграммы так, как будто кроме процессов ничего больше нет. Особо продвинутые добавляют еще сигналы. А как же данные? Они никуда не деваются, отказываться от баз данных никто не собирается, и это законный способ коммуникации между процессами.
а про тренинг можно поподробнее
Следите за объявлениями.
Очень интересные возможности могут открыться в будущем по использованию событий типа “сигнал”. На семинаре по “автоматизации процессов в вузе” вы говорили можно использовать стиль “каскад со смещением”, т.к работы не всегда выполняются по плану. Так вот управляющие сигналы смогут координировать действия при таком стиле выполнения. Например, запланировано сделать точно заказ к определенной дате, но он сделан на неделю позже. Можно выставить формальный диапазон ожидания, не плановый, а с запасом. В вузе по плану диплом на проверку надо сдать в определенную дату, но по факту сдают намного позже. Также ожидание сигнала может стать гарантией, что процесс все равно продолжится независимо от того когда пришел сигнал (это определенная страховка).
Ирина
Только не упускайте из виду принципиальный момент: сигнал шлется всем, кто его слушает, без исключения. Например, если 10 студентов из группы сдали курсовик на проверку, то реализовать при помощи сигнала ожидание оценки от преподавателя не получится, потому что сигнал от преподавателя получит не одна группа, а студенты всех факультетов и курсов, ожидающие оценку. Надо использовать сообщения.
В примере, разобранном в этой заметке, фокус в том, что процесс планирования принципиально один. Если же у компании несколько производственных площадок, планирование на каждой из которых выполняется независимо, то, опять-таки, использовать сигнал не выйдет.
А.Б.
Спасибо Вам за комментарий.