Recently on the ODI forum an issue was brought to my attention when using 184.108.40.206, Hyperion planning and the staging area set to the memory engine. Now I have used ODI 220.127.116.11 with the Hyperion knowledge modules and not really experienced any major issues but I have not had the opportunity to test them out on 18.104.22.168
In the support matrix for 22.214.171.124 it says the modules are certified for 126.96.36.199+
Considering most of the technologies say 188.8.131.52+ I assuming that means 184.108.40.206 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 220.127.116.11
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 18.104.22.168 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 22.214.171.124 and then recreated using 126.96.36.199
The only difference with 188.8.131.52 is it looks to includes patches that I wrote about here for 10g which provide an extra column for sortid.
Executing the interface on 184.108.40.206 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 220.127.116.11 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 18.104.22.168 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 22.214.171.124
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.