| Oracle® Retail Predictive Application Server and Applications Cloud Edition Security Guide Release 23.1.201.0 F80663-01 |
|
 Previous |
| Oracle® Retail Predictive Application Server and Applications Cloud Edition Security Guide Release 23.1.201.0 F80663-01 |
|
Previous |
This chapter covers integrating information across multiple RPASCE applications.
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.
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.
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
Data from all pre-defined planning interfaces to external systems such as RMF CS (Oracle Retail Merchandising Foundation Cloud Service) or internal systems like Retail Insight/Science is pulled via importers from RDX schema. Any data that is going from Planning to external systems can also be exported via exporters to 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 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.
Customers can make use of Oracle ReSTful Data Services (ORDS) to invoke web services that supply the data stored with 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.
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.
