Configuration Tools User Guide

B Appendix – RPASCE Cloud Partitioning Guide

Note:

This chapter contains descriptions of features that are not supported in the current version of RPASCE. However, in order to assist in the process of migrating to the RPASCE platform, the configuration components associated with these deprecated features remain present within the RPASCE Configuration Tools and therefore continue to be described within this document.

The domain partitioning is deprecated. The domain is always created as a simple domain and only used in the PDS building/patching process. However, in the data mart schema of PDS, fact tables are partitioned. Proper partitioning is crucial for optimal performance. The concept and method of partitioning PDS is the same as that of partitioning global domain in older versions of RPASCE: the configurator first chooses a partitioning dimension level, and then assigns positions to partitions. The partition configuration file partitioninfo.xml is one of the required input files to the deployment process. Refer to Planning Data Schema Administration in Oracle Retail Predictive Application Server Cloud Service Administration Guide for PDS partitioning.

This chapter provides guidelines regarding Oracle Retail Predictive Application Server Cloud Edition (RPASCE) partitioning for the application. It is intended to help the RPASCE application configurator and system integrator properly partition the data storage for optimal performance.

Overview

Traditionally, there are two ways to configure the partitioning of a global domain. One is using only a command line parameter -p to specify the partition dimension for the RPAS Installer command (rpasInstall), in which case each position of the partition dimension will be used to create a local domain. Another way is providing a configuration file called globaldomainconfig.xml, which specifies the partition dimension, the absolute path to the master domain, and the absolute path and grouping of the positions of each local domain. The first approach is very straightforward and allows the users to control the partitioning through the hierarchy structure. Some users even create an artificial dimension solely for this purpose (for example, a dimension called ldom). The second approach provides flexibility and more control over the locations of the master domain and the local domains, and how the partition positions are grouped into the local domains.

In RPASCE, both options are supported. The first option is usually called internally by RPASCE since the customer may not have direct access to the rpasInstall command. The second option requires modification to the partition configuration in order to be cloud compliant.

Domain Partitioning

The purpose of using a global domain and partitioning data across multiple domains is to help reduce contention, provide smaller domains for most users to interact with, and allow for parallel processing during batch. If the partitioning is not done correctly, it can lead to unnecessary contention or poor performance. Here are some key considerations to understand when determining how to partition a global domain environment:

The hierarchy that you partition on must allow the users the ability to work in a single local domain. If users require access to all positions within a hierarchy, that is not a good candidate for partitioning. For example, it does not make sense to partition on the location hierarchy if your business process requires all users to include all locations in each workbook.
The partition level must also be above the level at which most of the data is stored. If most data is stored at the division level or below in the product hierarchy, the partition level must be at the division level or above. When data is based above the partition level of the domain, the data will be stored in the single master domain. All users across the local domains that require this data will have contention from all of the users and not only the users of the local domain that they are working in.
The partitioning must be set such that the business requirements do not require high usage of the master domain. The performance of a workbook built from the master domain will never match that of a local domain workbook. The heavy usage of workbooks must take place across the local domains. For example, if most of the users only need to see data within a division, the partitioning must not be done below that level.
The number of users that are in a single local domain must be evenly distributed across all the domains in a global domain environment. If there are a larger number of users in a single local domain than others, it will not matter how many partitions you create. The domain with the largest user group will always have the potential to experience more contention issues and poor performance. If possible, create more domains and separate more users across those domains.

Note that the domain partitioning is not visible from the front end or User Interface (UI). It is solely used for better organization of data storage on the server.

Performance Considerations

When deciding on the partitioning dimension and how many of its positions are in each local domain, one should consider two main items: batch performance and front-end usability. From a batch standpoint, local domains must be as balanced as possible. This will allow for the most efficient usage of system resources. Balancing local domains refers to the idea that each local domain must be performing a similar amount of work with a similar number of positions. Front-end usability refers to the preference of keeping the slice of the hierarchy that a user needs to access regularly, contained within a single local domain.

Domain Partition Configuration

The original globaldomainconfig.xml in RPAS is broken down into two files for RPASCE:

globaldomainpartition.xml, which is modified from the original file to remove the path and add a partition name for each grouping
globaldomainpaths.xml, which contains all the path information

Original content:

<?xml version="1.0" encoding="UTF-8" standalone="yes" ?>
<!-- Initial creation of domain -->
<rpas>
<globaldomain>
<path>C:/work/rpasce_btree/domains/RPAS_UT_G</path>
<partitiondim>dept</partitiondim>
<subdomain>
<subpath>C:/work/rpasce_btree/domains/RPAS_UT_G/ldom0</subpath>
<subpositions>dept01,dept02</subpositions>
</subdomain>
<subdomain>
<subpath>C:/work/rpasce_btree/domains/RPAS_UT_G/ldom1</subpath>
<subpositions>dept03,dept04</subpositions>
</subdomain>
<subdomain>
<subpath>C:/work/rpasce_btree/domains/RPAS_UT_G/ldom2</subpath>
<subpositions>dept05,dept06,dept07</subpositions>
</subdomain>
<subdomain>
<subpath>C:/work/rpasce_btree/domains/RPAS_UT_G/ldom3</subpath>
<subpositions>dept08</subpositions>
</subdomain>
</globaldomain>
</rpas>

New globaldomainpartition.xml modified from the original globaldomainconfig.xml:

<?xml version="1.0" encoding="UTF-8" standalone="yes" ?>
<!-- Initial creation of domain -->
<rpas>
<globaldomain>
<partitiondim>dept</partitiondim>
<subdomain name="ldom0">
<subpositions>dept01,dept02</subpositions>
</subdomain>
<subdomain name="ldom1">
<subpositions>dept03,dept04</subpositions>
</subdomain>
<subdomain name="ldom2">
<subpositions>dept05,dept06,dept07</subpositions>
</subdomain>
<subdomain name="ldom3">
<subpositions>dept08</subpositions>
</subdomain>
</globaldomain>
</rpas>

These names for the sub-domain must be unique. They will be used as the directory name of the local domain.

Optionally, a second configuration file globaldomainpaths.xml can be used to specify the root paths of the master and local domains. This file must be managed by the OCI or Oracle Cloud Engineering/AMS. It contains system information (file or directory paths) that must be kept confidential.

<?xml version="1.0" encoding="UTF-8" standalone="yes" ?>
<!-- Initial creation of domain -->
<rpas>
<globaldomain>
<path>C:/work/rpasce_btree/domains/RPAS_UT_G</path>
<subdomain name="ldom0">
<path>C:/work/rpasce_btree/domains/RPAS_UT_G</path>
</subdomain>
<subdomain name="ldom1">
<path>C:/work/rpasce_btree/domains/RPAS_UT_G</path>
</subdomain >
<subdomain name="ldom2">
<path>C:/work/rpasce_btree/domains/RPAS_UT_G</path>
</subdomain>
<subdomain name="ldom3">
<path>C:/work/rpasce_btree/domains/RPAS_UT_G</path>
</subdomain>
</globaldomain>
</rpas>

Note that the path under <subdomain> is the parent directory of the local domain. It is appended with the sub—domain name to form the final path of the local domain. The globaldomainpartition.xml file is required if the globaldomainpaths.xml is provided. They must have matching local domain lists.

If the globaldomainpaths.xml file is not present, all local domains will be created under the global domain directory with the sub-domain name as its directory name.

Note:

The paths specified in the xml file must not exist before the domain is built. Otherwise, an Domain Already Exist exception will be thrown during the domain build.

Building a Domain Using the RPASCE Installer

If globaldomainpartition.xml is provided, it must be put under the directory specified by the rpasInstall command line parameter -ch <config_home>. If globaldomainpaths.xml is provided, it must be put under the directory specified by the environment variable $RPAS_CUST_ROOT.

The globaldomainpartition.xml is required if the globaldomainpaths.xml is provided. They must have matching local domain lists.

The partition dimension can be specified by the -p parameter or by the <partitiondim>xxxx</partitiondim>. If both -p and partition dimension name must match.

Both globaldomainpartition.xml and globaldomainpaths.xml are only required during the domain initial build. They are not required for domain patching since the domain partitioning cannot be changed after domain creation.