| Oracle® Retail Integration Cloud Service Implementation Guide Release 19.0.000 F25439-01 |
|
 Previous |
 Next |
| Oracle® Retail Integration Cloud Service Implementation Guide Release 19.0.000 F25439-01 |
|
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.
Prepare the environment
Assemble the application
Deploy and start the application
Perform day-to-day monitoring to make sure the application is running properly
Apply code fixes to the application
RIB supports and follows the RIB Software Lifecycle Management, a well-defined process life cycle that 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 are 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, configuration changes and maintenance of the RIB is performed.
Another key concept in the design of RIB is that all configuration and management is done 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.
TAFR adapters use RIB Hospital functionality. 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 them 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 co-locate 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.
If the RIB is deployed into an environment where multibyte characters are used in the message data, improper database setup can lead to error messages indicating that insert values are too long.
There are several database settings that can affect the behavior of the processing messages that contain multi-byte characters. Some are set during the creation of the instance, and others are configurable. The settings to pay attention to are NLS_CHARACTERSET, NLS_LANG, NLS_LENGTH_SEMANTICS. The interactions and considerations are beyond the scope of the RIB documentation and should be discussed with the database administration team prior to installation.
The BYTE vs. CHAR setting is especially important. If it is not set up correctly, errors can result, indicating the value being inserted is too long for the field. The following is an example of an insert error:
Internal Exception: java.sql.SQLException: ORA-01461: can bind a LONG value only for insert into a LONG column.
The RIB error hospital is designed to handle systemic and business related error conditions while preserving publication sequence. The error hospital is not designed to stage large volumes of data for lengthy time periods. When sizing the Error Hospitals as part of any topology suggested in this document, keep in mind that they can suddenly grow to many times what will be considered normal. This condition is called flooding the hospital and one of the situations that can have catastrophic effect on the run-time performance of the RIB flows that are associated with that hospital.
The tuning and performance of the Hospital and associated retry components is not designed to support large numbers of messages; aka flooding. Flooding is difficult to define, but generally speaking when the number of messages in the hospital is measured in the 5 figures (10,000) and up, operational impacts will occur and process and procedures should be developed to stop the flow(s) and deal immediately with the source of the issue causing the messages to go to the hospital. During the development and test phases, a customer should consider the possibility of flooding to occur and to have predetermined processes in-place before production. When the problem hits is not the time to be trying to find answers, the out-come of a hospital flood situation is often a business-down situation.
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 the 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.
It is important to consider the sizing, either file system space or database table space, when planning the deployment of the JMS Provider to a host. It is a very common operational use case for one of the Oracle Retail subscribing applications to go off-line for an extended period, either due to business requirements or problems. Basic sizing at a customer for any JMS system is for the disk (mount points or database) to be able to handle 24 hours of maximum messages per topic.
Having multiple JMS servers can improve overall system performance and accommodate the following:
the separation of high volume families from low volume ones.
the customization of integration flows.
Operational Quality of Service(QoS).
distribution of the overall load on the integration system.
To meet the JMS agnostic requirement for RIB, a unique JMS server ID (jms-server-id) is assigned to each RIB adapter. Accordingly, each RIB adapter can identify the JMS server to which it is associated. As the default, out-of-the-box adapters are configured to be on jms-server jms1.
For each new jms-server-ID, a new resource adapter must be configured to point the application server to the JMS provider's resource. The adapter communicates with the JMS server and is deployed as part of the application. Where customization is required, the adapter can be configured to point to a different JMS.
|
Note: For more information on using multiple JMS, see Chapter 6, "JMS Provider Management," in the Oracle Retail Integration Bus Operations Guide. |
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.
The Oracle RDBMS instance that will be configured as the AQ JMS must be tuned to support the number of processes needed for the RIB adapters installed and configured in each deployment environment.
The number of JMS AQ processes depends on the RIB configuration.
|
Note: To determine the probable number of RIB AQ JMS processes in the deployment, see "The RIB on AQ JMS" in the Oracle Retail Integration Bus Operations Guide. |
|
Note: See also the Oracle Database Performance Tuning Guide 12c Release 1 (12.2). |
See also the following information about 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, have become a basic requirement 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 addresses availability, scalability, recoverability requirements which are 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; those relevant to RIB are Oracle database cluster (RAC) and WebLogic 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 the 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.
A WebLogic Server cluster consists of multiple WebLogic Server managed server instances running simultaneously and working together to provide increased scalability and reliability. A cluster appears to clients to be a single WebLogic Server instance. The server instances that constitute a cluster can run on the same machine, or be located on different machines. You can increase a cluster's capacity by adding additional server instances to the cluster on an existing machine, or you can add machines to the cluster to host the incremental server instances. Each server instance in a cluster must run the same version of WebLogic Server.
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.
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.
See the Oracle® Fusion Middeware Using Clusters for Oracle WebLogic Server documentation for more information:
>>https://docs.oracle.com/middleware/1221/wls/CLUST/title.htm.
RIB uses a JMS server for message transportation between the integrating retail applications. Since RIB must preserve the message publication and subscription ordering, rib-<app>s deployed in WebLogic 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 managed server instance of an WebLogic Application Server that is clustered(active-passive). In this configuration even though rib-<app> is deployed in a WebLogic cluster, multiple instances of the same rib-<app> are not running at the same time, as there is only one managed server instance where the rib-<app> is deployed and so RIB can still preserve message ordering.
To truly configure rib-<app>s for high availability, the only option is to configure it in active-passive mode.
For WebLogic server, using a concept called Pinned Deployment, you can deploy and target your applications to a particular instance in the cluster.
|
Note: When the AdminServer and second node are on two different physical machines, the deployment of RIB to the second node may fail the first time due to timing issues. If this occurs, the workaround is to run the deployment script a second time. |
At any given time, only one instance of the same RIB app can be running in a cluster. Failure to ensure that only one is running can cause messages to be processed out of sequence or applications to receive duplicate copies of messages.
