| Oracle® Retail Bulk Data Integration Implementation Guide Release 16.0 E81413-01 |
|
 Previous |
 Next |
| Oracle® Retail Bulk Data Integration Implementation Guide Release 16.0 E81413-01 |
|
Previous |
Next |
Before BDI 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 reinstall or re-architect because of performance or operational problems.
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
In this phase, site specific configuration changes are made and all relevant BDI wars are generated.
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 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 BDI, the decision on where to physically/logically locate BDI applications is very important and will have direct impact on the functioning of your enterprise.
It is recommended to keep the "bdi-rms" integration schema created in the RMS database server so that the data movement from RMS to outbound tables located in integration schema is fast. Similarly the "bdi-rxm" integration schema is created in the RXM database server so that the data movement from inbound tables located in the integration schema to the RXM transactional tables is fast.
It is also recommended to colocate the "bdi-rms-batch-job-admin" application near RMS application and the "bdi-rxm-batch-job-admin" application near RXM application. The Job Admin application for BDI RMS (bdi-rms-batch-job-admin) need to be deployed in a separate domain. Similarly BDI RXM (bdi-rxm-batch-job-admin) needs to be deployed in a separate domain.
Multiple instances of the BDI RXM application can improve the transfer of bulk data between RMS and RXM.
As businesses are maturing and having to do everything quicker, better, faster, and with less resources 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, 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, a 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 BDI are Oracle database cluster (RAC) and WebLogic Server clusters.
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.
|
Note: See the Oracle® Fusion Middleware Using Clusters for Oracle WebLogic Server documentation for more information.http://download.oracle.com/docs/cd/E15523_01/web.1111/e13709/toc.htm. |
BDI uses the Receiver Service to transfer data from one system to another system. The BDI edge apps such as RXM, SIM can be configured in an active-active cluster mode to achieve better throughput.
In active-active cluster mode, bdi-rms application can send data to multiple instances of the bdi-rxm application simultaneously.
