In the Image field, click the Search icon to optionally change the graphical image

Using Fault Handling in a BPEL Process 11-33 assign invoke name=InvokeCheckCreditCard inputVariable=lCreditCardInput outputVariable=lCreditCardOutput partnerLink=CreditCardAuthorizationService portType=ns2:CreditAuthorizationPort operation=AuthorizeCredit switch name=Switch_EvaluateCCResult case condition=bpws:getVariableDatalCreditCardOutput,status, ns8:status = APPROVED bpelx:annotation bpelx:patternstatus lt;gt; approvedbpelx:pattern bpelx:annotation throw name=Throw_Fault_CC_Denied faultName=client:OrderProcessorFault case switch sequence scope

11.10.4 What You May Need to Know About Scopes

Scopes can use a significant amount of CPU and memory and should not be overused. Sequence activities use less CPU and memory and can make large BPEL flows more readable.

11.10.5 How to Use a Fault Handler Within a Scope

If a fault is not handled, it creates a faulted state that migrates up through the application and can throw the entire process into a faulted state. To prevent this from occurring, place the parts of the process that have the potential to receive faults within a scope. The scope activity includes the following fault handling capabilities: ■ The catch activity works within a scope to catch faults and exceptions before they can throw the entire process into a faulted state. You can use specific fault names in the catch activity to respond in a specific way to an individual fault. ■ The catchAll activity catches any faults that are not handled by name-specific catch activities. Example 11–25 shows the syntax for catch and catchAll activities. Assume that a fault named x:foo is thrown. The first catch is selected if the fault carries no fault data. If there is fault data associated with the fault, the third catch is selected if the type of the faults data matches the type of variable bar. Otherwise, the default catchAll handler is selected. Finally, a fault with a fault variable whose type matches the type of bar and whose name is not x:foo is processed by the second catch. All other faults are processed by the default catchAll handler. Example 11–25 Catch and CatchAll Activities faulthandlers catch faultName=x:foo empty catch catch faultVariable=bar empty catch catch faultName=x:foo faultVariable=bar empty catch