Oracle® Retail Reference Architecture
RIB/IGS Logical Architecture Model
December 2015
Contents
Intended Audience for this Document
Introduction
The logical architecture of a system presents the significant components that make up the system, as well as how these components interact with each other to deliver the required functionality. The system’s significant components are described in this document, which includes the component’s responsibilities and composition.
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 logical model is used as a tool to allow customers to understand the componentization of our systems, and the some technology underpinnings without being too bogged down into the source code itself.
· All RGBU Groups – the entire organization will now have a level-set architecture from which everyone can understand the significant components of our systems
Logical Model
The logical model diagram shown in Figure 1 depicts the logical components for the RGBU’s integration systems. Each section of the integration systems (RIB, RSL and IGS) are described in the subsequent sections of this document.
Figure 1: RIB/IGS Logical Architecuture Diagram
The diagram outlines the relationships between the logical components, and shows the packaging of the components.
RIB
The publishing application API is responsible for creating the business object from business content. The RIB publishing adapter accepts the business objects, either java beans or PL/SQL Oracle Objects, and converts it to a RIB message and publishes it to the JMS Server and makes it available to any JMS subscribers.
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 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.
A single TAFR may only transform a given message, only filter the message, only route it, or combine any of the three operations.
n Transform - A message may be transformed from one message type into another, for example, 'WH' (warehouse) from RMS to 'Location' for RWMS.
n Filter - A message may be filtered. Filtering can occur based on message type or based on content.
n Route - A TAFR may route a message. For example, whenever a stock order message is published for a warehouse with an instance of RWMS, the TAFR routes it to the particular RWMS instance from where the stock will be fulfilled and not to warehouses that do not stock the order's items.
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 RIB 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 ensure messages are always processed in the proper sequence. If proper sequencing is not maintained, then the subscribing application's data can get corrupt.
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.
After a message is checked into the RIB 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.
Component
Descriptions
Adapters
A RIB adapter is a component that coordinates business event (message) generation and processing with the respective Oracle Retail application interface. Each adapter in the RIB is created to handle a specific functional interface. RIB adapters are developed using Enterprise Java Beans (EJB) components architecture, subscribing adapters use Message Driven Beans (MDBs) and publishing adapters use Stateless Session Beans (SLSBs).
The RIB provides four types of adapters that Oracle Retail applications can exploit to integrate with one another. These adapter types are: publisher, subscriber, TAFR, and hospital retry. They have been built using different technologies based on their particular needs.
Subscriber and TAFR adapters use Message Driven Bean (MDB) technology to register with JMS topics and receive messages for further processing.
Publisher and hospital retry adapters make use of the Java SE (Standard Edition) timer facility to schedule repetitive events that trigger calls to Stateless Session Beans (SLSBs) to query application tables for messages to publish to the JMS server.
The RIB
Hospital
The RIB 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:
n Guaranteed once-and-only-once successful delivery.
n Preservation of publication sequence (even in case of failures).
When a message is processed, the adapter checks to see if the RIB Hospital contains any messages associated with the same businessObjectId as the current message. If so, then the adapter places the current message in the hospital as well. This is to ensure messages are always processed in the proper sequence. If proper sequencing is not maintained, then the subscribing application's data can get corrupted.
If an error occurs during message processing, the subscribing adapter notes this internally and rolls back all 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.
|
Oracle Corporation
World Headquarters
500 Oracle Parkway
Redwood Shores, CA 94065
U.S.A.
Worldwide Inquiries:
Phone: +1.650.506.7000
Fax: +1.650.506.7200
oracle.com
Copyright © 2015, Oracle. All rights reserved.
This document is provided for information purposes
only and the
contents hereof are subject to change without notice.
This document is not warranted to be error-free, nor
subject to any
other warranties or conditions, whether expressed orally or
implied
in law, including implied warranties and conditions of merchantability
or fitness for a particular purpose. We specifically disclaim any
liability with respect to this document and no contractual obligations
are formed either directly or indirectly by this document. This document
may not be reproduced or transmitted in any form or by any means,
electronic or mechanical, for any purpose, without our prior written
permission.
Oracle, JD Edwards, PeopleSoft, and
Siebel are registered trademarks of Oracle
Corporation and/or its affiliates. Other names may be trademarks
of their respective owners.