Master Data Volume and its Impacts on BPC for NetWeaver
Overview
BPC for NetWeaver does not have any pre-defined limits on the amount of master data that can be stored in any one dimension. The amount of master data included in a dimension impacts BPC performance in the following ways:
- Client Login Performance
- Dimension member master data cache files are created for clients on the BW tier the first time a client logs in from a specific system and on subsequent logons if there are changes to master data.
- These cache files must be loaded into memory on the client tier (BPC for Excel, BPC Administration, etc).
In both cases, the amount of master data is one of the primary factors dictating performance.
- Administration Operations
- Processing dimensions will take progressively longer as more master data is created
- Selecting members when configuring Member Access Profiles and Business Process Flows is impacted by volume of master data
- Client Report Creation Operation
- Some operations, such as creating an EvDRE report may cause master data to be read from the cache files. In these cases the amount of master data has a direct impact on client side performance.
It is possible that client side issues exist and have not yet been identified which impose a limit on the actual amount of master data that can be loaded for a given dimension/application. In these cases the limitation is generally induced by a defect which is later corrected by development.
There is no limitation to the amount of accessible master data inherent in the design of BPC at this time.
What Factors Determine Master Data Cache File Size
Each dimension a user has access to gets cached during the first login on a given machine and then subsequent logins, when changes are made. The XML cache files consist of one line per dimension member / hierarchy that a user has access to. Each line documents all of the properties associated with that dimension member.
Thus, there are three primary factors that determine the size of a master data cache file for a given dimension:
- The number of hierarchies
- Either:
- The number of dimension members (for unsecured dimensions)
- The number of dimension members that a user has access to (for secured dimensions)
- The number and size of properties
Example 1:
For example, a simple unsecured dimension and one hierarchy containing 15,000 members will result in a file with approximately 15,000 lines (there will be a couple more to make it a well formed XML file).
Example 2:
If you take the same dimension, and double the number of properties (with consistent sizes to the first set of properties) you will effectively double the size of the cache file even though it will not result in any additional lines in the XML file.
Example 3:
Similarly, if you were to add a second hierarchy to the same dimension, including all existing members, you would approximately double the size of the cache file by approximately doubling the number of lines in the file.
Increasing the size of the cache file increases:
- The amount of time it takes to create cache files in BW
- The amount of time it takes to transfer cache files to the client over the network
- The amount of time it takes for the client tier to interact with master data (login, some action pane operations, etc).
Recommendations / Best Practices
Now that we know the drivers to large dimensions, we can design some best practices to mitigate their impacts.
Recommendation 1: Secured Dimensions – Only provide access to required members
Often times, secured dimensions are the largest. When working with large secured dimensions, ensure that you configure member access profiles in a way that only grants access to required members. By limiting the number of members and/or hierarchies a user has access to you are directly impacting the size of the cache files used on the client tier which in turn increases performance.
Recommendation 2: Hierarchies – Evaluate whether additional hierarchies are required
Multiple hierarchies are often required and can be included in well designed applications however; it is worth evaluating whether an additional hierarchy is required to reach your goal. There are other techniques that can sometimes be used in place of a hierarchy without losing any functionality.
Depending on the purpose of the hierarchy, some possible alternatives include:
- Adding one or more additional dimensions to the application model
- Adding logic to simulate the rollups to be included in the new hierarchy
Recommendation 3: Property Names – Keep property names concise
This is a relatively simple one to demonstrate. If you have a dimension with 120,000 lines (unique member / hierarchy combinations), and you name a property “ARLP” instead of “A_REALLY_LONG_PROPERTY”, you will decrease the cache file by a little more than two megabytes. If you enact shorter names for multiple properties, or have more lines in your cache file, the savings can be much greater.
Final Thoughts
We are continually seeing refinements in the way BPC creates and interacts with master data so setting any targets or limits on master data volume would quickly become out of date. That said we currently have successful BPC NetWeaver customers with dimensions containing greater than 100,000 members.
Based on the information above, you know what drives the size of the master data cache files and where the application will be impacted. You also have the aforementioned guidelines to help mitigate the impact of large amounts of master data.
5 Comments
