I had good luck with my previous BPMN “request for information” posting, so here is another one. Is it valid to end a top-level process in BPMN with an error end event? In my training I say that it is not, but it is a gray area. An error end event in a subprocess throws a signal that is caught by an error intermediate event attached to the boundary of that subprocess, i.e. at a parent level in the model. That is the only purpose of error event in BPMN, to propagate exception handling from child to parent levels in a hierarchical model. In a top-level process there is no parent level – it’s already the top – so nothing to catch the error signal. The error end event thus has no purpose.
Nevertheless I frequently see it in the wild, most recently during a technical review of some BPMN questions on OMG’s forthcoming certification exam. The example looks something like this:
Is this valid? I say no, or at least it’s bad practice. You could argue, I suppose, that throwing a signal that is not caught does no harm, and the error symbol signifies a failed outcome. Fair enough, but I think a misuse of the error symbol. Antoine Lonjon proposed some new end event symbol for this purpose - a downward arrow I think – in the BPDM version of BPMN 2.0, and I think that’s fine; it’s not a thrown error signal.
The other argument that this diagram is valid holds that this process could possibly be called as a reusable subprocess by some other (unknown) process. The catcher of the error signal would be the calling activity in that parent process.
OK, but normally Receive Order instantiates a process; it is not something that happens in the middle. Well, maybe in a Quote-to-Cash process, the order happens after the quote, so there it could be in the middle.
And here’s another murky area of BPMN. The spec says a subprocess must start with a None start event, not a triggered start like Message. What if it’s indeterminate whether it’s top-level or subprocess? If the process could be used either as a top-level process or a reusable subprocess, BPMN 1.1 says it should be drawn like this:
Yes, really. Section 9.4.2.3, check it out if you don’t believe me. And no, I have never seen this in the wild, either. But it is consistent with the notion that a subprocess must start with a None start.
So on either count, I would say that the first diagram here is invalid.
But I’m still (somewhat) open to persuasion. Any BPMS Watch readers have something to contribute?
Tags: BPMN
I would view the throwing of an event and not defining the handling of that event as very bad practice and at the very least I would like a BPMN tool to warn me about it. It is the equivalent of a sequence flow going nowhere. It is true that in the real world a business process may get to an exceptional condition and the business would invent a process to handle it at the time and it is not necessary to define every possible case but an indication that this is to happen should be made explicit even if the catch of the error leads to an activity simply labelled “handle remaining error conditions”
Where the BPMN goes on to be executed (as BPEL or whatever) there is likely to be a default error handler but it is not very useful to the business to have a decision recorded as 100 lines of java stack dump, or silence. Also, the BPMN is intended to be portable but there is no guarantee that the default action will be the same across different executables.
David.
Thanks for the comment. Unlike BPEL, BPMN does not provide process-level error handlers, and to trigger an exception handler process you would use message not error event, as there is no error start event in BPMN. So it’s even worse than you thought.
I am not sure about this, but I actually think it’s ok. My ambition is to bring the BPMN to Business, and I have experienced that Business users love to design a “bad end” of a process as an error. And of course there can be process models which reflect a bad As-Is-situation by showing thrown errors nobody takes care of. I mean, process modeling is not only about the perfect world, but also showing the process running today, especially if it is designed weakly. I think it is not the purpose of a notation nor a metamodel or anything similar to tell us how a “good” process looks like. We need process design – guidelines for this, which you can perfectly implement into a modeling tool. But that’s different story – A bad process modelled syntactically correct is definitely a valid model.
Short version: I think it is ok to throw an error nobody’s catching – in an as-is-model, not in a to-be-concept!
Another thing: In your review of Stephen White’s Reference Guide you wonder why he presents a process instantiation pattern with different start events instead of using the event-based gateway. But I think the “reusable sub-process which can also be a top-level-process”-pattern in spec-section 9.4.2.3 does exactly the same, doesn’t it?
BTW: Great blog!
Jakob
OK, one vote the other way. But I think you are saying business may want to relax the rules of BPMN, so it’s ok with that understanding.
Re the diagram in Steve and Derek’s book – it’s fig 8-14 on p93 – No this is not a reusable subprocess with a None start (used when called as a subprocess) and a message start (used when a top level process). It’s a process with two message start events representing two different types of orders. It’s exactly the use case described by the bootstrapped event gateway in BPMN 1.1. So I’m standing firm on that one.
I’d say that when you see an error event “thrown” at the end you assume the process is a subprocess. I don’t think it is “good” design for a top-level process to do this, but an implementation of BPMN should handle this case as it can happen by accident if not on purpose.
Much like, in other “programming languages” an uncaught exception still has to be dealt with at some level (by the OS if nothing else). you don’t want your BPM server dying just because someone threw the odd exception End event
One “advantage” of throwing an error exception on a failed process is that you can see that it failed. but personally, when I have to model a failure I want it to go into some kind of queue for resolution by someone that knows what they’re doing (administrator, IT admin, etc. )
I guess to me the issue isn’t so much conformance to spec as it is style… .5++
Hmmm… I didn’t think BPMN was supposed to be a flowcharting “style guide”. It purports to be a spec with defined semantics and rules. The key difference between BPMN and the flowcharts of yesteryear is a business-oriented language for defining what should happen if some exception occurs, precisely so it doesn’t just get dumped into the old “supervisor queue”. That is so 1995.
I don’t think this is about uncaught runtime exceptions. In an executable design environment, if there’s nothing to catch an exception throw the tool is not going to let you insert it. This is about process modeling not execution. It might be a good idea for BPMN to allow process-level exception handlers, but today it doesn’t. If the semantic is valuable let’s get it into the spec instead of awarding style points to violators.