11 Pre-implementation Considerations

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.

BDI Software Lifecycle Management

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

Preparation Phase

In this phase, all relevant components are downloaded, extracted, and configured.

Application Assembly Phase

In this phase, site specific configuration changes are made and all relevant BDI wars are generated.

Deployment Phase

In this phase, using the BDI wars created in the previous step, the wars are deployed to application server instances.

Operation Phase

In this phase, day-to-day operations of the BDI applications are performed.

Maintenance Phase

In this phase, code fixes, patching, configuration changes and maintenance of the BDI applications are performed.

Physical Location Considerations

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-rpas" integration schema is created in the RPAS database server so that the data movement from inbound tables located in the integration schema to the RPAS transactional tables is fast.

It is also recommended to colocate the "rms-batch-job-admin" application near RMS application and the "rpas-batch-job-admin" application near RPAS application. The Job Admin application for BDI RMS (rms-batch-job-admin) need to be deployed in a separate domain. Similarly BDI RPAS (rpas-batch-job-admin) needs to be deployed in a separate domain.

Multiple instances of the BDI RPAS application can improve the transfer of bulk data between RMS and RPAS.

High Availability Considerations

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.

WebLogic Server Cluster Concepts

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-<app> application and WebLogic Application Server Cluster

BDI uses the Receiver Service to transfer data from one system to another system. The BDI edge apps such as RPAS, 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-rpas application simultaneously.

Logging

Issue

The "System Logs" tab in Scheduler, Process Flow, and Job Admin UIs show only logs from the server that UI is connected to.

Solution

Use a common log directory for each of the BDI components. BDI components use the following directory structure for creating log files.

$DOMAIN_HOME/logs/<server name>/<app name>

Example

$DOMAIN_HOME/logs/server1/rms-job-admin_war

$DOMAIN_HOME/logs/server2/rms-job-admin_war

Create a common log directory (e.g. /home/logs/bdijobadmin) for each BDI application.
Create symbolic links to the common log directory for each server using the below command from $DOMAIN_HOME/logs directory.

ln -s /home/logs/bdijobadmin

server1/rms-job-admin_war

ln -s /home/logs/bdijobadmin

server2/rms-job-admin_war
If the directory $DOMAIN_HOME/logs/<server>/<app> already exists, it needs to be deleted before symbolic link is created.
App needs to be restarted after symbolic link is created.

When weblogic managed servers are in different machines a shared network disk has to be used.

Update Log Level

Issue

When log level is updated through UI or REST end point, it updates the log level only on the server it is connected to.

Solution

Log level needs to be updated through the URL of all the nodes in the cluster using UI or REST endpoint.

Example

http://server1:port1/rms-batch-job-admin/system-setting/system-logs

http://server2:port2/rms-batch-job-admin/system-setting/system-logs

Create/Update/Delete System Options

Issue

When system options are created/updated/deleted using UI or REST end point, the changes are reflected only on the server that client is connected to.

Solution

The reset-cache REST endpoint need to be invoked on the other nodes in the cluster for that application in bdi.

Example

http://server1:port1/rms-batch-job-admin/system-setting/reset-cache

Create/Update/Delete System Credentials

Issue

When system credentials are created/updated/deleted using REST endpoint, the credentials are created/updated/deleted only on the server that client is connected to.

Solution

The REST endpoint that creates/updates/deletes credentials need to be invoked on all the nodes in the cluster for that application in BDI.

Example

http://server1:port1/rms-batch-job-admin/system-setting/system-credentials

http://server2:port2/rms-batch-job-admin/system-setting/system-credentials

Scheduler Configuration Changes for Cluster

Two data sources need to be created for scheduler on cluster in the Admin Console.
- Create a non-XA data source (SchedulerTimerDs) pointing to the schema that contains the WEBLOGIC_TIMERS table. This is the schema with the WLS suffix, created using RCU.
  
  Specify this schema in the scheduling tab of cluster configuration in WebLogic console.
- Create a non-XA data source (SchedulerRuntimeDs) pointing to schema that contains ACTIVE table. This is the schema with the WLS_RUNTIME suffix, created using RCU.
  
  Specify this schema in the Migration tab of cluster configuration in the WebLogic console.
Perform the following steps to configure the data sources:
1. Specify the data source for schedule timers in the Admin Console.
2. Login to Admin Console.
3. Click Lock & Edit (For Production Mode only).
4. Click Environment -> Clusters.
5. Click the cluster name.
6. Click Scheduling.
7. Select SchedulerTimerDs for the Data Source For Job Scheduler field.
8. Click Save.
9. Click Migration.
10. Select Migration Basis: DataBase, and Data Source For Automatic Migration: SchedulerRuntimeDs.
11. Click Save.
12. Verify Auto Migration Table Name populated with ACTIVE.
13. Click Activate Changes.

Update the weblogic-ejb-jar.xml in WEB-INF folder of the bdi-scheduler-ui-<version>.war in <bdi-home>/dist folder with the contents shown (The entry in red is the change from the existing contents of the file)

Instructions to update

cd dist
jar xf bdi-scheduler-ui-<version>.war WEB-INF/weblogic-ejb-jar.xml
Update the WEB-INF/weblogic-ejb-jar.xml with the contents below
jar uf bdi-scheduler-ui-<version>.war WEB-INF/weblogic-ejb-jar.xml
Delete dist/WEB-INF folder
Deploy the scheduler application

<weblogic-ejb-jar xmlns="http://xmlns.oracle.com/weblogic/weblogic-ejb-jar" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
    <security-role-assignment>
        <role-name>AdminRole</role-name>
        <principal-name>BdiSchedulerAdminGroup</principal-name>
    </security-role-assignment>
 
 
    <security-role-assignment>
        <role-name>OperatorRole</role-name>
        <principal-name>BdiSchedulerOperatorGroup</principal-name>
    </security-role-assignment>
    <security-role-assignment>
        <role-name>MonitorRole</role-name>
        <principal-name>BdiSchedulerMonitorGroup</principal-name>
    </security-role-assignment>
    <timer-implementation>Clustered</timer-implementation>
</weblogic-ejb-jar>