Skip Headers
Oracle® Fusion Middleware Enterprise Deployment Guide for Oracle Business Intelligence
11g Release 1 (11.1.1)

Part Number E15722-03
Go to Documentation Home
Go to Book List
Book List
Go to Table of Contents
Go to Index
Go to Feedback page
Contact Us

Go to previous page
Go to next page
PDF · Mobi · ePub

1 Enterprise Deployment Overview

This chapter provides an overview of the enterprise topology for Oracle Business Intelligence.


Oracle strongly recommends that you read Oracle Fusion Middleware Release Notes for any additional installation and deployment considerations before starting the setup process.

This chapter contains the following topics:

1.1 What Is an Enterprise Deployment?

This Enterprise Deployment Guide defines an architectural blueprint that captures Oracle's recommended best practices for a highly available and secure Oracle Business Intelligence deployment. The best practices described in this blueprint use Oracle products from across the technology stack, including Oracle Database, Oracle Fusion Middleware, and Oracle Enterprise Manager. The resulting enterprise deployment can be readily scaled out to support increasing capacity requirements.

In particular, an Oracle Business Intelligence enterprise deployment:

For more information on high availability practices, go to:


This document focuses on enterprise deployments in Linux environments, but enterprise deployments can also be implemented in UNIX and Windows environments.

1.2 Terminology

The following terms are used in this document:

In addition to the terms defined in this section, this Enterprise Deployment Guide assumes knowledge of general Oracle Fusion Middleware and Oracle WebLogic Server concepts and architecture. See Oracle Fusion Middleware Administrator's Guide for more information.

1.3 Benefits of Oracle Recommendations

The Oracle Fusion Middleware configurations discussed in this document are designed to ensure security of all invocations, maximize hardware resources, and provide a reliable, standards-compliant system for Oracle Business Intelligence.

The security and high availability benefits of the Oracle Fusion Middleware configurations are realized through isolation in firewall zones and replication of software components.

This section contains the following topics:

1.3.1 Built-in Security

The Enterprise Deployment architectures are secure because every functional group of software components is isolated in its own demilitarized zone (DMZ), and all traffic is restricted by protocol and port. A DMZ is a perimeter network that exposes external services to a larger untrusted network.

The following characteristics ensure security at all needed levels and a high level of standards compliance:

  • External load balancers are configured to redirect all external communication received on port 80 to port 443.


    You can find a list of validated load balancers and their configuration on the Oracle Technology Network at:

  • Communication from external clients does not go beyond the Load Balancing Router level.

  • No direct communication from the Load Balancing Router to the data tier is allowed.

  • Components are separated in different protection zones: the Web tier, application tier, and the data tier.

  • Direct communication between two firewalls at any one time is prohibited.

  • If a communication begins in one firewall zone, it must end in the next firewall zone.

  • Oracle Internet Directory is isolated in the data tier.

  • Identity Management components are in a separate subnet.

  • All communication between components across protection zones is restricted by port and protocol, according to firewall rules.

1.3.2 High Availability

The enterprise deployment architectures are highly available, because each component or functional group of software components is replicated on a different computer, and configured for component-level high availability.

1.4 Hardware Requirements

Typical hardware requirements for the Enterprise Deployment on Linux operating systems are listed in Table 1-1.

For detailed requirements, or for requirements for other platforms, see the Oracle Fusion Middleware Installation Guide for that platform.

Table 1-1 Typical Hardware Requirements

Server Processor Disk Memory TMP Directory Swap


4 or more X Pentium, 1.5 GHz or greater


n = number of disks, at least 4 (striped as one disk)

m = size of the disk (minimum of 30 GB)

6-8 GB




2 or more X Pentium, 1.5 GHz or greater

10 GB

4 GB




1 dual-core Pentium, 2.8 GHz or greater

20 GB or more

8 GB



1.5 Enterprise Deployment Reference Topology

The instructions and diagrams in this document describe a reference topology, to which variations may be applied.

This document provides configuration instructions for a reference enterprise topology that uses Oracle Business Intelligence with Oracle Access Manager, as shown in Figure 1-1.

Figure 1-1 MyBICompany Topology with Oracle Access Manager

Description of Figure 1-1 follows
Description of "Figure 1-1 MyBICompany Topology with Oracle Access Manager"

This section covers the following topics:

1.5.1 Oracle Identity Management

Integration with the Oracle Identity Management system is an important aspect of the enterprise deployment architecture. This integration provides features such as single sign-on, integration with OPSS, centralized identity and credential store, authentication for the WebLogic domain, and so on. The IDM (Identity Management) EDG is separate from this EDG and exists in a separate domain by itself. For more information on identity management in an enterprise deployment context, see Oracle Fusion Middleware Enterprise Deployment Guide for Oracle Identity Management.

The primary interface to the IDM EDG is the LDAP traffic to the LDAP servers, the OAP (Oracle Access Protocol) to the OAM Access Servers, and the HTTP redirection of authentication requests.

1.5.2 Web Tier

Nodes in the Web tier are located in the DMZ public zone.

In this tier, two nodes, WEBHOST1 and WEBHOST2, run Oracle HTTP Server configured with WebGate and mod_wl_ohs.

Through mod_wl_ohs, which allows requests to be proxied from Oracle HTTP Server to Oracle WebLogic Server, Oracle HTTP Server forwards the requests to Oracle WebLogic Server running in the application tier.

WebGate (which is an Oracle Access Manager component) in Oracle HTTP Server uses Oracle Access Protocol (OAP) to communicate with Oracle Access Manager running on OAMHOST2, in the Identity Management DMZ. WebGate and Oracle Access Manager are used to perform operations such as user authentication.

The Web tier also includes a load balancer router to handle external requests. External requests are sent to the virtual host names configured on the load balancer. The load balancer then forwards the requests to Oracle HTTP Server.

The WebGate module in Oracle HTTP Server uses Oracle Access Protocol (OAP) to communicate with Oracle Access Manager to perform operations such as querying user groups.

On the firewall protecting the Web tier, only the HTTP ports are open: 443 for HTTPS, and 80 for HTTP. Load Balancer Requirements

This enterprise topology uses an external load balancer. This external load balancer should have the following features:

  • Ability to load-balance traffic to a pool of real servers through a virtual host name

    Clients access services using the virtual host name (instead of using actual host names). The load balancer can then load balance requests to the servers in the pool.

  • Port translation configuration

    This feature is necessary so that incoming requests on the virtual host name and port are directed to a different port on the back-end servers.

  • Monitoring of ports on the servers in the pool to determine the availability of a service

  • Ability to configure virtual server names and ports

    Note the following requirements:

    • The load balancer should allow configuration of multiple virtual servers. For each virtual server, the load balancer should allow configuration of traffic management on multiple ports. For example, for Oracle HTTP Server in the Web tier, the load balancer must be configured with a virtual server and ports for HTTP and HTTPS traffic.

    • The virtual server names must be associated with IP addresses and be part of your DNS. Clients must be able to access the external load balancer through the virtual server names.

  • Ability to detect node failures and immediately stop routing traffic to the failed node

  • Fault-tolerant mode

    It is highly recommended that you configure the load balancer to be in fault-tolerant mode.

  • Ability to configure the virtual server to return immediately to the calling client

    It is highly recommended that you configure the load balancer virtual server to return immediately to the calling client when the back-end services to which it forwards traffic are unavailable. This is preferred over the client disconnecting on its own after a timeout based on the TCP/IP settings on the client computer.

  • Sticky routing capability

    Sticky routing capability is the ability to maintain sticky connections to components. Examples of this include cookie-based persistence, IP-based persistence, and so on.

  • SSL acceleration

    The load balancer should be able to terminate SSL requests at the load balancer and forward traffic to the back-end real servers using the equivalent non-SSL protocol (for example, HTTPS to HTTP). Typically, this feature is called SSL acceleration and it is required for this EDG.

1.5.3 Application Tier

Nodes in the application tier are located in the DMZ secure zone.

APPHOST1 and APPHOST2 run the Oracle WebLogic Server Administration Console and Oracle Enterprise Manager Fusion Middleware Control, but in an active-passive configuration. You can fail over the Administration Server manually (see Section 5.14, "Manually Failing Over the Administration Server to APPHOST2"); alternatively you can configure the Administration Console with CFC/CRS to fail over automatically on a separate hardware cluster (not shown in this architecture).

The Oracle Business Intelligence Cluster Controller and Oracle BI Scheduler system components run on APPHOST1 and APPHOST2 in an active-passive configuration. The other Oracle Business Intelligence system components, Oracle BI Server, Oracle BI JavaHost, and Oracle BI Presentation Services, run on APPHOST1 and APPHOST2 in an active-active configuration. All system components are managed by OPMN and do not run in the Managed Servers.

The Oracle Business Intelligence Java components, including Oracle Real-Time Decisions, Oracle BI Publisher, Oracle BI for Microsoft Office, and the Oracle BI Enterprise Edition Analytics application, run in the two Managed Servers on APPHOST1 and APPHOST2. Oracle Web Services Manager (Oracle WSM) is another Java component that provides a policy framework to manage and secure Web services in the EDG topology. WSM Policy Manager runs in active-active configuration in the two Managed Servers in APPHOST1 and APPHOST2.

1.5.4 Data Tier

Nodes in the data tier are located in the most secured network zone (the intranet).

In this tier, an Oracle RAC database runs on the nodes CUSTDBHOST1 and CUSTDBHOST2. The database contains the schemas needed by the Oracle Business Intelligence components. The Oracle Business Intelligence components running in the application tier access this database.

On the firewall protecting the data tier, the database listener port (typically, 1521) is required to be open. The LDAP ports (typically, 389 and 636) are also required to be open for the traffic accessing the LDAP storage in the IDM EDG.

1.5.5 What to Install

Table 1-2 identifies the source for installation of each software component. For more information, see Oracle Fusion Middleware Installation Guide for Oracle Business Intelligence.

Table 1-2 Components and Installation Sources

Component Distribution Medium

Oracle Database 10g or 11g

Oracle Database CD (in 10g series, or higher; in 11g series, or higher)

Repository Creation Utility (RCU)

Oracle Fusion Middleware Repository Creation Utility 11g ( DVD

Oracle WebLogic Server (WLS)

Oracle Weblogic Server (10.3.1) DVD

Oracle HTTP Server

Oracle Fusion Middleware WebTier and Utilities 11g ( DVD

Oracle Business Intelligence

Oracle Business Intelligence 11g ( DVD

Oracle Access Manager 10g Webgate

Oracle Access Manager 10g Webgates ( DVD; OAM OHS 11g Webgates per platform

Oracle Virtual Directory (OVD)

Oracle Identity Management 11g ( DVD

1.5.6 Unicast Requirement

Oracle recommends that the nodes in the MyBICompany topology communicate using unicast. Unlike multicast communication, unicast does not require cross-network configuration and it reduces potential network errors that can occur from multicast address conflicts as well.

The following considerations apply when using unicast to handle cluster communications:

  • All members of a WebLogic cluster must use the same message type. Mixing between multicast and unicast messaging is not allowed.

  • Individual cluster members cannot override the cluster messaging type.

  • The entire cluster must be shut down and restarted to change the message modes (from unicast to multicast or from multicast to unicast).

  • JMS topics configured for multicasting can access WebLogic clusters configured for unicast because a JMS topic publishes messages on its own multicast address that is independent of the cluster address. However, the following considerations apply:

    • The router hardware configurations that allow unicast clusters may not allow JMS multicast subscribers to work.

    • JMS multicast subscribers must be in a network hardware configuration that allows multicast accessibility. (That is, JMS subscribers must be in a multicast-enabled network to access multicast topics.)