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

Love?  

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 11.1.2.2 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?

Navigation

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.

Variables

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.