About Me

About Me
Working with SOA technologies , implementing solution using IBM BPM , IBM Integration Designer,IBM WODM and IBM DataPower

About me

View Mahesh Dondeti's profile on LinkedIn

upcoming posts on IBM Bluemix,Devops,Worklight,Node js.

Thursday, 3 January 2013

Different ways to handle Faults in BPEL Process

This post explains fault-handling mechanisms in the context of a microflow business process designed using BPEL.
A microflow business process is a short-running process that constitutes a single transaction. In contrast, a macroflow or long-running process could constitute multiple transactions over a prolonged period. The term fault refers to any exceptional condition that can alter the normal processing of a business process. Within the context of a business process, a fault need not result in a process ending condition; instead, a fault should lead to an actionable event. If a fault is not handled, it will lead to unexpected conditions, outcomes or even unpredictable failures of the business process. A well-designed business process should handle faults so that failures lead to predictable outcomes. Within BPEL, fault handlers can catch faults and attach business relevant execution logic to deal with the exceptional situation.
To correctly approach fault handling, the team identifies all exceptional conditions that can occur in a business process. The fault handling logic can be different depending on the nature of the fault. Identifying and classifying the faults helps you to design the fault handlers and place them within the appropriate scope of the business process.
When designing fault handlers, consider the following options:
  • Catch a fault and try to correct the problem, allowing the business process to continue to normal completion.
  • Catch a fault and find that it is not resolvable at this scope. Now, you have additional options:
    • Throw a new fault.
    • Re-throw the original fault to allow another scope to handle it.
    • Reply with a fault to the process initiator.
    • Invoke a human task to correct the issue.
    • If the fault handler cannot resolve the issue, you might need to rollback and compensate
BPEL activities to propagate a fault:-
BPEL allows fault propagation using throw, rethrow and reply within a fault handler. Next we’ll look at each of these ways to propagate a fault:
A throw activity indicates a problem that a business process flow cannot handle. You use it to throw an exception corresponding to an internal error condition. You can use a throw activity within the flow of a business process or within a fault handler, to allow an outer fault handler to handle the fault. A throw activity can throw one of the standard BPEL faults or a custom fault. The throw activity is required to provide a name for the fault and can optionally include a variable with data providing further information about the fault.
You use a rethrow activity when the current fault handler cannot handle the fault and wants to propagate it to an outer-scoped fault handler. In the absence of a rethrow activity, a fault propagated to a higher level using a throw activity would be a new fault. When a rethrow activity is invoked, the fault is the same instance. The rethrow activity is available only within a fault handler because only an existing fault can be rethrown.
Faults are either application faults or system and standard faults:
  • Application faults: These faults occur at set points during a business process due to application issues. The fault condition could be the result of business rules or constraint violations. For example, invoking a bank service to transfer funds can result in an insufficient funds fault. The process designer defines application faults in BPEL. An external service provider defines them in the service’s WSDL. For example see the figure1.
Figure 1. User-defined faults in WSDL:


User-defined fault in the BPEL Process:-