Exceptions are a norm in business processes, and all BPM systems attempt to support exception handling to some degree. However, most systems have a limited view of what a business process exception means.
There are at least two kinds of exceptions. The first kind which occur because we have an automated BPM system - call them "technical exceptions." These are caused by system failures, network unavailability, web services binding problems, script/method execution errors, unexpected input formats, data transformation errors, and a whole bunch of things like these. Most sophisticated BPM systems that are EAI / integration centric, including the BPEL standard, address these exceptions thoroughly, and provide very elaborate exception handling mechanisms including catch-and-throw, notifications, compensations, automatic / manual retries, and more.
The exceptions of the second kind arise whether or not a BPM system is employed, and these are real business process exceptions - call them "business exceptions." Some of these exceptions may be foreseen and modeled in the BPM system explicitly. For example, a loan process may throw an explicit exception when the loan amount requested exceeds certain limit, or when a specific work item hasn't been acted upon for a certain duration. Some tend to classify any case that cannot go through straight-thru-processing (STP) as an exception case. Many modern BPM systems, including the BPEL standard, support explicit throwing of exceptions and custom exception handlers. Appropriate actions (such as rollbacks and compesation actions) are automatically taken when an explicit exception is thrown.
Some other exceptions are either not foreseen or not explicitly modeled in the BPM system, which may result in dead-paths or dead-locks during the process execution. Many BPM systems today fail to identify these exceptions, and offer little or no support for handling such exceptions.
There may be even more complex exceptions that may require certain process execution steps to be retracted and restarted. Imagine a scenario when you are booking a flight, and the agent starts the process with the assumption that you are a non-preferred customer. Just before completion, you inform the agent that you are a preferred customer. Now, process execution may need to be retracted, and a different branch of process may need to be selected. In such scenarios, a BPM system should be able to automatically determine how to backtrack to a past execution point and re-execute the process. Most BPM systems offer no support at all for these kinds of exceptions. And, much more complex variations of this scenario exist in the real world.
So, when a product brochure claims support for exception handling, do not assume it means all the above. It may mean very little to you, depending on what you are looking for.
