Let’s consider the credit card issuance process:
Fig. 1. Credit card issuance with a “passive” task “Issue card”.
Business scenario: after the card is manufactured, the client must come to the bank branch within 45 days and request it. Now look at the task “Issue card”: if the average client comes in for the card after 10 days and the branch issues 100 cards per day then 1000 of these tasks will queue into bank clerk’s task list.
What’s worse, the clerk cannot actively execute this task. The client must come to the branch and request the card first and it’s beyond clerk’s control. Generally speaking, this is bad practice - a user should be able to actively execute the task assigned to him.
In order to get rid of the passive task an event catcher should be added to the diagram, the event being client’s card request message:
Fig. 2. “Request” message is sent to unidentified process instance.
But here is the question: how would the message from client John Smith find its way into specific process instance associated with him? Let’s not forget that there are about thousand of instances behind the single pool “Credit card issuance” shown in the diagram.
There is no such routing problem with the message “Application” because the process start isn’t a part of a process instance, it’s rather a unique “process factory”.
But when a message is sent into the middle of a process (i.e. to the intermediate event) one must specify the process instance ID. Moreover, the process instance ID is the internal BPMS data so we can’t expect that a message from an external entity (from collapsed pool on a BPMN diagram) would contain it explicitly. In our case it’s just client’s words “hello, I want my card.”
So before sending a message to the card issuance process that will activate “Issue card” task we must ask client’s name and maybe also his date of birth and / or passport number and find a particular process instance matching these data.
This is done within a separate process “Credit card request”:
Fig. 3. “Credit card request” process is an example of “Incoming Processor” pattern.
How it may look in practice: a clerk enters client’s data into the form, the system scans the issued cards databases for the record matching client’s data, fetches the process instance ID from the record found and forward the message to this instance.
Note that a positive search result is not guaranteed: the client may come to our bank by mistake or more likely to come too soon. In both cases the “Credit card request” process ends without sending a message.
Summary: The message from an external entity in BPMN may only go to the start of a process. If the message should reach an intermediate event then it must go through an “Incoming Processor” that will identify the proper process instance and forward the message to this instance.
The diagram shown at fig. 2 can be considered valid only with the assumption that there is a process following “Incoming Processor” pattern behind the “Request” message arrow that we imply but not depict to avoid clutter.
Recruitment process and associated Resume processing, the Sale process and the associated Cash income processing - I meet the “Incoming Processor” pattern all the time in my practice.
In this post we have considered the case where the message destination (a specific instance of the Credit card issuance process, the Recruitment process or the Sale process) is unknown but at least the message type is clear (a card request, a candidate’s resume or an income statement, respectively). Next time we’ll consider a situation where neither one nor the other is known a prior.