1. Integration Overview Guide
  2. Retail Integration Cloud Service Components
  3. Retail Integration Bus (RIB)

Retail Integration Bus (RIB)

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).

RIB Responsibilities with Retail Applications and Third Party Integrations

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.

Figure 3-1 RIB Integration Responsibilities

RIB Integration Responsibilities

RIB Third Party and Legacy Integration

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.

    Figure 3-2 RIBforEXT Information Flow

    RIBforEXT Information Flow

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.

Figure 3-3 FILEIO Information Flow

FILEIO Information Flow