One of my personal blogging goals this year is to take a tour of apps, code, libraries, and other third-party tools in the Hyperion ecosystem. I have some cool stuff on deck to be reviewed, starting with today.
Today I’d like to take a look at Harry Gates‘ cubeSavvy. cubeSavvy ostensibly purports to be “Planning without Planning”. Or, put another way, it’s a web-based interface for Essbase cubes, without all of the additional infrastructure and setup that Planning entails. This is an interesting approach. Let’s think about it for a moment.
As many of you know, by design, Hyperion Planning sits on top of Essbase and is synchronized down to Essbase. This design has some drawbacks and some advantages that are possibly worth musing on in a future post. Planning also brings a lot of extra functionality to the table that manifests itself in the user interface and/or is pushed down in some way to the underlying cube. cubeSavvy comes to the table and more or less says, “Hey, let’s do away with all of that and get a little more purist about this: let’s have grids (similar in concept to forms in Planning) defined that work with our vanilla Essbase functionality – and let’s just manage the cube instead of pushing and synchronizing things down to Essbase.”
So in theory, if you have an Essbase server up and running and then stick a cubeSavvy server in front of it, define some grids and provision some users, you’ve got a web-based budgeting and planning system on top of your cubes. Interesting.
In a first for me and this blog, this article will be split up in to several pages, covering Installation & Setup, Configuring Grids, User Experience, and Closing Thoughts. Please enjoy this whirlwind tour of cubeSavvy!
Wow, I think I am actually writing an article on Hyperion Planning. I think pigs are flying right now. I have been helping out on a system upgrade for the last few months where we are in many ways “refactoring” a Planning deployment. I’m borrowing that term from the software world. In other words, we are changing how things work under the hood without the explicit intention of changing how things look to users. One of the changes we are making, however, is to introduce some variables for users to be able to change their Version and Scenario.
Just to be clear, the variables are the ones that are set in the preferences menu. And we’d like to provide some defaults so that the users have the most likely choices pre-selected. We can export the User Preferences option from LCM. The corresponding XML file has a section for each user’s variables. It’s like this:
<!-- some stuff here -->
<Variable Name="Scen_UserVar" Value="Forecast"/>
<Variable Name="Ver_UserVar" Value="Working"/>
There’s, of course, a UserPreference section for each user. We can edit the variables here in this config file and the import it to the target system (or back into the current one) to fill the values. A couple of notes to consider:
- If you try to strip out the other stuff in the UserPreference section so that it doesn’t get touched, it’ll just load defaults for that user. You might not want to blow out the user’s settings that way.
- The reason for trying to do the above bullet item would be if you’re just trying to copy and paste the same block of code for each user.
- A user in the target system might not be in the User Preferences export – you can create that manually by copying and pasting a different user.
It’s incredibly likely that there’s a better way to do this or some magical option I don’t know of somewhere that’ll take care of it, but I wasn’t aware of it and decided to “brute” force it. The copying/pasting and editing was the “hardest” part as I couldn’t think if this procedure could be reasonably automated in UltraEdit or Notepad++ or something, so I just did it by hand.
Hope this helps someone!