Managing SKIPCHECK and Feeders in IBM Cognos TM1
When you first begin to use TM1, especially if you came from the EP world as I did, you can quickly become enamored with how well TM1 can handle large cubes with ease. You can create multiple hierarchies within a cube and within those hierarchies TM1’s sparse consolidation algorithm aggregates values at light speed. You can reach out to virtually any data source with a Turbo Integrator (TI) process and create a dimension, create and populate a cube with data, or a myriad of other tasks only limited by the developer’s imagination. The challenge comes when you need to write rules governing more complex calculations or movement of data between cubes. No intuitive D-Links or BiF’s here. Everything must be coded, and getting the calculations to work properly requires mastering the art of feeders.
Why use a SKIPCHECK?
In a large cube with a great deal of data sparsity (relatively few cells with non-zero values compared to the total number of cells in the cube), cube performance could suffer significantly if TM1 was required to perform a calculation on every cell. Anyone who has ever tried building a large cube in EP knows exactly what I mean. The SKIPCHECK statement tells TM1 to ignore cells with zero or null values when processing rules. This is what gives TM1 its efficiency, because it only performs the calculations where there are values to calculate.
What are TM1 Feeders?
What does all of that have to do with feeders? Feeders essentially tell TM1 which cells are rules-calculated, and not to ignore those cells during consolidation. Failure to do so will result in your consolidations having zero values, or worse yet, incorrect values. While using feeders can be confusing, especially when you are new to TM1, it is a necessary exercise to keep the TM1 engine operating at peak efficiency. If managed properly you’ll save yourself the grief and anxiety that so many developers encounter.
How do I use TM1 Feeders?
Let’s start by looking at a simple rule and the construction of the corresponding feeder statement. In this rule ‘Gross Sales’ is being calculated by multiplying ‘Unit Price’ and ‘Volume’. While this is a very basic rule (in TM1 the rules can become far more complex and involved especially when we are coping with cubes where dimensions do no match) it does illustrate what I am trying to show in a way that is easy to comprehend. Here’s the rule as it would be written inside the TM1 Rules Editor:
The corresponding feeder statement is essentially the opposite of the rule, hence the following:
[‘Unit Price’] => [‘Gross Sales’]; [‘Volume’] => [‘Gross Sales’];
Feeders are just markers communicating to the rules which values should be calculated and which cells should be ignored because they are zero. After the feeders have marked the cells, the rule(s) are executed and actually perform the calculations on only the marked cells. The feeders above, while technically correct, may not both be necessary, and putting both of them in your rules may result in overfeeding. In very large cubes with copious amounts of rules and corresponding feeder statements, it could potentially result in a degradation of performance. Instead, choose to construct the feeder statement for the element most likely to contain zero values. In our example above, would be the logical choice to feed, because there is a greater likelihood that for a given intersection in the cube, there would be a unit price, but no volume. In some cases, you may need a little trial and error to determine the best solution.
That’s our initial look at SKIPCHECK and feeders, and how they can present a challenge for even seasoned TM1 developers. In part two of this article, we’ll tackle the construction of feeders between cubes, with the added complexity of dimensions that do not match.
