Advertisements

Posts Tagged 'Fault'

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

Using SOA Test to Simulate Fault Scenarios

The focus on the Web services continue to grow with the emergence of Service Oriented Architecture (SOA) because of its reuse, loose coupled nature and agility it adds to business processes.

Similar to typical software application life cycle, web service testing also assumes the equal significance. Rapid creation and deployment of complex web services offer challenges to the developers and QA teams as well during testing.

Web service testing typically has the following tasks:

   · Creating Test Clients based on the WSDL

   · Invoking the Web service using the test clients by sending the requests.

   · Verifying that the actual response is similar to that of expected response.

In some of the cases where the end system is unavailable we need to create the stubs to simulate service provider behavior.

Parasoft SOA Test is a testing tool used in the Webservice Testing that can be used to perform all of the above activities.

This post assumes the basic working knowledge of SOA Test 6.2 in creating the stubs and will discuss the case of simulating the fault from the service provider.

Settings to do for Fault Case in SOA Test stubs:

– Double click on the stub in Test Case Explorer that brings up the screen similar to the below one. Copy the SOAP fault that you want to receive from the service provider in the Response tab as shown below.

                image

– Go to the Service Options tab and click on ‘Return Status’ in the options available at the left side of the screen as shown below. Enter the ‘Return Status’ and ‘Return Message’  fields as shown in below screen.

                image

As per WS Basic Profile, HTTP  status code 500 has to be sent to the consumer of the service when service provider sends the fault response. That’s why we are setting the value as 500 here.


Advertisements

Pages

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

Join 372 other followers

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

Advertisements