4 Planning the Configuration of the Components of Your Installation

This chapter contains the following sections, each of which corresponds to a tab in the Oracle Fusion Applications Installation Workbook:

4.1 Network- Virtual Hosts: Planning Network Configuration

Filling in the Network-Virtual Hosts tab of the Oracle Fusion Applications Installation Workbook entails understanding and deciding about a range of Oracle Fusion Applications concepts and conventions.

4.1.1 Understanding Internal vs. External URLs

Both the Oracle Identity Management and the Oracle Fusion Applications install procedures use the concept of internal and external HTTP endpoints as part of their service-oriented architecture. External HTTP endpoints are used by end-users to access the system and are used for the login screen, welcome pages, transaction pages, online help, and so on. Internal HTTP endpoints are not meant to be seen by end-users and instead are used for inter-component communication.

This distinction exists for security as well as topology reasons, allowing for maximum flexibility when deploying Oracle Fusion Applications on an enterprise environment. Since internal endpoints are not exposed externally, this provides a layer of security, and since internal traffic can easily be restricted to specific network segments, there is no need for extra security measures such as encryption. External HTTP endpoints allow for maximum topology flexibility: since they are the only external entry points for all Oracle Fusion Applications traffic, they are the only points in the topology that must be directly accessible to the external world; all other components can be located inside a firewall while still providing 100% access to end-users and other applications that integrate with Oracle Fusion Applications.

Both external and internal endpoints can be configured directly at the HTTP Server (in which case internal and external URLs will point at the HTTP Server) or can be configured at a Load Balancer or Reverse Proxy (in which case internal and external URLs will point at the LBR/RP and it in turn must be configured to point at the HTTP Server).

4.1.2 Naming Conventions in Oracle Fusion Applications

These conventions are used when naming URLs/endpoints within Oracle Fusion Applications, Oracle Identity Management, and in any load balancer that may be used.

4.1.2.1 Planning URL Naming Conventions

Naming conventions for network configuration are extremely important, since they will define the URLs that will be used by end-users to access the system, as well as defining all the internal "wiring."

When choosing hostnames for external HTTP endpoints, choose meaningful, easy-to-remember names, as they will be used by end-users.

When choosing hostnames for servers, virtual IP addresses (VIPs), and internal HTTP endpoints, note the following:

  • These names will be used for all Oracle Fusion Applications-Oracle Fusion Applications addressing.

  • Once chosen, these names cannot be changed!

  • It is best to use environment-neutral (abstract) names, rather than names that include clues such as "test" or "prod" or "staging". Since the names are used to maintain internal wiring, they may be deployed on more than one environment (for example, if you clone an installation). Choose environment-neutral names to avoid headaches later.

4.1.3 Planning Load Balancer Requirements

A Load Balancer (LBR) is required for scaled-out enterprise topologies. It is used to balance and route:

  • External HTTP traffic from end-users to the Oracle Fusion Applications and Oracle Identity Management Web Tiers

  • Internal HTTP traffic from the mid tiers to the Web Tiers (for both Oracle Fusion Applications and Oracle Identity Management)

  • Internal LDAP (TCP) traffic from mid tiers to the Identity and Policy Stores (directory tier)

  • Internal TCP traffic from the Oracle Fusion Applications mid tier to the Oracle WebCenter Content (UCM) socket listeners

If the topology is not scaled out, an LBR/Reverse proxy is not mandatory, but it is recommended for enterprise topologies with the following characteristics:

  • External access requiring that traffic go through a DMZ with the Oracle Fusion Applications Web Tier located in the internal network

  • The environment is not currently scaled out but may be in the future

For development environments, an LBR/RP is normally not required or used. In this case, the Provisioning framework can have the LBR option turned off which will set up the Web Tier (OHS) as the HTTP endpoint for Oracle Fusion Applications.

4.1.3.1 SSL Certificate Requirements

Both Oracle Identity Management and Oracle Fusion Applications terminate SSL connections at the LBR. Therefore, it is necessary to set up the appropriate SSL certificates on the LBR prior to starting the provisioning process. More details are provided in Section 4.6, "SSL and Certificates".

4.1.3.2 How the Load Balancer Option Affects the Environment Setup

When Provisioning Oracle Identity Management

When running the Oracle Identity Management Provisioning Tool, the load balancer option not available with the "Single-host" install. The other alternative, "EDG" topology, prompts for three IDM HTTP endpoints and three LDAP endpoints.

Description of plan_idm_lbr.gif follows
Description of the illustration plan_idm_lbr.gif

The requirements for this screen are described in the table below:

Table 4-1 Load Balancer SSL Requirements

Endpoint Type SSL? Description

HTTP/HTTPS Requirements

Admin

Optional

Defines the host configuration on the Oracle HTTP Server (specifically the ServerName clause on the virtual host configuration .conf files)

Internal

Not allowed

Defines the URLs configured internally for the HTTP endpoints

SSO

Required

 

LDAP Requirements

OID Endpoint

 


LDAP LBR endpoints are only used for the URLs configured internally for the LDAP endpoints.

OVD Endpoint

 

All load balancer configuration must be performed by the network administrators; the Oracle Identity Management Provisioning process does not automate that or provide any specific settings for load balancer/reverse proxy configuration.

When Provisioning Oracle Fusion Applications

For Oracle Fusion Applications provisioning, the load balancer option is available for any topology. All load balancer configuration, adding internal and external virtual IP host and port, must be performed by the network administrators before you start provisioning Oracle Fusion Applications. The Oracle Fusion Applications Provisioning process does not install load balancer or provide any specific settings for load balancer/reverse proxy configuration. For more information about planning load balancer requirements, see Section 4.1.3, "Planning Load Balancer Requirements".

Description of config_balance.png follows
Description of the illustration config_balance.png

If selected, this setting will affect:

  • Virtual host configuration on the Oracle HTTP Server (more specifically the ServerName clause in the virtual host configuration .conf files)

  • The URLs configured internally for the HTTP endpoints.

Note:

Whether or not the load balancer is selected has an affect on the SSL configuration at the OHS. This is discussed in Section 4.1.3.1.

4.1.3.3 Network Placement of Load Balancers/Reverse Proxy

If you decide to use a load balancer/reverse proxy, it is important to consider where on the network it should be placed, and whether firewalls exist between it and the Oracle Fusion Applications mid tier and Web Tier.

For example, if a load balancer is placed in the DMZ and is configured for both internal and external Oracle Fusion Applications traffic, this may be undesirable for security reasons. (In this case, internal traffic from the Oracle Fusion Applications and Oracle Identity Management mid tiers will go through the DMZ to get to the respective web tiers.) Additionally, firewall ports may have to be opened for traffic from the internal network to the DMZ, and TCP traffic (for LDAP and UCM) will be going through the DMZ.

In this case, placing an additional load balancer on the internal network is recommended for internal traffic (HTTP and TCP), to prevent it from going through the DMZ.

The following diagrams show both scenarios in more detail:

Figure 4-1 Load Balancer Placed Outside the internal Network

Description of Figure 4-1 follows
Description of "Figure 4-1 Load Balancer Placed Outside the internal Network"

Figure 4-2 Internal/External LBR Configuration

Description of Figure 4-2 follows
Description of "Figure 4-2 Internal/External LBR Configuration"

Follow the decision tree to plan the usage and placement of a load balancer, and to fill out the Oracle Fusion Applications Installation Workbook appropriately. Enter decisions on the Environment tab, Environment Info table, Load Balancer/Reverse proxy row.

Figure 4-3 Load Balancer/Reverse Proxy Decision Tree

Description of Figure 4-3 follows
Description of "Figure 4-3 Load Balancer/Reverse Proxy Decision Tree"

4.1.3.4 Load Balancer Feature Requirements

Several virtual servers and associated ports must be configured on the load balancer for different types of network traffic and monitoring. These should be configured to the appropriate real hosts and ports for the services running. Also, the load balancer should be configured to monitor the real host and ports for availability so that the traffic to these is stopped as soon as possible when a service is down. This ensures that incoming traffic on a given virtual host is not directed to an unavailable service in the other tiers.

If your topology uses a load balancer, it must 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

  • Port monitoring (HTTP and HTTPS)

  • Resource monitoring / port monitoring / process failure detection: The load balancer must be able to detect service and node failures (through notification or some other means) and to stop directing non-Oracle Web traffic to the failed node. If your external load balancer has the ability to automatically detect failures, you should use it.

  • Ability to Preserve the Client IP Addresses: The load balancer must have the capability to insert the original client IP address of a request in an X-Forwarded-For HTTP header to preserve the Client IP Address.

  • Virtual servers and port configuration: Ability to configure virtual server names and ports on your external load balancer.

Note that there are also requirements for the virtual server names and ports, as follows:

  • 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.

  • The load balancer should allow configuration of multiple virtual servers, and for each virtual server, the load balancer should allow configuration of traffic management on more than one port. For example, for Oracle WebLogic Clusters, the load balancer must be configured with a virtual server and ports for HTTP and HTTPS traffic.

The last list of features are recommended, though not required for every topology:

  • It is 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 time-out based on the TCP/IP settings on the client machine.

  • SSL termination is used in the Oracle Identity Management EDG topology as well as all Oracle Fusion Applications topologies. This is the ability 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, the load balancer must be able to forward HTTPS requests as HTTP.)

  • Configure the virtual servers for the Directory Tier in the load balancer with a high value for the connection time-out for TCP connections. This value should be more than the maximum expected time over which no traffic is expected between Oracle Access Manager and the Directory Tier.

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

  • SSL acceleration is recommended, but not required. This refers to off-loading the public-key encryption algorithms involved in SSL transactions to a hardware accelerator.

  • Have the ability to add WL-Proxy-SSL: true to the HTTP Request Header. Some load balancers do this automatically.

4.1.4 Planning HTTP Server Requirements

Both Oracle Identity Management and Oracle Fusion Applications Provisioning will install their own Oracle HTTP Server, which is the primary endpoint for all HTTP traffic, both internal and external. While each provisioning tool may configure its HTTP Server slightly differently, it is important that the planning phase take both into consideration when deciding:

  • Naming convention for virtual hosts

  • DMZ placement

  • Port usage

Note the following default setups:

  • Oracle Identity Management Provisioning requires hostnames for only the LBR endpoint. The OHS listeners and name-based virtual hosts are set up with wildcards. Oracle Fusion Applications, however, always requires hostnames for the OHS endpoints even when using an LBR, and its virtual hosts are set up using those hostnames. This has implications when choosing name-based vs. IP or port-based virtual hosts for Oracle Fusion Applications.

  • Both Oracle Identity Management and Oracle Fusion Applications Provisioning terminate SSL connections at the LBR (external HTTP endpoints only). This means that when the LBR option is selected during provisioning, the OHS virtual hosts will not be configured with an SSL listener and therefore the connection between the LBR and OHS will always be non-SSL and SSL certificates must be set up at the LBR.

    On the other hand, if the LBR option is NOT selected, the consequences differ.

    For Oracle Identity Management, only the "Basic" topology allows no LBR. In this case, OHS is configured with no SSL for all internal, external and admin virtual hosts.

    For Oracle Fusion Applications Provisioning, the OHS will be set up with SSL on the external virtual hosts, which will require installing SSL certificates.

4.1.4.1 Defining Web Tier Virtual Host Mode

Oracle Identity Management Provisioning always uses name-based virtual hosts.

Oracle Fusion Applications Provisioning allows you to choose which method you prefer:

  • Port-based

  • Name-based

  • IP-based

The choice depends on whether a load balancer is used or not, and the hostname/port convention desired for endpoints.

If a load-balancer is used, then IP- or Port-based mode is used.

The following table shows the parameters.

Virtual Host Configuration Description # of Ports # of Host Names
Port-based Based on the incoming port 2 per domain (one internal and one external) No virtual hosts will be used
Name-based Based on the incoming host name 2: one internal (non-SSL) and one external (SSL) 2 per domain (one internal and one external)
IP-based Based on IP:Port combination At least 1 and up to 2 per domain (one internal and one external) At least 1 and up to 2 per domain (one internal and one external)

Figure 4-4 Choosing Virtual Host Mode; Name-, Port- or IP-Based

Description of Figure 4-4 follows
Description of "Figure 4-4 Choosing Virtual Host Mode; Name-, Port- or IP-Based"

4.1.5 Defining VIPs for Administration and Managed Servers

A virtual IP address is an unused IP Address which belongs to the same subnet as the host's primary IP address. It is assigned to a host manually and Oracle WebLogic Managed servers are configured to listen on this IP Address. In the event of the failure of the node where the IP address is assigned, the IP address is assigned to another node in the same subnet, so that the new node can take responsibility for running the managed servers assigned to it.

4.1.5.1 Define VIPs for Oracle Identity Management

The following is a list of the Virtual IP addresses required by Oracle Identity Management:

  • IDMDomain AdminServer: In Enterprise deployments, the WebLogic Administration Server must be able to continue processing requests even if the host on which it resides fails. A virtual IP address should be provisioned in the Application Tier so it can be bound to a network interface on any host in the Application Tier. The WebLogic Administration Server is configured later to listen on this virtual IP address. The virtual IP address fails over along with the Administration Server from IDMHOST1 to IDMHOST2, or vice versa.

  • IDMDomain SOA Server: One virtual IP address is required for each SOA managed server. This enables the servers to participate in Server migration. Provision a virtual IP address in the Application Tier so it can be bound to a network interface on any host in the Application Tier.

  • IDMDomain OIM Server: One virtual IP Address is required for each Oracle Identity Manager managed server. This enables the servers to participate in Server migration. Provision a virtual IP address in the Application Tier so it can be bound to a network interface on any host in the Application Tier.

4.1.5.2 Define VIPs for Oracle Fusion Applications

Configure the Administration Server and the Managed Servers to listen on different virtual IPs. Oracle Fusion Applications VIPs are required in Enterprise-HA topologies to configure specific components:

  • Virtual IPs for AdminServer are needed for every domain to configure AdminServer in active-passive mode. These VIPs are shared across primary and secondary hosts, depending on where the Administration Server is running.

  • Virtual IPs for all Oracle SOA Suite servers in every domain, and Oracle Business Intelligence servers in the Oracle Business Intelligence domain are needed to support server migration. These components are implemented in active-active mode, so these VIPs are needed for primary and secondary hosts.

4.1.6 Completing the Network-Virtual Hosts Tab of the Oracle Fusion Applications Installation Workbook

The Network-Virtual Hosts tab includes the following tables:

4.1.6.1 Complete the Web Tier Virtual Host Mode Table

Select the appropriate virtual host mode (name-, port-, or IP-based), as determined in Section 4.1.4.1

4.1.6.2 Complete the FA Web Tier Virtual Hosts Table

How you complete this table depends on the Virtual Host Mode you chose (Section 4.1.4.1. Each row of the table is described in Section 4.1.6.2.1; the mode-based usage is as follows:

Port-Based

  • Internal and External Hostnames: Will not be used. Leave them blank or mark N/A.

  • Ports: The Oracle Fusion Applications Installation Workbook provides the default ports to be used; they are the same as the defaults presented on the Provisioning Wizard. We recommend keeping the defaults (see Section 4.2.1 for details if needed).

Name-Based

  • Internal and External Hostnames: Select the external and internal hostnames to be used for the Oracle Fusion Applications Web Tier. The Oracle Fusion Applications Installation Workbook provides the defaul hostnames as presented on the Provisioning Wizard. See Section 4.1.2.1, "Planning URL Naming Conventions", for more detail. Note: this virtual host mode is not recommend for use with a load balancer, as indicated in Section 4.1.4.1, "Defining Web Tier Virtual Host Mode".

  • Ports: In name-based mode, you should not use the "Internal Port" or " External Port" columns. Make them blank or mark them N/A.
    The reason is that in this mode, the default ports defined for the Oracle Fusion Applications HTTP Server are used by the Provisioning Wizard as follows:

    - Internal Port: Oracle Fusion Applications Installation Workbook - Network-Ports tab -> Fusion Applications Port Numbers -> FA Oracle HTTP Server

    - External Port: Oracle Fusion Applications Installation Workbook - Network-Ports tab -> Fusion Applications Port Numbers -> FA Oracle HTTP Server SSL.

IP-Based

This mode lets you select both port and hostname and has the defaults as presented on the Provisioning Wizard.

In all three modes, the IP Address column should contain the IP address of the host that will run the Oracle Fusion Applications Web Tier. They will normally be all the same.

4.1.6.2.1 FA Web Tier Virtual Hosts Table Rows Defined

A general description of each row is below. How you use them depends on the Virtual Host Mode, above.

  • FA Web Tier Internal Name: The internal and external names point to the Oracle Fusion Applications Web Tier host or hosts. It can be advantageous/more user-friendly to assign names that indicate their use; for example, the Financials preceded by fin-ext (external) or fin-int (internal), as shown in the defaults. If you assign a name that differs from the default structure, it will need to be added to the /etc/hosts file (or equivalent /hosts for Windows).

  • Internal Port: The default ports are provided by the Provisioning Wizard and are pre-entered in the Oracle Fusion Applications Installation Workbook. Change only if necessary for your enterprise. Different ports must be assigned to each product.

  • FA Web Tier External Name: The internal and external names point to the Oracle Fusion Applications Web Tier host or hosts. It can be advantageous/more user-friendly to assign names that indicate their use; for example, the Financials preceded by fin-ext (external) or fin-int (internal), as shown in the defaults. If you assign a name that differs from the default structure, it will need to be added to the /etc/hosts file (or equivalent /hosts for Windows).

  • External Port: The default ports are provided by the Provisioning Wizard and are pre-entered in the Oracle Fusion Applications Installation Workbook. Change only if necessary for your enterprise. Different ports must be assigned to each product.

  • IP Address: Provide the IP address of the Oracle Fusion Applications Web Tier.

4.1.6.3 Complete the IDM Web Tier Virtual Hosts Table

The Oracle Identity Management Web Tier hosts must share a common port. The IP address points at the Oracle Identity Management Web Tier.

External, Internal and Admin hostnames cannot be chosen. They will default to the hostname defined in the Topology tab -> Topology table for the component "IDM Web Tier," and will be greyed out on the Provisioning Wizard.

4.1.6.4 Complete the LDAP Endpoints Table

The entries in this table differ depending on whether you chose the "Single Host" or "EDG" topology for Oracle Identity Management. Check your Oracle Fusion Applications Installation Workbook: Environment tab, Environment Info table, IDM Topology Type. To fill in this table, follow these steps:

Determine whether you are using Single-host or EDG topology.

If Single-host, then enter the abstract hostname (or real hostname if not using an abstract one) for the node where you assigned the "IDM Directory" component in the Topology tab. When you run the Oracle Identity Management Provisioning Wizard, these values will be automatically pre-populated and greyed out. They cannot be changed.

If EDG, then you can choose virtual host names for the Policy Store and Identity Store (OVD). These will later be defined either in DNS or /etc/hosts. If a load balancer is used, then the virtual host name and port described here will point to the LBR.

The ports are predefined and should only be changed if required by your enterprise.

  • OID Identity Store (OID): If you are using the Single-host Topology and have OID as your Identity Store, enter the abstract host name and ports. It is the same as the Policy Store and cannot be changed.

  • Policy Store (OID): Define an abstract host name for the Policy Store. Must be defined either in DNS or /etc/hosts. The default port values are already entered and should not be changed unless you are changing the OID port numbers in general.

  • Identity Store (OVD): Define the abstract host name for the Identity Store and the ports. Otherwise, if you chose to use OID as your Identity Store, use the OID ports.

4.1.6.5 Complete the UCM LBR Endpoint Table

If you are using high availability, then an entry in the load balancer is needed to distribute the load among UCM servers.

  • Hostname: The load balancer entry here will be configured to distribute traffic among UCM managed servers in the UCM cluster. Enter the load balancer virtual host name used for UCM distribution.

  • Port: Only change the default port if required by your enterprise. Port must be configured for TCP traffic.

4.1.6.6 Complete the HTTP LBR Endpoints Table

Select the external and internal hostnames that to be used for the HTTP Endpoints at the Load Balancer or Reverse proxy. The Oracle Fusion Applications Installation Workbook provides the default hostnames as presented on the Provisioning Wizard. See Section 4.1.2.1, "Planning URL Naming Conventions" for details.

We recommend keeping the default port numbers, as mentioned in Section 4.2.1, "Using Default vs. Custom Port Numbers".

4.1.6.7 Complete the AdminServer Virtual Hosts/VIPs Table

The Oracle Identity Management-related entry is needed for all Enterprise topologies. The Oracle Fusion Applications entries are only needed when planning for Enterprise high availability (HA). You only need to define entries for those products you have licensed.

See Section 4.1.5.1, "Define VIPs for Oracle Identity Management" for general discussion.

  • Virtual Host Name: For each domain, define a Virtual Hostname. The network administrator will later need to set these up in DNS.

  • Virtual IP Address: For each domain, define a Virtual IP.

4.1.6.8 Complete the Managed Server Virtual Hosts/VIPs Table

Like the Admin Server entries above, the Oracle Identity Management-related entries are needed for all Enterprise topologies. The Oracle Fusion Applications entries are only needed when planning for Enterprise high availability (HA). You only need to define entries for those products you have licensed. For each managed server in the table, you must define a virtual host name and IP for each scale-out node.

4.2 Network-Ports: Planning Ports

Default ports are provided by Oracle Identity Management and Oracle Fusion Applications Provisioning, and are listed in the Oracle Fusion Applications Installation Workbook. The network administrator of your enterprise will determine whether these can be used or should be changed; enter accordingly.

4.2.1 Using Default vs. Custom Port Numbers

The Provisioning tools include default port numbers for all components in their Wizards. While it is possible to change these ports to any other value, keeping the defaults guarantees consistency across different installations/environments and may be helpful when following product documentation, since it uses these default ports in its reference architectures and configuration examples.

When changing port numbers from their defaults, pay special attention to potential conflicts for components running on the same server with the same port. While the installers will verify and warn about any potential port conflicts, ensuring there are no conflicts before installation will help provide a more predictable and smoother installation experience.

4.2.1.1 Completing the Network-Ports Tab of the Oracle Fusion Applications Installation Workbook

The Network-Ports tab in the Oracle Fusion Applications Installation Workbook lists all ports that can be changed in the Oracle Identity Management and Oracle Fusion Applications provisioning tools and includes default values. Change the defaults only if required by existing conflicts in your enterprise's network setup.

4.3 Storage: Planning Storage Configuration

Storage planning refers to all planning activities related to:

  • Determining how much storage will be needed for Oracle Fusion Applications during installation, runtime, and for upgrade

  • Defining the file system directories where the software will be installed

  • Defining the type of storage to be used (local, shared), depending on the requirements of both Oracle Fusion Applications and your enterprise.

This section focuses on software installation and initial use only. It does not address long-term capacity planning for the Oracle Fusion Applications environment or space management (e.g. periodic purging of logs).

4.3.1 Recommended Minimum Disk Space

It is recommended that you maintain the minimum amount of free disk space specified in Table 4-2 to accommodate the initial installation, and a reasonable number of incremental backups, daily or weekly thereafter, and subsequent upgrade activities for future releases. If your environment does not meet the minimum requirements, a warning message will be recorded in the provisioning log. You can continue with the installation but may encounter insufficient disk space issues.

In Table 4-2, the Installation/Upgrade Storage column represents the free disk space required for completing installation and upgrade. The Base Storage column is free disk space required to maintain a working application environment which takes into account of storage growth due to transition data, and retention of diagnostic logs for administration and troubleshooting.

Table 4-2 Recommended Minimum Disk Space

Host Base Storage (GB) Installation/Upgrade Storage (GB)

Oracle Fusion Applications Web Tier Host

50

50

Oracle Fusion Applications Provisioning Host

500

300

Oracle Fusion Applications Database Host

600

200

Oracle Identity Management Web Tier Host

50

50

Oracle Identity Management Provisioning Host

200

100

Oracle Identity Management Database Host

200

100


4.3.2 Directory Storage Requirements

Table 4-3 outlines space recommendations for various components and directories, several of which are detailed below. It does not include the storage required for storing the Oracle Fusion Applications media packs and the provisioning repository.

Table 4-3 Planning Storage Size

Directory Created Description Storage Size Usage Estimate

DB HOME/oradata

Both the Oracle Fusion Applications transaction database and the Oracle Identity Management database(s) may be on one machine or separate machines. On the same machine, they can share a DB Home; otherwise there will be a DB Home on each database machine. DB Home includes database directory files and configuration files. /oradata contains the table spaces and logs.

The Oracle Fusion Applications transaction database DB Home requirement: 50 GB.

The Oracle Identity Management DB Home requirement: 50 GB.

/oradata for FA: 200 GB

/oradata for IDM: 75 GB

IDM_BASE (shared), IDM_CONFIG (shared), IDM_LOCAL_CONFIG (local)

IDM_BASE contains the Oracle Identity Management product directory. It remains relatively unchanged. It must use shared storage and may use local storage additionally.

20 GB

IDMLCM_HOME (shared)

IDMLCM_HOME contains the Oracle Identity Management Configuration directory which stores the configuration files and is modified as a result of the provisioning process. It must use shared storage.

25 GB

FAPROV_HOME (shared)

A directory created just for the Oracle Fusion Applications installing the provisioning framework. Once Oracle Fusion Applications is installed, it can be deleted if there is no further usage after provisioning.

10 GB

APPLICATIONS_BASE (shared), APPLICATIONS_CONFIG (shared), APPLICATIONS_LOCAL_CONFIG (local)

APPLICATIONS_BASE is the top-level directory containing the Oracle Oracle Fusion Applications executable. APPLICATIONS_CONFIG contains the instance details for Oracle Fusion Applications. It must use shared storage and may use local storage (APPLICATIONS_LOCAL_CONFIG) additionally.

120 GB shared

/mnt/hwrrepo (shared)

A required directory for Oracle Fusion Human Capital Management (Oracle Fusion HCM) which is checked by the Provisioning Wizard in the pre-verify stage of Oracle Fusion Applications provisioning. It has a large storage requirement if you plan to use the Workforce Reputation Management feature. You can ignore the warning if you do not use Workforce Reputation Management feature.

1 TB

/tmp (local)

For each provisioning host, ensure that there is at least 4 GB free space available for /tmp before installing Oracle Fusion Applications on the provisioning hosts. If the disk space for /tmp is low, you will encounter performance issues. In this case, you should make disk space available or restart the hosts to clean up /tmp.

4 GB/host


4.3.2.1 Shared Storage

Shared storage space must be made available for use by all nodes running Oracle Fusion Applications and Oracle Identity Management. The shared storage space will normally hold:

  • The provisioning repository (see Section 4.3.2.1.1)

  • All of the Oracle Identity Management and Oracle Fusion Applications software (including their provisioning frameworks). An exception: some of the software will be stored elsewhere if you choose "local Config" during provisioning (see Section 4.3.2.2) or select the DMZ option (see Section 4.3.2.3).

  • Temporary backup files (see Section 4.3.2.1.2)

  • The hwrrepo directory (HCM only; see Section 4.3.2.1.3.)

For more information about the directory structure of the shared storage please refer to Section 2.3

4.3.2.1.1 Installation Files and Provision Repository

The Oracle Fusion Applications software from Oracle eDelivery is downloaded in the form of several .zip files. You extract these into a directory called the provisioning repository (REPOSITORY_LOCATION), which contains the "installers" directory containing all installers required by Oracle Fusion Applications. This repository must reside on shared storage. Space is needed for both the zip files and the extracted repository; you can delete or move the zip files after the repository is created.

For more information, see Section 2.3.1, "Installation Repository".

4.3.2.1.2 Temporary Backup Files

The installation procedures described in this guide prompt you to take temporary backup files at several milestones of the installation process. Plan to make enough space available to store those backups files for the duration of the installation process.

4.3.2.1.3 The hwrrepo Directory

If you are provisioning the Oracle Fusion Human Capital Management (Oracle Fusion HCM) application offerings, namely Workforce Development and Workforce Deployment, and planning to use Workforce Reputation Management feature, you must create a directory named /mnt/hwrrepo (Windows: C:\mnt\hwrrepo) on a shared disk for the provisioning hosts. If this directory is not set up, you will see a warning message in the provisioning log during the pre-verify phase when you select the offerings for provisioning. You can proceed with provisioning the environment and mount the shared disk after provisioning is complete and before you start using the Workforce Reputation application.

4.3.2.2 Local Storage (if used)

If desired, certain runtime and configuration directories can be stored in local storage instead of shared storage, for both Oracle Identity Management and Oracle Fusion Applications components. See Section 4.3.6, "Local Storage Considerations" for more information on making this decision.

For more information about the directory structure of the local storage, see Section 2.3.

4.3.2.3 DMZ Local Storage (if used)

If desired, the Middleware Home for OHS and Webgate, as well as other configuration files, can be stored separately from the shared storage, for use in a DMZ. See Section 3.4.3, "Topology: Understanding DMZ Requirements" for information on how to choose whether to use the DMZ option in Oracle Identity Management and Oracle Fusion Applications provisioning wizards. If used, plan space for the DMZ servers.

For more information about the directory structure of the local storage, see Section 2.3.

4.3.2.4 Database Storage

Initial database storage requirements are provided in Table 4-3, but consider short and long-term storage requirements during the planning phase. Storage is needed for both the Oracle database binaries and the data files and other configuration files.

If using Real Application Clusters (RAC) for high-availability, the database storage must be shared among all nodes for each database. Automatic Storage Management (ASM) is the only supported database storage for RAC.

4.3.2.5 Temporary Files Created During Installation (temp directory)

Oracle Fusion Applications uses the system temporary directory to store certain files used during the install, and that space is required throughout the installation process. Since these files may also be used post-installation for patching or upgrade processes, it is recommended to assign that space to the system temp directory permanently.

4.3.3 oraInventory Planning

The oraInventory is the location where the Oracle Universal Installer stores information about all the Oracle software products installed on all ORACLE_HOMES and it is essential for lifecycle events such as applying patches, upgrades, and de-installing components. The following components require an oraInventory:

  • Oracle Database

  • Oracle Identity Management Provisioning tool

  • Oracle Identity Management components

  • Oracle Fusion Applications Provisioning tool

  • Oracle Fusion Applications components

  • Oracle HTTP Server (separate oraInventory when installed on a DMZ)

For more information about oraInventory (also called OUI Inventory in some references), see the "Oracle Universal Installer (OUI) Inventory" in the Oracle Fusion Applications Patching Guide.

When planning the location of the oraInventory directories, consider the following:

  • The oraInventory must be accessible from all the nodes that run software installed against it. Therefore, when Oracle Fusion Applications is installed on multiple nodes, the oraInventory for Oracle Fusion Applications must be located on shared storage. The same applies to the oraInventory for Oracle Identity Management. The database oraInventory locations are usually maintained separately from Oracle Fusion Applications and Oracle Identity Management oraInventory; shared storage is not applicable.

  • Having a single oraInventory across all Oracle Fusion Applications components brings the advantage of centralized management and eliminates guesswork when applying patches. By default, the central oraInventory includes a known file (oraInst.loc) that provides the location of the central oraInventory to Oracle Fusion Applications lifecycle management utilities such as patching, upgrading, or cloning tools.

For oraInventory planning, please define the inventory location for each of the components below:

  • Oracle Identity Management Provisioning Framework

  • Oracle Fusion Applications Provisioning Framework

  • Oracle Fusion Applications

  • Oracle Identity Management

  • Oracle Fusion Applications database

  • Oracle Identity Management database

  • OID database

  • Oracle Fusion Applications Data Warehouse database

You should also define whether each inventory will be central or local:

  • Central: The /etc/oraInst.loc file defines a server-wide location for a single inventory. When this file is present, Oracle installers/provisioning tools will not prompt for an inventory location and will use the one defined in this file instead. This works well if you plan to use the same Inventory path for all components.

    If the /etc/oraInst.loc file is not present, the first time you run an installer you will be prompted for a central inventory location and group owner. The installer will create the file automatically in the /etc directory, which requires root access. You must manually copy that file to all servers using that software.

  • Local: No /etc/oraInst.loc file should be present. In this case, during install you may have to:

    1. Specify an inventory location and group owner when prompted by an installer, and check the option to make it a local inventory. Be sure to use a path in shared storage so it is visible to all servers running that software. No root access is required in this case. The installer will create the local inventory automatically in the specified location and will add an oraInst.loc file pointing to that inventory in the ORACLE_HOME of the product.

    2. When the local inventory and oraInst.loc file have been created by the installer, use the option –invPrtLoc to specify the oraInst.loc file location when invoking the installers/provisioning tools.

4.3.4 Planning Directory Structure and Naming Conventions

Ensure enough shared storage available and is accessible, and enough local storage is available if using that option. When you run the Provisioning Wizard, in addition to oraInventory, it is necessary to plan for the locations listed in the table below:

Directory Conventions:

  • Directory names should not contain spaces

  • Directory structure will be maintained across sources and targets, so use environment-neutral directory names and make them unique enough to guarantee this naming will be available on a potential subsequent clone target.

  • All the directories must be owned by the installing (operating system) user. By convention, most Oracle software installation are done with the operating system user called "oracle".

4.3.5 Shared Storage Considerations

Oracle Fusion Applications and Oracle Identity Management use shared storage to make the binary files, configuration files, and other files available to all its Mid Tier nodes (and Web Tier nodes, if not using the DMZ option). The shared storage should be mounted at the exact same location for each Mid Tier node (and Web Tier nodes, if not using the DMZ option).

Shared storage must also be used for the:

  • Provisioning repository

  • Oracle Identity Management provisioning framework

  • Oracle Fusion Applications provisioning framework

  • hwrrepo directory

  • Database when using RAC

Shared storage may also be used temporarily during the installation process to hold temporary backup files or other files used during the installation process.

Additional consideration for the shared storage:

  • Shared storage can be a Network Attached Storage (NAS) or Storage Area Network (SAN) device.

  • NAS storage is only supported on NetApp and zFS.

  • It is possible to set up separate volumes of shared storage, one for Oracle Fusion Applications and another for Oracle Identity Management. The Oracle Fusion Applications shared storage does not have to be mounted or visible to the Oracle Identity Management nodes, and vice-versa.

  • If provisioning Oracle Identity Management and Oracle Fusion Applications on a single node, it is possible to use a local disk for shared storage, since it must only be visible to one node.

  • The shared drive such as, Network File System (NFS) or Common Internet File System (CIFS) must support file locking. For NFS Version 3 and NFS Version 4, the advisory locking must be configured for the NFS mount. This applies to all UNIX platforms.

4.3.6 Local Storage Considerations

Both Oracle Identity Management and Oracle Fusion Applications Provisioning offer the option of using local storage to run Managed Servers and local instances. This storage location is a networked (local) disk on the host, visible only to the processes running on that host, which may offer better performance than shared storage.

When deciding whether or not to use local configuration take the following into account:

  • Speed of local storage vs. shared storage

  • Disk space available on the local storage

  • IT processes (e.g. backup, storage mirroring) that will require additional maintenance due to the added drive location and its accessibility from the local server only.

If the Local Config Storage option is used, the following directories will be created:

Installation Location Sub-Directories Includes
Oracle Identity Management IDM_LOCAL /instances

/domains

All instance configuration files (for OID, OVD, OIF, ODSM, OHS)

All managed server files

Oracle Fusion Applications FA_LOCAL /applications

/BIInstances

/domains

BI Instance configuration files

UCM configuration files

All managed server files


4.3.6.1 Local Config Storage Decision Tree

The decision diagram outlines the key choice points when choosing whether to use the Local Storage Config option available in the Oracle Fusion Applications and Oracle Identity Management Provisioning Wizards.

Figure 4-5 Local Storage Decision Tree

Description of Figure 4-5 follows
Description of "Figure 4-5 Local Storage Decision Tree"

4.3.7 Completing the Storage Tab of the Oracle Fusion Applications Installation Workbook

To complete the Shared Storage table:

  • Mount Point: The file system mount point for the Oracle Fusion Applications or Oracle Identity Management shared storage.

  • NFS Share/Windows Share: Network location, including server name and path of the shared storage. In UNIX, for example, <hostname>:/<path>. In Windows, for example, \\<hostname>\<share-name>.

  • NFS Parameters (UNIX only): NFS parameters as defined in /etc/fstab.

To complete the Install Directories Table:

  • Enter the appropriate install directories, as described in Section 4.3.4.

To complete the Inventories Table:

Complete the Inventory path with the desired path for the inventories. See Section 4.3.3, "oraInventory Planning" for details.

To complete the Temporary Storage Table:

  • Installer Directory: When you downloaded the Oracle Fusion Applications package from e-delivery, you receive multiple zip files which, when unzipped create the top-level directory called Installers.

  • Temporary Backup Location: plan space to back up during the provisioning process. When everything is installed and validated, you can delete this.

4.4 Database: Planning Database Configuration

A Oracle Fusion Applications environment will have, at minimum, two databases: one for Oracle Identity Management (IDMDB) and another one for Oracle Fusion Applications transactions (FADB). Since these two databases are subject to different patching and maintenance requirements, it is recommended that they are installed on separate ORACLE_HOMEs.

Optionally, a database for the Data Warehouse will also be used if you install Oracle BI Applications (DWDB).

Oracle Identity Management Provisioning also permits a separate dedicated database for OID (OIDDB). This database can be installed on the same ORACLE_HOME as the IDMDB.

The following table summarizes the database requirements for Oracle Fusion Applications

Database Purpose Mandatory Separate OACLE_HOME Recommended
FADB Oracle Fusion Applications transactional database yes yes
IDMDB Oracle Identity Management database yes yes
OIDDB Oracle Identity Management (OID only) no no
DWDB Data Warehouse for Business Intelligence no yes

4.4.1 RAC vs. Single Instance Planning

For environments using the Basic or Enterprise (non-HA) topologies, a single-instance database will be used.

For environments with High Availability requirements, Oracle Fusion Applications supports the use of Oracle Real Application Clusters (RAC).

Note:

You must use at least two nodes. RAC single-node functionality is not currently supported.

When you create a provisioning response file using the Oracle Fusion Applications Provisioning Wizard, if you provide only one RAC node information for the Oracle Fusion Applications database, then you will get an error during the install phase. The error is generated due to a limitation in the Oracle Data Integrator (ODI) installer and you must provide at least two RAC nodes. For more information, see Section 14.6.2, "Install Phase Failed with INST-07221: Specified connect string is not in a valid format Error".

For more information on Oracle RAC, see the Oracle database library.

Figure 4-6 RAC or Single-instance Database Decision Tree

Description of Figure 4-6 follows
Description of "Figure 4-6 RAC or Single-instance Database Decision Tree"

4.4.2 Planning for Database Requirements

When determining your database configuration, consider the required instances, the required patching, listener configurations, schema and password requirements, and RCU directories.

Note:

Two databases are recommended for Oracle Internet Directory and Oracle Access Manager/Oracle Identity Manager because they are likely to have different configuration requirements. If desired, they can be combined into a single database.

4.4.2.1 Required Instance Parameters

The Oracle Fusion Applications database has specific required instance parameters. Validate Oracle-recommended database instance parameters for the Oracle Fusion Applications and Oracle Identity Management databases against your enterprise corporate guidelines for any potential issues and plan accordingly. For details, see:

Oracle Identity Management: Section 7.2.3, "About Initialization Parameters"

Oracle Fusion Applications: Section 8.2.2.2, "Minimum Configuration Parameters for Oracle Database"

4.4.2.2 Required Database Patches

The Oracle Fusion Applications database has specific patch requirements, which must be applied before starting the provisioning process. To determine your required patches, per corporate guidelines (e.g. CPUs), see:

Oracle Identity Management:
Section 7.2.2.1, "Patch Requirements for Oracle Database 11g (11.1.0.7)", and Section 7.2.2.2, "Patch Requirements for Oracle Database 11g (11.2.0.2.0)"

Oracle Fusion Applications: Section 8.2.2.4, "Mandatory Oracle Database Patches"

Use these references to check for potential conflicts and plan accordingly. If necessary, request merge patches from Oracle Support.

4.4.2.3 Schema and Password Requirements

All Oracle Identity Management and Oracle Fusion Applications schema names for the Oracle Identity Management database/OID database and Oracle Fusion Applications database are fixed and cannot be modified. They will be created by the Oracle Fusion Middleware RCU (Oracle Identity Management) and Oracle Fusion Applications RCU.

Note that the Oracle Fusion Middleware RCU appears to provide an option to choose a prefix for the schemas, but in this release the prefix must always be FA.

Therefore, on the topic of schemas, the only planning required is regarding password selection. Oracle Identity Management and Oracle Fusion Applications Provisioning Wizards give you the option of choosing a different password for each schema, but you can also use the same password for all schemas or groups of schemas as desired.

Note:

The Oracle Metadata Services (MDS) Repository is a particular type of repository that contains metadata for some Oracle Fusion Middleware components. It can also include custom Java EE applications developed by your organization.

Table 4-4 lists all the Oracle Fusion Applications schemas created.

Table 4-4 Oracle Fusion Middleware and Oracle Fusion Applications Schema Owners

Component Schema

Oracle Fusion Applications

FUSION

FUSION_DYNAMIC

FUSION_RUNTIME

FUSION_APM

FUSION_AQ

FUSION_BI

FUSION_DQ

FUSION_ODI_STAGE

FUSION_SETUP

AS Common Schemas

  • Enterprise Scheduler Service

  • Metadata Services

Includes:

  • FUSION_ORA_ESS

  • CRM_FUSION_MDS_SOA

  • FIN_FUSION_MDS_SOA

  • HCM_FUSION_MDS_SOA

  • OIC_FUSION_MDS_SOA

  • PRC_FUSION_MDS_SOA

  • PRJ_FUSION_MDS_SOA

  • SCM_FUSION_MDS_SOA

  • SETUP_FUSION_MDS_SOA

  • FUSION_MDS

  • FUSION_MDS_ESS

  • FUSION_MDS_SPACES

Secure Enterprise Search

SEARCHSYS

Oracle Data Integrator

  • Master and Work Repository

FUSION_ODI

Enterprise Content Management

  • Oracle Content Server 11g - Complete

  • Oracle Imaging and Process Management

Includes:

  • FUSION_OCSERVER11G

  • FUSION_IPM

Oracle Business Intelligence (Platform)

FUSION_BIPLATFORM

Oracle BI Applications Schemas

  • Oracle Transactional BI

Includes:

  • FUSION_OTBI

WebLogic Server Communication Services

  • SIP Infrastructure Location Service

  • Presence

  • SIP Infrastructure Subscriber Data Service

Includes:

  • FUSION_ORASDPLS

  • FUSION_ORASDPXDMS

  • FUSION_ORASDPSDS

SOA and BPM Infrastructure

  • User Messaging Service

  • SOA Infrastructure

  • SOA Infrastructure

  • SOA Infrastructure

  • SOA Infrastructure

  • SOA Infrastructure

  • SOA Infrastructure

  • SOA Infrastructure

  • SOA Infrastructure

Includes:

  • FUSION_ORASDPM

  • CRM_FUSION_SOAINFRA

  • FIN_FUSION_SOAINFRA

  • HCM_FUSION_SOAINFRA

  • OIC_FUSION_SOAINFRA

  • PRC_FUSION_SOAINFRA

  • PRJ_FUSION_SOAINFRA

  • SCM_FUSION_SOAINFRA

  • SETUP_FUSION_SOAINFRA

WebCenter Suite

  • WebCenter Spaces

  • Portlet Producers

  • Activity Graph and Analytics

  • Discussions

Includes:

  • FUSION_WEBCENTER

  • FUSION_PORTLET

  • FUSION_ACTIVITIES

  • FUSION_DISCUSSIONS

  • FUSION_DISCUSSIONS_CRAWLER

Audit

Includes:

  • FUSION_IAU

  • FUSION_IAU_APPEND

  • FUSION_IAU_VIEWER

Oracle Social Network

Includes:

  • FUSION_SOCIAL

  • FUSION_SOCIAL_VIEWS

  • FUSION_SOCIAL_CEF

Fusion Data Integration

Includes:

  • FUSION_INTEGRATION_CURRENT

  • FUSION_INTEGRATION_PREVIOUS

  • FUSION_INTEGRATION_FINAL

Oracle Enterprise Data Quality

Includes:

  • FUSION_EDQFUSION

  • FUSION_EDQCONFIG1

  • FUSION_EDQRESULTS1

  • FUSION_EDQCONFIG2

  • FUSION_EDQRESULTS2


Table 4-5 shows all the Oracle Identity Management schemas created:

Table 4-5 Oracle Identity Management Schemas

Component and Database Name Schema Service Name

Oracle Internet Directory

OIDDB

Includes:

  • ODSSM

  • ODS

  • DIP (Directory Integration Platform)

OIDEDG.mycompany.com

Oracle Identity and Access Management

IDMDB

Includes:

  • FA_OIM

  • FA_OAM

  • FA_OIF

  • SOA_INFRA

  • FA_MDS

  • FA_ORASDPM

  • FA_OAM

  • FA_IAU

IAMEDG.mycompany.com


4.4.2.4 Oracle Fusion Applications RCU Directories

The Oracle Fusion Applications transactional database requires the creation of several DBA directories, listed in the following table. Directory creation is performed when you run the Oracle Fusion Applications RCU.

To plan for these DBA directories, decide where you will create the corresponding file system directories on the database server and add those locations to the Oracle Fusion Applications Installation Workbook. You will be asked to enter the locations when you run the Oracle Fusion Applications RCU.

DBA Directory Name Purpose Requirements
APPLCP_FILE_DIR Used by Oracle Enterprise Scheduler to store the log and output files. Must be valid on the database server with read-write permissions to the database owner. For Oracle RAC, must point to a location that is shared across all nodes.
APPLLOG_DIR Location of the PL/SQL log files from Oracle Fusion Applications PL/SQL procedures on the database server. Ensure that the database owner has read-write privileges.
FUSIONAPPS_PROV_RECOVERY_DIR
(RCU OBIEE Backup Directory)
Location of the Oracle Business Intelligence Enterprise Edition dump files. These files are used for enabling a restart action. Ensure that the database owner has read-write privileges. For Oracle RAC, must point to a location that is shared across all nodes.
FUSIONAPPS_DBINSTALL_DP_DIR Directory where you will copy the Oracle Fusion Applications database dump files Ensure that the database owner has read-write privileges. For Oracle RAC, must point to a location that is shared across all nodes.
OTBI_DBINSTALL_DUMP_DIR
(RCU OTBI Dump File Directory)
Directory on the database server where Oracle Transactional Business Intelligence dump file is stored. Ensure that the database owner has read-write privileges. For Oracle RAC, must point to a location that is shared across all nodes.

4.4.2.5 Oracle Identity Management Split Database Configuration

The Oracle Identity Management Provisioning tool allows you to use a dedicated database for OID (OIDDB), which will hold the ODS and ODSSM schemas used by it. With this configuration, only the ODS and ODSSM schemas will be placed on a different database, all other IDM schemas will still be located in the IDMDB.

This configuration can be used if you plan on using the Advanced replication features of the Oracle Database to perform multi-master replication across multiple OID instances. Otherwise, a separate database for OID is not required.

4.4.3 Completing the Database Tab of the Oracle Fusion Applications Installation Workbook

To complete the Fusion Applications Transactional Database table:

  • FA DB Service Name: This is the global database name, such as fadb.mycompany.com.

  • FA DB Service Instance: If you are using RAC, separate the instances with commas in the Oracle Fusion Applications Installation Workbook table cell.

  • RCU Directories: When you start the Repository Creation Utility to populate schemas for Oracle Fusion Applications, it will ask for these directories. Note that they are local to the database server. See Section 8.6, "Running the Oracle Fusion Applications RCU to Create Oracle Fusion Applications Database Objects" for the full context.

To complete the IDM Database table:

  • IDM DB Service Name: This is the global database name, such as fadb.mycompany.com.

  • IDM DB Service Instance: If you are using RAC, separate the instances with commas in the Oracle Fusion Applications Installation Workbook table cell.

  • IDM DB Prefix: This is for running the Oracle Fusion Middleware RCU utility. You must enter FA in the Oracle Identity Management Provisioning Wizard when prompted.

If you are planning to use the OID database or the Oracle Fusion Applications Data Warehouse, enter the same parameters in their respective tables.

4.5 Identity Management: Planning Oracle Identity Management Configuration

The following topics provide concepts needed to plan an Oracle Identity Management installation and to fill out the Identity Management tab in the Oracle Fusion Applications Installation Workbook.

4.5.1 Identity Store Planning

Planning your Oracle Identity Management installation requires understanding how Oracle Identity Management handles the OID and OVD Identity Stores.

Understanding OID and OVD

Oracle Fusion Applications supports two types of Identity Store: OID and OVD. With the OID option, identity information is physically stored in OID. OVD on the other hand is a virtual directory and does not store any user/group information. Therefore, when OVD is used as the Identity Store, it is possible to configure it to point to any other user/group store without the need to reconfigure the components in Oracle Fusion Applications or Oracle Identity Management.

Using OVD as the Identity Store has the advantage of flexibility; identity data can still be stored in OID, but OVD provides the ability to switch to a different identity provider later with little impact. (Section 16.9.4, "Setting up LDAP Split Profile and Enabling Active Directory Users in Oracle Fusion Applications", provides instructions on how to configure other sources, such as MS Active Directory, post-provisioning.) Given this flexibility, OVD will usually be the primary choice for the Identity Store for Oracle Fusion Applications.

How Topology Affects the OID/OVD Decision

While OVD is installed and configured with an adapter to OID for all three Oracle Identity Management topology types, it is only auto-configured as the Identity Store in the EDG topology types. (Note that the EDG topology type will require a load balancer or reverse proxy.)

For the Single-Host topology, OID is configured as the Identity Store instead, and that option cannot be user-defined. If you plan to use OVD as the ID Store, you must select the EDG (that is, Enterprise) topology for Oracle Identity Management Provisioning.

Additional Considerations when Planning the Identity Store

  • Integration with other products for single-sign -on (SSO) may have specific requirements, e.g. Ebusiness Suite integration.

  • OID offers additional options if you decide to use OID (without OVD) as the ID Store. One of them is DIP (Directory Integration Platform), which performs synchronization between OID and other directories.

Figure 4-7 Identity Store Decision Tree: OID or OVD?

OVD OID decision flowchart

4.5.2 LDAP Context Planning

LDAP directories are used by Oracle Fusion Applications for storing identities - users and groups (acting as the Identity Store), as well as authorization policies and credentials (acting as the Policy Store/Credential Store).

Oracle Identity Management Provisioning provides the option to choose the context root for the Identity Store, i.e. the starting point in the directory tree for storing user and group information. Normally, the ID Store context root will be based on your domain name, e.g. for a company with domain name "mycompany.com", the ID Store context root chosen will normally be "dc=mycompany,dc=com". Provisioning will then create sub-contexts for Users (cn=Users), groups (cn=Groups) among others.

For the Policy Store, Oracle Identity Management Provisioning will automatically create contexts for the two policy stores (IDM and FA), under cn=jpsroot and cn=FAPolicies, respectively. Oracle Identity Management Provisioning does not allow you to change them. During Oracle Fusion Applications Provisioning, you will be asked to provide a context root for the FA Policy Store, and although you are free to choose a different one (Oracle Fusion Applications Provisioning can create it for you if necessary), we recommend using the one previously created by Oracle Identity Management Provisioning.

The table below provides a summary of the LDAP context roots used by Oracle Fusion Applications:


Default Directory Type Can be User-Defined?
Identity Store
(Oracle Fusion Applications/Oracle Identity Management) Realm DN
dc=mycompany,dc=com (example) OID or OVD Yes
IDM Policy Store cn=jpsroot OID No.
Fusion Applications Policy Store cn=FAPolicies OID Yes

4.5.3 Location for Files Generated During Oracle Identity Management Provisioning

Oracle Identity Management Provisioning automatically generates files to be used during Oracle Fusion Applications Provisioning, providing a more streamlined integration between the two.

Once the Oracle Identity Management Provisioning process finishes, you will find the generated files under IDM_INSTALL_APPCONFIG_DIR/fa. These files must be copied to a directory accessible from all Oracle Fusion Applications nodes before Oracle Fusion Applications Provisioning, so planning for this involves simply defining the location where these files will be and adding the information to the Oracle Fusion Applications Installation Workbook.

4.5.4 Oracle Access Manager Transfer Mode

Oracle Access Manager (OAM) Transfer Mode refers to the transport security modes for communication between the Oracle Access Manager Server (OAM Server) and the Web gates. While OAM in general supports three different mode options (Open, Simple and Cert), the only available mode for Oracle Fusion Applications Provisioning is "Simple" for all platforms, with the exception of AIX (where only Open mode is supported).

The table below provides a summary of OAM Transfer Modes and availability in Oracle Fusion Applications Provisioning. A single mode must be selected for the entire installation (including Oracle Identity Management) in accordance to the table. In simpler terms: all platforms require Simple mode except for AIX, where Open mode must be selected.

Table 4-6 OAM Transfer Modes available in Oracle Fusion Applications

OAM Mode Description Available in Fusion Applications Provisioning

Open

Uses un-encrypted communication

Yes (AIX only)

Simple

Uses encrypted communication through SSL with a public key certificate issued by Oracle

Yes (all platforms except AIX)

Cert

Uses encrypted communication through SSL with a public key certificate issued by a trusted third-party certificate authority.

No


4.5.5 Considering Oracle Internet Directory Password Policies

By default, Oracle Internet Directory passwords expire in 120 days. Users who do not reset their passwords before expiration can no longer authenticate to Oracle Internet Directory. Note that this includes administrative users, such as oamadmin, and the Oracle Identity Management environment cannot work properly unless these users can authenticate. See the Oracle Fusion Middleware Administrator's Guide for Oracle Internet Directory for information about changing Oracle Internet Directory password policies.

4.5.6 Completing the Identity Management Tab of the Oracle Fusion Applications Installation Workbook

The Oracle Fusion Applications Installation Workbook provides sample values to make many of these entries self-explanatory.

4.5.6.1 To complete the LDAP table:

Review Section 4.5.2, "LDAP Context Planning" to obtain the information required for the DN entries in this table.

  • Identity Store Realm DN: Format described in the table in Section 4.5.2,

  • LDAP User DN: The User DN is a subtree of the Identity Store Realm DN (above). Naming format is fixed: cn=Users

  • LDAP Group DN: The Group DN is a subtree of the Identity Store Realm DN (above). Naming format is fixed: cn=Groups

  • Policy Store JPS root DN: Un-editable.

  • FA JPS root DN: Refer to the table in Section 4.5.2 to derive.

4.5.6.2 To Complete the IDM Provisioning Files Table

  • IDM Properties file location: When Oracle Identity Management Provisioning is complete, a file will be created in the IDM Shared Configuration Location/fa directory (as defined on the Storage tab, Install Directories table). This file must be made available to the Oracle Fusion Applications Provisioning process. If the original location is accessible to the Oracle Fusion Applications Provisioning tool, enter that location in the Oracle Fusion Applications Installation Workbook. Otherwise, copy the file to an accessible location and note the new location here.

  • IDM Keystore file location: Not used in this release.

4.5.6.3 To Complete the OAM Table:

Only one field in this table can be edited, and it is generally not necessary to do even that one.

  • OAM Administrator User name: It is recommended to keep the default (OAMAdminUser) unless explicitly instructed to change this.

4.5.6.4 To Complete the Identity Store/Policy Store Table:

Most of the fields in this table cannot be edited. The exceptions are below:

  • ID Store Type (OID/OVD): Enter the Identity Store you are using, based on the topology you chose (see Section 4.5.1 for details.).

  • FA Node Manager Username: Use the default or edit if desired.

4.6 SSL and Certificates

This section describes requirements that apply to the SSL and Certificates tab in the Oracle Fusion Applications Installation Workbook.

4.6.1 Out-of-the-Box SSL Configuration

Out of the box, the Oracle Identity Management and Oracle Fusion Applications Provisioning frameworks will configure their respective components to use SSL connections between the end users and the load balancer/reverse proxy (or Web Tier if an LBR/RP is not used). This is mandatory and cannot be changed.

Oracle Identity Management Provisioning provides the option to select SSL or non-SSL for the IDM Admin HTTP endpoint, as noted in the Oracle Fusion Applications Installation Workbook. Select yes if you want that endpoint to be configured for SSL automatically during Oracle Identity Management Provisioning.

If a load balancer is used, the connection between the LBR and the Web Tier will be configured as non-SSL, out of the box. Therefore, the HTTP listener on the Oracle HTTP Server will be non-SSL.

If a load balancer is not used, Oracle Identity Management behaves differently from Oracle Fusion Applications:

  • Oracle Fusion Applications: The end-user (external) connections will still be SSL, but they will terminate at the Web Tier instead. (FA OHS will be configured to listen to SSL traffic.)

  • Oracle Identity Management: All external endpoints will be non-SSL. (IDM OHS will be configured to listen to regular HTTP traffic.)

4.6.2 SSL Certificate Requirements

SSL Certificate requirements depend on whether your topology uses a load balancer/reverse proxy or not.

If using an LBR/RP:
Because both Oracle Identity Management and Oracle Fusion Applications terminate SSL connections at the load balancer, it is necessary to set up the appropriate SSL certificates on the load balancer BEFORE starting the provisioning process. The certificates should be created and provisioned to the LBR/RP according to your own policies and procedures, along with the instructions provided by your LBR/RP manufacturer.

If not using an LBR/RP:
SSL will terminate at OHS, which will be configured with a default dummy certificate. As the dummy certificate is not trusted by browsers, end users will get certificate warning messages when they access any external URL.

To avoid this, you must configure OHS to use certificate(s) signed by a trusted certificate authority (CA). This can be an external certificate authority such as Verisign, or an internal certificate authority whose root certificate is trusted by the browser. See Section 16.6, "Configuring Oracle HTTP Server with Custom Certificates" for more information.

4.7 Memory Requirements

Table 4-7 lists the default memory settings for WebLogic administration and managed servers in the Oracle Fusion Applications environment. Follow Table 4-7 to plan for the memory requirements of the provisioning hosts. You should plan for additional memory for operating system and reserve enough spare memory to give room for future growth and scale out.

Table 4-7 Memory Requirements for WebLogic Administration and Managed Servers

Memory Specifics Requirements

Memory per Managed Servers

2GB multiplied by the number of managed servers in your environment, plus 4GB.

Memory Per Administration Servers

1GB multiplied by the number of administration servers in your environment, if the WebLogic domain is not a product family of the product offerings that you selected (see Table 2-2).

2GB multiplied by the number of administration servers in your environment, if the WebLogic domain is a product family of the product offerings that you selected (see Table 2-2).

Business Intelligence Cluster (bi_cluster / BIDomain)

6GB multiplied by the number of managed servers in your environment.

Oracle Enterprise Data Quality Cluster (EDQCluster / CommonDomain)

8GB for one instance of EDQ WebLogic managed server created out-of-the-box if you select any of the product offerings listed below:

  • CRM: Sales, Marketing, Customer Data Management, Enterprise Contracts.

  • Financials: Financials, Procurement

  • SCM: Product Management, Material Management, and Logistics

Workforce Reputation Cluster (WorkforceReputationCluster / HCMDomain)

8GB multiplied by the number of managed servers in your environment if you select any of the product offerings listed below:

  • Workforce Deployment

  • Workforce Development

For more information, see Section 22.1, "Recommended Memory Requirement for Oracle Fusion Human Capital Management Workforce Reputation Management Product".


4.8 What to Do Next

When the Oracle Fusion Applications Installation Workbook is entirely filled out, you are ready to proceed with Chapter 5, "Preparing for an Installation".