onFault Element
The onFault element is used to handle errors. You can include
onFault elements in any complex activity. These onFault elements
may be necessary to recover from faults so that the process can continue.
The onFault element
contains a fault handling activity. For information about using the onFault group
in the GPM, refer to the GPM documentation.
The following specifications apply to the onFault element:
- If the complex activity containing the
onFaultactivity faults before the complex activity is finished, theonFaultactivity runs. - If the complex activity containing the
onFaultactivity finishes successfully, theonFaultactivity finishes successfully, too. - Sterling B2B Integrator
accepts multiple
onFaultelements within a single complex activity, making it possible to handle different fault codes.- Each set of
onFaultelements must use a unique fault code. - Omit the code attribute for only one element when using multiple
onFaultelements for a single complex activity. Here is the syntax:<onFault code?> activity+ </onFault>
- Each set of
- In BPML, each fault can be associated with a unique code attribute. If the code
attribute is provided, the associated
onFaultelement is triggered only by a fault that matches that code attribute. For example, theonFaultelement has a code attribute set to SystemBusy. If the operation results in a fault associated with a different code attribute, the SystemBusyonFaultelement does not run. - You can force the process to run the
onFaultactivity for any fault encountered, by omitting a code attribute. - If there are multiple layers of joins in BPML, each layer has
onFaultdefined, an error occurs in the branch, and the final join of the inner join layer carries the error, theonFaultof this layer is executed (even though the execution of theonFaultdoes not have an error) and the error in the inner final join is propagated to the next layer of the join. This should not happen, because the inner layer of the join went to the inneronFaultroute and the on fault completes successfully. Avoid using complex multiple join layers in the BPML. Use Invoke Service Sync Mode for the branches; this mode merges all data from the subprocesses.
In the credit card example, the Verify Credit Card activity results in a
SystemBusy fault, causing the process to run the onFault element.
When the onFault element runs, the complex activity that it contains also runs. The
onFault activity finishes when the complex activity it contains finishes. The
complex activity that contains the onFault finishes at the same time, regardless of
whether it was fully or partially run. As a result, the Verify Sufficient Credit activity does not
fully run.
<process name="ProcessCustomerOrder">
<rule name="BookInStock">
<condition>foundBook true = </condition>
</rule>
<sequence>
<operation name='Check Inventory'>
<participant name='InventoryService' />
<output message='checkStockRequest'>
<assign to='ISBN'>1-56592-488-6</assign>
</output>
<input message name='checkStockResponse'>
<assign to='foundBook' from='InStock' />
</input>
</operation>
<choice>
<select>
<case ref="BookInStock" activity="proceed"/>
<case ref="BookInStock" negative="true" activity="stop"/>
</select>
<sequence name="proceed">
<sequence>
<operation name='Verify Credit Card'> … </operation>
<operation name='Verify Sufficient Credit'>…</operation>
<onFault code='SystemBusy'>
<sequence>
<!-- Logic to wait and retry -->
</sequence>
</onFault>
</sequence>
…
</sequence>
<sequence name="stop">
<operation name='Apologize to Customer'> … </operation>
</sequence>
</choice>
<operation name='Update customer on status'> … </operation>
<onFault>
<sequence>
<operation name='Inform Customer of Error'> … </operation>
<operation name='Signal Operator'> … </operation>
</sequence>
</onFault>
</sequence>
</process>