Posts Tagged 'body'

Common Mistakes in OSB message flow

I see following are the few common errors that developer might come across during the initial stages of OSB learning.

1)

Failed to set the value of context variable "body". Value must be an instance of {http://schemas.xmlsoap.org/soap/envelope/}Body.

Failed to set the value of context variable "header". Value must be an instance of {http://schemas.xmlsoap.org/soap/envelope/}Header.

This error is because of, OSB always enclose the context variables $body and $header with <soap-env:Body> and <soap-env:Header> respectively. So when we are manipulating $header and $body we should make sure that these soap-env tags are not removed. For example, doing in the following way in an Assign activity can cause the above error as we are not maintaining <soap-env:Body> tag in $body variable.

            Expression: <Value>Sample Value</Value>

            Variable: body

And the correct usage in assign activity is like below:

             Expression:

           <soapenv:Body xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/">                    <Value>Sample Value</Value>

            </soapenv:Body>
            Variable: body

When we use service call out, the variable given for ‘SOAP Request Header’ should always contain <soap-env:Header> element irrespective of the selection of either ‘Çonfigure SOAP Body’ or ‘Configure Payload Document’. Otherwise again the above header related error will come.

2) 

Invalid message: the SOAP Header value is not an XML instance

One of the scenarios that this error can come is, when we use the service call out and the variable given for ‘SOAP Request Header’ is null.

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.


Pages

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

Join 377 other followers

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