Conditional feeders can be used to minimize the storage impact of rule feeders. The typical situation occurs when rule values are calculated by multiplying factors, any of which may be zero. This means that the value should be fed only when all the factors are non-zero.
Given a cube SalesBySalesperson with dimensions:
- Measures (‘Sales’ and ‘Commissions’)
If you calculate Commissions based on Sales using a commission rate as follows:
['Commissions'] = N:['Sales'] * db('CommissionRates', !product, !month);
Commissions should be fed from Sales, but only if the commission rate for the product in the month where the sale occurs is non-zero.
This can be accomplished by a feeder of the form:
['Sales'] => db( cubename, !salesperson, !product, !month, 'Commissions');
Here, cubename is a conditional expression that results in a blank if the corresponding commission rate is zero. Since a blank cube name cause the feeder to be ignored, the required effect is produced.
The complete feeder would then read:
['Sales'] => db( if( db('CommissionRates', !product, !month ) = 0, ' ', 'SalesBySalesperson'), !salesperson, !product, !month, 'Commissions');
NOTE: The above example assumes that commission rates do not change. If a commission rate were to change from zero to a non-zero value, the required feeder would not take place.
To remedy this problem with conditional feeders in the CommissionRates cube, write a feeder as follows:
Note that since we cannot write a conditional expression based on the sales to feed only those salespersons that have non-zero sales, all salespersons must be fed, which results in overfeeding.
A different way of ensuring conditional feeders are performed is to re-process the feeders from SalesBySalesperson whenever CommissionRates is changed. This can be done by either:
- Re-compiling the rules for SalesBySalesperson
- Executing CubeProcessFeeders(‘SalesBySalesperson’) from TurboIntegrator.
Note that re-starting the server will also ensure all feeders in all cubes are re-processed. This is normally not recommended because, depending on how many cubes need to be fed, it may take an unnecessarily long time.
Two-Way Conditional Feeders
If commission rates are variable by salesperson (the CommissionRates cube had the same dimensions as SalesBySalesperson), you can write two-way conditional feeders as follows:
In the SalesBySalesperson cube:
['Sales'] => db(
if( db('CommissionRates', !salesperson, !product, !month ) = 0, ' ', 'SalesBySalesperson'),
!salesperson, !product, !month, ‘Commissions’);
In the CommissionRates cube:
 => db(
if( db('SalesBySalesperson', !salesperson, !product, !month, 'Sales') = 0, ' ', 'SalesBySalesperson'),
!salesperson, !product, !month, 'Commissions');
Reevaluating Conditional Feeders
In some instances when conditional feeders are used in rules, a change in the condition value does not trigger the feeder. For example, suppose your rule has the following feeder structure:
- Cell A feeds cell B.
- Cell B feeds cell C when condition D is true (this is the conditional feeder).
Assuming condition D is false, a change in the value of cell A triggers feeding of cell B, but the feeding of cell B does not trigger the feeding of cell C. This is because at this point, condition D is false, and cell C is fed only when the condition is true.
Now, if condition D subsequently becomes true but the value of cell A does not again change, cell C remains unfed. This can lead to inconsistencies in data
If you add the line ReevaluateConditionalFeeders=T to the Tm1s.cfg for your server, any changes to cell values referenced by conditional feeders will force the feeder to be re-evaluated. If ReevaluateConditionalFeeders is not enabled in the Tm1s.cfg file, feeders from numeric cells are executed only when the cell changes from being zero to having a nonzero value.
In the above example, any change to a cell value that causes condition D to become true would force a re-evaluation of the conditional feeder, resulting in cell B feeding cell C.
ReevaluateConditionalFeeders is an optional parameter that must be explicitly added to Tm1s.cfg.
Other changes to the cube, such as changes to attributes, do not force the feeder to be re-evaluated. Only cell value changes trigger the re-evaluation.