6 Domain Creation and Maintenance

This chapter of the security guide covers domain creation and maintenance.

Configuration Management

The process of RPAS application configuration can be performed by an RPAS administrator, an application expert, a consultant or a third-party implementation team. In all cases, the process of creating or modifying the configuration of an RPAS application is performed using a stand-alone Java application known as the RPAS Configuration Tools.

The RPAS Configuration Tools work with an XML representation of the content of a domain known as the domain configuration. Using the Configuration Tools, a domain configuration can be inspected and modified. The configuration is then used as an input to the rpasInstall process, which creates and modifies RPAS domains.

Because the RPAS Configuration Tools are supported only on the Windows platform, there is a need to manage the transfer of that configuration between the system being used for the configuration and the system on which the RPAS domain will be built and maintained.

Although the configuration itself does not contain any sensitive information, it does contain information about the meta-data of the domain and the processes used to maintain and modify that domain data. As such, it is prudent secure the representation of the domain contained within the configuration.

To that end, there are three areas in which the security of a configuration can be discussed. These areas are:

Upon the system on which the configuration process is performed.
Upon the system on which the RPAS domain is deployed.
Upon the transfer of the configuration between the above two systems.

In each of these areas, precautions can be taken to maintain the integrity and confidentiality of the information represented within the configuration.

Securing the configuration system

As the RPAS Configuration Tools do not interact directly with an RPAS domain, they cannot be used to inspect or modify domain information. However, because the configuration describes information about the information in the domain and the processes used to maintain and modify that information, it should be viewed as proprietary information. As such it should be subjected to the appropriate considerations employed to protect other proprietary information present on user systems.

The considerations include safeguarding the physical security of systems that store proprietary information, encryption of storage devices for these systems and limiting risk of exposure through controlling access to the information contained within the configuration.

Securing the deployment system

The domain configuration is an input to the rpasInstall process which runs on the system on which the RPAS application is deployed. It therefore needs to be deployed to that system in order to build or modify the RPAS domain. As such, the information contained within it should be protected while it is present on the system.

The protection requirements for the information contained within the configuration are similar to the requirements for other proprietary information stored on the system. These include controlling access to the system and maintenance of system for managing rights of users on that system. The configuration itself, being a set of XML files, should be subject to file system protections to limit access to the files to appropriate users.

Securing the transfer of configurations

Configuration is performed on one or more users' individual systems. In order to build or update an RPAS domain with that configuration, it is necessary to transfer the configuration to the system upon which the domain will be deployed. As with any information transfer between systems, this transfer should be protected. Therefore, maintaining a secure environment for the configuration includes the use of secure file transfer protocols to protect the information during the transfer along with the safeguarding of the source and destination systems.

Dynamic Position Maintenance

The creation of positions within the dimensions of an RPAS domain is a process that is performed as part of an off-line process managed through the loadHier utility. However, the business processes performed by some RPAS applications make deferring position creation and management to an off-line process unacceptable.

Dynamic Position Maintenance (DPM) allows user to create and manage certain positions in an online process while working within a workbook. Users can create additional positions within constraints based on domain security settings and the workbook configuration and enforced by the RPAS Server instance.

Users can also modify and or delete existing positions created through DPM operations within constraints based on domain security settings and the workbook configuration and enforced by the RPAS Server instance.

Users are not allowed to modify or delete positions which the domain's security settings do not grant them access to; they may also not modify positions not allowed by the configuration of the workbook in which they are working. Finally, changes to formal positions managed through the loadhier process cannot by modified in any circumstances through DPM operations.

Enabling DPM functionality within a workbook involves the following process:

Configurator must enable DPM on particular dimensions on the domain.
Configurator must enable DPM on the specific workbook template.
Configurator or system administrator must ensure there is enough space to accommodate the volume of DPM position given by the bitsize of the dimension.
Administrator must give WRITE permission on that workbook template to the user.

When a user creates DPM positions, they are treated as temporary positions; loadHier does not update these positions. A command line utility informalPositionMgr is available for the purpose of:

When a user has finalized its information and wants to convert them to normal positions.
Application involves creating a very large number of DPM positions.

Like all RPAS server utilities. This command line utility should only have execution rights granted to system administrators.

RPAS Maintenance

Domain maintenance is a periodic operation that needs to be performed by the administrator. Its frequency depends on the degree to which the domain is subjected to hierarchy changes across time. Many of these operations can improve overall performance of data access operations - this can result in fewer contention issues which improves accessibility.

In addition, many of these operations involve removing data from the domain when that data is no longer needed by the operations being performed by the domain. This periodic cleansing serves to remove data from the system and addresses the need to retire data as a part of the data management life cycle. Some of the domain maintenance tasks that can be performed periodically are:

Purging unused and inactive hierarchy positions

All measure data within a domain is stored in either scalar or dimensional measures. As positions are introduced to the hierarchies of a domain, these positions become available for the storage of measure data. When a position is no longer needed by the domain, it can be purged. This purging, along with the use of the reindex domain, or optimize domain processes will result in the measure data associated with the retired positions being cleaned from the domain.

The purging process is performed by use of the loadHier utility purge operation. loadHier can be used to purge formal, informal, and user-defined positions from the listed hierarchies.

Cleanup of the input and processed directories

RPAS makes use of the loadhier and loadmeasure utilities to load information into the domain. These utilities read data in the form of text files that are staged to the input directory of the domain. Once the data in an input file is loaded, that file is moved to the processed sub-directory of the domain, where they are suffixed with a timestamp indicating the date and time of load.

Periodic clean up of these processed files is advisable because, over a period of time, these files can occupy sizable and valuable diskspace. Furthermore, although all information contained within the files present in both in the input directory and processed sub-directory should be protected by file system security, removing files when they are no longer required removes their potential vulnerability should file system protections be compromised. User can maintain and use a script to delete these files from the input/processed folder periodically.

Reindexing domain arrays

Run the reindexDomain analyze option from the master domain on individual hier/dims periodically to check whether a particular hier/dim requires a bitsize increase or whether it needs to be defragged. If hierarchy operations are frequent enough and if the above check is not made, then the size of the hier/dim and the available list of physical ids may not be sufficient enough to accommodate and allocate for the incoming hierarchy load request. This can result in a loadhier failure.

ReindexDomain also reshapes arrays and a periodical run, in conjunction with the use of hierarchy purging, will remove inactive physical ids and can potentially reduce the size of the domain arrays and remove unneeded data from the domain.

Optimizing domain arrays

Run optimizeDomain periodically from master domain to improve performance and to minimize the space required by the domain data. Optimize domain has options to selectively defrag domain data based on database fragmentation and, in conjunction with hierarchy purging, to clean up domain data that is no longer required by the system.

A detailed description of LoadHier, ReindexDomain, and OptimizeDomain can be found in Oracle Retail Predictive Application Server Administration Guide.