{"id":4055,"date":"2023-08-16T17:33:18","date_gmt":"2023-08-16T17:33:18","guid":{"rendered":"https:\/\/quebit.com\/askquebit\/?p=4055"},"modified":"2026-01-20T16:07:28","modified_gmt":"2026-01-20T16:07:28","slug":"getting-started-with-planning-analytics-rule-and-feeder-optimization","status":"publish","type":"post","link":"https:\/\/quebit.com\/askquebit\/getting-started-with-planning-analytics-rule-and-feeder-optimization\/","title":{"rendered":"How Do I Get Started with Rule and Feeder Optimization in IBM Planning Analytics?"},"content":{"rendered":"

Getting Started with Planning Analytics Rule and Feeder Optimization <\/strong><\/p>\n

If you are new to IBM Planning Analytics or specifically new to the task of rule and feeder optimization, the following information may help in getting started. Keep in mind that these are some simple \u201cstrategies\u201d or \u201cguidelines\u201d outlined here to provide general direction, with some specific prescriptions for action, but not meant to be comprehensive in that not all of the rule and feeder optimizations that may or may not be applicable to a specific model are covered.<\/p>\n

Starting Point<\/strong><\/p>\n

To get started, (I assume that you have the appropriate access to make changes to cube rules and feeders) make sure you are working in a development environment! Editing rules and feeders will cause locking and, more importantly, the changes you make most certainly will affect data in the cube (or at least how it is displayed) so you will want to be sure your edits are correct before landing them in a production environment.<\/p>\n

 <\/p>\n

Next, be sure to gather some performance baselines for the cube that you want to improve. That is, record all the statistics you can about the cube \u2013 total memory used, memory used compared to other cubes in the model, the number of stored calculated cells, number of fed cells, memory used for calculations and memory used for feeders \u2013 are some good data point examples.<\/p>\n

 <\/p>\n

Finally, create a backup! Even though you are working in a non-production environment, a notepad copy of the cube rule (RUX) file will be a handy reference as you progress with your changes.<\/p>\n

Step 1 \u2013 Reduction of Calculation Statements<\/strong><\/p>\n

Generally, the more rule (and corresponding feeder) statements you have in a cube, the higher resources (i.e., memory) will be used, so trying to reduce the number of rules is a good place to start. Since historical data does not change in real-time, it is not necessary for calculations based on this data to be performed in real-time. Rules that calculate cube N level values for historical (\u201cactualized\u201d) periods<\/strong> should be removed and reimplemented as TurboIntegrator (batch) processes.<\/p>\n

Again, the fewer the number of rules and feeders, the lower the memory and processor requirements will be, which typically results in improved performance. Furthermore, overall sustainability is improved since there is less code to maintain.<\/p>\n

Step 2 \u2013 Replace all ATTR Functions with DB Statements<\/strong><\/p>\n

Another \u201ceasy\u201d optimization\u2013 almost a \u201cfind and replace\u201d – is to \u201cswap out\u201d less efficient functions within a rule with a more efficient one. For example, using the ATTR<\/strong> function can be much (up to 70 % in some applications) slower than getting the value directly from an }ElementAttributes_ cube using the DB<\/strong> function; therefore, you should replace all<\/u> ATTR functions with DB functions.<\/p>\n

The following rule statements:<\/p>\n

 <\/p>\n

ATTRS (‘Cost Center’, !Cost Center, ‘Special Calc’) @= ‘Y’<\/p>\n

 <\/p>\n

And:<\/p>\n

 <\/p>\n

DB(‘Financial Planning’, !Versions, ATTRS(‘Periods’, !Periods, ‘Prior\u00a0 Reporting Period’), !Company, !Product, !Cost Center, !Region, !Financial Planning Measures)<\/p>\n

can be optimized to:<\/p>\n

 <\/p>\n

DB (‘}ElementAttributes_Cost Center’, !Cost Center, ‘Special Calc ‘) @= ‘Y’<\/p>\n

 <\/p>\n

And:<\/p>\n

 <\/p>\n

DB(‘Financial Planning’, !Versions, DB (‘}ElementAttributes_Periods’, !Periods, ‘Prior\u00a0 Reporting Period’), !Company, !Product, !Cost Center, !Region, !Financial Planning Measures)<\/p>\n

Step 3 – \u00a0Streamline and Simplification of Future Period Calculations<\/strong><\/p>\n

After you have addressed the historical (\u201cactualized\u201d) period calculations in the cube, it\u2019s time to look at the future period<\/em><\/strong> calculations. If you review these rules and observe any consistently utilized<\/em> attribute or control-element conditionals being used to invoke or \u201cfire\u201d rules (maybe lines such as these):<\/p>\n

IF (ATTRS(‘Versions’, !Versions, ‘Plan Helper Rules’) @= ‘Y’,<\/p>\n

IF(!Periods @> DB(‘Period Control’, !Versions, ‘Current Month’),<\/p>\n

Then the above conditional statements may be able to be removed (from all the future period calculations that include them) once the following CONTINUE\/STET statement is added to the top<\/u> of the rule (RUX) file:<\/p>\n

[ ] = N:<\/p>\n

IF ( !Versions @= ‘Working Forecast’<\/p>\n

, IF ( !Periods @>DB ( ‘Period Control’ , !Versions , ‘Current Month’ )<\/p>\n

, CONTINUE<\/p>\n

, STET<\/p>\n

)<\/p>\n

, CONTINUE<\/p>\n

) ;<\/p>\n

This statement \u201cturns off\u201d all of the future period calculations UNLESS the current version is \u201cWorking Forecast\u201d AND the period is a future period eliminating the need to repeatedly code the previously mentioned attribute and control-element conditionals in each future period calculation. CONTINUE allows evaluation to continue (fire calculations) while STET cancels all calculations beneath the (STET) statement.<\/p>\n

The idea here is to \u201cexperiment\u201d to see if a single (or a few) CONTINUE\/STET statement(s) can be used (obviously more efficiently) than having Planning Analytics interpret each<\/em> and all<\/em> of the rules to determine if it should be applied. You\u2019ll need to be sure to thoroughly understand all business logic on this one to make sure that the CONTINUE\/STET statement(s) include or exclude the applicable rule(s).<\/p>\n

Step 4 –\u00a0\u00a0\u00a0 Remove Unnecessary\/Obsolete Attributes<\/strong><\/p>\n

Object permanence is \u201cthe understanding that objects continue to exist even when they cannot be sensed\u201d; in every Planning Analytics model\u2019s lifespan, new objects are continually added, and typically existing objects are not always decommissioned. This means that the total number of objects increases while some objects continue to consume valuable resources while not adding value\u00a0 (since they are not or seldom used).\u00a0 To that point, in the above example, since the \u201cPlan Helper Rules\u201d attribute reference has been removed from the rule (RUX) file, it can be deleted from the model \u2013 again, if you are able to remove any attribute references (and those attributes are not used elsewhere in your model) get rid of them!<\/p>\n

Step 5 \u2013 <\/strong>Optimization of Feeder Statements <\/strong><\/p>\n

Every rule calculation statement should<\/em> have a corresponding feeder statement (yes, there are always exceptions) and each feeder statement implemented will have an impact on memory consumption. The more \u201cfeeding\u201d being done, the more memory will be consumed. To address \u201cover feeding\u201d, if possible, feeder statements should be first \u201cnarrowed\u201d by adding version (or other qualification) to the (left side of the) statement. An original feeder statement such as:<\/p>\n

[‘Planning Base Source’, ‘TOTAL_FTE_HEADCOUNT’, ‘Amount’] => [‘999999’];<\/p>\n

Could be improved to this:<\/p>\n

[‘Working Forecast\u2019, ‘Planning Base Source’, ‘TOTAL_FTE_HEADCOUNT’, ‘Amount’] => [‘999999’];<\/p>\n

Additionally, by adding a conditional<\/em> to the feeder statement, it can be further optimized (from the above) to the following:<\/p>\n

[‘Working Forecast’, ‘Planning Base Source’, ‘TOTAL_FTE_HEADCOUNT’, ‘Amount’] =><\/p>\n

DB(\u00a0 IF(!Periods @<= DB(‘Period Control’, !Versions, ‘Current Month’), CONTINUE, ‘Financial Planning’), !System Planning, !Versions, !Periods, !Currencies,<\/p>\n

!Company, ‘999999’, !Category, !Product, !Cost Center, !Region, !One Bank, ‘Amount’);<\/p>\n

 <\/p>\n

Adding a conditional(s) to a feeder statement makes it a \u201cconditional feeder\u201d. A conditional feeder will contain one (or more) of the following:<\/p>\n