Introduction

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 .

Create the Data Server

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

In particular, this technology supports OWSM policies for enhanced security configuration:

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.

Install and configure a JEE agent

The first step is to install and configure a JEE agent.

To make sure that you have the framework required for ODI, you can download the Fusion Middleware Infrastructure directly from the ODI download page, along with the ODI installation program.

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:

startManagedWeblogic ODI_server1

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:

<WLS_HOME>/user_projects/domains/<myDomain>/servers/ODI_server1

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.

 Configure the JEE agent to support OWSM policies

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

Here you should see two ‘Stripes’ (unless you have already added more) as shown on the following screenshot: system and opss.

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

For Chrome, click on the green lock in front of the URL  and click Connection/Certificate information. The Details tab has a Copy to File… button that allows you to save the certificate:

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.

Define the Connection to the Web Service

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.

Test the Connection to the Web Service

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:

• Select the logical schema that points to the physical schema created in the previous step (HCM in the picture below);
• Do not forget to set the XML request payload – this is the body of you Web Service request.

Figure 15: parameters for odiInvokeWebService

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:

• The policies defined in ODI Topology match the ones required by the web service;
• The user used to connect to the web service has enough privileges with the target application to perform the required task.

Conclusion

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).

Acknowledgements

Special thanks to Sebu T. Koleh and Naveen Nahanta for their help and support with the concepts details here.

References

• OWSM documentation
• Understand OWSM policy framework
• Understand policies
• Topology Configurations for Web Services in Oracle Data Integrator (ODI) 12.2.1
• ODI 12c documentation for OdiInvokeWebService

All content listed on this page is the property of Oracle Corp. Redistribution not allowed without written permission