2017-03-31 11:44:37 UTC
I would like to share my experience in using the AxisEasyInvokeSoapWS FC in TDI, the issues I faced, the solutions I found and useful links for getting started.
I will try to keep this short but informative and help also those that are not software developers (such as myself) achieve a working solution.
The first think you must absolutely do is go through this excellent guide by Stephen Swann:
Because this blog is a bit outdated (2011) you will probably face your first issue when using the Complex Types Generator function component -- with your JAVA SDK complaining about obsolete declarations or something of sorts.
The SOLUTION is to (temporarily) install an older version of JDK such as JDK1.6.0_u23.This will enable you to generate your complex functions which is basically a jar file containing the necessary class definitions for creating and using objects in TDI scripts for maintaining your specific WebService.
This brings us to another issue you may face: In order for the new JAR file to take effect in TDI you may need to restart your whole PC and not just the TDI tool.
By following these steps you should be able to replicate the example provided in Stephe's blog and get started with your own WS.
Configuring the Function Component to fit your own WS
As it is often the case with most example guides, the documented procedure in Stephen's blog applies for very simple scenarios and simple WSs that my not be applicable to your case as it was not in mine.
For this reason I will try to point out certain things to look for when configuring TDI to fit your case.
The first thing to do is use the Java Decompiler referenced in Stephen's blog and identify the specific function defined in your WS that you will be calling. This is the function that you will reference in the connection tab of the FC under "SOAP Operation". It is important to also note the input parameters required for this function that you will also reference in the same tab under "Operation Parameters".
You may find that the input parameter(s) to your function is of type OBJECT (you will found out about this using the Java decompiler) and as such you will then need to create this object and set your actual values before passing this to your WS function by using a TDI script component.
Specifically, you will need to find the constructor functions and setParameter functions of your webservices that you will use in the script.
Let's demonstrate this by using an example:
-Suppose the function I need to call is named "CreateUser" (SOAP OPERATION)
-Suppose the input parameter required for this function is named "UserParameters" (Operation Parameters).
-Suppose my WS class is called "com.examplewebservice.www"
-Using the Java decompiler we can find the constructor function for "UserParameters" and the function for setting the parameters for this object.
Then we can create a script like below to prepare the input object before passing it to the actual WS FC:
var create_user_object = com.examplewebservice.www.UserParameters();
At this point the UserParameters object can be used by the Axis function component that runs right after the above script.
Before firing this up I strongly urge you to use the well known SOAPUI application (there is a free version) and test that the function parameters you set will return a successful result by the WS.
In this way you can identify the mandatory parameters needed by the WebService and any other restrictions regarding the parameter values etc. Of course, you can always apply the same logic to the 'return' attribute in the input map of your Axis component to get the WS response but I found using SOAPUI is more helpful.
Dealing with SSL Protected WebServices
Most of the WebServices nowadays are SSL protected and without correctly installing the required certificate you are more than likely to get an HTTPS error in TDI.
The first thing to do is connect to your WebService using a browser and (depending on your browser) go to the security settings / advanced/ view certificate and download the certificate on your PC.
Then I suggest changing the extension of the certificate file to ".cer" and use a tool like ikeyman to install the certificate to the following trust stores:
- $ /opt/IBM/TDI/V7.1.1/jvm/jre/bin/keytool -import -trustcacerts -alias AddTrust-Global-CA -file AddTrust-Global-CA.pem -keystore /home/gattis/TDI/testserver.jks -storepass server
$ /opt/IBM/TDI/V7.1.1/jvm/jre/bin/keytool -import -trustcacerts -alias AddTrust-Global-CA -file AddTrust-Global-CA.pem -keystore /home/gattis/TDI/serverapi/testadmin.jks -storepass administrator
/opt/IBM/TDI/V7.1.1/jvm/jre/bin/keytool -import -trustcacerts -alias OHIO_CA_Singer -file OHIO_Signer.cer -keystore /opt/IBM/TDI/V7.1.1/testserver.jks -storepass server
/opt/IBM/TDI/V7.1.1/jvm/jre/bin/keytool -import -trustcacerts -alias OHIO_CA_Singer -file OHIO_Signer.cer -keystore /opt/IBM/TDI/V7.1.1/serverapi/testadmin.jks -storepass administrator
TDI will now trust the WebService certificate and establish the SSL/TSL connection.
I hope you found this post helpful, it has been written on the assumption that you read Stephen's blog first since I did not want to repeat much of the information written there.
Do let me know if you have any comments/suggestions - Thank you!