Comments on: When Are Error End Events Legal?

By: bruce

bruce — Fri, 24 Oct 2008 23:11:28 +0000

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.

By: sfrancis

sfrancis — Fri, 24 Oct 2008 22:50:19 +0000

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++

By: bruce

bruce — Wed, 22 Oct 2008 19:29:13 +0000

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.

By: jakob.freund

jakob.freund — Wed, 22 Oct 2008 19:16:20 +0000

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

By: bruce

bruce — Wed, 22 Oct 2008 18:30:53 +0000

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.

By: frenchdk

frenchdk — Wed, 22 Oct 2008 18:21:01 +0000

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.