Debugging Series: Debugging Web Service Proxy

Debugging issues on Web Service Proxy integration can be problematic, generally logs can be observed to get clues on the issue however sometimes the issue can be obscured by the generated logic for the proxy. In this article we will go through a real example case of debugging an issue encountered on a Web Service Proxy call to a Fusion Applications Web Service to illustrate an example debug flow.

Example Case

In this article we cover an example case where a web service call was failing with:  
JBO-26041: Failed to post data to database during "Insert":  
VALUES (:1,:2,:3,:4,:5,:6,:7,:8,:9,:10,:11,:12)".: 
ORA-01400: cannot insert NULL into 

While it would seem straightforward issue on wrong value passed in, however in this case the data passed in is valid so we need to debug the issue further.

Debugging the issue

To debug HttpAnalyzer is useful as we can use it obtain the exact SOAP envelope constructed by the proxy. The SOAP envelope is useful as it contains the exact data passed from the proxy to the service and also it can be used in other tools to debug the issue. In JDeveloper open the HttpAnalyzer by navigating to "Tools -> HttpAnalyzer":


You will be presented with the HttpAnalyzer UI:

To debug start an HttpAnalyzer instance by clicking the "play" icon. Once started run your Web Service Proxy call and you are presented with the http traffic produced by the proxy:

We are interested in the POST call; double click the row and UI with details of the POST request will be presented:

The exact SOAP enveloper can be accessed in the "Raw Message" tab:

This SOAP envelope can then be use to observe the data passed in and can also be used to run the same request using other tools such as SoapUI. In our example case we had an example of another SOAP envelope that works against another instance. If a working example is not available then the next step would be to try to run the SOAP envelope obtained using HttpAnalyzer with SoapUI and manipulate the data until the call works. In future OER will contain examples of payloads for calling a service. Based on the comparison the key difference was on the dates defined, which included a time zone component:


Whereas the working envelope did not include the time component at all:


To find out if the difference could cause the issue we run the problem SOAP Envelope using SoapUi and confirmed that the issue reproduced.


With the debugging we know that the issue is caused by the time zone component, but how will we resolve it. When integrating with Fusion Applications details of the services, the service operations and Service Data Objects (SDO) used as parameters can be observed in Oracle Enterprise Repository (OER). For the SDO passed as parameter the date attributes may have "java.sql.Date" or "java.sql.Timestamp", for our case:

If calling a service with a "java.sql.Date" attribute we need to be aware of how it needs to be used on the Web Service Proxy to avoid issues. For ADFbc EO / VO the dates are represented with "oracle.jbo.domain.Date" object and if looking at its String representation we'll see a date such as "2013-07-12". When Web Service Proxy is generated for the service the setter methods for dates are like this:

public void setEffectiveStartDate(XMLGregorianCalendar value)

So we will need to convert the "oracle.jbo.domain.Date" to "javax.xml.datatype.XMLGregorianCalendar", this is where we may run into issues. We could do the conversion as follows:

GregorianCalendar c = new GregorianCalendar();
XMLGregorianCalendar result = DatatypeFactory.newInstance().newXMLGregorianCalendar(c);

While we do get a date object the new object will include the time and time zone components, string representation would be something like "2013-07-12T00:00:00.000-07:00". This is what happened in the example case, the time zone was set and the internal service processing failed its queries. The specific issue could be fixed by explicitly setting the time zone component:


While this resolves the issue in the example case this would still leave the time component to the date, the string representation would be something like "2013-07-12T00:00:00.000". Since for the Date objects we only want the date related components in the objects to avoid unexpected issues we could instead use something like:

  Calendar calendar = Calendar.getInstance();
  XMLGregorianCalendar result =

Note that since Calendar.MONTH start from 0 we need to add 1 to it. With this the time component is removed and a string representation would be something like "2013-07-12".


In this article we have covered a real use case for debugging a time zone related issue on a web service proxy call to a Fusion Applications service.



Post a Comment:
  • HTML Syntax: NOT allowed

Follow us on twitter Fusion Applications Extensibility, Customizations and Integration forum Fusion Applications Dev Relations YouTube Channel
This blog offers news, tips and information for developers building extensions, customizations and integrations for Oracle Fusion Applications.


« November 2015