Databases Reference
In-Depth Information
Defining a fault policy
A policy consists of two basic components; the faults that you wish to catch and
once caught the actions you wish to take, such as retry the service or perform
manual recovery.
Let's re-examine the
UserRegistration
process at the point that it invokes the credit
card service to verify the user's card's details. Apart from the business faults that
could be returned, it could also return a system fault such as the following:
<soap:Bodyxmlns:soap="http://schemas.xmlsoap.org/soap/envelope"
xmlns:flt="http://rubiconred.com/obay/xsd/fault">
<soap:Fault>
<faultcode>soap:Server</faultcode>
<faultstring>TransportRunTimeError</faultstring>
<detail>
<flt:fault>
<flt:code>380002</flt:code>
<flt:summary>ConnectionError</flt:summary>
<flt:detail>
…
</flt:detail>
</flt:fault>
</detail>
</soap:Fault>
</soap:Body>
Indicating that it's unable to call the service because of a transport problem, the code
of 380002 indicating that this is probably due to a temporary problem. For this kind
of scenario, we can define a fault policy to catch this error and retry the service.
The outline of the fault policy for our CreditCard service is shown as follows:
<faultPolicyversion="2.0.1"
id="CreditCardPolicy"
>
<Conditions>
…
</Conditions>
<Actions>
…
</Actions>
</faultPolicy>
From this, we can see that the fault policy is divided into two sections: the
Conditions
section, which defines the faults we wish to handle, and the
Actions
section, which defines the actions to take in order to recover from the fault.
