| Oracle® Retail Integration Cloud Service Integration Overview Guide Release 21.0.000 F41458-01 |
|
 Previous |
 Next |
| Oracle® Retail Integration Cloud Service Integration Overview Guide Release 21.0.000 F41458-01 |
|
Previous |
Next |
The Retail Integration Bus (RIB) is a fire-and-forget, asynchronous messaging backbone and designed as a "Pub/Sub" JMS messaging architecture, with additional application functionality added such as intelligent transformation, routing and error handling.
The RIB acts as a shared communication layer for connecting various Oracle Retail applications and external applications throughout an asynchronous enterprise computing infrastructure. The RIB supplements the core asynchronous messaging backbone with additional application functionality such as intelligent transformation, routing and error handling.
Communication across the RIB is via xml messages (payloads). These payloads describe the retail business objects (such as items, purchase orders, suppliers, and so on) in a standard way and are governed by RIB on behalf of the Oracle Retail applications.
RIB architecture is based on standard Java EE components and the Java Message Service (JMS). JMS is an integral part of the Java EE (Java Enterprise Edition) Technology stack.
The RIB has been designed, and proven to handle retail volumes of messages, typically millions during a Tier 1 -Tier 1+ retailer's business day.
The design and architecture of the RIB infrastructure and the Oracle Retail Applications API's are based on two key requirements driven by the Oracle Retail Application's Business process models.
Preservation of Publication Sequence. The business event (message) must be delivered to all the subscribing applications in the order (FIFO) the business event (messages) was published by the publishing application.
Guaranteed Once-and-only-once Successful Delivery. The RIB must preserve and persist all business events (messages) until all applications (Subscribers) have looked at the message and have successfully consumed it or decided they do not care about that event (message).
The RIB is designed as an asynchronous publication and subscription messaging integration architecture. This allows the decoupling of applications and their systems. For example, a publishing application need not know about the subscribing applications, other than the requirement that at least one durable subscriber must exist. It decouples the application systems operationally. Once a subscriber is registered on the JMS, the RIB persists all published messages until all subscribers have seen them.
The publishing adapter does not know, or care, how many subscribers are waiting for the message, what types of adapters the subscribers are, what the subscribers' current states are (running or stopped), or where the subscribers are located. Delivering the message to all subscribing adapters is the responsibility of the RIB with the help of the underlying JMS server.
Physically, the message persisted so that it is available until all subscribers have processed it. The RIB uses the JMS specification for its messaging infrastructure. The JMS accepts the message from the publisher and saves it to stable storage, a JMS topic, until it is ready to be picked up by a subscriber. In all cases, message information must be kept on the JMS until all subscribers have read and processed it.
The RIB interfaces are organized by message family. Each message family contains information specific to a related set of operations on a business entity or related business entities. The publisher is responsible for publishing messages in response to actions performed on these business entities in the same sequence as they occur.
Each message family has specific message payloads based on agreed upon business elements between the Oracle Retail applications.
Third Party and Legacy Integration has been the corner stone of the Enterprise Integration components. To that end there are new cloud focused enhancements to RIB and BDI; RIB-EXT and BDI-EXT are among them.
A lot of effort has been put into continuing that focus into the Cloud by service enabling all of the RICS integration components. To do this, several new components have been added to the RICS suite of products.
RIBforEXT
RIBforEXT is a deployment time configurable component that supports pub/sub to/from the RIB and an external application by exposing the RIB as SOAP services to Retail Applications and third party deployed on-premises or in other cloud deployments.
RIBforEXT has all of the RIB flows available for the deployment time configuration based on the customer use cases.
RIBforEXT configuration is performed based on the customers use cases for data to and from the RIB.
FILEIO
The FileIO app has been enhanced to fill a gap by exposing customer facing SOAP Web Service APIs to FileIO that publishes and subscribes flat files to RIB-EXT that then pub/subs to the RIB's JMS.
FileIO works in conjunction with the new RIB-EXT component. The RIB-EXT server side component exposes customer facing SOAP Web Service APIs.
FileIO publishes or subscribes using flat files to RIB-EXT that then pub/subs to the RIB's JMS.
The files are not moved by ftp. RICS transmits the data via web services.
Batch (Bulk) data is still a predominant integration style within Oracle Retail and its customers.
The movement of bulk data remains important because some work is best suited to being performed in bulk. Batch processing was there in the early days; it is still here today; and it will still be here tomorrow. What has changed is the approach to batch processing.
Batch processing is typified by bulk-oriented, non-interactive, background execution. Frequently long running, it may be data or computationally intensive, executed sequentially or in parallel, and may be initiated through various invocation models, including ad hoc, scheduled, and on-demand.
Batch applications have common requirements including logging, checkpoint, and parallelization. Batch workloads have common requirements such as operational control, which allow for initiation of, and interaction with, batch instances; such interactions include stop and restart.
BDI productizes the Oracle Retail bulk data flows for delivery to customers and provides the tooling that is required to automate the creation and packaging of the configurations and to manage the full life cycle.
The goal of BDI is to provide an infrastructure to support the movement of bulk data between Oracle Retail applications using an agreed upon standard for the shape of the data produced from an application and delivered to an application.
The agreed upon standard is the shape of the data in the interface table structure and the file format. The standard of truth for both is the same and is described in an XML file that is a governable artifact that is part of the ICB process.
The producer of the data agrees to deliver to the BDI infrastructure Interface Tables the data that is shaped accordingly. The consumers understand that the BDI infrastructure will deliver to the BDI infrastructure interface tables or files that are shaped accordingly.
The core responsibility is taking the data published by the sender application and delivering it to all of the receiving applications, regardless if they are deployed on-premise or cloud and to do it in scalable, parallel execution threads with built in failure recoverability and granular job processing.
The technology used by the sender application and the receiver application to extract and fill the interface tables and to upload the data from the interface tables is a decision made by each of the applications. There are templates and hooks provided to the application's teams to assist in development.
The BDI Infrastructure for each application is an application (BDIforApp) that is built and supplied by the integration team. There is one dedicated to each application and it is responsible for transforming the data to and from the BDI Transport to the integration interface tables or files that are transported to each of the configured receivers.
All BDI Infrastructure components are service enabled.
The Oracle Retail Financial Integration (RFI) for E-Business Suite (EBS) / PeopleSoft Financials / CFIN provides integration to a robust enterprise financial system to complement the Oracle Retail Merchandising system in a retail customer environment.
On-Premise Merchandising to On-Premise Financial Applications
RFI for PeopleSoft (On-premise)
RFI for EBS (On-premise)
Merchandise Foundation Cloud Service (MFCS) to Financial Applications
RFI for MFCS to On-Premise EBS
RFI for MFCS to Oracle Cloud Financials
This integration is not a point-to-point integration between the Financial System (EBS or PeopleSoft or ERP Cloud) and Oracle Retail applications. This RFI implementation is independent of the version of integrated applications. A Oracle Retail Financial
Integration (RFI) layer serves as an intermediate thin layer of application between Financial application (EBS or PeopleSoft or ERP Cloud) and Oracle Retail. This integration remains synchronized with the new releases of the edge applications.
Audited transaction data is exported to the Financial applications days before the traditional audit process permits. The Financials applications can use this timely data in a proactive manner, which results in increased productivity and operational efficiencies.
Total cost of ownership for Oracle and its customers is reduced.
Life Cycle Data Management - This process provides data synchronization for the initial load prior to implementation and incremental data creation and maintenance after implementation.
Inventory Valuation (Retail stock ledger) - This process enables the posting of accounting entries generated from transactions that change the value of sellable products at a retailer's inventory locations (stores and warehouses) to the appropriate ledgers from Oracle Retail Merchandising - stock ledger to Oracle General Ledger (Oracle GL).
Retail Revenue Recognition - This process enables posting of accounting entries generated from sales and returns transactions from the retailer's stores for revenue and cash reconciliation to the appropriate ledgers. In this process, the data flows from Oracle Retail Sales Audit (ReSA) to Oracle GL.
Retail Merchandising Procure to Pay - This process begins with the Oracle Retail Invoice Matching (ReIM) application. Invoices from suppliers for retail merchandise are matched to the original purchase order (PO) for the merchandise and the receipt of the merchandise by the retailer.
The Universal Service Mapper (USM) is an application component of Retail Integration Cloud Service (RICS) that allows the definition, mapping, and configurations needed to support the integration between two heterogeneous applications. Typically this would be an Oracle Retail Application such as RMS, found in the Merchandise Foundation Cloud Service, and an application external to Oracle Retail such as Oracle Warehouse Management CS.
RICS USM supports two of the styles of integration used within Oracle Retail; message-based and service-based as inputs. Within the RGBU applications the message-based flows are across the RIB. It is typical that external applications are predominately service-based so the output of USM is a call is to an external service.
Service calls from an external service are transformed to the correct style and format of the internal application.
The functional requirement for the USM is to act as the place to transform the Oracle Retail application data style and the data format into the data format expected by the external application, and then to perform the transformations of the external application's response
The USM User Interface provides the ability to create and manage Projects in USM and to view app statistics, metrics about the message flow and the system Logs
The USM Engine is the logic part of the system where the data is received from one application, mapped to other data and the mapped data is sent to other applications. Data is communicated through service calls.
USM hosts all the necessary web-services that are required by both the participating sender and the receiver applications.
USM has a configuration file of the service URLs to the participating applications.
USM has templates that contains the mapping information, the code that does the mapping and other configuration files to make the application work.
Universal Service Mapper has three major components:
Event Listener [Abstract Service Mapper, Service Def JSON]
Service Mapper Orchestration [Orchestrator, Template and DVM]
External Service Invocation and Service Provider
The Event listener is a service hosted by the USM application which is open to receiving data from any application that is connected to it. The application here is either RIB-LGF or WMS Cloud. The applications have the following URL pattern set in their target for USM.
http://<host>:<port>
When application sends data, the event listener internally calls the abstract service mapper which determines family, message type and the operation(s) from the message received by referring to the Service Def JSON file.
The abstract service mapper in turn now calls the Service mapper orchestrator which decides which what data is to be populated in the mapper templates. The orchestrator does the mapping, field by field, from the source application to destination application. Certain key-value pairs in the DVM in order to maintain context between the applications.
The Service Mapper Orchestrator calls the services hosted by the service providers after the mapping operations are completed. The service providers here are either RIB-LGF or WMS Cloud, which consume these services via USM. The calls are REST calls. USM holds the information necessary for it to call these services in a file with the prefix "external_env_json" for the respective application. These are stored as key-value pairs in JSON file
Retail Integration Cloud Service (RICS) is used to integrate MFCS to Oracle Warehouse Management Cloud (WMS - LogFire).
RICS uses Universal Service Mapper (USM) to perform the mappings required to connect RICS payloads/services to LogFire interfaces. USM is used to transform and manage the integration flows in both directions.
