3 Retail Predictive Application Server Cloud Edition Security Features
Overview
The Oracle Retail Predictive Application Server Cloud Edition (RPASCE) is a platform that provides a set of common components used by a number of applications (solutions). For these solutions, RPASCE provides the infrastructure needed to store, process, and produce information based on data input by the retailer.
This guide discusses security considerations pertaining to the end user maintenance of an RPASCE Server application and the users of an RPASCE application.
Terminology
The following section provides a brief introduction to RPASCE and its terminology.
RPASCE Concepts
This section describes RPASCE concepts.
-
RPASCE: A platform that provides a foundation to run solutions used for retail planning. RPASCE provides those solutions with a common interface based on wizards, templates, workbooks, and batch processes.
-
RPASCE Solution: An application running on top of RPASCE that provides solutions for retail activities such financial planning or forecasting demand.
-
Planning Data Schema: The Planning Data Schema (PDS) is a schema created within the Oracle Database containing the tables that contain application metadata, a customer's planning data, and the procedures used to access and manipulate that data. The majority of user interactions with customer information are performed in workspaces; however, data load and other offline batch activities operate directly on the PDS.
-
Workspaces: Users perform application tasks inside workspaces. A workspace is a sandbox built by pulling data from the PDS; it supports the operations a user requires to perform a given task within the application. Once a task is complete, the changes made within the workspace sandbox can be applied to update the information contained within the PDS.
Secure Deployment
Secure deployment refers to the security of the infrastructure used to deploy the SaaS application. Key issues in secure deployment include Physical Safeguards, Network Security, Infrastructure Security, and Data Security.
RPASCE applications are deployed via Oracle Cloud Infrastructure datacenters. Access to Oracle Cloud data centers requires special authorization that is monitored and audited. The premises are monitored by CCTV, with entrances protected by physical barriers and security guards. Governance controls are in place to minimize the resources that are able to access systems. Physical security safeguards are further detailed in Oracle's Cloud Hosting and Delivery Policies.
http://www.oracle.com/us/corporate/contracts/ocloud-hosting-delivery-policies-3089853.pdfThe above referenced document also contains information about practices concerning Network, Infrastructure, and Data Security for applications deployed in the Oracle Cloud Infrastructure datacenters.
General Security Principles
The following principles are fundamental to using any application securely.
Keep Software Up to Date
One of the principles of good security practice is to keep all software versions and patches up to date. Since all interactions with RPASCE applications occur through a web browser (either through the RPASCE Client or through the Object Store web interface), these must be maintained at their latest release level to ensure the security of customer information.
Follow the Principle of Least Privilege
The principle of least privilege states that users must be given the lowest privilege level required to perform their jobs. Overly ambitious granting of responsibilities, roles, grants, and so on, especially early on in an organization's life cycle when people are few and work must be done quickly, often leaves a system wide open for abuse. User privileges must be reviewed periodically to determine relevance to current job responsibilities.
Monitor System Activity
System security stands on three legs: good security protocols, proper system configuration, and system monitoring. Auditing and reviewing audit records address this third requirement. Each component within a system has some degree of monitoring capability. Follow the audit advice in this document and regularly monitor audit records.
Client Tier Security
This chapter discusses security for the RPASCE Client.
Factors Affecting Security
The factors affecting security within the RPASCE Client are Authentication and Authorization.
Authentication
It is a requirement that user names and passwords for RPASCE users must be created in an Oracle Cloud Infrastructure Identity and Access Management (OCI IAM) instance. RPASCE Client uses perimeter authentication. The Oracle software product, Web Tier Security Service (WTSS), is used to field all HTTP requests. WTSS redirects the browser to an OCI IAM login page if a request lacks the OCI IAM session cookie.
Users authenticated by OCI IAM and assigned the authentication role for the RPASCE application will be granted access to the RPASCE application with a set of application permissions based upon the application roles granted them in OCI IAM
Users can be added through the OCI IAM Admin Console and can be added in bulk using a CSV file. For more information on
using OCI IAM, see the Oracle Identity Cloud Service online help at https://docs.oracle.com/en-us/iaas/Content/Identity/home.htm.
User accounts will be automatically created in the RPASCE application when a new user logs in for the first time if an account does not exist. However, this is not recommended, as there are some administrative tasks required to fully set up a new user account, so those tasks should be performed before they login. For AIF and RI applications, users do not exist in those systems independently of OCI IAM, all authentication is managed through direct communications between OCI IAM and the application client and there are no administrative steps in AIF/RI to separately configure user access.
To address the additional steps in Planning applications, the Online Administrative Tools (OAT) contain tasks to facilitate the addition of new users after they have been created in OCI IAM but prior to their first time logging into the system. Information about these tasks can be found in the Oracle Retail Predictive Application Server Cloud Edition Administration Guide.
Authorization
Authorization refers to the selective provisioning of data and the functional access to different classes of users.
Authorization Within an RPASCE UI Application
Once a user has been granted both the application authentication role and the administrator role in IAM, that user can log into the system as an administrative user.
The administrative user can log in to the application and see the functional groups within the application. Various application features such as workbook templates can be assigned to these functional groups. (We call this RPASCE capability “Security Administration”). He or she can then log in to IAM Console and assign users to the like-named IAM groups.
This will allow users to access those application features that he or she has been authorized to access, based on the memberships of functional groups (indirectly through their membership of the like-named IAM groups), and the access control established in the Security Administration process.
For more information on users, user groups, and granting privileges, see Compute Tier Security.
Authorization for Retail Home Metric Tiles
For each RPASCE solution, there is a Retail Home configuration file. A tile contains several “tile states” (accessed from the small round buttons at the bottom of the tile. This file defines the metadata for the Retail Home metric tiles, including the assignment of OCI IAM groups to tile states.
The user will only see those tile states for which he or she has been authorized, by way of their IAM group memberships.
Password Policies
The customer administrator user can define password complexity and rotation rules. All application user maintenance is performed by Customer Administrators via OCI IAM.
The following guidelines are useful.
-
Automatic lock out occurs after a certain number of failed login attempts.
-
Password expiration may be enabled.
-
The password reuse time can be set.
Browser Security
Update the browser when new versions are released; they often include new security features.
Check the browser for built-in safety features.
Setting Policy For Unattended PC Sessions
Others may try to access an unattended workstation while the user is still logged into the system. Users must never leave their workstation unattended while logged into the system because it makes the system accessible to others. Organizations must set a corporate policy for handling unattended PC sessions. Users must use the password-locked screen savers feature on all PCs.
Compute Tier Security
This chapter contains information on security activities carried out in the Compute Tier.
User and Group Management
Users of RPASCE applications are created and managed within OCI IAM. RPASCE allows administrators to create user groups within the application that correspond to roles defined in OCI IAM. When a user logs into the RPASCE application, the application will check to see if that user belongs to any roles that correspond to a group defined in the application and assign the user the privileges granted to those groups.
User groups are typically assigned based on a common business role such as Planners in order to facilitate managing the authorization settings at the group level. However, users will also have certain roles that server non-business purposes, as described "Non-Business Roles".
When a user is added, either through the Synch Users task or when a user logs into the application for the first time, a position is created for the user in the metadata dimension User. Similarly, when a group is added, that group is assigned a position in the metadata dimension Group.
User Life Cycle
As users enter the OCI IAM system, they can be granted both the application authorization role and one or more of the business roles. Once granted appropriate roles, users will be able to access the RPASCE application with the corresponding access rights. However, some additional administrative setup is required for a user accessing the system for the first time.
Position security is not role-based and is not managed through OCI IAM. It is therefore necessary for an administrative user to set the position access rights for a new user in order for that user to be able to interact with data in the application. Additionally, new users will not have access to the Dashboard in the RPASCE client until a dashboard workbook has been prepared for them. When a new user first logs in, that user will receive a message from the application to contact their administrator to complete these setup processes.
During the lifetime of a user within the system, any changes to that user's responsibilities can be accommodated by updating the set of roles assigned to the user in OCI IAM. If the set of roles possessed by a user change, those changes will automatically result in a change to that user's access rights when that user next logs in that reflect the access rights of the new set of roles they possess.
When a user should no longer be granted access to the application, the application authorization role can be revoked in OCI IAM or, if appropriate, the user can be dropped from OCI IAM entirely. No subsequent login attempts by that user will succeed, and they will no longer have access to the application and its data.
When a user is removed from the system, the system may continue to hold resources created by and for that user in the form of workbooks, saved formatting, and so on. To allow these resources to be reclaimed, a pair of administrative utilities can be run. First, the Sync Users from OCI IAM utility will query OCI IAM for the set of users authorized for the application. Any users who are no longer authorized for the application because of role changes, or as a result of being removed from OCI IAM, will be flagged within the application as expired.
A second utility, Manage Users, can then be executed. This utility will drop all workbooks and reclaim all other resources associated with the expired users and will purge them from the system. The purpose of this two-step process is to safeguard against the loss of user information as a result of accident. Purging a user from the system and deleting all that user's work may result in a significant loss of time and effort. As such, it is recommended that the two utilities be scheduled to run separately in order to provide a chance for error remediation prior to the irrevocable deletion of user data.
Non-Business Roles
Two special roles are associated with an RPASCE application using Atomic User Management (AUM): the first is the authentication role and the second is the application administration role. These roles are do not relate to the business processes of the application, but are instead used to manage access to the application and determine which users have administrative privileges within the application.
The names for these roles are not fixed and will vary between RPASCE applications and between the different environments (production, stage, and so on) making up a customer instance. For new customers, the role names will be provided during the provisioning and deployment process. For existing customers migrating to AUM, they are created as a part of the migration process.
Application Authorization Role
In order for users authenticated by OCI IAM to be allowed access to the RPASCE application, they must belong to the application authorization role. Users who do not possess the authentication role will not be allowed access to the application, even if they possess one or more of the roles defined and granted rights in the application. In this way, a single set of business-related roles can be managed across multiple RPASCE application instances but access can still be limited for an application instance to a subset of all users. It can be useful, for example, to share user roles between a stage and a production environment but grant access to the stage environment to a subset of users.
Application Administrative Role
Under the AUM model, users are no longer granted administrative privileges through the setting of the admin flag within the user management templates. Instead, users possessing the administrative role for a given application instance will be granted admin rights for that application instance. These rights can then be managed by assigning a user the administrative role or revoking that role, with the changes taking effect automatically when the user next accesses the RPASCE application.
Deactivating User Accounts
User accounts can be marked as deactivated by the administrator in the OCI IAM console. This prevents the user from logging on with the RPASCE Client. The account remains locked until the administrator re-activates the user.
Roles Created in OCI IAM
A number of roles are created within OCI IAM as part of the provisioning process that are used to support the RPASCE Cloud subscriptions. Some of these roles are created to support user operations and must be assigned to users in the system. Other roles are created within OCI IAM to support the integration of the RPASCE systems with other systems and components within the Cloud environment. These roles are used by the internal processes of the system and, in general, do not need to be assigned to users of the system.
Information on the roles created for the various components of an Oracle Retail cloud subscription can be found in the Oracle Retail Identity Management for OCI IAM. Readers are encouraged to review not only the sections pertaining to the cloud services for which they have subscriptions but also the sections detailing role information for common components that are a part of every subscription, such as Retail Home, Process Orchestration and Monitoring, and Retail AI Foundation Cloud Service.
Authorization
This section deals with authorizing access. The workbook template security and position-level security are managed in the security administration workbook through various Workbook Template Rights and Position Security views. See the “Security Administration Workbook” section in the Oracle Retail Predictive Application Server Cloud Edition Administration Guide for more information.
Workbook Template Security
Workbook template access can be granted as Full Access or Read-Only. Full Access enables the user to build, open, modify, and commit the workbook. Read-Only access allows the user to open and view the workbook only. Workbook access is automatically granted to the user who builds a workbook, and the workbook can be shared by that user with other users in the system who are authorized to view that workbook and the data contained within it. The user who receives access to a shared workbook has the same access granted to the user on the workbook template. That is, Full Access users can modify and commit the shared workbook while Read-Only users can only view the workbook.
For guidance on assigning permissions to workbooks by role and group, see the Implementation Considerations chapter, section "Security," of each RPASCE Application's Implementation Guide. All recommendations in the guides are for the GA solution. If a customer chooses to customize permissions, keep in mind that the Principle of Least Privilege: only provide users with sufficient permissions to do their job and nothing more.
Note:
A user must have access to the workbook template in order to access the workbook, even if the workbook has world or group access rights.
A user’s workbook template access rights can be inherited from the user’s groups. If any group a user belongs to has Full Access to a workbook template, the user also has Full Access. If one or more of the user’s groups have Read-Only access and the others have no access, the user inherits the Read-Only access which is then combined with their own access rights to become the final access rights. That is, if the user themselves has no access rights, the heritance grants Read-Only rights. If the user themselves already has Read-Only or Full Access rights, the heritance has no effects.
By default, the group template rights inheritance is enabled. It can be turned on/off on a user-by-user basis through the “Manage Users” OAT task.
Users with administrator status automatically have access to all workbook templates. By default, administrators have access to all workbooks that are saved with world access. If a workbook is saved with group access, administrators can only access the workbook if they are members of the default user group of the user who saved the workbook.
Another aspect of workbook security is the ability to set limits for the number of workbooks that a user can have saved at any given time. Limits can be set for a user per template, for a user group per template, or for a template for all users. The limits are evaluated in the above order, which means that a limit defined at user-template overrides any values defined at group-template or template. If the above limits are not defined, the default value is one billion.
The limits are checked when the workbook build process is initiated. When the limit is reached, an error message displays informing the user that the workbook build process cannot complete because the limit has been reached. The message also lets the user know what that limit is. The wizard process then terminates.
Administrative users have full access to all workbook templates, regardless of the access rights that other administrative users may assign to them in the Security workbook. The administrative user can build the Security workbook to change the access right back, so the nominal assignment does not matter for administrative users.
Non-administrative users do not have access to the Security template and User Administration template groups even if the administrator inadvertently assigns them access rights.
Position Level Security
Position Level Security allows access control for dimensions on a position-by-position basis. This capability is completely optional. If position level security is not explicitly defined and configured, all users in an application have access to all positions in all hierarchies. After the position level security is defined, access to a position can be granted or denied for individual users, users in a group, or for all users.
Position level security can be defined at levels at or above base (such as class in the product dimension) in any dimension other than calendar. As positions are added at a level lower in the dimension than where the position level security is maintained, access to those positions is automatically granted if a user has access to the parent position.
For example, if security is maintained at the subclass level, users are automatically granted access to all the SKUs in a given subclass if they have access to that subclass. This includes those that were added after security was established.
Exactly one level in each dimension can be defined as the security level for the dimension. If a security level is defined for the dimension, all levels in the dimension have position level security enabled, but position security is set at or above the designated level. For example, if the class level is designated as the security level, an administrator can maintain access to positions in the class level or at any level above class.
To specify the security level for a dimension, the application designer must update the configuration and either rebuild or patch the application. After a security level is defined for a dimension, all users in the application default to having access to all positions in any level in the dimension. Additionally, users automatically have access to newly added positions. Views in the Security Administration workbook are used to control position access for individual users, user groups, or all users (referred to as world or default access). Three views are provided in this workbook for each dimension with a defined security level. The default view controls access to positions for all users (for instance, Prod Security Default); one view controls access to positions by user group (for instance, Prod Security Group); and the last view controls access to positions by individual users (for instance, Prod Security User).
Access must be granted at all levels for a user to have access to a position. This means that a position must have a value of true at the levels default/world, group, and user. The table below demonstrates how access is granted or denied based on all combinations of settings.
In the table, security is set by Position. Denied = False and Granted = True. Based on the settings for User, User Group, and World, the user is either granted or denied access, as shown in the Resulting Access column.
Note:
A user can belong to multiple user groups (primary and other groups of the user), The user is granted access on the user group level as long as one of their groups is granted.Table 3-1 Granting Access
| User | User Group | World | Resulting Access |
|---|---|---|---|
|
Denied |
Denied |
Denied |
Denied |
|
Denied |
Denied |
Granted |
Denied |
|
Denied |
Granted |
Denied |
Denied |
|
Granted |
Denied |
Denied |
Denied |
|
Denied |
Granted |
Granted |
Denied |
|
Granted |
Denied |
Granted |
Denied |
|
Granted |
Granted |
Denied |
Denied |
|
Granted |
Granted |
Granted |
Granted |
Position-level security is used when a user selects positions in the wizard process before building a workbook. Only positions to which a user has access are available for selection in the 2-tree, which are then included in the build of the workbook.
Setting Proper Resource Limits
This section specifies how to set resource limits. The views described in the subsections below - WorkbookTemplate Limits, Max Domain Session Limit, Max User Session Limit and Dimension Modification Rights are the views present in the security administration workbook. These resource limits can also be viewed in the PDS Explorer. See the “Security Administration Workbook” and “PDS Explorer” sections in the Oracle Retail Predictive Application Server Cloud Edition Administration Guide for more information.
WorkbookTemplate Limit Views
The Workbook Template Limit views are used to limit the number of workbooks that the user can have saved. Limits can be set for a user per template, for a user group per template, or for a template for all users. The limits are evaluated in the above order, which means a limit defined in a user-template overrides any values defined at group-template or template. If the above limits are not defined, the default value is one billion, but it is not displayed in the workbook.
The limits are checked when the user begins the workbook build process. If the limit has been reached, an error message appears that informs the user that the workbook build process cannot completed because the limit has been reached. The wizard process then terminates.
Max Domain Session Limit View
The Max Domain Session Limit view is used to limit the number of user sessions that can be attached to a single application by all users of that application. The limit is set at the application level. This limit is checked during user login. If the limit has been reached, an error message appears to inform the user that the login has failed because this limit has been reached.
Max User Session Limit View
The Max User Session Limit view is used to limit the number of concurrent user sessions that can be attached to a single application by the same user at the same time. The limit is set per user so that the administrator can control the maximum number of concurrent sessions that are allowed for an individual user.
This limit is checked during user login. If the limit has been reached, an error message appears to inform the user that the login has failed because this limit has been reached.
Dimension Modification Rights View
The Dimension Modification Rights view allows the administrator to determine which user-defined dimensions, if any, a user can modify. Its purpose is to provide a filtered list of user-defined dimensions to be shown on the dimension selection wizard page of the Hierarchy Maintenance template. The view contains a check box for each available user and dimension combination. A check mark in the cell indicates that the user is permitted to modify the specified dimension.
Managing Sensitive Data
While RPASCE can be configured to store any type of data, it is designed to be used with sales history, inventory, and other business-related information with low security requirements. It is not intended to be used with any sensitive data, such as personally identifiable information or credit card information. It does not have any mechanisms to protect this data, such as encryption, and therefore must not be used in this manner.
Online Administration Tools
In order to be able to run and schedule administrative tasks in a cloud environment where the administrator has no access to the back-end servers, RPASCE Online Administration Tools provide an interface that allows authorized users to launch back-end processes from the RPASCE UI. It also provides a dashboard-like interface for the administrator to monitor the status of the tasks whose requests have been submitted.
Planning Data Schema Security
This chapter of the security guide covers Planning Data Schema (PDS) creation and maintenance.
Configuration Management
The process of RPASCE application configuration can be performed by an RPASCE 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 RPASCE application is performed using a stand-alone Java application known as the RPASCE Configuration Tools.
The RPASCE Configuration Tools work with an XML representation of the content of an application known as the application configuration. Using the Configuration Tools, an application configuration can be inspected and modified. The configuration is then used as an input to the application deployment process, which creates and modifies RPASCE PDS.
Because the RPASCE 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 RPASCE PDS 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 application and the processes used to maintain and modify that application data. As such, it is prudent to secure the representation of the application 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 RPASCE PDS 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
Because the RPASCE Configuration Tools do not interact directly with the RPASCE PDS, they cannot be used to inspect or modify PDS information. However, because the configuration describes the information in the PDS 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
Once uploaded to the OCI environment, the configuration is protected by the same safeguards present to secure all application resources residing within the host environment. No additional protections are required.
Securing the Transfer of Configurations
Configuration is performed on one or more users' individual systems. In order to build or update an RPASCE PDS with that configuration, it is necessary to transfer the configuration to the system upon which the PDS will be deployed. This transfer is accomplished using the Oracle Cloud Infrastructure Object Storage service. OCI Object Storage provides a reliable and secure method of moving information into and out of RPASCE application instances.
Information on use of OCI Object Storage in conjunction with RPASCE applications can be found in the Oracle Retail Predictive Application Cloud Service Implementation Guide. Information on OCI Object Storage itself, including information on security best practices, can be found here:
https://docs.oracle.com/en-us/iaas/Content/Object/Concepts/objectstorageoverview.htm
Dynamic Position Maintenance
The creation of positions within the dimensions of an RPASCE application is a process that is performed by loading the position information from flat files or through the integration of an RPASCE application with other Oracle Retail applications. However, the business processes performed by some RPASCE 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 positions within constraints based on application security settings and the workbook configuration and enforced by the RPASCE Server instance.
Users can also modify and or delete existing positions created through DPM operations within constraints based on application security settings and the workbook configuration and enforced by the RPASCE Server instance.
Users are not allowed to modify or delete positions which the application's security settings do not grant them access to; they may also not modify positions of levels and dimensions not allowed by the configuration of the workbook in which they are working. Finally, formal positions managed through data load or integration with other Oracle Retail applications 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 in the application.
-
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. Any users granted WRITE permission to the workbook template can create DPM positions.
When a user creates DPM positions, they are treated as temporary positions; flat file operations and integration with other Oracle Retail applications do not update these positions. Online Administration Tools (OAT) contains a Manage Informal Positions task that can be used for maintaining the informal positions of any levels in the application. This task can convert positions from formal to informal or from informal to formal. It can also remove informal positions, create informal positions in bulk, and copy data slices between positions in measures.
RPASCE Maintenance
PDS maintenance is a periodic operation that must be performed by the administrator. 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 PDS when that data is no longer needed by the operations being performed by the PDS. 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 PDS maintenance tasks that can be performed periodically are:
Purging Unused and Inactive Hierarchy Positions
All measure data within the PDS is stored in either scalar or dimensional measures. As positions are introduced to the hierarchies of the PDS, these positions become available for the storage of measure data. When a position is no longer required by the PDS, it can be purged. This hierarchy purging will result in the measure data associated with the retired positions being cleaned from the PDS.
The purging process is performed via the Load Dimension Data OAT task, which has a purgeAge option that can be used for purging unused hierarchy positions.
Clean Up Old Workbooks
It is possible to list all the workbooks in the application and determine which ones are old. "Managing Workbooks Using wbmgr", found in the Oracle Retail Predictive Application Server Administration Guide, describes using the option Manage Workspaces to list all the workbooks in the application. From this output, all the old and obsolete workbooks can be found. These old workbooks can be removed using the same Managing Workbooks task. Removing only the workbook and keeping the associated segment can help to rebuild the workbook later using the same selections if required. Segments without their workbooks do not require much space. Alternately, the entire segment can be removed using the Managing Segments task.
Clean Up Old Administration Tasks
The tasks in the OAT dashboard grow over time and take up valuable system resources. It is recommended that an Admin user periodically purge unused admin tasks. The task to perform the purge operation is described in "Purge Tasks from Task Status Dashboard Task", found in the Oracle Retail Predictive Application Server Administration Guide.
Performance Diagnostic Tool
The performance diagnostic tool contains valuable options to analyze system resources. See "Analyzing Workbook Performance", found in the Oracle Retail Predictive Application Server Administration Guide, regarding how to efficiently find workbooks that can be cleaned up.
RPASCE Integration
This chapter covers integrating information across multiple RPASCE applications.
Data and Metadata Integration
The client/server interactions of RPASCE define how users may access the system but are not effective for larger scale modification of the data of the system. To allow for these operations, RPASCE supports bulk data load and export operations. Even though RPASCE supports file-based integration, we recommend that the customer load data through importer. These files are provided to and retrieved from the system through the use of an Object Storage Cloud Service server that is part of the provisioned environment.
Integrating User Information
RPASCE applications rely on OCI IAM for user authentication and authorization. Users are created, deleted, and assigned roles within OCI IAM. Those users who have been granted the authentication role for an RPASCE application are given access to the application with the set of application privileges granted by the user roles that user has been granted in OCI IAM. Additionally, users granted the administrator role in OCI IAM are also allowed access to the administrative functions of the RPASCE application and granted super user rights that supersede the rights of the application roles they may have.
As a result, the integration of user information between multiple RPASCE applications or between an RPASCE application and another Oracle Retail application is entirely a matter of role membership within OCI IAM. Users granted the authorization role for multiple RPASCE applications will have access to those applications, with application privileges determined by the application roles for those applications.
Object Store
RPASCE uses object storage for interacting with incoming and outgoing files in the cloud. Object storage is available from
Oracle for cloud customers and is documented at the link below.https://docs.oracle.com/en-us/iaas/Content/Object/Concepts/objectstorageoverview.htm
Interface Configuration File
Data from all pre-defined planning interfaces to external systems such as RMFCS (Oracle Retail Merchandising Foundation
Cloud Service) or internal systems like Retail Insight/Science is pulled through importers from RAP Data Exchange (RDX) schema.
Any data that is going from Planning to external systems can also be exported through importers from the RDX schema. Though
interface tables in the RDX schema will not change quite often, as defined by the interface contracts between respective applications,
the planning/forecast application that is implemented on PDS supports extensibility and enterprise edition (EE) configuration.
Therefore, importers and exporters must be configurable, since dimensions and fact names can be different for different customers.
To provide for the configurability of importers and exports, the interface.cfg file (interface configuration
file) is used. It is a free-form text file similar to the batch control file, and contains the mapping of dimension/facts
in PDS to columns mapped to external tables for each interface.
Both importers and exporters are commonly referred as interfaces within PDS; each interface has a unique interface ID.
Interfaces are classified as one of three types: dimension importers, data importers, or data exporters. Customer can create
or modify entries only for the available list of interfaces. They can configure the interface to match and pull the required
dimension/fact data per the dimension/fact names configured with in their application when those interfaces are executed in
batch. For general availability applications, the pre-configured interface.cfg file is readily available,
and customer can customize the file for any required extensibility changes, similar to an EE customer.
For more information about uploading the custom interface.cfg file, see the Load Interface Mappings task
in the Oracle Retail Predictive Application Cloud Edition Administration Guide.
Use of ORDS in Conjunction with the Planning Data Schema
Customers can make use of Oracle ReSTful Data Services (ORDS) to invoke web services that supply the data stored in the Planning Data Schema. Several standard web service endpoints are provided, and it is possible to create additional endpoints to supplement those provided.
The access provided to ORDS by the Planning Data Schema allows only for reading data; there is no capability for modification of the data contained within the Planning Data Schema. The endpoints provided are intended for use by external systems that connect to ORDS through the use of system accounts.
In order to connect to the Planning Data Schema through ORDS, the account representing the external process must exist within the OCI IAM instance associated with the application. Additionally, that account must belong to the group RPAS_ORDS_GROUP. All unauthenticated access requests and any requests made by a user who is not a member of the RPAS_ORDS_GROUP will be denied.
Creation of Additional Service Endpoints
In order to create additional service endpoints, it is necessary for a user to gain limited administrative access to ORDS. First, the user must exist within the OCI IAM instance and belong to the RPAS_ORDS_GROUP role. Second, a service request must be created to give that user access to the ORDS administrative UI.
Once access is granted, authorized users will be able to access parts of the ORDS administrative UI that allow the creation and registration of endpoints. However, they will not have access to other administrative functions (such as security policy management) of the ORDS instance.