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
onFault
activity faults before the complex activity is finished, theonFault
activity runs. - If the complex activity containing the
onFault
activity finishes successfully, theonFault
activity finishes successfully, too. - Sterling B2B Integrator
accepts multiple
onFault
elements within a single complex activity, making it possible to handle different fault codes.- Each set of
onFault
elements must use a unique fault code. - Omit the code attribute for only one element when using multiple
onFault
elements 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
onFault
element is triggered only by a fault that matches that code attribute. For example, theonFault
element has a code attribute set to SystemBusy. If the operation results in a fault associated with a different code attribute, the SystemBusyonFault
element does not run. - You can force the process to run the
onFault
activity for any fault encountered, by omitting a code attribute. - If there are multiple layers of joins in BPML, each layer has
onFault
defined, an error occurs in the branch, and the final join of the inner join layer carries the error, theonFault
of this layer is executed (even though the execution of theonFault
does 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 inneronFault
route 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>