In the previous post we considered a message from external entity that needs to be processed to determine which process instance it should be routed to. But at least there were no incertainity about which process template (process type) the message corresponds: client requests a credit card from a clerk (credit card issuance process), CV arrives to Human Resources (enrollment process), payment notification reaches Finance (sales process).
Now let’s consider more complicated case: documents arrive to the company’s post address by traditional mail. They don’t reach process participant’s desk directly but go to the general administration office.
Fig.1 Client’s documents magically reach “his” process.
As we found in the previous post, there is an implication at the diagram on fig.1: it should be figured out somewhere which particular process instance the arrived documents are for - a simple yet necessary activity.
Fig.2. “Incoming Processor” pattern: which process instance are these documents addressed to?
The easiest way to identify the request is by the reference number in the accompanying client’s letter. If there is no accompanying letter (we should be prepared for this scenario) then we should just look at the sender - probably we have just one active request from this client. If there are more than one then requests attributes should be compared with the documents received. Generally speaking, successful identification isn’t granted - e.g. the documents could arrive when the main credit process has timed out.
But who will obtain the documents sent by the client - right the performer of the credit process? Sometimes this is the case - it may go this way when adressee’s name and department are specified on the envelope. But we can’t be sure about it: the addressing may be wrong or incomplete, the case could be reassigned to other performer. In the general case documents will arrive to the bank’s administrative office.
Fig.3. Which messages relate to the process A and which ones to the process B?
The implication of the scheme on fig.3: when the office receives a letter saying “please provide a credit for our company…” there is no writing on the envelope saying that this is a start message for credit request process. An incoming letter or documents package is all the office worker can see at first glance.
Fig.5. “Post Office” pattern: centralized processing of all inbound and outbound correspondence.
One more thing: it’s better to use BPMN signals instead of messages in communications between the Post Office and applied processes, as depicted on fig.5.
Let me remind that signals are a sort of broadcast messages: unlike messages, they are sent not to a single process instance but to all processes awaiting it at the moment. But this aspect doesn’t matter in this case because we are dealing only with start events.
There is another reason to use signals: they provide late binding. When messages are used, one should specify sender and receiver processes at design time. In case of signal receivers are determined at run time - when it was fired. So if messages were used all processes would become interconnected via the inbound docflow; signals let us create independent diagrams for each fragment separated by dashed lines on fig.5.
First, it’s not always possible to replace original with copy.
More importantly, we are not in position to say to business “your procedure is too cumbersome, I can’t implement it with BPMN/BPMS so you have to streamline it”. Sure you may and should warn business that implementing the procedure this way would be harder and more expensive but it should be doable.
Never give lightweight advices to business - it has issues to solve and compromises to find while dealing with matters more complicated than BPMN.
The case considered above was raisied by a student at my BPMN training. Well it wasn’t a bank but a company that have a lot of mail exchange with different regulation bodies. All this mail goes in a very traditional way and changing it means re-educating all this government offices. The company don’t need this kind of optimization, thanks a lot.
Анатолий, а если клиент не вставит «в ответ на ваш исходящий № …», то организовывается процесс “Разбирательство……”. Я правильно понял?
Конечно. То, что я нарисовал,- это голая схема, скелет. “Идентифицировать тип документа” можно (и нужно, если мы решаем реальную бизнес-задачу) превратить в подпроцесс и накрутить в нем бизнес-логику, эскалации и т.п. По принципу “были бы кости, а мясо нарастет”. То же самое с идентификацией экземпляра процесса в Обработчике входящих.
It sounds to me like: Anatoly, i’ve noticed that you have two ears. Have a dobry day.
В последней схеме ивенты сигналов отправителя и получателя должны быть названы одинаково.
И еще: обработчик событий посылает сигнал о поступлении дополнительных документов в процесс А. И при этом ВСЕ процессы А срабатывают на этот сигнал.
По поводу названий: спасибо за замечание, это погрешность перевода с английского на русский.
По поводу сигнала: он принимается *стартовым* событием, какие тут “все процессы А”?
Сорь, с сигналом ошиблась: для старта процесса работает. Перепутала с промежуточным событием.
Возможно, я не до конца понимаю сути задачи, но у меня вопрос следующий: А что, если типов процессов А и В будет не два, как в этом примере, а много больше, как в реальной жизни. Мало того, эти типы процессов меняются (дополняются и изменяются) часто. Все время помнить о том, что в процессе на рис 3 под названием “Входящий документооборот” необходимо поддерживать исходящие от развилки ветки в актуальном состоянии довольно проблематично. Есть ли паттерн проектирования, который помог бы избежать подобного затруднения?
Смущает использование артефакта Data Object для “БД исходящих документов”. Разве это не должно быть Data Store? Как я понимаю DO существует только в период жизни экземпляра процесса (в данном случае процесса “Исходящий документооборот”), а нам нужно получить доступ к информации об уже отправленном исходящем документе, т.е. вне периода жизни экземпляра процесса. ИМХО в этом случае уместно использовать DS. Разве нет?
Абсолютно справедливое замечание, в BPMN 2.0 дело обстоит точно так, как Вы написали.
Просто на момент написания этой заметки Bizagi Modeler поддерживал только BPMN 1.2. В рамках этой версии все изображено корректно.