Kim Kardashian can get my Essbase server updates

I had the great pleasure of presenting at Kscope17 on the power of Essbase CDFs.  At the end of my CDF presentation this year, I gave a live demonstration of a little CDF that is designed to spark the imagination.

In 2009, Matt Milella presented on CDFs at Kaleidoscope and talked about the top 5 CDFs that his team had created.  At the end, he showed a very cool demonstration of how his Essbase server could send out a tweet using a CDF. This was an amazing display and really inspired me to figure out how to create CDFs.

So, as an homage to Matt’s blog post about how Ashton Kutcher can get his Essbase server updates, I have created an updated version of the Twitter CDF. As Matt states, he used JTwitter back in 2009.  Unfortunately for me, Twitter has long since changed their authentication to use OAuth for security which means that JTwitter doesn’t work anymore.

I did some searching and found Twitter4J, an unofficial Java library for the Twitter API. This library handles the OAuth authentication as well as allows submitting of new status updates, sending direct messages, searching tweets, etc. Between Matt’s original Twitter code, the Twitter4J sample code, and some trial and error, I was able to get the library setup and created a Java class that could send my tweets.

  1. The first step was to download the Twitter4J library.  I added the twitter4j-core-4.0.3.jar file into my lib folder in JDeveloper and added it to my classpath.
  2. Next, I had to setup a new Twitter account (EssbaseServer2).
  3. Then, I went to and setup my application to get the OAuth keys needed for my code to authenticate.
  4. Once I gathered the keys, I put them into a .properties file called “”.  This file will be placed onto my Essbase server into the %EOH%/products/Essbase/EssbaseServer/java/udf directory.  Placing the file into the …/java/udf directory puts it into Essbase’s Java classpath and Essbase will be able to access the file when its needed.
  5. Next, I wrote my code (based heavily on Twitter4J’s sample code), compiled it, deployed the code to a JAR and placed the JAR on the Essbase server.
  6. I registered the CDF manually in EAS.
  7. I was able to pretty much reuse Matt’s original calc script as he had it back in 2009 with the exception of using an @CalcMgr function instead of one of the older data functions.

Does it work? Well, go and check out the @EssbaseServer2 account for yourself.

While publicly tweeting your data might not be the best idea, hopefully this serves as a spark to ignite your imagination of the power of CDFs. Anything you can do in Java can be implemented in an Essbase calculation. Some attendees of my presentation were pretty excited about the possibilities of communicating with their users by submitting messages using Slack or updating a status on a SharePoint site. The possibilities are limited only by your imagination.

Thanks again to Matt for presenting on CDFs eight years ago. It definitely inspired me to learn more and hopefully this will inspire others to do the same.

There has been some uncertainty about the fate of CDFs with OAC and the Essbase cloud service, but never fear, CDFs are supported but they are limited to local CDFs. More on that in the future.

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.

CDF Series Part 3: Creating CDFs

If the prebuilt CDFs from Oracle that we discussed last time don’t meet your needs, it is also possible to create your own Custom Defined Function. Using a Java integrated development environment (IDE) is the simplest method for beginners, although it is possible to create a JAR using nothing more than a text editor and command line interface with Java.  There are several IDEs available for Java; however, I prefer to use Oracle’s JDeveloper as it makes doing this work very easy.


JDeveloper makes Java development and deployment to JARs very easy. I am currently using JDeveloper because it is compatible with both Java 1.6 and 1.7.  The EPM System is shipped with Java 1.6, so using some version of Java 6 will prevent any errors due to incompatible code.

The software can be downloaded from the Oracle Technology Network. For just programming Essbase CDFs, select the Oracle JDeveloper Java Edition download. Unzip the downloaded files to the C:\ drive for simplicity, and it will create a C:\jdeveloper folder. At the first startup, point JDeveloper to a JDK installation.  The Oracle EPM JDK can be used at C:\Oracle\Middleware\jdk160_35 to ensure compatibility.  Any Java 6 JDK could be used and later versions are recommended due to security vulnerabilities in the lower Java 6 releases.

Next we need to create a generic Java project and add a new Java Class.  Here we will enter our code.  When writing a Java CDF that may be called using the RUNJAVA method, we need to add in an additional parameter to the “main” method.  Typically in Java programming the main method only accepts a String array (String[]) called “args”.  With Custom Defined Functions, we must accept a calculator context parameter as well as our String[] args. The main method description will appear similar to:

public static void main(com.hyperion.essbase.calculator.Context ctx, String[] args) {

By adding the calculator context to our Java Class, JDeveloper will give errors as it is unable to find the definition for the context object. In order to properly compile our Java Class into a JAR, we must first make JDeveloper aware of the context object that is part of the Essbase server in a file called Essbase.jar.  To add Essbase.jar into the Classpath for our code, right-click the project in JDeveloper and select Project Properties… as shown below:


Next, navigate to the Libraries and Classpath option of the Project Properties and click the Add JAR Directory button.  Browse to the Essbase.jar file and click Select.  If done properly, your screen will be updated showing the Essbase.jar file as a Classpath entry as shown here:


To deploy our Class to a JAR, we must first create a deployment profile in JDeveloper.  To create a deployment profile, right-click the project, select Deploy >> New Deployment Profile… as shown below:


In the New Gallery dialog box, select Deployment Profiles then select JAR File in the right pane like this:


In the Create Deployment Profile – JAR File dialog box, enter a name for the Deployment Profile.  This will become the name of your JAR file.


In the JAR Options dialog box, select the checkbox to Include Manifest File (META-INF/MANIFEST.MF) and browse to select the main class.


Next, to deploy our Class to a JAR file, simply right-click on the project again and navigate to Deploy >> ProfileName, then click the Finish button to deploy the Class to a JAR file.


Now that we have our JAR file, the next steps are to copy the JAR to our Essbase server and register the function in EAS or by using MAXL.


After restarting Essbase, we should then be able to use our new code in an Essbase calculation script:

"Budget" = @CREATEBLOCK("New York"->@RELATIVE("Product",0));
FIX ("New York", "Sales", "Budget",@RELATIVE("Product",0))
AGG (Product, Market);


CDF Tips for Java Developers

Custom Defined Functions should be programmed using static methods in Java.  These classes typically are not be overridden and are used as utility classes, so using static methods is the best practice.

CDF methods can accept any number of parameters. These parameters may use any of the following data types:

  • boolean
  • byte
  • char
  • hyperion.essbase.calculator.CalcBoolean
  • float, double
  • lang.String
  • short, int, long
  • arrays of any of these types

The CalcBoolean object is defined in the Essbase.jar file and is equivalent to the Essbase calculator’s Boolean function and has values of TRUE, FALSE, or #Missing.

Any return values to Essbase can be void, or any of the above data types. Returned data is mapped to an Essbase-specific data type.  String return values are mapped to a String. Boolean return values are mapped to the CalcBoolean data type.  Any other return value is mapped to a double data type.

CDFs must start with the @ symbol, the rest of the name can contain letters, numbers, or the following symbols: @, #, $, and _.  CDF names must not include spaces.

If multiple users can run the same CDF at a time, the variables can be shared and overwritten.  For thread safety, I have used the synchronized attribute on methods in Java with success.

Any passwords or other properties that may need changed can be stored in a *.properties file in the %EPM_ORACLE_HOME%\products\Essbase\EssbaseServer\java\udf directory for global or server-wide functions or they can be placed in the %EPM_ORACLE_INSTANCE%\EssbaseServer\essbaseserver1\app\ApplicationName directory.  Your methods can then use the *.properties file as a resource and read the values at runtime.  This is a better method than saving passwords directly in your Java code.

Custom Defined Functions open Essbase calculations up to a world of possibilities. There are several prebuilt options from Oracle that may meet any needs outside the traditional Essbase calculator engine. If the existing prebuilt code does not solve your specific need, custom code can easily be implemented to solve almost any calculation need in Essbase.

CDF Series Part 2: Prebuilt CDFs

Oracle has given Essbase administrators several different prebuilt CDFs that can be used anytime they are needed. There are three main locations for prebuilt CDFs: Oracle’s Sample Code site, Calculation Manager, and Hyperion Planning.

Oracle Sample Code

Located at (, Oracle’s Sample Code site offers eight different downloads containing several CDFs.  These downloads contain precompiled JAR files, the necessary MaxL statements to register the CDFs, and usually a sample calculation to show how to use the CDFs.  The eight downloads are:

  • Financial Functions: Calculates loan maturity, principal and interest payments, and interest rates
  • Export Functions: The main function used in this CDF was replaced by the DATAEXPORT Essbase calculator function
  • Email Functions: Sends emails during calculations to alert administrators or users
  • Date Functions: Includes various functions to work with dates, some are epoch date format and some are YYYYMMDD format
  • Data Functions: Allows retrieval of external data from files or the Internet
  • Counter Functions: Counts the number of passes through an outline during a calculation for tuning purposes
  • Logging Functions: Logs messages to a specified file, replaced by @CalcMgrLog and @CalcMgrLogText functions
  • String Functions: Manipulates text fields, many of these functions are also available in @CalcMgr* text functions

Calculation Manager CDFs

Beginning with Calculation Manager and up, many prebuilt Custom Defined Functions are automatically deployed to the Essbase server and ready for use. Version of Calculation Manager includes 67 prebuilt functions.  Many of these functions are for text and date manipulation.  The date functions are primarily for use in Capital Expenditure and Workforce Planning applications using the YYYYMMDD date format, but can be used in any application that stores dates using that format.

In addition to the text and date functions, there are six miscellaneous functions that can be useful in a variety of situations.  The six miscellaneous functions are:

  • @CalcMgrExecuteEncryptMaxLFile – allows the execution of an encrypted MaxL file.
  • @CalcMgrExecuteMaxLScript – streams MaxL code to the Essbase kernel for immediate execution
  • @CalcMgrLog – writes messages to a specified text file, can include data from Essbase for validations
  • @CalcMgrLogText – writes text-only messages to a specified text file
  • @CalcMgrMDXDataCopy – using MDX queries, this function can select a range of data blocks in one application and copy the data to a target application
  • @CalcMgrMDXExport – using MDX queries, this function exports data to a file quickly without the ugly formatting of a traditional MDX export

Some of these functions are not properly registered after applying the patch.  The errors can be fixed by editing the essfunc.xml file in the %EPM_ORACLE_HOME%\EssbaseServer\essbaseserver1\java directory. The following edits need to be made to have all of the CDFs registered properly:

  • @CalcMgrGetCurrentDate
    • Change getCurrentDate(int) to getCurrentDate()
  • @CalcMgrIndexOf
    • Change indexOf(String,int) to indexOf(String,String,int)
    • Change @CalcMgrIndexOf(text, beginIndex) to @CalcMgrIndexOf(text, searchString, beginIndex)
  • @CalcMgrLastIndexOf
    • Change lastIndexOf(String,int) to indexOf(String,String,int)
    • Change @CalcMgrLastIndexOf(text, beginIndex) to @CalcMgrLastIndexOf(text, searchString, beginIndex)
  • @CalcMgrSubstring
    • Change substring2(String,int,int) to substring(String,int,int)
    • Change @CalcMgrSubstring2(text, startIndex, endIndex) to @CalcMgrSubstring(text, startIndex, endIndex)
  • @CalcMgrMDXExport
    • Change hyperion.calcmgr.common.cdf to com.hyperion.calcmgr.common.cdf.MDXExport

Hyperion Planning CDFs

Hyperion Planning also comes with several prebuilt CDFs.  In version, Planning contains 23 CDFs available for use in both Calculation Manager rules and in Essbase calculation scripts. When attempting to use these rules in Calculation Manager, the parameter definitions are not descriptive, as shown in the picture below:

CalcMgr Functions

To get a better feel for the parameters for each @Hsp* function, view their definitions in Essbase Administration services as shown below:

EAS Function

Next time we will cover creating our own CDFs from scratch.

Introduction to CDFs

I attended a Matt Milella presentation several years ago about CDFs and always wanted to use one.  A couple of years ago, I was in a bind at a client who needed very specific to an Essbase extract for integration with SAP, and I actually had a chance to write one from scratch.  It’s not very often that you are faced with such a problem, but it’s great to know that Oracle has given us the tools to handle almost any situation.

Introduction to Custom Defined Functions

The Essbase calculator engine is use in Block Storage Option (BSO) and hybrid aggregation applications. There are 160 built-in calculator functions. BSO databases are known for their superior calculation ability due to these functions; however, occasionally there is a need for additional functionality not covered by the calculator engine or built-in functions. In these instances, Custom Defined Functions can be used to extend the calculator engine.

Custom Defined Functions (CDFs) are Java classes written to interact with the Essbase calculator. CDFs allow data, metadata, or both to be passed from the calculator engine into Java.  Data or metadata can then be returned to the calculator engine. CDFs harness the power of Java, so they are able to call any outside process.

CDFs open a world of possibilities through the use of Java.  They can be used to: submit MaxL commands dynamically from within a calculation, interact with the server operating system, do complex calculations not available with the existing calculator functions, or even fetch data from the Internet. These functions may be deployed at the server-level and available for use by all applications, or at the individual application level.

Java code is compiled into a Class file. Classes must then be packaged into a Java Archive file, also known as a JAR. The JAR file is then placed on the Essbase server in the %EPM_ORACLE_HOME%\products\Essbase\EssbaseServer\java\udf directory for global or server-wide functions or they can be placed in the %EPM_ORACLE_INSTANCE%\EssbaseServer\essbaseserver1\app\ApplicationName directory for an application-level CDF.  When using global CDFs, the udf.policy in the %EPM_ORACLE_HOME%\products\Essbase\EssbaseServer\java directory must be updated to allow Essbase access to the custom code.  A line can be added to the end of the udf.policy file as follows:

grant codeBase "file:${}/../java/udf/yourCDF.jar" {   

Next, the CDF must be registered with Essbase.  This can be done in Essbase Administration Services (EAS) by selecting Edit >> Functions on your Essbase server, or within MaxL. To register the @JsendMail function, the MaxL code would look like:

create or replace function '@JechoString' as 
spec '@JechoString(strArray)' 
comment 'Echoes back all arguments passed to the function.  To pass an array of arguments use @List(comma delimited list)'

Essbase picks up new Custom Defined Functions on startup.  When creating new global CDFs, the Essbase service must be stopped and restarted to recognize the new function.  When creating application specific CDFs, restarting the application is sufficient. When developing new CDFs, it is recommended to begin with application level functions during the initial testing as it is easier to stop and restart at the application level than restart the Essbase service.

As the application starts, messages are written to the application’s Essbase log about the functions. When creating new functions, check the Essbase application log to verify that the function is registered successfully. Any messages other than a successful registration indicate changes are needed to the CDFs registration in EAS. When a function is registered properly the following message is displayed in the log:

[Wed May 20 10:14:34 2015]Local/Sample///10636/Info(1200445) 
External [GLOBAL] function [@JechoString] registered OK

Once defined properly and registered with Essbase, Custom Defined Functions may typically be run in two ways.  The first method of running a CDF is similar to a typical Essbase calculator function.  When running a CDF using this method, it must be placed inside a calculation member block.  This option calls the Java methods directly from inside the Class file. If the CDF definition was setup “with property runtime” in MaxL, or with the “Runtime” box checked in EAS, the CDF will execute for all members of the calculation.  The amount of blocks impacted by the CDF can be limited with a FIX statement. A typical calculation script using the first option for running a CDF is:

FIX ("New York", "Sales", "Budget",@RELATIVE("Product",0))

The second option to run a CDF is using the RUNJAVA command.  This method of running a CDF executes only once and calls the “main” method of a Java class.  The Custom Defined Function must be written properly to accept this method of calling it. Using the RUNJAVA command does not require that a CDF be registered in EAS or by MaxL. A typical RUNJAVA command is:

RUNJAVA com.hyperion.calcmgr.common.cdf.MaxLFunctions
  true -D C:\\Scripts\\BatchCalc.mxl

That’s all for this week, next time we will talk about prebuilt CDFs from Oracle that we can use right away. Later, we will cover how to write your own CDF (assuming some level of Java coding experience)/

Calculation Manager

As I posted the other day, Caclulation Manager 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 was released on Monday (patch number 20830325) and contains the same fixes as

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 Calc Manager to the 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 version up-to-date.  Kudos to Oracle and the Calculation Manager product team!

Calculation Manager

On Tuesday, 6/9, Calculation Manager patch set update 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 Not only that, but there are some new CDFs to report with this version of Calculation Manager as well. Calculation Manager is a patch set update now available on My Oracle Support as patch number 20968612.

New Functions in Calc Manager

@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 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 Well, as luck would have it, a new patch to Calc Manager 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 persist in 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 and

To sum it all up, if you have fixed your CDFs in and are planning to apply (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, you can still use it in

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

Fixing errors in Calc Manager 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 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)]


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)


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.


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.


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 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.