16 Configuring High Availability for Other Components

This section describes information unique to certain component products.

For this release, this section includes the following topics:

• Deploying Oracle Data Integrator
  Review information in this section, which describes considerations for configuring Oracle Data Integrator repository connections to Oracle Real Application Clusters:
• Deploying Oracle Application Development Framework
  Review this section for special considerations to deploy Oracle Application Development Framework (ADF).
• Deploying BI
  Keep the following in mind as you deploy Oracle Business Intelligence (BI).
• Deploying Forms
  Keep the following in mind as you deploy Forms.
• Deploying Reports
  Reports has the certain considerations you need to know about for a high availability set up.
• Deploying Oracle Business Process Management
  Keep the following in mind when you deploy Oracle Business Process Management in a high availability environment.

Deploying Oracle Data Integrator

Review information in this section, which describes considerations for configuring Oracle Data Integrator repository connections to Oracle Real Application Clusters:

• Oracle RAC Retry Connectivity for Source and Target Connections
  When you configure Oracle Data Integrator (ODI) Oracle Real Application Clusters (RAC) connections, Oracle RAC retry is supported for the ODI master or ODI work repository.
• Configuring ODI Repository Connections to Oracle RAC
  When you create an ODI repository using Repository Creation Utility (RCU), you specify the work repository connection JDBC URL. RCU stores the URL in the master repository contents. If a work repository JDBC URL is a single node URL, Oracle recommends that you modify the URL to include the Oracle Real Application Clusters (Oracle RAC) failover address.
• About Oracle Data Integrator Scheduler Node Failure
  If a WebLogic Server failover occurs, the other WebLogic Server instance becomes the scheduler. A Coherence cache handles the scheduler lifecycle. Locking guarantees the scheduler uniqueness, and event notification provides scheduler migration.

Oracle RAC Retry Connectivity for Source and Target Connections

When you configure Oracle Data Integrator (ODI) Oracle Real Application Clusters (RAC) connections, Oracle RAC retry is supported for the ODI master or ODI work repository.

ODI uses transactional connections to source and target connections while running ODI scenarios. For these source and target connections, ODI doesn't support RAC retry connectivity. You can't migrate these transactions to another node in Oracle RAC.

Configuring ODI Repository Connections to Oracle RAC

When you create an ODI repository using Repository Creation Utility (RCU), you specify the work repository connection JDBC URL. RCU stores the URL in the master repository contents. If a work repository JDBC URL is a single node URL, Oracle recommends that you modify the URL to include the Oracle Real Application Clusters (Oracle RAC) failover address.

• If Oracle RAC is not configured with Single Client Access Name (SCAN), you can provide details of the Oracle RAC instances. In the work repository JDBC URL field, enter the Oracle RAC connectivity address in the format host:port. See the following example.

• If Oracle RAC is configured with SCAN, provide Oracle RAC instance details with the SCAN address.

The following example shows the JDBC URL format to connect to an Oracle RAC with two hosts when it doesn't use SCAN:

jdbc:oracle:thin:(DESCRIPTION =(LOAD_BALANCE=ON) (ADDRESS =(PROTOCOL =tcp)
(HOST =host1)(PORT =port1)) (ADDRESS =(PROTOCOL =tcp)(HOST =host2)
(PORT =port2)) (CONNECT_DATA =(SERVER=dedicated) 
(SERVICE_NAME=service_name)))

See Creating a Work Repository in Administering Oracle Data Integrator.

About Oracle Data Integrator Scheduler Node Failure

If a WebLogic Server failover occurs, the other WebLogic Server instance becomes the scheduler. A Coherence cache handles the scheduler lifecycle. Locking guarantees the scheduler uniqueness, and event notification provides scheduler migration.

When an agent restarts and computes its schedule, it takes into account schedules in progress, which automatically continue their execution cycle beyond the server startup time. New sessions trigger as if the scheduler never stopped. Stale sessions move to an error state and remain in that state when they restart.

In an Oracle Data Integrator Agent cluster, if the Agent node that is the scheduler node fails, another node in the cluster takes over as the scheduler node. The new scheduler node reinitializes and runs all schedules from that point forward.

If a scheduled scenario with a repeatable execution cycle is running when the node crashes, the scenario doesn't continue its iterations on the new scheduler node from the point at which the scheduler node failed. For example, if a scheduled scenario is configured to repeat the execution 10 times after an interval of two minutes and the scheduler node fails during the third execution, the new scheduler node doesn't continue running the scenario for the next eight executions.

Deploying Oracle Application Development Framework

Review this section for special considerations to deploy Oracle Application Development Framework (ADF).

Note:

For more on ADF, see:

• Oracle ADF Key Concepts in Understanding the Oracle Application Development Framework

• Oracle Fusion Middleware Administering Oracle ADF Applications

• Oracle JRF Asynchronous Web Services (Pinned Service Behavior)
  

Oracle JRF Asynchronous Web Services (Pinned Service Behavior)

When you use Oracle JRF Asynchronous Web Services, the asynchronous web service is pinned to a service and doesn't fail over. When you use a reliability protocol such as WS-RM, the higher-level protocol reconnects to a new server after a failure.

For more on Oracle JRF Asynchronous Web Services, see Oracle JRF and ADF TemplatesOracle JRF Template in Domain Template Reference.

Deploying BI

Keep the following in mind as you deploy Oracle Business Intelligence (BI).

• About BI Session Failover
  If a BI Managed Server and/or host crashes, a user may need to log in again. This depends on which application they are using at the time of the crash and whether or not SSO is in use.
• About BI Essbase
  Essbase doesn't support a high availability configuration. If a server fails, there is no loss of state; you can recover from a failure by redploying Essbase Cube.
• About BI Studio
  Studio doesn't support a high availability configuration. Oracle recommends performing xml import/export on a regular basis. This is the best practice for Studio recovery from a catalog failure.
• About Specifying Ports for Multiple Node Managers
  If you have more than one node manager per machine, verify that you specify your ports.
• About RAC Database Post Installation Configuration
  Oracle BI requires additional configuration steps for whole server migration after installation.
• About Scaling Out BI Publisher
  Completing BI scale out requires tasks in addition to typical scale out steps.

About BI Session Failover

If a BI Managed Server and/or host crashes, a user may need to log in again. This depends on which application they are using at the time of the crash and whether or not SSO is in use.

About BI Essbase

Essbase doesn't support a high availability configuration. If a server fails, there is no loss of state; you can recover from a failure by redploying Essbase Cube.

About BI Studio

Studio doesn't support a high availability configuration. Oracle recommends performing xml import/export on a regular basis. This is the best practice for Studio recovery from a catalog failure.

About Specifying Ports for Multiple Node Managers

If you have more than one node manager per machine, verify that you specify your ports.

See About Node Manager Configuration in a Typical Enterprise Deployment in Oracle Fusion Middleware Enterprise Deployment Guide for Oracle Business Intelligence.

About RAC Database Post Installation Configuration

Oracle BI requires additional configuration steps for whole server migration after installation.

See Using Whole Server Migration and Service Migration in an Enterprise Deployment in Oracle Fusion Middleware Enterprise Deployment Guide for Oracle Business Intelligence for these steps.

About Scaling Out BI Publisher

Completing BI scale out requires tasks in addition to typical scale out steps.

Oracle BI requires additional steps after you follow scale out steps in Scaling Out a Topology (Machine Scale Out). Oracle BI requires you to change setDomainEnv.sh to the updated singleton-data-directory setting (SDD).

To complete Oracle BI scale out:

1. Move the SDD from local to shared storage so that all hosts can access it using the same path. For example, move it to:

   DOMAIN_HOME/bidata/net/yoursystem/scratch/sdd

2. Open DOMAIN_HOME/config/fmwconfig/bienv/core/bi-environment.xml (element bi:singleton-data-directory).
3. Change the xdo.server.config.dir path to refer to the new SDD path you just created.
4. Restart the server.

Deploying Forms

Keep the following in mind as you deploy Forms.

• About Recovering from Forms HTTP Session Failover
  

About Recovering from Forms HTTP Session Failover

If a Forms HTTP session fails, you must reconnect and restart your session with the Forms application.

Deploying Reports

Reports has the certain considerations you need to know about for a high availability set up.

• About Scaling Up in Reports
  If you scale up Reports components, Oracle recommends that you bring down all nodes and then restart them when configuration is complete.
• About Reports Multicast Communication
  Reports cluster members or individual clients use multicast to discover other nodes. There is no workaround to using multicast.
• About Reports Shared-File Based Cache
  Reports has shared file based cache as a singleton. If the cache fails, high availability also fails.
• About Reports Database Service Failure
  Reports components can tolerate database failure. Reports retries the database connection three times. After the database is up, you must run Reports again.
• About Reports OID/Shared Cache File System Failure
  Reports doesn't have retries for OID/Shared cache file system failures. There is no workaround. After the external system is up, you must run Reports again.

About Scaling Up in Reports

If you scale up Reports components, Oracle recommends that you bring down all nodes and then restart them when configuration is complete.

See Starting and Stopping Oracle Reports Server in Oracle Fusion Middleware Publishing Reports to the Web with Oracle Reports Services.

About Reports Multicast Communication

Reports cluster members or individual clients use multicast to discover other nodes. There is no workaround to using multicast.

About Reports Shared-File Based Cache

Reports has shared file based cache as a singleton. If the cache fails, high availability also fails.

There is no workaround. If shared-file based cache fails, you must restart Reports servers.

About Reports Database Service Failure

Reports components can tolerate database failure. Reports retries the database connection three times. After the database is up, you must run Reports again.

About Reports OID/Shared Cache File System Failure

Reports doesn't have retries for OID/Shared cache file system failures. There is no workaround. After the external system is up, you must run Reports again.

Deploying Oracle Business Process Management

Keep the following in mind when you deploy Oracle Business Process Management in a high availability environment.

• About BP Composer and High Availability
  

About BP Composer and High Availability

In a high availability environment, you lose session state in BPM Composer if failover occurs. This causes loss of work; any in-progress edits are lost. BPM Composer is accessible on the secondary server but you must log in again and create a fresh session.