| Oracle® Retail Predictive Application Server and Applications Cloud Edition Security Guide Release 19.0 F25911-13 |
|
 Previous |
 Next |
| Oracle® Retail Predictive Application Server and Applications Cloud Edition Security Guide Release 19.0 F25911-13 |
|
Previous |
Next |
This chapter covers integrating information across multiple RPASCE domains.
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. RPASCE supports only file-based integration. These files are provided to and retrieved from the system through the use of an SFTP server that is part of the provisioned environment.
The RPASCE platform supports the bulk creation of user accounts as a part of the domain build process. This bulk creation is accomplished by supplying a users.xml document with the other configuration inputs provided for the domain build.The information contained within the supplied file is used to create a set of users and user groups within the RPASCE domain as a convenience; subsequent user maintenance is performed using the administrative user management templates. Note that user accounts created in this fashion will not have access to the system until they are provisioned within the OID. See the individual application Administrative Guides for information on creating and maintaining users in the OID.
The RPASCE platform stores data within an embedded BTree database located within the domain on the file system. As such, it is necessary to manage the integration of the data within an RPASCE domain with other domains or with outside systems through a set of data import and export operations.
The primary operations used for this are the loadhier and loadmeasure utilities for importing data and the exportHier and exportmeasure utilities for exporting data. These operations can be performed either directly through scheduling a task in the Online Administration Tool interface or indirectly through the RPASCE batch framework.
The RPASCE platform supports the importing of data from and exporting of data to text files. These files provide an efficient method of moving large amounts of data into or out of an RPASCE domain. Based on configuration options for these tasks, the input and output files will be transferred via the SFTP server (for integration with non-cloud applications) or via an internal (single-tenant) file holding area for integration between multiple Oracle Cloud applications.
Details on secure access to the SFTP server, including instructions for setting up SSH keys, may be found in the Nightly Batch File Uploads section of each cloud application's Administration Guide.
RPASCE includes an optional component known as Planning Data Store (PDS). RPASCE PDS allows a configurable subset of RPASCE data and metadata to be stored in an Oracle Database for the purposes of multi-application integration and reporting.
RPASCE PDS enforces a least privileges model of database access control. The PDS installation process will create, in its standard configuration, ten Oracle schemas. Only one of these schemas, the Data Mart schema, will own persistent data tables. The remaining schemas have defined access rights, as required by particular RPASCE Server processes. Oracle DB login details for these schemas are stored in an Oracle Wallet, created and managed internally to the RPASCE Cloud Service. Figure 6-0 shows all schemas and the corresponding role and connection alias for each.
Table 6-1 Schemas
| Schema Name | Role | DB Connection Alias |
|---|---|---|
|
rpas_data_mart |
N/A |
rpas_data_mart_conn |
|
rpas_patch_user |
rpas_patch_role |
rpas_patch_conn |
|
rpas_batch_user |
rpas_batch_role |
rpas_batch_conn |
|
rpas_dimload_user |
rpas_dimload_role |
rpas_dimload_conn |
|
rpas_factload_user |
rpas_factload_role |
rpas_factload_conn |
|
rpas_hiermgr_user |
rpas_hiermgr_role |
rpas_hiermgr_conn |
|
rpas_wkbk_user |
rpas_wkbk_role |
rpas_wkbk_conn |
|
rpas_etl_user |
rpas_etl_role |
rpas_etl_conn |
|
rpas_bdi_user |
rpas_bdi_role |
rpas_bdi_conn |
|
rpas_rdonly_user |
rpas_rdonly_role |
rpas_rdonly_conn |
The RPASCE PDS installer creates the required schemas and set their permissions.
The RPAS PDS build process (a set of binary utilities and shell scripts) creates all schema objects and load metadata.
The rpas_bdi_user schema is open to Oracle Bulk Data Integration (BDI). The BDI installation process takes username and password of rpas_bdi_schema, and creates a separate Wallet for its own internal use.
The rpas_rdonly_user schema is created for Oracle RESTful Data Service (ORDS) web services. The web services are read-only, so the rpas_rdonly_user schema has read only access to PDS.
Customers can make use of Oracle ReSTful Data Services (ORDS) to invoke web services that supply the data stored with in the Planning Data Store. 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 Store allows only for reading data; there is no capability for modification of the data contained within the Planning Data Store. 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 Store through ORDS, the account representing the external process must exist within the IDCS or 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.
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 IDCS or 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.
