ODI Series - Web Services

Today I am going to embark on going through the Web Services functionality that is available in ODI; I have seen a few posts recently on problems setting up and configuring them so I thought I would go through my usual methodology and break it into detailed bite size chunks. Yes, I know there are other explanations out there on the web but from what I have seen I don’t feel they provide enough substance and anyway I find it useful to write it all down so I can refer back to it when required.

There are three main areas in which you can use Web Services in ODI, invoking ODI scenarios/sessions over the web, invoking web services using the ODI tool – ODIInvokeWebServices and finally Data Services. Data Services enable to create a web services against existing DataStores, this is mainly going to be of a RDMS source technology, I wouldn’t of thought you could use any different type of technology but maybe I am wrong? The Data Service provides the ability to retrieve, update and delete data governed by the DataStore.

First of all it is important to install the necessary components to use Web Services. To use Web Services with ODI you will need a Java JDK, I recommended downloading and installing the latest 1.5 version. If you go down the 1.6 route you may encounter problems, I know I did and it is a known issue.

OdiInvokeWebService tool is not working properly when using Designer with Java 1.6
It is not possible to invoke a Web Service with the OdiInvokeWebService tool when using
Designer with Java 1.6.
Invoking an operation throws the following exception :
java.lang.AbstractMethodError:
org.apache.crimson.tree.XmlDocument.getXmlStandalone()Z at
com.sun.org.apache.xalan.internal.xsltc.trax.DOM2TO.setDocumentInfo(DOM2TO.jav a:373)
at com.sun.org.apache.xalan.internal.xsltc.trax.DOM2TO.parse(DOM2TO.java:127)
at com.sun.org.apache.xalan.internal.xsltc.trax.DOM2TO.parse(DOM2TO.java:94....

I actually encountered the issue when trying to create a web service from a DataStore. The JDK version I installed was 1_5_0_18.



The environment variable ODI_JAVA_HOME was updated to point to the JDK installation, if you are using an agent service you will need to restart it to pick up the JDK.

To run web services an application server is required plus Axis2 which is Apaches web services engine.
The documentation recommends “J2EE 1.4 compliant application server, such as OC4J 10.1.3 and above.”
I already had Apache Tomcat 6.0.16 installed so will go ahead with using that as the app server.

It is important that you download the correct version of Axis2 or you will encounter issues, Version 1.2 seems to be the best option anything later and you will hit errors.



If you are just going to use the web services standard functionality then the WAR file will suffice and can be deployed from the application server.

If you are using Tomcat you can just place the axis2.war file in the webapps directory of the Tomcat installation, restart the server and axis2 will be auto-deployed.



After axis2 has been deployed you should be able access the administration console from http://:/axis2/axis2-admin/



The default username password for axis is admin/axis2.
Once logged in select “Upload Service”, the ODI public web service file is available at :- OraHome_1\oracledi\tools\web_services\odi-public-ws.aar

Once uploaded if you select “Available Services” you should see the service OdiInvoke and the operations that are available.



If you have read through my previous blogs I covered the Java invocation API that does pretty much the same thing except that uses TCP/IP to communicate directly with the ODI agent.

Clicking on OdiInvoke will display the WSDL, this information is required for testing.

If you intend on using the public web service you will need a source application that will generate and handle SOAP requests which is the protocol for communicating with Web Services. For testing purposes, I highly recommend soapUI and that is what I will be using to demonstrate any SOAP related material, you could use the ODI tool ODIInvokeWebServices but I am going to cover that off later.

If you are using soapUI then you can just create a new project and put in the url to the ODIinvoke WSDL.



This will generate all the operations that are available.



If you want to get a list of the available Scenarios that can be executed then the listScenario operation can be used, in soapUI it is simple as opening up the request editor and filling in the details and then executing the request.



Executing a scenario is just as simple though you will require an agent running, the format for the SOAP request look like this >



Many of the parameters are optional so once you have stripped out all unneeded elements an example would be :-



A successful request will produce a result of :-



The session number can be traced back to the operator where you can see the results of the execution.
If there are any problems with the request the response would follow the format of :-



Well that is all fine running SOAP requests from a testing GUI but what if you want to build them into a functional application, there are a number of different programming options out there and in the next blog I will use my preferred choice Java to try and accomplish this.