01 December 2012

Fixing Planning's annoying LCM dimension import error

The problem

I am a big, big, big fan of Lifecycle Management (LCM) for migrating Planning applications.  It gets better and better with each release, and has (hopefully) forever gotten me out of the business of modifying Planning schemas and hoping that I got everything right when I did it.  Yup, LCM is great, but I have found that sometimes when I migrate an application, or try to pull dimensions out of an application, the dimensions import in the wrong order, and then those rogue dimensions cannot be moved in the Performance Settings screen.  

NB – In case you have still not twigged on to this, I am talking about Classic Planning.  I try, successfully I might add, my very best to stay away from EPMA.  You can draw your own conclusions as to why, but have a read of this thread for more information.

Back to the issue, am I imagining that Planning dimensions cannot be moved, sometimes, after LCM importation?  Nope, as it is documented in this Oracle Support KB:  Unable to Order Dimensions Through Hyperion Planning 'Performance Settings' Screen [ID 1072365.1].

And what does that really mean?  

Here is a brand new Planning database with the dimensions in the (sort of, actually, I want Segments to go right above Entity) right order.

Yes, that looks an awful lot like the Planning sample application, but it’s my take on it for use in a future (hint, hint) blog post.  I want the dimensions to be ordered (mostly) this way.  

So what happens when I use LCM to import those base dimensions from the Planning sample application?

Hee I am grabbing them from an LCM file source:

And my target – have you figured out yet what the next blog post is likely to be about?

In progress:

Done, and successfully:

And here it is:

Guess what, Segments is where it ought to be (somewhat miraculously as it has moved, and that is a clue) , but Entity is not.  Can I move Enitity?  Why, I cannot move the !@#$ing thing.  The up and down arrows – they do nothing.  Ai, Caramba!  This is the bug referenced in Oracle Support.  If you read that Support article, it claims that this is fixed in 11.1.2.1.  I have news for you – this is on 11.1.2.1.  The bug is still with us.  

Two possible fixes

Now to be fair to the KB article, it has two solutions.  The first suggests editing the HSP_DIMENSION table and modifying the dimension’s POSITIONx field.  I am a tremendous fan of reading from the Planning tables, but I get nervous (I am the nervous type in general) when I change the tables.  What could possibly go wrong?  Uh, everything, if I FUBAR/SNAFU it as is my wont.

The below may seem a little daunting, but is actually quite simple, although I would recommend using some of the queries I’ve written about in the past to figure out what those DIM_ID values actually pertain to:

The other approach is (and I only quote this because it is incomplete) this:
SOLUTION 2:
1. Export the Standard dimension settings using LCM.
2. Edit the xml with notepad, ensure there are no duplicate values in the Plan1, Plan2 etc., performance orders.
3. Import the standard dimension you edited back into the app using LCM.
4. Planning performing as expected.

As far as I can tell, the duplicate values issue above is not the issue/fix.  Well, maybe it is sometimes, but not in the context of the single PlanType application that is the sample Planning application.  Maybe that is the right approach in multiple PT apps, but I leave that to you to prove or disprove.

The fix that works

The KB is so close – all we need to do is combine the first suggestion and the second one and we are going to be very happy geeks.  What do I mean?  Well, remember that LCM xml files contain everything there is to know about a dimension, including its position.  How else do you think the Planning repository gets that information?

And what oh what do we see below?  Is that the dimension order?  Why, yes it is.

And what happens if I turn that 3 to a 4 and reimport the dimension?

‘Arf a mo, guv’nor,  won’t there be another dimension with an order of 4?  Yep.

Hmm, let’s take a look at all of the Plan1PerfOrder settings in the export files and then how do we want it to look?

Dimension
Exported order
Desired order
Period
2
1
Account
1
2
Segments
4
3
Entity
3
4
Year
3 (yes, really)
5
Version
8
6
Scenario
7
7
Currency (to be revealed in the next blog post)
N/A
N/A

What needs to be done then is to set all of the dimensions to the right order and then bring them all in.  

Problem (hopefully) solved.

Set those dimension orders

Period


Account


Segments


Entity


Year


Scenario


Version


And do that import

Save the files, and then reimport.

Success, boil in bag

LCM works just fine, so those xml file mods were tickety-boo.
And then see what we have in Planning.
Ta da, we are done as the dimensions are in the right order.  That was only slightly painful, and now I can go on my merry way with the work I really want/need/am-compelled-to-do-even-though-it-may-spell-my-certain-doom-such-is-my-lot-what-is-yours to do.


No comments:

Post a Comment