Databases Reference
In-Depth Information
This will open the
Edit ErrorHandler; Route Node
window, where we can configure
the error handler. An error handler consists of one or more stages, so the first
we thing we need to do is to add a stage and name it accordingly (for example,
HandleVerfifyMasterCardFault),
), as shown in the next screenshot:
The first step within our error handler is to check whether we have received a SOAP
Fault or something more generic. To do this, we just need to add an
If…Then…
action, which checks if the value of
$fault/ctx:errorCode
is either BEA-382500
or BEA-380001.
Although the Service Bus reserves the error BEA-382500 for
SOAP Faults, we find that when we return a custom SOAP Fault,
the Service Bus raises an error of type BEA-380001. So we have to
check for both error codes to be safe.
Checking the type of SOAP Faults
Next, we need to check the SOAP Fault returned (which will be in
$body
), so that we
can handle it appropriately.
If we examine the WSDL for our
verifyMasterCard
operation, we can see that it
could potentially return one of two faults:
mcd:declined
and
mcd:invalid
, each of
which needs to be mapped to a fault returned by our proxy service.
At first glance, this all looks pretty straightforward. We just need to define an
'If…
Then…'
action, with a branch to test for each type of fault returned and generate the
appropriate fault to return.
For example, to test for a fault of type
mcd:declined
, we could define a branch with
a condition such as the following:
$body/soap-env:Fault/faultcode='mcd:declined'
However, if we look at
faultcode
more closely, we can see its type is
QName
, with
a format of prefix:faultName (for example,
mcd:declined
), where prefix is mapped
to a namespace in the
soap:Fault
element (for example,
http://xmlns.packtpub.
com/MasterCard
).
