ODI Series - Web Services Part 2

Last time I went through setting up axis2 web services with ODI and how to execute services using a SOAP utility, if you are ever considering developing your own application and there is a requirement to execute ODI scenarios then you could either do this directly by using the Java invocation API but this relies on there being availability of a tcp/ip connectivity to the ODI agent, this is not always going a viable solution so using a web service can be a more appealing option.

You can obviously handle SOAP requests with one of the multitude of programming languages out there but I am going to show how this can be done with Java, mainly because I am a convert to Java, I am trying to improve my skills in this area and it fits in well with the Oracle EPM APIs.

Firstly the standard distribution of Axis 2 is required, in the previous blog I downloaded the war file but this doesn’t contain all the required Java packages.



Once the distribution files have been downloaded and extracted then what we need is some method in which a Java API can interact with the ODIinvoke web service, luckily included with axis2 is a useful utility that converts a WSDL to Java, aptly named WSDL2Java.

The utility will create what is known as a client stub, which is basically a Java class that contains all the information to communicate with the web service and its operations.

The syntax to create the stub is :- WSDL2Java -uri <wsdl location> -p <name-of-package-to-create-stub-in> -d adb –s –o <location-of-output>

The –d adb parameter specifies to use the ADB data binding method to create the client (if you want to understand more about the different methods information is available in the axis2 documentation, it certainly goes into far more depth than I can handle today)

The –s parameter stands for synchronous method so the client will wait for a response from the web service before continuing.



Running the utility outputs three files to the directory specified and creates the package structure.



Each file represents a different type of protocol that can be used; I am going to use the SOAP1.2 just because it is the latest and probably more robust, I wouldn’t be too concerned about what is in the java files unless you are a Java guru and wish to reach enlightenment.

Now we can move on to writing some simple Java, depending on what Java IDE you are using you will need to add the axis2 jar files and include the include the generated stub.

If you followed the blog where I used the Java ODI invocation API then using this client follows pretty much the same concept.



What I am going to do first is to retrieve a list of available scenarios that can be executed.

When creating a new instance of the OdiInvokeOdiInvokeSOAP12Port_httpStub class it requires one String variable in the constructor and that is the URL of the web service that is going to be invoked.



Once you have created the instance, you can view the methods that are available.



listScenario is the method to retrieve the available scenarios though this requires an instance of ListScenarioRequest to be passed into it.

ListScenarioRequest has a method call setListScenarioRequest that requires an instance of RepositoryConnectionType3 to be passed into it.

I am not sure why it is done like this or it a fault of the conversion of the WSDL but there are three different classes of RepositoryConnectionType, to use the ListScenarioRequest you need to use 2 and 3.



RepositoryConnectionType2 has a number of methods to set items such as the ODI username/password, JDBC connection details.



RepositoryConnectionType3 you can set the work repository.



Basically what we are doing the same details as when I set up the SOAP request in the previous blog.



The only difference is that we are using the various methods of the class to populate this information.



Once all the information has been passed into the methods, the web service can be invoked and the response dealt with.



The request is sent by using the listScenario method and a response is returned with an object type of ListScenarioResponse, this contains a method to retrieve an array of Scenario Types, then all I do is iterate through each scenario type and output the Scenario name and version.



You can easily convert this to say a jsp script that displays the scenarios in a drop down box ready to be executed from a web page.



Running a scenario follows the same concept and is exactly the same as using the invocation API, to run a scenario you could put something like this together.



Combining the listing of scenarios and executing a scenario you could update the jsp script to execute a scenario based on the selection from the dropdown, I am not going to show that because I feel I am done for today and hopefully it has given you an insight into how you can work with Java and the ODI web services.

Next time I am going to take you through Data Services in ODI and go through step by step on setting it up.