At present, cubeSavvy allows for the definition of grids (including their dimensionality, calcs, and so on), and also allows for organizing grids into folders to help organize them for the users. Most likely the folders will be used to organize things along certain steps in a process or around certain operational areas. For the user’s part, they login to cubeSavvy using their browser, and are then presented with a list of grids. Clicking on a grid brings it up with data:
As this is a user-based system with the express intent of soliciting input from users, it’s a simple matter of inputting the data. Just click on a cell and type in a new value. This is pretty much the crux of the cubeSavvy user experience right now: load a grid, dial in the page if needed, see refreshed data, make edits if needed, submit data. Conceptually this is similar to the Planning experience.
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 […]