jason w. jones

Happy Friday! Most of you Hyperion folks out there have probably called it a week already, so you can just catch the fun from your RSS readers or when 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 power tools, and more (even a few things I can’t mention… yet).

A while back I mused on some Essbase or Hyperion related names for my new betta fish. I never circled back to this but I have to go with a late submission from “Keith” – so without further ado, Mr. Fish will be henceforth known as DBAG. *hehe*

Last, but not least, this is my one-hundredth blog post here. Wow! I’d probably write anyway even if no one read this blog because I find it oddly therapeutic (not to mention serving as a repository for the obscure bugs I track down and fix), but to those of you that regularly comment, email me, offer to help out on testing some tool, and say Hello at conferences, thank you very much for your time and thoughtfulness.

Have a great weekend.

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!

Installation & Setup

cubeSavvy has a pretty straightforward setup process. It doesn’t require setting up an configuring a separate relational database, which can greatly simplify and speed things up (at least in terms of deployment). This might sound a bit odd (not having a relational database) but I’m quite familiar with the concept and coming from the Java world myself (which cubeSavvy’s server component is written in), I know that there are some very capable relational databases that are written entirely in Java that are up to the task of storing persistent cubeSavvy info.

cubeSavvy is a Java servlet that comes with its own servlet container (think Tomcat, WebLogic, etc.), database, and installer. As Java software, these components are all cross-platform (or at least ostensibly cross-platform). My main machine is a Mac (a maxed out early-2011 i7 MacBook Pro), and I figured, hey, why not see if this baby runs on a Mac? Aren’t we all a little tired of enterprise software running on Windows and Linux? Let’s let the Mac have some fun!

cubeSavvy just needs a few things configured to get up and running: the target server, APS URL, and the EPM version (I tested this with EPM 11.1.2.3 that is installed on Windows Server 2008 R2 64-bit). Here’s one of the installer screens:

After copying some files around and installing things, cubeSavvy presents us this screen:

And things are installed. We now just start up the service and we’re able to get to it with a standard browser. As an aside, cubeSavvy quite obviously uses what is called “Twitter Bootstrap”. For those of you not familiar, Twitter Bootstrap is a something of a foundational layer of HTML and CSS for web developers that generally looks pretty good and has been extensively tested to work in all browsers (or at least degrade gracefully on older browser – I’m looking at you, IE6). Bootstrap is used by countless sites these days and in the context of a web-based system in the Oracle world, it serves as an alternative to a other presentation frameworks such as Oracle’s ADF.

Planning has gotten a bit better over the years in terms of its browser support, but still has some glaring omissions that they would be well-served to address. For example, Firefox support is better but spotty (in terms of having to configure Firefox to get it to work with Planning), and Chrome and Safari are not supported at all. I believe that browser support should continue to gradually get better in Planning, but in the meantime for a system such as cubeSavvy that isn’t relying on ADF, it’s a bit of a breath of fresh air to support all browsers out of the box rather than just a very narrow spectrum of Internet Explorer versions.

At present, cubeSavvy’s setup also entails adding a couple of new groups to your Hyperion server: one for admins and one for users. This is detailed on the main screen upon logging in to cubeSavvy and covered in the documentation. I imagine that later versions will include “fancier” support for configuring security against Shared Services in a more elaborate manner, but for now it suffices.

Configuring Grids

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.

User Experience

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.

 

Closing Thoughts

I have been pleasantly surprised with the functionality afforded by cubeSavvy even this early in its development. The “basics” are all more or less in place. cubeSavvy is not without its faults or defects though: I did experience a handful of issues during testing that required me to either manually refresh the page or navigate to a different section and then back to the section I wanted to be in. I imagine this is to be expected for now and am sure that Mr. Gates is hard at work on fixes for the issues I experience, if they haven’t been fixed already.

As I mentioned on the first page, I find myself intrigued with the cubeSavvy value and administration proposition, which is dispensing with some of the complexity of Planning (and its deployment) and going back to a more Essbase-centric view of the world. This is a possibly interesting solution for those people not wanting to make the leap to Planning but wanting to have a web interface in front of their cubes.

At this point in time, I think cubeSavvy would be well-served to take the following course of action:

1. Focus on a polished user experience. There are just simply some kinks that need to be worked out to make the user experience smoother: bug fixes, text prompts, and the like.
2. Adopt a strong visual identity. Speaking as no stranger to web development, using Bootstrap is a great foundation to build on. This provides for broad browser support right out of the gate and also allows for relatively easy theming. I would love to see cubeSavvy adopt either a high-quality or even a custom theme to really make it feel like its own entity rather than just the Bootstrap defaults.
3. Really embrace the notion of being a front-end to Essbase and innovating on the Planning/planning experience (note that I mention Planning with a capital P and planning without a capital P). I think this is part of the game plan already, but thought I’d say it explicitly.

I’m really looking forward to seeing this project evolve and mature over time into a useful tool. If for whatever reason the business side doesn’t pan out, I think cubeSavvy would make a great candidate for an open source, community development driven project.

Keep up the great work, Harry.

As some of you may know, I am now the active maintainer for the essbasepy Python module for MaxL. This project is an analog to the MaxL Perl module that was originally created by David Welden. I have put a fair bit of time into getting up and running with it, updating it, and testing it against EPM 11.1.2.3. I have now moved the code from its previous home on Google Code to an open repo on my GitHub account.

Other than moving to GitHub, I have included a few updates for the newest version of Hyperion, updated the documentation, and consolidated the distribution down to one master set of files. The future plans for this project are to keep validating it against Hyperion updates, polish it a bit, and enhance the documentation even more. At this point I don’t have any plans to significantly change the functionality.

I know there’s a handful of you out there that are hardcore users of this so if you have any issues or questions, please don’t hesitate to contact me.

Happy Friday! These weeks are flying by like a blur, it seems.

As you may know from my previous posts, I’m constantly thinking up little Hyperion-related app ideas. And since it’s Friday, I’m feeling a little whimsical and have YET ANOTHER app idea. How about an app that detects when you are designing a cube that takes input at level 1 (or level 2 for good measure), then you run the app and it automatically emails you too tell you that you’re an idiot. BONUS POINTS for turning off Aggregate Missing Values!

Genius. I like this.

I have a question for my audience about a tool idea. Would it be useful to be able to tell what the data differences between two cubes with the same (or highly similar) dimensional structure is? For example, let’s say you had Sample/Basic on one server, and Sample/Basic on another server. Would it be useful to check for differences in the data loaded to them, if any?

I could see this as possible being helpful in checking for differences between cubes in development/qa/production, between archive cubes and ‘real’ cubes, and possibly during testing when you spin off a side cube to check some calcs.

Just a thought. Let me know! After HUMA is kicked over the wall I’ll be looking for my next side project (as time permits) and I am trying to focus on things that will increase the productivity of Hyperion developers.

Thank you all so much for helping out. I am absolutely blown away at the response that this utility has generated from all of you. Please let me know if you run into any issues.

Changing subjects (and zooming out) a bit, back to my efforts to understand what you (as consultants and Hyperion professionals) check during your “health check hit list“, it’s my goal over the next year to put together a suite of power tools that enable all of us to create, analyze, and maintain more robust solutions. HUMA is one such tool in the toolbox.

I have a few other ideas up my sleeve, but if you ever find yourself saying, “Self, I wish I had a tool for [fill in the blank]” or “I wish there were an easy way to…” then I would love to know about it. Even if it’s something you do already that’s perhaps manual and laborious, perhaps it can be automated, sped up, improved, and made useable by the community at large.

I have been working on a tool called HUMA – Hyperion Unused Member Analyzer. The idea for it came out of some side discussions at Kscope a couple of months ago. The idea is simple: Wouldn’t it be nice if there was an easy way to determine if any members are unused in a given cube?

Given a server, database, and credentials, HUMA will connect to a a cube, analyze its stored members, generate a list of all possible values, then iterate over it, analyzing the resulting data grids for the presence of data. If there are members with no data in them, they are shown to the user running the program. To increase performance, HUMA orders the grids and sequences of members within the sub grids so that they are aligned to the dense/sparse structure of the cube, so that it can pound on the same hot blocks before moving on to grids with different sparse permutations.

On a pretty gutless VM of mine with Essbase running in 1GB of RAM, a standard Sample/Basic cube can be ransacked for data in about three seconds. Also, given the way the tool works, it’s not necessary to do a full export of a cube or anything since the analysis is based on the data that is queried and immediately discarded. So far it seems to work pretty well.

The goal of the tool is to be a tool in the toolbox for Hyperion/Essbase admins that want to analyze their environment and act on possible improvements. This goes hand in hand with my research and efforts to find out what we all do when we dive into a new system as part of a health check hit list.  Doing so on a BSO database can yield improvements (particularly on dense members).

In any case, version 1.0 of the tool is basically ready to go and I’d love to have a few people test it out and let me know of any issues!

Happy Monday.

Do you love random, not-quite-Essbase-related posts? Well, I’m going to find a way to relate this to Essbase, believe it or not. I am the proud owner of an AquaFarm. Actually, I’m not sure if proud is quite the right word. I am very enthusiastic about aquaponics, but my current living arrangements don’t quite accommodate my interest. I received an AquaFarm as a gift a while back, which is a very miniature aquaponics setup. The kit has everything you need: the tank, pump, shale rocks, seeds, growing baskets… but no fish. Nicely enough they give you a coupon for a betta fish from Petco. Right now the fish is named Mr. Fish.

Just for fun and to cement my Essbase geek cred, I propose giving the fish an Essbase inspired name. Here are my thoughts so far:

• Low Block Density
• Inter-dimensional Irrelevance
• Unable to Save Custom Views
• Multiple Retrievals On A Single Sheet

Have your own stupid name for my new fish? I’d love to hear it. :D

I know there’s lot of you Java and Essbase folks out there in addition to myself. I’m always interested in ways to use an IDE more effectively. I came across this list of Eclipse annoyances and easy solutions for them earlier today. I am already using some of these but some of them are new to me. So if you want to get your environment dialed in a little bit, check these out. And for you IntelliJ folks… just keep being your normal smug selves. ;-)

Oh, and I’m thinking about doing a small series on “Essential Java for Essbase Developers” or something along those lines. It’d be something like a tutorial series on how to navigate around all of the Java terminology, features, and ecosystem in order to get straight to developing the solutions you want to develop, just a little bit quicker. Let me know if you have any thoughts or suggestions!

 

 

I can’t believe I didn’t know about command-line utility until very recently. I was doing a little research on some text processing utilities and came across the “paste” command. As a Mac user I have this installed already, and this appears to be a fairly common LInux/Unix tool as well. It’s part of a suite of text processing utilities that are fairly standard. Oddly, I am very familiar with the likes of sed, grep, awk, and so on, and yet have not stumbled upon this.

Anyway, imagine the following files, starting with names.txt:

Jason
Cameron
Tim

And numbers.txt:

555-1234
555-9876
555-2468

Then we just run paste:

paste names.txt numbers.txt

And we get this:

Jason   555-1234
Cameron 555-9876
Tim     555-2468

Paste just marries the files up by column, reading from each file. You can supply more than two files.

I don’t have an immediate need for this utility for processing Essbase data, but it just might come in handy someday, so I’m going to keep it in my back pocket. And for you Windows users out there, well, you know the deal: get cygwin or whatever the latest and greatest Unix-on-Windows environment is.