Sunday, 21 December 2008

ODI Release Update

There are a couple of updates to mention in regards to ODI, firstly a new patch is available from metalink3 - 10.1.3.4.7_01, .7 was released and then quickly .7_01 because of an issue adding projects.

The patch addresses two issues with using essbase.

7525003: Moving large amount of data from Essbase to Oracle generates timeout error.

7520405: Issue extracting large or long queries against Essbase KM.

It always worth moving to the latest patch release and installing the patches is simple it just involves copying over a new set of files.

The other update to mention is that ODI 10.1.3.5 has been released, looking through the release notes there have been a few new additions that include a new lightweight designer, which allows users to modify the mappings of an interface through a web browser, it is something I am interested in looking at even though there was lightweight designer in the previous release and I have never got round to looking at it yet, anyway I will probably cover it in a future blog.

Interesting in the release notes it points out that the Hyperion KMs (Hyperion Essbase, Hyperion Financial Management, and Hyperion Planning) are certified for Hyperion 11.1.1
As I have been using ODI with version 11 and hit upon a few problems this is good news and something I am going to test, it will be interesting to see if that have actually made any major updates to the Java behind the KMs. You can view the release notes here.

Well as it has been released I might as well go through and try and upgrade my existing ODI installation and see if I hit upon any issues.

Before you upgrade it is important to back up the existing installation directory of ODI, if you have a service running the agent make sure you stop it before copying the directory, the database repositories master/work will also need backing up.

When you have backed up extract the software and run \setup\Windows\setup.bat. choose Deinstall Products and remove ODI 10.1.3.4.0



Once it has been removed just follow the installation screens, installing is the same as previous versions and I have already been through the 10.1.3.4 install in a previous blog.

You will now have to restore from your backup \oracledi\bin\odiparams.bat and anything with .xml or .layout file types, most of them may have been left after uninstalling.

Next to upgrade the master repository, Start Menu, select Programs > Oracle Data Integrator > Repository Management > Master Repository Upgrade, you should be able to choose your work existing work repository from login dropdown.

To upgrade your work repository, open the topology manager, select the repositories tab, right click your work repository and select upgrade.

Your current projects will include the old Knowledge Modules, you can continue to use them without any issues or you can choose to import them again, I don't think you will need to replace any of the Hyperion KMs as none of the descriptions or dates seem to be updated so they are probably exactly the same and only the Java drivers have been updated.

If you are using an agent start it up again and that should be the upgrade completed.

I just had a quick look to see if Oracle are correct in saying it is certified for 11.1.1, it is true they have tidied up some of the code but I still notice there is going to be a problem if you try and use a calc script to extract data. In the ODIEssbaseDataReader.class it still checks the version in the following way.



If the version is greater than 9 and less than a point release of 3 then the exception will be raised so for 11.1 users it will be raised and the integration halted, not 11.1.1 certified then.

I am also assuming that the issues fixed in the patch .07 for the previous version of ODI are included in this new release, I am not sure if there is an easy way of finding out though...

1 comment:

Badger said...

John
in the description, you say:
"Capture processes: Journalizing captures the changes in the source datastores either by
creating triggers on the data tables.", but you don't give the other half, which is of course "or using the native logmining features of databases such as Oracle to deliver the change feed into the Journal table".
Great blog BTW.