Using Attributes to map Feeder destinations

[PavoGa]

This seems like it should work, but it is not unless the server is restarted or feeders are reprocessed on the cube. The target element in the DB() function is determined by the attribute for a value stored in an input cube.

The rule calculates properly, but the results are not fed. The question boils down to is the construction of the feeder correct and/or is there something about retrieving the attribute causing the problem?

Code: Select all

FEEDSTRINGS;
SKIPCHECK;

['Budget', {'All Employee Incentive', 'QIP Incentive', 'CAP Incentive', 'Executive Incentive', 'Marketing Incentive'}] = N:
                IF (!StaffingCalc_Measures @= ATTRS('Staffing_IncentivePlans', DB('Staffing Calc',
                                !Com_Versions,
                                !Staffing_Types,
                                !Com_Slots,
                                !HIERARCHY_STAFFING,
                                !Com_Months,
                                'Incentive Plan'), 'StaffingCalc_IncentiveElement')
                , DB('Staffing Calc',
                                !Com_Versions,
                                !Staffing_Types,
                                !Com_Slots,
                                !HIERARCHY_STAFFING,
                                !Com_Months,
                                'Monthly Incentives')
                , 0) * ['CountFlag1'];
                
FEEDERS;

# feed  the appropriate incentive with CountFlag1
['Budget', 'CountFlag1', {'Current Staff', 'BSKL', 'Adds', 'Transfers'}] => DB('Staffing Calc',
                !Com_Versions,
                !Staffing_Types,
                !Com_Slots,
                !HIERARCHY_STAFFING,
                !Com_Months,
                ATTRS('Staffing_IncentivePlans',
                                DB('Staffing Input', !Com_Versions, !Staffing_Types, !Com_Slots, !HIERARCHY_STAFFING, 'Incentive Plan'),
                                'StaffingCalc_IncentiveElement') );

[jim wood]

It's a variable feeder. If you change the attributes then you need to process the feeders. It's the way it works.

[PavoGa]

Thank you for posting back. The attributes are not changing. The dimension is a picklist and I added the attribute to eliminate the conditional in the rule and feeder. Here is the previous version of the feeder:

Code: Select all

# Feed the appropriate StaffingCalc Incentive Element with CountFlag1
['Budget', {'Current Staff', 'BSKL', 'Adds', 'Transfers'}, 'CountFlag1'] => 
    DB('Staffing Calc', !Com_Versions, !Staffing_Types, !Com_Slots, !HIERARCHY_STAFFING, !Com_Months,
        IF(DB('Staffing Calc', !Com_Versions, !Staffing_Types, !Com_Slots, !HIERARCHY_STAFFING, !Com_Months, 'Incentive Plan') @= 'All Employee'
            , 'All Employee Incentive', '') ),
    DB('Staffing Calc', !Com_Versions, !Staffing_Types, !Com_Slots, !HIERARCHY_STAFFING, !Com_Months,
        IF(DB('Staffing Calc', !Com_Versions, !Staffing_Types, !Com_Slots, !HIERARCHY_STAFFING, !Com_Months, 'Incentive Plan') @= 'QIP'
            , 'QIP Incentive', '') ),
    DB('Staffing Calc', !Com_Versions, !Staffing_Types, !Com_Slots, !HIERARCHY_STAFFING, !Com_Months,
        IF(DB('Staffing Calc', !Com_Versions, !Staffing_Types, !Com_Slots, !HIERARCHY_STAFFING, !Com_Months, 'Incentive Plan') @= 'CAP'
            , 'CAP Incentive', '') ),
    DB('Staffing Calc', !Com_Versions, !Staffing_Types, !Com_Slots, !HIERARCHY_STAFFING, !Com_Months,
        IF(DB('Staffing Calc', !Com_Versions, !Staffing_Types, !Com_Slots, !HIERARCHY_STAFFING, !Com_Months, 'Incentive Plan') @= 'Executive'
            , 'Executive Incentive', '') ),
    DB('Staffing Calc', !Com_Versions, !Staffing_Types, !Com_Slots, !HIERARCHY_STAFFING, !Com_Months,
        IF(DB('Staffing Calc', !Com_Versions, !Staffing_Types, !Com_Slots, !HIERARCHY_STAFFING, !Com_Months, 'Incentive Plan') @= 'Marketing'
        , 'Marketing Incentive', '') );

[declanr]

Too tired to look in detail at the actual rule/feeder atm but if using conditional feeders it is always worth having the ForceReevaluationofFeedersforFedCellsonDataChange tm1s.cfg parameter set.

Or whatever the long and wordy cfg parameter is (its something like that.)

[PavoGa]

Thanks, declanr. That variable is set, but in this case, the feeder has been changed to a non-conditional. It looks up the value in the Input cube, retrieves the target element attribute from the dimension and uses that as the target of the feeder. It works fine...if feeders are reprocessed or the server restarted.

The current construction of the feeder (in my first post) seems to be pretty straight forward. But obviously it is not. Is there something special about using attributes to map the target for a feeder?

Thanks, again to you and Jim both.

I did only what my duty demanded. I could have taken no other course without dishonor. And if all were to be done over again, I should act in precisely the same manner.

[tomok]

Updating string values used in feeders will not trigger a re-evaluation of the feeders. This is a known fact with TM1. You'll have to force the re-evaluation with a TI process (with an embedded CubeProcessFeeders function in it), a re-save of the rules, or by recycling the service.

[declanr]

As tomok said a process is needed.

To make this more "user friendly" I would create a websheet (or just for use in perspectives) where the users input all their changes with an action button at the top to run the TI.

[Wim Gielis]

Updating string values used in feeders will not trigger a re-evaluation of the feeders. This is a known fact with TM1. You'll have to force the re-evaluation with a TI process (with an embedded CubeProcessFeeders function in it), a re-save of the rules, or by recycling the service.

Adding to this for completeness: if the cell where you are feeding from is a text cell, then changing the cell with trigger the feeders out of that cell (unless a numeric cell when you change the cell from a non-zero value to another non-zero value).

[Steve Rowe]

Hi,
If your feeder works when the rule sheet is saved or the server is recycled then the feeder is constructed correctly. It will fail if

Code: Select all

ATTRS('Staffing_IncentivePlans',
                                DB('Staffing Input', !Com_Versions, !Staffing_Types, !Com_Slots, !HIERARCHY_STAFFING, 'Incentive Plan'),
                                'StaffingCalc_IncentiveElement') );

resolves to something different post save / launch.

As others have stated you'll need to recycle the rule sheet if it changes, this probably won't be practical if you're doing anything real time in a large model. There is an alternative though (I think, untested).

If you have control over when the

Code: Select all

ATTRS('Staffing_IncentivePlans',
                                DB('Staffing Input', !Com_Versions, !Staffing_Types, !Com_Slots, !HIERARCHY_STAFFING, 'Incentive Plan'),
                                'StaffingCalc_IncentiveElement') );

changes (or you can track the changes) you may also be able to deduce what the input value is that you want to trigger the feeder.

If so then rather than a TI to recycle the rule sheets, the TI could copy the input value to an unruled mirror cube, zero out the ruled input source cube and then write the data back from the mirror cube.

Since feeders are also triggered and derived items on the right hand side recalculated when an item changes from 0 to non-zero this should keep the feeder working.

Obviously you'll need a more sophisticated TI but provided the area of the cube is sufficiently targeted it should be a lot faster in a large model.

Cheers,

[PavoGa]

Okay, I think I see what you are saying, but let's see if I have it right:

The user is selecting the string value of the incentive plan in the value. The feeder uses that value to lookup the attribute of the incentive plan that tells the DB() function what element to actually feed. Because the item doing the feeding is a number, it has already fired and is not being re-evaluated to actually feed the target element.

Thanks again.

[PavoGa]

Wm.

Don't you mean changing a zero to a non-zero value?

[Steve Rowe]

The user is selecting the string value of the incentive plan in the value. The feeder uses that value to lookup the attribute of the incentive plan that tells the DB() function what element to actually feed. Because the item doing the feeding is a number, it has already fired and is not being re-evaluated to actually feed the target element.

Yes, (numeric cell sourced) feeders are not live in the same way rules are, they are one off events that happen when a cell changes from zero to non-zero. (or server starts / rule sheet saved)

The point Wim is saying, but probably doesn't apply in your case is that feeders triggered from strings input cells are different, they fire every time they change..

Simple!

[PavoGa]

Yes, I've been able to get the feeder to fire by simply changing one of the string values in the input cube.

By the way, thanks for the suggestions, unfortunately, I'm kind of locked in on how it will have to be handled, precluding switching up and using perspectives, websheet or TI process to deal with it for now.

[PavoGa]

SOLUTION!

Good Gracious, this was too simple. The feeder is relying on the Incentive Plan to determine where to feed. The numeric feeders have already fired once when this is being calculated, so no feeding. Changed it to feed from incentive plan and it fires correctly every time.

Just kind of had to stew about it. The correct code:

Code: Select all

# 7/17/14 feed  the appropriate incentive with Incentive Plan - Ty  
# this feeder was not working properly with numeric feeders because those had already fired before this one could be resolved.
# kind of like it is a second-tier calculation/feeder.  Changed it to feed from the dependant string Incentive Plan
# and it fired 100% of the time.  (No Makers Mark was consumed in the resolution of this problem)
['Budget', 'Incentive Plan', {'Current Staff', 'BSKL', 'Adds', 'Transfers'}] => DB('Staffing Calc',
                !Com_Versions,
                !Staffing_Types,
                !Com_Slots,
                !HIERARCHY_STAFFING,
                !Com_Months,
                ATTRS('Staffing_IncentivePlans',
                                DB('Staffing Input', !Com_Versions, !Staffing_Types, !Com_Slots, !HIERARCHY_STAFFING, 'Incentive Plan'),
                                'StaffingCalc_IncentiveElement') );

thanks to everyone for all the input.