Events are both the most powerful component of BPMN and most difficult to learn. There are many types of events (more and more with each new versions of BPMN) and it’s not clear how, where and when to use each one. As a result not only users but also developers of BPM Suites make mistakes by implementing events not exactly as the standard prescribes.
There are two levels of understanding: 1) formal and 2) meaningful. Knowing the definition is one thing and knowing how the event of given type differs from others and what are the use cases is another.
In this article I will focus on the signal event.
Like messages, signals are used to synchronize and exchange information between different parts of the process. They differ from each other by the following:
- Message flow is drawn in the diagram explicitly by the dashed arrow while in the signal case the sender (”thrower”) and receiver (”catcher”) are linked implicitly by the signal name. That is, if there is a thrower signal (marked by a filled triangle) on a diagram labelled “we won”, then look for a catcher signal (non-filled triangle) with the same label on this and/or other diagrams .
- Messages can only pass between different pools (i.e. between different processes), there is no such limitation for signals.
- The most important difference: messages are point-to-point communcations: an instance of a sender process cummunicates to one specific instance of the receiver process (let’s forget about start events for simplicity). Accordingly for a process engine to be able to deliver a message, one must specify the process ID of the recipient - e.g. by a process attribute. A signal passes from one process instance to many: to all instances awaiting a signal of given name at the moment. Thus signals are broadcast messages.
OK, it was the formal part, now let’s go to the meaningfull one.
BPMN 2.0 standard comments: “A BPMN Signal is similar to a signal flare that shot into the sky for anyone who might be interested to notice and then react.” Well I’d prefer an example somehow related to the letter “B” in BPMN, i.e. to business.
I couldn’t find a case for signals for some time. The difficulty is that the sender must be unique in the sense that at any given time there can be only one instance of such a process. It should be a process that plays a special role in the life of the organization - a trigger for a number of other processes.
At the end of the day I’ve found examples of such processes in planning.
For example let’s consider a company accepting orders from clients. If the manager successfully agrees the terms and conditions with the client then a record is placed into production orders queue. A scheduling procedure starts at the evening of each day which analyzes the orders queued and calculates the production schedule for tomorrow. Upon completion of scheduling the process related to the client order receives a signal, notifies the client and perform other actions. A simplified case indeed yet very typical for planning.
The process diagram:
It can also be implemented by by messages but in that case we’ll have to send many messages - one for each client process instance - instead of one signal:
The diagram with signals has an advantage of being simpler but only at first glance.
Generally speaking, the incoming orders may excess the production capacity, in that case some orders would remain in the queue. To take this into account the client process must check whether the order is successfully scheduled and go back to waiting the signal if not:
You can see now that the complexity of two schemes are about the same, so it’s a matter of personal preference which one to choose.
Отлично написано, но событий там куча! будет еще что то про них?
А еще расскажите пожалуйста по какому принципу вы выставляете типы процессов.
Так это же здорово, когда куча событий! Как говорится, нет повода не выпить
В октябре я буду проводить тренинг по BPMN, там будет подробнее и про события, и про типы задач.
Анатолий, в процессе “От заказ до оплаты” перед действием “Отправить заказ в производство” стОит ли добавить промежуточное событие “Ждать запрос от производства”? Ведь отправка произойдёт лишь в конце рабочего дня…
Ещё вариант реализации примера - экземпляр процесса “От заказа до оплаты” после согласования заказа выдаёт сигнал типа “Есть согласованный заказ”, и тогда процесс “Планирование производства” обращается за согласованными заказами только к этим экземплярам процессов в конце рабочего дня (но он должен фиксировать полученные сигналы).
Третий вариант - после согласования все заказы помещаются в отдельное хранилище/буфер/очередь (можно реализовать отдельным процессом?), к которому в конце рабочего дня обращается процесс планирования и выбирает заказы согласно некоторым правилам (объёмы, приоритеты, сроки, …).
Чётвёртый вариант - сам процесс планирования может послать сигнал экземплярам процессов “От заказа до оплаты” о списке попавших в график заказов.
Сергей
В моей схеме заказ отправится в производство сразу после того, как он успешно согласован. Отправка эта заключается в том, что в таблицу базы данных “Очередь заказов” добавляется запись. А производство (диспетчер-планировщик) прочтет заказы в конце дня. Причем не один, а сразу все накопившиеся заказы. Это похоже на Ваш третий вариант, только без отдельного процесса (зачем он?).
По второму варианту: фиксировать полученные сигналы, и что с ними делать? Наверное, складывать в базу данных? А зачем так сложно, когда можно сразу складывать в базу безо всяких сигналов.
А.Б.
В третьем варианте я стал добавлять отдельный процесс для буфера как раз потому, что про записи в базу данных никакой информации на диаграммах нет (реализация при просмотре диаграммы неочевидна, а часто возникает вопрос, куда же делись заказы).
По второму варианту - просто ещё один из способов реализации, пусть и неоптимальный
За пример - отдельно спасибо!
Как это нет информации на диаграммах? А что означает data object, подписанный “Заказы на производство”, и входящие-выходящие в него стрелки?!
Это какое-то массовое умопомрачение: люди рисуют процессные диаграммы так, как будто кроме процессов ничего больше нет. Особо продвинутые добавляют еще сигналы. А как же данные? Они никуда не деваются, отказываться от баз данных никто не собирается, и это законный способ коммуникации между процессами.
а про тренинг можно поподробнее
Следите за объявлениями.
Очень интересные возможности могут открыться в будущем по использованию событий типа “сигнал”. На семинаре по “автоматизации процессов в вузе” вы говорили можно использовать стиль “каскад со смещением”, т.к работы не всегда выполняются по плану. Так вот управляющие сигналы смогут координировать действия при таком стиле выполнения. Например, запланировано сделать точно заказ к определенной дате, но он сделан на неделю позже. Можно выставить формальный диапазон ожидания, не плановый, а с запасом. В вузе по плану диплом на проверку надо сдать в определенную дату, но по факту сдают намного позже. Также ожидание сигнала может стать гарантией, что процесс все равно продолжится независимо от того когда пришел сигнал (это определенная страховка).
Ирина
Только не упускайте из виду принципиальный момент: сигнал шлется всем, кто его слушает, без исключения. Например, если 10 студентов из группы сдали курсовик на проверку, то реализовать при помощи сигнала ожидание оценки от преподавателя не получится, потому что сигнал от преподавателя получит не одна группа, а студенты всех факультетов и курсов, ожидающие оценку. Надо использовать сообщения.
В примере, разобранном в этой заметке, фокус в том, что процесс планирования принципиально один. Если же у компании несколько производственных площадок, планирование на каждой из которых выполняется независимо, то, опять-таки, использовать сигнал не выйдет.
А.Б.
Спасибо Вам за комментарий.