I’ve already written partially about this, but now I’m trying to solve it by adjusting the listing.xml that LCM uses to import articafts. LCM moves most of the needed stuff before environments correctly, with few exceptions, organizing the folders by date of creation being the main one.
Now this is a dummy case, but it could happen – especially in older version than I’m testing this on – that when importing from Acceptance to Production you end up with a similar mass:

When you look at listing.xml it will look this:

The lines circled, and the only that need adjusting, both on Folder side and as well Forms one. This is what they will look like once re-ordered:

Once you have saved the changes, and after deleting the incorrectly ordered folders just simply import by using the new listing file and TADA:

Working with HP sometimes you get to dig in the Planning DB, here is my latest story. Might be good to mention don’t do this home alone without supervision by an adult.

I have been dealing with an applications sited in an older Hyperion (x.2.1) version. And when using LCM, it decided to re-order folders as it wished. “Move” did not do much in the sense of letting me re-order it. Here is a view of me trying to – btw you might notice it’s not the same version as my demo lab is x.2.3. – import the data forms.



In HP after import with LCM (AppX*) :

Which leaves me with a nice mess. So I decided to have a look at the background.

As I had to somewhere I first had a look at a select statement to get the most common object types counts:

On one of the apps I’m running on my x.2.3 lab, gives this result:

What about the Folder count per parent, to be able to compare two environments, you need the name and not id as that is probably different from app to app.

So let’s run the query, which just gives us you the count and the names. All the queries from here on were run on our AppX database:

But let’s go back to the problem that bought me here. You might have already know or notice while reading this the important column is Position as is how Planning knows how to sort the folders. Let’s take the “two ends” of the folders, just for a comparison, as you can see that the folders starting with 1, :

If you don’t know the “Forms” object ID, you can always do this to see the second generation:


After update has run:

If we now check our AppX we see this:

Very easily you can do something similar with TaskLists:


So on the other hand this is how it looks creating folders in Planning:
Step 1:
Step 2
Step 3
And Step 4 looks like 1, so working as intended, so if you want to re-order you just have to do it with some sql skill.

Better late than never. I got to install the new version of HP. Still not patched but that will be my next step. For now I got this:

In the installation I used: CentOS 5.11 and Oracle DB 12c.

Kernel info (you will be able to see it in the validation, later on as well):

The uninformed surprise (as I did not prep on the new things in the DB, this bit was much a surprise – both positive and negative one):

I was surprised how easy the Hyperion bit was. Install was pretty much as always Next, next, next…and the configuration, tho I did it in few iterations, was very simple and without any pain.

Validation (“Green…green everywhere”):

At this point I had to see a new application in the system…as seeing EAS empty made me a bit sad.

HCSample seemed a good idea. At this point I wanted to see LCM error, before all else. So imported CalcMng before just to see it error:

Sounds correct…I did try to trick you CalcMgr. Now importing “module” per module works. But did they somehow improve the import process? Almost…almost


…2min later. Did I configure FR even? Nop 😀

Okey. Lets try this again. Delete existing app and rules…just in case DS as well, so at least I know I started with a clean environment.

And ta-da:

After further check – still had to create a FR connections (5 in this case).
The FR book still does not work as expected.

On further note it all good looked in Planning (& FR), until I tried to look into CalcMgr.
Turns out only some parts got imported. Reimport on it’s own and much more artifacts are present now.

Last though on this point:
– As for now I would still NOT recommend importing the whole starter kit in one go…at least from this experience.
– I’m using 8Gb on my Virtual Machine, running DB and WebLogic and Hyperion and it’s not slow – so kudos*.

*For Reference

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
where enumeration_id = (Select ENUMERATION_ID
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 🙂