Calc Manager Issue

I applied the Calc Manager patch to a sandbox VM in anticipation of my upcoming Kscope presentation “Essbase CDFs Demystifyied.” As I was working on my CDF demos for this presentation, I found that the @CalcMgrMDXExport CDF was having an issue as my Essbase application started up:

[Thu Jun 15 12:45:49 2017]Local/Samp2///8632/Warning(1200490)
Wrong java method specification [com.hyperion.calcmgr.common.cdf.MDXExport.exportData(String,String,String,String,String,String,String,String,String,String,String,String,String,String,String)] (function [@CalcMgrMDXExport]): [specified method not found:com.hyperion.calcmgr.common.cdf.MDXExport::exportData(java.lang.String,java.lang.String,java.lang.String,java.lang.String,java.lang.String,java.lang.String,java.lang.String,java.lang.String,java.lang.String,java.lang.String,java.lang.String,java.lang.String,java.lang.String,java.lang.String,java.lang.String)]

This error is saying that the exportData method of the MDXExport class with 15 String input parameters is not valid. I peeked at the code and found that in, the exportData method is now looking for 19 String variables. It sounds like this was not planned, so we can look forward to a new @CalcMgrMDXExport-like CDF in the near future.

If you have already applied the Calc Manager patch, you can apply a quick fix by changing the CDF registration and editing your calculation scripts to include four additional null strings at the end of your @CalcMgrMDXExport calls.

To fix the issue, you can run the following MaxL statement to register the CDF with the appropriate number of parameters:

create or replace function ‘@CalcMgrMDXExport’ as ‘com.hyperion.calcmgr.common.cdf.MDXExport.exportData(String,String,String,String,String,String,String,String,String,String,String,String,String,String,String,String,String,String,String)’ spec ‘@CalcMgrMDXExport(key,usr,pwd,file,app,db,svr,colAxs,rowAxs,sep,msg,Unique,Alias,supZero,rowHdrs,whereMDX,srcMap,tgtMap,supColH)’ with property runtime

I had to resort to shorthand on the “spec” field because Essbase only allows 128 bytes in that field if you register the CDFs through MaxL or EAS. I believe there may be more leeway for longer fields if you use the Java API to register CDFs.

After running the MaxL to register the CDF and restarting my application, it looks like all is well with the world:

[Thu Jun 15 15:47:08 2017]Local/Samp2///1960/Info(1200445)
External [GLOBAL] function [@CalcMgrMDXExport] registered OK

The additional fields needed for the @CalcMgrMDXExport method in this version of Calc Manager are as follows (in order):

  • String wheremdx
  • String srcMappings
  • String targetMappings
  • String supressColHeaders

The wheremdx field, if used, allows me to filter my results coming back from the source application. This field is optional and can be left null.

The srcMappings and targetMappings fields, if used, allow mapping members from source to target. This would allow me to map account 1234 to 4567 on the export by providing “1234” for the srcMappings field and “4567” in the targetMappings field. This field is also optional and can be left null.

The supressColHeaders accepts a string “true” or “yes” to suppress the column headers. Any other value (including null) will result in the output file containing the headers.

I have submitted an SR and expect a bug to be filed in the next few days. I’ll submit a new post once we have an updated Calc Manager patch that fixes this issue and includes a new @CalcMgr* CDF.


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s