2 Introduction to the Enterprise Deployment Reference Topologies

This chapter describes and illustrates the Oracle Fusion Customer Relationship Management enterprise deployment reference topologies described in this guide. The road map for installation and configuration directs you to the appropriate chapters for the tasks you need to perform. Use this chapter to help you plan your Oracle Fusion Customer Relationship Management enterprise deployment.

This chapter includes the following topics:

Section 2.1, "Overview of Reference Enterprise Deployment Topologies"
Section 2.2, "Hardware Requirements"
Section 2.3, "Installation Prerequisite"
Section 2.4, "Implementing the Topology"

2.1 Overview of Reference Enterprise Deployment Topologies

This section describes diagrams used in an Oracle Fusion Customer Relationship Management enterprise deployment. Use this section to plan your enterprise deployment topology.

This section includes the following topics:

Section 2.1.1, "Overall Reference Enterprise Deployment Topology"
Section 2.1.2, "Reference Topologies Documented in the Guide"
Section 2.1.3, "About the Web Tier Nodes"
Section 2.1.4, "About the Application Tier"
Section 2.1.5, "About the Data Tier"

2.1.1 Overall Reference Enterprise Deployment Topology

Figure 2-1 shows the overall Oracle Fusion Customer Relationship Management reference enterprise deployment topology, to which variations may be applied. The graphic illustrates how all components are deployed together.

In the topology, the primary node (also known as a host, and is CRMHOST1 in the diagram) is actively running the Oracle Fusion Applications instance. The secondary node (CRMHOST2) is the redundant (HA) node for the Oracle Fusion Applications instance. The primary node consists of an Administration Server and applications that have been deployed to Managed Servers. Managed Servers can be grouped together in clusters to provide scalability and high availability for applications. Together, the primary and secondary nodes form a domain.

Figure 2-1 Oracle Fusion CRM Reference Enterprise Deployment Topology

As shown in Figure 2-1, the overall Oracle Fusion Applications reference enterprise deployment topology comprises several domains:

Oracle Fusion Customer Relationship Management Domain
Oracle Fusion Common Domain
Oracle Fusion Human Capital Management Domain
Oracle Fusion Supply Chain Management Domain
Oracle Fusion Financials Domain
Oracle Fusion Incentive Compensation Domain
Oracle Business Intelligence Domain

Figure 2-2 shows each of the domains in detail.

Figure 2-2 Domain Details

The scale out of these domains is described in the chapters that follow.

For information about installing the Oracle Identity Management stack for Oracle Fusion Applications, see Section 5.2, "Prerequisites for Using the Provisioning Process."

2.1.2 Reference Topologies Documented in the Guide

This section describes the references topologies used in an Oracle Fusion Customer Relationship Management enterprise deployment.

2.1.2.1 Oracle Fusion Customer Relationship Management Domain

Figure 2-3 shows the Oracle Fusion Customer Relationship Management domain within the overall reference enterprise deployment topology for Oracle Fusion Applications.

Figure 2-3 Reference Topology for Oracle Fusion Customer Relationship Management Domain

Ref. Topology: Customer Relationship Mgmt.

2.1.2.2 Oracle Fusion Common Domain

Figure 2-4 shows the Oracle Fusion Common domain within the overall reference enterprise deployment topology for Oracle Fusion Applications.

Figure 2-4 Reference Topology for Oracle Fusion Common Domain

2.1.2.3 Oracle Fusion Human Capital Management Domain

Figure 2-5 shows the Oracle Fusion Human Capital Management domain within the overall reference enterprise deployment topology for Oracle Fusion Applications.

Figure 2-5 Reference Topology for the Oracle Fusion Human Capital Management Domain

Ref. Topology: Human Capital Mgmt. Domain

2.1.2.4 Oracle Fusion Supply Chain Management Domain

Figure 2-6 shows the Oracle Fusion Supply Chain Management domain within the overall reference enterprise deployment topology for Oracle Fusion Applications.

Figure 2-6 Reference Topology for Oracle Fusion Supply Chain Management

Ref. Topology for Supply Chain Mgmt. Domain

2.1.2.5 Oracle Fusion Financials Domain

Figure 2-7 shows the Oracle Fusion Financials domain within the overall reference enterprise deployment topology for Oracle Fusion Applications.

Figure 2-7 Reference Topology for Oracle Fusion Financials Domain

2.1.2.6 Oracle Fusion Incentive Compensation Domain

Figure 2-8 shows the Oracle Fusion Incentive Compensation domain within the overall reference enterprise deployment topology for Oracle Fusion Applications.

Figure 2-8 Reference Topology for Oracle Fusion Incentive Compensation

Ref. Topology: Incentive Compensation Domain

2.1.2.7 Oracle Business Intelligence Domain

Figure 2-9 shows the Oracle Business Intelligence domain within the overall reference enterprise deployment topology for Oracle Fusion Applications.

Figure 2-9 Reference Topology for Oracle Business Intelligence Domain

Ref. Topology: Oracle Business Intelligence Domain

2.1.3 About the Web Tier Nodes

Nodes in the Oracle Web Tier are located in the demilitarized zone (DMZ) public zone. In this tier, two nodes WEBHOST1 and WEBHOST2 run Oracle HTTP Server configured with WebGate and FusionVirtualHost_domain.conf.

Through FusionVirtualHost_domain.conf, which allows requests to be proxied from Oracle HTTP Server to WebLogic Server, Oracle HTTP Server forwards the requests to 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 OAMHOST1 and OAMHOST2, in the Identity Management DMZ. WebGate and Oracle Access Manager are used to perform operations such as user authentication.

The Oracle 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 Oracle Web Tier, only the HTTP ports are open: 443 for HTTPS and 80 for HTTP.

2.1.3.1 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 should be possible 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 availability of a service.
Virtual servers and port configuration: Ability to configure virtual server names and ports on your external load balancer, and the virtual server names and ports must meet 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 more than one port. For example, for Oracle HTTP Server in the Oracle Web Tier, the load balancer needs to 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.
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: Ability to maintain sticky connections to components. Examples of this include cookie-based persistence, IP-based persistence, and so on.
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 enterprise deployment.

2.1.4 About the Application Tier

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

CRMHOST1 and CRMHOST2 run all the managed servers in the Oracle Fusion Customer Relationship Management, Oracle Business Intelligence, Oracle Incentive Compensation, Oracle Fusion Financials, Oracle Fusion Supply Chain Management, and Oracle Fusion Human Capital Management domains.

CRMHOST1 and CRMHOST2 run the managed and C/C++ servers from different domains in an active-active or active-passive implementation. C/C++ components are managed by Oracle Process Manager and Notification Server (OPMN), and all the managed servers are managed by Administration Server within the domain.

CRMHOST1 and CRMHOST2 also run the Oracle WebLogic Server Administration Console and Oracle Enterprise Manager Fusion Middleware Control, but in an active-passive configuration. You also can fail over the Administration Server manually. Alternatively, you can configure the Oracle WebLogic Server Administration Console with CFC/CRS to fail over automatically on a separate hardware cluster.

Oracle Web Services Manager (Oracle WSM) provides a policy framework to manage and secure Web services in the enterprise deployment topology. WSM Policy Manager also runs in active-active configuration in every Fusion domain where Web Services are hosted.

On the firewall protecting the application tier, the HTTP ports, OAP port, and proxy port are open. The OAP port is for the WebGate module running in Oracle HTTP Server in the Oracle Web Tier to communicate with Oracle Access Manager. Applications requiring external HTTP access use Oracle HTTP Server as the proxy. (The proxy on the Oracle HTTP Server must be enabled to allow this access.)

2.1.5 About the 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 FUSIONDBHOST1 and FUSIONDBHOST2. The database contains the schemas needed by the Oracle Fusion Applications components. The 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 enterprise deployment.

2.2 Hardware Requirements

This section provides recommended hardware for the Oracle Fusion Applications reference enterprise deployment topology on Linux operating systems.

The recommended hardware for the Oracle Fusion Applications reference enterprise deployment topology consists of six 96 GB Intel Westmere, six dual-core CPU servers (excluding Oracle HTTP Server and Oracle Database servers). Table 2-1 describes the typical hardware requirements.

Table 2-1 Example Hardware Requirements - 200 Concurrent Users

Server	Processor	Memory	TMP	SWAP
`CRMHOST1`	6 core 2 CPU Westmere	96 GB	default	default
`CRMHOST2`	6 core 2 CPU Westmere	96 GB	default	default
`CRMHOST3`	6 core 2 CPU Westmere	96 GB	default	default
`WEBHOST1`	2 core 2 CPU	4 GB	default	default
`WEBHOST2`	2 core 2 CPU	4 GB	default	default
`FUSIONDBHOST1`	4 core 4 CPU	48 GB	default	default
`FUSIONDBHOST2`	4 core 4 CPU	48 GB	default	default

2.3 Installation Prerequisite

The Oracle Identity Management stack for Oracle Fusion Applications should already be installed prior to starting a deployment. Note, however, that the provisioning process described in Chapter 5, "Using the Provisioning Process to Install Components for an Enterprise Deployment," cannot proceed without it. Follow the instructions in Oracle Fusion Middleware Enterprise Deployment Guide for Oracle Identity Management (Oracle Fusion Applications Edition) to install and configure these components.

2.4 Implementing the Topology

Oracle recommends the following approach when implementing the Oracle Fusion Applications topology outlined in Section 2.1, "Overview of Reference Enterprise Deployment Topologies":

Oracle recommends this modular approach in order to facilitate the verification of individual components one by one. This building block approach simplifies the troubleshooting during the setup process and facilitates the configuration in smaller steps.