In order to test whether BW aggregation is used by BPC report, we set up a demo environment:
It includes following dimensions, and storage type is PERIODIC.
Transaction data input through BPC Input Form, and BPC version is 10.0.
Case 1:
Step1: To build an aggregate on InfoCube with only one dimension in RSA1, here we use ACCOUNT, and scope is * which means for all members.
Step 2: Build a report in EPM Addin to query the data.
Result:
After refresh the report, we found the usage for the aggregate is still 0. Aggregate is not hit.
Case 2:
Step1: To build aggregate with all dimensions, and scope for member is * (all members included).
Step2: To refresh the report we used in case 1.
Result:
The usage for the aggregate increases after the query. Aggregate hit in this case.
Case 3:
Step1: Based on the aggregate used in case 2, we add a scope limit on hierarchy of ACCOUNT as node level equal 1.
Step2: To modify the report in EPM Addin to query the result of level 1 node in ACCOUNT hierarchy.
Result:
After refresh report, the usage is not changed. The aggregate is not hit in this case.
Case 4:
Step1: To remove one dimension for the aggregate used in case 2. For example we remove RPTCURRENCY.
Step2: To use the report used in case 2 and refresh.
Result:
The usage number is not changed. The aggregate is not hit.
Case 5
Step1: Based on the aggregate used in case 2, we add a limit on fixed member of TIME (= 2014.01).
Step2:
Build a report with ACCOUNT on row axis and TIME on column axis.
Set TIME to 2014.01, and test with difference choice of ACCOUNT dimension.
Result:
- If we use base member on ACCOUNT dimension, the aggregate is hit.
- If we use non-base member of ACCOUNT dimension, the aggregate is not hit.
Conclusion:
From previous tests we found it is necessary to include all dimensions in the aggregate. If you get rid of any dimension, BPC will not touch it. Setting member scope on dimension is okay, but not on hierarchy level.