Want to know The Truth About CPM?

09 March 2012

Why I hate (and love) Calculation Manager, part 1

Hate takes too much energy

And besides, it’s difficult to hate a software product, unless its name is HAL.  :)


When it comes to technologies, I love Essbase (and in fact I was the editor in chief and contributed to a book all about it – read about it here), but love for Calculation Manager aka Calc Manager aka Calc Mgr aka CM?  Love may be a bit of an overstatement but it certainly has its interesting bits as I shall endeavor to show you.

Why Calculation Manager now?

I have resisted to date the siren song of Calculation Manager (there is no way I am typing that again and again and again – CM it is henceforth)  as I tend to do Classic Planning applications that utilize Hyperion Business Rules.  However, time marches on, EPMA uses CM exclusively, and I have read (although I have to say this is 100% unsubstantiated) that Classic Planning applications will no longer support HBR.  

In any case, this is a good opportunity to revisit what continues to be some of this blog’s most popular posts, Why I hate (and love) Business Rules, part 1 and 2,  This post is similar, but for CM and I will throw in a few twists that I didn’t (couldn’t actually) cover in the HBR posts.

If you haven’t yet dipped your toe into CM, check out this good introductory series of blog posts on the Edgewater/Ranzal blog:  Parts 1, 2, 3, and 4.  One difference between what you will see below and their series – I don’t use the graphical module.  If you are in love with dragging and dropping you will have to look elsewhere.  If you love graphical rules, I still suggest you read on because I cover quite a bit that is common to both approaches.

What’s different?


Oh, everything as far as the interface is concerned.  CM is no longer a module in EAS but instead is its very own subsystem in Workspace.  Here’s how you get to it:

Code organization

Once in, the interface is certainly different looking, but if you think about it, not all that different from the way HBRs look in EAS if you use projects to manage them:
One thing that I like about CM is that I no longer need to come up with rule names like AppName.PlanTypeName.ScriptName to keep them sorted correctly in HBR’s Repository View.  I use Projects in HBR to make my life a little easier – CM just does it out of the box through its hierarchical nature.  Score one for why I love CM.

I will also note that there is no more malarky around having to set locations to be able to validate the rule I just wrote (that one still trips me up) as in HBR.  Another one for CM.


Variable creation is certainly different as well, and there are more places to create them.  

Just to review, in HBR, variable creation is either Global or within the rule itself (Local):

In CM, variables are created by going to CM’s Tools->Variables and then by expanding the technology/application:

Interestingly, there are additional levels of variables:  Global, Application, Plan Type, and Rule.

For us HBR types, Rule = Local Variable and Global = Global Variable.  So what about CM’s Application and Plan Type?  What about Global?  Does it work the same way?  This is where it gets a little interesting if completely undocumented.

Through trial and error (Am I smart enough to learn any other way?  Nope.), I have figured out the following:
  1. Global really is global to the entire server.  This is just like HBR Global variables.  So far, so good.  
  2. Application level variables don’t really have an analogue in HBR.  They are global to the application.
  3. Plan Type level variables also don’t have a corresponding type in HBR.  They are global to the Plan Type.

Just as with HBR’s Global Variables, I can see a use case for creating variables for all common dimensions for use in Run Time Prompts (RTPs) and sticking them at whatever level makes sense.  Most of the time, I think that would be at the Application level.

But there’s a catch – you can only create Global or Application variables for common dimension types.  In other words:  

Btw, the label to that dropdown (actually dropup) is Dimension Type, not Dimension:
Fooling Calculation Manager
So what happens when you want that Global or Application variable for a Custom dimension?  You can’t.  You can’t even create one at the Rule or Plan Type level and copy and paste it – if the dimension type isn’t one of the required dimensions, it doesn’t work:
NB – If the dimension type is one the seven required dimensions, the copy and paste does work.

Definitely not a plus for CM.

However, the great False God Google came to my rescue once again with this wonderful
blog post.  What you do is:
  1. Create a Global or Application variable with an allowed dimension type.  
  2. Insert it into the CM rule
  3. Export the rule
  4. Edit the rule in a text editor and replace the dimension name with the custom dimension.
  5. Import the rule back into CM.
  6. Ta-da, your custom dimension variable is now at the Global or Application level.

Let’s take a lookie-loo at the XML of an exported rule with global, variable, and :

The addition of the application node makes the variable a…wait for it…application variable.  The notes for application and plantype equals a Plan Type variable.  It would be nice if CM just handled this out of the box.

Just in case you think I am completely nuts (oh, many do, and they’re likely right), check out this from Oracle Support:  When creating Calculation Manager Global Variables, not all Hyperion Planning Dimensions are available [ID 1272807.1].  

I agree with their comments about Global variables – if a dimension is only in one Planning application or Plan Type, it really isn’t Global, is it?  

However, to preserve what little sanity I have left, I do like the idea of creating an Application level variable and will use Celvin’s approach going forward.  We all owe a big thanks to him.

Default values in Run Time Prompts

Another oddity in CM that doesn’t manifest itself in HBR is validating a rule with variables.  In HBR, when you create a Member RTP variable, be it Local or Global, you have the option of not providing a default value.  This is, to my mind, a Good Thing as there could be a failure to feed the form POV values to the RTP.

By default, it’s blank in HBR:

And in CM. So far, so good.

In HBR, when you validate a rule that uses variables that do not have a default value, you are prompted to select values.  You’ll only get prompted once if you don’t select this tick box:

I tend to select that as I want to be DoublePlusSure that the form drives the value.  

Here’s what HBR pops up on rule validation:

In CM, when the same approach is tried:

What’s going on?  Our friends in Oracle Support (they don’t invite me over to their respective houses for a kaffeklatsch, but boy oh boy do they answer a lot of questions) have this article:  Failed to validate against Essbase. One or more unresolved RTPs found" [ID 1235676.1]

Here's the relevant passage:
As Calculation Manager does not provide an interactive interface to enter RTP values during validation, the validation relies on the RTP's default value. If at least one RTP does not have a default value set, the validation fails with above error.

To recap:  you can create a RTP variable, you can insert it into a rule, but then that rule will never ever validate.  Or, you can put in default values that don't match what a given user might select, but then you can validate.  Hmmm.  I guess I will put in default values.

Another minus for CM.  

Oh well, rant over, I will henceforth put in default values for RTPs:
Success!  Boil in bag!

You must deploy

One big difference between HBR and CM is related to the issue above.  You must deploy the CM rule to the Planning application to run the rule.  There is no run-from-Calc-Manager option.  All rules get run from Planning itself.

The rule can be deployed from within CM by clicking on the Validate and Deploy button within the rule.

Or by selecting Deploy or Deploy All from within the System:

Or by clicking on the Planning application and selecting Deploy.

Deployment viewing
What needs to be deployed?  CM can give you that information by going to the View menu when in the System View tab and selecting Deployment View. 

You can even deploy individual or all rules from this report:

You can also go to the View menu and select List View:

Which will let you filter what comes back from CM:

Which results in this report.  Pretty slick and several +1’s to make viewing this easier.  Remember, with a handful of rules, navigation is a doddle.  When many start to appear, understanding what is where and why gets quite a bit more complicated.

Deleting rules

The Deploy moves the CM rule from CM to your Planning application.  A very important thing to note is that deleting a rule from CM does NOT delete it from Planning.  What that means is that you must select Deploy All or Deploy at the Planning application level to remove rules from Planning.  This is totally different than HBR where, when you delete a rule, you’ve deleted it.  I’m not going to give this one a plus or a minus, just a note that it doesn’t behave the same way.

Fixed in Calc Manager

How many times in HBR have you seen this when trying to create a HBR in EAS:

The “fix” for this is to go into the Planning application in question, open a form, return to EAS/HBR, close the rule, open the rule back up, and select the Planning Plan Type which should (hopefully) be available to you now:

CM completely does away with this requirement as the rules can only be created at the Planning application level.  Definitely a big +1 for CM.

Stop for now, but the balance next week

So there we have it:
  • Big changes in the navigation of rules, for the better, really.
  • The removal of some of the odd things traditional HBR required such as writing the rule but not being able to run it till the localtion and rights are assigned and that trick with opening a form before being able to select an outline.  
  • A different way of navigating variables with of course a hack to make it work the way we want (that is sort of the definition of this blog, right?)

There’s another big interface change but I will cover that in the next and final part of this series (hey, this thing came to 37 pages in total – that’s too much for one post) and of course a semi-interesting twist on how to calc Planning forms that is different (and better) than what I did in HBR.


srx said...

Sure that this is a GREAT paper made by one of the BEST Essbase/Planning expert (IMO), however I'm so glad not to be a Planning admin and to have to use such a "methane factory"!

Cameron Lackpour said...

>>by one of the BEST Essbase/Planning expert (IMO)
^^^Blush. But thank you. :)

Actually, I was told recently that I was (and I am paraphrasing here), "Not experienced with large Planning implementations." Huh? Why would anyone think up the focused aggregation technique (hint, that's the next post but with a twist and better explanation as to how I described it before) if the implementation (or at least the database) wasn't huge? So it is nice to hear some praise.

As for the methane factory comment. :) Well, when Planning hits its sweet spot, it is really a great tool. I can actually see when the penny drops for a client and it is gratifying. When Planning *isn't* a good fit, it simply doesn't work very well, and yes, I have been on those projects and it is quite frustrating. Horses for courses.


Cameron Lackpour

Anonymous said...

Business rules will be gone in, if it is an upgrade existing business rules will be migrated to Calc Manager

Cameron Lackpour said...


You heard that at the training last week? That sure seems to be the message. Pity that Calculation Manager is missing one big bit of functionality that's in HBR. All will be revealed next Monday. :)


Cameron Lackpour

Tim Young said...

One "gotcha" about Calc Manager & LCM: Avoid building templates within templates when possible. The repository table assigns them item numbers, which usually won't migrate properly between environments.

Always Trubl said...

Can you explain how to import replacement variables into The export option was an easy right click, but the import . . . not so much. Any help would be greatly appreciated! Thanks!

Anonymous said...

Can you please mention the process to migrate HBR from 9.3.1 version to calc manager for classic planning applications

Unknown said...

I'm still not comfortable with the Dimension Type concept in CM. If we add a Custom Dimension to all Plan Types then that is definitely a candidate for Global Variable...Good to know that I was able to provide some help :)

Anonymous said...

Thanks Cameron for your thoughts...

But, as you know...there is something like Sequences and
cmdLauncher for Calculation Manager ?

there is some work-arounds for this 2 issues ? :)


Anonymous said...


A sequence is now called a RuleSet:

Batch launches of Calc Mgr take place in CalcMgrCmdLineLauncher:


Cameron Lackpour

Joe said...

can we automate the backup of business rules using calc manager

Unknown said...

Thanks Cameron, your tips on deleting business rules from the planning app help are very helpful.

Anonymous said...

Question: Are deployed CM Rules the only rules that get exported on LCM?
(Plan Type -> XXXX -> Calculation Manager Rules -> )

In short, code changes that are not deployed do not get picked up by LCM.