Let’s consider a process diagram borrowed (with some simplifications) from the book by Stephen White, Derek Miers, “BPMN Modeling And Reference Guide”, p. 113:
The diagram illustrates a fragment of book creation process. The process splits into two subprocesses executed in parallel: writing text and developing book cover. The point is that book cover development may start only when the concept is ready.
The challenge of implementing this logic is that we can’t use sequence flow because it cannot cross subprocess boundary. (Let’s leave apart the question why we need subporcesses here; let’s just suppose we need them for some reason.) We can’t use message flow either because it’s all within a single pool.
The standard recommendation is to use BPMN signal event:
- when the concept is ready, first subporcess triggers a signal
- second process was awaiting for the signal; after catching the signal it proceeds to “Develop Book Cover” task
It’s so called “Milestone” process pattern. A similar example of BPMN signal usage is given in the book by Bruce Silver, “BPMN Method and Style”, p. 98.
Where is the catch?
Everything is OK as long as we consider a signle book creation. Now let’s suppose several books are processed at once. Recalling that BPMN signal is broadcasted to everyone awaiting it at the given moment, as soon as the concept of first book is ready all designers will receive the signal to start developing the cover. Not exactly what we expected.
In order to make the diagram work we must limit the signal propagation somehow. How it can be done?
- The first thing that comes into my mind is an attribute that would limit signal broadcasting by the current process instance boundaries. Yet there is no such attribute in the standard. Under BPMN 1.x one may say that it’s implementation issue not covered by the standard. But BPMN 2.0 fully specify the process metamodel. Let’s look at page 281 of OMG document dated June 2010: signal has a single attribute - its name. Therefore, a signal will be transmitted to all process instances.
- If the signal has only name then let’s use what we have. The diagram above may work if we could change signal name dynamically i.e. during the process execution. If we could name the signal “Process 999 Concept Ready” instead of “Concept Ready” then everything will be fine. But it’s a dirty hack and it’s hard to count on it. BPMS engines allow to change certain things during the execution (e.g. timer settings) but unlikely the name.
Why we should care.
Depending on whether we may use signal events to coordinate flows within a process instance, we should chose one process architecture or another:
- if signals propagation can be limited, one can freely use subprocesses - whenever the need to synchronize them arises, it can be done by a signal
- if signals transmit without limits then the only option is to launch separate processes for each branch because we can synchronize processes by message flows, resulting in a diagram like this:
Conclusions:
- The BPMN standard lacks an attribute giving an option to limit signal event propagation.
- As long as there is no way to limit the signal propagation, the “Milestone” process pattern should be implmented by message flows between separate pools.
Yes, it is strange that you can synchronize two separate processes, but not two sub-processes within the same parent process.
I don’t like the workaround with separate pools, because this is rather artificial if you actually want to model one process. It also adds complexity, since you need to use a correlation mechanism. Communication within the same instance can be accomplished more easily, e.g. by using process variables.
How about this workaround: Use a conditional event instead of the catching signal event. In the upper process you don’t need a throwing event, or you use a none event just to mark the place where the concept reaches the ready state. The actual communication would take place by a flag attribute that is defined in the parent process. Variables defined in the parent process are visible in all sub-processes. “Develop book concept” would set the “concept ready” flag to true, and the conditional event which has waited, would be triggered.
I agree that it would be good to have an attribute in the signal event that could be used for correlating the signal to a specific process instance. Of course, you could define your own attribute using the BPMN extension mechanism. However, this again is an individual extension, but not the standard. I would like to draw a line between such signal events that are bound to a specific instance (maybe a specific type of association). After all, you can draw a line for the message flow so that you can connect the corresponding message events of different processes. The same should be possible for sub-processes (equal rights for sub-processes …!).
Thomas
Thank you for valuable input. I like the idea to use conditional event.
The separate pool workaround is artificial indeed but let’s take into account that the whole case is artificial. There is no real need to use subprocesses here hence launching external processes looks like an overkill.
But look, with the conditional event we fall into the same trap. The “concept ready” flag won’t help by the same reason as the “concept ready” signal. The “process 9999 concept ready” would work but you’ll need to create a business rule dynamically which may be a non-trivial task.
According to the BPMN specification, a conditional event has an expression which can be used for this purpose. If a signal is regarded as something that is usually independent from a certain process instance, the assignment to a specific instance may indeed be non-trivial. However, if we define a process instance variable “concept ready” in the parent process, the rule of the condition event is rather simple: It triggers when “concept ready” becomes true. There is no need to identify the right process instance, because a process instance variable always exists in the context of a process instance.
Well, I just looked it up in the spec: There is only one instance variable in the spec: “state”. However, you can assign data to a process instance via data input and output, so it’s possible to solve the problem as I state above.
Guess you are right. The BPMN 2.0 spec says:
“The Condition Expression of a Conditional Start Event MUST NOT refer to the data context or instance attribute of the Process (as the Process
instance has not yet been created). Instead, it MAY refer to static Process attributes and states of entities in the environment. The specification
of mechanisms to access such states is out of scope of the standard.”
So it’s safe to assume that unlike a start event expression, intermediate conditional event expression may refer to the process instance attributes.
Good day
What about using Link, like in pattern WCP-18 (site http://diveintobpm.org/index.jsp)?
Denis
Thank you for the good question.
Link event doesn’t add anything to the process semantic, it’s just a way to represent a process graphically. One can draw a sequence flow from Task3 to the parallel merge on the diagram you refer as well. Both ways will work for this process indeed but in our case we are trying to synchronize different subprocesses. Links won’t help here: a pair of links creates a virtual sequence flow so it’s plain wrong to place them at different process levels or in different processes.
A.B.