ODI 11.1.1.7 : Works with JDK 7 only !!!

ODI 11.1.1.7 has been released and it can work normally with JDK 7 only. Although ODI will install successfully with JDK/JRE 1.6, the certification matrix says its compatible only with JDK 7.

I was trying to work with the ODI SDK of 11.1.1.7 and everything worked fine until I encountered 'NoClassDefFound' exception. Reason : I was runnning a JVM of 1.6,

As a caution, never try to install ODI 11.1.1.7 to work with Oracle EPM 11.1.2.2, since EPM 11.1.2.2 does not support JDK 7.

Better have a look at certification matrix before installing version 11.1.1.7

Best of Luck !!!

Doing Static Control Check in a ODI Package

This is something like finding a cheat code while playing video games.

The problem was that I wanted to check a source table for constraints (static control check if you may). 

Normally it is done using the 'Check' option on the data-store, but what if I want to automate it in a package and don't want to go right-clicking the datastores everytime ?

To know what static control is, search ODIExperts blog or John Goodwin's blog. No point in re-inventing the wheel :)

I just thought of dragging the table (data store) onto the package area and voila !!, got the option to perform the check
 Following are the constraints that I wanted to check in a package

Then I dragged the table directly onto the Package diagram 

If you see the properties pane, you will be able to select the 'Datastore check' which will basically execute the constraints check on the table 

ODI Myth #1 : Cannot be used for bulk loading or very high volumes of Data

I always get into a debate where people say that ODI doesn't do bulk integration or very high volume of data integration that smoothly as compared to its competitors. So is it really true ? I deal with this in sections

1. Native Essbase Data load vs. Oracle Data Integrator Load
Native Essbase load (using Load rules and EAS console) is faster than integration done using Oracle Data Integrator. But the amount of flexibilty that ODI provides in terms of mappings and transformations sometimes outweighs the lesser load time taken by native technique. Also, the use or selection of Staging area is crucial in deciding the load time. Using Sunopsis memory engine (Java heap in other words) as Staging drastically increases the load time, sometimes even failing the process. Staging area should always be a good relational database or if possible, the source itself.

2. Relational Databases
Having worked on integration projects involving pure relational tables and lots of data. I have come to know that there are few things that decide how good or bad the load times are going to be

1. Selection of Staging area
2. Deciding which transformation is executed where
3. Selection of the right Knowledge module
4. Table joins and lookups.
4 And ofcourse, how good the source, target and staging area relational databases are in terms of memory and processing speeds

The best part is that ODI gives a vast amount of flexibility when dealing the question of 'how to load data most efficiently'. It is through trial and errors that we arrive at the best possible solution. So, in my opinion, ODI is not that bad when it comes to loading high volumes of data.