So as we were saying in January this not very known feature of HP is not a miracle cure. But after spending some days on trying to prototype it for an example with something like 11 dimension application (+ all the attribute dimensions) I thought it would be good to add something to my previous post.

I had one HP application (one plan type), which is an EPMA application. After few attempts I was able to create an application that has a compatible data model as the HP one. Reused few dimensions from the Shared Dimension Library and removed members, like the one linked to SmartLists from the Account dimension. I created two additional dimension to describe the options we have in SmartLists and deployed. Now something I have been chasing around for a bit was the labels. So if you read the documentation you will noticed that name or alias of the new dimensions has to match label of the SmartList members/options. This point is very very important.

The application created is an Essbase BSO and deployed from EPMA. Now I made it as BSO just because…in fact you should think about this very carefully. There is much sense in make it a ASO application.

This is an example out of the prototype (changed some names, but you get the point):


Something that took me a while to grasp is the two SmartLists are now real dimensions, which means you need an intersections of at least one member out of it to hold the data. So what we can do is add a “N/A” member, for those combination of data, in the Prototype I just choose the first member out of the lists, anyway what transpires is that this new dimension would probably be dense…making all “a bit” bigger, on both sides source (HP) and target (Essbase BSO). Maybe ASO? Maybe custom mapping?

I explored the custom option as well. Thought of exporting data from HP application Essbase cube, first and re-mapping it on the base of what is in the metadata of the application. Here is a sample Select statement for this:

Select entry_id, name, label
from HSP_ENUMERATION_ENTRY
where enumeration_id = (Select ENUMERATION_ID
from HSP_ENUMERATION
where name = 'SmartListName');

HSP_ENUMERATION, contains the all the SmartList and their id codes.
HSP_ENUMERATION_ENTRY, the SmartList members are in here with their id, labels and their id to tide them to their SmartList.

Point being is doable and with not THAT much effort and this would mean the source target does not need to have any value of the original SmartList instead only the target would have the N/A member where to map this slices of data.

Anyway, a bit of a long post. And last but not least my question is: Does anyone has any “how to”, that they would like to recommend for this?

I thought of posting an update about one of the new Hyperion Planning (11.1.2+) features. I will keep it short:
– This feature is not the miracle pill (sorry developers). Why not? ‘Cause it’s not what the name suggests. It (only) maps data from one application to the other,
knowing how to interpret the Smart List data. Keep in mind names/labels are only available on the level of Hyperion Planning metadata,since they are stored in the DB not Essbase.
– The reporting application (yes it can be an ASO) + database + all dimensions and members need to exist before you can push data in.
– The Smart Lists you want to analyse need their own dimension(s) – careful with names/labels, if you confused about it look at the export file created and throw out the dimension members (probably accounts)
– If you create it in EAS, you will need to provision the user. I did it with admin user and it took me 30 minutes to figure out that one of my problems was due to only having “Provisioning” rights on the new application.

For the rest “how to” this two links were really useful (more then the official documentation):
11.1.2 Planning Mapping Reporting
Mapping Applications for Reporting

Other considerations:
– Licenses, since you make a new Essbase application.
– I would suggest EPMA should be able to handle this better/with less hassle then if you use a classical planning application, since you can reuse dimensions/members…
– Behind the scenes no real magic happens (more info in John Goodwin blog and is easy to find the generated files so you can look for yourself, plus is always good to check the Essbase logs) and as I see it this all could be build as part as a bigger integration work with some “ETL” magic and maybe a bit more wits.

This is just my thoughts as usual 🙂