Archive for June, 2011

Custom XPath Functions in OSB

Wikipedia says “Extensibility is a system design principle where the implementation takes into consideration future growth.Extensions can be through the addition of new functionality or through modification of existing functionality”.

The extensibility is possible even in case of OSB and custom XPath functions is one of the ways to extend the out-of-the-box functionality provided with OSB. In this  post, we talk about the procedure to come up with the custom XPath functions. Though the example taken in this post (division of numbers)does not represent the real-world case but sufficient enough to stress the point.

During the IDE and server start up, OSB checks for custom functions in the path $OSB_HOME/config/xpath-functions.

Creating the custom XPath functions involves coming up with an xml file and the java code that does the required task. The xml file is going to be similar to the file osb-built-in.xml provided in above path that contains OSB functions. So let us create a xml file custom-func-demo.xml with the below contents and place it the folder mentioned above.

<?xml version="1.0" encoding="UTF-8"?>
<xpf:xpathFunctions xmlns:xpf="">
    <xpf:category id="Custom Functions">
        <xpf:comment>Function used for division of numbers</xpf:comment>
        <xpf:method>java.lang.Double divide(java.lang.Double,java.lang.Double)</xpf:method>

The above XML fragment shows the custom XPath function name (Divide Numbers), Class Name, Java Method and the namespace that should be used to access the function in the message flow. ‘isDeterministic’ specifies whether the function is deterministic or non-deterministic. Deterministic functions always provide the same results where as Non-Deterministic functions return the unique results.

Create a simple java class with the following code. Make sure that class name (including the package) and method signature matches with the above xml contents. Create a jar of this and place it in the above mentioned location so that IDE and server can detect the custom function.

package demo;

import java.lang.Double;

public class DivideNumbers {
    public static Double divide(Double a, Double b) {
        return a/b;

On restart of Eclipse IDE and OSB server, we should be able to see the custom XPath function that we just defined.




Use the custom XPath function and run the proxy service to see the expected results as shown below.



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.


Failed to set the value of context variable "body". Value must be an instance of {}Body.

Failed to set the value of context variable "header". Value must be an instance of {}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:


           <soapenv:Body xmlns:soapenv="">                    <Value>Sample Value</Value>

            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.


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="" 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.

Namespace Issue

Today, for one of the tasks i need one sample WSDL so that i can create some mock service in SOAP UI. As usual wanted to leverage google search capabilities Smile for the same, instead of coming up with one on my own.

I have taken one of the WSDLs given in to my eclipse. I am surprised to see the errors given by eclipse for the WSDL. I made sure that the WSDL structure, namespace aliases etc. are given correctly.On careful examination of the inline XSD given in the WSDL, found the issue is with the namespace which is given as

Modifying this namespace to resolved the error.

So the moral of the story is that some times blind copy does not give the intended time saving benefits as we expect.

Java Embedded Activity in BPEL

Today, it’s the first time that i worked with the Java Embedded Activity in BPEL 11g as i had a requirement of using coherence in the context of BPEL.

Came across one of the silly issues during this process so wanted to share the resolution of the same as i feel its the common mistake that can be done.

When i put the code in java embedded activity and rebuild the composite, i was getting the following error.

Error(23,34): Failed to compile bpel generated classes. failure to compile the generated BPEL classes for BPEL process "BPELProcess1" of composite "default/Project1!1.0"
The class path setting is incorrect.
Ensure that the class path is set correctly. If this happens on the server side, verify that the custom classes or jars which this BPEL process is depending on are deployed correctly. Also verify that the run time is using the same release/version.

The issue is coming as the necessary import statements are missing. To resolve this issue, add the import statements in the following way in .bpel file(these are the classes that i used) before the listing of partner links.

<bpelx:exec import=""/>
<bpelx:exec import=""/>



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

Join 327 other followers

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