Databases Reference
In-Depth Information
This would be intercepted by the Service Bus, which would then populate
$fault
with the following:
<con:faultxmlns:con="http://www.bea.com/wli/sb/context">
<con:errorCode>BEA-380001</con:errorCode>
<con:reason>InternalServerError</con:reason>
<con:location>
<con:node>RouteToVerifyMasterCard</con:node>
<con:path>response-pipeline</con:path>
</con:location>
</con:fault>
Here,
errorCode
and its corresponding
reason
provide an indication of the type of
error that occurred; common error codes include:
•
BEA-380001 - Indicates an internal server error, including the return of a
fault by a SOAP Service
BEA-380002 - Indicates a connection error, such as the SOAP Service not
being reachable or available
BEA-382500 - Indicates that a service callout returned a SOAP Fault
•
•
We can also see from the content of the
location
element that the error occurred in
the response pipeline of the
RouteToVerifyMasterCard
node. This information can
be useful if we are implementing a more generic error handler at either the pipeline
or service level.
In addition to populating the
$fault
variable, the
$body
variable will now contain
the actual SOAP fault returned by the external service.
Finally, the Service Bus will raise an error, which, if not handled by the proxy
service, will result in the Service Bus returning its own fault to the client of the
proxy service.
Defining an error handler
The first step in handling an error is to catch it. Within a proxy service we do this
by using an error handler, which can be defined at the route, stage, pipeline,
or service level.
When the Service Bus raises an error, it will first look to invoke the error handler on
the route node or stage in which the error occurred.
