Introduction

This document serves as a plain-English narrative to the context model, RTG RIB/RSL/IGS Domain. The context model perspectives, as well as the intent of each context model are discussed in this document. The context models’ elements are also cited, with focus on what each system in the context model is responsible for in the perspective discussed.

The content of this document is structured to cite the perspective belonging to the domain, the context model associated with the perspective, and then details on the elements within the context model drawing.

Intended Audience for this Document

The intended audience for this document is enumerated in the following list:

· Oracle Retail’s Prospective Customers – through the RGBU Sales and Professional Services organizations, the Retail Reference Architecture (of which context models are a part) can be a key enabler for product license sales and future engagement work.

· All RGBU Groups – the entire organization will now have a level-set architecture from which everyone can understand the weaknesses and features of the RGBU product set

Perspectives for RIB/RSL/IGS Product Domain

The different perspectives for the domain are listed in the following table. Each perspective has a corresponding context model that illustrates the systems involved, and the relationship between systems.

Perspective	Context Model Description	Context Model File Name
Transaction	Shows the generation and flow of transaction message throughout the RIB/RSL/IGS domain and to the edge of the MOM domain	RTG Dev Context Models.vsd

Perspective 1: Messaging Perspective

The Messaging Perspective depicts the creation and movement of transactions between adjacent product domains’ systems.

Context Model Narrative

The RIB, RSL and IGS act as a shared communication layer for connecting various Oracle Retail applications and external applications through an enterprise computing infrastructure. Each of the products implements a different integration pattern, but all use a common set of Business Objects. The RIB/RSL/IGS 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. Each message family has specific message payloads that contain business elements agreed upon between the Oracle Retail applications involved.

RIB

The Retail Integration Bus (RIB) is the core asynchronous messaging backbone and designed as a “Pub/Sub” messaging architecture, with additional application functionality added such as intelligent transformation, routing and error handling. The RIB has been designed to handle retail volumes of messages, typically millions during a Tier 1 retailer’s business day.

The design and architecture of the RIB infrastructure is based on two key requirements driven by the Oracle Retail Application business model.

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). In other words RIB must deliver to every subscriber all messages except those filtered per a subscribing application’s requirements.

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. To enable this, the publishing application defines a “Business Object Id” whose existence informs RIB that this and all subsequent messages with the same “Business Object Id” have to be processed in order. Business event (message) ordering (FIFO) is assured only for messages with the same “Business Object Id” within the same message family.

Message Life Cycle

The publishing application is responsible for creating the initial message content. The RIB publishing adapter publishes it to topics on the JMS Server and makes it available to any registered JMS subscribers. The RIB knows what subscribers are to receive the message due to the RIB configuration -- this configuration associates a set of subscribers to each publisher / Message Family combination.

For PL/SQL Applications, database tables associated with the publishing application typically stage message information. One or more RIB Publishing Adapters poll the application via a stored procedure call. For Java EE Applications, the application calls a RIB Enterprise Java Bean (EJB) with the payload information to be published.

The message resides on a Java Message Service (JMS) immediately after publication. The JMS topic provides stable storage for the message in case a system crash occurs before all message subscribers receive and process it.

A fundamental RIB system requirement is that a message must be delivered to and processed successfully exactly once by each subscriber. Furthermore, all work performed by the subscriber and the RIB must be atomically committed or rolled back, even if the JMS server is on a remote host. The standard way to perform this is by using an XA compliant interface and two-phase commit protocol.

After initial publication, a message may undergo a series of transformation, filtering, or routing operations. A RIB component that implements these operations is known as a Transformation and Address Filter/Router (TAFR) component. TAFR is the acronym for Transform, Address, Filter, and Route. A TAFR is an operation that occurs on the RIB, an adapter that performs one of the operations noted below. A TAFR is completely internal to the RIB and does not reside in either the publishing or subscribing application. The RIB performs these intermediate transformation and routing operations on some messages before making them available to the subscribing application.

TAFR operations are specific to the set of subscribers to a specific Message Family. Multiple TAFRs may process a single message for a specific subscriber and different specific TAFRs may be present for different subscribers. Different sets of TAFRs are necessary for different Message Families. If all subscribers to a message can process all messages within a Message Family without any TAFR operations, then no TAFR components are needed.

Message processing continues until a subscribing adapter successfully processes the message or determines that no subscriber needs this message.

When a Subscriber gets a message to be processed, the adapter checks to see if the Error Hospital contains any messages associated with the same entity as the current message. If so, then the adapter places the current message in the hospital as well. This is to insure messages are always processed in the proper sequence. If proper sequencing is not maintained, then the subscribing application contains invalid data.

If an error occurs during message processing, the subscribing adapter notes this internally and rolls back all database work associated with the message. When the message is re-processed (since it has yet to be processed successfully), the adapter now recognizes this message is problematic and checks it into the hospital.

The RIB Error Hospital is a collective term for a set of Java Classes and database tables whose purpose is to provide a mechanism to handle system and business related errors while meeting the fundamental RIB requirements of guaranteed once-and-only-once successful delivery and preservation of publication sequence (even in case of failures).

After a message is checked into the Error Hospital, a “retry” Adapter extracts the message from the hospital and re-publishes it to the JMS topic for reprocessing. The message remains in the hospital during all re-tries until the subscribing adapter successfully processes it.

Note: See RIB Implementation Guide for more details.

RSL

The Retail Service Layer (RSL) provides synchronous request/response between a limited set of Oracle Retail applications. RSL was designed to fill the integration need for tight coupling between RMS, RPM, SIM, and Allocation. There are only a few Message Families where this was necessary.

RSL handles the interface between a client application and a server application. The client application typically runs on a different host than the service. However, RSL allows for the service to be called internally in the same program or Java Virtual Machine as the client without the need for code modification.

All services are defined using the same basic paradigm -- the input and output to the service, if any, is a single set of values. Errors are communicated via Java Exceptions that are thrown by the services. The normal behavior when a service throws an exception is for all database work performed in the service call being rolled back.

RSL works within the Java EE framework. All services are contained within an interface offered by a Stateless Session Bean. To a client application, each service appears to be merely a method call.

Some Oracle Retail applications, such as RMS, are implemented in the PL/SQL language, which runs inside of the Oracle Database. RSL uses a generalized conversion process that converts the input java object to a native Oracle Object and any output Oracle Objects to the returned java object from the service. There is a one-to-one correspondence of all fields contained in the java parameters as in the Oracle Objects used.

Note: See RSL Programmers Guide for more details.

IGS

The Integration Gateway Services (IGS) provides an integration infrastructure for external system (3^rd Party) connectivity to the Oracle Retail Integration Bus (RIB) in the form of a tested set of Web Service Providers and the configurations to connect to RIB 13.1.

The IGS sub-system is designed to ease the integration to the RIB interfaces and RIB payloads. Traditionally this required custom RIB adapters to create and publish RIB payloads wrapped in RIB Messages envelopes to the RIB JMS topics. The IGS provides the integration to these RIB interfaces via standard request/response Web Services using only the standard XSD based RIB message payloads.

The 13.1 release of the IGS exposes eighteen RIB Message Family interfaces. These interfaces have been selected as the ones most commonly used by for custom integration to their legacy systems. There is a Web Service corresponding to each of the selected Message Families. Each Service expose as operations the message types the RIB Message Family supports.

The integrator will create Web Service clients from the IGS WSDLs, using whatever tools or technology that fit with the retailer’s organization, such as Oracle BPEL. The message payloads are the standard XSDs that ship with the RIB Functional Artifacts. The business logic behind the customer’s client must be written to match the RIB Integration and the Oracle Retail Application API rules. These are the same rules as any GA or custom adapter must follow and are documented in the RIB documents as well as the Applications Guides.

The IGS Web Service infrastructure has been designed to support the RIB features of multi-channel publication via the Business Object ID, as well as message routing via RIB TAFRs where the Message Family supports it. There are additional XSDs that have been added to support these requirements.

Note: See RIB Implementation Guide and RIB Operations Guide for more details.

System Responsibilities

The following table lists the responsibilities of the systems with respect to Messaging Perspective.

SYSTEM	RESPONSIBILITIES
RIB	o RIB enables Oracle Retail applications to integrate in an asynchronous and near real time fashion. o Integration 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
IGS	o Provides a supported infrastructure for customer (3^rd party) integration to the Oracle Retail RIB interfaces via request/response web services using RIB Object XSD message payloads
RSL	o The Retail Service Layer (RSL) provides synchronous request/response between a limited set of Oracle Retail applications