While developing an IBM Planning Analytics (PA) model, you may have come across a situation similar to the following:  A rule and feeder are seemingly working correctly, but upon a data change the expected cells are not returning values, implying they are no longer being fed.  Consider the example below showing a simple rule from a typical two-cube Workforce Planning (WFP) model, consisting of an input cube (“WFP Input”) where employee information is captured and a summary cube (“WFP Summary”) from which the calculated results of the model (e.g., Employee expense by Department) can be reported.

But what if the user decides to change the employee’s department from IT to Finance?  As you can see, the desired cells are no longer fed as evidenced by the mismatch between the value at the leaf and consolidated levels. Totals not rolling up correctly are a classic symptom of missing feeders.

So how can we ensure that the proper cells are always fed? One way would be to constantly process feeders via the CUBEPROCESSFEEDERS(); Turbo Integrator (TI) function.  However, this approach can bring about undesired consequences such as locking of the cube for the length of the processing and underfeeding in the event that a user forgets to execute the TI process.

To understand how we can make the feeder react to any change in input, we must consider when and how feeders are created in PA.  When feeding from a numeric cell, a feeder is evaluated only when the cell goes from zero to a non-zero value, hence why changing the department does not update the cell fed. This is observed in the example when feeding from numeric cells for Salary and Headcount.  Feeders originating from a string cell are reevaluated any time there is a change in the value of the cell, whether it is from blank to non-blank or between non-blank values.  In our example, a feeder from the department measure(string) solves our underfeeding issue.

The above methodology can be expanded to apply to multiple measures and dimensions.

In closing, there is one consideration to take into account when feeding from a string cell.  Unlike numeric cells which only store data at the leaf level, string data can reside at any level of a dimension.  In a case where a user mistakenly enters a string value at a consolidated level a feeder will be created for every intersection underneath that cell.  This has the potential to create a massive number of unwanted feeders which would lead to a spike in memory consumed as well as degraded performance.  This can be guarded against by writing a rule as shown below: