| Oracle® Retail Integration Bus Implementation Guide Release 13.0 |
|
 Previous |
 Next |
Before the RIB is installed into an enterprise, there are many factors that need to be considered. Planning and addressing each of the factors will avoid having to re-install or re-architect because of performance or operational problems.
The process of RIB implementation requires the creation or modification of a retailer's Enterprise Integration Architecture. Typically, retailers will already have an integration strategy, plan or architecture and products in place to integrate their current systems.
The deployment of the RIB is always a portion of the deployment of the Oracle Retail applications, almost always with RMS. Because the implementation of RMS is a long cycle project, and always involves data conversions and integration into a retailer's existing infrastructure, the RIB implementation planning is strategic to that effort.
Software applications, after being made generally available (GA), have a well defined lifecycle process. The implementer must manage and perform tasks in these phases.
Acquire the software components.
Prepares the environment
Assembles the application
Deploys and start the application
Perform day-to-day monitoring to makes sure the application is running properly
Apply code fixes to the application
The RIB supports and follows the RIB Software Lifecycle Management. The RIB Software Lifecycle Management is a well-defined process life cycle and has implemented specific tools and functionality for each of these phases.
Preparation Phase - In this phase all relevant components are downloaded, extracted configured, and version compatibility checks done.
Application Assembly Phase - In this phase, site specific configuration changes are made and all the relevant rib-<app>.ears are generated.
Deployment Phase - In this phase, using the rib-<app>.ears created in the previous step and the site specific information present in a global configuration file, the rib-<app> .ears are deployed to the application server instances.
Operations Phase - In this phase day-to-day operations of the rib-<app> applications are performed.
Maintenance Phase - In this phase, code fixes, patching and configuration changes and maintenance of the RIB is performed.
Another key concept in the design of RIB is that all configuration and management is from a single centralized location using specific RIB provided tools. The RIB is built on a completely de-centralized model. However, to ensure consistency and compatibility within an enterprise deployment, a centralized management and configuration model has been designed.
The RIB provides a RIB installer, consistent with all of the Oracle Retail applications, in addition to a command line set of tools that are used at installation, assembly and deployment time to create the Oracle Retail application specific integration. Collectively these command line tools are called the rib-app-builder and provide functionality to support the RIB Software Life Cycle.
The Oracle Retail Merchandising System (RMS) is the most important core business application from the suite of Oracle Retail Product offerings. RMS provides most of the retail business functionality that Oracle Retail offers its customers. In other words RMS is the central hub of oracle retail applications. Since RMS is the central hub of retail information/data and most information/data flows outward from RMS to other edge retail applications through RIB the decision on where to physically/logically locate RIB is very important and will have direct impact on functioning of your enterprise.
It is recommend to keep the RIB's JMS server logically (not physically) close to the RMS database server as 80% of the data flowing through RIB will interact with RMS database server. Normally RMS up or down status defines your overall enterprise retail business status and so keeping your integration infrastructure status in sync with RMS is beneficial.
RIB Hospital functionality has been added to the TAFR adapters in this release. In order to avoid situations where entire integration can be down just because the TAFR RIB Hospital database is down, it is strategic and beneficial to put the TAFR RIB Hospital tables in the same database instance as the RMS database instance. Obviously it is required to separate the RMS RIB Hospital tables and the TAFR RIB Hospital tables by installing then in their own respective database schemas.
The argument above can be extended to the rib-tafr.ear application and rib-rms.ear application, and so it is recommended to collocate rib-rms.ear and rib-tafr.ear as much as possible.
RWMS and SIM are edge retail applications which might be running closer to your physical warehouse location or your physical store management location. It is recommended collocate rib-sim.ear near SIM application and rib-rwms.ear near RWMS application.
The integration message flow is centrally managed in this release. The rib-func-artifact.war web application determines which messages go where between the rib adapters across all rib-<app> applications. At runtime the rib-<app>.ear needs access to the central message flow repository available in rib-func-artifact.war. Therefore, rib-func-artifact.war must be deployed in a central location where all rib-<app>.ears have access to it at runtime.
The RIB is a central office enterprise integration solution; it is not designed to work optimally on a low (non LAN) bandwidth network. Distribute the rib-<app>.ear applications in such a way where you can avoid lots of network hops, any network protocol bridges, and any communication over a WAN.
Retail business generates huge volume of transactions that are time sensitive in nature. For the business to be agile and react quickly RIB has to transmit the business events over the JMS server very quickly. The RIB depends upon the underlying JMS server for its performance, robustness, and reliability. Therefore, your retail business performance and reliability is directly dependent on how robust and performant JMS server is and how much CPU, memory, network and other system resources are available to it. It is critical to provide adequate hardware resource to the JMS server in order for it to be able to meet your performance requirements.
It is not recommended to locate the JMS server and the RIB application server on the same machine. RIB tools automatically configure the JMS server to meets RIB's required configuration. Do not modify the RIB JMS server configuration unless it is advised by RIB documentations. RIB provides tools to monitor the RIB JMS server and only those recommended tools must be used for your daily operations.
Streams AQ provides PL/SQL APIs to interact with the native AQ server inside the Oracle database. Native AQ stream is not the same as AQ behaving as a JMS server. RIB configures the native AQ server to behave as a JMS specification compliant JMS server implementation. Therefore, it is strictly prohibited to manipulate RIB's JMS topics and RIB's AQ configurations directly with the AQ PL/SQL or java API.
AQ JMS server can be configured to be highly available by taking advantage of Real Application Cluster (RAC) functionality of the Oracle Database.
The RIB installation process defines the minimum RDBMS permissions and role that are required for the RIB code to properly create the AQ JMS topics per the specifications required for the RIB behavior. There should be no attempt to use alternate settings or configurations.
Beyond the installation, there are critical considerations that must be addressed for performance and operations that depend on the volumes and topology of the deployment.
For more information, see Oracle's documentation around High Availability..
As businesses are maturing and having to do everything quicker, better, faster, and with less resource and money they are pushing similar expectation onto their IT infrastructure. Business users are expecting more out of their IT investments, with zero down time, consistent predictable responding systems which are highly available has become basic requirements of today's business applications.
Modern business application requirements are classified by the abilities that the system must provide. This list of abilities such as availability, scalability, reliability, scalability, audit ability, recoverability, portability, manageability, and maintainability determine the success or failure of a business.
With a clustered system many of these business requirement abilities gets addressed without having to do lots of development work within the business application. Clustering directly address availability, scalability, recoverability requirements which is very attractive to a business. In reality though it is a tradeoff, clustered system increases complexity, is normally more difficult to manage and secure so one should evaluate the pros and cons before deciding to use clustering.
Oracle provides many clustering solutions and options, the ones that are directly relevant to RIB are Oracle database cluster (RAC) and Oracle Application Server clusters.
A cluster comprises multiple interconnected computers or servers that appear as if they are one server to end users and applications. Oracle Database Real Application Clusters (Oracle RAC) enables the clustering of the Oracle database. Oracle RAC uses Oracle Clusterware for the infrastructure to bind multiple servers so that they operate as a single system.
Single-instance Oracle databases have a one-to-one relationship between the Oracle database and the instance. Oracle RAC environments, however, have a one-to-many relationship between the database and instances. In Oracle RAC environments, the cluster database instances access one database. The combined processing power of the multiple servers can provide greater throughput and scalability than is available from a single server. Oracle RAC is the Oracle database option that provides a single system image for multiple servers to access one Oracle database. In Oracle RAC, each Oracle instance usually runs on a separate server.
Oracle RAC technology provides high availability and scalability for all database applications. Having multiple instances access a single database prevents the server from being a single point of failure. Oracle RAC enables capability to combine smaller commodity servers into a cluster to create scalable environments that support mission critical business applications.
|
Note: For more information see Oracle RAC documentation. |
In this release rib-<app> uses Oracle Streams AQ as the JMS provider. Oracle Streams AQ is built on top of an Oracle database system. Since AQ is hosted by Oracle database system, RIB can take advantage of database RAC capability for its JMS provider. By using RAC configured AQ as the RIB's JMS provider you can scale the RIB's JMS server vertically and horizontally to meet any retailer's scalability and high availability need.
At runtime rib-<app> uses the database for keeping track of its RIB Hospital records. These RIB Hospital tables can be hosted by an Oracle RAC database providing high availability and scalability for these RIB Hospital records.
Oracle Application Server cluster is defined as two or more Oracle Application Server instances loosely connected to each other providing high availability and scalability for hosted business applications.
Any highly available system has to have redundant components to mask failures in individual components. All Oracle Application Server components can be deployed in a redundant fashion to make their services more available. Oracle Application Server allows choosing between active-active or active-passive redundant models in all its sub-tiers.
In an active-passive configuration the passive components are only used when the active component fails. Active-passive solutions deploy an active instance that handles requests and a passive instance that is on standby. In addition, a heartbeat mechanism is usually set up between these two instances together with a hardware cluster (such as Sun Cluster, Veritas, RedHat Cluster Manager, and Oracle CRS) agent so that when the active instance fails, the agent shuts down the active instance completely, brings up the passive instance, and resumes application services.
In an active-active model all equivalent members are active and none are on standby. All instances handle requests concurrently.
Obviously, an active-active system generally provides higher transparency to consumers and has a greater scalability than an active-passive system. On the other hand, the operational and licensing costs of an active-passive model are lower than that of an active-active deployment.
For those systems requiring an active-active model, Oracle Application Server provides Oracle Application Server Clusters, a set of application server instances configured in an active-active model to serve the same set of applications and/or services. When an active-passive model is needed, Oracle Application Server provides Oracle Application Server Cold Failover Cluster, which is a set of application server instances (two in most cases, since only one remains active and no greater benefits are achieved by including more nodes) configured in an active-passive model to serve the same set of applications and/or services.
Oracle Application Server allows the grouping of Java EE containers that serve the same application through Oracle Application Server Cluster (Oracle Containers for Java EE). The connectivity provided within a cluster is a function of Oracle Notification Server (ONS), which manages communications between Oracle Application Server components, including OC4J and Oracle HTTP Server. The ONS server is a component of Oracle Process Manager and Notification Server (OPMN), which is installed by default on every Oracle Application Server host. When configuring a cluster topology, you are actually connecting the ONS servers running on each Oracle Application Server node which manages the system handshake and coordination.
|
Note: For more information see the Oracle High Availability document. |
RIB uses a JMS server for message transportation between the integrating retail applications. Since RIB must preserver the message publication and subscription ordering, rib-<app>s deployed in Oracle Application Server cannot be configured in an active-active cluster mode. In active-active cluster mode, multiple subscribers and publishers process messages simultaneously and there is no way to preserve message ordering.
rib-<app> can be deployed to a "single" oc4j instance of an Oracle Application Server that is clustered(active-active). In this configuration even though rib-<app> is deployed in an OAS cluster, multiple instance of same rib-<app> is not running at the same time as there is only one oc4j instance where the rib-<app> is deployed and so RIB can still preserve message ordering. The maximum number of JVM (Java Virtual Machine) hosting a rib-<app> oc4j instance must always be configured to be 1 for the same reason of preserving message ordering.
To truly configure rib-<app>s for high availability the only option is to configure it in active-passive mode.
