TM1 Forum

Hello everybody,

here there is a general issue we usually have in our application.
Imagine two have to cube, Cube A and Cube B.


Cube A
- Account
- Cost Center

Cube B
- Account
- Cost Center
- Cost Center owner

Then we ha a Param cube which connects a Cost Center to a Cost Center owner.

Cube Param
- Cost Center
- Coster Center Owner Measure

Here below you have the rule and the feeder in the respective cubes.


Cube B Rule:

[] =: IF (!Cost Center @= DB (Cube Param, Cost center, 'Owner'), DB (Cube A, Account, Cost Center), STET);

Cube A Feeder:

[] => DB (Cube B, Account, Cost Center, DB (Cube Param, Cost center, 'Owner'));

My issue is typically in the feeder; not in writing it but in using it.
I mean that I would like that Cube be would fed correctly everytime the CubeParam is changed.

With the feeder I wrote this is not happening because the changing of the parameter is not triggering the cells of cube A so Cube B will not change from the changes of Cube Param.
In this case I have to refire the feeders and this will may take a lot.

Otherwise if I made a feeder from cube Param I certainly overfeed on the account dimension or other possible dimension which I may have and that are not calculated in all the members.

I tried I third option which is a feeder cube but managing this cube it can be very time-consuming.



Is there any best practice in this case to avoid this situation?
What do you do typically in this situation?

Thanks in advance,

Nicola

Do you have ReevaluateConditionalFeeders=T in your tm1s.cfg file?

Hi
If you don't use your third option the feeder cube, which I would recommend using, ReevaluateConditionalFeeders won't do anything for you.

I take it you ommitted several other dimensions from your example and focused on the ones you deem important to explain the problem. And depending on how many consolidations you actually have to overfeed in your feeding cube it can take a bit to compile the feeders that feed that cube but other than that I don't quite understand how it would be time consuming to manage that.
Maybe you could explain how you actually implement option 3 and why it is time consuming.

Cheers

Gregor,
First of all, yes the example was done in with the most important dimension. The others, less important, are not in the example.

with time consuming I mean the time the system will take to insert the feeding data into the feeder cube.
i had an experience with this and I tried to implement the first option.
In this experience I had to assign stores to owners . I had a cube containing only stores and other 9 business dimensions. Then another cube and the the store and a separate dimensions with the owner (it was a dimension because one owner could have more than one store) + other 9 business dimensions.


After having done in I realized the following things:

Cons:
- the feeder cube, which was the same in terms of dimension of the target cube, took a lot of time to be filled by process. This activity, was done, for the entire cube every night.
It took almost 2 hours.
- Every time there were a changing on the master data the user had to launch this process and this activity was very confusing and not natural for him. With a normal feeder (if it is possible) the data is automatically refreshed.
- It takes a lot of space and the RAM increases a lot. (the feeder cube was taking almost 1,5 Gb). In my solution I had three of them.


Pros:
You don't have to re-fire the cube everytime and if you change just one master data you can refresh only that part of the feeder.