1 Feature Summary

The following enhancements are included in this release.

Column Definitions

  • Feature: Provides a description of the feature being delivered.

  • Delivered: Identifies whether the feature is Enabled or Disabled upon initial delivery.

  • Scale: Identifies the size of the feature. Options are:

    • Small: These UI or Process-based features are typically comprised of minor field, validation, or program changes. Therefore, the potential impact to users is minimal.

    • Large: These UI or process-based features have more complex designs. Therefore, the potential impact to users is higher.

  • Customer Action Required: You must take action before these features can be used. these features are delivered disabled and you choose if and when to enable them.
Feature Delivered Scale Customer Action Required?

Technical Architecture Enhancements

Enabled

Small

No

Updated Solution URLs

Enabled

Small

No

Merchandising File Transfer Services

Disabled

Small

Yes

New Foundation, Inventory, and Pricing Services

Disabled

Small

Yes

OAuth for REST Service Authentication

Disabled

Small

Yes

Initial Data Seeding for SIOCS

Enabled

Small

No

Technical Architecture Enhancements

With this release, all of Oracle’s Merchandising cloud services are moving to Oracle’s Next Generation SaaS Architecture. This is a cloud-native, container-based architecture that is more secure, highly scalable, and allows for better up-time and availability.  This is accomplished by leveraging a Kubernetes cluster management back end, connected to an automated Oracle database service.  This new architecture will yield the following benefits:

  • Significantly reduced downtime due to fully automated deployment pipelines for all updates and patches

  • Full adoption of OAuth 2.0 for all ReST services

  • Significant improvements in middle-tier and application-tier scalability

  • Higher overall throughput due to leveraging all customer hardware (including disaster recovery) for day-to-day activities, resulting in no wasted environments

  • Adoption of proactive monitoring and alerting via industry standard tools such as Prometheus, Grafana, and ELK

Updated Solution URLs

With this release, the Merchandising cloud services will be deployed in a new data center. As such, the URLs used to access the services and some of the associated tools will change. The basic structure of the URLs is as follows:

https://<$service>.retail.<$region>.ocs.oraclecloud.com<$customer_subnamespace>/<$application_context_root>

The components that vary by customer are the region and customer sub-namespace portions. Region will be based on the data center where your environment are located and the sub-namespace portion will contain an acronym for your company name along with type of environment (for example, prd, stg, and so on).

Below are the common portions of the updated URLs are shown below.

Solution/Tool URL

Pricing

https://rex.retail.<Region Name>.ocs.oraclecloud.com/<Customer Subnamespace>/Rpm/faces/Home

Pricing REST Services

https://rex.retail.<Region Name>.ocs.oraclecloud.com/<Customer Subnamespace>/PricingServices/

Merchandising File Transfer Services

File Transfer Services (FTS) used by all of the Merchandising cloud services are being exposed in this release, replacing SFTP. The services are used by all of the Merchandising cloud services, including the Data Conversion tool. They will allow you to manage uploading and downloading files to Oracle Cloud Infrastructure Object Storage, which is an internet-scale, high-performance storage platform that offers reliable and cost-efficient data durability. For each customer environment, buckets, which are logical containers for storing objects, will be created in Object Storage. Any type of data, regardless of content type, is stored as an object. An object is composed of the object itself and metadata about the object.

Access to the buckets is through a pre-authenticated request (PAR), which is a URL that requires no further authentication to use to upload or download files to the bucket. To retrieve a PAR, you must use the appropriate file transfer REST service. These new services will enable you to import files to and export files from Object Storage used by the solutions. The primary role of these services is to ensure that only valid external users can call the service by enforcing authorization policies. Listing and deletion of incoming, outgoing and reject files are also supported.

Note:

These services will support files of up to 512MB. Where supported, the files can be zipped. Any larger files will need to be broken into multiple files before sending through these services.

For more details see the Oracle Retail Merchandising Foundation Cloud Service Release Readiness Guide.

New Foundation, Inventory, and Pricing Services

This release introduces new services that will be used to integrate foundation, item, and pricing information from the Merchandising and Pricing solutions to the following Oracle Retail cloud services:

  • Oracle Retail Customer Engagement CS (version 20.1 and later only)

  • Oracle Retail Order Broker CS (version 20.0 and later only)

Services used by ORCE Services used by OROB
  • Organizational Hierarchy

  • Stores

  • Merchandise Hierarchy

  • Items

  • Item Images

  • Stores

  • Warehouses

  • Items

  • Store Inventory

  • Warehouse Inventory

These services replace the previous method of integration, which leverages the Oracle Retail Integration CS (RICS) component referred to as omni-channel data service (OCDS). Existing services via RICS will remain to support integrations with older versions of these solutions, as well as for backward compatibility for 3rd party solutions. Additional services were also added as part of this release that are not leveraged by ORCE nor OROB; these services will be used in the future to support integration with other Oracle Retail solutions and are included in this release for integration with 3rd party solutions, if desired.

These new services use new system options to determine which Oracle Retail solutions are being used in your implementation and are backed by a new set of tables that hold the integration data in json format for the supported entities. If using these services in support of a third party equivalent of the Oracle Retail solutions supported by this functionality, you can set the system option for that Oracle Retail solution to checked (Y). For example, if implementing with a third party CRM solution, you could set the ORCE system option to checked to leverage the above listed integration points.

The service call queries the json message from the new tables to serve the consumers. These new tables require initial seeding from the base tables and continuous maintenance to keep them updated for changes in the base tables. The initial data loading and continuous maintenance is carried out by new batch jobs. 

  • Bulk Data Processing: This process is used for bulk maintenance of the json cache table. The bulk data batch processing is generally applicable during to do the initial loading of the json cache table or if an enhancement to the service requires a refresh of existing cache. This process also supports purging the json cache tables in scenarios where there are no active consumers for a service. 

  • Delta Processing: Delta processing is used to populate/merge the delta changes that were made to the base Merchandising and Pricing tables into the respective json cache tables based on interface change log table entries. The delta processing job for each API has to be scheduled to run at regular frequency throughout the day to scan the change log tables for changes and build the json messages to keep the delta update ready for the consuming system.

Note:

The Pricing services item/price and item/promotion do not use the Bulk Data Processing batches. They are only delta services.

Lastly, a new code type and codes were added to hold organizational hierarchy level names that are used by these integrations. These code descriptions should not be updated with dynamic hierarchy names if changed in Merchandising and should not be set to Used = No.

Note:

See the Oracle Retail Merchandising Foundation Cloud Service Release Readiness Guide for the steps to enable and more details on the services.

OAuth for REST Service Authentication

OAuth 2.0 is industry standard protocol for authorization. Merchandising cloud services REST Services now supports OAuth 2.0. In order to invoke these services you will need to obtain access token and use it as a bearer token.

Note:

Basic Authentication access will not longer be supported for these services. Allocation CS services still use Basic Authentication with this release.

Steps to Enable

In order to obtain a token and call the services, use the following steps:
  1. Get an access token using OAuth client id and secret from IDCS.

    1. export ACCESS_TOKEN="$(curl -u <Client ID>:<Secret> -H 'Content-Type: application/x-www-form-urlencoded;charset=UTF-8' --request POST https://<IDCS_BASE_URL>/oauth2/v1/token -d 'grant_type=client_credentials&scope=<Customer Environment Specific Scope>' | jq -r '.access_token')"

    2. The token is generally valid for 1 hour.

  2. REST clients that need to call Merchandising REST service end points should use the client id and secret of the OAuth client generated in the previous step to get access token.

OAuth tokens can also be obtained by REST client tools like Postman for testing purposes by filling in the necessary details like client id/secret and scope. Use the below information in such cases:

  • Authorization: OAuth 2.0

  • Access Token URL: https://<IDCS_BASE_URL>/oauth2/v1/token

  • Client ID: <Client id of OAuth client app>

  • Client Secret: <Client secret of OAuth client app>

  • Scope: <Custom environment specific scope>

curl --location --request GET 'http://<hostname or IP address>:<port number>/RmsReSTServices/services/private/Common/vDate' \        --header 'Authorization: Bearer $ACCESS_TOKEN'

Initial Data Seeding for SIOCS

This release brings in a change in how initial data seeding and periodic on-demand refresh by store is performed in Store Inventory Operations Cloud Service (SIOCS) when implemented with Merchandising. Prior to this release, bulk data integration (BDI) was used for initial seeding and periodic on-demand refresh by store. Going forward, Merchandising and Pricing will expose data views which will be used by SIOCS to pull data for initial seeding and periodic on-demand refresh by stores. The existing BDI proceses will remain in Merchandising for backward compatibility for a period of time after initial release before being retired.

See SIOCS documentation for more details on this process.