Posts Tagged 'routing'

Using Dynamic Routing in OSB

Dynamic Routing in OSB can be used when we want to determine the business service at runtime in the message flow. To store the information about the business services that can be used, we can use XQuery resource.

Consider a scenario where OSB has to route the incoming requests to 2 different services based on the CustomerType element value sent in the payload. So create a XQuery resource with the following contents. Observe that we are using the absolute path of business service in configuration as required by dynamic routing.

<CustomerType value =’Privileged’>

<CustomerType value =’Ordinary’>

Following is the XML schema that we use.

<xsd:schema targetNamespace=””
    xmlns:xsd=”” xmlns:ns1=””>

    <xsd:complexType name=”Customer”>
<xsd:element name=”CustomerId” type=”xsd:string” />
<xsd:element name=”FirstName” type=”xsd:string” />
<xsd:element name=”LastName” type=”xsd:string” />
<xsd:element name=”MiddleName” minOccurs=”0″ type=”xsd:string” />
<xsd:element name=”CustomerType” type=”xsd:string” />
<xsd:element name=”Email” minOccurs=”0″ type=”xsd:string” />
<xsd:element name=”Mobile” minOccurs=”0″ type=”xsd:string” />

    <xsd:complexType name=”StatusMsg”>
<xsd:element name=”CustomerId” type=”xsd:string” />
<xsd:element name=”Response” type=”xsd:string” />
<xsd:element name=”ErrorCode” type=”xsd:string” minOccurs=”0″/>
<xsd:element name=”ErrorMessage” type=”xsd:string” />

    <xsd:element name=”Customer” type=”ns1:Customer” />
<xsd:element name=”StatusMsg” type=”ns1:StatusMsg” />

Following is the WSDL that we will use for the proxy service:

<wsdl:definitions name=”CustomerService”
targetNamespace=””         xmlns:wsdl=””
    xmlns:ns1=”” xmlns:xsd=””
    xmlns:tns=”” xmlns:soap=””>
<xsd:import namespace=””
                schemaLocation=”Customer.xsd” />

    <wsdl:message name=”CustomerCreate”>
<wsdl:part name=”parameters” element=”ns1:Customer” />
<wsdl:message name=”CustomerCreateResponse”>
<wsdl:part name=”parameters” element=”ns1:StatusMsg” />

    <wsdl:portType name=”CustomerServicePort”>
<wsdl:operation name=”CustomerCreate”>
<wsdl:input message=”tns:CustomerCreate” />
<wsdl:output message=”tns:CustomerCreateResponse” />

    <wsdl:binding name=”CustomerServiceBinding” type=”tns:CustomerServicePort”>
<soap:binding style=”document”
transport=”” />

        <wsdl:operation name=”CustomerCreate”>
<soap:operation soapAction=”CustomerCreate” />
<soap:body use=”literal” />
<soap:body use=”literal” />

Create the required resources a proxy service based on the above WSDL, 2 business services and a XQuery resource with the contents shown above.


Create the message flow as shown below.


The first assign activity loads the XQuery resource and stores the contents of the file in variable ‘varConfig’. The second assign activity stores the value of customer type element in the payload in ‘varType’ variable using the xpath expression $body/cus:Customer/CustomerType/text().

For the dynamic routing the expression should resolve to the following XML snippet. The attribute isProxy has to be set to ‘true’ if routing the request to proxy service or ‘false’ if routing the request to business service. Operation name is optional as business service might  not be WSDL service always.

<ctx:service isProxy=’false’>absolute path of business service</ctx:service>
<ctx:operation>operation name</ctx:operation>

So for our case use the XML contents as shown in the below screenshot along with the XPath expressions to get the required values.


Deploy the configuration jar and test it from test console to verify its working as expected.

The sample jar can be download from the following location.

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="" xmlns:xsi="" xmlns:xsd="">
         <faultstring>Failed to locate method (ValidateCreditCard) in class</faultstring>
                   <ErrorMessage>Validation failed.Credit Card Expired.</ErrorMessage>

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

Proxy with Routing


Proxy with Service Callout


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.


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.


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.


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

Join 380 other subscribers

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

%d bloggers like this: