Exceptions, Business as Usual?

In this article I describe some aspects considering using BPMN exceptions to handle business exceptions. The conclusion is that you should carefully consider if doing so is appropriate, or that using a combination of a gateway and End event would be a better option.

Bruce Silver writes in his book BPM Method & Style that he used to use BPMN Exception end events only for technical exceptions. For business exceptions he used to use a combination of a gateway and an end state test.

When I first read that I found that to be a peculiar remark, as - coming from a Oracle BPM 10g direction - I used them for business exceptions all the time! Moreover, as most technical exceptions could be caught and managed in BPL (the 10g, Java-like scripting language) I even adviced people to to use Exceptions for technical exceptions only if unavoidable with the argument that the business audience is not interested in technical exceptions, and that therefore they should be left out of the model if possible. After all, wouldn't you agree that the first model (in which exceptions are used for business exceptions) looks simpler that the second one (which is more the gateway/end-state type of solution)?

Using BPMN Error end event

Using gateways

The model presented is inspired by a business process model with a similar complexity, but then bigger. From a functional point of view both models do the same. Examples like this may explain why later on Bruce Silver changed his mind based on feedback from his students.

With Oracle BPM 10g it was easy to write some generic (technical) business exception handling process with a retry option (using the BACK action). With this retry you could simply return to the happy path even when an Exception end event had occurred.

The first time I started to have second thoughts about using Exceptions for business exceptions was when I found that with 11g this back functionality is no longer possible (although it is supposed to come back in 12c in some way or another).

The second second thoughts came when I realized that throwing an Exception and catch that in an Event Sub-process, also has some other peculiarities, as I will explain using the model below:

In this sample model there is an Event Sub-process with a non-interrupting Get Status Message start event, and a Return Status Message end event. This exposes a getStatus services operation that can be called by some 3rd party to find out where the process is, and for that returns a status that is set by the Set Rejected Status and Set Reconsidering Status Script activities. When the Rejected Error event is thrown this is caught by the Event Sub-process with the Rejection Error start event. An Event Sub-process that starts with an Error start event, is interrupting by definition.

Patterns like this (where some operation or service is exposed to interact with a running instance) are very common in my practice. As a matter of fact, as far as I recall more than half of the models I created have a similar Event Sub-process, either to get or to set some process data on the run.

The issue that I found is that when the order is rejected without the option to reconsider - meaning that the Rejected Error event is thrown, the normal flow of the process is aborted (because of the interrupting nature of Error events). As a result, when the process is in the Confirm activity, and the getStatus operation is called, it won't react because that operation it is tied to the normal flow, which is no longer active. In contrast, when the process is in the Reconsider this is not a problem.

It is unclear to me what the BPMN specifications say about this. I can imagine that this behavior is in line with the specifications, or that the specifications are not explicit about what that behavior should be. In any case, this is how it works with 11g, which made me realize that throwing Error end events in case of business exceptions has some drawbacks that might make that modeling by using a gateway plus end state is not so peculiar after all.