Kyle McCollum, Senior Principal Technical Support Engineer and RPAS Support Global Product Lead, shares best practices to encourage solid RPAS design and implementation.
Oracle Retail Predictive Application Server (RPAS) Support frequently responds to performance problems/concerns which may arise when loading hierarchies that add new partition positions and/or reclass existing products from one local domain to another. Below is Part 2 of a 3-part blog series which presents concepts intended to aid customers in putting forth the best design possible to ensure that the highest levels of performance are achieved when performing such actions.
PART 2 OF 3
By effectively using the parameters provided by loadHier, it is very possible to reduce the total reclass time by 50% or more. When performing a large reclass (such as one involving 10K+ items), this time savings could certainly make the difference when it comes to meeting an ‘Application Up’ SLA (service level agreement) for the business.
Although very powerful when it comes to performance optimization, the following parameters tend to be overlooked by most RPAS designers:
Path to exclude list XML file. Optimize performance by excluding this list of measures while moving data during the hierarchy reclassification process.
Path to include list XML file. Optimize performance by including only this list of measures while moving data during the hierarchy reclassification process.
Without these parameters specified, every single measure with a base intersection that contains the reclass dimension will be invoked for a data transfer from the source domain to the destination domain -- including transferring data for calculated measures, which is a wasteful activity.
Therefore, the -excludeMeasList and -includeMeasList parameters should be a key part of every RPAS design in the field. Designers should exploit this feature by telling RPAS to move data only for non-calculated measures during the reclass. Consider the fact that after the reclass, the next likely batch job is going to be the main batch calculation sequence. Thus, let the calculation engine perform the work of populating the data of calculated measures for the positions that have just been reclassed, and allow the reclass itself to bypass this duplication of effort.
A designer can quickly get a list of all calculated measures by using a 'mace –print –group' command and then piping that output to some 'grep' statements to get the LHS measures of the expressions. All rule groups with the exception of _load, _refresh, _commit should be evaluated to find the LHS measures. The 'mace –print –allGroups' should NOT be used, as this would include the rule groups just mentioned.
Another approach would be to utilize the “measure description” field in the Configuration Tools to describe each measure appropriately (e.g., “A calculated measure that ……” or “A loaded measure…”). Then a command such as “printArray -array data/measdata.measinfo -slice info:description -cellsperrow 1 | grep -i calculate” would provide a list of the calculated measures.
Part 3 of this blog series will discuss space requirements for a large reclass.
Click here to revisit Part 1 of this series, which discussed partitioning considerations.
Feel free to comment on this article in this forum, or you may take in-depth questions and discussions to the Retail Predictive Application Server (RPAS) Support Community on My Oracle Support.