DimensionElementComponentAdd - a bug or expected behavior ??

[hyunjia]

Hi Gurus

I am scratching my head for hours for this issue . Please share your insight and help . Here is my current dimension structure :
N A
N B
N C

C All Alphabet
A
B
C
Alpha
Beta

C Alpha
A

C Beta
B

What I want to do is to unwind all the consolidation first and then rebuild the hierarchy . So I created a generic process to do that by putting the ELCOMP and DimensionElementComponentDelete altogether as ( Dim.Element.Unwind) . However, after I run the main process (zTest) , I got this :
N A
N B
N C

C All Alphabet
Alpha
Beta

C Alpha

C Beta
C B
The unwind would only apply to Alpha but not Beta . To debug , I wrote the unwind statement in the main process instead and abandand the statement of "executeProcess" in the prolog and run it again (zTest2) , and I get the expected result .
N A
N B
N C

C All Alphabet
A
B
C
Alpha
Beta

C Alpha
C Beta

Strangely enought , If I remove the line "DimensionElementComponentAdd ( sDim , sTopConsol , sConsol , 1 ) ; " from the original process (zTest3) and run it , I would could see the unwind process did do his job , althought All Aphabet is empty which is expected because I removed the stament .
C All Alphabet

C Alpha
C Beta

How strange is that , the generic process could unwind the first consolidation Alpha but not the secnond one Beta when I call a executeprocess to do that .

Please let me know your thoughts , I really really appreciate that !!! . Here is the related objects for your reference.

[hyunjia]

Forgot to mention , I am running tm1 10.1.1 fp2

[lotsaram]

This is expected behaviour as described by Duncan here and here.

Each TI process even if called from another using ExecuteProcess takes its own private metadata copy as the pre-update starting point which will be the state pre-commit. Therefore if you want to do a "function call" type operation like unwind it will not work in combination with later metadata changes within the same process. The solution is to either incorporate all the unwind code within a prolog loop as you have had to do (which is kinda naff and avoids the benefits of having a function library like bedrock in the first place), or else use a chore and call the unwind before the main dimension update in the chore. This is also a little unwieldy as function calls to a library from within a main dimension update process would be much nicer and cleaner.

I for one am very much hoping that this problem will dissolve once we have a bedrock java function library to do things like dimension unwind. Then presumably as long as you are careful to make no metadata changes in the prolog BEFORE calling unwind.js then this kind of thing will possible and we can have much neater and less redundant code for dimension updates.

[hyunjia]

Hi

That would just make sense . I did suspecte the cause would be the "private copy" behavior , but I always thought the private copy was taken when the first statement from the prolog is executed , as such the dimension shouldn't be update at all . Now that I understand what the true trigger would be the meta data update statement and all this behavior would just make sense .

When I execute unwind first on Alpha , the public dimension is updated ,then since I execuete ElementComponentAdd , it take a private copy at the point where Alpha is unwinded but Beta isn't . so the Beta sructure would always the same even thought I execute a seperate unwind process in the subsequent statement

To work around this , I wrapped the elementcomponentadd in another process and execute in the prolog , the result seems to be fine . However , my question is , would this workaround cause a lot of overheads when it's used on a larget dimension such as cost centre or accoutns ?

What would you recommend ?