All Processes are Created Equal
15th of August 2016I have solid grasp on BPMN 2.0. I use it on a regular basis in all of my projects, and since I also design the analytical and executable levels of the processes, I have a tendency to utilize almost all of the elements afforded to me by the standard on a regular basis. As such, when I am confronted to come up with the best way to design a process, a lot of the BPMN elements get used. And this is where sometimes some annoyance pops up in my work. As I design for analytical levels, I usually do not use the process designer tools afforded to me by the BPMS tool, and tend to draw them in a tool such as Bizagi Modeler, Sparx Enterprise Architect, Signavio, or whatever other tool is the standard of the customer I am doing a project for (sometimes even just a whiteboard). These tools typically have the exhaustive range of elements in BPMN 2.0. However, when I then switch to the suite that will execute the code, this element set gets limited, and I am forced to rethink my solution to fit it into the BPMS.
Writing from recent experience, the need arose to be able to cancel a process by an external source. It would send out a message to be correlated based on a process instance ID, and this would lead to the process instance to immediately stop. This message can occur at any time during the execution of the (long-running) process. My technical designer, who has more than ample experience in service design, but is a novice when it comes to process design, drew the following model (simplified for this blog post):
Clearly, there is a glaring mistake in this model due to the inexperience of the modeler, and this mistake became part of his learning curve. The issue presents itself when the happy flow happens: BPMN is at heart a token based system, and after the parallel gateway, both the “Handle Case” Activity and the Cancel Event both receive a token. However, when the happy flow progresses till the point of the standard end event, the token for the cancellation event is never consumed. This keeps the process instance active even though there will no longer be any activity in this process instance. It also hits on one of my pet peeves in BPMN, namely that it is my belief that a terminate event is an element that should be very sparsely used, and is usually indicative of a bad design.
If I had the full range of BPMN 2.0 available to me, my design would be as shown in the model below. However, this uses multiple particularities of the BPMN 2.0 standard, such as unattached intermediate events, embedded subprocesses, transaction boundaries, and cancel boundary events. Not all of these are possible in every BPMS on the market. Since we are working with IBM Process Manager 8.5.5, embedded subprocesses are possible, and so are intermediate events.
The bad news about the IBM Process Manager: There is no option to define a subprocess as a transaction, and thus the cancel event isn’t possible either. So we have to become more creative. A cancel could be construed as a message sent to the process telling it to shut down, so we could have the boundary event be the message that triggers the cancel, giving us a model resembling the one below. We could event construe the cancel trigger as a business exception modeling it as such.
If by some mystery, the BPMS tool would not support boundary events or uncoupled intermediary events, a last ditch effort on my part before consulting the client to change BPMS choice of technology, is to employ an event gateway and informing the cancel branch by way of signal that it should no longer wait. Funny enough, it closely resembles the solution I showed to be incorrect at the beginning of the article.
No single version of the truth in process modeling, even if by some miracle the behavior of the process was completely known without ambiguities or misconceptions. But that is what keeps the job interesting and the mind sharp and on the lookout for modeling errors in all possible executions of any analyzed process.
| Thought | BPM |