When you look at the list of Technologies listed in ODI 12.2.1 Topology, you can see a new entry: SOAP Web Services. Prior to having this Technology defined here, developers connecting to Web Services in ODI had to enter all the connectivity details in their packages when they designed the Web Service call. Now they can predefine the connection parameters and security policies, and then focus separately on the implementation of the Web Service call. We will see here how to define and use this Technology .
Prior to ODI 12.2.1, when invoking a Web Service with the tool OdiInvokeWebService, ODI developers had to enter all the necessary parameters to connect to that Web Service. This limited the type of parameters that could be used. Now with the availability of the SOAP Web Service Technology in the Topology navigator, support for Web Services is dramatically improved.
Figure 1: Web Services in ODI Topology
Figure 2: Web Services list supported security policies
For ODI to support OWSM policies, we first need a JEE agent, and we need the underlying WLS infrastructure to be properly configured.
The first step is to install and configure a JEE agent.
The installation manual available here details the configuration of the JEE agent.
There is one step that we did not follow from the installation guide, and only because that made debugging easier for us: we wanted all errors reported in the console used to start the agent. To do this, we started the JEE agent directly from the command line instead of using NodeManager. The command line used for this is:
where ODI_server1 is the name of the managed server that hosts the agent. If you have any doubts about the name of your managed server, you can retrieve this name from the WLS domain directory structure:
Or you can see it from the Enterprise Manager view (typically http://<yourhost>:7001/em):
Figure 3: ODI Managed Server name
if you start the JEE agent manually as stated above, you will be prompted for your WLS username and password. You are not prompted if you use NodeManager.
Now that you have your JEE agent installed, you need to setup OWSM as part of your infrastructure. Start enterprise manager and select the menu option: WeblogicDomain/Security/Keystore:
Figure 4: Create a keystore
Figure 5: Existing keystores
You need to add a new stripe named ‘owsm’:
Figure 6: create an 'owsm' stripe
This new stripe will be listed along with the others, but so far it is empty:
Figure 7: Created OWSM stripe
Select it and click Create Keystore. Name that keystore ‘keystore’ (exactly!), select Policy protection and leave the rest empty:
Figure 8: Create a Keystore named 'keystore'
Now you need to select the certificate from the service you are trying to connect to. I retrieved mine from the WSDL for the service I was using. You can also retrieve it from your web browser. In that case, enter the URL to the service in your web browser. The browser will have an option to save the certificate as a file. If you use Firefox, you can go to Options/Advanced/Certificates and click View Certificate. From there you can export the certificate.
Figure 9: saving certificate with FireFox
Figure 10: saving certificate with Chrome
Other browsers have similar options to save the certificate.
Back to our keystore configuration, select the file you have created when you saved the certificate:
Figure 11: import the certificate
You are all set now with the infrastructure configuration.
To validate this configuration we connected to Oracle HCM (Oracle Cloud’s Human Capital Management), which leverages security policies. For this we create a physical Data Server in the ODI Topology navigator. We provide the WSDL URL and a username that has the necessary privileges for the operation that we want to perform with this Web Service.
Figure 12: Create a Web Service in ODI Topology
Then in the physical schema definition we can select the Service, Port and OWSM security policy. Note that the Service and Port will be listed automatically by ODI as it connects to the Web Service.
Figure 13: OWSM policies support in ODI Topology
You can then add OWSM policies as needed.
To test this Web Service connection, we need to create a package in which we add the tool OdiInvokeWebService:
Figure 14: odiInvokeWebService
The important steps here are:
Figure 15: parameters for odiInvokeWebService[/cap
A successful execution will prove that you can connect successfully, using the OWSM security policy.
Figure 16: successful secure Web Service connection
If the connection fails, it will be important to make sure that:
With only a few configuration steps, we can now leverage OWSM security policies with ODI, which gives us access to the most advanced security for Web Services calls without any complex development effort in the ODI Studio.
For more Oracle Data Integrator best practices, tips, tricks, and guidance that the A-Team members gain from real-world experiences working with customers and partners, visit Oracle A-team Chronicles for Oracle Data Integrator (ODI).
Special thanks to Sebu T. Koleh and Naveen Nahanta for their help and support with the concepts details here.