Now that we’re up and running with our cubeSavvy installation, it’s time to configure some grids. Grids ostensibly serve the same purpose as forms in Planning: they are configurable comprehensions of the dimensionality of a given outline. As with Planning, cubeSavvy supports defining the POV, page dimensions, and the rows/columns. These are all based on a single member (such as the POV) or on a list of members (possibly with a selection to include their descendants, children, and so on). Check out this grid definition screen:
We can easily drag and drop members from the dimensions to the proper “slot”. Those of you familiar with Planning will be comfortable with this. We can dive deeper on a particular node in the configuration to define which members and children of members to include:
All in all, the grid definition and member configuration process is pretty smooth. Along with defining the grid, we can also define a calc to run when the grid is submitted/saved by a user. Again, this is pretty standard fare for those familiar with Planning. It’s typical to need to aggregate some values up after the user hits submit, or perform some other calculation.
Excellent article. I had never heard of cubeSavvy but will now check it out.
Thank you for sharing!
Have you ever tried using Dodeca for budgeting instead of Planning? Just curious.
Yes I have used Dodeca – in fact, I rolled out one of the earliest and largest (at that point) Dodeca deployments several years ago! I am going to do a long blog series on Dodeca as soon as possible. As I said, I am working through the third-party Hyperion ecosystem this year and next on the list is something quite interesting, followed by Dodeca. Stay tuned. :D
Two things I didn’t see:
1) How is dimensional security in grids represented? Does it follow the user’s username and so metaread filters would suffice or does cubeSavvy use a “ghost user” to do logins and handles security some other way?
2) Is there any way to pass grid POV, page, row, and column settings to some kind of calc script execution stage? I am thinking either the way Planning forms work with business rules (not bad, but could use some real improvement in the row and column area) or the way tokens work in Dodeca (even better because if you set the views up just right you can drive aggregations in BSO with row and column information).
Otherwise a very intriguing product.
1. Dimensional security is handled by way of the user’s security — rather than all requests being marshaled through an admin user, the user uses their own credentials.
2. This came to mind as well and I almost commented on it since it’s highly relevant to what calc gets run on submit. At present I don’t think the product includes this capability, but speaking from my own experience, it is possible to do with just the Essbase Java API (i.e., generate your own calc based on a template that you parameterize). So… doable, if not trivial.
1) Jason is correct. You log into cubeSavvy with the same credentials you would log into Essbase. The only difference being that you would need to be in the cubeSavvy_admins group (either native Essbase or Shared Services) to create grids or cubeSavvy_users to enter data in a grid. Having users continue to utilize their own ID (instead of the “ghost user” approach you mentioned) has the added benefit of simplifying the logging of user activity.
2) This is definitely on my road map for the product. I will try to piggyback off the new Essbase as much as possible, since my whole goal is to stick with native Essbase functionality (and not bastardize it to death, as Planning has done). I envision being able to limit a calc to EXACTLY what is displayed in the grid – including rows and columns.
I’d be more than happy to hear any other ideas you have.
That should read “piggyback off the new Essbase runtime substitution variables as much as possible”.
[…] you come up for air next week. It has been a busy week on my end, what with doing a fairly deep cubeSavvy review, building elegant/robust/awesome solutions for clients, polishing up open source Essbase […]