One of the most challenging tasks to the success of the project is to come up with a proper error handling approach. Today I will briefly touch up on the error handling features in BPEL/ESB.
BPEL
When you consider a BPEL process, the errors can be categorized as below.
- Partner link errors.
- Non-partner link errors.
Partner Link Errors
Partner link can throw error in either of the 2 scenarios.
The partner link invocation fails.
The partner link receives a fault.
In case of Partner link errors BPEL 10.1.3.3 provides the Fault Policy management framework which helps you in standardizing the error handling mechanism at domain level, process level, partner link or port Type level depending on your requirements. It provides a generic fault management framework for handling faults in BPEL processes. If a fault occurs during runtime in an invoke activity in a process, the framework catches the fault and performs a user-specified action defined in a fault policy file associated with the activity.
Non-Partner Link Errors
In case of Non-partner link errors you need to manually handle this.
Create a bpel process say NPErrorHandlingBPELProcess. The error handling mechanism has to be defined in this process. Depending on the requirements this BPEL process should initiate the error handling along with sending out notifications and error logging.
Every participating BPEL process needs to use a common Application specific Fault message which will be given as the input to our NPErrorHandlingBPELProcess. Each BPEL process needs to populate the message and invoke the NPErrorHandlingBPELProcess.
ESB
In the case of ESB the error handling is dependent on the type of process. Error handling is processed differently whether asynchronous and synchronous execution is specified for a routing service. ESB errors can be categorized into
Errors generated by asynchronous processes come under the category of retryable. When you create a ESB process itself there is an option to define a ERROR TOPIC. In the case of an error the ERROR TOPIC will be used to store the business event along with the payload. So in such scenarios we can retrieve the payload from the Topic by subscribing to the topic and handle it according to your requirements.
Errors generated by synchronous ESB processes are non-retryable. The best way as I see it is to use a BPEL process to invoke the ESB processes with synchronous routing service. For synchronous execution, the transaction is rolled back and an error notification is returned to the adapter/service that initiated the processing. Once you have the error notification in the BPEL process you have multiple ways to handle it.
Hope this article helps you in getting started with the different error handling options available in BPEL/ESB.
2 comments:
In bpel-processes we can categorize the faults into: business faults and runtime faults. Business faults are application specific faults and will occur when we use the “throw”-activity or if we invoke a partnerlink which returns with some fault. It’s up to the “business” to decide what needs to be done when the fault occurs and what activities are needed for handling it.
Besides the business faults we have the runtime faults. Runtime faults will not be defined by the user, so we need to design parts in the process to handle them. In bpel we will make use of the catch-activity for this. In the catch itself we can invoke our own fault-handling processes or do some other activities (retry etc) which are needed to get a valid situation again.
ravi.
Hello Ravi
Pardon my enexperience in SOA.. Did you just stated above, the difference between Partner link error and Non Partner link error??
SanjayMD
Post a Comment