BSo Will never Die and here Is Why - Developing Essbase Applications - page 133

Figure 4.11 Dense block modification example.
Figure 4.12 Results after flipping order of time and measures.
The order changed. I should not be surprised because the order of processing is clearly
explained in the DBAg. however, the test demonstrates the importance of dimension
order if we are expecting all of the accounts to be calculated for a month before moving
on to the next month.
4 .7. 4 Reduce Processing and Simplify Code
variables are also handy when it is necessary to control the processing of a calculation
script. Let us assume that we have an employee forecasting application and there is a
need to calculate benefits for each of our 50,000 employees based on a blended rate. The
application has many rates and rather than clog up the Employee database, the benefit
rate is stored in a BSo database called Emp_rates. The benefit rate is pulled from the
EmP_rates database using the @xrEF.
Benefits = Salary * @XREF("_RateCube_", "Emp_Rates", "Blended Rate" )
Certainly the code will work, but it takes a lot of processing and network traffic to do
this 50,000 times. The rate could be pulled once and stored in an account for use by the
formula, but that defeats the purpose of the rate database. A better solution is to use a
variable in a calculation script.
VAR vInitialize = 0;
VAR vBlendedRate = 0;
FIX(OUTLOOK, BUDGET, FY12,@RELATIVE(EMPLOYEES,0))
Benefits(
IF(vInitialize ==0) /*execute first time only */
vBlendedRate = @XREF("_RateCube_","Emp_Rates", "Blended
Rate";
vInitialize = 100;
ENDIF