Calc Manager

Calc Manager 11.1.2.4.010 Issue

I applied the Calc Manager 11.1.2.4.010 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 11.1.2.4.010, 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 11.1.2.4.010 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.

Advertisements

Calculation Manager 11.1.2.4.002

As I posted the other day, Caclulation Manager 11.1.2.3.505 was released.  Not only did it include the fixes to the CDF declarations, it also contained some new CDFs we haven’t seen before.  Well, Calculation Manager 11.1.2.4.002 was released on Monday (patch number 20830325) and contains the same fixes as 11.1.2.3.505.

This version of Calculation Manager contains the new CDFs as well as fixes the issues with the CDF registration.  I think it’s great that the Calculation Manager team continues to crank out new CDFs for us to use.  Beyond that, I am very impressed that they have caught up the 11.1.2.3.50x Calc Manager to the 11.1.2.4.002 version.  It would be very simple for them to say that the new CDFs will only be added to the latest release, but they have kept the 11.1.2.3 version up-to-date.  Kudos to Oracle and the Calculation Manager product team!

Calculation Manager 11.1.2.3.505

On Tuesday, 6/9, Calculation Manager patch set update 11.1.2.3.505 was released. I have previously written about the errors in the CDF registration and how to fix those. I am very happy to report that all of the CDFs are now registered properly in 11.1.2.3.505. Not only that, but there are some new CDFs to report with this version of Calculation Manager as well. Calculation Manager 11.1.2.3.505 is a patch set update now available on My Oracle Support as patch number 20968612.

New Functions in Calc Manager 11.1.2.3.505:

@CalcMgrPadText (text,length,padText,append) – Fills the text with a padding text before or after the text to make up the length.

  • @CalcMgrPadText(“01″,5,”0”,@_true) = 01000
  • @CalcMgrPadText(“01″,5,”0”,@_false) = 00001

@CalcMgrMatches(text, regExpr, ignoreCase) – Returns true, if the first substring of this string that matches the given regular expression. For regular expression, please refer to java docs for java.util.regex.Pattern.

  • @CalcMgrMatches(“AsSeT”, “(Asset|Liability|Income|Expense|Equity)”, @_false) = true
  • @CalcMgrMatches(“CAT”, “c*”, @_true) = true

@CalcMgrFindFirst(text, regExpr, ignoreCase) – Find the first substring of this string that matches the given regular expression. For regular expression, please refer to java docs for java.util.regex.Pattern.

  • @CalcMgrFindFirst(“We are searching for a string in this sentence.”, “string”, @_false) = “string”
  • @CalcMgrFindFirst(“Can’t find this STRING anywhere”, “string”, @_true) = “Can’t find this STRING anywhere”

@CalcMgrFindLast(text, regExpr, ignoreCase) – Find the last substring of this string that matches the given regular expression. For regular expression, please refer to java docs for java.util.regex.Pattern.

  • @CalcMgrFindFirst(“acatamaranbatarang”, “ran?”, @_false) = “rang”

@CalcMgrDoubleFromString(text) – Returns a double.

  • @CalcMgrDoubleFromString(“12.54”) = 12.54(Double)
  • @CalcMgrDoubleFromString(“test”) = 0.0(Double)

@CalcMgrGetCurrentDateTime() – Returns the current date and time in the YYYYMMDDHHMMSS format.

  • @CalcMgrGetCurrentDateTime() = 20140101143001

@CalcMgrGetCustomDateTime(year,month,day,hour,min,sec) – Returns the custom date and time in the YYYYMMDDHHMMSS format.

  • @CalcMgrGetCustomDateTime(2015,06,11,21,27,01) = 20150611212701

@CalcMgrGetDateTimePart(date,date_part_ex) – Returns the Year/Month/Week/Day/DayOfYear/Weekday/Hour/Minute/Second as a number from date.

  • Options for the date_part_ex parameter are: Year, Month, DayofMonth, WeekOfYear, WeekOfMonth, DayOfYear, Hour, Minute, or Second.  These are Strings passed and the capitalization does not matter.
  • @CalcMgrGetDatePart (20141230052736, Hour) = 05
  • @CalcMgrGetDatePart (20141230125430, mInUtE) = 54

@CalcMgrMesssageFormat(text,parameters) – Creates a String with the given pattern and uses it to format the given arguments.

  • This one is interesting, it accepts the parameters to basically create a dynamic string that can be used in messages. You might pass those messages to a custom log file or even into an email for your administrators.

Calc Manager 11.1.2.3.503 released

Three blog posts in three days? He’s on fire. Maybe that’s not as highbrow as Cameron Lackpour’s references; however, if you’re in your 30’s, you probably understand.

A couple of days ago, I posted the fix to five of the Calc Manager CDFs in 11.1.2.3.502. Well, as luck would have it, a new patch to Calc Manager 11.1.2.3 was released a few days ago on January 15. As one that frequents this blog, I’m sure you all went right out and made those changes to your essfunc.xml files and are wondering if that was necessary or if this release fixes those CDFs for you.

I downloaded and applied the patch to my laptop’s sandbox EPM system and found that all 55 of the @CalcMgr* functions from 11.1.2.3.502 persist in 11.1.2.3.503. Not only do the same CDFs persist, but so do all five errors on the CDF declarations. I compared the essfunc.xml files from the two patches and found only a few differences but nothing that would materially change the implementation of the CDFs between 11.1.2.3.502 and 11.1.2.3.503.

To sum it all up, if you have fixed your CDFs in 11.1.2.3.502 and are planning to apply 11.1.2.3.503 (patch number 19927906), then prepare to re-fix your CDF specifications in either EAS or the essfunc.xml file again.  The great news is that if you have used some of the cool functionality in Calc Manager 11.1.2.3.502, you can still use it in 11.1.2.3.503.

**** EDIT 6/11/2015 **** Calculation Manager 11.1.2.3.505 has been released and fixes the issues with CDF registration.

Fixing errors in Calc Manager 11.1.2.3.502 Custom Defined Functions

**** Please see the edit at the bottom of this post for important information ****

Celvin Kattookaran and Cameron Lackpour have previously blogged about the Calc Manager 11.1.2.3.502 CDFs.  Celvin does a great job in both the ODTUG Blog “Tech Tips” article and his blog where he describes the use of some of these functions.  As I was researching these functions, I found several errors in my Essbase application logs where five of these functions are not registered properly.

[Wed Jan 07 11:46:43 2015]Local/Vis_ASO///13072/Warning(1200490)
Wrong java method specification [com.hyperion.calcmgr.common.cdf.exportData(String,String,String,String,String,String,String,String,String,String,String,String,String,String,String)] (function [@CalcMgrMDXExport]): [specified class not found:com.hyperion.calcmgr.common.cdf]

[Wed Jan 07 11:46:43 2015]Local/Vis_ASO///13072/Warning(1200490)
Wrong java method specification [com.hyperion.calcmgr.common.cdf.StringFunctions.substring2(String,int,int)] (function [@CalcMgrSubstring]): [specified method not found:com.hyperion.calcmgr.common.cdf.StringFunctions::substring2(java.lang.String,int,int)]

[Wed Jan 07 11:46:43 2015]Local/Vis_ASO///13072/Warning(1200490)
Wrong java method specification [com.hyperion.calcmgr.common.cdf.StringFunctions.indexOf(String,int)] (function [@CalcMgrIndexOf]): [specified method not found:com.hyperion.calcmgr.common.cdf.StringFunctions::indexOf(java.lang.String,int)]

[Wed Jan 07 11:46:43 2015]Local/Vis_ASO///13072/Warning(1200490)
Wrong java method specification [com.hyperion.calcmgr.common.cdf.StringFunctions.lastIndexOf(String,int)] (function [@CalcMgrLastIndexOf]): [specified method not found:com.hyperion.calcmgr.common.cdf.StringFunctions::lastIndexOf(java.lang.String,int)]

[Wed Jan 07 11:46:43 2015]Local/Vis_ASO///13072/Warning(1200490)
Wrong java method specification [com.hyperion.calcmgr.common.cdf.CalendarFunctions.getCurrentDate(int)] (function [@CalcMgrGetCurrentDate]): [specified method not found:com.hyperion.calcmgr.common.cdf.CalendarFunctions::getCurrentDate(int)]

@CalcMgrGetCurrentDate

So, how do we fix these?  Celvin comes to the rescue on the first one.  In his Tech Tips article, he explains that we need to remove the “int” input parameter in the Java Method field.

  1. In EAS, I right-clicked on my Essbase server and selected Edit>Functions.
  2. Inside the CDF Manager, I selected the @CalcMgrGetCurrentDate function and clicked the Edit button.
  3. Inside the Edit Function window, we change the Java Method field from getCurrentDate(int) to getCurrentDate().
  4. Stop/Restart an application and view the log to verify that the function is registered properly.

That works great and it’s one down, four to go.

Change getCurrentDate(int) to getCurrentDate()

Change getCurrentDate(int) to getCurrentDate()

@CalcMgrIndexOf and @CalcMgrLastIndexOf

Next we can fix @CalcMgrIndexOf and @CalcMgrLastIndexOf with the same steps.  These functions are not declared properly.  I took at peek into the Java class for these functions and found that they need to receive two String variables and a numeric variable.  The default specification is one String and one number.  To fix these two functions, we need to add an additional String to the input parameters in the Java Method field.  Change indexOf(String,int) to indexOf(String,String,int). Next we need to edit the Spec field to add “searchString”.  Change @CalcMgrIndexOf(text, beginIndex) to @CalcMgrIndexOf(text, searchString, beginIndex).

Change indexOf(String,int) to indexOf(String,String,int) and @CalcMgrIndexOf(text, beginIndex) to @CalcMgrIndexOf(text, searchString, beginIndex)

Change indexOf(String,int) to indexOf(String,String,int) and @CalcMgrIndexOf(text, beginIndex) to @CalcMgrIndexOf(text, searchString, beginIndex)

@CalcMgrSusbtring

With the @CalcMgrSusbtring function, we need to edit the Java Method and Spec fields to remove the “2”.  Change substring2(String,int,int) to substring(String,int,int), then change @CalcMgrSubstring2(text, startIndex, endIndex) to @CalcMgrSubstring(text, startIndex, endIndex).  If you use EAS to edit this function, you will run into an error when trying to save the change back.  The error looks something like this:

The Comment field is over 256 characters.

The Comment field is over 256 characters.

Great, now what?  Well, we can edit the comment field and remove the third line and that would allow us to save the function back since we would have reduced the comment field to under 256 characters.  More on that later… Until then, this is what your function should look like when it’s fixed.

Fixed @CalcMgrSubstring function definition.

Fixed @CalcMgrSubstring function definition.

@CalcMgrMDXExport

The final function is @CalcMgrMDXExport.  Celvin has a great explanation of how this works and shows a great example on this blog, so read that to see how cool this is.  This function is missing the Class in its Java Class field.  To fix this one add “.MDXExport”.  We need to change com.hyperion.calcmgr.common.cdf to com.hyperion.calcmgr.common.cdf.MDXExport.

That’s pretty simple, but we are again going to run into issues with EAS CDF Manager.  As we previously found out, the Comment field has a limit of 256 characters in EAS.  If you cut down the comment on this function, you’ll also find out that the Spec field has a limit and of course this function is too large.  Through testing, I found the limit of the Spec field is 128 characters.  The default Spec for this function is 162 characters.  We could use shorthand changing “application” to “app” and “database” to “db”, but that’s really a pain.  If only there was a way to edit these functions without losing the comments and extended specification.

Essfunc.xml

This is where Cameron’s blog comes in.  Cameron has covered the Planning CDF functions in the past and explained that the “essfunc.xml” holds a better explanation of the @Hsp* Planning functions.  Well, that’s also the file that EAS looks at when you Open the CDF Manager, only in a different location.  So, if you make these same changes to the function specification in the proper essfunc.xml file, the functions will be fixed in EAS and you can then call them like a calculator function.

The essfunc.xml that contains the definitions of my server-wide CDFs, that is the functions that are valid for all applications, is stored in C:\Oracle\Middleware\user_projects\epmsystem1\EssbaseServer\essbaseserver1\java. As I have previously blogged, I prefer TextPad for my text editing duties, so that is the tool I used for editing.

In my copy of essfunc.xml, on line 82 the function for @CalcMgrMDXExport starts:

<function name=”@CalcMgrMDXExport” tssec=”1420730410″ tsmcs=”606000″ javaSpec=”com.hyperion.calcmgr.common.cdf.exportData(String,String,String,String,String,String,String,String,String,String,String,String,String,String,String)”>

To fix this one, all we need to do is edit that one line to:

<function name=”@CalcMgrMDXExport” tssec=”1420730410″ tsmcs=”606000″ javaSpec=”com.hyperion.calcmgr.common.cdf.MDXExport.exportData(String,String,String,String,String,String,String,String,String,String,String,String,String,String,String)”>

Just inserting “.MDXExport” in the javaSpec is all we need to do.  No messing around with shorting the Comment or Spec fields needed.  Save the file back to the server.  To verify the change was made, we can view the function in the EAS CDF Manager where we should see our edits have saved properly.  Stop and restart your application to verify that the edits were successful and that the function has registered properly.

1-4-2015 5-04-55 PM

The five specification errors fixed and ready to be used.

 

****EDIT 6/11/2015 **** Calculation Manager 11.1.2.3.505 fixes these errors, so just apply PSU 20968612 and you won’t need to mess with fixing the CDF registration in EAS or the essfunc.xml.