Recently on the ODI forum an issue was brought to my attention when using 188.8.131.52, Hyperion planning and the staging area set to the memory engine. Now I have used ODI 184.108.40.206 with the Hyperion knowledge modules and not really experienced any major issues but I have not had the opportunity to test them out on 220.127.116.11
In the support matrix for 18.104.22.168 it says the modules are certified for 22.214.171.124+
Considering most of the technologies say 126.96.36.199+ I assuming that means 188.8.131.52 should be supported for the Hyperion set.
The issue with loading planning metadata using the memory engine as the staging area can easily be replicated.
A simple interface is created loading one record from a flat file source a dimension in planning, it doesn’t really matter which dimension it is as issue occurs across them all.
The equivalent interface definitely works on 184.108.40.206
The staging area is set to use the Memory Engine.
The error generated is
com.hyperion.odi.planning.ODIPlanningException: com.hyperion.odi.planning.ODIPlanningException: The source result set contains column [C1_ACCOUNT] which has no corresponding column on the planning side.
For some reason "C1_ACCOUNT" is being passed to planning instead of "Account"
The code generated is same as on previous versions and querying the memory engine seems to return the correct results.
So there is a workaround to the issue but if you are considering moving to 220.127.116.11 and currently use the memory engine in planning interfaces it is one to watch out for until a fix arrives.
While I had the chance I thought I would just test out a metadata load to essbase to see if there were any issues.
Once again a simple interface was created to load one record of metadata to an essbase database; the interface was tested on 18.104.22.168 and then recreated using 22.214.171.124
The only difference with 126.96.36.199 is it looks to includes patches that I wrote about here for 10g which provide an extra column for sortid.
Executing the interface on 188.8.131.52 generates and a Java related error and causes the interface to fail.
I thought maybe it was down the ODI installation so I tested out on a different 184.108.40.206 install and the same problem exists, so either I am really unlucky which could easily be the case or there is definitely a problem (if anybody else has tried this and doesn’t see the issue then let me know)
It is also worth pointing out this issue is only with loading metadata, loading data and extracting metadata still works without any issues.
As the error points towards to an issue with java files that the modules use I thought I would look into replacing them with ones from another version.
I decided to go with ones from 10.1.3.6.8 as these contain the fixes that include the sort id and are newer than ones in the 220.127.116.11 version.
The files replaced were odihapp_common.jar and odihapp_essbase.jar though it should be possible just to replace odihapp_essbase.jar.
If you look at the file size the 10.1.3.6.8 ones are bigger so I assuming contains additional code.
After replacing the jar files the same interface executes without any issues so it does look like a problem with the java files released with 18.104.22.168
Also make sure you import the KM - "LKM Hyperion Essbase METADATA to SQL" from the 10.1.3.6.8 release as it contains required extra code otherwise you will receive an error while extracting metadata from essbase.
I know this is not the official way of going about things but at least the essbase interfaces successfully complete and is a workaround if you are also experiencing the same issue until an official fix from Oracle comes along.
Update: If you experience the above issues then have a read of the following in Oracle support:
Unable to load Essbase Metadata using Oracle Data Integrator 22.214.171.124 (Doc ID 1437498.1)
Patch 12905298: INTERFACE FAILS TO INTEGRATE ON STEP "LOAD DATA INTO PLANNING"