Exception handling
To cope with exceptional situations, e.g. calling a Web service that is currently unavailable, BPEL offers the concept of fault handlers. A fault handler can be attached to a scope, a process, or even directly as a shorthand notation on an invoke activity.
A fault handler gets installed as soon as the scope it is associated to gets started. As an example, the process level fault handler gets installed when the process starts. If the process completes normally, the installed fault handler then gets discarded, but if a fault situation occurs, that fault gets propagated to the fault handler.
A fault handler can have two types of children: One or more catch constructs, and at most one catchAll. Each catch construct then has to provide an activity that performs exception handling for a specific type of error condition.
A catch construct has optional additional attributes: a faultName that refers to the name of the fault that should get caught, and a faultVariable attribute. When faultVariable attribute is used, either faultMessageType or faultElement attribute must be specified. The faultVariable would point to a variable locally declared within the catch construct based on the faultMessageType or faultElement attribute.
Optionally, the fault hander can end with a catchAll construct. The intention is to provide a means for default fault handling.
There are now companies with Prepackaged BPEL Error Handling www.karmaticIT.com
See also:
- WS-BPEL 2.0 Primer: Exception handling
Search
SUBSCRIBE
RECENT CONTENT
- 9th ACM International Conference on Event-Based Systems, ACM DEBS 2015
9 years ago - Wiki Knowledgebase
9 years ago - 8th International Workshop on Value Modeling and Business Ontology
10 years ago - Conflicting Receive
10 years ago - Quick Question: Yes or No?
10 years ago - Quick Question: Yes or No?
10 years ago
Dead-Path-Eleminition is a special way of exception handling
Just want to make a short comment: BPEL supports both graph-based and block-structured programming. Dead-Path-Elimination is a way to give graphs execution semantics. Normally, if a bpel:joinFailure is thrown, it is handled by the appropriate fault handler. If suppressJoinFailure="yes" is set, Dead-Path-Elimination is activated and now fault is thrown.
More details on the relation of Dead-Path-Eliminiation and Exception Handling can be found in: Francisco Curbera, Rania Khalaf, Frank Leymann, Sanjiva Weerawarana: Exception Handling in the BPEL4WS Language. Business Process Management 2003: 276-290. Springer, LNC.and for comments on support of graph-based constructus by BPEL: Kopp, Oliver; Martin, Daniel; Wutke, Daniel; Leymann, Frank: On the Choice Between Graph-Based and Block-Structured Business Process Modeling Languages. In: Modellierung betrieblicher Informationssysteme (MobIS 2008)