ODI 11.1.1.5 with the 10.1.3.6.8 odihapp_essbase.jar & odihapp_common.jar

Question

I've got an installation of ODI 11.1.1.5 on 64 bit Windows 2008 R2 server. Both ODI client and server are on the same box.
I have been able to successfully extract ASOSamp's dimensions to a SQL Server 2008 Express table. Wonderful, very nice, etc.
However, when I try to load from a table, using a load rule, I cannot do so and get the (abbreviated) error:
org.apache.bsf.BSFException: exception from Jython:
Traceback (most recent call last):
File "<string>", line 61, in <module>
     at com.hyperion.odi.essbase.AbstractEssbaseWriter.beginLoad(Unknown Source)
     at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
     at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
     at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
     at java.lang.reflect.Method.invoke(Method.java:597)
I read the Great and Good John Goodwin's blog and OTN posts and see the the answer seems to be to download the patch for 10.1.3.6.8, grab the odihapp_essbase.jar and the odihapp_common.jar files, and copy them in place of the existing jar files.
Figuring that if it's in there more than once, I better copy it to all locations so I've done just that at:
C:\Oracle\product\11.1.1\Oracle_ODI_1\oracledi\client\jdev\extensions\oracle.odi.navigator\lib
C:\Oracle\product\11.1.1\Oracle_ODI_1\oracledi.sdk\lib
I start the OPMN services back up (yes, I had to stop them to do the file copy and rename) and then try out my interface with the load of metadata from SQL to Essbase. Hallelujah it works! So, I figure, why not try running my extract process? Surely that will work, right?
Bzzzt! I get the following (again abbreviated) message in Operator:
org.apache.bsf.BSFException: exception from Jython:
Traceback (most recent call last):
File "<string>", line 89, in <module>
     at com.hyperion.odi.essbase.ODIEssbaseMetaReader.validateExtractOptions(Unknown Source)
     at com.hyperion.odi.essbase.AbstractEssbaseReader.beginExtract(Unknown Source)
     at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
     at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
     at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
     at java.lang.reflect.Method.invoke(Method.java:597)
This is pretty neat, in a not so neat kind of way.
I can:
1) Go with 11.1.1.5's drivers and extract metadata from Essbase, but not load new metadata.
2) Or, using 10.1.3.6.8's drivers I can load new metadata to Essbase, but I can't extract it.
I haven't even tried to load data yet.
What oh what am i doing wrong? Has anyone tried to do both an extract AND a load with 11.1.1.5 and the 10.1.3.6.8 patch's jar files?
I am just about at the point where I'm going to forget the whole load process through ODI and instead do it in a MaxL script that I'll automate through a package. I sort of like that better because then I can use very simple SQL in the load rule instead of the kind of lame-o SQL-to-text-to-Essbase process that ODI does when loading metadata, but really it shouldn't have to be that way. In theory, with larger datasets there should even be a performance premium with the MaxL/SQL load rule but I haven't gotten there yet nor do I really want to.
Thanks for any help.
Regards,
Cameron Lackpour

Answer 1

John,
I'm very happy to report that the importation of the 10.1.3.6.8 KM fixed it! Thank you, again, for providing leadership on ODI/EPM. I found the Support KM that said to pull out the 10.1.3.6.8 jar files but not a word about the KM. Perhaps they should more closely read your blog? :)
I was not looking forward to, at all, a installation of 11.1.1.3. You have a good idea of my utter ineptitude wrt installs -- yeah, I get them working, sort of, eventually, but oh the pain. At least it's up in the cloud so I could just spawn a new clean 11.1.2.1 non-ODI environment, but that would be two days of my life consumed.
I may still go with the MaxL approach to load the dimensions -- the more I think about the way ODI does an Essbase data and dim load, the less I'm impressed. I see:
1) A SQL to text file conversion. Depending on the dimension size, there could be a hit on performance. Not really a big deal, but odd for sure.
2) The inability to do a suppress verification when loading multiple dimensions (ironically, you can't do that with SQL dimension rules, but you can with text; ODI extracts SQL to text but then doesn't have a way of joining together the loads like MaxL does.) on a big db.
3) The inability to load to buffers (or kick off loads to buffers in parallel).
Oh well, it's not like ODI can't fire this stuff off a command object tied to MaxL, I'm just sort of surprised it doesn't have that functionality natively. Maybe that's what Oracle figured everyone would do.
Thanks again for your help.
Regards,
Cameron Lackpour