Advertisements



Fault Handling in OSB

As we know, service provider can send the error back to the consumer in the following ways:

  • As a normal response, by populating the fields like “ErrorNumber” and “ErrorMesssage”. Assuming that these fields are defined in the response message structure in WSDL.
  • As a SOAP fault

Typically when OSB is mediating between service consumer and service provider, we might have to transform this error response or fault response to the response structure defined in the proxy WSDL. So we need to understand on what message context variables can be used for this transformation.

As per WS-I BP, the service provider should send the HTTP response code as 200 when the error is being sent back as normal response and 500 should be sent when the error being sent back in form of the SOAP fault.

When HTTP response code 200 is received, OSB treats it as a normal response and $body will have the received response. And when response code 500 is received, the OSB runtime control goes  to the ‘Service Error Handler’ if present or to ‘System Error Handler’. That means OSB considers the fault response also as a normal response and populates $body, when response code is 200 is received for fault response.

And OSB populates different message context variables in case of fault response with 500 code depending on whether Routing or Service Callout are used to call the business service. When routing is used, the variable $body will have the fault response. When service callout is used, the variable $fault will have the fault response in ‘ReceivedFaultDetail’ structure.

For demonstrating the same, the following SOAP fault structure is used as a response in SOAP UI mock service.

<SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/" xmlns:xsi="http://www.w3.org/1999/XMLSchema-instance" xmlns:xsd="http://www.w3.org/1999/XMLSchema">
   <SOAP-ENV:Body>
      <SOAP-ENV:Fault>
         <faultcode>SOAP-ENV:Client</faultcode>
         <faultstring>Failed to locate method (ValidateCreditCard) in class</faultstring>
         <detail>
              <ValidationError>
                   <ErrorCode>78970989</ErrorCode>
                   <ErrorMessage>Validation failed.Credit Card Expired.</ErrorMessage>
              </ValidationError>
     </detail>
      </SOAP-ENV:Fault>
   </SOAP-ENV:Body>
</SOAP-ENV:Envelope>

Create 2 proxy services with routing and service callout as shown below.

Proxy with Routing

                      image

Proxy with Service Callout

                      image

The log activities in the error handler are used to log the contents of $body and $fault variable for demonstration purpose.

Create a business service by giving the mock service endpoint which returns a SOAP fault as shown below.

                      image

In case of routing, the following screenshot confirms that $body has the received fault response. So the expression fn:empty($body/soap-env:Fault) can be used to find out whether we have received the fault or not.

                     Routing

In case of service callout, the following screenshot confirms that $fault has the received fault response. So the expression fn:empty($fault/ctx:details/con1:ReceivedFaultDetail) can be used to find out whether we have received the fault or not. We can come up with similar kind of expressions for all other OSB faults that are described in the link.

                    Service Callout

In case where both service callout and routing are used in single proxy service, a combination of both of above expressions has to be used.

Also look at the note given here that talks about fault handling in OSB.

Advertisements

2 Responses to “Fault Handling in OSB”


  1. 1 aswinisahu February 11, 2013 at 3:48 PM

    Hi Author, Can you please let me know which is the better approach to go with (fault as normal response vs soap fault) ?

    • 2 svgonugu February 25, 2013 at 11:35 AM

      I want to be little diplomatic here as i feel we can’t decide on the better approach without depending on the scenario. I generally go with the soap fault approach where i declare 2 to 3 specific fault structures and one generic fault structure in WSDL definition.


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s




Advertisements

Pages

Enter your email address to subscribe to this blog and receive notifications of new posts by email.

Join 344 other followers

Enter your email address to follow this blog and receive notifications of new posts by email.