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 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.
User-defined fault in the BPEL Process:-