15 Configuring High Availability for Oracle Business Intelligence and EPM

Oracle Business Intelligence is an integrated business intelligence (BI) solution that provides a business user with a complete picture across the entire organization. Oracle Business Intelligence is designed to quickly and easily integrate diverse data sources, find information from the database, share the database information, and exploit the data to learn more about the business and its customers.

Oracle's Enterprise Performance Management (EPM) system integrates a modular suite of performance management applications with comprehensive business intelligence capabilities for reporting and analysis. It increases user productivity, lowers cost of ownership, and reduces business risk.

This chapter provides topics that describe high availability for the following:

Section 15.1, "High Availability for Oracle Business Intelligence Enterprise Edition and Enterprise Performance Management"
Section 15.2, "High Availability for Oracle Business Intelligence Publisher"
Section 15.3, "High Availability for Oracle Real-Time Decisions"

This chapter assumes that you are familiar with Oracle Business Intelligence and EPM. If not, please refer to the Oracle Business Intelligence and EPM documentation.

15.1 High Availability for Oracle Business Intelligence Enterprise Edition and Enterprise Performance Management

This section provides an introduction to Oracle Business Intelligence Enterprise Edition (Oracle BI EE) and Enterprise Performance Management (EPM). This section also describes how to design and deploy a high availability environment for Oracle BI EE and EPM.

Oracle BI EE is part of Oracle Business Intelligence, a comprehensive collection of enterprise BI functionality that provides the full range of BI capabilities including interactive dashboards, full ad hoc, proactive intelligence and alerts, enterprise and financial reporting, real-time predictive intelligence, and more. The Oracle BI EE platform is based on a proven, modern web services-oriented architecture that delivers true next-generation BI capabilities. Oracle BI EE is a robust application that allows you to collect and organize disparate data and present the organized data to users who analyze, interpret, and act upon this content. For additional introductory information about Oracle BI EE, see Oracle Fusion Middleware User's Guide for Oracle Business Intelligence Enterprise Edition

Enterprise Performance Management applications integrate strategy, planning, and execution into a seamless process. Oracle's EPM applications are a modular suite of integrated applications that integrate with both Oracle and non-Oracle transactional systems. You can deploy each application independently to deliver a high degree of value but they work better together, integrating strategic, financial, and operational management processes while delivering a low cost of deployment and ownership.

This section includes the following topics:

Section 15.1.1, "Oracle BI EE Component Architecture"
Section 15.1.2, "Oracle BI EE High Availability Concepts"
Section 15.1.3, "Oracle Essbase Component Architecture"
Section 15.1.4, "Oracle Essbase High Availability Concepts"
Section 15.1.5, "Oracle Hyperion Provider Services Component Architecture"
Section 15.1.6, "Oracle Hyperion Provider Services High Availability Concepts"
Section 15.1.7, "Oracle EPM Workspace Component Architecture"
Section 15.1.8, "Oracle EPM Workspace High Availability Concepts"
Section 15.1.9, "Oracle Hyperion Financial Reporting Component Architecture"
Section 15.1.10, "Oracle Hyperion Financial Reporting High Availability Concepts"
Section 15.1.11, "Allocation Manager Component Architecture and Characteristics"
Section 15.1.12, "Oracle BI EE High Availability Configuration Steps"

15.1.1 Oracle BI EE Component Architecture

Figure 15-1 shows the Oracle BI EE components in a single instance architecture. All communication between Java and system components is via SOAP messages over HTTP.

Figure 15-1 Oracle BI EE Single Instance Architecture

Description of "Figure 15-1 Oracle BI EE Single Instance Architecture"

Note that the port numbers shown in Figure 15-1 are the default port numbers for a simple installation with one component of each component type on a single machine. When you use Oracle Enterprise Manager Fusion Middleware Control to scale out, you can choose a port number range. See Using Fusion Middleware Control to Scale System Components.

15.1.1.1 Oracle BI EE Component Characteristics

The following sections provide more information about the characteristics of the Oracle BI EE components. This information can help you better understand Oracle BI EE high availability requirements.

The following list summarizes the functionality of the Oracle BI EE system components.

Oracle BI Presentation Services (Presentation Services): This is a C++ process that generates the user interface pages and renders result sets on behalf of the Oracle BI Scheduler. You can configure multiple Presentation Services processes, which share the load. No session replication takes place between the Presentation Services processes.

Presentation Services is almost stateless. The only significant state is the client authentication. If Oracle Business Intelligence is configured to use single sign on for authentication purposes, then users do not have to reauthenticate after a failover. For all other authentication schemes, when failover occurs, clients will have to reauthenticate. The client sees an interruption of service and is redirected to a login page.
Oracle Business Intelligence Server (BI Server): This is a C++ process that does the data manipulation and aggregates data from data sources. You can configure multiple BI Server processes, which share the load. No session replication takes place between the BI Server processes.

The BI Server does not maintain user session state. For high availability deployments, query results are cached in the global cache.
JavaHost: This is a Java process that includes resource-intensive graph and PDF rendering. You can configure multiple JavaHost processes, which share the load. No session replication takes place between the JavaHost processes.

The JavaHost is a stateless process.
Cluster Controller: This is a C++ process which manages the population of BI Servers and Oracle BI Schedulers.
Oracle Business Intelligence Scheduler (Oracle BI Scheduler): This is a C++ process that runs jobs according to a timed schedule. Jobs may be agents created in the Oracle BI Presentation Catalog, or jobs created by the job manager.

The following list summarizes the functionality of the Oracle BI EE Java components:

Oracle BI Presentation Services plug-in servlet: Presentation Services runs as a process, not as a Web server, and does not communicate using any Web server plug-in API. The Oracle BI Presentation Services Plug-in forwards HTTP requests to Presentation Services. The HTTP requests are requests from the browser-based user interface, or SOAP requests.
Web services:
- Action execution service: Executes actions on behalf of Presentation Services and Oracle BI Scheduler. Actions may be invocations of third party web services, or invocations of user supplied Java code executed as EJBs.
- Action registry web service: Provides a list of actions.
- Action location service: Provides an indirection level so that actions can be developed in a customer test environment, and then deployed to a production environment without every action definition having to be changed to point to production sources.
- Web services for SOA: Provides a web service interface to the contents of the Oracle BI Presentation Catalog. The tree of objects in the Oracle BI Presentation Catalog is exposed as a tree of web services, defined by a WSIL tree with WSDL leaves.
- Security web service: Provides standards-based authentication and population services.

15.1.1.1.1 Process Lifecycle

OPMN controls each Oracle BI EE system component. To start and stop, use the Oracle Enterprise Manager Fusion Middleware Control Oracle BI EE administration pages.

Each Oracle BI EE Java component is hosted by a managed Oracle WebLogic Server and controlled using the Oracle WebLogic Server Administration Console. Each of the managed Oracle WebLogic Servers is monitored and, if necessary, restarted by the local WebLogic Node Manager.

Note:

See Ensuring That Shared Network Files Are Accessible in Windows Environments if you run OPMN processes using a named user.

15.1.1.1.2 External Dependencies

Oracle BI EE requires the following:

An SMTP mail server
An LDAP provider, such as Oracle Internet Directory
External web services to support actions (configured by the user)

The following clients depend on Oracle BI EE:

ADF Desktop Integration: ADF uses both Presentation Services web services and direct invocation of BI Server via the ODBC/JDBC port. This is the only case where the Oracle BI Server is invoked directly, without going through Presentation Services.
BI Publisher: Uses Presentation Services web services.
BPEL: Uses web services for SOA web services and WSIL browsing servlet.

15.1.1.1.3 Configuration Artifacts

Oracle BI EE provides three different configuration methods:

Central configuration is provided by BI EE pages in Oracle Enterprise Manager Fusion Middleware Control. Using these pages, additional instances can be provisioned, providing high availability and scalability. Key configuration values can also be centrally administered, ensuring that all instances have consistent configuration values.
Configuration of local system components. Local configuration is only required when making advanced configuration changes.
Configuration of local Java components. As with configuration of system components, local configuration is only required for advanced options.

Central Configuration

Oracle BI EE provides a central configuration mechanism, which is exposed in the Enterprise Manager Fusion Middleware Control.

Centrally managed configuration covers:

Changes in the number of components.
Listening port ranges. Ports used by each component are automatically assigned from this range.
Basic SSL configuration: SSL can be enabled for BI EE components using the System MBean browser.
Mail server configuration
Principal tuning options
Location of shared files.

Advanced configuration can be done locally by directly editing the local configuration files. When a central configuration is committed, only the configuration options that are set by central configuration are distributed to the local machines.

Configuration of Local System Components

Each running system component sees a combination of shared and component-specific configuration files. The shared configuration files, such as ClusterConfig.xml, will be under this directory:

ORACLE_INSTANCE/config/OracleBIApplication/coreapplication

The component-specific configuration files will be under:

ORACLE_INSTANCE/config/ComponentType/ComponentInstanceName

For example:

ORACLE_INSTANCE/config/OracleBIPresentationServicesComponent/
coreapplication_obips1

Since each component sees local files, they are not dependent on access to files held centrally on the Administration Server. The centrally managed configuration values are distributed to these local configuration files when central configuration is committed. These centrally managed configuration values are marked in the local files by comments warning the user not to edit them locally. The remaining values are available for local editing.

The rpd file contains references to data sources. Typically development environments use a different database for the fact tables than production environments. When the rpd file moves from a development to production environment, you must use the BI Administration Tool to edit the rpd file and change the data source references.

Local Java Component Configuration

Java components are configured in the WebLogic directory tree at:

DOMAIN_HOME/config/fmwconfig/biinstances/coreapplication

15.1.1.1.4 Deployment Artifacts

In general, Oracle BI EE deploys Java applications in nostage mode. WebLogic Server explodes the .ear file, putting it into a private temp directory. An exception to this is MapViewer, which has configuration requirements which can only be performed in a pre-exploded deployment directory.

All the Managed Server applications (excluding administration applications such as the Enterprise Manager Fusion Middleware Control and central configuration application) deploy to the whole Oracle BI EE cluster, not to individually named systems.

For information on the location of the log files when the Oracle BI EE system components are deployed, see Section 15.1.1.1.5, "Log File Locations."

15.1.1.1.5 Log File Locations

Table 15-1 shows the log files for the Oracle BI EE system components. You can access all of these log files from the Enterprise Manager Fusion Middleware Control.

Table 15-1 Log Files for Oracle BI EE System Components

BI Component	Log File	Log File Directory
OPMN	debug.log	ORACLE_INSTANCE/diagnostics/logs/OPMN/opmn
OPMN	opmn.log	ORACLE_INSTANCE/diagnostics/logs/OPMN/opmn
BI Server	nqserver.log	ORACLE_INSTANCE/diagnostics/logs/OracleBIServerComponent/coreapplication_obis1
BI Cluster Controller	nqcluster.log	ORACLE_INSTANCE/diagnostics/logs/OracleBIClusterControllerComponent/coreapplication_obiccs1
Oracle BI Scheduler	nqscheduler.log	ORACLE_INSTANCE/diagnostics/logs/OracleBISchedulerComponent/coreapplication_obisch1
Presentation Services	sawlog*.log (for example, sawlog0.log)	ORACLE_INSTANCE/diagnostics/logs/OracleBIPresentationServicesComponent/coreapplication_obips1
BI JavaHost	jh.log	ORACLE_INSTANCE/diagnostics/logs/OracleBIJavaHostComponent/coreapplication_objh1

15.1.2 Oracle BI EE High Availability Concepts

This section provides conceptual information about using Oracle BI EE in a high availability deployment.

Requirements for Making Oracle BI EE Highly Available

Oracle BI EE achieves high availability through a combination of process replication and highly available storage (database and shared file system).

To provide a highly available system, Oracle BI EE requires the following external services:

A fault tolerant HTTP load balancer
A highly available shared file system
A highly available database for Oracle BI Scheduler and fact tables

The following system components must be replicated (have at least two instances):

Presentation Services
Cluster Controller
Oracle BI Scheduler
BI Server
JavaHost

The Enterprise Manager Fusion Middleware Control configuration UI will warn the administrator if the system components do not have at least two instances to meet the high availability requirement.

The following persistent data sources must be placed on the highly available shared file system:

RPD publishing directory: The server metadata is contained in the repository file (.rpd file) that is local to each BI Server. One BI Server is designated as a Master. Online changes to the rpd file are made on the Master BI Server, and these changes are replicated to other members of the cluster.
Oracle BI Presentation Catalog
Global cache (optional, but advisable for higher performance). The global cache capability offers support for a common query cache that stores cache seeding and purging events. The global cache is visible to all BI Servers in the cluster.
Scheduler scripts

Also, a WebLogic cluster with at least two members is required to host the Oracle BI EE Java components such as the Oracle BI Presentation Services Plug-in and the authentication service.

15.1.2.1 Oracle BI EE and EPM High Availability Architecture

Figure 15-2 shows a highly available Oracle BI EE and EPM deployment.

Figure 15-2 A Highly Available Oracle BI EE and EPM Deployment

Description of "Figure 15-2 A Highly Available Oracle BI EE and EPM Deployment"

In Figure 15-2, incoming requests are received by the hardware load balancer, which routes them to WEBHOST1 or WEBHOST2 in the web tier. These hosts have Oracle HTTP Server installed.

Oracle WebLogic Server is installed on APPHOST1 and APPHOST2 in the application tier. The Administration Server can be made active on APPHOST2 if APPHOST1 becomes unavailable, as described in Chapter 3, "High Availability for WebLogic Server." The Oracle BI EE, Oracle EPM, and Oracle BI Publisher Java components are deployed on the BI_SERVER1 and BI_SERVER2 managed servers on these hosts (note that Financial Reporting, Provider Services, and Workspace are Oracle EPM components). These managed servers are configured in an Oracle WebLogic cluster that allows them to work in an active-active manner. Whole server migration is configured for the managed servers.

The BI domain uses virtual hostnames as the listen addresses for the BI managed servers. You must enable VIP mapping for each of these hostnames on the two BI Machines, VIP1 on APPHOST1 and VIP2 on APPHOST2, and must correctly resolve the virtual hostnames in the network system that the topology uses (by DNS Server or by hosts resolution). Section 15.1.12.21, "Configuring Server Migration for the BI_SERVERn Servers" provides more details on configuring server migration for the BI servers.

Oracle BI Presentation Services, JavaHost, Oracle BI Cluster Controller, Oracle BI Scheduler, and Oracle BI Server are system components installed on APPHOST1 and APPHOST2 and configured as a cluster. The Cluster Controller and Scheduler on APPHOST2 are passive (they are started but do not service requests) and are made active only if APPHOST1 components fail.

In the data tier, shared external storage is set up to store Catalog, query cache, RPD, and Scheduler script data. An Oracle RAC database is used to store the BI EE schema metadata, BI Publisher repository data, and is also recommended for the enterprise database.

The following subsections provide high availability information for several of the Oracle BI EE components.

15.1.2.1.1 Web Server High Availability Considerations

The Oracle BI Presentation Services Plug-in is the initial point of contact for any HTTP client, such as the browser user interface. This may in turn be fronted by an Oracle HTTP Server or other supported Web server. You must replicate this HTTP stack to avoid a single point of failure. To avoid presenting multiple HTTP URLs to users, set up an external load balancer, which routes user requests to one of the replicated Oracle BI EE URLs.

If internal HTTP requests route directly to the local WebLogic Managed Server, there is a reduced degree of high availability. If the WebLogic instance fails, Node Manager will restart it. WebLogic restart may take several minutes. During this period, the local security service is unavailable, preventing login. Contrast this with the recommended configuration, where the internal HTTP requests are routed through the load balancer. The alternative security service is quickly available.

15.1.2.1.2 Oracle BI Presentation Services Plug-in High Availability Considerations

The Oracle BI Presentation Services Plug-in is deployed as the analytics .ear application. It routes session requests to Presentation Services instances using a native RPC protocol over TCP. It also performs load balancing between the multiple Presentation Services instances, with session affinity maintained in general through a session cookie or URL argument. Presentation Services and the Plug-in run as separate processes.

Each Oracle BI Presentation Services Plug-in instance is entirely independent - there is no communication between Oracle BI Presentation Services Plug-in instances. Each makes its own decision on load balancing based on its experience of response times and number of outstanding requests.

It is recommended to configure session affinity on the load balancer.

The Oracle BI Presentation Services Plug-in is one of the Oracle Business Intelligence Java components and is scaled for high availability when you add additional Managed Servers to the deployment.

15.1.2.1.3 Presentation Services High Availability Considerations

Presentation Services receives requests from the Oracle BI Presentation Services Plug-in on a port assigned from the port range defined in the Scalability tab of the Capacity Management page in Fusion Middleware Control. Although an initial user session request can go to any Presentation Services instance in the cluster, each user is then bound to a specific Presentation Services instance.

To process user requests, Presentation Services must communicate with the BI Servers. In a clustered environment, the first point of contact to the BI Servers is through the Cluster Controller. Presentation Services uses the Oracle BI ODBC data source that is configured for the clustered environment to identify the primary and secondary Cluster Controllers and the ports on which they listen. The centralized BI domain configuration file configures automatically connection parameters in the ODBC Data Source Name (DSN) when centralized configuration is changed. Do not modify the Oracle BI ODBC DSN connection parameters locally.

Cluster Controller assigns the Oracle BI Server instance that Presentation Services connects to. The connection to the Oracle BI Server establishes over ODBC, and subsequent requests in the same session go directly from Presentation Services to the assigned Oracle BI Server. The ODBC session between Presentation Services and the Oracle BI Server is stateful and must maintain affinity for the session lifetime.

To communicate with Oracle BI Scheduler, Presentation Services first contacts the Cluster Controller, which relays the active Oracle BI Scheduler instance. Presentation Services then establishes a session with the appropriate Oracle BI Scheduler instance. the Availability tab of the Capacity Management page in Fusion Middleware Control specifies the host and Oracle instance names for the Cluster Controllers and Oracle BI Scheduler.

15.1.2.1.4 BI Cluster Controller High Availability Considerations

The Cluster Controller is the first point of contact for a new BI Server or Oracle BI Scheduler session from Presentation Services and other clients. The Cluster Controller deploys in active-passive configuration:

Primary Cluster Controller: The active cluster controller.
Secondary Cluster Controller: Assumes the role of active Cluster Controller if the Primary Cluster Controller is unavailable.

By default, the first Cluster Controller that you configure in your Oracle Business Intelligence installation is the primary Cluster Controller.

The Cluster Controller determines which Oracle BI Server in the cluster should receive incoming requests based on Oracle BI Server availability and load. It also monitors the server operation in the cluster, including the Oracle BI Scheduler instances.

The Cluster Controller supports:

Detection of server and Oracle BI Scheduler failures.
Failover for ODBC clients if their servers fail.

The Cluster Controller also determines the active Oracle BI Scheduler instance at run time. Note that Cluster Controller does not control Presentation Services instances.

It is important to avoid a split brain configuration, where both Cluster Controllers consider themselves to be active. To avoid a split brain configuration, do not configure Cluster Controllers on separate LANs connected across a potentially unreliable WAN. Fault tolerance against site failures should use the disaster recovery mechanisms, not the clustering mechanisms.

15.1.2.1.5 BI Server High Availability Considerations

You can install and configure multiple BI Servers to create a BI Server cluster. The Cluster Controller dispatches requests from clients such as Presentation Services to an active member of this cluster. BI Servers listen for client requests on a port assigned from the port range that is defined in the Scalability tab of the Capacity Management page in Fusion Middleware Control.

Note:

You must synchronize the clock on each server participating in a cluster. Unsynchronized clocks can skew reporting.

The Master BI Server is the server that the Oracle BI Administration Tool connects to in order to perform online metadata changes in the RPD file. The metadata changes then propagate out to the other servers when they restart. You can view which Oracle BI Server is the master using the Cluster Manager in the Administration Tool.

Communication from BI Server to Databases

BI Server supports communication with many database types, including Oracle databases. The BI Server data repositories hold the raw fact tables. Oracle BI EE does not use the BI Server data repositories to store metadata; the RPD file or the Oracle BI Presentation Catalog (for Presentation Services) stores all metadata.

The Oracle BI Scheduler stores data in the Oracle BI Scheduler schema. Since the Oracle BI Scheduler database connection configuration uses the same libraries as BI Server, the fault tolerance characteristics are the same. The only difference is that the Oracle BI Scheduler interaction is much more write intensive. BI Server data sources are primarily read-only.

The main points of BI Server interaction with the database are:

Source database: Source databases are used for Oracle BI EE reporting. They are primarily read-only. There are many supported options for source databases.
Event polling: Keeps track of cache removal or creation from the file system.
Usage tracking
Write back facility: A user-driven capability.

The implementation provides the following characteristics:

All database read/write operations are performed by C++ code.
For Oracle databases, OCI is used. For other databases or data sources, native database capabilities are used.
Oracle and non-Oracle database support is possible for not just the Source database, but also for Oracle BI Scheduler.

15.1.2.1.6 Administration Tool High Availability Considerations

The Administration Tool uses the same Oracle BI ODBC DSN that Presentation Services uses. It is directed to the Master BI Server by the Cluster Controller. If the Master BI Server is unavailable, the Administration Tool cannot perform RPD file writes.

15.1.2.1.7 Oracle BI Scheduler High Availability Considerations

The Oracle BI Scheduler instances operate on an active-passive model. Only one Oracle BI Scheduler is active and processing requests at any one time to ensure that it allocates unique job ids to new jobs. The inactive Oracle BI Scheduler instance remains idle and does not process jobs until called on to take over if an active Oracle BI Scheduler fails.

Do not configure multiple Oracle BI installations to use the same scheduler tables. Doing so creates multiple active Oracle BI Schedulers, breaking the unique job ID constraint.

The Oracle BI Scheduler uses the same database technology as the BI Server.

If Oracle BI Scheduler is up and the database is down, Oracle BI Scheduler queues up failed transactions in its memory and retries them until they are successful. Therefore, if you shut down a back-end database source for maintenance you do not need to restart Oracle BI EE processes when you restart the database. The processes are retried on the same count as the periodic purge in the Oracle BI Scheduler, and therefore use the same configuration values. Oracle BI EE only retries statements that are required to be in Oracle BI EE metadata. Oracle BI EE does not retry queries, only inserts and deletes (except for deletes that would be reexecuted). Configuration values are in the instanceconfig.xml file for Oracle BI Scheduler (PurgeIntervalMinutes).

The Oracle BI Scheduler listens for Cluster Controller communication and for client requests on ports assigned from the port range defined in the Scalability tab of the Capacity Management page in Fusion Middleware Control.

15.1.2.1.8 BI JavaHost High Availability Considerations

The Oracle BI JavaHost component provides services that enable Oracle BI Presentation Services to support various components such as Java tasks for Oracle BI Scheduler, Oracle BI Publisher, and graph generation. As with all other components, the administrator can use Fusion Middleware Control to control how many instances are deployed and where. The default configuration of JavaHost clients is to use all available JavaHosts; this differs from the previous 10g default of only using the local JavaHost.

The JavaHost service receives requests from Presentation Services and Oracle BI Scheduler on a port that is assigned from the port range that is defined in the Scalability tab of the Capacity Management page in Fusion Middleware Control.

15.1.2.2 Shared Files and Directories

In Oracle BI EE, process state is shared through shared file systems and databases rather than through distributed communication protocols. In particular, Oracle BI EE does not store state internal to processes or Java components. Therefore, Oracle BI EE does not need to serialize component state so it can be distributed within a Java cluster.

The fact tables and Oracle BI Scheduler tables are shared between BI Server and Oracle BI Scheduler instances, respectively. File system sharing is less standard, as the end of this section describes. You can use a shared storage device such as NAS or SAN.

15.1.2.2.1 Oracle BI Presentation Catalog Shared Files

The Presentation Services instances in a cluster share a common Oracle BI Presentation Catalog. The Oracle BI Presentation Catalog should be placed on a shared NAS or SAN device. All instances of Presentation Services must have read and write access to the shared device. Concurrent access is managed by the file system locking semantics.

Because the Oracle BI Presentation Catalog consists of a large number of heavily accessed small files, be aware that in some cases the number of files may exceed the file limits for shared file systems. Refer to the documentation for your shared file system for information on setting the file limits for your system.

15.1.2.2.2 Repository Publishing Directory Shared Files

All BI Servers participating in a cluster share the repository publishing directory, which holds the master copies of repositories edited in online mode. The Master BI Server must have read and write access to this directory; all other BI Servers must have read access.

The clustered BI Servers examine this directory on startup for any repository changes. On startup, a BI Server instance copies the repository in the publishing directory to its local repository directory, for example:

ORACLE_INSTANCE/bifoundation/OracleBIServerComponent/coreapplication_obis1/repository

Because this copy occurs only at restart, a cluster with a writable rpd file may show inconsistent behavior (for example, metadata does not match requests from analyses) until all the BI Server instances restart. Metadata changes are normally made offline in a development environment with a read only rpd file in the production environment.

In Fusion Middleware Control, the Shared Location parameter on the Repository tab of the Deployment page specifies the repository publishing directory location.

15.1.2.2.3 Global Cache Shared Files

The global cache is shared by all BI Servers participating in a cluster. It resides on a shared file system storage device and stores purging events, seeding events (often generated by agents), and result sets associated with seeding events. Each Oracle BI Server maintains its own local query cache for regular queries.

Shared files requirements for the global cache are:

All BI Servers must have read and write access to the global cache directory.
The global cache parameters are configured in the NQSConfig.INI file for each BI Server node participating in the cluster. The global cache is controlled centrally via Fusion Middleware Control.
The BI Server maintains a query cache, a local, disk-based cache of query result sets. The query cache allows a BI Server to potentially meet many query requests without accessing back-end databases, dramatically decreasing query response time. Query cache entries become obsolete as updates occur on the back-end databases and must purge periodically. For more information on the query cache, refer to the Oracle Fusion Middleware System Administrator's Guide for Oracle Business Intelligence Enterprise Edition.

15.1.2.2.4 Oracle BI Scheduler Scripts Shared Files

You must create a network share for the Oracle BI Scheduler scripts. To create a network share, update the SchedulerScriptPath and DefaultScriptPath elements of the Oracle BI Scheduler instanceconfig.xml file (located in ORACLE_INSTANCE/config/OracleBISchedulerComponent/coreapplication_obischn). The Oracle BI Scheduler servers must have read and write access to this share.

15.1.2.3 Starting and Stopping the Cluster

Because there are dependencies between the processes, you must start a cluster in a particular order. The startup sequence is:

Start all of the WebLogic Managed Servers. The system components look to their local Managed Server for the authentication service.
Start other processes using the Start All button in Fusion Middleware Control. Using the Start All button ensures that the Java applications and the system components start in the correct startup order.

15.1.2.4 Cluster-Wide Configuration Changes

Configuration changes, especially changes to the population of the cluster, are critical for high availability. Without the ability to add new members to a cluster, a failure cannot be repaired, leaving the cluster vulnerable to a subsequent failure (this is why mean time to repair is just as important in a high availability system as mean time between individual failures).

The two technology stacks, Java and system, are managed separately.

WebLogic configuration changes are made in the WebLogic Administration Console. Standard WebLogic mechanisms are used to lock configuration while it is being changed, and to propagate the changes to all Managed Servers.

System component configuration changes are made centrally using Fusion Middleware Control. After you enter configuration changes and click Save, the configuration changes propagate to all local configuration files. This propagation is important; if the configuration is corrupt or propagation fails, the next propagation corrects the local files. An Oracle JMX extension performs file distribution similar to the WebLogic config file distribution. Delivery at the remote site is announced by a JMX MBean call. Since MBeans must be hosted in an MBean server, this means that every machine which hosts Oracle BI EE system components must also have a WebLogic Managed Server even if that machine does not host any Java Oracle BI EE components.

All components access configuration changes at their next restart only; there is no online configuration reload mechanism.

Configuration changes are triggered by:

An administrator committing changes made in the Fusion Middleware Control.
An administrator committing changes made by the MBeans API (which directly mirrors the Fusion Middleware Control user interface).

An enterprise installation that registers a new installation does not trigger a configuration push. This changes the population of machines which the administrator may pick from in the Fusion Middleware Control - new component instances are not automatically added to the configuration.

15.1.2.5 Protection From Failures and Expected Behaviors

This section describes different types of failures that can occur and the expected behavior when each type of failure occurs.

15.1.2.5.1 Machine Failure

If a machine suffers a transient failure, the cluster detects the restarted components and starts using them again. If a machine fails permanently, you must replace it. Install Oracle BI EE on the new machine using an enterprise install to extend the existing cluster.

For information about recovering from Oracle BI EE machine failures, refer to the section on recovering Oracle BI EE to a different host in Oracle Fusion Middleware Administrator's Guide.

15.1.2.5.2 WebLogic Administration Server Failure

The WebLogic Administration Server is a singleton and only one instance can be up and running at any given time. For information on protecting the WebLogic Administration Server, see Chapter 12, "Active-Passive Topologies for Oracle Fusion Middleware High Availability." In Oracle BI EE, the WebLogic Administration Server is used only for administrative tasks.

While the WebLogic Administration Server is down, you cannot reconfigure Oracle BI EE or use Fusion Middleware Control to look at log files.

15.1.2.5.3 WebLogic Managed Server Failure

The WebLogic Node Manager detects failure of Managed Servers. Because all Java components are stateless, Oracle BI EE does not take Java cluster state maintenance into consideration.

All communications from system components to Managed Servers, for example, from Presentation Services to action services, use HTTP to the local Managed Server. If the local Managed Server fails, the Node Manager should restart it.

The following lists the effect on system components running on the same machine if the Managed Server cannot restart but the machine does not fail:

BI Server: Taken out of service until the local Managed Server works to ensure that login (done through the BI Server) is not affected. When the BI Server detects that the local Managed Server is not running, it directs the Cluster Controller to send login requests to other BI Servers.
Presentation Services: Unable to execute actions.
Oracle BI Scheduler: Scheduled action executions fail if the active scheduler runs on this machine.

New Scheduler connections (for example, from Job Manager) will fail. The Oracle BI Scheduler on a host where the local Managed Server is not running is unable to authenticate new users.

If you must take a Managed Server offline, first stop all system components running on the machine. If the Managed Server on a particular machine becomes unavailable, stop all system components running on that machine.

15.1.2.5.4 Oracle BI Scheduler Failure

The Cluster Controller monitors and manages the Oracle BI Scheduler. If the Oracle BI Scheduler is unavailable, the Cluster Controller determines the next Oracle BI Scheduler instance to activate. If the previous primary Oracle BI Scheduler becomes available again, the primary role doesn't revert to it.

When the active Oracle BI Scheduler fails, any open client connections do not receive an error because the Oracle BI Scheduler protocol is stateless and seamlessly fails over.

Agents: Agent executions maintain state in the Oracle BI Scheduler tables. When the next instance of Oracle BI Scheduler becomes active, it reads the state of all job instances that were in progress, and executes them. A scheduled agent only delivers to those recipients that it did not deliver to before the failure of the active instance.

Successful delivery is recorded in the Oracle BI Scheduler tables after completion of the delivery. If Oracle BI Scheduler fails over after delivery is complete, but before recording that fact, then the delivery is repeated. Because of this, a small number of repeat deliveries are possible.

Note that Agent failover is only supported for agents that are scheduled. For example, if you click Run Agent Now on the toolbar in Answers, and then the primary Oracle BI Scheduler fails, that Agent will not continue to run on the Secondary Scheduler and an error message will be displayed in the Run Now results dialog box.
Java, Command Line, or Script Job: The jobs are re-executed from the beginning with a new job instance.

Note:

Any job instance can be manually rerun from the Job Manager. For an agent, this only delivers to those users that did not have successful deliveries. For example, if the mail server goes down halfway through an agent's execution, the rerun of the instance delivers only to those recipients who did not receive e-mail due to the mail server crash.

15.1.2.5.5 Cluster Controller Failure

The Cluster Controller supports detection of BI Server or Oracle BI Scheduler failures and failover for clients of failed servers.

The Cluster Controller works on an active-passive model. All clients first attempt to connect to the primary Cluster Controller. If the primary Cluster Controller is unavailable, clients then connect to the secondary Cluster Controller. The secondary Cluster Controller then directs requests to BI Servers based on load and availability, and to the active Oracle BI Scheduler instance. If the primary later becomes available, then all requests go to the primary again.

The secondary Cluster Controller monitors the session count on each BI Server (just like the primary), but the secondary Cluster Controller does not determine which Oracle BI Scheduler is the active Scheduler unless the primary Cluster Controller is down.

The primary and secondary Cluster Controllers monitor each other's life cycle. A Split-Brain failure can occur if communication is down between the Cluster Controller instances but each is up and can communicate with other clients. In these cases, BI Servers are not affected but the Oracle BI Scheduler may have two active instances at once. In rare cases, this situation can lead to double execution of jobs. When the line of communication comes back up, the primary Cluster Controller dictates to the cluster that only one Oracle BI Scheduler should be active. The Cluster component must reside on the same LAN, minimizing the possibility of a Split-Brain failure.

If both Cluster Controllers are unavailable, Presentation Services returns an error to any new user attempting to login. Existing sessions are not affected.

Cluster Controllers track the number of active sessions on each BI Server instance. When new ODBC connections are made, the Cluster Controller allocates the new session to keep the sessions for each BI Server in balance. If a BI Server instance goes down temporarily and comes back up, then all new ODBC sessions route to this node until its session count matches that of the others in the cluster.

When a Cluster Controller fails, the first person who tries to create a new session sees a delay of about six seconds as the secondary Cluster Controller picks up sessions. All other connections are then routed to the secondary Cluster Controller.

15.1.2.5.6 Presentation Services Failure

A Presentation Services failure affects:

Web clients: Although an initial user session request can go to any Presentation Services instance, each user is then bound to a specific Presentation Services instance. Loss of that Presentation Services instance disconnects the session, and an error is relayed back to the browser. Any work in progress during the loss of the server that was not saved to disk is lost. The user must log in again to establish a new connection to an available Presentation Services instance. If user login is taking place using a Single Sign-On system such as Oracle Single Sign-On, then this relogin occurs automatically. The new Presentation Services session will create a new BI Server session.

Note:
When a Presentation Services instance fails, there is a small interval of time before the system recognizes that the instance has failed and before users are migrated to a new Presentation Services instance. If a single sign-on solution is being used, then there is no need for users to reauthenticate. If single sign-on is not being used, then users must reauthenticate.
Agents: An error is relayed to the Oracle BI Scheduler, which logs the failure and then retries the job. The retry establishes a new connection to an available Presentation Services.

15.1.2.5.7 BI Server Failure

When a BI Server failure occurs, an ODBC error goes to the appropriate client:

Presentation Services: Each Web user has requests that one BI Server serves. If the BI Server is unavailable, the user might see an error. However, a browser refresh makes a new session establish with an available BI Server. Note that the Presentation Services component performs this arbitration on behalf of its users.
Administration Tool: The Administration Tool relays the ODBC error when the BI Server that it connects to becomes unavailable, and then closes the connection. The administrator must use the Administration Tool to reconnect.
Agents: When BI Server failure occurs, the error relays to the Oracle BI Scheduler, which logs the failure and retries the job. A connection then establishes with an available BI Server.
Third-party clients: Third-party clients use ODBC to connect the BI Server. When BI Server failure occurs, ODBC relays the failure and the session closes and reopens according to the ODBC standard.
Master BI Server failure: If the Master BI Server is unavailable, online metadata changes cannot be performed. This is an administration operation; it does not affect run-time availability.

If the Master BI Server is permanently unavailable, you must appoint one of the other servers as the new master:
- Scale in the Master BI Server using the Scalability tab of the Capacity Management page in Fusion Middleware Control.
- Restart the Oracle BI EE system components.
  
  The system assigns a new Master BI Server.

15.1.2.5.8 Troubleshooting Oracle BI EE

Recovery issues typically involve failure to start a process. The suggested troubleshooting sequence is:

Check Fusion Middleware Control to see which processes are running. This reflects the state reported by OPMN.
Check the OPMN log files. They can be accessed from Fusion Middleware Control. They can also be accessed in the locations specified in Table 15-1.
When a failed process is identified, check its log file, which can be accessed from Fusion Middleware Control or in the locations specified in Table 15-1.

Certain processes shut down if they cannot communicate with their peers. To diagnose this problem:

Identify the failed process. Find the low-level socket error in the log file, which identifies the port and server address. Check in the local configuration files to see which process is configured to listen on that port. Simple deployments use the default port allocations, as the component descriptions in the subsections of Section 15.1.2.1, "Oracle BI EE and EPM High Availability Architecture" describe. You can see the ports that are currently configured in the Availability tab of the Capacity Management page in Fusion Middleware Control.
Check to see if the peer is running. If the peer is running, check its log file for an entry rejecting the communication. This can happen if SSL configuration is inconsistent or if there is a protocol failure.

Cluster Controller managed processes will fail if their configuration fails to match the Cluster Controller. While some failover events are not logged, the Cluster Controller log file records crashes of any Oracle BI Scheduler or BI Server instances.

Review the log files after initial start up. If a BI Server or Oracle BI Scheduler instance has not been configured correctly and as expected by the Cluster Controller, then the instance, though it may not shut down, will not be added to the cluster. The log files will record such failures.

15.1.3 Oracle Essbase Component Architecture

Figure 15-3 shows the Oracle Essbase single instance architecture.

Figure 15-3 Oracle Essbase Single Instance Architecture

Description of "Figure 15-3 Oracle Essbase Single Instance Architecture"

15.1.3.1 Oracle Essbase Component Characteristics

Essbase component architecture comprises four tiers:

Web: Oracle HTTP Server
Application: Oracle Hyperion Provider Services, a mid-tier enterprise application deployed on a WebLogic application server

Provider Services communicates with Essbase Agent and Essbase Servers using TCP/IP.
Essbase Service: Essbase Analytical Services, comprising OPMN, Essbase Agent, and Essbase application servers

OPMN communicates with Essbase Agent using Oracle Net Services. Essbase Agent acts as a coordinator between clients and Essbase application servers. Essbase Agent has a pipe communication channel with the servers. It also communicates using TCP/IP.
Storage: The Hyperion Registry is a repository that stores configuration information in a relational database. Essbase Agent and Essbase application servers communicate with the back-end database using JDBC or ODBC.

15.1.3.1.1 State Information

The Oracle Essbase session state is in memory, and there is no session failover. If a client session is lost, the client must log on again.

15.1.3.1.2 Runtime Processes

Essbase Analytical Services comprises these processes at runtime:

Oracle Process Manager and Notification Server (OPMN): A daemon that monitors Oracle Fusion Middleware components, including Essbase

OPMN-managed components are specified in opmn.xml.

You can use a command-line interface to OPMN to start, stop, restart, and monitor Essbase Agent; see Section 15.1.1.1.1, "Process Lifecycle." It does not start or stop the Essbase Application Server process directly. OPMN communicates with Essbase Agent using Oracle Net Services.
Essbase Agent (ESSBASE): The process responsible for coordinating user requests for applications.

Essbase Agent is directly managed by OPMN. Essbase Agent manages application servers.
Essbase Application Server (ESSSVR): The Essbase Application Server process handles all the data storage, caching, calculations, and data security.

15.1.3.1.3 Process Lifecycle

Use the OPMN command opmnctl to start, stop, and monitor Essbase Agent.

Start

To start OPMN and all its managed components, use $ORACLE_INSTANCE/bin/opmnctl startall.

To start Essbase Agent only, with OPMN already running, use $ORACLE_INSTANCE/bin/opmnctl startproc ias-component=essbaseserver1, where essbaseserver1 is the name of the managed Essbase instance specified in opmn.xml.

Stop

To stop OPMN and all its managed components, use $ORACLE_INSTANCE/bin/opmnctl stopall.

To stop Essbase Agent only if Essbase is configured in failover cluster mode and OPMN is already running, use $ORACLE_INSTANCE/bin/opmnctl stopproc ias-component=essbaseserver1 process-type=Essbase, where essbaseserver1 is the name of the managed Oracle Essbase instance specified in opmn.xml.

Monitor

To get status information about the managed process, use $ORACLE_INSTANCE/bin/opmnctl status.

15.1.3.1.4 Request Flow

Communication with Essbase can be through a cluster name (resolved by Provider Services), a URL (resolved by the application), or a physical host and port.

15.1.3.1.5 External Dependencies

Essbase uses Hyperion Registry, a database repository, to store and retrieve configuration information.

You can configure Essbase to work with an external directory service such as the Oracle Internet Directory (OID). Essbase communicates with OID using LDAP protocol.

15.1.3.1.6 Configuration Artifacts

The following table describes Essbase configuration artifacts.

Table 15-2 Essbase Configuration Artifacts

File	Location	Description
Essbase configuration file, `essbase.cfg`	`$ARBORPATH/bin`	Contains configurable parameter values for Essbase.
The Essbase security file, `essbase.sec`	`$ARBORPATH/bin`	Contains information on security and applications
OPMN configuration file, `opmn.xml`	`$ORACLE_INSTANCE/config/OPMN/opmn`	Lists all the managed components and the environment variables to be passed to each managed component.

15.1.3.1.7 Deployment Artifacts

Deployment artifacts required for correct setup of Essbase include JDBC and ODBC, reg.properties, security artifacts, and so forth. Deployment artifacts must be passed to OPMN, which can then provision Essbase.

15.1.3.1.8 Log Files

Diagnostic log files reside, by default, under $ORACLE_INSTANCE/diagnostics.

Essbase Agent writes messages to Essbase.log:

Default location: $ORACLE_INSTANCE/diagnostics/logs/Essbase/<name of the Essbase instance>/essbase
Configured location: $HYPERION_LOGHOME/essbase

Essbase application server writes messages to application server log files:

Default location: $ORACLE_INSTANCE/diagnostics/logs/Essbase/<name of the Essbase instance>
Configured location: $HYPERION_LOGHOME/essbase/app

OPMN creates the Essbase console log, located by default in $ORACLE_INSTANCE/diagnostics/logs/Essbase/<name of Essbase instance>.

The Essbase Forward Ping log, EssbasePing.log, is located by default in $ORACLE_INSTANCE/diagnostics/logs/OPMN/opmn.

Lease manager logs are created only in a failover configuration. (See Section 15.1.4.2, "Protection from Failures and Expected Behaviors.") The lease manager modules within Essbase Agent and Essbase Server write messages to their own logs:

Default location: $ORACLE_INSTANCE/diagnostics/logs/Essbase/<ias component name>/essbase
Configured location: $HYPERION_LOGHOME/essbase

15.1.4 Oracle Essbase High Availability Concepts

This section provides conceptual information about using Essbase in a high availability environment.

15.1.4.1 Oracle Essbase High Availability Architecture

Figure 15-2 shows Essbase in a highly available Oracle BI EE deployment.

15.1.4.1.1 Shared Files and Directories

ARBORPATH, which includes configuration files, security files, and all applications and corresponding databases, is on a shared disk. Instance-specific files, binaries, and log files are on a local disk by default but can be shared. For example, you could put log files on a shared disk by changing a configuration setting in opmn.xml.

15.1.4.1.2 Cluster-Wide Configuration Changes

Shared configuration information is in essbase.cfg, which is on a shared disk. For example, changes in timeout settings for lease acquisition or renewal are made in essbase.cfg on the shared disk.

15.1.4.2 Protection from Failures and Expected Behaviors

For failover, you can configure Essbase in a two-node cluster.

Included in a failover cluster setup:

Two nodes

One node is active at all times and one node is passive.
A shared disk between the nodes

The shared disk stores applications, databases, product configuration, and everything that is placed under $ARBORPATH.
Product binaries and others in $ESSBASEPATH

Each node can have the binaries on a direct attached storage disk.
Registry and lease databases

These databases, which are critical, must be on redundant storage devices.

A leasing mechanism ensures that one and only one Essbase Agent and its set of application servers are active. One and only one lease must be active on a resource at any time; the owner of the active lease has ownership rights to the resource. This leasing scheme is implemented using the lease tables in the database. The lease tables are seeded by Repository Configuration Utility (RCU).

To exploit failover functionality, Java API clients must log on using APS Servlet endpoint URL. The URL would specify the cluster name of the failover cluster; for example, http://WEBHOST1:7777/aps/Essbase?clusterName=cludemo

Provider Services resolves the cluster name to the host name and port of the active node in the cluster.

Session failover is not supported. If service failover occurs, the client receives an error message and must log on again.

15.1.4.3 Troubleshooting

To troubleshoot Essbase failover, check OPMN and Essbase logs to determine event sequence. For example, the logs might show that OPMN starts Essbase but Essbase does not acquire a lease because of database authentication failure.

15.1.5 Oracle Hyperion Provider Services Component Architecture

Oracle Hyperion Provider Services (Provider Services) is a middle-tier data-source provider to Oracle Essbase for Java API, Oracle Hyperion Smart View for Office, Fusion Edition, and XMLA clients and to Oracle Business Intelligence Enterprise Edition. Provider Services supports highly concurrent analytical scenarios and provides scalability and reliability in a distributed Web-enabled enterprise environment.

Figure 15-4 shows the Provider Services single instance architecture.

Figure 15-4 Provider Services Single Instance Architecture

Description of "Figure 15-4 Provider Services Single Instance Architecture"

Provider Services contains three subcomponents: Essbase Java API, SmartView Provider, and an XMLA (XML for Analysis) provider. These subcomponents service Java API clients, SmartView clients, and XMLA clients, respectively. Provider Services is designed with three different servlets, one for each subcomponent.

Communication between clients and Provider Services is over the HTTP(S) protocol. The JAPI and XMLA clients are designed for Essbase communication. The Smart View client enables users to connect to data sources such as Essbase, Oracle Hyperion Planning, Fusion Edition and Oracle BI EE servers.

15.1.5.1 Oracle Hyperion Provider Services Component Characteristics

The following sections describe Prover Services Component characteristics.

15.1.5.1.1 State Information

Provider Services session information is stored in memory until the user disconnects or the session times-out.

15.1.5.1.2 Runtime Processes

Provider Services is a Java-based enterprise application deployed on the WebLogic server application container. At runtime, there is a single Java process, which is the container. Provider Services runs no other external processes.

15.1.5.1.3 Process Lifecycle

The lifecycle of the Provider Services process is the same as the process lifecycle for any standard Java- based enterprise application deployed on a WebLogic server.

15.1.5.1.4 Request Flow

A dispatcher such as Oracle HTTP Web Server acts as a gateway, delivering requests to the Provider Services instances that are part of the cluster. Provider Services supports sticky sessions, so that when a user session establishes with a Provider Services instance, the same instance handles all subsequent requests from the client until the user disconnects. If a Provider Services instance fails, the user must disconnect the existing invalid session and log on again, using the same URL (the dispatcher URL) as for the failed session.

15.1.5.1.5 External Dependencies

Provider Services is dependent on Hyperion Registry. The SmartView Provider component stores the Data Sources (datasources.xml) and Smart Slices in the registry database using Registry Java APIs. The Essbase Java API component also uses the Hyperion registry for maintaining domain-related (domain.db file) information. All of this information is stored under the Registry's LOGICAL_WEB_APP component of Provider Services.

15.1.5.1.6 Configuration Artifacts

Provider Services has a configuration file, essbase.properties, which resides in $ORACLE_HOME/products/Essbase/aps/bin. The Provider Services startup script requires the following JVM setting ESS_ES_HOME so that it can identify the configuration file at runtime. This setting specifies the PROVIDER_SERVICES_HOME folder, in which the bin/essbase.properties file resides.

15.1.5.1.7 Deployment Artifacts

Provider Services deployment artifacts include these files:

logging.xml: Configuration file for managing Provider Services logs
essbase.properties: Provider Services configuration file
aps.ear: Provider Services enterprise application archive

15.1.5.1.8 Log Files

Provider Services logging is based on ODL logger. The Provider Services startup script requires these JVM settings related to logging:

oracle.core.ojdl.logging.config.file: To specify the ODL logging.xml file path for Provider Services.
logging.folder: The location to store the Provider Services server log files.

Note:

In a cluster including several Provider Services instances, a separate unique log location is defined for each instance. If the log location for an instance is under a Provider Services home, the administrator must grant read and write permissions to that folder for all Provider Services instances.

15.1.6 Oracle Hyperion Provider Services High Availability Concepts

Provider Services deploys and runs within an application server environment such as Oracle WebLogic Server. To support Provider Services high availability, you can deploy multiple instances of Provider Services, using the WebLogic Server clustering and load balancing capabilities. For details on clustering enterprise applications such as Provider Services, see the WebLogic Server documentation.

15.1.6.1 Oracle Hyperion Provider Services High Availability Architecture

Figure 15-2 shows Oracle Hyperion Provider Services in a highly available Oracle BI EE deployment.

15.1.6.1.1 Hyperion Registry Structure for a Provider Services Cluster

In the preceding figure, LOGICAL_WEB_APP represents a cluster consisting of Provider Services instances. Each PROVIDER_SERVICES_WEB_APP component stores the actual server and port of its Provider Services instance; for example:

LOGICAL_WEB_APPCluster_URL

----- PROVIDER_SERVICES_WEB_APP 1 server1:port

----- PROVIDER_SERVICES_WEB_APP 2

----- PROVIDER_SERVICES_WEB_APP 2 server2:port_y

The LOGICAL_WEB_APP component information specifies the Provider Services cluster URL, which is unique.

15.1.6.1.2 Cluster-Wide Configuration Changes

Provider Services reads the essbase.properties file only during startup. If the Provider Services administrator changes this file, the administrator must restart the Provider Services cluster so that all Provider Services instances in the cluster are synchronized with configuration settings.

15.1.6.1.3 OPMN Essbase Cluster Support

To support Essbase clusters, clients communicate with Provider Services to fetch the active Essbase node in the cluster. API clients (CAPI/JAPI) must specify an Provider Services URL (which contains the OPMN Essbase cluster name) to obtain the active Essbase host instance details. Provider Services then retrieves the active Essbase node details from the Hyperion Registry. The remainder of this section describes the behavior for Provider Services and C/JAPI client use cases.

15.1.6.1.4 Essbase Database Clustering by Provider Services

Provider Services supports high availability of Essbase databases with active-active clustering. Clustering Essbase cubes (databases) enables load balancing and failover support. Provider Services manages a series of active, duplicate databases that respond to user requests. Users connect to the database by specifying an Essbase cluster; the database that is accessed must be transparent to users. Provider Services facilitates the routing of connections between databases in a cluster, based on availability and precedence rules (using the round-robin technique). The Essbase cluster supports read-only operations on the Essbase database. Write-back operations such as data load and outline editing are not supported.

15.1.6.2 Protection from Failures and Expected Behaviors

Provider Services supports sticky sessions: After a user session is established with a Provider Services instance, the same Provider Services instance handles all subsequent requests from the client until the user disconnects. When a Provider Services instance fails (indicated by an invalid session error), the user must disconnect the existing (invalid) session and log on again. The failover to the new Provider Services instance is transparent, so that the user can connect to the same APS URL (the dispatcher's URL) that was used earlier. A dispatcher could be, for example, Oracle HTTP Server, which acts as a gateway, delivering requests to the Provider Services instances that are part of the cluster.

15.1.7 Oracle EPM Workspace Component Architecture

Oracle Enterprise Performance Management (EPM) Workspace, Fusion Edition (Workspace) is the Web user interface that is used to access all Oracle Hyperion and non-Oracle Hyperion content. Oracle Hyperion content includes Reporting and Analysis Framework and Oracle's Hyperion financial applications.

15.1.7.1 Workspace Component Characteristics

Figure 15-5 shows the Workspace single instance architecture.

Figure 15-5 Workspace Single Instance Architecture

Description of "Figure 15-5 Workspace Single Instance Architecture"

EPM Workspace consists of a single J2EE Web application, which is typically fronted by an HTTP proxy such as Oracle HTTP Server. The HTTP proxy serves static content and proxies other products integrated into EPM Workspace. Content aggregation typically occurs on the client-side. EPM Workspace does not aggregate content within its own process; that is, EPM Workspace does not function as a portal.

15.1.7.1.1 State Information

EPM Workspace sessions are regular J2EE sessions that are held in memory only. EPM Workspace is stateful in its session use and the sessions are not serializable to any DB.

15.1.7.1.2 Runtime Processes

EPM Workspace has a normal J2EE runtime. Users typically connect to EPM Workspace, log on to the system, and access another product, such as Oracle Hyperion Financial Reporting. There are no background threads or other forms of server-side services or jobs. All processing is handled in the context of the HTTP request.

EPM Workspace uses a set of servlets, implemented directly or as JSPs, and servlet filters. There are no EJBs or JMS usage. Database access is through a standard JNDI lookup of a JDBC data source.

15.1.7.1.3 Process Lifecycle

EPM Workspace is managed as a standard J2EE Web application deployed to the WebLogic application server. It is managed, started, and terminated by its application server.

15.1.7.1.4 Request Flow

Requests are made to EPM Workspace by means of the HTTP proxy, which is the only means for end-users to access EPM Workspace. EPM Workspace does not make requests against other Web applications or databases other than its repository database and the EPM Registry database.

15.1.7.1.5 External Dependencies

EPM Workspace relies upon its repository database and the Hyperion Registry; both are in the same schema.

Most EPM products rely on EPM Workspace to provide initial authentication and a containing user interface.

15.1.7.1.6 Configuration Artifacts

The entire EPM Workspace configuration is stored in the Hyperion Registry. Individual user preferences are stored in the EPM Workspace repository.

15.1.7.1.7 Deployment Artifacts

EPM Workspace has no deployment artifacts other than the JDBC data source.

15.1.7.1.8 Log Files

Go to the logs/workspace subdirectory in the managed server domain home to view workspace.log and Framework.log.

15.1.8 Oracle EPM Workspace High Availability Concepts

This section provides conceptual information about using EPM Workspace in a high availability environment.

15.1.8.1 Workspace High Availability Architecture

You can cluster both the HTTP proxy and the J2EE deployment of EPM Workspace with standard WebLogic Server clustering mechanisms and standard use of the application server deployment and data sources. EPM Workspace high availability requires sticky sessions; session replication and failover are not supported.

All clustered versions must be identical. All updates to cluster members must be made at the same time.

The load-balancer hardware or HTTP proxy allocates requests in a round-robin rotation.Requests fail if the repository database or Hyperion Registry is lost. When a request fails, subsequent requests attempt to initialize EPM Workspace and restore its database connectivity.

Database use increases markedly when an EPM Workspace instance is started and initialized. If there are many deployments, the cluster startup may be faster if you stagger startup of the instances.

15.1.8.1.1 Shared Files and Directories

EPM Workspace has no shared files or directories except for Oracle JRF and EPM common files.

15.1.8.1.2 Cluster-Wide Configuration Changes

Product binaries and deployment information generated by WebLogic Server are stored in the file system. The configuration is stored in the Hyperion Registry. All Workspace instances share the same configuration via the Hyperion Registry. You can change the configuration through the EPM Workspace administrative user interface or with explicit updates to the registry outside EPM Workspace.

Normally, the file system artifact changes only for a patch or for reconfiguration of the deployment or clustering that requires Oracle WebLogic Server file changes. Configuration changes do not require files system updates. Cluster members see the updated configuration at the next reinitialization. Each cluster member must be directed to reinitialize itself; the Hyperion Registry is not polled.

15.1.8.2 Protection from Failures and Expected Behaviors

Unfinished requests and sessions that are on the failed node are lost. Subsequent requests from the browser that are routed to a different node are intercepted and require re-authentication to Workspace. There is no provision to migrate any sessions for a single node failure; there is a feature for administrators to send a message to Workspace users at logon that could inform them of downtime, etc.

Note:

Database outages affect BI Workspace sessions. With RAC database backends, if a database instance has an outage, BI workspace sessions connected to the database generate an error and may need to restart.

15.1.8.3 Troubleshooting

Go to the logs/workspace subdirectory in the managed server domain home to view Workspace.log and Framework.log.

15.1.9 Oracle Hyperion Financial Reporting Component Architecture

Oracle Hyperion Financial Reporting (Financial Reporting) is a powerful tool for designing and presenting analytic data graphically. You can design traditional financial report formats such as cash management reports, profit and loss statements, and balance sheets. You can also design nontraditional formats for financial or analytic data that include text and graphics.

Use Financial Reporting to create and deliver financial reports to the General Ledger system. Reporting administrators use EPM Workspace with financial reports to create and modify reports, books, and batch definitions and to schedule batch jobs via the reporting scheduler user interface within EPM Workspace. Reporting users run and view reports using the General Ledger user interface; they can launch reports in an IFrame within the General Ledger browser window.

Figure 15-6 shows the Financial Reporting single instance architecture.

Figure 15-6 Financial Reporting Single Instance Architecture

Description of "Figure 15-6 Financial Reporting Single Instance Architecture"

15.1.9.1 Oracle Hyperion Financial Reporting Component Characteristics

Financial Reporting contains servlets and also contains JSPs for UI and XML generation. It also provides a web service API (JRF based) for use from ESS scheduler implementation for FR (FREssClient.ear). FRWebApp also contains RMI objects which are discovered and distributed via HTTP calls that replace the typical RMI registry, allowing multiple instances per machine with lookup via proxy request to distribute the load across instances.

PrintServer is a stand-alone RMI server (default port 8297) which is registered with the Web application, allowing a Web request for a PDF to locate a print server and generate PDF results.

15.1.9.1.1 State Information

EPM Workspace browser is either stateless or per session. Connections to Oracle BI Presentation Service cache and restore if they time out. WebLogic pooling handles RDBMS and tries to reconnect in case of failure when making SQL calls. By default, Essbase connections cache for 5 minutes (configurable).

Protocol:

RDBMS – Managed by JNDI connection configured by WebLogic.
Oracle BI Presentation Services Web Services URL – Configured in Hyperion Registry.
EPM Workspace – Web user interface container for Financial Reporting (All interactions with Financial Reporting are in the browser with JavaScript.)
Essbase/Provider Services – Financial Reporting connects directly to Essbase by way of sockets. Lookup is direct or by way of Provider Services HTTP calls.

15.1.9.1.2 Runtime Processes

This section describes Financial Reporting processes at runtime.
Users launch report or book from the list of available reports. Users can select formats that include HTML, PDF, or Microsoft Office document).
- Financial Reporting loads a tracking frame, which identifies what report instances are used and catches unloading events for the IFrame to clean up server instances. This frame loads another frame for executing and viewing the report or book.
- Financial Reporting Web Application loads the report or book design and runs it against Essbase to generate output in the requested format.
  - Financial Reporting loads the design from the catalog by means of Oracle BI Presentation Services calls.
  - Financial Reporting connects to Essbase either directly or by way of a Provider Services URL.
  - Financial Reporting queries Essbase based on the report or book design and generates output in the requested format.
    
    For HTML and Microsoft Office formats, Financial Reporting generates HTML and delivers the associated mime type to the client to allow launching in Microsoft Office when requested.
    
    For PDF format, the Financial Reporting application server makes an RMI call to an available print server to generate PDF content, then returns the PDF file to the browser client.
    
    Note:
    Configure and register multiple print servers. If a print server fails or goes offline, Financial Reporting moves to another print server.
EPM Workspace-initiated report or book execution and viewing (HTML, PDF, Microsoft Office)
- Initiated from a browser
- XML, HTML, JavaScript, and Bindows – User interface components shown from EPM Workspace, Financial Reporting, and Oracle BI EE
- Failover not supported; users must restart browser.
Smart View importing of reports:
- Initiated from Microsoft Office
- XML, HTML, JavaScript
- Failover supported
Report previews appear in an Internet Explorer-based control that shows the report in HTML before returning the Microsoft Office-formatted HTML results.
Book and batch design and modification (available only from EPM Workspace)
- Initiated from a browser
- XML, HTML, JavaScript, and Bindows
- Failover not supported; users must restart browser.
Editing book and batch designs uses a complex user interface of bindows components to present and manipulate book and batch contents.
- Financial Reporting opens and saves design objects in the Oracle BI Presentation Services repository by means of web services APIs.
- Financial Reporting connects to design- specified Essbase cubes through direct Essbase connection or a Provider Services URL (to allow for failover).
- Financial Reporting uses Bindows user interface components and JavaScript to present the design to Reports Designer to allow for changes to the book or batch design.
Report Design and Modification (available from Financial Reporting Studio)
- Initiated from Financial Reporting Studio (Windows 32-bit executable)
- Visual Basic/Visual C++/Java application
- Failover not supported, users must restart Financial Reporting Studio
- Connection and user authentication: Report Designer enters credentials and URL of the Financial Reporting server (normally address of the Oracle HTTP Server proxy). Financial Reporting Studio makes an HTTP call to the Web application to get an RMI stub object; afterward, all communication is by way of RMI.
- All access to repository and data sources is through remote RMI calls to Financial Reporting Web Application RMI objects, which make calls to repository and data sources. No direct connection is made from Financial Reporting Studio to the repository or Essbase.
- All access to RDBMS is through remote calls to Financial Reporting Web Application RMI objects, which make the JDBC calls. No direct connection is made from FRStudio to the JDBC datasources.
Batch scheduling (Available from EPM Workspace; schedule accessible and modifiable via ESS EM):
- Initiated from a browser
- HTML, JavaScript, and Bindows
- Failover not supported; users must restart browser.
Users open a wizard to select a batch to schedule and job attributes such as point of view, execution time/frequency of execution, and output format.

The Financial Reporting Web Application uses ESS EJB APIs to create and schedule the job according to the user's instructions. ESS RDBMS tables store the job and request.
Batch Execution (ESS and Financial Reporting backend code)
- Initiated by ESS
- Invokes Webservice calls to Financial Reporting
- Failover supported (Webservice failure during call causes batch result state of error)
- ESS picks up the Financial Reporting scheduled job and calls the Financial Reporting EssClient, which deploys with ESS-dedicated servers in the FSCM domain.
- FREssClient extracts the URL of the target Financial Reporting application server and makes a Webservice call to the Financial Reporting application server to execute the job, passing the XML defined as the job definition.
- Financial Reporting Web Application runs the job according to the parameters defined when the user scheduled the job and returns a status code to FREssClient.
- FREssClient returns the success or failure status to the ESS caller.
Note:
Financial Reporting keeps job results in RDBMS tables. However, ESS determines when a job runs and the FREssClient connects to only one Financial Reporting Web Application. This prevents multiple Financial Reporting servers from processing issues of the same job; ESS manages how it prevents multiple ESS servers from processing the same job.
Batch Results viewer (Available from EPM Workspace)
- Initiated from a browser
- HTML, JavaScript, and Bindows
- Failover not supported; users must restart browser.
- User gets a list of executed and pending jobs; Financial Reporting Web Application gets the list from ESS in-process EJBs.
- User can retrieve result content from list of jobs; Financial Reporting Web Application gets results from Financial Reporting Scheduler RDBMS tables.
- User can delete or replicate jobs, following the same process as for creating and scheduling jobs.

15.1.9.1.3 External Dependencies

RDBMS – Hyperion Registry, Annotations Tables (Financial Reporting), Financial Reporting Scheduler Tables (Financial Reporting), ESS Job Tables (ESS)
Oracle BI Presentation Services Repository (accessed through Web Services and EPM Workspace)
EPM Workspace (for reporting administrators)
Essbase/Provider Services
Essbase-generated cubes
ESS installed and configured

15.1.9.1.4 Configuration Artifacts

Hyperion Registry stores configuration information that is not part of the overall system configuration; all Web application instances share Hyperion Registry. MBeans, which you can open and modify with Fusion Middleware Control, exposes configuration information. See the following in Fusion Middleware Control: com.hyperion.FinancialReporting and com.hyperion.Annotations.

15.1.9.1.5 Deployment Artifacts

Financial Reporting has these Deployment Artifacts:

FREssClient.ear – Contains the Enterprise Scheduler Service server implementation for Financial Reporting jobs, deployed to the FinDomain Enterprise Scheduler Service.
HReports.ear – Primary Financial Reporting Web Application deployed to the BIDomain.

Shared Libraries deployed to the BIDomain that the Financial Reporting Web Application requires include: epm-shared-libraries epm-fr-libraries epm-annotation-libraries epm-frweb-libraries epm-misc-libraries.

15.1.9.1.6 Log Files

Financial Reporting logs are in $domain home/servers/${weblogic.Name}/logs/financialreporting. Note that ${weblogic.Name}is the managed server name, for example bi_server1 or bi_server2.

15.1.10 Oracle Hyperion Financial Reporting High Availability Concepts

Oracle Hyperion Financial Reporting supports high availability for the following functionality:

Report Execution and Viewing as HTML or PDF:
- Prompt
- POV changes
- Page dimension drop-down (HTML only)
- Annotation creation and viewing
- Expansion
- Drill-through (Not available in PDF)
Book execution and viewing as HTML or PDF
Export to Microsoft Office formats

15.1.10.1 Oracle Hyperion Financial Reporting High Availability Architecture

Figure 15-2 shows Essbase in a highly available Oracle BI EE deployment.

15.1.10.1.1 Shared Files and Directories

There are no shared files or directories. All common properties and documents are either in the relational database or stored in the Oracle BI Presentation Services repository.

15.1.10.1.2 Cluster-Wide Configuration Changes

Except for PrintServer, configuration is cached. Modifications affect only the server where they are made until the next restart of the other server. Print servers are not cached and can be added or removed at any time.

15.1.10.2 Protection from Failures and Expected Behaviors

Financial Reporting supports failover and session serialization if you also deploy the following components:

Oracle Business Intelligence Enterprise Edition/Oracle BI Presentation Services – Financial Reporting uses web service connections to Oracle BI Presentation Services, with failover from the current Oracle BI Presentation Services connection fails to other catalog nodes, assuming these conditions:
- The catalog application server, Presentation Services, and file storage are clustered or replicated.
- The catalog location configured during applications provisioning references the proxy server and not a direct catalog Web application server.
Essbase – Financial Reporting reports must target Essbase using the Provider Services URL, and Provider Services must be configured with active and passive Essbase servers. When Essbase fails, Financial Reporting connects through the Oracle Hyperion Provider Services URL to the backup server, and Essbase queries are reissued without interruption to the user request.
RDBMS – The database must support failover. Connections are handled through the WebLogic JDBC configuration and connection pooling.
Oracle Internet Directory/OAM
Oracle HTTP Server is expected to provide failover and provide integration point for all components. Financial Reporting configuration should target Oracle BI Presentation Services through Oracle HTTP Server or a load-balanced URL and not directly target the catalog server.
Oracle Hyperion Financial Reporting, Fusion Edition PrintServer – At least two PrintServer hosts should be deployed on Windows machines and configured with the system.

15.1.11 Allocation Manager Component Architecture and Characteristics

Use Allocation Manager to create, validate, deploy, and administer sophisticated calculations that solve Oracle Hyperion Financial Management, Fusion Edition, Oracle Hyperion Planning, Fusion Edition, and Oracle Essbase business problems. You access Allocation Manager within Oracle Enterprise Performance Management Workspace, Fusion Edition.

Allocation Manager is a Java Web application, deployed on WebLogic with multiple instances running in active-active mode. All instances of Allocation Manager are equal and can service any request. Allocation Manager is a stateful application that requires sticky routing. Session failover is not supported. Edits are made only within a single instance and are not saved if the instance fails.

Allocation Manager administration and discovery of external components is done through Hyperion Registry.

15.1.12 Oracle BI EE High Availability Configuration Steps

This section describes how to set up a two node highly available configuration for Oracle BI EE and BI Publisher. The architecture targeted for the configuration steps is Figure 15-2.

Note:

Oracle strongly recommends reading the release notes for any additional installation and deployment considerations prior to starting the setup process.

15.1.12.1 Prerequisite Steps Before Setting Up a High Availability Configuration for Oracle BI Enterprise Edition and BI Publisher

The following section describes prerequisite steps before setting up a high availability configuration for Oracle BI EE and Oracle BI Publisher.

15.1.12.1.1 Database Prerequisites

Oracle BI EE supports the following database versions:

Oracle Database 10g (10.2.0.4 or later for non-XE database)
Oracle Database 11g (11.1.0.7 or later for non-XE database)

To determine the database version, execute this query:

SQL>select version from sys.product_component_version where product like 'Oracle%';

15.1.12.1.2 VIP and IP Prerequisites

You configure the BI managed servers to listen on different virtual IPs, shown in Table 15-7. This requires the provisioning of the corresponding VIP in the node and related host names in the DNS system in your network. Ensure that the different VIPs are available and are reachable before running the installation.

Table 15-3 BI EE Virtual Hosts

Virtual IP	Virtual IP Maps To	Description
VIP1	APPHOST1VHN1	APPHOST1VHN1 is the virtual host name that maps to the listen address for BI_SERVER1 and fails over with server migration of this managed server. It is enabled on the node where BI_SERVER1 process is running (APPHOST1 by default).
VIP2	APPHOST2VHN1	APPHOST2VHN1 is the virtual host name that maps to the listen address for BI_SERVER2 and fails over with server migration of this managed server. It is enabled on the node where BI_SERVER2 process is running (APPHOST2 by default).

15.1.12.1.3 Shared Storage Prerequisites

For proper recovery in case of failure, store both JMS and transaction logs in a location that is accessible to all the nodes that can resume the operations after a failure in a managed server. This requires a shared storage location that can be referenced by multiple nodes. Table 15-4 lists the contents of shared storage.

Table 15-4 Contents of BI EE Shared Storage

Server	Type of Data	Volume in Shared Storage	Directory	Files
BI_SERVER1 and BI_SERVER2	Transaction logs	VOL2	ORACLE_BASE/admin/domain_name/cluster_name/tlogs	Common location (stores decided by WebLogic Server)
BI_SERVER1 and BI_SERVER2	JMS stores	VOL2	ORACLE_BASE/admin/domain_name/cluster_name/jms	Common location, but individual store per server. For example: BipJmsStore for BI_SERVER1 and BipJmsStore2 for BI_SERVER2)
BI_SERVER1 and BI_SERVER2	BI Server Repository	VOL1	ORACLE_BASE/admin/domain_name/cluster_name/ClusterRPD	Common location
BI_SERVER1 and BI_SERVER2	BI Global Cache	VOL1	ORACLE_BASE/admin/domain_name/cluster_name/GlobalCache	Common location
BI_SERVER1 and BI_SERVER2	BI Presentation Services Repository	VOL1	ORACLE_BASE/admin/domain_name/cluster_name/catalog	Common location
BI_SERVER1 and BI_SERVER2	BI Publisher Configuration folder	VOL1	ORACLE_BASE/admin/domain_name/cluster_name/bipublisher/config	Common location
BI_SERVER1 and BI_SERVER2	BI Publisher Catalog repository	VOL1	ORACLE_BASE/domain_name/config/bipublisher/catalog This is only required if Oracle BI Publisher - File System is selected for the BI Publisher Catalog type.	Common location
BI_SERVER1 and BI_SERVER2	BI Publisher Scheduler Temp directory	VOL1	ORACLE_BASE/admin/domain_name/cluster_name/bipublisher/temp	Common location

The shared storage can be a NAS or SAN device. The following is an example command based on a NAS over NFS device. Your options may be different from the ones specified in this section.

APPHOST1> mount nasfiler:/vol/volX/FMWshared MW_HOME-t nfs -o
rw,bg,hard,nointr,tcp,vers=3,timeo=300,rsize=32768,wsize=32768

15.1.12.1.4 Clock Synchronization

You must synchronize all server clocks that participate in the cluster to within one second difference. To synchronize the clocks, use a single network time server and point each server to it. The procedure to point to the network time server is different from Windows to Linux. Refer to your operating system's manual.

15.1.12.1.5 Installing and Configuring the Database Repository

This section describes how to install and configure the database repository.

Oracle Clusterware

For 10g Release 2 (10.2), see Oracle Database Oracle Clusterware and Oracle Real Application Clusters Installation Guide.
For 11g Release 1 (11.1) and later, see Oracle Clusterware Installation Guide.

Automatic Storage Management

For 10g Release 2 (10.2), see Oracle Database Oracle Clusterware and Oracle Real Application Clusters Installation Guide.
For 11g Release 1 (11.1) and later, see Oracle Real Application Clusters Installation Guide.

When you run the installer, select the Configure Automatic Storage Management option in the Select Configuration page to create a separate Automatic Storage Management home.

Oracle Real Application Clusters

For 10g Release 2 (10.2), see Oracle Database Oracle Clusterware and Oracle Real Application Clusters Installation Guide.
For 11g Release 1 (11.1) and later, see Oracle Real Application Clusters Installation Guide.

You must install the 11g (11.1.1) Oracle Fusion Middleware Repository into an Oracle Real Application Clusters (Oracle RAC) database before you install the Oracle Fusion Middleware components. Oracle Fusion Middleware provides a tool, Oracle Fusion Middleware Repository Creation Utility (RCU), to create the component schemas in an existing database. You install RCU in its own, separate Middleware home.

Use the latest version of RCU to install the 11g (11.1.1.) Oracle Fusion Middleware Repository into an Oracle RAC database.

See Oracle Fusion Middleware Repository Creation Utility User's Guide for more information about obtaining and running the latest version of RCU.

15.1.12.1.6 Using RCU to Load the Business Intelligence Schemas in the Database

Install the 11g (11.1.1) Oracle Fusion Middleware Metadata Store and Oracle BI schemas into an Oracle RAC database before you install Oracle Business Intelligence. Follow these steps:

Insert the Repository Creation Utility (RCU) DVD, and then start RCU from the bin directory in the RCU home directory.
```
prompt> cd RCU_HOME/bin
prompt> ./rcu
```
In the Welcome screen, click Next.
In the Create Repository screen, select Create to load component schemas into a database. Click Next.
In the Database Connection Details screen, enter connect information for your database:
- Database Type: Select Oracle Database.
- Host Name: Specify the name of the node on which the database resides. For the Oracle RAC database, specify the VIP name or one of the node names as the host name, for example:
  
  BIDBHOST1-VIP
- Port: Specify the listen port number for the database: 1521
- Service Name: Specify the service name of the database:
  
  biha.mycompany.com
- Username: Specify the name of the user with DBA or SYSDBA privilege: SYS
- Password: Enter the password for the SYS user.
- Role: Select the database user's role from the list: SYSDBA (required by the SYS user).
Click Next.
In the Select Components screen:
- Select Create a new Prefix and enter a prefix to use for the database schemas, for example, BIHA. You can specify up to six characters as a prefix. Prefixes are used to create logical groupings of multiple repositories in a database. For more information, see Oracle Fusion Middleware Repository Creation Utility User's Guide.
  
  Tip:
  Note the name of this schema because the upcoming steps require this information.
- Select the following components:
```
o  AS Common Schemas: Metadata Services (automatically selected)
o  Oracle Business Intelligence: Business Intelligence Platform
```
Click Next.
In the Schema Passwords screen, enter passwords for the main schema users and click Next.

Choose either Use same passwords for all schemas or Specify different passwords for all schemas, depending on your requirements.

Do not select Use main schema passwords for auxiliary schemas. The auxiliary passwords derive from the passwords of the main schema users.

Tip:
Note the names of the schema passwords because the upcoming steps require this information.
In the Map Tablespaces screen, choose the tablespaces for the selected components, and click Next.
In the Summary screen, click Create.
In the Completion Summary screen, click Close.

15.1.12.1.7 Configuring Virtual Server Names and Ports for the Load Balancer

This section describes the load balancer prerequisites for deploying an Oracle BI EE high availability environment.

Load Balancers

Oracle BI EE uses a hardware load balancer when deployed in a high availability configuration with two Oracle HTTP Servers as web tier components.

Virtual Server Names

bi.mycompany.com is a virtual server name that acts as the access point for all HTTP traffic to the runtime BI components, such as Oracle BI Publisher. Traffic to both SSL and non-SSL ports is configured, and typically non-SSL is redirected to SSL. Clients access this service using the address bi.mycompany.com:443. This virtual server is defined on the load balancer.

15.1.12.1.8 Installing Oracle HTTP Server on WEBHOST1 and WEBHOST2

This section describes how to install Oracle HTTP Server on WEBHOST1.

Verify that the servers meet the following requirements:
- Ensure that the system, patch, kernel and other requirements are met. These are listed in the Oracle Fusion Middleware Installation Guide for Oracle Web Tier in the Oracle Fusion Middleware documentation library for the platform and version you are using.
- Ensure that port 7777 is not in use by any service on WEBHOST1 by issuing these commands for the operating system you are using. If a port is not in use, no output is returned from the command.
  
  On UNIX:
```
netstat -an | grep "7777"
```
  On Windows:
```
netstat -an | findstr :7777
```
  If the port is in use (if the command returns output identifying the port), you must free the port.
  
  On UNIX:
  
  Remove the entries for port 7777 in the /etc/services file and restart the services, or restart the computer.
  
  On Windows:
  
  Stop the component that is using the port.
- Copy the staticports.ini file from the Disk1/stage/Response directory to a temporary directory.
- Edit the staticports.ini file that you copied to the temporary directory to assign the following custom ports (uncomment the line where you specify the port number for Oracle HTTP Server):
```
# The port for Oracle HTTP server
Oracle HTTP Server port = 7777
```
Start the Oracle Universal Installer for Oracle Fusion Middleware 11g Web Tier Utilities CD installation as follows:

On UNIX:

Issue the command: ./runinstaller

On Windows:

Double-click setup.exe.

This displays the Specify Inventory Directory screen.
On the Specify Inventory Directory screen, enter values for the Oracle Inventory Directory and the Operating System Group Name. For example:

Specify the Inventory Directory: /u01/app/oraInventory

Operating System Group Name: oinstall

A dialog box appears with the following message:

"Certain actions need to be performed with root privileges before the install can continue. Please execute the script /u01/app/oraInventory/createCentralInventory.sh now from another window and then press "Ok" to continue the install. If you do not have the root privileges and wish to continue the install select the "Continue installation with local inventory" option"

Log in as root and run the "/u01/app/oraInventory/createCentralInventory.sh"

This sets the required permissions for the Oracle Inventory Directory and then brings up the Welcome screen.
Note:
The Oracle Inventory screen is not shown if an Oracle product was previously installed on the host. If the Oracle Inventory screen does not appear for this installation, verify and see:
- If the /etc/oraInst.loc file exists.
- If the file exists, that the Inventory directory listed is valid.
- Whether or not the user performing the installation has write permissions for the Inventory directory.
On the Welcome screen, click Next.
On the Select Installation Type screen, select Install and Configure, and click Next.
On the Prerequisite Checks screen, the installer completes the prerequisite check. If any fail, fix them and restart your installation.

Click Next.
On the Specify Installation Location screen, specify:
- Oracle Middleware Home: ORACLE_BASE/product/fmw (grayed out)
- Oracle Home Directory: Oracle_WT1
Click Next.
On the Configure Components screen:
- Select Oracle HTTP Server.
- Do not select Associate Selected Components with Weblogic Domain.
Click Next.
On the Specify Component Details screen, enter the following values for WEBHOST1:
- Instance Home Location: ORACLE_BASE/product/fmw/Oracle_WT1/instances/web1
- Instance Name: web1
- OHS Component Name: ohs1
Click Next.
On the Configure Ports screen:
- If you specify a custom port, select Specify Ports using Configuration File and then use the Browse function to select the file.
- Enter the Oracle HTTP Server port, for example: 7777
Click Next.
In the Specify Security Updates screen, choose whether you want to receive security updates from Oracle Support and if you do, enter your email address and click Next.
On the Installation Summary screen, ensure that the selections are correct. If they are not, click Back and make the necessary fixes. After ensuring that the selections are correct, click Install.
On the Installation Progress screen on UNIX systems, a dialog appears that prompts you to run the oracleRoot.sh script. Open a window and run the script, following the prompts in the window.

Click Next.
On the Configuration Progress screen, multiple configuration assistants are launched in succession; this process can be lengthy. Click Next.
On the Installation Complete screen, click Finish to exit.

Repeat the steps for WEBHOST2 and configure your load balancer with a pool containing both the WEBHOST1 and WEBHOST2 addresses.

15.1.12.1.9 Validating Oracle HTTP Server

To verify that Oracle HTTP Server is set up correctly, access the root URL context of the server by using the following URLs in the browser:

http://WEBHOST1:7777/
http://WEBHOST2:7777/

If Oracle HTTP Server is set up correctly, the Oracle FMW Welcome screen appears in the browser.

15.1.12.2 Installing Oracle Business Intelligence Enterprise Edition for High Availability

This section describes how to install Oracle Fusion Middleware on all application tier nodes that run Oracle WebLogic Server and Oracle BI EE. Repeat the procedure (described below for APPHOST1) for installing WebLogic Server and Oracle BI EE in APPHOST2. The directory paths you use for binary files and domains when installing new nodes must be identical to those for the first node.

Install the following Oracle Fusion Middleware components:

Oracle WebLogic Server
Oracle Business Intelligence

In this section, a software-only install is performed then the config.sh configuration script is used to create and scale out the Oracle BI system.

15.1.12.2.1 Installing Oracle WebLogic Server

Follow these steps to install Oracle WebLogic Server:

Start the installer for Oracle WebLogic Server from the installation media.
In the Welcome screen, click Next.
In the Choose Middleware Home Directory screen:
- Select Create a new Middleware Home.
- For the Middleware Home Directory, enter ORACLE_BASE/product/fmw
  
  Note:
  ORACLE_BASE is the base directory under which Oracle products are installed. The recommended value is /u01/app/oracle.
Click Next.
In the Register for Security Updates screen, choose whether you want to receive security updates from Oracle Support and if you do, enter your email address. Click Next.
In the Choose Install Type screen, select Typical and click Next.
In the Choose Product Installation Directories screen, accept the directory ORACLE_BASE/product/fmw/wlserver_10.3 for WebLogic Server and ORACLE_BASE/product/fmw/coherence_3.6 for Oracle Coherence and click Next.
In the Installation Summary screen, click Next.

The Oracle WebLogic Server software is installed.
In the Installation Complete screen, clear the Run Quickstart check box and click Done.

15.1.12.2.2 Installing Oracle Fusion Middleware for Business Intelligence Enterprise Edition and Oracle BI Publisher

On the Linux platform, if the /etc/oraInst.loc file exists, check that its contents are correct. Specifically, check that the inventory directory is correct and that you have write permissions for that directory. If the /etc/oraInst.loc file does not exist, you can skip this step.

Start the installer for Oracle Fusion Middleware Business Intelligence 11g from the installation media:

On UNIX:
```
APPHOST1>./runInstaller
```
On Windows:
```
APPHOST1> setup.exe
```
In the Specify Inventory Directory screen:
- Enter HOME/oraInventory, where HOME is the home directory of the user performing the installation (this is the recommended location).
- Enter the OS group for the user performing the installation.
  
  Click Next.
- Follow the instructions on screen to execute /createCentralnventory.sh as root.
  
  Click OK.
In the Welcome screen, click Next.
In the Select Installation Type screen, select Software Only Install and click Next.
In the Prerequisite Checks screen, verify that all checks complete successfully, and click Next.
In the Specify Installation Location screen, select the previously installed Middleware Home from the drop-down list. For the Oracle Home directory, enter the directory name (Oracle_BI1).

Click Next.
In the Specify Security Updates screen, choose whether you want to receive security updates from Oracle Support and if you do, enter your email address and click Next.
In the Summary screen, click Install.

The Oracle Fusion Middleware Business Intelligence 11g software is installed.
In the Installation Progress screen, click Next.
In the Complete screen, click Finish.

15.1.12.3 Enabling VIP1 in APPHOST1 and VIP2 in APPHOST2

The BI domain uses virtual hostnames as the listen addresses for the BI managed servers. You must enable the VIPs, mapping each of these hostnames on the two BI machines (VIP1 on APPHOST1 and VIP2 on APPHOST2), and they must correctly resolve to the virtual hostnames in the network system used by the topology (either by DNS Server or hosts resolution).

15.1.12.4 Creating a Domain with the Administration Server and the First BI_SERVER1 Managed Server

This section describes how to create a domain and the first WebLogic Server BI managed server using the Oracle Business Intelligence Configuration Assistant, Oracle WebLogic Server Administration Console, and Oracle Enterprise Manager. Ensure that the database where you installed the repository is running. For Oracle RAC databases, all the instances must be running.

Note:

Oracle strongly recommends that you read the release notes for any additional installation and deployment considerations prior to starting the setup process.

Run the Configuration Assistant from the Oracle home directory to create a domain containing the Administration Server and the managed server with BI Publisher:

Change the directory to the location of the Configuration Assistant:
```
APPHOST1> cd ORACLE_HOME/bin
```
Start the Configuration Assistant:

On UNIX:
```
APPHOST1> ./config.sh
```
On Windows:
```
APPHOST1> config.cmd
```
In the Welcome screen, click Next.
In the Prerequisite Checks screen, verify that all checks complete successfully, and click Next.
The Create or Scale Out BI System screen opens. Select Create New BI System and specify the following:
- User Name: weblogic
- User Password: Enter the weblogic user password.
- Domain Name: bifoundation_domain
Click Next.
In the Specify Installation Location screen, enter:
- Middleware Home: ORACLE_BASE/product/fmw (grayed out)
- Oracle Home: ORACLE_BASE/product/fmw/Oracle_BI1 (grayed out)
- WebLogic Server Home: ORACLE_BASE/product/fmw/wlserver_10.3 (grayed out)
- Domain Home: ORACLE_BASE/product/fmw/user_projects/domain/bifoundation_domain
  
  Note:
  The Domain Home must end with the domain name.
- Instance Home: ORACLE_BASE/product/fmw/instance1
- Instance Name: instance1
Click Next.

In the Configure Components screen, select:

- Oracle Business Intelligence
       - Business Intelligence Enterprise Edition
       - Business Intelligence Publisher

Click Next.

In the RPD Encryption Password screen, enter the following information:
- RPD Password
- Confirm RPD Password
  
  The RPD Password is used for the sample repository SampleAppLite.rpd that is included with the installed files.
Click Next.
In the MDS Schema screen, verify the information. For example:
- Database Type: Oracle Database
- Connect String: BIDBHOST1:1521:BIDB1^BIDBHOST2:1521:BIDB2@BIHA.MYCOMPANY.COM
- MDS Schema Username: prefix_MDS
- MDS Password: your_password
Click Next.
In the BIPLATFORM Schema screen, enter:
- Database Type: Oracle Database
- Connect String: BIDBHOST1:1521:BIDB1^BIDBHOST2:1521:BIDB2@BIHA.MYCOMPANY.COM
- BIPLATFORM Schema Username: BIHA_BIPLATFORM
- BIPLATFORM Schema Password: Enter the password for the BIPLATFORM schema user.
Click Next.
In the Configure Ports screen, select one of the following:
- Auto Port Configuration
- Specify Ports using Configuration File
Click Next.
In the Specify Security Updates screen, choose whether you want to receive security updates from Oracle Support and if you do, enter your email address. Click Next.
In the Summary screen, click Configure.
In the Configuration Progress screen, verify that all the Configuration Tools have completed successfully and click Next.
In the Complete screen, click Finish.

15.1.12.5 Creating boot.properties for the Administration Server on APPHOST1

This is an optional step for enabling the Administration Server to start without prompting you for the administrator username and password. Create a boot.properties file for the Administration Server on APPHOST1.

Go to the following directory:

ORACLE_BASE/product/fmw/user_projects/domains/bifoundation_domain/servers/
AdminServer/security

Enter the following lines in the file, save the file, and close the editor:
```
username=Admin_username
password=Admin_password
```
Note:
When you start the Administration Server, the username and password entries in the file are encrypted.
For security reasons, minimize the time the entries in the file are left unencrypted. After you edit the file, start the server as soon as possible for the entries to be encrypted.

15.1.12.6 Starting and Validating the Administration Server on APPHOST1

This section describes procedures for starting and validating the Administration Server on APPHOST1.

15.1.12.6.1 Starting the Administration Server on APPHOST1

To start the Administration Server on APPHOST1, run the following commands:

APPHOST1> cd MW_HOME/user_projects/domains/bifoundation_domain/bin
APPHOST1> ./startWebLogic.sh

15.1.12.6.2 Validating the Administration Server

verify that the Administration Server is properly configured:

In a browser, go to http://APPHOST1:7001/console.
Log in as the administrator.
Verify that the BI_SERVER1 managed server is listed.
Verify that the bi_cluster cluster is listed.
Verify that you can access Enterprise Manager at http://APPHOST1:7001/em.

15.1.12.7 Setting the Listen Address for BI_SERVER1 Managed Server

Perform these steps to set the managed server listen address:

Log into the Oracle WebLogic Server Administration Console.
In the Change Center, click Lock & Edit.
Expand the Environment node in the Domain Structure window.
Click Servers.

The Summary of Servers page is displayed.
Select bi_server1 in the Names column of the table.

The Setting page for bi_server1 is displayed.
Set the Listen Address to APPHOST1VHN1.
Click Save.
Click Activate Changes.
Restart the BI_SERVER1 managed server to make the changes take effect.
1. In the Summary of Servers screen, select the Control tab.
2. Select bi_server1 in the table and then click Shutdown.

Restart the BI System components. For example:

cd ORACLE_BASE/admin/instance1/bin
./opmnctl restartproc

15.1.12.7.1 Updating the Oracle BI Publisher Scheduler Configuration

Follow the steps in this section to update the WebLogic JNDI URL for the Oracle BI Publisher Scheduler.

Note:

See Missing JMS Instances on Oracle BI Publisher Scheduler Diagnostics Page for information about keeping clocks synchronized in Oracle BI Publisher Scheduler.

To update the Oracle BI Publisher Scheduler configuration:

Log in to Oracle BI Publisher at the following URL:
```
http://APPHOST1VHN1:9704/xmlpserver
```
Click the Administration link.
Click Scheduler Configuration under System Maintenance.
Update the WebLogic JNDI URL under JMS Configuration, as follows:
```
t3://APPHOST1VHN1:9704
```
Click Apply.
Check the Scheduler status from the Scheduler Diagnostics tab.

15.1.12.8 Disabling Host Name Verification for the BI_SERVER1 Managed Server

This step is required if you have not set up the appropriate certificates to authenticate the different nodes with the Administration Server. If you do not configure the server certificates, you receive errors when managing the different WebLogic Servers. To avoid these errors, disable host name verification while setting up and validating the topology, and enable it again once the high availability topology configuration is complete.

To disable host name verification:

Log into Oracle WebLogic Server Administration Console.
In the Change Center, click Lock & Edit.
Expand the Environment node in the Domain Structure window.
Click Servers.
Select bi_server1 in the Names column of the table.
Open the SSL tab.
Expand the Advanced section of the page.
Set Hostname Verification to None.
Click Save.
Click Activate Changes.
The changes do not take effect until the BI_SERVER1 managed server restarts.
1. In the Summary of Servers screen, select the Control tab.
2. Select bi_server1 in the table and then click Shutdown.

Restart the BI System components, for example:

cd ORACLE_BASE/admin/instance1/bin
./opmnctl restartproc

15.1.12.9 Starting the System in APPHOST1

This section describes how to start Node Manager on APPHOST1 and how to start and validate the BI_SERVER1 managed server on APPHOST1.

15.1.12.9.1 Starting Node Manager on APPHOST1

Usually, Node Manager starts automatically when config.sh completes. If Node Manager is not running for some reason, start it on APPHOST1 using these commands:

APPHOST1> cd WL_HOME/server/bin
APPHOST1> ./startNodeManager.sh

15.1.12.9.2 Starting and Validating the BI_SERVER1 Managed Server

To start the BI_SERVER1 managed server and check that it has the correct configuration:

Start the bi_server1 managed server using Oracle WebLogic Server Administration Console, as follows:
1. Expand the Environment node in the Domain Structure window.
2. Choose Servers.
3. Click the Control tab.
4. Select bi_server1 and then click Start.
Verify that the server status is reported as "Running" in the Administration Console. If the server is shown as "Starting" or "Resuming", wait for the server status to change to "Started". If another status is reported (such as "Admin" or "Failed"), check the server output log files for errors
When BI_SERVER1 starts, the following URLs become available:
- Access http://APPHOST1VHN1:9704/wsm-pm to verify the status of Web Services Manager. Click Validate Policy Manager. A list of policies and assertion templates available in the data appears.
  
  Note:
  The configuration is incorrect if no policies or assertion templates appear.
- Access http://APPHOST1VHN1:9704/xmlpserver to verify the BI Publisher application status.

15.1.12.9.3 Starting and Validating the BI EE System Components on APPHOST1

You can control Oracle Business Intelligence system components using opmnctl commands.

To start the BI EE system components using the OPMNCTL command line:

Go to the directory that contains the OPMN command line tool.

Note:
The OPMN command line tool is in the ORACLE_INSTANCE/bin directory.
Run the opmnctl command to start the BI EE system components:
- opmnctl startall
  
  This command starts OPMN and all BI EE system components.
- opmnctl start
  
  This command starts OPMN only.
- opmnctl startproc ias-component=componentName
  
  This command starts a particular system component. For example, where coreapplication_obips1 is the BI Presentation Services:
```
opmnctl startproc ias-component=coreapplication_obips1
```
Check the status of the BI EE system components:
```
opmnctl status
```

15.1.12.10 Configuring Oracle BI EE

This section describes how to configure Oracle BI EE.

15.1.12.10.1 Setting the Location of the Shared Oracle BI Repository

Perform the following steps in Fusion Middleware Control:

Log into Fusion Middleware Control.
Expand the Business Intelligence node in the Farm_domain_name window.
Click coreapplication.
Click Deployment, then click Repository.
Click Lock and Edit Configuration.
Select Share Repository and specify the Shared Location for the Oracle BI Repository. In a Windows environment, the Enterprise Manager Fusion Middleware Control requires that a UNC path be used to define the shared location of the Repository.
Click Apply.
Click Activate Changes.

15.1.12.10.2 Setting the Shared Global Cache for BI Server

Perform the following steps in Fusion Middleware Control:

Log into Fusion Middleware Control.
Expand the Business Intelligence node in the Farm_domain_name window.
Click coreapplication.
Click Capacity Management, then click Performance.
Click Lock and Edit Configuration.
In the Global Cache section, specify the shared location for the Oracle BI Server Global Cache and specify 250 MB for the global cache size. In a Windows environment, the Enterprise Manager Fusion Middleware Control requires that a UNC path be used to define the shared location of the Oracle BI Server Global Cache.
Click Apply.
Click Activate Changes.

15.1.12.10.3 Setting the Scheduler Script Path and Default Script Path

if you use server-side scripts with Oracle BI Scheduler, it is recommended that you configure a shared directory for the scripts so that they can be shared by all Oracle BI Scheduler components in a cluster.

Perform these steps only if you are using server-side scripts.

To share Oracle BI Scheduler scripts:

Copy the default Oracle BI Scheduler Scripts (for example, ORACLE_INSTANCE/bifoundation/OracleBISchedulerComponent/coreapplication_obisch1/scripts/common) and custom Oracle BI Scheduler scripts (for example, ORACLE_INSTANCE/bifoundation/OracleBISchedulerComponent/coreapplication_obisch1/scripts/scheduler) to the shared BI Scheduler scripts location.
Update the SchedulerScriptPath and DefaultScriptPath elements of the Oracle BI Scheduler instanceconfig.xml file.
- SchedulerScriptPath: Refers to the path where Oracle BI Scheduler-created job scripts are stored. Change this to the path of the shared BI Scheduler scripts location.
- DefaultScriptPath: Specifies the path where user-created job scripts (not agents) are stored. Change this to the path of the shared BI Scheduler scripts location.
You must update this file for each Oracle BI Scheduler component in the deployment

15.1.12.10.4 Setting the Location of the Shared Oracle BI Presentation Catalog

Each Presentation Services instance loads the Oracle BI Presentation Catalog from the catalog location specified in Fusion Middleware Control.

Perform the following steps:

Copy your existing (locally published) Oracle BI Presentation Catalog to the shared location. An example of a locally published catalog is:
```
ORACLE_INSTANCE/bifoundation/OracleBIPresentationServicesComponent/
coreapplication_obipsn/catalog/SampleAppLite
```
You must perform this step before designating the Catalog Location from Fusion Middleware Control.

If you plan to use the SampleAppLite catalog mentioned as an example in this section as the shared catalog, make sure to copy it from APPHOST1.
Log in to Fusion Middleware Control.
Expand the Business Intelligence node in the Farm_domain_name window.
Click coreapplication.
Click Deployment, then click Repository.
Click Lock and Edit Configuration.
Specify the Catalog Location for the shared Oracle BI Presentation Catalog.

In a Windows environment, specify a UNC path name.

Note:
In a Windows environment, you must specify shared storage using the Universal Naming Convention (UNC). UNC is a PC format for specifying resource locations on a local area network. UNC uses the format \\server-name\shared-resource-path-name.
Click Apply.
Click Activate Changes.

15.1.12.11 Scaling Out the BI System on APPHOST2

Follow the steps in Section 15.1.12.2, "Installing Oracle Business Intelligence Enterprise Edition for High Availability" to perform a software-only install of Oracle WebLogic Server and Oracle Business Intelligence on APPHOST2.

Then run the Configuration Assistant from the ORACLE_HOME directory to scale out the BI System.

Change the directory to the location of the Configuration Assistant:
```
APPHOST2> cd ORACLE_HOME/bin
```
Start the Configuration Assistant:
```
APPHOST2> ./config.sh
```
In the Welcome screen, click Next.
On the Prerequisite Checks screen, the installer completes the prerequisite check. If any fail, fix them and restart your installation.

Click Next.
The Create or Scale out BI System screen opens. Select Scale Out BI System and then enter the following values:
- Host Name: ADMINHOST
- Port: 7001
- User name: weblogic
- User Password: Enter the password for the weblogic user.
Click Next.
In the Scale Out BI System Details screen, enter:
- Middleware Home: ORACLE_BASE/product/fmw (grayed out)
- Oracle Home: Oracle_BI1 (grayed out)
- WebLogic Server Home: ORACLE_BASE/product/fmw/wlserver_10.3 (grayed out)
- Domain Home: ORACLE_BASE/product/fmw/user_projects/domain/bifoundation_domain
- Applications Home: ORACLE_BASE/admin/domain_name/mserver/applications
- Instance Home: ORACLE_BASE/product/fmw/instance2
- Instance Name: instance2 (grayed out)
Click Next.
In the Configure Ports screen, select one of the following:
- Auto Port Configuration
- Specify Ports using Configuration File
Click Next.
In the Specify Security Updates screen, choose whether you want to receive security updates from Oracle Support and if you do, enter your email address. Click Next.
In the Summary screen, click Configure.
In the Configuration Progress screen, verify that all the Configuration Tools have completed successfully and click Next.
In the Complete screen, click Finish.

Usually Node Manager starts automatically when config.sh completes. If Node Manager is not running, run these commands to start it on APPHOST2:

APPHOST2> cd WL_HOME/server/bin
APPHOST2> ./startNodeManager.sh

15.1.12.12 Scaling Out BI System Components

To scale out BI System Components, complete these steps in Fusion Middleware Control:

Log into Fusion Middleware Control.
Expand the Business Intelligence node in the Farm_domain_name window.
Click coreapplication.
Click Capacity Management, then click Scalability.
Click Lock and Edit Configuration.
For the APPHOST2 instance2 Oracle instance, increment the Oracle Business Intelligence components by 1:
- BI Servers
- Presentation Services
- JavaHosts
Change the Port Range From and Port Range To to be the same as the APPHOST1 instance1 Oracle instance.
Click Apply.
The following message appears:

Warning: Multiple Presentation Services are configured; adjust the catalog location to point to a shared location.

Click OK. You perform this configuration in a later step.
Click Activate Changes.
Click Restart to apply recent changes.

15.1.12.13 Making Singleton Components Active-Passive

Perform the following steps in Fusion Middleware Control:

Log into Fusion Middleware Control.
Expand the Business Intelligence node in the Farm_domain_name window.
Click coreapplication.
Click Capacity Management, then click Availability.
Click Lock and Edit Configuration to activate the Active/Passive Configuration section of the Availability tab.
Specify the Passive Host/Instance for BI Scheduler and BI Cluster Controller.
Click Apply.

Under Potential Single Points of Failure, it should report "No problems - all components have a backup."
Click Activate Changes.
Click Restart to apply recent changes.

15.1.12.14 Setting the Listen Address for the BI_SERVER2 Managed Server

Perform these steps to set the BI_SERVER2 managed server listen address:

Log into the Oracle WebLogic Server Administration Console.
In the Change Center, click Lock & Edit.
Expand the Environment node in the Domain Structure window.
Click Servers.
Select bi_server2 in the Names column of the table.

The Setting page for bi_server2 opens.
Set the Listen Address to APPHOST2VHN1.
Click Save.
Click Activate Changes.
The changes do not take effect until the BI_SERVER2 managed server restarts.
1. In the Summary of Servers screen, select the Control tab.
2. Select bi_server2 in the table and then click Shutdown.

Restart the BI System components, for example:

cd ORACLE_BASE/admin/instance2/bin
./opmnctl restartproc

15.1.12.14.1 Updating the Oracle BI Publisher Scheduler Configuration on APPHOST1 and APPHOST2

Follow the steps in this section to update the WebLogic JNDI URL for the Oracle BI Publisher Scheduler.

To update the Oracle BI Publisher Scheduler configuration:

http://APPHOST1VHN1:9704/xmlpserver
http://APPHOST2VHN1:9704/xmlpserver

Click the Administration link.
Click Scheduler Configuration under System Maintenance.
Update the WebLogic JNDI URL under JMS Configuration, as follows:
```
t3://APPHOST1VHN1:9704,APPHOST2VHN1:9704
```
Click Apply.
Check the Scheduler status from the Scheduler Diagnostics tab.

15.1.12.15 Disabling Host Name Verification for the BI_SERVER2 Managed Server

This step is required if you have not set up the appropriate certificates to authenticate the different nodes with the Administration Server. If you have not configured the server certificates, you receive errors when managing the different WebLogic Servers. To avoid these errors, disable host name verification while setting up and validating the topology, and enable it again once the high availability topology configuration is complete.

To disable host name verification:

Log into Oracle WebLogic Server Administration Console.
In the Change Center, click Lock & Edit.
Expand the Environment node in the Domain Structure window.
Click Servers.
Select bi_server2 in the Names column of the table.
Open the SSL tab.
Expand the Advanced section of the page.
Set Hostname Verification to None.
Click Save.
Click Activate Changes.

The changes don't take effect until the BI_SERVER2 managed server restarts.

15.1.12.16 Configuring Oracle BI for Microsoft Office SSO Properties

To configure Oracle BI for Microsoft Office Single Sign-On (SSO) properties:

Validate the Oracle BI EE Office Server setup by accessing the following URLs:
- http://APPHOST1VHN1:9704/bioffice/about.jsp
- http://APPHOST2VHN1:9704/bioffice/about.jsp
The About Oracle BI EE Office Server page appears, as shown in Figure 15-7.

Figure 15-7 About Oracle BI EE Office Server Page

Description of "Figure 15-7 About Oracle BI EE Office Server Page"
Go to the Oracle BI EE Office Server directory. For example:

DOMAIN_HOME/servers/managed_server/tmp/_WL_user/bioffice_11.1.1/cvsibb/war/WEB-INF

If you are not sure how to locate the Oracle BI EE Office Server directory, check the LogDir parameter on the About Oracle BI EE Office Server page. The Oracle BI Enterprise Edition Office Server directory is the parent directory of the log directory.

On both APPHOST1 and APPHOST2, open bioffice.xml for editing and modify the BI Office properties shown in Table 15-5.

Table 15-5 Oracle BI for Microsoft Office Properties in bioffice.xml

Property Name	Valid Value	Description
SawBaseURL	https://bi.mydomain.com:443/analytics/saw.dll or https://bi.mydomain.com:443/analytics-ws/saw.dll	Load Balancer Virtual Server Name URL for Oracle BI Presentation Services. Important: If SSO is enabled, enter the URL for the protected analytics servlet that you deployed when configuring Oracle BI for Microsoft Office to integrate with the SSO-enabled Oracle BI Server. Web services requests between the Oracle BI for Microsoft Office Server and Presentation Services use the URL that you specify here.
SawUseSSO	0 = No (Default) 1 = Yes	Set this property to 1 if the Oracle Business Intelligence implementation is enabled for SSO.
SawWebURLforSSO	https://bi.mydomain.com:443/analytics/saw.dll	When SSO is enabled, use this property to enter the public URL that allows external users to access Oracle Business Intelligence using SSO from Oracle BI for Microsoft Office.

Property Name

Valid Value

Description

SawBaseURL

https://bi.mydomain.com:443/analytics/saw.dll

https://bi.mydomain.com:443/analytics-ws/saw.dll

Load Balancer Virtual Server Name URL for Oracle BI Presentation Services.

Important: If SSO is enabled, enter the URL for the protected analytics servlet that you deployed when configuring Oracle BI for Microsoft Office to integrate with the SSO-enabled Oracle BI Server. Web services requests between the Oracle BI for Microsoft Office Server and Presentation Services use the URL that you specify here.

SawUseSSO

0 = No (Default)

1 = Yes

Set this property to 1 if the Oracle Business Intelligence implementation is enabled for SSO.

SawWebURLforSSO

https://bi.mydomain.com:443/analytics/saw.dll

When SSO is enabled, use this property to enter the public URL that allows external users to access Oracle Business Intelligence using SSO from Oracle BI for Microsoft Office.

Restart the Oracle BI for Microsoft Office application, as follows:
1. Log in to the Administration Console.
2. Click Deployments in the Domain Structure window.
3. Select bioffice(11.1.1).
4. Click Stop.
5. After the application stops, click Start.
Validate that the SawBaseURL parameter has been updated on the About Oracle BI EE Office Server page.

15.1.12.16.1 Validating Oracle BI for Microsoft Office Configuration

Follow these steps to validate configuration for Oracle BI for Microsoft Office:

Log in to Oracle BI Presentation Services at:

https://bi.mydomain.com:443/analytics
In the lower left pane, under the Get Started heading, select Download BI Desktop Tools and then select Oracle BI for MS Office.
Install Oracle BI for Microsoft Office by running the Oracle BI for Microsoft Office InstallShield Wizard.
Open Microsoft Excel or Microsoft Powerpoint.
From the Oracle BI menu, select Preferences.
In the Connections tab, select New.
Enter values for the following fields:
- Server Name: Provide a name for the connection.
- BI Office Server: Provide the URL for the Oracle BI for Microsoft Office Server.
- Application Name: Enter the Application Name that you defined for the Oracle BI for Microsoft Office Server when you deployed the Oracle BI for Microsoft Office Server application to WLS. The default name is bioffice.
- Port: Enter the Oracle BI for Microsoft Office Server port number.
Figure 15-8 shows the New Connection dialog.

Figure 15-8 New Connection Dialog for Oracle BI for Microsoft Office

Description of "Figure 15-8 New Connection Dialog for Oracle BI for Microsoft Office"
Click Test Connection to test the connection between the add-in and the Oracle BI for Microsoft Office Server.

Successful connections receive a Test connection successful message, as shown in Figure 15-9.

Figure 15-9 Test Connection Successful Message

Description of "Figure 15-9 Test Connection Successful Message"
Log in as an Administrator (for example, weblogic) and validate that you can access the Oracle BI Task Pane, as shown in Figure 15-10.

Figure 15-10 Oracle BI Task Pane in Microsoft Excel

Description of "Figure 15-10 Oracle BI Task Pane in Microsoft Excel"

15.1.12.17 Configuring Oracle BI Publisher

This section describes how to configure Oracle BI Publisher.

15.1.12.17.1 Setting Server Configuration Options

Follow these steps to set server configuration options for Oracle BI Publisher:

Copy over the contents of DOMAIN_HOME/config/bipublisher/repository to the shared configuration folder location.
Log into BI Publisher with Administrator credentials and select the Administration tab.
Under System Maintenance, select Server Configuration.
Enter the following fields for the Configuration Folder.
- Path: Enter the path of the shared location for the Configuration Folder.
Apply your changes and restart your BI Publisher application.

15.1.12.17.2 Setting Oracle BI Presentation Services Options

Follow these steps to configure Oracle BI Presentation Services Integration options:

Log into Oracle BI Publisher with Administrator credentials and select the Administration tab.
Under Integration, select Oracle BI Presentation Services.
Verify and update the following:
- Server Protocol: http
- Server: bi.mycompany.com
- Port URL Suffix: analytics-ws/saw.dl: 80
Click Apply.
Restart your Oracle BI Publisher application.

15.1.12.17.3 Setting Scheduler Configuration Options

Follow these steps to configure scheduler configuration options:

Log into BI Publisher with Administrator credentials and select the Administration tab.
Under System Maintenance, select Scheduler Configuration.
Select Quartz Clustering under the Scheduler Selection.
Apply your changes and restart your BI Publisher application.

15.1.12.17.4 Setting the Oracle BI EE Data Source

The Oracle BI EE data source must point to the clustered BI Servers via the Cluster Controllers. Perform this task in the Oracle BI Publisher application.

To set the Oracle BI EE data source in BI Publisher:

Log in to BI Publisher with Administrator credentials and select the Administration tab.
Under Data Sources, select JDBC Connection.

Update the Oracle BI EE data source setting by changing the Connection String parameter to the following:

<Primary Cluster Controller Port>/PrimaryCCS=<Primary Cluster Controller Host>;PrimaryCCSPort=<Primary Cluster Controller Port>;SecondaryCCS=<Secondary Cluster Controller Host>;SecondaryCCSPort=<Secondary Cluster Controller Port>;

For example:

jdbc:oraclebi://APPHOST1:9706/PrimaryCCS=APPHOST1;PrimaryCCSPort=9706;SecondaryCCS=APPHOST2;SecondaryCCSPort=9706;

Deselect Use System User and specify the Administrator credentials for Username and Password. For example, weblogic.
Click Test Connection. You should receive "Connection established successfully" message.
Click Apply.

15.1.12.17.5 Configuring JMS for Oracle BI Publisher

You must configure the location for all persistence stores to a directory visible from both nodes. Change all persistent stores to use this shared base directory.

Log into the Oracle WebLogic Server Administration Console.
In the Domain Structure window, expand the Services node and then click the Persistent Stores node.
In the Change Center, click Lock & Edit.
Click on BipJmsStore and enter a directory that is located in the shared storage. This shared storage is accessible from both APPHOST1 and APPHOST2:
```
ORACLE_BASE/admin/domain_name/bi_cluster/jms
```
Click Save and Activate Changes.
In the Domain Structure window, expand the Services node and then click the Persistent Stores node.
In the Change Center, click Lock & Edit.
Click New, and then Create File Store.
Enter a name (for example, BipJmsStore2) and target BI_SERVER2. Enter a directory that is located in shared storage so that it is accessible from both APPHOST1 and APPHOST2:
```
ORACLE_BASE/admin/domain_name/bi_cluster/jms
```
Click OK and activate the changes.
In the Domain Structure window, expand the Services node and then click the Messaging > JMS Servers node.
In the Change Center, click Lock & Edit.
Click New.
Enter a name (for example, BipJmsServer2) and in the Persistence Store drop-down list, select BipJmsStore2 and click Next.
Select BI_SERVER2 as the target.
Click Finish and Activate Changes.
In the Domain Structure window, expand the Services node and then click the Messaging > JMS Modules node.
In the Change Center, click Lock & Edit.
Click BIPJmsResource and then click the Subdeployments tab.
Target the Subdeployment BipJmsSubDeployment to both BipJmsServer1 and BipJmsServer2.
Click Finish and Activate Changes.

To validate the JMS configuration performed for Oracle BI Publisher, perform the steps in Section 15.1.12.7.1, "Updating the Oracle BI Publisher Scheduler Configuration."

15.1.12.17.6 Configuring a Default Persistence Store for Transaction Recovery

Each server has a transaction log, which stores information about committed transactions coordinated by the server that may not have been completed. WebLogic Server uses the transaction log when recovering from system crashes or network failures. To leverage the migration capability of the Transaction Recovery Service for the servers within a cluster, store the transaction log in a location accessible to the server.

Note:

Preferably, this location should be a dual-ported SCSI disk or on a Storage Area Network (SAN).

Perform these steps to set the location for the default persistence store for BI_SERVER1:

Log into the Oracle WebLogic Server Administration Console.
In the Change Center, click Lock & Edit.
In the Domain Structure window, expand the Environment node and then click the Servers node.
Click BI_SERVER1 (represented as a hyperlink) in the Name column of the table.

The settings page for the BI_SERVER1 server opens with the Configuration tab active.
Click the Services tab.
In the Default Store section of the page, enter the path to the folder where the default persistent stores will store its data files. The directory structure of the path is as follows:
```
ORACLE_BASE/admin/domain_name/bi_cluster/tlogs
```
Click Save and Activate Changes.
Repeat these steps for the BI_SERVER2 server.

Note:
To enable migration of the Transaction Recovery Service, specify a location on a persistent storage solution that is available to other servers in the cluster. Both APPHOST1 and APPHOST2 must be able to access this directory. This directory must also exist before you restart the server.

15.1.12.18 Starting the System in APPHOST2

This section describes procedures for starting the system in APPHOST2.

15.1.12.18.1 Starting Node Manager on APPHOST2

Usually, Node Manager is started automatically when config.sh completes. If Node Manager is not running for some reason, start the Node Manager on APPHOST2 by following the instructions in Section 15.1.12.9.1, "Starting Node Manager on APPHOST1."

15.1.12.18.2 Starting and Validating the BI_SERVER2 Managed Server

To start the BI_SERVER2 managed server and check that it is configured correctly:

Start the bi_server2 managed server using Oracle WebLogic Server Administration Console, as follows:
1. Expand the Environment node in the Domain Structure window.
2. Choose Servers.
3. Click the Control tab.
4. Select bi_server2 and then click Start.
Verify that the server status is reported as "Running" in the Administration Console. If the server is shown as "Starting" or "Resuming", wait for the server status to change to "Started". If another status is reported (such as "Admin" or "Failed"), check the server output log files for errors
When BI_SERVER2 is started, the following URLs become available:
- Access http://APPHOST2VHN1:9704/wsm-pm to verify the status of Web Services Manager. Click Validate Policy Manager. A list of policies and assertion templates available in the data opens.
  
  Note:
  The configuration is incorrect if no policies or assertion templates appear.
- Access http://APPHOST2VHN1:9704/xmlpserver to verify the status of the Oracle BI Publisher application.

15.1.12.18.3 Starting and Validating the Business Intelligence Enterprise Edition System Components

To start the BI Enterprise Edition system components on APPHOST2, repeat the steps in Section 15.1.12.9.3, "Starting and Validating the BI EE System Components on APPHOST1" on APPHOST2.

15.1.12.19 Configuring Oracle HTTP Server for the BI_SERVERn Managed Servers

To enable Oracle HTTP Server to route to bi_cluster, which contains the BI_SERVERn managed servers, you must set the WebLogicCluster parameter to the list of nodes in the cluster:

On WEBHOST1 and WEBHOST2, add the following lines to the ORACLE_BASE/product/fmw/Oracle_WT1/instances/web1/config/OHS/ohs1/mod_wl_ohs.conf file:

# BI Office
<Location /bioffice>
   SetHandler weblogic-handler
   WebLogicCluster APPHOST1VHN1:9704,APPHOST2VHN1:9704
   WLProxySSL ON
   WLProxySSLPassThrough ON
</Location>
 
<Location /biofficeclient>
   SetHandler weblogic-handler
   WebLogicCluster APPHOST1VHN1:9704, APPHOST2VHN1:9704
   WLProxySSL ON
   WLProxySSLPassThrough ON
</Location>

# WSM-PM
<Location /wsm-pm>
   SetHandler weblogic-handler
   WebLogicCluster APPHOST1VHN1:9704, APPHOST2VHN1:9704
   WLProxySSL ON
   WLProxySSLPassThrough ON
</Location>

# BIEE Analytics
<Location /analytics>
   SetHandler weblogic-handler
   WebLogicCluster APPHOST1VHN1:9704, APPHOST2VHN1:9704
   WLProxySSL ON
   WLProxySSLPassThrough ON
</Location>

<Location /mapviewer>
   SetHandler weblogic-handler
   WebLogicCluster APPHOST1VHN1:9704, APPHOST2VHN1:9704
   WLProxySSL ON
   WLProxySSLPassThrough ON
</Location>

<Location /analytics-ws>
   SetHandler weblogic-handler
   WebLogicCluster APPHOST1VHN1:9704, APPHOST2VHN1:9704
   WLProxySSL ON
   WLProxySSLPassThrough ON
</Location>

<Location /bimiddleware>
   SetHandler weblogic-handler
   WebLogicCluster APPHOST1VHN1:9704, APPHOST2VHN1:9704
   WLProxySSL ON
   WLProxySSLPassThrough ON
</Location>

# BI Publisher
<Location /xmlpserver>
   SetHandler weblogic-handler
   WebLogicCluster APPHOST1VHN1:9704, APPHOST2VHN1:9704
   WLProxySSL ON
   WLProxySSLPassThrough ON
 </Location>

Perform the same steps for the Oracle HTTP Server on WEBHOST2.

Restart Oracle HTTP Server on WEBHOST1 and WEBHOST2:

WEBHOST1> ORACLE_BASE/product/fmw/Oracle_WT1/instances/web1/bin/
opmnctlrestartproc ias-component=ohs1

WEBHOST2> ORACLE_BASE/product/fmw/Oracle_WT1/instances/web1/bin/
opmnctlrestartproc ias-component=ohs1

15.1.12.19.1 Validating Access Through Oracle HTTP Server

In the Administration Console, verify that the BI Server status is Running. If the status is Starting or Resuming, wait for the server status to change to Started. If the console shows another status (such as Admin), check the server output log files for errors.

Verify that you can access these URLs:

http://WEBHOST1:7777/wsm-pm
http://WEBHOST2:7777/wsm-pm
http://WEBHOST1:7777/analytics
http://WEBHOST2:7777/analytics
http://WEBHOST1:7777/xmlpserver
http://WEBHOST2:7777/xmlpserver
http://WEBHOST1:7777/bioffice/about.jsp
http://WEBHOST2:7777/bioffice/about.jsp
http://WEBHOST1:7777/mapviewer
http://WEBHOST2:7777/mapviewer

Verify that you can access these URLs using your load balancing router address:

http://bi.mycompany.com:80/analytics
http://bi.mycompany.com:80/xmlpserver
http://bi.mycompany.com:80/wsm-pm
http://bi.mycompany.com:80/bioffice/about.jsp
http://bi.mycompany.com:80/mapviewer

Follow these instructions to ensure that routing and failover from the HTTP Server to the bi_cluster is working correctly:

While BI_SERVER2 is running, stop BI_SERVER1 from Oracle WebLogic Server Administration Console.
Access the following URLs and verify the appropriate functionality:
- WEBHOST1:7777/wsm-pm
- WEBHOST1:7777/analytics
- WEBHOST1:7777/xmlpserver
- WEBHOST1:7777/bioffice/about.jsp
Start BI_SERVER1 from Oracle WebLogic Server Administration Console.
Stop BI_SERVER2.
Access the URLs in Step 2 above again and verify the appropriate functionality.

15.1.12.20 Setting the Frontend HTTP Host and Port

You must set the frontend HTTP host and port for the Oracle WebLogic Server cluster. To do this, follow these steps:

In the Change Center of the WebLogic Server Administration Console, click Lock & Edit.
In the left pane, choose Environment in the Domain Structure window and then choose Clusters. The Summary of Clusters page appears.
Select the bi_cluster cluster.
Select HTTP.
Set the values for the following:
- Frontend Host: bi.mycompany.com
- Frontend HTTP Port: 80
- Frontend HTTPS Port: Leave this field blank
  
  Note:
  Make sure this address is correct and available (the load balancer is up). An incorrect value, for example, http:// in the address or trailing / in the hostname, may prevent the BI system from being accessible even when using the virtual IPs to access it.
Click Save.
To activate the changes, click Activate Changes.
Restart the servers to make the Frontend Host directive in the cluster effective.

15.1.12.21 Configuring Server Migration for the BI_SERVERn Servers

In this high availability topology, you must configure server migration for the bi_server1 and bi_server2 Managed Servers. To do this, you configure the bi_server1 Managed Server to restart on APPHOST2 should a failure occur, and you configure the bi_server2 Managed Server to restart on APPHOST1 should a failure occur. For this configuration, the bi_server1 and bi_server2 servers listen on specific floating IPs that are failed over by WLS Server Migration.

This section includes the following topics:

Section 15.1.12.21.1, "Setting Up a User and Tablespace for the Server Migration Leasing Table"
Section 15.1.12.21.2, "Creating a Multi Data Source Using the Oracle WebLogic Server Administration Console"
Section 15.1.12.21.3, "Editing Node Manager's Properties File"
Section 15.1.12.21.4, "Setting Environment and Superuser Privileges for the wlsifconfig.sh Script"
Section 15.1.12.21.5, "Configuring Server Migration Targets"
Section 15.1.12.21.6, "Testing the Server Migration"

15.1.12.21.1 Setting Up a User and Tablespace for the Server Migration Leasing Table

Follow these steps to set up a user and tablespace for the server migration leasing table:

Create a tablespace named leasing. For example, log on to SQL*Plus as the sysdba user and run the following command:

SQL> create tablespace leasing logging datafile 'DB_HOME/oradata/orcl/leasing.dbf' size 32m autoextend on next 32m maxsize 2048m extent management local;

Create a user named leasing and assign to it the leasing tablespace:

SQL> create user leasing identified by welcome1;
SQL> grant create table to leasing;
SQL> grant create session to leasing;
SQL> alter user leasing default tablespace leasing;
SQL> alter user leasing quota unlimited on LEASING;

Create the leasing table using the leasing.ddl script:
1. Copy the leasing.ddl file located in either the WL_HOME/server/db/oracle/817 or the WL_HOME/server/db/oracle/920 directory to your database node.
2. Connect to the database as the leasing user.
3. Run the leasing.ddl script in SQL*Plus:
```
SQL> @Copy_Location/leasing.ddl;
```

15.1.12.21.2 Creating a Multi Data Source Using the Oracle WebLogic Server Administration Console

This section describes how to create a multi data source for the leasing table from the Oracle WebLogic Server Administration Console. You create a data source to each of the Oracle RAC database instances during the process of setting up the multi data source, both for these data sources and the global leasing multi data source. Please note the following considerations when creating a data source:

Ensure that this is a non-XA data source.
The names of the multi data sources are in the format of <MultiDS>-rac0, <MultiDS>-rac1, and so on.
Use Oracle's Driver (Thin) Version 9.0.1, 9.2.0, 10, 11.
Data sources do not require support for global transactions. Therefore, do not use any type of distributed transaction emulation/participation algorithm for the data source (do not choose the Supports Global Transactions option, or the Logging Last Resource, Emulate Two-Phase Commit, or One-Phase Commit options of the Supports Global Transactions option), and specify a service name for your database.
Target these data sources to the Oracle I/PM cluster.
Make sure the initial connection pool capacity of the data sources is set to 0 (zero). To do this, select Services, then JDBC, and then Datasources. In the Datasources screen, click the Datasource Name, then click the Connection Pool tab, and enter 0 (zero) in the Initial Capacity field.

Creating a Multi Data Source

Perform these steps to create a multi data source:

From the Domain Structure window in the Oracle WebLogic Server Administration Console, expand the Services node, then click Data Sources. The Summary of JDBC Data Sources page appears.
In the Change Center, click Lock & Edit.
Click New, then click Multi Data Sources. The Create a New JDBC Multi Data Source page appears.
Enter leasing as the name.
Enter jdbc/leasing as the JNDI name.
Select Failover as algorithm (default).
Click Next.
Select bi_cluster as the target.
Click Next.
Select non-XA driver (the default).
Click Next.
Click Create New Data Source.
Enter leasing-rac0 as the name. Enter jdbc/leasing-rac0 as the JNDI name. Enter oracle as the database type. For the driver type, select Oracle Driver (Thin) for RAC server-Instance connection Version 10,11.

Note:
When creating the multi data sources for the leasing table, enter names in the format of <MultiDS>-rac0, <MultiDS>-rac1, and so on.
Click Next.
Deselect Supports Global Transactions.
Click Next.
Enter the service name, database name (this is actually the RAC Node instance name, for example: racdb1,racdb2), host port, and password for your leasing schema.
Click Next.
Click Test Configuration and verify that the connection works.
Click Next.
Target the data source to bi_cluster.
Select the data source and add it to the right screen.
Click Create a New Data Source for the second instance of your Oracle RAC database, target it to the bi_cluster, and then repeat the steps for the second instance of your Oracle RAC database.
Add the second data source to your multi data source.
Click Activate Changes.

15.1.12.21.3 Editing Node Manager's Properties File

This section describes how to edit the Node Manager properties file, nodemanager.properties. This needs to be done for the Node Managers in both nodes where server migration is being configured:

Interface=eth0
NetMask=255.255.255.0
UseMACBroadcast=true

Interface: This property specifies the interface name for the floating IP (eth0, for example, on Linux).

Note:
Do not specify the sub interface, such as eth0:1 or eth0:2. This interface is to be used without the :0, or :1. The Node Manager's scripts traverse the different :X enabled IPs to determine which to add or remove. For example, the valid values in Linux environments are eth0, eth1, or, eth2, eth3, ethn, depending on the number of interfaces configured.

Note:
For Windows, the Interface should be set to the Network Interface Name. For example: Interface="Local Area Connection".
NetMask: This property specifies the net mask for the interface for the floating IP. The net mask should the same as the net mask on the interface; 255.255.255.0 is used as an example in this document.
UseMACBroadcast: This property specifies whether or not to use a node's MAC address when sending ARP packets, that is, whether or not to use the -b flag in the arping command.

Verify in Node Manager's output (shell where Node Manager is started) that these properties are being used, or problems may arise during migration. You should see something like this in Node Manager's output:

...
StateCheckInterval=500
Interface=eth0 (Linux) or Interface="Local Area Connection" (Windows)
NetMask=255.255.255.0
...

Note:

The steps below are not required if the server properties (start properties) have been properly set and Node Manager can start the servers remotely.

Set the following property in the nodemanager.properties file:
- StartScriptEnabled: Set this property to true. This is required for Node Manager to start the managed servers using start scripts.
Start Node Manager on APPHOST1 and APPHOST2 by running the startNodeManager.sh script, which is located in the WL_HOME/server/bin directory.

Note:

When running Node Manager from a shared storage installation, multiple nodes are started using the same nodemanager.properties file. However, each node may require different NetMask or Interface properties. In this case, specify individual parameters on a per-node basis using environment variables. For example, to use a different interface (eth3) in APPHOSTn, use the Interface environment variable as follows: APPHOSTn> export JAVA_OPTIONS=-DInterface=eth3 and start Node Manager after the variable has been set in the shell.

15.1.12.21.4 Setting Environment and Superuser Privileges for the wlsifconfig.sh Script

This section describes how to set environment and superuser privileges for the wlsifconfig.sh script:

Note:

On Windows, the script is named wlsifconfig.cmd and users with the Administrator privilege can run it.

Ensure that your PATH environment variable includes these files:

Table 15-6 Files Required for the PATH Environment Variable

File	Located in this directory
wlsifconfig.sh	ORACLE_BASE/admin/domain_name/mserver/domain_name/bin/server_migration
wlscontrol.sh	WL_HOME/common/bin
nodemanager.domains	WL_HOME/common

Grant sudo configuration for the wlsifconfig.sh script.
- Configure sudo to work without a password prompt.
- For security reasons, sudo should be restricted to the subset of commands required to run the wlsifconfig.sh script. For example, perform these steps to set the environment and superuser privileges for the wlsifconfig.sh script:
  1. Grant sudo privilege to the WebLogic user ('oracle') with no password restriction, and grant execute privilege on the /sbin/ifconfig and /sbin/arping binaries.
  2. Make sure the script is executable by the WebLogic user ('oracle'). The following is an example of an entry inside /etc/sudoers granting sudo execution privilege for oracle and also over ifconfig and arping:
```
Defaults:oracle !requiretty
oracle ALL=NOPASSWD: /sbin/ifconfig,/sbin/arping
```
Note:
Ask the system administrator for the sudo and system rights as appropriate to this step.

15.1.12.21.5 Configuring Server Migration Targets

This section describes how to configure server migration targets. You first assign all the available nodes for the cluster's members and then specify candidate machines (in order of preference) for each server that is configured with server migration. Follow these steps to configure cluster migration in a migration in a cluster:

Log in to the Oracle WebLogic Server Administration Console (http://Host:Admin_Port/console). Typically, Admin_Port is 7001 by default.
In the Domain Structure window, expand Environment and select Clusters.
Click the cluster for which you want to configure migration (bi_cluster) in the Name column of the table.
Click the Migration tab.
In the Change Center, click Lock & Edit.
In the Available field, select the machine to which to allow migration and click the right arrow. In this case, select APPHOST1 and APPHOST2.
Select the data source to be used for automatic migration. In this case, select the leasing data source.
Click Save.
Click Activate Changes.
Set the candidate machines for server migration. You must perform this task for all of the managed servers as follows:
1. In the Domain Structure window of the Oracle WebLogic Server Administration Console, expand Environment and select Servers.
  
  Tip:
  Click Customize this table in the Summary of Servers page and move Current Machine from the Available window to the Chosen window to view the machine on which the server is running. This will be different from the configuration if the server gets migrated automatically.
2. Select the server for which you want to configure migration.
3. Click the Migration tab.
4. In the Available field, located in the Migration Configuration section, select the machines to which to allow migration and click the right arrow. For bi_server1, select APPHOST2. For bi_server2, select APPHOST1.
5. Select Automatic Server Migration Enabled. This enables Node Manager to start a failed server on the target node automatically.
6. Click Save.
7. Click Activate Changes.
8. Restart the administration server, node managers, and the servers for which server migration has been configured.

15.1.12.21.6 Testing the Server Migration

The final step is to test the server migration. Perform these steps to verify that server migration is working properly:

From APPHOST1:

Force stop the bi_server1 managed server. To do this, run this command:
```
APPHOST1> kill -9 pid
```
where pid specifies the process ID of the managed server. You can identify the pid in the node by running this command:
```
APPHOST1> ps -ef | grep bi_server1
```
Note:
For Windows, the Managed Server can be terminated by using the taskkill command. For example:
```
taskkill /f /pid <pid>
```
Where <pid> is the process Id of the Managed Server.

To determine the process Id of the Managed Server run the following command and identify the pid of the bi_servern Managed Server.
```
MW_HOME\jrockit_160_20_D1.0.1-2124\bin\jps -l -v
```
Watch the Node Manager console. You should see a message indicating that bi_server1's floating IP has been disabled.
Wait for Node Manager to try a second restart of bi_server1. It waits for a fence period of 30 seconds before trying this restart.
Once Node Manager restarts the server, stop it again. Node Manager should now log a message indicating that the server will not be restarted again locally.

From APPHOST2:

Watch the local Node Manager console. After 30 seconds since the last try to restart bi_server1 on APPHOST1, Node Manager on APPHOST2 should prompt that the floating IP for bi_server1 is being brought up and that the server is being restarted in this node.
Access one of the applications (for example, BI Publisher) using the same IP.

Verification From the Administration Console

Migration can also be verified in the Administration Console:

Log in to the Administration Console.
Click Domain on the left console.
Click the Monitoring tab and then the Migration subtype.

The Migration Status table provides information on the status of the migration.

Note:

After a server is migrated, to fail it back to its original node/machine, stop the managed server from the Oracle WebLogic Administration Console and then start it again. The appropriate Node Manager will start the managed server on the machine to which it was originally assigned.

15.1.12.22 Scaling Up the Oracle BI EE Topology

When you scale up the Oracle BI EE topology, you add additional system components to one of the existing nodes in your Oracle BI EE high availability topology.

This section assumes that you already have a high availability topology that includes at least two nodes, with a managed server and a full set of system components on each node. To scale up the topology, you increase the number of system components running on one of your existing nodes.

Note that it is not necessary to run multiple managed servers on a given node.

To scale up the Oracle BI EE topology:

Log in to Fusion Middleware Control.
Expand the Business Intelligence node in the Farm_domain_name window.
Click coreapplication.
Click Capacity Management, then click Scalability.
Click Lock and Edit Configuration.
Use arrow keys to change the number of BI Servers, Presentation Services, or JavaHosts.
Click Apply then click Activate Changes.
Click Overview then click Restart.

15.1.12.23 Scaling Out the Oracle BI EE Topology to a New Node (APPHOST3)

When you scale out the Oracle BI EE topology, you add a new managed server and set of system components to a new node in your topology (APPHOST3). This section assumes that you already have a high availability topology that includes at least two nodes, with a managed server and a full set of system components on each node.

Before performing the steps in this section, check that you meet these requirements:

There must be existing nodes running Oracle Business Intelligence Managed Servers within the topology.
The new node (APPHOST3) can access the existing home directories for Oracle WebLogic Server and Oracle Business Intelligence.
When an ORACLE_HOME or WL_HOME is shared by multiple servers in different nodes, it is recommended that you keep the Oracle Inventory and Middleware home list in those nodes updated for consistency in the installations and application of patches. To update the oraInventory in a node and "attach" an installation in a shared storage to it, use ORACLE_HOME/oui/bin/attachHome.sh. To update the Middleware home list to add or remove a WL_HOME, edit the MW_HOME/.home file. See the steps below.
The new server can use a new individual domain directory or, if the other Managed Servers domain directories reside on shared storage, reuse the domain directories on those servers.

Perform these steps to scale out Oracle Business Intelligence on APPHOST3:

On APPHOST3, mount the existing Middleware home, which should include the Oracle Business Intelligence installation and (optionally, if the domain directory for Managed Servers in other nodes resides on shared storage) the domain directory, and ensure that the new node has access to this directory, just like the rest of the nodes in the domain.
To attach ORACLE_HOME in shared storage to the local Oracle Inventory, run the following command:
```
APPHOST3> cd ORACLE_COMMON_HOME/oui/bin/
APPHOST3> ./attachHome.sh -jreLoc ORACLE_BASE/product/fmw/jrockit_160_<version>
```
To update the Middleware home list, create (or edit, if another WebLogic installation is in the node) the MW_HOME/.home file and add ORACLE_BASE/product/fmw to it.
Enable VIP3 in APPHOST3. See Section 15.1.12.3, "Enabling VIP1 in APPHOST1 and VIP2 in APPHOST2."
Run the Configuration Assistant from one of the shared Oracle homes using the steps in Section 15.1.12.11, "Scaling Out the BI System on APPHOST2" as a guide.
Scale out the system components on APPHOST3 using the steps in Section 15.1.12.12, "Scaling Out BI System Components" as a guide.
Configure the bi_server3 Managed Server by setting the Listen Address and disabling host name verification, using the steps in Section 15.1.12.14, "Setting the Listen Address for the BI_SERVER2 Managed Server" and Section 15.1.12.15, "Disabling Host Name Verification for the BI_SERVER2 Managed Server" as a guide.
Configure JMS for Oracle BI Publisher as Section 15.1.12.17.5, "Configuring JMS for Oracle BI Publisher" describes.
Configure Oracle BI for Microsoft Office on APPHOST3, as described in Section 15.1.12.16, "Configuring Oracle BI for Microsoft Office SSO Properties."
Set the location of the default persistence store for bi_server 3, as described in Section 15.1.12.17.6, "Configuring a Default Persistence Store for Transaction Recovery."
Configure Oracle HTTP Server for APPHOST3VHN1, using the steps in Section 15.1.12.19, "Configuring Oracle HTTP Server for the BI_SERVERn Managed Servers" as a guide.
Start the bi_server3 Managed Server and the system components running on APPHOST3. See Section 15.1.12.9.2, "Starting and Validating the BI_SERVER1 Managed Server" and Section 15.1.12.9.3, "Starting and Validating the BI EE System Components on APPHOST1" for details.
Configure server migration, as described in Section 15.1.12.21.5, "Configuring Server Migration Targets" and Section 15.1.12.21.6, "Testing the Server Migration."
To validate the configuration, access the following URLs:
- http://APPHOST3VHN1:9704/analytics to verify the status of bi_server3.
- http://APPHOST3VHN1:9704/wsm-pm to verify the status of Web Services Manager. Click Validate Policy Manager. A list of policies and assertion templates available in the data opens.
  
  Note: The configuration is incorrect if no policies or assertion templates appear.
- http://APPHOST3VHN1:9704/xmlpserver to verify the status of the Oracle BI Publisher application.
Oracle recommends using host name verification for the communication between Node Manager and the servers in the domain. This requires using certificates for the different addresses communicating with the Administration Server and other servers. See the chapter on setting up Node Manager in the Oracle Fusion Middleware Enterprise Deployment Guide for Oracle Business Intelligence for more detail.

15.2 High Availability for Oracle Business Intelligence Publisher

Oracle Business Intelligence Publisher (Oracle BI Publisher) offers you the most efficient, scalable reporting solution available for complex, distributed environments. It provides a central architecture for generating and delivering information to employees, customers, and suppliers—both securely and in the right format. Oracle BI Publisher reduces the high costs associated with the development, customization and maintenance of business documents, while increasing the efficiency of reports management

This section describes how to design and deploy a high availability environment for Oracle BI Publisher.

This section includes the following topics:

Section 15.2.1, "Oracle BI Publisher Component Architecture"
Section 15.2.2, "Oracle BI Publisher High Availability Concepts"
Section 15.2.3, "Oracle BI Publisher High Availability Configuration Steps"

15.2.1 Oracle BI Publisher Component Architecture

Figure 15-11 shows the Oracle BI Publisher components in a single instance architecture.

Figure 15-11 Oracle BI Publisher Single Instance Architecture

Description of "Figure 15-11 Oracle BI Publisher Single Instance Architecture"

15.2.1.1 Oracle BI Publisher Component Characteristics

Oracle BI Publisher is a Java EE application that uses a servlet based architecture. JMS is used for scheduled jobs execution; Fusion ESS integrates with BI Publisher by means of web services.

15.2.1.1.1 State Information

During the execution of Oracle BI Publisher reports, the session information is stored in memory.

BI Publisher is not a stateless application due to the complexity of migrating report execution across servers.

15.2.1.1.2 Runtime Processes

Oracle BI Publisher is a Java EE component deployed on Oracle WebLogic Server.

Oracle BI Publisher artifact processing, which includes creating, deleting, and editing these artifacts:
- Reports
- Data models
- Layout templates
- Scheduler jobs
- Configuration
Execution of scheduler reports
Execution of online reports

15.2.1.1.3 Process Lifecycle

Oracle BI Publisher depends entirely on the Oracle infrastructure. Use the WebLogic Server Administration Console to deploy, start, stop, and monitor Oracle BI Publisher.

15.2.1.1.4 Request Flow

JMS is used as a backbone to the Oracle BI Publisher batch report processing system. JMS is used as a messaging board in a transactional fashion. Every report is divided into these stages of execution:

Data retrieval
Data formatting
Report delivery

Each of these stages appears as a job request in the JMS queue. If a node goes down, the other nodes continue to service the queue. However, if a report job is in one of these stages of execution—data retrieval, data formatting, or report delivery—the job is marked as failed and you must resubmit it manually.

15.2.1.1.5 External Dependencies

Oracle BI Publisher depends on:

Database repository: for scheduled jobs information.
Storage of Oracle BI Publisher artifacts: These artifacts include reports, definitions, and layouts. The storage is done in two different ways:
- In Oracle Business Intelligence Enterprise Edition mode: Oracle BI Publisher uses Oracle BI Presentation Catalog via a short-lived connection over Web services.
- In standalone mode: Oracle BI Publisher uses a shared file system (such as SAN or NAS).
DBMS for report data: Oracle BI Publisher queries the DBMS to retrieve the report data that needs to be processed.
Web services: for data retrieval.

15.2.1.1.6 Configuration Artifacts

Oracle BI Publisher is a standard Java EE application.

15.2.1.1.7 Deployment Artifacts

Oracle BI Publisher does not have any special deployment artifacts.

15.2.1.1.8 Log Files

Oracle BI Publisher is a Java EE application deployed on Oracle WebLogic Server. All log messages are logged in the server log file of the Oracle WebLogic Server that the application is deployed on. The default location of the server log is:

WEBLOGIC_SERVER_HOME/user_projects/domains/domainName/servers/serverName/logs/
serverName-diagnostic.log

15.2.2 Oracle BI Publisher High Availability Concepts

This section provides conceptual information about using Oracle BI Publisher in a high availability environment.

15.2.2.1 Oracle BI Publisher High Availability Architecture

Figure 15-12 shows an Oracle BI Publisher high availability architecture.

Figure 15-12 Oracle BI Publisher High Availability Architecture

Description of "Figure 15-12 Oracle BI Publisher High Availability Architecture"

In Figure 15-12, incoming requests are received by the hardware load balancer, which routes them to WEBHOST1 or WEBHOST2 in the web tier. These hosts have Oracle HTTP Server installed.

The Oracle WebLogic Server on which Oracle BI Publisher runs is installed on APPHOST1 and APPHOST2 in the application tier. The Administration Server on APPHOST2 is passive. The Administration Server can be made active on APPHOST2 if APPHOST1 becomes unavailable, as described in Chapter 3, "High Availability for WebLogic Server." Oracle BI Publisher is deployed on the BI_SERVER1 and BI_SERVER2 managed servers on these hosts. These managed servers are configured in an Oracle WebLogic cluster that allows them to work in an active-active manner. Whole server migration is configured for the managed servers.

The BI domain uses virtual hostnames as the listen addresses for the BI managed servers. You must enable VIP mapping for each of these hostnames on the two BI Machines, (VIP1 on APPHOST1 and VIP2 on APPHOST2), and must correctly resolve the virtual hostnames in the network system used by the topology (either by DNS Server or by hosts resolution). Section 15.1.12.21, "Configuring Server Migration for the BI_SERVERn Servers" provides more details on configuring server migration for the BI servers.

In the data tier, shared external storage is set up to store Oracle BI Publisher Repository metadata such as record definitions, report layouts, and data models, as well as the Oracle BI Publisher JMS persistence store.

An Oracle RAC database is used for reports data, and is also recommended for the enterprise database.

Oracle BI Publisher supports an active-active high availability configuration. Each node acts as an independent server that shares a common repository and the scheduler database with the other Oracle BI Publisher nodes.

The Oracle BI Publisher repository (which contains all content, such as reports and data models) is stored in the Oracle BI Presentation Catalog when BI Publisher is configured with Oracle BI EE, and it is stored on a shared file system when Oracle BI Publisher is installed by itself.

The Oracle BI Publisher configuration folder must be on a shared file system.

The shared repository stores the following Oracle BI Publisher artifacts:

Report definitions
Report templates
Data models
Oracle BI Publisher configuration

The Scheduler database is a shared database that stores the following information:

Details about the reports (parameters)
Execution status
Execution history
Snapshots of previous report runs

A hardware or software load balancer can be used as a front end to the Oracle BI Publisher nodes in a high availability environment.

In a high availability deployment of Oracle BI Publisher:

Sticky sessions should be enabled for the load balancer.
Oracle BI Publisher depends on the WebLogic Server JMS failover mechanism.
All the Oracle BI Publisher instances in the cluster are independent.
Artifacts and configurations are stored in the shared repository, and each instance reads the repository independently.

15.2.2.1.1 Shared Files and Directories

The Oracle BI Publisher shared files are the shared repository and Scheduler database described in the previous section.

15.2.2.1.2 Cluster-Wide Configuration Changes

The Configuration Folder contains all configuration, security, and data sources that you set up with BI Publisher. When the Configuration Folder is on shared storage, any changes made will be applied to all nodes in the cluster.

15.2.2.2 Protection from Failures and Expected Behaviors

Node Manager can be set up to restart a failed Oracle BI Publisher instance.

When an Oracle BI Publisher instance restarts, it does not affect the other running instances.

When a node fails, the behavior is:

In a deployment where single sign-on is not implemented, the user will be asked to log in again.
Any transaction that included editing is saved.

15.2.2.3 Troubleshooting

Oracle BI Publisher logging is included in the WebLogic Server logs in the default location:

DOMAIN_HOME/servers/serverName/logs/serverName-diagnostic.log

Also, the following file includes BI Publisher related messages:

DOMAIN_HOME/servers/serverName/logs/bipublisher/bipublisher.log

Configuration information is stored in the shared repository. The configuration files are stored under the Admin directory in the shared repository.

15.2.3 Oracle BI Publisher High Availability Configuration Steps

This section describes how to set up a two node highly available configuration for Oracle BI Publisher. The architecture targeted for the configuration steps is shown in Figure 15-12.

Note:

Oracle strongly recommends reading the release notes for any additional installation and deployment considerations prior to starting the setup process.

15.2.3.1 Preparing the Environment: Prerequisite Steps Before Setting Up an Oracle BI Publisher High Availability Configuration

This section includes the prerequisites for setting up the BI Publisher high availability configuration.

15.2.3.1.1 Database Prerequisites

Oracle BI Publisher supports the following database versions:

Oracle Database 10g (10.2.0.4 or later for non-XE database)
Oracle Database 11g (11.1.0.7 or later for non-XE database)

To determine the database version, execute this query:

SQL>select version from sys.product_component_version where product like 'Oracle%';

15.2.3.1.2 VIP and IP Prerequisites

Table 15-7 BI Publisher Virtual Hosts

Virtual IP	Virtual IP Maps To	Description
VIP1	APPHOST1VHN1	APPHOST1VHN1 is the virtual host name that makes to the listen address for BI_SERVER1 and fails over with server migration of this managed server. It is enabled on the node where BI_SERVER1 process is running (APPHOST1 by default).
VIP2	APPHOST2VHN1	APPHOST2VHN1 is the virtual host name that makes to the listen address for BI_SERVER2 and fails over with server migration of this managed server. It is enabled on the node where BI_SERVER2 process is running (APPHOST2 by default).

15.2.3.1.3 Shared Storage Prerequisites

Table 15-8 Contents of BI Publisher Shared Storage

Server	Type of Data	Volume in Shared Storage	Directory	Files
BI_SERVER1 and BI_SERVER2	Transaction logs	VOL2	ORACLE_BASE/admin/domain_name/bi_cluster_name/tlogs	Common location (stores decided by WebLogic Server)
BI_SERVER1 and BI_SERVER2	JMS stores	VOL2	ORACLE_BASE/admin/domain_name/bi_cluster_name/jms	Common location, but individual store per server. For example: BipJmsStore for BI_SERVER1 and BipJmsStore2 for BI_SERVER2)
BI_SERVER1 and BI_SERVER2	BI Publisher Configuration folder	VOL1	ORACLE_BASE/domain_name/config/bipublisher/repository	Common location
BI_SERVER1 and BI_SERVER2	BI Publisher Catalog repository	VOL1	ORACLE_BASE/domain_name/config/bipublisher/catalog	Common location
BI_SERVER1 and BI_SERVER2	BI Publisher Scheduler Temp directory	VOL1	ORACLE_BASE/domain_name/config/bipublisher/temp	Common location

The shared storage can be a NAS or SAN device. The following is an example command based on a NAS device. Your options may be different from the ones specified in this section.

APPHOST1> mount nasfiler:/vol/volX/FMWshared MW_HOME-t nfs -o
rw,bg,hard,nointr,tcp,vers=3,timeo=300,rsize=32768,wsize=32768

15.2.3.1.4 Clock Synchronization

15.2.3.1.5 Installing and Configuring the Database Repository

This section describes how to install and configure the database repository.

Oracle Clusterware

For 10g Release 2 (10.2), see Oracle Database Oracle Clusterware and Oracle Real Application Clusters Installation Guide.
For 11g Release 1 (11.1) and later, see Oracle Clusterware Installation Guide.

Automatic Storage Management

For 10g Release 2 (10.2), see Oracle Database Oracle Clusterware and Oracle Real Application Clusters Installation Guide.
For 11g Release 1 (11.1) and later, see Oracle Real Application Clusters Installation Guide.

When you run the installer, select the Configure Automatic Storage Management option in the Select Configuration page to create a separate Automatic Storage Management home.

Oracle Real Application Clusters

For 10g Release 2 (10.2), see Oracle Database Oracle Clusterware and Oracle Real Application Clusters Installation Guide.
For 11g Release 1 (11.1) and later, see Oracle Real Application Clusters Installation Guide.

Use the latest version of RCU to install the 11g (11.1.1.) Oracle Fusion Middleware Repository into an Oracle RAC database.

See Oracle Fusion Middleware Repository Creation Utility User's Guide for more information about obtaining and running the latest version of RCU.

15.2.3.1.6 Using RCU to Load the Business Intelligence Schemas in the Database

Install the 11g (11.1.1) Oracle Fusion Middleware Metadata Store and Oracle BI schemas into an Oracle RAC database before you install Oracle BI Publisher. Follow these steps:

Insert the Repository Creation Utility (RCU) DVD, and then start RCU from the bin directory in the RCU home directory.
```
prompt> cd RCU_HOME/bin
prompt> ./rcu
```
In the Welcome screen, click Next.
In the Create Repository screen, select Create to load component schemas into a database. Click Next.
In the Database Connection Details screen, enter connect information for your database:
- Database Type: Select Oracle Database.
- Host Name: Specify the name of the node on which the database resides. For the Oracle RAC database, specify the VIP name or one of the node names as the host name, for example:
  
  BIDBHOST1-VIP
- Port: Specify the listen port number for the database: 1521
- Service Name: Specify the service name of the database:
  
  biha.mycompany.com
- Username: Specify the name of the user with DBA or SYSDBA privilege: SYS
- Password: Enter the password for the SYS user.
- Role: Select the database user's role from the list: SYSDBA (required by the SYS user).
Click Next.
In the Select Components screen:
- Select Create a new Prefix, and enter a prefix to use for the database schemas, for example, BIHA. You can specify up to six characters as a prefix. Prefixes are used to create logical groupings of multiple repositories in a database. For more information, see Oracle Fusion Middleware Repository Creation Utility User's Guide.
  
  Tip:
  Note the name of this schema because the upcoming steps require this information.
- Select the following components:
```
o  AS Common Schemas: Metadata Services (automatically selected)
o  Oracle Business Intelligence: Business Intelligence Platform
```
Click Next.
In the Schema Passwords screen, enter passwords for the main schema users, and click Next.

You can choose either Use same passwords for all schemas or Specify different passwords for all schemas, depending on your requirements.

Do not select Use main schema passwords for auxiliary schemas. The auxiliary passwords are derived from the passwords of the main schema users.

Tip:
Note the names of the schema passwords because the upcoming steps require this information.
In the Map Tablespaces screen, choose the tablespaces for the selected components, and click Next.
In the Summary screen, click Create.
In the Completion Summary screen, click Close.

15.2.3.1.7 Configuring Virtual Server Names and Ports for the Load Balancer

This section describes the load balancer prerequisites for deploying an Oracle BI Publisher high availability environment.

Load Balancers

BI Publisher uses a hardware load balancer when deployed in a high availability configuration with two Oracle HTTP Servers as web tier components.

Virtual Server Names

15.2.3.1.8 Installing Oracle HTTP Server on WEBHOST1 and WEBHOST2

This section describes how to install Oracle HTTP Server on WEBHOST1.

Verify that the servers meet the following requirements:
- Ensure that the system, patch, kernel and other requirements are met. These are listed in the Oracle Fusion Middleware Installation Guide for Oracle Web Tier in the Oracle Fusion Middleware documentation library for the platform and version you are using.
- Ensure that port 7777 is not in use by any service on WEBHOST1 by issuing these commands for the operating system you are using. If a port is not in use, no output is returned from the command.
  
  On UNIX:
```
netstat -an | grep "7777"
```
  On Windows:
```
netstat -an | findstr :7777
```
  If the port is in use (if the command returns output identifying the port), you must free the port.
  
  On UNIX:
  
  Remove the entries for port 7777 in the /etc/services file and restart the services, or restart the computer.
  
  On Windows:
  
  Stop the component that is using the port.
- Copy the staticports.ini file from the Disk1/stage/Response directory to a temporary directory.
- Edit the staticports.ini file that you copied to the temporary directory to assign the following custom ports (uncomment the line where you specify the port number for Oracle HTTP Server):
```
# The port for Oracle HTTP server
Oracle HTTP Server port = 7777
```
Start the Oracle Universal Installer for Oracle Fusion Middleware 11g Web Tier Utilities CD installation as follows:

On UNIX:

Issue the command: ./runinstaller

On Windows:

Double-click setup.exe.

This displays the Specify Inventory Directory screen.
On the Specify Inventory Directory screen, enter values for the Oracle Inventory Directory and the Operating System Group Name. For example:

Specify the Inventory Directory: /u01/app/oraInventory

Operating System Group Name: oinstall

A dialog box appears with the following message:

"Certain actions need to be performed with root privileges before the install can continue. Please execute the script /u01/app/oraInventory/createCentralInventory.sh now from another window and then press "Ok" to continue the install. If you do not have the root privileges and wish to continue the install select the "Continue installation with local inventory" option"

Log in as root and run the "/u01/app/oraInventory/createCentralInventory.sh"

This sets the required permissions for the Oracle Inventory Directory and then brings up the Welcome screen.
Note:
The Oracle Inventory screen is not shown if an Oracle product was previously installed on the host. If the Oracle Inventory screen does not appear for this installation, verify:
- If the /etc/oraInst.loc file exists.
- If the file exists, the Inventory directory listed is valid.
- Whether or not the user performing the installation has write permissions for the Inventory directory.
On the Welcome screen, click Next.
On the Select Installation Type screen, select Install and Configure, and click Next.
On the Prerequisite Checks screen, the installer completes the prerequisite check. If any fail, fix them and restart your installation.

Click Next.
On the Specify Installation Location screen, specify:
- Oracle Middleware Home: ORACLE_BASE/product/fmw (grayed out)
- Oracle Home Directory: Oracle_WT1
Click Next.
On the Configure Components screen:
- Select Oracle HTTP Server.
- Do not select Associate Selected Components with Weblogic Domain.
Click Next.
On the Specify Component Details screen, enter the following values for WEBHOST1:
- Instance Home Location: ORACLE_BASE/product/fmw/Oracle_WT1/instances/web1
- Instance Name: web1
- OHS Component Name: ohs1
Click Next.
On the Configure Ports screen:
- If you specify a custom port, select Specify Ports using Configuration File and then use the Browse function to select the file.
- Enter the Oracle HTTP Server port, for example: 7777
Click Next.
In the Specify Security Updates screen, choose whether you want to receive security updates from Oracle Support and if you do, enter your email address and click Next.
On the Installation Summary screen, ensure that the selections are correct. If they are not, click Back and make the necessary fixes. After ensuring that the selections are correct, click Install.
On the Installation Progress screen on UNIX systems, a dialog appears that prompts you to run the oracleRoot.sh script. Open a window and run the script, following the prompts in the window.

Click Next.
On the Configuration Progress screen, multiple configuration assistants are launched in succession; this process can be lengthy. Click Next.
On the Installation Complete screen, click Finish to exit.

Repeat the steps for WEBHOST2 and configure your load balancer with a pool containing both the WEBHOST1 and WEBHOST2 addresses.

15.2.3.1.9 Validating Oracle HTTP Server

To verify that Oracle HTTP Server is set up correctly, access the root URL context of the server by using the following URLs in the browser:

http://WEBHOST1:7777/
http://WEBHOST2:7777/

If Oracle HTTP Server is set up correctly, the Oracle FMW Welcome screen appears in the browser.

15.2.3.2 Installing Oracle Fusion Middleware Home

This section describes the procedure for installing Oracle Fusion Middleware on all nodes in the application tier that run Oracle WebLogic Server and Oracle Fusion Middleware BI EE. Repeat the procedure (described below for APPHOST1) for installing WebLogic Server and BI Publisher in APPHOST2. The directory paths for binary files and domains used when installing new nodes must be exactly the same as those used for first node.

Install the following Oracle Fusion Middleware components:

Oracle WebLogic Server
Oracle Fusion Middleware BI EE

15.2.3.2.1 Installing Oracle WebLogic Server

Follow these steps to install Oracle WebLogic Server:

Start the installer for Oracle WebLogic Server from the installation media.
In the Welcome screen, click Next.
In the Choose Middleware Home Directory screen:
- Select Create a new Middleware Home.
- For the Middleware Home Directory, enter ORACLE_BASE/product/fmw
  
  Note:
  ORACLE_BASE is the base directory under which Oracle products are installed. The recommended value is /u01/app/oracle.
Click Next.
In the Register for Security Updates screen, choose whether you want to receive security updates from Oracle Support and if you do, enter your email address. Click Next.
In the Choose Install Type screen, select Typical and click Next.
In the Choose Product Installation Directories screen, accept the directory ORACLE_BASE/product/fmw/wlserver_10.3 for WebLogic Server and ORACLE_BASE/product/fmw/coherence_3.6 for Oracle Coherence and click Next.
In the Installation Summary screen, click Next.

The Oracle WebLogic Server software is installed.
In the Installation Complete screen, clear the Run Quickstart check box and click Done.

15.2.3.2.2 Installing Oracle Fusion Middleware for BI Publisher

Start the installer for Oracle Fusion Middleware Business Intelligence 11g from the installation media:

On UNIX:
```
APPHOST1>./runInstaller
```
On Windows:
```
APPHOST1> setup.exe
```
In the Specify Inventory Directory screen:
- Enter HOME/oraInventory, where HOME is the home directory of the user performing the installation (this is the recommended location).
- Enter the OS group for the user performing the installation.
  
  Click Next.
- Follow the instructions on screen to execute /createCentralnventory.sh as root.
  
  Click OK.
In the Welcome screen, click Next.
In the Select Installation Type screen, select Software Only Install and click Next.
In the Prerequisite Checks screen, verify that all checks complete successfully, and click Next.
In the Specify Installation Location screen, select the previously installed Middleware Home from the drop-down list. For the Oracle Home directory, enter the directory name (Oracle_BI1).

Click Next.
In the Specify Security Updates screen, choose whether you want to receive security updates from Oracle Support and if you do, enter your email address and click Next.
In the Summary screen, click Install.
In the Installation Progress screen, click Next.
In the Complete screen, click Finish.

15.2.3.3 Enabling VIP1 in APPHOST1 and VIP2 in APPHOST2

15.2.3.4 Creating a Domain with the Administration Server and the First BI_SERVER1 Managed Server

Note:

Oracle strongly recommends that you read the release notes for any additional installation and deployment considerations prior to starting the setup process.

Run the Configuration Assistant from the Oracle home directory to create a domain containing the Administration Server and the managed server with BI Publisher:

Change the directory to the location of the Configuration Assistant:
```
APPHOST1> cd ORACLE_HOME/bin
```
Start the Configuration Assistant:

On UNIX:
```
APPHOST1> ./config.sh
```
On Windows:
```
APPHOST1> config.cmd
```
In the Welcome screen, click Next.
In the Prerequisite Checks screen, verify that all checks complete successfully and click Next.
The Create or Scale Out BI System screen opens. Select Create New BI System and specify the following:
- User Name: weblogic
- User Password: Enter the weblogic user password.
- Domain Name: bifoundation_domain
Click Next.
In the Specify Installation Location screen, enter:
- Middleware Home: ORACLE_BASE/product/fmw (grayed out)
- Oracle Home: ORACLE_BASE/product/fmw/Oracle_BI1 (grayed out)
- WebLogic Server Home: ORACLE_BASE/product/fmw/wlserver_10.3 (grayed out)
- Domain Home: ORACLE_BASE/product/fmw/user_projects/domain/bifoundation_domain
  
  Note:
  The Domain Home must end with the domain name.
- Instance Home: ORACLE_BASE/product/fmw/instance1
- Instance Name: instance1
Click Next.
In the Configure Components screen, select Business Intelligence Publisher.

Click Next.
In the BIPLATFORM Schema screen, enter:
- Database Type: Oracle Database
- Connect String: BIDBHOST1:1521:BIDB1^BIDBHOST2:1521:BIDB2@BIHA.MYCOMPANY.COM
- BIPLATFORM Schema Username: BIHA_BIPLATFORM
- BIPLATFORM Schema Password: Enter the password for the BIPLATFORM schema user.
Click Next.
In the Configure Ports screen, select one of the following:
- Auto Port Configuration
- Specify Ports using Configuration File
Click Next.
In the Specify Security Updates screen, choose whether you want to receive security updates from Oracle Support and if you do, enter your email address. Click Next.
In the Summary screen, click Configure.
In the Configuration Progress screen, verify that all the Configuration Tools have completed successfully and click Next.
In the Complete screen, click Finish.

15.2.3.5 Creating boot.properties for the Administration Server on APPHOST1

Go to the following directory:

ORACLE_BASE/product/fmw/user_projects/domains/bifoundation_domain/servers/
AdminServer/security

Enter the following lines in the file, save the file, and close the editor:
```
username=Admin_username
password=Admin_password
```
Note:
When you start the Administration Server, the username and password entries in the file are encrypted.
For security reasons, minimize the time the entries in the file are left unencrypted. After you edit the file, start the server as soon as possible for the entries to be encrypted.

15.2.3.6 Starting and Validating the Administration Server on APPHOST1

This section describes procedures for starting and validating the Administration Server on APPHOST1.

15.2.3.6.1 Starting the Administration Server on APPHOST1

To start the Administration Server on APPHOST1, run the following commands:

APPHOST1> cd MW_HOME/user_projects/domains/bifoundation_domain/bin
APPHOST1> ./startWebLogic.sh

15.2.3.6.2 Validating the Administration Server

verify that the Administration Server is properly configured:

In a browser, go to http://APPHOST1:7001/console.
Log in as the administrator.
Verify that the BI_SERVER1 managed server is listed.
Verify that the bi_cluster cluster is listed.
Verify that you can access Enterprise Manager at http://APPHOST1:7001/em.

15.2.3.7 Setting the Listen Address for BI_SERVER1 Managed Server

Perform these steps to set the managed server listen address:

Log into the Oracle WebLogic Server Administration Console.
In the Change Center, click Lock & Edit.
Expand the Environment node in the Domain Structure window.
Click Servers.
Select bi_server1 in the Names column of the table.
Set the Listen Address to APPHOST1VHN1.
Click Save.
Save and activate the changes.

The changes will not take effect until the BI_SERVER1 managed server is restarted.

15.2.3.8 Disabling Host Name Verification for the BI_SERVER1 Managed Server

This step is required if you have not set up the appropriate certificates to authenticate the different nodes with the Administration Server. If you have not configured the server certificates, you will receive errors when managing the different WebLogic Servers. To avoid these errors, disable host name verification while setting up and validating the topology, and enable it again once the high availability topology configuration is complete.

To disable host name verification:

Log into Oracle WebLogic Server Administration Console.
In the Change Center, click Lock & Edit.
Expand the Environment node in the Domain Structure window.
Click Servers.
Select bi_server1 in the Names column of the table. The settings page opens.
Open the SSL tab.
Expand the Advanced section of the page.
Set Hostname Verification to None.
Click Save.
Save and activate the changes.
The change will not take effect until the BI_SERVER1 managed server is restarted.

15.2.3.9 Starting the System in APPHOST1

This section describes how to start Node Manager on APPHOST1 and how to start and validate the BI_SERVER1 managed server on APPHOST1.

15.2.3.9.1 Starting Node Manager on APPHOST1

Usually, Node Manager is started automatically when config.sh completes. If Node Manager is not running for some reason, start it on APPHOST1 using these commands:

APPHOST1> cd WL_HOME/server/bin
APPHOST1> ./startNodeManager.sh

15.2.3.9.2 Starting and Validating the BI_SERVER1 Managed Server

To start the BI_SERVER1 managed server and check that it is configured correctly:

Start the bi_server1 managed server using Oracle WebLogic Server Administration Console, as follows:
1. Expand the Environment node in the Domain Structure window.
2. Choose Servers.
3. Click the Control tab.
4. Select bi_server1 and then click Start.
Verify that the server status is reported as "Running" in the Administration Console. If the server is shown as "Starting" or "Resuming", wait for the server status to change to "Started". If another status is reported (such as "Admin" or "Failed"), check the server output log files for errors
When BI_SERVER1 is started, the following URLs become available:
- Access http://APPHOST1VHN1:9704/wsm-pm to verify the status of Web Services Manager. Click Validate Policy Manager.
  
  Note:
  The configuration is incorrect if no policies or assertion templates appear.
- Access http://APPHOST1VHN1:9704/xmlpserver to verify the status of the BI Publisher application.

15.2.3.10 Prerequisites for Scaling Out the BI System on APPHOST2

This section includes prerequisite tasks to perform before scaling out the BI system on APPHOST2.

15.2.3.10.1 Setting Server Configuration Options

Follow these steps to configure server configuration options:

Copy over the contents of DOMAIN_HOME/config/bipublisher/repository to the shared configuration folder location.
Log into BI Publisher with Administrator credentials and select the Administration tab.
Under System Maintenance, select Server Configuration.
Enter the following fields for the Configuration Folder.
- Path: Enter the path of the shared location for the Configuration Folder.
Apply your changes and restart your BI Publisher application.

15.2.3.10.2 Setting Scheduler Configuration Options

Follow these steps to configure scheduler configuration options:

Log into BI Publisher with Administrator credentials and select the Administration tab.
Under System Maintenance, select Scheduler Configuration.
Select Quartz Clustering under the Scheduler Selection.
Apply your changes and restart your BI Publisher application.

15.2.3.10.3 Updating the Oracle BI Publisher Scheduler Configuration

Follow the steps in this section to update the WebLogic JNDI URL and the JMS Shared Temp directory for the Oracle BI Publisher Scheduler.

To update the Oracle BI Publisher Scheduler configuration:

http://APPHOST1VHN1:9704/xmlpserver
http://APPHOST2VHN1:9704/xmlpserver

Click the Administration link.
Click Scheduler Configuration under System Maintenance.
Update the WebLogic JNDI URL under JMS Configuration, as follows:
```
t3://APPHOST1VHN1:9704,APPHOST2VHN1:9704
```
Update the Shared Directory by entering a directory that is located in the shared storage. This shared storage is accessible from both APPHOST1 and APPHOST2.Continue with the rest of the steps.
Click Apply.
Check the Scheduler status from the Scheduler Diagnostics tab.

15.2.3.11 Scaling Out the BI System on APPHOST2

Run the Configuration Assistant from the ORACLE_HOME directory to scale out the BI System.

Change the directory to the location of the Configuration Assistant:
```
APPHOST2> cd ORACLE_HOME/bin
```
Start the Configuration Assistant:
```
APPHOST2> ./config.sh
```
In the Welcome screen, click Next.
On the Prerequisite Checks screen, the installer completes the prerequisite check. If any fail, fix them and restart your installation.

Click Next.
Select Scale Out BI System and then enter the following values:
- Host Name: ADMINHOST
- Port: 7001
- User name: weblogic
- User Password: Enter the password for the weblogic user.
Click Next.
In the Scale Out BI System Details screen, enter:
- Middleware Home: ORACLE_BASE/product/fmw (grayed out)
- Oracle Home: Oracle_BI1 (grayed out)
- WebLogic Server Home: ORACLE_BASE/product/fmw/wlserver_10.3 (grayed out)
- Domain Home: ORACLE_BASE/product/fmw/user_projects/domain/bifoundation_domain
  
  Note:
  The Domain Home must end with the domain name.
- Instance Home: ORACLE_BASE/product/fmw/instance2
- Instance Name: instance2 (grayed out)
Click Next.
In the Configure Ports screen, select one of the following:
- Auto Port Configuration
- Specify Ports using Configuration File
Click Next.
In the Specify Security Updates screen, choose whether you want to receive security updates from Oracle Support and if you do, enter your email address. Click Next.
In the Summary screen, click Configure.
In the Configuration Progress screen, verify that all the Configuration Tools have completed successfully and click Next.
In the Complete screen, click Finish.

15.2.3.12 Setting the Listen Address for the BI_SERVER2 Managed Server

Perform these steps to set the BI_SERVER2 managed server listen address:

Log into the Oracle WebLogic Server Administration Console.
In the Change Center, click Lock & Edit.
Expand the Environment node in the Domain Structure window.
Click Servers.
Select bi_server2 in the Names column of the table.
Set the Listen Address to APPHOST2VHN1.
Click Save.
Save and activate the changes.

Changes take effect when the BI_SERVER2 managed server restarts.

15.2.3.13 Disabling Host Name Verification for the BI_SERVER2 Managed Server

This step is required if you have not set up the appropriate certificates to authenticate the different nodes with the Administration Server. If you have not configured the server certificates, you will receive errors when managing the different WebLogic Servers. To avoid these errors, disable host name verification while setting up and validating the topology, and enable it again once the high availability topology configuration is complete.

To disable host name verification:

Log into Oracle WebLogic Server Administration Console.
In the Change Center, click Lock & Edit.
Expand the Environment node in the Domain Structure window.
Click Servers.
Select bi_server2 in the Names column of the table.
Open the SSL tab.
Expand the Advanced section of the page.
Set Hostname Verification to None.
Click Save.
Save and activate the changes.
The change does not take effect until you restart the BI_SERVER2 managed server.

15.2.3.14 Configuring Oracle BI Publisher

This section describes how to configure Oracle BI Publisher.

15.2.3.14.1 Configuring JMS Persistence Store for BI Publisher

You must configure the location for all persistence stores to a directory visible from both nodes. Change all persistent stores to use this shared base directory.

Log into the Oracle WebLogic Server Administration Console.
In the Domain Structure window, expand the Services node and then click the Persistent Stores node.
In the Change Center, click Lock & Edit.
Click on BipJmsStore and enter a directory that is located in the shared storage. This shared storage is accessible from both APPHOST1 and APPHOST2:
```
ORACLE_BASE/admin/domain_name/bi_cluster/jms
```
Click Save and Activate Changes.
In the Domain Structure window, expand the Services node and then click the Persistent Stores node.
In the Change Center, click Lock & Edit.
Click New, and then Create File Store.
Enter a name (for example, BipJmsStore2) and target BI_SERVER2. Enter a directory that is located in shared storage so that it is accessible from both APPHOST1 and APPHOST2:
```
ORACLE_BASE/admin/domain_name/bi_cluster/jms
```
Click OK and activate the changes.
In the Domain Structure window, expand the Services node and then click the Messaging > JMS Servers node. The Summary of JMS Servers page opens.
In the Change Center, click Lock & Edit.
Click New.
Enter a name (for example, BipJmsServer2) and in the Persistence Store drop-down list, select BipJmsStore2 and click Next.
Select BI_SERVER2 as the target.
Click Finish and Activate Changes.
In the Domain Structure window, expand the Services node and then click the Messaging > JMS Modules node.
In the Change Center, click Lock & Edit.
Click BIPJmsResource and then click the Subdeployments tab.
Target the Subdeployment BipJmsSubDeployment to both BipJmsServer1 and BipJmsServer2.
Click Finish and Activate Changes.

To validate the JMS configuration performed for Oracle BI Publisher, perform the steps in Section 15.2.3.10.3, "Updating the Oracle BI Publisher Scheduler Configuration."

15.2.3.14.2 Configuring a Default Persistence Store for Transaction Recovery

Note:

Preferably, this location should be a dual-ported SCSI disk or on a Storage Area Network (SAN).

Perform these steps to set the location for the default persistence store for BI_SERVER1:

Log into the Oracle WebLogic Server Administration Console.
In the Domain Structure window, expand the Environment node and then click the Servers node.
Click BI_SERVER1 (represented as a hyperlink) in the Name column of the table.

The settings page for the BI_SERVER1 server opens with the Configuration tab active.
Click the Services tab.
In the Change Center, click Lock & Edit.
In the Default Store section of the page, enter the path to the folder where the default persistent stores will store its data files. The directory structure of the path is as follows:
```
ORACLE_BASE/admin/domain_name/bi_cluster/tlogs
```
Click Save and Activate Changes.
Repeat these steps for the BI_SERVER2 server.

Note:
To enable migration of the Transaction Recovery Service, specify a location on a persistent storage solution that is available to other servers in the cluster. Both APPHOST1 and APPHOST2 must be able to access this directory. This directory must also exist before you restart the server.

15.2.3.15 Starting the System in APPHOST2

This section describes procedures for starting the system in APPHOST2.

15.2.3.15.1 Starting Node Manager on APPHOST2

15.2.3.15.2 Starting and Validating the BI_SERVER2 Managed Server

To start the BI_SERVER2 managed server and check that it is configured correctly:

Start the bi_server2 managed server using Oracle WebLogic Server Administration Console, as follows:
1. Expand the Environment node in the Domain Structure window.
2. Choose Servers.
3. Click the Control tab.
4. Select bi_server2 and then click Start.
Verify that the server status is reported as "Running" in the Administration Console. If the server is shown as "Starting" or "Resuming", wait for the server status to change to "Started". If another status is reported (such as "Admin" or "Failed"), check the server output log files for errors
When BI_SERVER2 is started, the following URLs become available:
- Access http://APPHOST2VHN1:9704/wsm-pm to verify the status of Web Services Manager. Click Validate Policy Manager.
  
  Note:
  The configuration is incorrect if no policies or assertion templates appear.
- Access http://APPHOST2VHN1:9704/xmlpserver to verify the status of the Oracle BI Publisher application.

15.2.3.16 Configuring Oracle HTTP Server for the BI_SERVERn Managed Servers

To enable Oracle HTTP Server to route to bi_cluster, which contains the BI_SERVERn managed servers, you must set the WebLogicCluster parameter to the list of nodes in the cluster:

On WEBHOST1 and WEBHOST2, add the following lines to the ORACLE_BASE/product/fmw/Oracle_WT1/instances/web1/config/OHS/ohs1/mod_wl_ohs.conf file:

# WSM-PM
<Location /wsm-pm>
   SetHandler weblogic-handler
   WebLogicCluster APPHOST1VHN1:9704, APPHOST2VHN1:9704
   WLProxySSL ON
   WLProxySSLPassThrough ON
</Location>

# BI Publisher
<Location /xmlpserver>
   SetHandler weblogic-handler
   WebLogicCluster APPHOST1VHN1:9704, APPHOST2VHN1:9704
   WLProxySSL ON
   WLProxySSLPassThrough ON
 </Location>

Perform the same steps for the Oracle HTTP Server on WEBHOST2.

Restart Oracle HTTP Server on WEBHOST1 and WEBHOST2:

WEBHOST1> ORACLE_BASE/product/fmw/Oracle_WT1/instances/web1/bin/
opmnctlrestartproc ias-component=ohs1

WEBHOST2> ORACLE_BASE/product/fmw/Oracle_WT1/instances/web1/bin/
opmnctlrestartproc ias-component=ohs1

15.2.3.17 Validating Access Through Oracle HTTP Server

Verify that the BI Servers status is reported as "Running" in the Administration Console. If the server is shown as "Starting" or "Resuming," wait for the server status to change to "Started". If another status is reported (such as "Admin" or "Failed"), check the server output log files for errors.

Verify that you can access these URLs:

http://WEBHOST1:7777/wsm-pm
http://WEBHOST2:7777/wsm-pm
http://WEBHOST1:7777/xmlpserver
http://WEBHOST2:7777/xmlpserver

Verify that you can access these URLs using your load balancing router address:

http://bi.mycompany.com:80/xmlpserver
http://bi.mycompany.com:80/wsm-pm

Follow these instructions to ensure that routing and failover from the HTTP Server to the bi_cluster is working correctly:

While BI_SERVER2 is running, stop BI_SERVER1 from Oracle WebLogic Server Administration Console.
Access the following URLs and verify the appropriate functionality:
- WEBHOST1:7777/wsm-pm
- WEBHOST1:7777/xmlpserver
Start BI_SERVER1 from Oracle WebLogic Server Administration Console.
Stop BI_SERVER2.
Access the URLs in Step 2 above again and verify the appropriate functionality.

15.2.3.18 Configuring Server Migration for the BI_SERVERn Servers

In this high availability topology, you must configure server migration for the bi_server1 and bi_server2 Managed Servers. To do this, follow the instructions in Section 15.1.12.21, "Configuring Server Migration for the BI_SERVERn Servers."

15.2.3.19 Scaling Out the Oracle BI Publisher Topology to a New Node (APPHOST3)

When you scale out the Oracle BI Publisher topology, you add a new managed server and set of system components to a new node in your topology (APPHOST3). This section assumes that you already have a high availability topology that includes at least two nodes, with a managed server and a full set of system components on each node.

Before performing the steps in this section, check that you meet these requirements:

There must be existing nodes running Oracle BI Publisher managed servers within the topology.
The new node (APPHOST3) can access the existing home directories for Oracle WebLogic Server and Oracle Business Intelligence.
When an ORACLE_HOME or WL_HOME is shared by multiple servers in different nodes, it is recommended that you keep the Oracle Inventory and Middleware home list in those nodes updated for consistency in the installations and application of patches. To update the oraInventory in a node and "attach" an installation in a shared storage to it, use ORACLE_HOME/oui/bin/attachHome.sh. To update the Middleware home list to add or remove a WL_HOME, edit the MW_HOME/.home file. See the steps below.
The new server can use a new individual domain directory or, if the other Managed Servers domain directories reside on shared storage, reuse the domain directories on those servers.

Perform these steps to scale out Oracle BI Publisher on APPHOST3:

On APPHOST3, mount the existing Middleware home, which should include the Oracle Business Intelligence installation and (optionally, if the domain directory for Managed Servers in other nodes resides on shared storage) the domain directory, and ensure that the new node has access to this directory, just like the rest of the nodes in the domain.
To attach ORACLE_HOME in shared storage to the local Oracle Inventory, execute the following command:
```
APPHOST3> cd ORACLE_COMMON_HOME/oui/bin/
APPHOST3> ./attachHome.sh -jreLoc ORACLE_BASE/product/fmw/jrockit_160_<version>
```
To update the Middleware home list, create (or edit, if another WebLogic installation exists in the node) the MW_HOME/.home file and add ORACLE_BASE/product/fmw to it.
Enable VIP3 in APPHOST3. See Section 15.2.3.3, "Enabling VIP1 in APPHOST1 and VIP2 in APPHOST2."
Run the Configuration Assistant from one of the shared Oracle homes, using the steps in Section 15.2.3.11, "Scaling Out the BI System on APPHOST2" as a guide.
Configure the bi_server3 Managed Server by setting the Listen Address and disabling host name verification, using the steps in Section 15.2.3.12, "Setting the Listen Address for the BI_SERVER2 Managed Server" and Section 15.2.3.13, "Disabling Host Name Verification for the BI_SERVER2 Managed Server" as a guide.
Configure JMS for Oracle BI Publisher, as described in Section 15.2.3.14.1, "Configuring JMS Persistence Store for BI Publisher."
Set the location of the default persistence store for bi_server 3, as described in Section 15.2.3.14.2, "Configuring a Default Persistence Store for Transaction Recovery."
Configure Oracle HTTP Server for APPHOST3VHN1, using the steps in Section 15.2.3.16, "Configuring Oracle HTTP Server for the BI_SERVERn Managed Servers" as a guide.
Start the bi_server3 Managed Server and the system components running on APPHOST3. See Section 15.2.3.9.2, "Starting and Validating the BI_SERVER1 Managed Server" for details.
Configure server migration, as described in Section 15.1.12.21.5, "Configuring Server Migration Targets" and Section 15.1.12.21.6, "Testing the Server Migration."
To validate the configuration, access the http://APPHOST3VHN1:9704/xmlpserver URL to verify the status of the Oracle BI Publisher application.
Oracle recommends using host name verification for the communication between Node Manager and the servers in the domain. This requires the use of certificates for the different addresses communicating with the Administration Server and other servers. See the chapter on setting up Node Manager in the Oracle Fusion Middleware Enterprise Deployment Guide for Oracle Business Intelligence for further details.

15.3 High Availability for Oracle Real-Time Decisions

Oracle Real-Time Decisions (Oracle RTD) is used to provide a ranked list of choices or offers for a request, given a sufficient context for making a decision on the best choices to select from. Oracle RTD always uses a front-end application that is responsible for defining process flow, capturing user interaction, and translating this interaction as input for Oracle RTD decision making. Therefore, Oracle RTD can be seen as more of a decision service rather than a traditional web application.

This section describes how to design and deploy a high availability environment for Oracle RTD.

This section includes the following topics:

Section 15.3.1, "Oracle RTD Component Architecture"
Section 15.3.2, "Oracle RTD High Availability Concepts"
Section 15.3.3, "Oracle RTD High Availability Configuration Steps"

15.3.1 Oracle RTD Component Architecture

Figure 15-13 shows the key components in a single instance Oracle RTD architecture:

Figure 15-13 Oracle RTD Single Instance Architecture

Description of "Figure 15-13 Oracle RTD Single Instance Architecture"

The components shown in Figure 15-13 include:

Decision Server: Provides run-time services to execute Oracle RTD applications called Inline Services.

For more information about Decision Server and Inline Services, see the "Decision Server" subsection.
Batch Services: Includes the Batch Manager and Batch Agent. Batch Services is responsible for satisfying requests to perform batch jobs.

For more information about Batch Services, see the "Oracle RTD Batch Framework" chapter in the Oracle Fusion Middleware Platform Developer's Guide for Oracle Real-Time Decisions.
Decision Center: Is the web-based UI for business users to view reports about the effectiveness of their analytical models and to tune their hosting Inline Services.

For more information about Decision Center, see the "Decision Center" subsection.
Learning Services: Read learning records from the Oracle RTD database and periodically generate new predictive models.

For more information about Learning Services, see the "Learning Services" subsection.

Decision Server

Decision Server provides the necessary run-time services to execute Oracle RTD applications called Inline Services. Inline Services are developed using the Decision Studio development environment, and are deployed to and run in Oracle RTD Decision Server. For more information about Decision Studio, see the "Decision Studio, RTD Clients and Tools" subsection.

An Inline Service can gather data and analyze characteristics of enterprise business processes on a real-time and continuous basis. It also leverages that data and analysis to provide decision-making capability and feedback to key business processes.

Decision Server stores all its metadata in the Oracle RTD database.

The following elements of an Inline Service play a role in or are affected by a high availability topology (mostly by accessing resources outside of Oracle RTD):

Choices: Choices represent the offers that will be presented through the Inline Service or the targets of study to be tracked by the self-learning models of Oracle RTD. There are two forms of choices: static and dynamic. Static choices are hard coded using Decision Studio. Dynamic choices are defined in an external data source and loaded during the execution of an Inline Service.
Rules: Rules are used to target segments of population, decide whether a choice is eligible, or score a particular choice. Rules are constructed through a graphical rules editor. Rules are loaded by Decision Server during the execution of an Inline Service. Oracle RTD has a type of rules called external rules. These rules are stored in an data source external to Oracle RTD.
Entities: Entities are a logical representation of data used for Oracle RTD modeling and decisioning. The attributes of an entity can be populated via data sources, as incoming parameters from integration points, or derived in real time through custom logic.
Data Sources: Data sources retrieve data from tables or stored procedures.
Integration Points: Integration points serve as the touchpoints with outside systems interacting with Oracle RTD. There are two classes of integration points: informants and advisors. Informants receive data from outside systems, whereas advisors receive data and also send recommendations back to outside systems.
Models: Serve two primary purposes: prediction and reporting. Models are defined to:
- Predict the likelihood that certain events associated with Choices will occur.
- Analyze data correlated with those events.
Statistics Collectors are special models that track statistics about entities.

Models are associated at design time with a Choice Group. This defines the list of Choices to which prediction and reports apply.

Decision Center

Workbench Services, which supports the deployment of Inline Services by Decision Server, also provides the Decision Center web interface. Decision Center displays the structure and decisioning history of Inline Services. Business users use Decision Center to view reports about the effectiveness of their analytical models and to tune their hosting Inline Services.

Decision Center interacts with the Learning Server to query the contents of the Learning Models.

Learning Services

Learning records are created when an Inline Service session closes. Learning records are batched in memory (configurable) and queued to be stored in the Oracle RTD database. This is done for performance reasons - to minimize the number of database transactions required to store learning records in the Oracle RTD database. By default, Oracle RTD buffers 100 records, with a queue for 50 buffers. A worker thread is responsible for writing learning records to the Oracle RTD database.

Learning Services awakens periodically and:

Reads learning records from the database
Generates new predictive models

Each predictive model is associated with a specific Inline Service. Therefore, an Inline Service is only affected when it has a new predictive model. All Inline Services are isolated from updates to another Inline Service's models.

Predictive models are propagated to the Decision Server. Each Decision Server frequently polls the Oracle RTD database for new predictive models. When a new predictive model is found, it is loaded into memory.

Decision Studio, RTD Clients and Tools

Decision Studio is an Eclipse based development environment for developing Oracle RTD Inline Services.

Decision Studio is also used to deploy and download an Inline Service from an Oracle RTD Server through the Oracle RTD Workbench Services web service.

Oracle RTD provides a number of client components that make it easier to integrate with Oracle RTD Decision Server. For example, Oracle RTD provides a Java client that provides a wrapper for Oracle RTD web service calls, caches default result sets on the client side, and provides default responses when the Oracle RTD server is not responding.

For more information on Oracle RTD client tools, refer to the Oracle Fusion Middleware Platform Developer's Guide for Oracle Real-Time Decisions.

Administration of Oracle RTD

Oracle Enterprise Manager Fusion Middleware Control is used to configure Oracle RTD single instance and cluster-wide attributes.

15.3.1.1 Oracle RTD Component Characteristics

This section describes the Oracle RTD component characteristics.

The Oracle RTD Server and its components are Java or web based components. They run either within the Java or web container. Communication between Decision Studio and Oracle RTD clients with the Oracle RTD Server is through a number of web services.

Oracle RTD manages session information locally and does not rely on a web server for session management. This is because Oracle RTD requires long running sessions to complete a business process vs the typical session associated with a web application. A single Decision Server session might receive requests from several HTTP sessions from different client servers. An Oracle RTD session can be fast, or it can last several hours, days or weeks.

If a server fails, the request will be directed to another server and a new session will be created. For the most part, session information is read from an external data source or calculated. These values will be reread or recalculated on a new session. Oracle RTD uses session information to calculate likelihood and not for storing state of a business transaction (this is delegated to a transactional/operational system). Therefore, the loss of session information does not adversely impact a business process.

15.3.1.1.1 Component Lifecycle

Oracle RTD is managed through Oracle Enterprise Manager Fusion Middleware Control. The Fusion Middleware Control is used to start, stop, undeploy, deploy, and monitor Oracle RTD services.

15.3.1.1.2 Process Flow

The process flow for Oracle RTD is:

A call is made by an external application to an Oracle RTD integration point.
The request is sent to the Oracle RTD's Decision Service web service, which is authenticated by Oracle Web Services Manager before the Decision Service serves the request.
The request is then forwarded to the targeted Inline Service and the target informant or advisor within the Inline Service.
Informant processing includes executing rules, executing functions, accessing entities, and creating learning records.
Advisor processing includes executing decisions, executing rules, executing functions for eligibility (filtering), accessing entities, and returning a list of eligible choices.

15.3.1.1.3 External Dependencies

Configuration information for Oracle RTD is self-contained and stored in its own database schema. However, an Inline Service can load its entities or external rules from external data sources.

15.3.1.1.4 Configuration Artifacts

Configuration information is stored in the Oracle RTD database, and it is updated using the Fusion Middleware Control.

Data source configuration information is set using the Oracle WebLogic Server Administration Console.

15.3.1.1.5 Deployment Artifacts

Oracle RTD Inline Services are created in Decision Studio. Developers use the Decision Studio deployment facility to deploy an Inline Service. The Inline Service is packaged by Oracle RTD Studio and uploaded to an instance of Decision Server. The Decision Server stores all uploaded Inline Services to the Oracle RTD operational tables.

15.3.1.1.6 Log File Locations

You can view Oracle RTD log files using Oracle Enterprise Manager Fusion Middleware Control. To view the log files from the Oracle RTD home page, right-click the deployed Oracle RTD application in the navigator pane, and select Logs > View Log Files. This displays the Log Messages screen, on which you can view the log files. For more information on viewing Oracle RTD log files, see Oracle Fusion Middleware Administrator's Guide for Oracle Real-Time Decisions.

15.3.2 Oracle RTD High Availability Concepts

This section provides conceptual information about using Oracle RTD in a high availability deployment.

15.3.2.1 Oracle RTD High Availability Architecture

Figure 15-14 shows an Oracle RTD high availability active-active architecture.

Figure 15-14 Oracle RTD High Availability Architecture

Description of "Figure 15-14 Oracle RTD High Availability Architecture"

In Figure 15-14, incoming requests are received by the hardware load balancer, which routes them to WEBHOST1 or WEBHOST2 in the web tier. These hosts have Oracle HTTP Server installed.

Oracle WebLogic Server is installed on APPHOST1 and APPHOST2 in the application tier. The Administration Server can be made active on APPHOST2 if APPHOST1 becomes unavailable, as described in Chapter 3, "High Availability for WebLogic Server." Oracle RTD is deployed on the BI_SERVER1 and BI_SERVER2 managed servers on these hosts. These managed servers are configured in an Oracle WebLogic cluster that allows them to work in an active-active manner.

In the data tier, an Oracle RAC database is used for the Oracle RTD repository, which stores learning models, learning records, prediction models, and Inline Services metadata, and is also recommended for the enterprise database.

Note:

A cluster of Oracle RTD instances front-ended directly by a load balancer (instead of a web tier) is also supported. In this type of deployment, the load balancer has to be configured to ensure sticky session routing using the HTTP headers. See your load balancer documentation for information on configuring it to ensure sticky routing using the HTTP header.

Clients accessing the Oracle RTD cluster in this type of deployment must meet the requirements specified in the "About the Java Smart Client" section of Oracle Fusion Middleware Platform Developer's Guide for Oracle Real-Time Decisions. For an example of setting up the client, see the "Using the Java Smart Client" chapter of Oracle Fusion Middleware Platform Developer's Guide for Oracle Real-Time Decisions.

Oracle RTD Cluster Considerations

In a clustered installation, instances of RTD components must communicate with other RTD components that can be located in the same host or a remote host. When the components are not in the same host they use an internal Remote Procedure Call (RPC) mechanism to communicate between cluster hosts and convey the response.

In a cluster, Decision Center is typically deployed in the same Oracle RTD instances as Learning Services, because Decision Center needs to communicate with Learning Services. Decision Center is not a singleton, however, so any instances not co-located with the active Learning Services use RPC to communicate with the active Learning Services.

In a cluster, Decision Center is typically deployed in a different Oracle RTD instance than Decision Services, which minimizes the performance and memory impact of Decision Center on Decision Services.

In a cluster, an Inline Service is deployed by Decision Studio to any cluster member, using the same internal WorkBench web service used in a non-clustered installation. The instance to which Decision Studio is connected will load the Inline Service into memory and will save the Inline Service in the database. Other cluster members will notice the new Inline Service in the database, and will load the Inline Service into their own memory.

For performance reasons it is best to deploy Oracle RTD in a cluster with HTTP session affinity enabled. This is because having the context of the Oracle RTD Session is necessary in order to create accurate learning records and making predictions. There is dynamic state in a session that can contribute to learning (for example, the sequence of web pages accessed in this Decision Server session), and that does not come from the database. While this state contributes to learning, it is only in an aggregated manner; there is no personal state, or any state important enough to mirror across servers, even if the state was Serializable. Losing a few sessions because of a server failure will not noticeably impact the integrity of Oracle RTD learning models, which are based on aggregated information.

Each instance of Decision Server in a cluster polls the Oracle RTD operational tables for new or updated Inline Services. If a new or newer version of an Inline Service is found, it is loaded into memory by every member of a cluster.

Oracle RTD uses hardware or software load balancers.

You can inject a Session Key into a web service request. The Session Key is user defined and passed in as a parameter to the Oracle RTD Java client (a wrapper to the Oracle RTD web service). The load balancer must be configured to have session affinity enabled and to retrieve the Session Key from the HTTP header.

Intra-cluster member communication between Oracle RTD instances is performed through its internal intra-cluster RPC technology. The JMS publish/subscribe model is used with a single topic "RTDTopic" created on Oracle RTD deployment (defined in Oracle RTD's Weblogic template). Each Oracle RTD instance subscribes to this single Topic and reads messages that apply to it (through filtering).

An Oracle RTD server may receive a request for which it does not have the request's Session state. In this case, the receiving Decision Server performs a lookup and finds the Decision Server to which this request should be directed. The request will then be forwarded to the correct Decision Server. The forwarding Decision Server will wait on the request to be completed by the receiving Decision Server.

The forwarded request is sent via RPC. Each Oracle RTD server pulls all messages that apply to it from the Oracle RTD JMS Topic.

After the receiving Decision Server completes the request, the call is unwound and the originator of the request forwarding gets the response from the receiving Decision Server. The response is then sent back to the caller.

Singleton Services

In Figure 15-14, the Oracle RTD Learning Service and Batch Manager are singletons. The Learning Service is responsible for building analytical models from data records written by one or more of the Oracle RTD Decision Service instances. An analytical model provides the likelihood of a specific outcome given a set of input values. For example, an analytical model can determine how likely a customer is to purchase a specific product given a prior history of products purchased. Learning models are built in memory; if the active Learning Service fails while building a model, a new Learning Service is activated and it will build the model from scratch with no loss of data. Batch Manager is responsible for starting and managing batch jobs on behalf of the batch administration client. It communicates with Batch Agent instances on other Oracle RTD instances to distribute the work across the cluster. Both Learning Service and Batch Manager are considered Active-Spare singletons.

Cluster Coordinator

Oracle RTD has its own cluster coordinator, which performs these tasks:

It assures that precisely one singleton is active of each type, Learning Service singleton and Batch Manager singleton. Only the cluster coordinator starts or stops a cluster singleton
The cluster coordinator cleans up resources left open by a member that leaves the cluster (this cleanup logic is the same as the node would normally perform for itself when it shuts down in a controlled manner). The coordinator does this cleanup in case the leaving node died unexpectedly before it had a chance to close its own resources. e.g. All Decision Center sessions hosted by a cluster member will be closed by the coordinator when that cluster member leaves the cluster

On startup, each Oracle RTD cluster member vies to become the cluster coordinator by transactionally testing the database to see if another instance is already the coordinator, and inserts itself into the database as the coordinator if no other coordinator exists. A coordinator's right to be the coordinator expires unless periodically renewed by itself, so if a coordinator dies some other cluster member will successfully become coordinator.

15.3.2.1.1 Starting and Stopping the Cluster

You can use the Oracle WebLogic Server Administration Console to start and stop single instances in an Oracle RTD cluster.

15.3.2.1.2 Cluster-Wide Configuration Changes

Configuration information for Oracle RTD is self-contained and stored in its own database schema. It can be updated using Oracle Enterprise Manager Fusion Middleware Control.

When you change the configuration of one instance in an Oracle RTD cluster, the other instances pick up the configuration changes after you click the Apply button in Oracle Enterprise Manager Fusion Middleware Control.

15.3.2.2 Protection from Failures and Expected Behaviors

The Oracle RTD topology management layer, running in each cluster member, will detect cluster members that stop updating their heartbeat records in the database. It does not check for failures of individual services within a managed server. So the failure scenarios described in this section are for managed server failures, not individual service failures.

15.3.2.2.1 Decision Server Failure

If a Decision Server fails:

The Oracle RTD sessions associated with the Decision Server are lost, along with their stateful information.
The load balancer will direct requests originally destined to the failed server to another server.
The server receiving these requests will create a new Oracle RTD session, hydrate session level entities from the appropriate data sources, and satisfy the request.

Learning records are written to the database frequently. They are used for statistical purposes. When a Decision Server fails:

All non-persisted learning records are lost.
Oracle RTD does not store any transactional data, such as a specific customer's information or account information, and so on. Therefore, when a large number of learning records have already been learned from and the prediction models have converged, the loss of some data is not material, and it will not significantly affect likelihood calculations and, therefore, the offers returned by an Oracle RTD Informant.

15.3.2.2.2 Cluster Coordinator Failure

If the failed server is the cluster coordinator:

It would stop updating the timestamp in the Oracle RTD database.
Other servers polling the database table would realize that the timestamp has become stale and that there may be a problem with the cluster coordinator.
All active Oracle RTD instances vie to become the new cluster coordinator.

15.3.2.2.3 Learning Service Failure

Learning models are built in memory.

If the active Learning Service fails while building a model, a new Learning Service will be activated, and it will build the model from scratch with no loss of data.

If the node with the active Learning Service fails, the cluster coordinator will activate the Learning Service on one of the remaining cluster nodes (to which a Learning Service has been deployed and enabled). The cluster coordinator does this by sending a command to the Oracle RTD instance via an intra-cluster RPC.

15.3.2.2.4 Decision Center Failure

If a Decision Center fails, a user loses any work in progress that was not saved, for example, rule updates or changes to performance goals that were not saved.

Since multiple Decision Centers run in a cluster, the user will be directed to an active Decision Center.

15.3.2.2.5 Batch Manager Failure

If the node with the active Batch Manager fails, the cluster coordinator will activate a Batch Manager on one of the other remaining nodes (to which a Batch Manager has been deployed and enabled).

If the cluster's Batch Manager singleton fails, the cluster coordinator will notice the death and start another Batch Manager in a different host. All Batch Agents will be notified of the presence of the new Batch Manager, and the Batch Agents will then register themselves with the new Batch Manager.

If the node running a batch job fails:

Only the batch jobs on the failed server will stop processing.
Any batch jobs that were running on the failed node will enter an Interrupted state, and can be manually resumed by issuing a Resume command to the Batch Manager using the Batch Console or other Batch Admin Client.
When an interrupted job is resumed, it will continue from the point where it last synchronized its state with the Batch Manager. When the Batch Manager is asked to resume a job, the job will resume on any available Batch Agent, selected by the Batch Manager.

15.3.3 Oracle RTD High Availability Configuration Steps

This section describes how to set up a two node highly available configuration for Oracle Real-Time Decisions. The architecture targeted for the configuration steps is shown in Figure 15-14.

Note:

Oracle strongly recommends reading the release notes for any additional installation and deployment considerations prior to starting the setup process.

15.3.3.1 Prerequisite Steps Before Setting up an Oracle RTD High Availability Configuration

This section includes the prerequisites for setting up the Oracle RTD high availability configuration.

15.3.3.1.1 Database Prerequisites

Oracle RTD supports the following database versions:

Oracle Database 10g (10.2.0.4 or later for non-XE database)
Oracle Database 11g (11.1.0.7 or later for non-XE database)

To determine the database version, execute this query:

SQL>select version from sys.product_component_version where product like 'Oracle%';

15.3.3.1.2 Installing and Configuring the Database Repository

This section describes how to install and configure the database repository.

Oracle Clusterware

For 10g Release 2 (10.2), see Oracle Database Oracle Clusterware and Oracle Real Application Clusters Installation Guide.
For 11g Release 1 (11.1) and later, see Oracle Clusterware Installation Guide.

Automatic Storage Management

For 10g Release 2 (10.2), see Oracle Database Oracle Clusterware and Oracle Real Application Clusters Installation Guide.
For 11g Release 1 (11.1) and later, see Oracle Real Application Clusters Installation Guide.

When you run the installer, select the Configure Automatic Storage Management option in the Select Configuration page to create a separate Automatic Storage Management home.

Oracle Real Application Clusters

For 10g Release 2 (10.2), see Oracle Database Oracle Clusterware and Oracle Real Application Clusters Installation Guide.
For 11g Release 1 (11.1) and later, see Oracle Real Application Clusters Installation Guide.

Use the latest version of RCU to install the 11g (11.1.1.) Oracle Fusion Middleware Repository into an Oracle RAC database.

See Oracle Fusion Middleware Repository Creation Utility User's Guide for more information about obtaining and running the latest version of RCU.

15.3.3.1.3 Using RCU to Load the Business Intelligence Schemas into the Database

Install the 11g (11.1.1) Oracle Fusion Middleware Metadata Store and Oracle BI schemas into an Oracle RAC database before you install Oracle RTD. Follow these steps:

Insert the Repository Creation Utility (RCU) DVD, and then start RCU from the bin directory in the RCU home directory.
```
prompt> cd RCU_HOME/bin
prompt> ./rcu
```
In the Welcome screen, click Next.
In the Create Repository screen, select Create to load component schemas into a database. Click Next.
In the Database Connection Details screen, enter connect information for your database:
- Database Type: Select Oracle Database.
- Host Name: Specify the name of the node on which the database resides. For the Oracle RAC database, specify the VIP name or one of the node names as the host name, for example:
  
  BIDBHOST1-VIP
- Port: Specify the listen port number for the database: 1521
- Service Name: Specify the service name of the database:
  
  biha.mycompany.com
- Username: Specify the name of the user with DBA or SYSDBA privilege: SYS
- Password: Enter the password for the SYS user.
- Role: Select the database user's role from the list: SYSDBA (required by the SYS user).
Click Next.
In the Select Components screen:
- Select Create a new Prefix, and enter a prefix to use for the database schemas, for example, BIHA. You can specify up to six characters as a prefix. Prefixes are used to create logical groupings of multiple repositories in a database. For more information, see Oracle Fusion Middleware Repository Creation Utility User's Guide.
  
  Tip:
  Note the name of this schema because the upcoming steps require this information.
- Select the following components:
```
o  AS Common Schemas: Metadata Services (automatically selected)
o  Oracle Business Intelligence: Business Intelligence Platform
```
Click Next.
In the Schema Passwords screen, enter passwords for the main schema users and click Next.

You can choose either Use same passwords for all schemas or Specify different passwords for all schemas, depending on your requirements.

Do not select Use main schema passwords for auxiliary schemas. The auxiliary passwords are derived from the passwords of the main schema users.

Tip:
Note the names of the schema passwords because the upcoming steps require this information.
In the Map Tablespaces screen, choose the tablespaces for the selected components, and click Next.
In the Summary screen, click Create.
In the Completion Summary screen, click Close.

15.3.3.1.4 Configuring Virtual Server Names and Ports for the Load Balancer

This section describes the load balancer prerequisites for deploying an Oracle RTD high availability environment.

Load Balancers

Oracle RTD uses a hardware load balancer when deployed in a high availability configuration with two Oracle HTTP Servers as web tier components.

Virtual Server Names

bi.mycompany.com is a virtual server name that acts as the access point for all HTTP traffic to the runtime BI components, such as Oracle RTD. Traffic to both SSL and non-SSL ports is configured, and typically non-SSL is redirected to SSL. Clients access this service using the address bi.mycompany.com:443. This virtual server is defined on the load balancer.

15.3.3.1.5 Installing Oracle HTTP Server on WEBHOST1 and WEBHOST2

This section describes how to install Oracle HTTP Server on WEBHOST1.

Verify that the servers meet the following requirements:
- Ensure that the system, patch, kernel and other requirements are met. These are listed in the Oracle Fusion Middleware Installation Guide for Oracle Web Tier in the Oracle Fusion Middleware documentation library for the platform and version you are using.
- Ensure that port 7777 is not in use by any service on WEBHOST1 by issuing these commands for the operating system you are using. If a port is not in use, no output is returned from the command.
  
  On UNIX:
```
netstat -an | grep "7777"
```
  On Windows:
```
netstat -an | findstr :7777
```
  If the port is in use (if the command returns output identifying the port), you must free the port.
  
  On UNIX:
  
  Remove the entries for port 7777 in the /etc/services file and restart the services, or restart the computer.
  
  On Windows:
  
  Stop the component that is using the port.
- Copy the staticports.ini file from the Disk1/stage/Response directory to a temporary directory.
- Edit the staticports.ini file that you copied to the temporary directory to assign the following custom ports (uncomment the line where you specify the port number for Oracle HTTP Server):
```
# The port for Oracle HTTP server
Oracle HTTP Server port = 7777
```
Start the Oracle Universal Installer for Oracle Fusion Middleware 11g Web Tier Utilities CD installation as follows:

On UNIX:

Issue the command: ./runinstaller

On Windows:

Double-click setup.exe.

This displays the Specify Inventory Directory screen.
On the Specify Inventory Directory screen, enter values for the Oracle Inventory Directory and the Operating System Group Name. For example:

Specify the Inventory Directory: /u01/app/oraInventory

Operating System Group Name: oinstall

A dialog box appears with the following message:

"Certain actions need to be performed with root privileges before the install can continue. Please execute the script /u01/app/oraInventory/createCentralInventory.sh now from another window and then press "Ok" to continue the install. If you do not have the root privileges and wish to continue the install select the "Continue installation with local inventory" option"

Log in as root and run the "/u01/app/oraInventory/createCentralInventory.sh"

This sets the required permissions for the Oracle Inventory Directory and then brings up the Welcome screen.
Note:
The Oracle Inventory screen is not shown if an Oracle product was previously installed on the host. If the Oracle Inventory screen is not displayed for this installation, make sure to check and see:
- If the /etc/oraInst.loc file exists.
- If the file exists, the Inventory directory listed is valid.
- The user performing the installation has write permissions for the Inventory directory.
On the Welcome screen, click Next.
On the Select Installation Type screen, select Install and Configure, and click Next.
On the Prerequisite Checks screen, the installer completes the prerequisite check. If any fail, fix them and restart your installation.

Click Next.
On the Specify Installation Location screen, specify:
- Oracle Middleware Home: ORACLE_BASE/product/fmw (grayed out)
- Oracle Home Directory: Oracle_WT1
Click Next.
On the Configure Components screen:
- Select Oracle HTTP Server.
- Do not select Associate Selected Components with Weblogic Domain.
Click Next.
On the Specify Component Details screen, enter the following values for WEBHOST1:
- Instance Home Location: ORACLE_BASE/product/fmw/Oracle_WT1/instances/web1
- Instance Name: web1
- OHS Component Name: ohs1
Click Next.
On the Configure Ports screen:
- If you specify a custom port, select Specify Ports using Configuration File and then use the Browse function to select the file.
- Enter the Oracle HTTP Server port, for example: 7777
Click Next.
In the Specify Security Updates screen, choose whether you want to receive security updates from Oracle Support and if you do, enter your email address and click Next.
On the Installation Summary screen, ensure that the selections are correct. If they are not, click Back and make the necessary fixes. After ensuring that the selections are correct, click Install.
On the Installation Progress screen on UNIX systems, a dialog appears that prompts you to run the oracleRoot.sh script. Open a window and run the script, following the prompts in the window.

Click Next.
On the Configuration Progress screen, multiple configuration assistants are launched in succession; this process can be lengthy. Click Next.
On the Installation Complete screen, click Finish to exit.

Repeat the steps for WEBHOST2 and configure your load balancer with a pool containing both the WEBHOST1 and WEBHOST2 addresses.

15.3.3.1.6 Validating Oracle HTTP Server

To verify that Oracle HTTP Server is set up correctly, access the root URL context of the server by using the following URLs in the browser:

http://WEBHOST1:7777/
http://WEBHOST2:7777/

If Oracle HTTP Server is set up correctly, the Oracle FMW Welcome screen appears in the browser.

15.3.3.2 Installing Oracle Fusion Middleware Home

This section describes how to install Oracle Fusion Middleware on all nodes in the application tier that run Oracle WebLogic Server and Oracle Fusion Middleware BI EE. Repeat the procedure (described below for APPHOST1) for installing WebLogic Server and Oracle RTD in APPHOST2. The directory paths for binary files and domains used when installing new nodes must be exactly the same as those used for first node.

Install the following Oracle Fusion Middleware components:

Oracle WebLogic Server
Oracle Fusion Middleware BI EE

15.3.3.2.1 Installing Oracle WebLogic Server

Follow these steps to install Oracle WebLogic Server:

Start the installer for Oracle WebLogic Server from the installation media.
In the Welcome screen, click Next.
In the Choose Middleware Home Directory screen:
- Select Create a new Middleware Home.
- For the Middleware Home Directory, enter ORACLE_BASE/product/fmw
  
  Note:
  ORACLE_BASE is the base directory under which Oracle products are installed. The recommended value is /u01/app/oracle.
Click Next.
In the Register for Security Updates screen, choose whether you want to receive security updates from Oracle Support and if you do, enter your email address. Click Next.
In the Choose Install Type screen, select Typical and click Next.
In the Choose Product Installation Directories screen, accept the directory ORACLE_BASE/product/fmw/wlserver_10.3 for WebLogic Server and ORACLE_BASE/product/fmw/coherence_3.6 for Oracle Coherence and click Next.
In the Installation Summary screen, click Next.

The Oracle WebLogic Server software is installed.
In the Installation Complete screen, clear the Run Quickstart check box and click Done.

15.3.3.2.2 Installing Oracle RTD

Start the installer for Oracle Fusion Middleware Business Intelligence 11g from the installation media:

On UNIX:
```
APPHOST1>./runInstaller
```
On Windows:
```
APPHOST1> setup.exe
```
In the Specify Inventory Directory screen:
- Enter HOME/oraInventory, where HOME is the home directory of the user performing the installation (this is the recommended location).
- Enter the OS group for the user performing the installation.
  
  Click Next.
- Follow the instructions on screen to execute /createCentralnventory.sh as root.
  
  Click OK.
In the Welcome screen, click Next.
In the Select Installation Type screen, select Software Only Install and click Next.
In the Prerequisite Checks screen, verify that all checks complete successfully, and click Next.
In the Specify Installation Location screen, select the previously installed Middleware Home from the drop-down list. For the Oracle Home directory, enter the directory name (Oracle_BI1).

Click Next.
In the Specify Security Updates screen, choose whether you want to receive security updates from Oracle Support and if you do, enter your email address and click Next.
In the Summary screen, click Install.

The Oracle Fusion Middleware Business Intelligence 11g software is installed.
In the Installation Progress screen, click Next.
In the Complete screen, click Finish.

15.3.3.3 Enabling VIP1 in APPHOST1 and VIP2 in APPHOST2

15.3.3.4 Creating a Domain with the Administration Server and the First BI_SERVER1 Managed Server

Note:

Oracle strongly recommends that you read the release notes for any additional installation and deployment considerations prior to starting the setup process.

Run the Configuration Assistant from the Oracle home directory to create a domain containing the Administration Server and the managed server with Oracle RTD:

Change the directory to the location of the Configuration Assistant:
```
APPHOST1> cd ORACLE_HOME/bin
```
Start the Configuration Assistant:

On UNIX:
```
APPHOST1> ./config.sh
```
On Windows:
```
APPHOST1> config.bat
```
In the Welcome screen, click Next.
In the Prerequisite Checks screen, verify that all checks complete successfully, and click Next.
The Create or Scale Out BI System screen opens. Select Create New BI System and specify the following:
- User Name: weblogic
- User Password: Enter the weblogic user password.
- Domain Name: bifoundation_domain
Click Next.
In the Specify Installation Location screen, enter:
- Middleware Home: ORACLE_BASE/product/fmw (grayed out)
- Oracle Home: ORACLE_BASE/product/fmw/Oracle_BI1 (grayed out)
- WebLogic Server Home: ORACLE_BASE/product/fmw/wlserver_10.3 (grayed out)
- Domain Home: ORACLE_BASE/product/fmw/user_projects/domain/bifoundation_domain
  
  Note:
  The Domain Home must end with the domain name.
- Instance Home: ORACLE_BASE/product/fmw/instance1
- Instance Name: instance1
Click Next.
In the Configure Components screen, select Oracle Real-Time Decisions.

Click Next.
In the BIPLATFORM Schema screen, enter:
- Database Type: Oracle Database
- Connect String: BIDBHOST1:1521:BIDB1^BIDBHOST2:1521:BIDB2@BIHA.MYCOMPANY.COM
- BIPLATFORM Schema Username: BIHA_BIPLATFORM
- BIPLATFORM Schema Password: Enter the password for the BIPLATFORM schema user.
Click Next.
In the Configure Ports screen, select one of the following:
- Auto Port Configuration
- Specify Ports using Configuration File
Click Next.
In the Specify Security Updates screen, choose whether you want to receive security updates from Oracle Support and if you do, enter your email address. Click Next.
In the Summary screen, click Configure.
In the Configuration Progress screen, verify that all the Configuration Tools have completed successfully and click Next.
In the Complete screen, click Finish.

15.3.3.5 Creating boot.properties for the Administration Server on APPHOST1

Go to the following directory:

ORACLE_BASE/product/fmw/user_projects/domains/bifoundation_domain/servers/
AdminServer/security

Enter the following lines in the file, save the file, and close the editor:
```
username=Admin_username
password=Admin_password
```
Note:
When you start the Administration Server, the username and password entries in the file are encrypted.
For security reasons, minimize the time the entries in the file are left unencrypted. After you edit the file, start the server as soon as possible for the entries to be encrypted.

15.3.3.6 Starting and Validating the Administration Server on APPHOST1

This section describes procedures for starting and validating the Administration Server on APPHOST1.

15.3.3.6.1 Starting the Administration Server on APPHOST1

To start the Administration Server on APPHOST1, run the following commands:

APPHOST1> cd MW_HOME/user_projects/domains/bifoundation_domain/bin
APPHOST1> ./startWebLogic.sh

15.3.3.6.2 Validating the Administration Server

verify that the Administration Server is properly configured:

In a browser, go to http://APPHOST1:7001/console.
Log in as the administrator.
Verify that the BI_SERVER1 managed server is listed.
Verify that the bi_cluster cluster is listed.
Verify that you can access Enterprise Manager at http://APPHOST1:7001/em.

15.3.3.7 Setting the Listen Address for BI_SERVER1 Managed Server

Perform these steps to set the managed server listen address:

Log into the Oracle WebLogic Server Administration Console.
In the Change Center, click Lock & Edit.
Expand the Environment node in the Domain Structure window.
Click Servers.
Select bi_server1 in the Names column of the table.
Set the Listen Address to APPHOST1VHN1.
Click Save.
Save and activate the changes.

The changes will not take effect until the BI_SERVER1 managed server is restarted.

15.3.3.8 Disabling Host Name Verification for the BI_SERVER1 Managed Server

This step is required if you have not set up the appropriate certificates to authenticate the different nodes with the Administration Server. If you have not configured the server certificates, you will receive errors when managing the different WebLogic Servers. To avoid these errors, disable host name verification while setting up and validating the topology, and enable it again once the high availability topology configuration is complete.

To disable host name verification:

Log into Oracle WebLogic Server Administration Console.
In the Change Center, click Lock & Edit.
Expand the Environment node in the Domain Structure window.
Click Servers.
Select bi_server1 in the Names column of the table. The settings page for the server is displayed.
Open the SSL tab.
Expand the Advanced section of the page.
Set Hostname Verification to None.
Click Save.
Save and activate the changes.
The change will not take effect until the BI_SERVER1 managed server is restarted.

15.3.3.9 Starting the System in APPHOST1

This section describes how to start Node Manager on APPHOST1 and how to start and validate the BI_SERVER1 managed server on APPHOST1.

15.3.3.9.1 Starting Node Manager on APPHOST1

Usually, Node Manager is started automatically when config.sh completes. If Node Manager is not running for some reason, start it on APPHOST1 using these commands:

APPHOST1> cd WL_HOME/server/bin
APPHOST1> ./startNodeManager.sh

15.3.3.9.2 Starting and Validating the BI_SERVER1 Managed Server

To start the BI_SERVER1 managed server and check that it is configured correctly:

Start the bi_server1 managed server using Oracle WebLogic Server Administration Console, as follows:
1. Expand the Environment node in the Domain Structure window.
2. Choose Servers.
3. Click the Control tab.
4. Select bi_server1 and then click Start.
Verify that the server status is reported as "Running" in the Administration Console. If the server is shown as "Starting" or "Resuming", wait for the server status to change to "Started". If another status is reported (such as "Admin" or "Failed"), check the server output log files for errors
When BI_SERVER1 is started, the following URLs become available:
- Access http://APPHOST1:9704/wsm-pm to verify the status of Web Services Manager. Click Validate Policy Manager. A list of policies and assertion templates available in the data is displayed.
  
  Note:
  The configuration is incorrect if no policies or assertion templates appear.
- Access http://APPHOST1:9704/ui to verify the status of the Oracle RTD Decision Center application.

15.3.3.10 Scaling Out the BI System on APPHOST2

Run the Configuration Assistant from the ORACLE_HOME directory to scale out the BI System.

Change the directory to the location of the Configuration Assistant:
```
APPHOST2> cd ORACLE_HOME/bin
```
Start the Configuration Assistant:
```
APPHOST2> ./config.sh
```
In the Welcome screen, click Next.
On the Prerequisite Checks screen, the installer completes the prerequisite check. If any fail, fix them and restart your installation.

Click Next.
The Create or Scale out BI System screen opens. Select Scale Out BI System and then enter the following values:
- Host Name: ADMINHOST
- Port: 7001
- User name: weblogic
- User Password: Enter the password for the weblogic user.
Click Next.
In the Scale Out BI System Details screen, enter:
- Middleware Home: ORACLE_BASE/product/fmw (grayed out)
- Oracle Home: Oracle_BI1 (grayed out)
- WebLogic Server Home: ORACLE_BASE/product/fmw/wlserver_10.3 (grayed out)
- Domain Home: ORACLE_BASE/product/fmw/user_projects/domain/bifoundation_domain
  
  Note:
  The Domain Home must end with the domain name.
- Instance Home: ORACLE_BASE/product/fmw/instance2
- Instance Name: instance2 (grayed out)
Click Next.
In the Configure Ports screen, select one of the following:
- Auto Port Configuration
- Specify Ports using Configuration File
Click Next.
In the Specify Security Updates screen, choose whether you want to receive security updates from Oracle Support and if you do, enter your email address. Click Next.
In the Summary screen, click Configure.
In the Configuration Progress screen, verify that all the Configuration Tools have completed successfully and click Next.
In the Complete screen, click Finish.

15.3.3.11 Setting the Listen Address for the BI_SERVER2 Managed Server

Perform these steps to set the BI_SERVER2 managed server listen address:

Log into the Oracle WebLogic Server Administration Console.
In the Change Center, click Lock & Edit.
Expand the Environment node in the Domain Structure window.
Click Servers.
Select bi_server2 in the Names column of the table.

The Setting page for bi_server2 is displayed.
Set the Listen Address to APPHOST2VHN1.
Click Save.
Save and activate the changes.

The changes do not take effect until the BI_SERVER2 managed server restarts.

15.3.3.12 Disabling Host Name Verification for the BI_SERVER2 Managed Server

This step is required if you have not set up the appropriate certificates to authenticate the different nodes with the Administration Server. If you have not configured the server certificates, you will receive errors when managing the different WebLogic Servers. To avoid these errors, disable host name verification while setting up and validating the topology, and enable it again once the high availability topology configuration is complete.

To disable host name verification:

Log into Oracle WebLogic Server Administration Console.
In the Change Center, click Lock & Edit.
Expand the Environment node in the Domain Structure window.
Click Servers.
Select bi_server2 in the Names column of the table. The settings page for the server is displayed.
Open the SSL tab.
Expand the Advanced section of the page.
Set Hostname Verification to None.
Click Save.
Save and activate the changes.
The change will not take effect until the Administration Server is restarted (ensure that Node Manager is up and running):
1. In the Summary of Servers screen, select the Control tab.
2. Select AdminServer(admin) (represented as a hyperlink) in the table and then click Shutdown.
3. Start the Administration Server again from the command line:
```
APPHOST1> cd ORACLE_COMMON_HOME/bin
APPHOST1> ./wlst.sh
```
  Once in the WLST shell, execute the following command (make sure Node Manager is up and running):
```
wls:/offline> nmConnect ('Admin_User','Admin_Password', 'APPHOST1', '9556',
'domain_name', 'ORACLE_BASE/product/fmw/user_projects/domain/
bifoundation_domain')

wls:/nm/domain_name> nmStart ('AdminServer')
```

15.3.3.13 Configuring Oracle RTD

This section includes information about configuring Oracle RTD.

15.3.3.13.1 Configuring RTD Cluster-Specific Properties

Perform the following steps in Oracle Enterprise Manager Fusion Middleware Control:

Log into Fusion Middleware Control.
Expand the Application Deployments node in the Farm_domain_name window.
Click OracleRTD(11.1.1)(bi_cluster).
Click on any node under it. For example, OracleRTD(11.1.1)(bi_server1).
On the right pane, click Application Deployment, and then select System MBean Browser.
On the System MBean Browser pane, expand Application Defined MBeans.
For each server under Oracle RTD, navigate to the MBean and set the attribute shown in Table 15-9.

Table 15-9 Attribute Value to Set for Oracle RTD MBeans

MBean Attribute BI_SERVER1 Value

SDClusterPropertyManager->Misc

DecisionServiceAddress

http://bi.mycompany.com
Click Apply.

MBean	Attribute	BI_SERVER1 Value
SDClusterPropertyManager->Misc	DecisionServiceAddress	http://bi.mycompany.com

15.3.3.14 Starting the System in APPHOST2

This section describes procedures for starting the system in APPHOST2.

15.3.3.14.1 Configuring a Default Persistence Store for Transaction Recovery

Note:

Preferably, this location should be a dual-ported SCSI disk or on a Storage Area Network (SAN).

Perform these steps to set the location for the default persistence store for BI_SERVER1:

Log into the Oracle WebLogic Server Administration Console.
In the Domain Structure window, expand the Environment node and then click the Servers node.
Click BI_SERVER1 (represented as a hyperlink) in the Name column of the table.

The settings page for the BI_SERVER1 server opens with the Configuration tab active.
Click the Services tab.
In the Change Center, click Lock & Edit.
In the Default Store section of the page, enter the path to the folder where the default persistent stores will store its data files. The directory structure of the path is as follows:
```
ORACLE_BASE/admin/domain_name/bi_cluster/tlogs
```
Click Save and Activate Changes.
Repeat these steps for the BI_SERVER2 server.

Note:
To enable migration of the Transaction Recovery Service, specify a location on a persistent storage solution that is available to other servers in the cluster. Both APPHOST1 and APPHOST2 must be able to access this directory. This directory must also exist before you restart the server.

15.3.3.14.2 Starting Node Manager on APPHOST2

Usually, Node Manager is started automatically when config.sh completes. If Node Manager is not running for some reason, start the Node Manager on APPHOST2 by repeating the steps in Section 15.3.3.9.1, "Starting Node Manager on APPHOST1."

15.3.3.14.3 Starting and Validating the BI_SERVER2 Managed Server

To start the BI_SERVER2 managed server and check that it is configured correctly:

Start the bi_server2 managed server using Oracle WebLogic Server Administration Console, as follows:
1. Expand the Environment node in the Domain Structure window.
2. Choose Servers.
3. Click the Control tab.
4. Select bi_server2 and then click Start.
Verify that the server status is reported as "Running" in the Administration Console. If the server is shown as "Starting" or "Resuming", wait for the server status to change to "Started". If another status is reported (such as "Admin" or "Failed"), check the server output log files for errors
When BI_SERVER2 is started, the following URLs become available:
- Access http://APPHOST2:9704/wsm-pm to verify the status of Web Services Manager. Click Validate Policy Manager. A list of policies and assertion templates available in the data is displayed.
  
  Note:
  The configuration is incorrect if no policies or assertion templates appear.
- Access http://APPHOST2:9704/ui to verify the status of the Oracle RTD Decision Center application.

15.3.3.15 Configuring Oracle HTTP Server for the BI_SERVERn Managed Servers

To enable Oracle HTTP Server to route to bi_cluster, which contains the BI_SERVERn managed servers, you must set the WebLogicCluster parameter to the list of nodes in the cluster:

On WEBHOST1 and WEBHOST2, add the following lines to the ORACLE_BASE/product/fmw/Oracle_WT1/instances/web1/config/OHS/ohs1/mod_wl_ohs.conf file:

<Location /rtis>
   SetHandler weblogic-handler
   WebLogicCluster APPHOST1:9704, APPHOST2:9704
   WLProxySSL ON
   WLProxySSLPassThrough ON
</Location>
 
<Location /schema>
   SetHandler weblogic-handler
   WebLogicCluster APPHOST1:9704, APPHOST2:9704
   WLProxySSL ON
   WLProxySSLPassThrough ON
</Location>
 
<Location /ws>
   SetHandler weblogic-handler
   WebLogicCluster APPHOST1VHN1:9704, APPHOST2VHN1:9704
   WLProxySSL ON
   WLProxySSLPassThrough ON
</Location>

# WSM-PM
<Location /wsm-pm>
   SetHandler weblogic-handler
   WebLogicCluster APPHOST1:9704, APPHOST2:9704
   WLProxySSL ON
   WLProxySSLPassThrough ON
</Location>

# RTD
<Location /ui>
   SetHandler weblogic-handler
   WebLogicCluster APPHOST1:9704, APPHOST2:9704
   WLProxySSL ON
   WLProxySSLPassThrough ON
 </Location>

Perform the same steps for the Oracle HTTP Server on WEBHOST2.

Restart Oracle HTTP Server on WEBHOST1 and WEBHOST2:

WEBHOST1> ORACLE_BASE/product/fmw/Oracle_WT1/instances/web1/bin/
opmnctlrestartproc ias-component=ohs1

WEBHOST2> ORACLE_BASE/product/fmw/Oracle_WT1/instances/web1/bin/
opmnctlrestartproc ias-component=ohs1

15.3.3.16 Validating Access Through Oracle HTTP Server

Verify that you can access these URLs:

http://WEBHOST1:7777/wsm-pm
http://WEBHOST2:7777/wsm-pm
http://WEBHOST1:7777/ui
http://WEBHOST2:7777/ui

Verify that you can access these URLs using your load balancing router address:

http://bi.mycompany.com:80/ui
http://bi.mycompany.com:80/wsm-pm

Follow these instructions to ensure that routing and failover from the HTTP Server to the bi_cluster is working correctly:

While BI_SERVER2 is running, stop BI_SERVER1 from Oracle WebLogic Server Administration Console.
Access the following URLs and verify the appropriate functionality:
- WEBHOST1:7777/wsm-pm
- WEBHOST1:7777/ui
Start BI_SERVER1 from Oracle WebLogic Server Administration Console.
Stop BI_SERVER2.
Access the URLs in Step 2 above again and verify the appropriate functionality.

15.3.3.17 Configuring Server Migration for the BI_SERVERn Servers

15.3.3.18 Scaling Out the Oracle RTD Topology to a New Node (APPHOST3)

When you scale out the Oracle RTD topology, you add a new managed server and set of system components to a new node in your topology (APPHOST3). This section assumes that you already have a high availability topology that includes at least two nodes, with a managed server and a full set of system components on each node.

Before performing the steps in this section, check that you meet these requirements:

There must be existing nodes running Oracle RTD managed servers within the topology.
The new node (APPHOST3) can access the existing home directories for Oracle WebLogic Server and Oracle Business Intelligence.
When an ORACLE_HOME or WL_HOME is shared by multiple servers in different nodes, it is recommended that you keep the Oracle Inventory and Middleware home list in those nodes updated for consistency in the installations and application of patches. To update the oraInventory in a node and "attach" an installation in a shared storage to it, use ORACLE_HOME/oui/bin/attachHome.sh. To update the Middleware home list to add or remove a WL_HOME, edit the MW_HOME/.home file. See the steps below.
The new server can use a new individual domain directory or, if the other Managed Servers domain directories reside on shared storage, reuse the domain directories on those servers.

Perform these steps to scale out Oracle RTD on APPHOST3:

On APPHOST3, mount the existing Middleware home, which should include the Oracle Business Intelligence installation and (optionally, if the domain directory for Managed Servers in other nodes resides on shared storage) the domain directory, and ensure that the new node has access to this directory, just like the rest of the nodes in the domain.
To attach ORACLE_HOME in shared storage to the local Oracle Inventory, run the following command:
```
APPHOST3> cd ORACLE_COMMON_HOME/oui/bin/
APPHOST3> ./attachHome.sh -jreLoc ORACLE_BASE/product/fmw/jrockit_160_<version>
```
To update the Middleware home list, create (or edit, if another WebLogic installation exists in the node) the MW_HOME/.home file and add ORACLE_BASE/product/fmw to it.
Enable VIP3 in APPHOST3. See Section 15.2.3.3, "Enabling VIP1 in APPHOST1 and VIP2 in APPHOST2."
Run the Configuration Assistant from one of the shared Oracle homes, using the steps in Section 15.3.3.10, "Scaling Out the BI System on APPHOST2" as a guide.
Configure the bi_server3 Managed Server by setting the Listen Address and disabling host name verification, using the steps in Section 15.3.3.11, "Setting the Listen Address for the BI_SERVER2 Managed Server" and Section 15.3.3.12, "Disabling Host Name Verification for the BI_SERVER2 Managed Server" as a guide.
Perform additional Oracle Real-Time Decisions configuration steps for the bi_server3 Managed Server on APPHOST3, using the steps in Section 15.3.3.13, "Configuring Oracle RTD" as a guide.
Set the location of the default persistence store for bi_server 3, as described in Section 15.3.3.14.1, "Configuring a Default Persistence Store for Transaction Recovery."
Configure Oracle HTTP Server for APPHOST3VHN1, using the steps in Section 15.3.3.15, "Configuring Oracle HTTP Server for the BI_SERVERn Managed Servers" as a guide.
Start the bi_server3 Managed Server and the system components running on APPHOST3. See Section 15.3.3.9.2, "Starting and Validating the BI_SERVER1 Managed Server" for details.
To validate the configuration, access the http://APPHOST3VHN1:9704/ui URL to verify the status of the Oracle RTD application.
Oracle recommends using host name verification for the communication between Node Manager and the servers in the domain. This requires the use of certificates for the different addresses communicating with the Administration Server and other servers. See the chapter on setting up Node Manager in the Oracle Fusion Middleware Enterprise Deployment Guide for Oracle Business Intelligence for further details.