ODI Studio, External Authentication and Multiple Environments

I wanted to go over a scenario that arises when you have enterprise licensing for ODI and how this relates to authentication. Specifically, when ODI is authenticated externally. Now, this is not something that most of us EPM developers are used to, but this is standard when BIAPPS is set up. Normally, we would just be using ODI with locally managed security. When external security is enabled, ODI will use Oracle Internet Directory or WebLogic to authenticate users. A rough diagram of these scenarios may look like this:

As you can see, while internal authentication depends on the ODI master repository to help with authentications, external authentication will pass through to WebLogic, based on 2 files on the client layer, the cwallet.sso file and the jps-config.jse.xml file. They can be found in your ODI client install directory (if you were set up by the administrator).

This post isn’t about enabling external authentication, but about how you go about setting up your ODI connections if you have multiple ODI environments. For instance, in my current case, we have 4 ODI environments (Development, Test, QA and Prod).

There are different .sso and .xml files for each environment. So, each time I need to log on to ODI on a second environment, I need to update the .sso and .xml files with the right ones! This becomes very hard to keep straight over time, and it becomes pretty frustrating.

Exhibit A

In order to keep things straight, I referred back to a post on this very blog by that doyen of data integration, young Pete Strayer. Sturdy Pete mentions that the connection information is stored locally on each machine in the snps_login_work.xml file.

If you open up the file, you can see the different connections that have been accessed on your machine.

Exhibit B

In order to solve this issue, my fix involved setting up a location on my machine with multiple folders, as seen below.

Each folder would contain the .sso and .xml files needed for that environment.

They would also contain an snps_login_work.xml. This file though would be edited to contain only the connection information for that environment. In other words, the “DEV” folder would only have “DEV” security and connection files. Nothing else.

Exhibit C

The last step to solving the problem involves setting up a simple batch script to move the files to the right location. I consider this to be a simple starter script, so haven’t bothered with error trapping and such. Also, you may want to change the “ODICLIENT” location based on where your client is installed.

Now, if I execute the script, I get prompted for the environment that I would like to access. I entered “QA” in this case.

And, ODI opens up pointing to the right environment with the correct security files copied over.

And there you have it. No more copying and pasting of security files each time you need to access ODI on a different environment.