This content has been marked as final. Show 3 replies
Not sure what do you mean by
"It change the structure of one of the dimensions, which must be done by the user - that is, my application must have response time of a few seconds for this."
Varying attributes provide ways to achieve SCD behavior in ESSBASE. However this feature seems to be not available in Hyperion Planning.
If you can explain your situation with an example, you may get some good suggestions.
The following situation applies dimension of Operation Units
At some point - very recurrent.
The user will need to change the member UO_505001D (Grandson), to take a position below UO_505006 (Child). And you need to rename it to appear to users the new name.
Then there is a consolidation.
And then again the same situation occurs with point 1.
And so often.
Dimensions are more than 1000 members.
400 users are.
I do not think i understand it very well. I would give it a try.
A section of your outline looks like this at one point
and then on user request, it should look like below
|UO_505050 (Parent) look like below
|__ UO_505001A (Grandson) renamed to UO_505006A
This is possible.
And depending on what you want to do with the history data in UO_505001A, you can take an action. If you want historical data to be seen under new name i.e. UO_505006A, you can take a level 0 export of UO_505001A before ESSBASE database refresh and load it to new member through rule file after database refresh. In fact, you can just rename the member on ESSBASE end (by opening outline in EAS) before planning database refresh and historical data will line up as expected.
Important point to remember is that when you rename a member on planning end, it is treated as delete and new addition at ESSBASE end when database refresh is done so current data does not get retained.