TM1 Forum

Hi all,

I'm really struggling with this so I'll try to explain what's going on. We have two cube that are identical except for the "Job" name. Each level zero job in the destination cube is a consolidation in the source cube and has a suffix added to it. So job "TEST1" in the destination cube is called "TEST1_R2012" in the source cube.

We wrote rules to set the destination cube "TEST1" = source cube "TEST1_R2012" for specific accounts....and then wrote a feeder to point values for TEST1_R2012 => TEST1. It works fine so long as nothing changes in the job hierarchy. Assume "TEST1_R2012" and "TEST2_R2012" in the source cube each have one child. "TEST1a" and "TEST2a" respectively. If I move "TEST2a" into "TEST1_R2012"...the values change in the source cube but they aren't fed to the destination cube. To get them to feed...I have to re-save the rule file. Then it magically works again.

Clearly, moving jobs within the hierarchy (which changes the consolidation values) doesn't trigger the feeders to re-fire. We tried several things including pointing the feeder at a third cube which contains a "Parent" attribute for each of the source cube jobs. When the hierarchy changes, a process runs to change the parent and that change was expected to cause the feeders to re-fire. It didn't work either.

Here is one of the rules and the corresponding feeders we've tried. They all work...but don't re-fire when the hierarchy changes

Rule in the Destination cube (note:the 'CMN Tag' reference is adding the suffix mentioned above):
['IWAGA Link', 'Local', 'Currency K'] = N:
DB('IDS Cost IWA Approved FCST', !IDS Job | DB('}ElementAttributes_IDS Scenario', !IDS Scenario, 'CMN Tag'), 'TOTGA', !IDS Scenario, !CMN Data Source, !IDS Location, !IDS Time Period, !CMN Currency, 'Value (Thousands)');

Feeder (note:the second DB lookup is using the third cube to determine the Job name without the suffix) :
['TOTGA', 'Local', 'Value (Thousands)','IDS Scenario':{'Rolling Forecast'}]=>
DB('IDS Cost FCST', DB('IDS Job IWA Attributes', !IDS Scenario, !IDS Job IWA, 'Trimmed Job'), 'IWAGA Link', !IDS Scenario, !CMN Data Source, !IDS Location, !IDS Time Period, 'Local', 'Currency K');

Other Feeder attempts:
['TOTGA', 'Local', 'Value (Thousands)','IDS Scenario':{'Rolling Forecast'}]=>
DB('IDS Cost FCST', SUBST('IDS Job IWA', 1 , LONG(IDS Job IWA')-6), 'IWAGA Link', !IDS Scenario, !CMN Data Source, !IDS Location, !IDS Time Period, 'Local', 'Currency K');

['TOTGA', 'Local', 'Value (Thousands)','IDS Scenario':{'Rolling Forecast'}]=>
DB('IDS Cost FCST', SUBST(DB('IDS Job IWA Attributes', !IDS Scenario, !IDS Job IWA, 'Parent'), 1, LONG(DB('IDS Job IWA Attributes', !IDS Scenario, !IDS Job IWA, 'Parent'))-6), 'IWAGA Link', !IDS Scenario, !CMN Data Source, !IDS Location, !IDS Time Period, 'Local', 'Currency K');

All of these feeders work but none of them re-fire when the hierarchy changes or when the parent/trimmed parent changes in the third cube (IDS Job IWA Attributes). In all cases...the only way I can get the values to update following a hierarchy change is to re-save the source cube's rules file (the one with the feeders). This isn't a big deal in this particular cube because it's small...but we have the same problem with cubes that take over an hour to save the rules file.

My thought is that when we move the jobs in the hierarchy...the data changes on the consolidation jobs in the source cube...and that change should trigger the feeders...but it doesn't. Turning SKIPCHECK off works...so I know it's a feeder issue, I just don't know what else to try.

Any help would be appreciated!

Terry

After reading several other posts...I think I know why it's not working. Nothing is changing at the leaf level of the source cube. I'm sending all jobs from the source cube to the destination cube but what's changing are the values of consolidations...not leafs.

Based on this...do you think the "CubeProcessFeeders" command from TI would work in my case? I'm not necessarily trying to establish new fed cells...just trying to get the new values to feed to the destination cube. The rules are working correctly for leaf level jobs in the destination cube...they just aren't fed so they won't then roll up the hierarchy.

Terry

Okay, I answered my own question...it does work. I was able to change the job hierarchy and have the data not update correctly in the destination cube. Then I ran a TI to reprocess feeders on the source cube...and the values updated correctly in the destination cube.

Unfortunately, this isn't a good solution for my other cubes having the same issue. I will try it later to make sure, but I'm thinking re-processing the feeders is what takes forever when it comes to saving the rules files on those larger cubes. If that's the case...it will simply take too long. I can't lock up the system for that long while users are trying to do their jobs.

What you are experiencing is the normal behavior for feeders when you use a consolidation in one cube to feed a leaf in another. In reality, you aren't really feeding a leaf from a consolidation, you are feeding the leaf in the destination cube from all the leafs underneath the consolidation in the source cube. TM1 monitors the leafs in the source and when a value is posted, the feeder path for that leaf is fired and the destination is fed. Changing the consolidation scheme in source will nor fire the feeders.

The easy answer is to reprocess the feeders when the consolidations change. even though it may not be the best answer from a performance standpoint. There are other options but they have their own complications. An idea they I have used successfully in situations like yours is to have a Feeders cube, using the affected dimension from the destination cube, that I post a value of 1 to and use that to feed. Whenever you change the hierarchy or update a job you post a 1 to the appropriate summary job. If you are doing your changes with an input form you might be able to sneak in the DBS and hide it from the user so they don't even know it's there.