Skip Headers
Oracle® Retail Predictive Application Server Administration Guide for the Classic Client
Release 14.1
E59120-01
  Go To Table Of Contents
Contents

Previous
Previous
 
Next
Next
 

1 Introduction

This guide is for administrators of the RPAS Server and the RPAS Classic Client.

Administrator Overview

After the RPAS Server and Classic Client have been installed, administrators must set up the RPAS Classic Client and complete several administration activities before they can begin using RPAS and RPAS applications. The activities include the following:

Before you start any of these activities, you should understand the basics of RPAS: domains, workbooks, worksheets, hierarchies, and measures.

Basic Concepts of RPAS

Retail Predictive Application Server (RPAS) is a configurable platform with a proven scalability for developing multidimensional forecasting and planning based solutions. This platform provides capabilities such as a multidimensional database structure, batch and online processing, a configurable slice-and-dice user interface, a sophisticated configurable calculation engine, user security and utility functions such as importing and exporting, all on a highly scalable technical environment that can be deployed on a variety of hardware.

This section introduces you to the following RPAS concepts:

Multidimensionality

In RPAS, information is stored and represented based on the multidimensional framework. In a multidimensional database system, data is presented as a multidimensional array, where each individual data value is contained within a cell accessible by multiple indexes.

Multidimensional database systems are a complementary technology to entity relational systems and achieve performance levels above the relational database systems. Applications that run on RPAS identify data through dimensional relationships. In RPAS, dimensions are called hierarchies. Hierarchies are qualities of an item (such as a product, location, or time) or components of a dimension that define the structure and roll up within the dimension.

Hierarchies

Hierarchies describe the top-to-bottom relationship between the levels or positions of the hierarchies in RPAS. They reflect the hierarchies set up at your business and being used by the merchandising solutions.

RPAS supports many alternative hierarchies that provide different roll ups and help analyze the data from a different perspective.

Measures

Measures represent the events or measurements that are recorded, while the positions in the dimensions provide a context for the measurement. Measures are defined based on the business rules set in the application. The dimensionality of a measure is configured through the definition of its base intersection, which is the collection of levels (one per appropriate dimension) defining the lowest level at which the information is stored for the measure.

Measure names are completely configurable and typically named using a convention that identifies each component and the meaning of the measure.

Domains and Workbooks

RPAS stores information in a persistent multidimensional data cache that is optimized for large volumes and dimensional or time series data access requirements, typically required by multidimensional solutions. This central repository is called a domain. The domain also includes central definitions of metadata for the solution and provides a single update point.

When you use an RPAS solution, you interact with the solution through a personal data repository called a workbook. A workbook contains the subset of the data (and metadata) from the domain and its scope is constrained by the access rights available to a user. Workbooks are stored on the RPAS server, and can be built using an online wizard process or scheduled to be built in a batch process automatically. Workbooks are made up of one or more worksheets. These worksheets display the hierarchy and measure data of the domain.

Although the data and metadata in the workbook are copied from the domain, the data remains independent of the domain.

Domains can be built in one of two methods:

  • Simple domain: This is the traditional, stand-alone domain that has no visibility to other domains.

  • Global domain: This is a domain environment that contains two or more local domains (or subdomains) and a master domain that has visibility to all local domains that are part of that environment.

A global domain is a type of domain structure that provides users with the ability to view data from multiple domains and to administer common activities of an RPAS domain and solution.

Using a global domain environment has two primary functional benefits. The first feature allows users to have a global view of data in workbooks. Users can build workbooks with data from local domains, refresh global workbook data from local domains, save global workbooks, and commit the data from global workbooks to the individual local domains.

Local domains are typically organized, or partitioned, along organizational structures that reflect user roles and responsibilities. Most users only work within the local domains that contain their area of responsibilities, and they may not need to be aware of the global domain environment. For performance and user contention reasons, global domain usage should be limited to relatively infrequent processes that require data from multiple local domains.

The other primary feature of global domain is centralized configuration and administration. Most of the mechanisms that are required to build and administer a domain have been centralized and they need only be run in the master domain, which either propagates data to the local domains or stores the data centrally so that the local domains reference it in the master domain.


Note:

For a global domain environment to function properly, all local domains must be structurally identical.

Measure Data

In a global domain environment, measure data can be physically stored in two different ways:

  • Across the local domains

  • In the master domain

Measure data that is stored in local domains is split across domains based on a pre-determined level of a given hierarchy. This level is defined during the configuration process, and it is referred to as the partition level.

The base intersection of a measure (for instance, what dimensions a measure contains) determines whether data is stored in the local domains or in the master domain. The data is stored in the master domain if the base intersection of a measure is above the partition level or if it does not contain the hierarchy on which the global domain environment is partitioned. This type of measure is referred to as a global domain measure or a higher base intersection measure.

Consider a global domain environment where the partition-level is based on the Department dimension in the Product hierarchy. Data for measures that have a base intersection in the Product hierarchy at or below Department are stored in the local domain based on the Department to which the underlying position in the Product hierarchy belongs. Other hierarchies are irrelevant for this discussion.

However, measures that have a higher base intersection in the Product hierarchy than Department (for instance, Division) or measures that do not contain the Product hierarchy (such as a measure based at Store-Week) cannot be split across the local domains. These measures will reside in the master domain and will be accessed from there when these measures are required in workbooks.

All measures are registered in the master domain, and they are automatically registered in all local domains. RPAS automatically determines where the measure needs to be stored by comparing the base intersection of the measure against the designated partition-level of the global domain environment. The physical locations of the measure data are invisible to the user after the measure has been registered.

Administrative Workbooks and Wizards

Using the administration workbooks, designated employees manage other employees' use of the Oracle Retail Predictive Solutions. System administrators use the administration workbooks to perform the following:

  • Set up and maintain users and user groups.

  • Manage user access to specific workbook templates and individual measures.

  • Edit the contents of translation tables to support multiple-language use of the application.

  • Specify the type, frequency, and format of workbooks in the automatic build queue.


Note:

If a solution is built in a global domain environment, most administrative activities can only be performed in the master domain. This applies to RPAS administrative workbook templates and wizards as well as RPAS utilities that are run on the backend against the domain. See each workbook or workbook wizard section in this guide for details about the domain access.

Hybrid Storage Architecture

This document contains an overview of the RPAS Hybrid Storage Architecture (HSA). The target audience includes business executives, planners, integrators, and pre-sales consultants with exposure to Retail Predictive Application Server (RPAS).

Numerous corporations adopt Oracle database for enterprise data storage and often leverage it as the system of record in integrated environments. By contrast, RPAS applications store data in a so-called domain that is a proprietary multi-dimensional database. One natural question is why RPAS does not use Oracle database.

The answer is simple. While Oracle database is a feature-rich enterprise data storage solution, it does not provide the agile and high-performing procedures for some of the access/insert patterns needed for multi-dimensional data processing. By contrast, the RPAS multi-dimensional persistence layer is optimized for fast data access and random write patterns used during multi-dimensional data processing. RPAS operations such as workbook commit and batch calculations would not perform if the entire multi-dimensional data set was to be stored in Oracle database.

A Note about RPAS Configurability and Extensibility

RPAS is a configurable and extensible platform providing a significant amount of flexibility in design and implementation. Lack of specific verbiage around a platform component does not guarantee a commitment to support its use in a non-documented way. In case of any ambiguity in the documentation, the customer is expected to ask for clarification with Oracle Customer Support.