Using Oracle Service Bus to Integrate Oracle Retail with External ...

An Oracle Retail White Paper 

September 2012 

Using Oracle Service Bus to Integrate 

Oracle Retail with External Applications

Oracle Retail White Paper – Using Oracle Service Bus to Integrate Oracle Retail with External Applications 

Contents 

Executive Overview ................................................................................................................... 3 

Introduction ................................................................................................................................ 3 

Integration Gateway Services .................................................................................................... 5 

Oracle Service Bus Publishing and Subscribing to RIB AQ/JMS ................................................ 7 

Utilizing Oracle Retail Web Services .......................................................................................... 8 

Customization and Extensions ................................................................................................... 9 

Customer Implementation Examples .........................................................................................10 

Petco .....................................................................................................................................10 

The Beer Store ......................................................................................................................13 

Conclusion ................................................................................................................................13 

Resources .................................................................................................................................13 

Disclaimer 

The following is intended to outline our general product direction. It is intended for information purposes only, 

and may not be incorporated into any contract. It is not a commitment to deliver any material, code, or 

functionality, and should not be relied upon in making purchasing decisions. The development, release, and timing 

of any features or functionality described for Oracle’s products remains at the sole discretion of Oracle.


Executive Overview 

One of the key challenges for customers in implementing Oracle Retail’s suite for merchandising 

operations management is integrating to other legacy and 3 rd party applications. Integration of 

heterogeneous applications or applications with different data and application architectures has always 

been and will always be challenging. Numerous companies have begun a Service Oriented Architecture 

(SOA) initiative with the assumption that implementing web services is synonymous with employing a 

service-oriented architecture. This white paper outlines approaches recommended by Oracle Retail and 

utilized by customers to integrate applications using Oracle Service Bus (OSB). 

Introduction 

One of the cornerstone principals of SOA-based architecture is to provide a loosely-integrated suite of 

services. In an enterprise architecture that makes use of an enterprise service bus (See Figure 1) like 

Oracle Service Bus (OSB), an application will communicate via the bus which acts as the single message 

turntable between other applications. That approach reduces the number of point-to-point connections 

between communicating applications, enabling integration of additional applications to the enterprise 

architecture and making changes quickly across enterprise applications to meet business processing 

requirements. 

The role of Oracle Service Bus for integrating applications is: 

• Acts as the conduit for communication between all participants of the SOA (service consumers and 

service producers). 

• Provides the ability to achieve loose coupling and a higher level of flexibility as integration points 

between consumer and provider can be configured at runtime rather than hard-coded. 

• Isolates service consumers from minor changes in the service provider. 

• Mediates between endpoints ─ mediation may be in the form of transport, message, and security 

exchange. 

• Supports transformation and routing between requesting applications and providing applications.


Figure 1: Enterprise Service Bus 

The proper implementation of Oracle Service Bus is highly dependent on understanding the correct 

integration style or pattern required between the requestors or consumers and the providers or producers. 

For this white paper, the five basic integration patterns used between Oracle Retail applications and other 

applications are: 

1. Data-centric integration for bulk data replication and transaction loading, where there are no data 

enrichment or multiple end points requirements. 

2. Native interface integration for exchange of business events between producer application and 

consumer application involving transactions in asynchronous, near real-time mode. 

3. Service-based integration using message exchange pattern involving business transactions in 

synchronous, real-time mode between requestor and producer applications. 

4. Reference data queries from a requesting application validate or query data from autonomous or 

multiple providers. 

5. Process centric integration flows between two or more applications to implement a business process 

requiring orchestration of activities between the applications themselves including message 

enrichment, validation, or complex transformation. 

While OSB has capabilities for handling flat file or bulk data centric integration, the first pattern is normally 

implemented using an Extract, Transform and Load (ETL) tool like Oracle Data Integrator. The second 

pattern is used by Oracle Retail Integration Bus (RIB) between participating Oracle Retail applications.


The focus of this white paper will be on how customers have integrated Oracle Retail applications to 

external applications for exchange of business events and transactions using either the asynchronous, 

near real-time pattern (#2) or the synchronous, real-time mode (#3). The key difference between these 

two patterns is the transaction boundary defined in the business process between the requestor and 

provider services. 

There are three basic methods customers can utilize OSB to integrate with Oracle Retail applications: 

1. OSB invokes requests to RIB’s Integration Gateway Services (IGS). 

2. OSB publishes or subscribes to messages on RIB AQ/JMS. 

3. OSB invokes requests directly to Oracle Retail provided web services or replies to Oracle Retail 

requests. 

Integration Gateway Services 

Beginning with Oracle Retail Integration Bus (RIB) 13.1, Oracle Retail provides a set of web services 

which expose existing RIB interfaces. The Integration Gateway Services (IGS) provide a web services 

wrapper around RIB external interfaces which can be invoked by a web service requestor directly or via 

OSB to push business event transactions and foundation data creates and updates into the Oracle Retail 

applications using the RIB infrastructure (see Figure 2). 

External Domain Oracle Retail Integration Domain Oracle Retail Application Domain 

External 

Application 

(web service 

client) 

Use Case: Expose 

Internal IGS Web 

Service External via 

OSB Proxy 

SOAP HTTP 

OSB 11gR1 

Proxy 

Service 

Business 


RIB IGS 


AQ JMS 

rib-4-rms 

Figure 2 – Method 1 Architecture Overview 

RMS RDBMS 

PL/SQL 

API’s 

Fire-and-Forget Request/Response


To the external application, IGS via OSB exposes a web service which can be involved with a request to 

create or update a retail business object (e.g. Supplier). OSB mediates the routing of the request to the 

appropriate IGS web service based on the operation and the retail business objects or message family as 

they are known in RIB. 

The main advantage of using IGS is it utilizes RIB’s Guaranteed Only Once Delivery (GOOD) architecture 

and Retail Business Object payloads to ensure all Oracle Retail applications that participate in the 

business transaction or foundation data sync receive the message from the source application to be 

processed or it is captured in the RIB Error Hospital using the synchronous real-time pattern. 

IGS and OSB allow the source application to be abstracted from any of the Oracle Retail applications. 

This enables relatively easy changes in the source application; source application interface; or retail 

business object payload to be made, tested and implemented. RIB also will preserve the publication 

sequence of the incoming transactions to ensure they are processed in the correct order after they are 

delivered to the JMS message queue. 

RIB/IGS 

RIB Business 

Object.xsd 

BusinessObjectId.xsd 

WS Client Soap R/R 

IGS Web Services 

IGS Service.wsdl 

RoutingInfos.xsd 

RIB Message.xsd 

RIB 

Msg 

W 

Depending on API 

technology converts to 

Oracle Object or java 

bean representation. 

RIB Business 

Object.xsd 

Figure 3 - IGS architecture overview 

A disadvantage of using OSB/IGS is when the source application (WS Client) needs more than an 

acknowledgement from RIB that the requesting message payload was received. IGS only provides an 

acknowledgement and not retail specific data resulting from a successful completion of the service call. 

JMS 

R 

RIB 

Msg 

RIB Sub Adapter(s) 

Invoke 

Invoke 

API Business 

Object – Oracle 

Object 


Object – Oracle 

Object 

Invoke 


Object – java 

Bean 

Warehouse 

Management System 

(RWMS) 

Merchandising 

System 

(RMS) 

Store Inventory 

Management 

(SIM)


The role of OSB is to mediate between the source application and the IGS web service (see Figure 3). 

OSB would transform the payload from the source application and route using a Simple Object Access 

Protocol (SOAP) call to the IGS web service for the retail business object being received. OSB would 

wait for the message received acknowledgement from the IGS web service ─ which OSB could keep for 

audit purposes or pass back to the source application. 

OSB Publishing and Subscribing to RIB AQ/JMS 

The second method for integration to Oracle Retail applications is by using the RIB topics at their Java 

Message Service (JMS) endpoints (see Figure 4). This method would be recommended for substitution of 

an existing Oracle Retail application or RIB interface with a 3 rd party or legacy application or interface. 

The role of OSB in this method would be to handle transformation of the retail business object payload 

and routing the payloads to/from the appropriate RIB/JMS topics. 



Internal AQ JMS Topic 

External via OSB 

Business Service 


Application 

Message 

Subscriber 

Adapter 

Message 

Publish 

Adapter 


Internal AQ JMS Topic 

External via OSB Proxy 



OSB 11gR1 

Proxy 


Proxy 




AQ JMS 

rib-4-rms 

AQ JMS rib-4-rms 


RMS RDBMS 

The advantages of using this method with OSB are the messages from RIB via AQ/JMS can be 

transformed and routed to multiple external applications and external applications can publish messages 

to OSB which can be transformed and routed to RIB via AQ/JMS. This provides an asynchronous, 

message-based framework for near real-time integration between external applications and Oracle Retail 

applications. The framework is agile to accommodate additions or changes in the participating 

applications, changes in the message payloads, and differences in data transport layers (e.g. MQ, Flat file 

I/O, EJB, FTP, and DB adapters). Using OSB and RIB in this method can be scalable to meet large 

volumes of messages of data being moved between external applications and Oracle Retail products. 

PL/SQL 

API’s 



Disadvantages of using this method include: lack of acknowledgement provided by the receiving or 

consuming application of message receipt since it is an asynchronous framework; and messages 

received by RIB that are not correctly formatted will be rejected by RIB causing the listening queues to be 

shutdown automatically by RIB. This is a protective feature in RIB to eliminate receipt of potentially 

‘poisonous’ data messages into RIB. 

Utilizing Oracle Retail Web Services 

The final method for integration of external 3 rd party or legacy applications and Oracle Retail applications 

is utilization of direct web services for synchronous, real-time integration (see Figure 5). Currently, there 

are three web services packaged with the Oracle Retail Applications: 

1. GL_Account_Code_Validation_Request 

2. Maintain_Supplier_Provider 

3. Maintain_Payment_Terms_Provider 



Application http soap 


External Business 

Service Internal via 

OSB Proxy 



Proxy 


http soap 

http soap Business Proxy 

http soap 

Service Service 

OSB 11gR1 


RMS RDBMS 

PL/SQL 

API’s 

Provider 

Web Service 

Requestor 

Web Service 

The advantage of using these web services for integration of Oracle Retail to external applications is they 

provide secured integration with any external application capable of requesting or providing standard 

SOAP-enabled web services. This can be utilized by multiple applications to routed to the appropriate 

service provider based on the context of the request ─ allowing for implementation of integration patterns 

#4 and #5 (see Page 4) mentioned earlier in this paper. 



The role of OSB in this method is to mediate the request/responses between the external application 

requestor/provider services and the Oracle Retail requestor/provider. This would allow for multiple 

external requesting services to access a single provider service or OSB to route based on the message 

context to one or more service providers. Utilizing this method, OSB can enable process-centric 

integration flows between two or more applications to implement a business process requiring 

orchestration of activities between the applications themselves including message enrichment, validation, 

or complex transformation. 

The disadvantage of this method is it requires services to be built exposing application functionality and 

their interfaces to be well understood and documented. It also requires versioning of services and object 

payloads. This requires mature SOA governance of the integration architecture to ensure new or change 

process orchestrations can be handled properly. 

Customization and Extensions 

Most implementations of Oracle Retail will require customizations and extensions to meet business and 

integration requirements. For purposes of this document, customization is the changing of an existing 

object or operation on an object (e.g. Maintain Suppliers) while extension is adding additional objects or 

operations to existing objects. 

Oracle Retail provides tooling RIB Artifact Generator and Retail Service Enabler for customers to 

customize and extend the RIB/IGS to help meet business processing requirements. The RIB Artifact 

Generator implements and enforces rules for customization/extension of the Retail Business Objects that 

are used to create the functional artifacts for use in the Oracle Retail Integration systems. The tool, 

regardless of the installation type, will only process XSDS that have been added or modified per these 

rules. 

The Retail SOA Enabler (RSE) is a Service Infrastructure tool developed by Oracle Retail to enable the 

adoption of Service Oriented Architecture (SOA) by enforcing SOA best practices and patterns. Major 

features of standards-based Retail SOA Enabler: 

� All services are SOAP/HTTP based Web services. 

� Complies with JAX-WS specification. 

� Services are WS-Addressing enabled. 

� WS-Security can be plugged in without any code change.


� Generates technology specific API templates for PL/SQL APIs and javaEE. 

� Supports PL/SQL as a Web service provider. 

� Supports Web Service versioning strategy. 

These tools make it easier for customers to customize and extend the existing Oracle Retail integration 

framework and maintain an upgrade path for future releases. 

Customer Implementation Examples 

Petco 

Objective 

PETCO is one of the fastest growing pet care retailers in North America. They needed to modernize their 

merchandise operations to meet the demands of business growth by implementing Oracle’s Retail 

Merchandising System and Price Management applications. The implementation required integration with 

other legacy and 3 rd party applications without customizations or extensions to applications. 

Challenge 

Petco faced the following challenges in integrating Oracle Retail products: 

1. Expose relevant RMS and RPM functions as services in Oracle Service Bus (OSB) through Retail 

Integration Bus (RIB) infrastructure. Leverage Integrated Gateway Services (IGS) for inbound 

integrations to retail systems wherever available. 

2. Build adapter and consumer services on OSB to interact with legacy applications. 

3. Build integrations following AIA framework for objects which are provided by AIA Foundation Pack. 

Create AIA artifacts(Enterprise Business Services and Application Business Connector Services). 

Loose coupling through a canonical (application-independent) model is achieved. 

4. Integrate by single service implemented in BPEL composite for enterprise objects which are not 

provided by AIA FP.


The following diagram depicts the inbound interface pattern used to feeding RMS from external 

applications using Oracle Service Bus and Retail Integration Gateway Services. 

1. BPEL Composite gets the message from third-party applications through configured technology 

adapter service or web service. 

2. BPEL transforms the message to the required format. 

3. BPEL Composite invokes the OSB Proxy service using a SOAP message. 

4. Proxy Service will in turn request appropriate RIB IGS web service. 

5. IGS web service does asynchronous write to AQ/JMS for RIB subscriber adapter.


For feeding external applications from RMS, the following pattern was utilized: 

1. RIB publishes asynchronous messages to AQ/JMS. 

2. OSB business service configured on Fusion middleware will get the messages from AQ/JMS. 

3. BPEL Composite will be invoked from the OSB proxy service to do the required formatting. 

4. Transformed messages will be routed to the target applications using application native adapters 

Results 

/web services or via POLARIS. 

Results from their initial use of OSB and RIB/IGS were successful: 

1. Petco’s SI, TCS, was able to implement production integrations using OSB and RIB/IGS: 

1. Item from PIM to RMS 

2. Item/Location from legacy via POLARIS to RMS 

3. Suppliers from PeopleSoft to RMS 

2. Used 3 rd party proprietary connectors for Item from PIM


3. Connectors do not populate Business Object ID for RIB which could be problematic for preservation 

of publishing sequence. 

The Beer Store 

Objective 

The Beer Store, Canada's largest beer retailer and distributor, had a company-wide initiative to modernize 

operations. They wanted to complete the rollout of a new high speed point-of-sale system that would 

enable the company's application server bridge to handle approx 500,000 messages per day from the 

company's 440 retail stores while delivering two-to-three-second transaction times at the cash registers. 

Challenge 

The challenge was to achieve accurate and timely inventory reporting and efficient open and close 

routines in stores to better manage inventories and reduce wage costs. 

Results 

The Beer Store worked with Oracle Consulting to achieve a tenfold improvement in back-end system 

performance through performance tuning and installation of Oracle Service Bus. 

Conclusion 

Oracle Service Bus can be a valuable tool for integrating Oracle Retail applications. But choosing the 

appropriate integration pattern is critical in utilizing several available methods for integrating external 

applications with Oracle Retail. 

Oracle Retail provides all the tools necessary to enable customers and system integrators to customize 

and extend their solutions. Oracle Service Bus provides a rich set of adapters to handle connectivity with 

many 3 rd party and legacy applications (OSB Adapters). 

Resources 

1. OSB Examples and Tutorial 

http://java.net/downloads/oraclesoasuite11g/OSB/osb_examples_tutorials_111130.pdf


2. How to Customize an IGS 13.2.0 Service using RSE and AG 13.2.0 - 1307371.1 

The purpose of this paper is to discuss how to use the Oracle Retail SOA Enabler (RSE) and Artifact 

Generator (AG) tools to customize an Integration Gateway Services (IGS) Service. Customization of 

an IGS Service also means customization of the API for RIB and the subscribing application. While 

this document focuses only on the IGS end of the process, all activities must be completed for a 

working flow. The most common use case in customization is to add new elements to existing 

messages. This document covers that use case. 

3. How to Configure WebLogic Server 10.3.3 to the RIB 13.2.0 AQ JMS - 1307397.1 

This paper covers the steps to configure WebLogic Server 10.3.3 to use the RIB AQ JMS as a foreign 

JMS server and to have all of the Oracle Retail RIB JMS topics available for use by 3 rd party software. 

The steps to configure foreign JMS server are covered in the GA WebLogic documentation set, but to 

also make the RIB JMS topics accessible for an application can be tedious and prone to error. 

Oracle Fusion Middleware allows for the creation of domain extension templates, which are Java 

Archive (JAR) files that contain the files and scripts required to create or extend a WebLogic domain. 

There is a WLS Domain template attachment to the white paper that will extend a domain and takes 

care of the infrastructure needed of applications to use the RIB AQ JMS. 

4. How to Integrate OSB 11.1.1.4 to the Oracle Retail RIB 13.2.0 AQ JMS - 1307396.1 

This document covers the steps to configure Oracle Enterprise Service Bus (OSB) on WebLogic 

Server 10.3.4 to use the RIB 13.2.0 AQ JMS as a foreign JMS server. It also discusses having OSB 

proxy and business service exposed for all of the Oracle Retail RIB JMS topics available for use by 

third party software.

Oracle Retail White Paper 


Using Oracle Service Bus to Integrate Oracle Retail with External Applications 

September, 2012 

Author: Dan Conway 

Contributors: David Burch, Prantor Bora 

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 © 2012, 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 is a registered trademark of Oracle Corporation and/or its affiliates. Other 

names may be trademarks of their respective owners.

Using Oracle Service Bus to Integrate Oracle Retail with External ...

Create successful ePaper yourself

Delete template?

Save as template?