Hyperion Planning ASO Plan Type Setup

Aggregate Storage (ASO) plan types provide a powerful new dimension to Hyperion Planning. I thought today, we’d take a quick look at how to set one of these plan types up. Now at times, the initial setup can be a bit frustrating, especially if you’ve already set up your planning application and are creating the ASO plan type as a subsequent step. I’ll try to go over some of the things that you will need to keep in mind when setting up this up. In my example, I am setting up an ASO version of a Workforce cube.

First things first, to enable an ASO plan type, navigate to Administer > Manage > Plan Types.


You’ll see a list of currently available plan types:


Select the ‘+’ sign to add a new plan type. Provide a plan type name, select ‘ASO’ as the cube type (obvious much? Remind me never to hold the wrong end of a chainsaw), a cube name and an Essbase application name. The last item determines how this item shows up in Essbase. As Planning applications are of the block storage persuasion, a separate application and database are created in Essbase.


Run through a quick refresh.


And you’ll see an empty outline when you log on to Essbase Administration Services:


To enable a dimension for ASO, you need to edit the dimension’s properties. This is where the setup is not super intuitive. You would think that standard dimensions like Accounts, Entity etc would show up naturally on ASO, but this is not the case. You have to enable each dimension you would need on the plan type.


I felt like an idiot when I noticed that the Years dimension was missing from my outline, even though all the other dimensions showed up (wait, didn’t we say something about a chainsaw earlier?). Even though it is a flat dimension, the principle does not change, just edit the properties, as you would on all the other dimensions.


One thing to note on the Accounts dimension is that you are able to set up hierarchy types as Stored or Dynamic, just like you could on regular ASO cubes. Easier said than done, as it might be hard to convert your dimension to be completely stored. But if you are able to, it might give you some performance gains.


Once you’ve enabled all your dimensions, try running a refresh. This is what I got when I ran it for the first time (one of the first few times I ran it):


It worked…for the most part, but why are my other dimensions empty? Well, since this planning application was set up initially without enabling the ASO plan type, none of the members have the ASO plan type selection enabled. I thought this would get automatically turned on when you enable the main hierarchy, but what do I know…


All you have to do, if this happens is export out your metadata (as shown in an earlier post) and make a couple of adjustments. In the screenshot below, I’ve exported out accounts, deleted all the columns I don’t need (even if you don’t have those columns, your metadata is not going to be overwritten). The ‘Plan Type’ column was initially set to ‘False’. I changed it to ‘True’ and re-imported the hierarchy. Refresh once again, and you should be good to go.



You will run into errors when you do this. No avoiding it. Here are some of the peaches that I ran into:




As is evident, most of them cropped up in the accounts dimension. I had to change the metadata on my accounts members, so, I followed a couple of rules (this may or may not work for you depending on your setup):

  • Any parent that didn’t need to be aggregated was tagged as ‘Label Only’ with the ‘~’ consolidation operator.
  • All level-0 members for the ASO plan type would be ‘Never Share’.
  • Any parent that needed to be aggregated would be tagged as ‘Stored’ with the ‘+’ consolidation operator.


So there you have it; I’ve tried to hit most of the key notes on this feature. Of course, you might want to add additional dimensions (like an analytic dimension for periods-to-date). You can also add MDX formulas directly from the Planning edit member properties pane, just make sure to toggle to the right plan type.


We’ll look at data loading options in a later post.


About Vijay Kurian

Known as the Clem Fandango of EPM consulting, Vijay Kurian has been developing enterprise solutions for companies for the last 12 years (increment years if reading post-2015). Having worked with Essbase, Planning, DRM and other assorted technologies during that time, he’s made the frankly, average decision, to write about them. He is, surprisingly, an Oracle ACE Associate. He hopes to contribute frequently to US Weekly, People and Sensible Chuckle magazines on improving reporting solutions, creating master data management systems and zzz…


  1. hi, is it possible to perform copy data for a ASO plan type. i have tried to do that in my application having ASO plan type, it is not possible to perform the same in our application.

    • Sorry for the late response, but, to copy data in an ASO database, you would have to use a procedural calc script (run through MaxL) or through a data load. Granted, I have not tried the first option on an ASO plan type, but I don’t see why it shouldn’t work.

Leave a Reply

Your email address will not be published. Required fields are marked *