4 Plan the Configuration of the Components of the Installation

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

4.1 Network- Virtual Hosts: Plan 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.

Internal vs External URLs: See Understand Internal vs. External URLs, for information about to how Oracle Identity Management and Oracle Fusion Applications provisioning use these concepts.
Naming: All parts of the network-related decisions involve choosing appropriate names for various endpoints. These are used throughout the installation, both for internal communication between Oracle Fusion Applications components and externally, to be viewed by users. Naming Conventions in Oracle Fusion Applications, gives important orientation on how to name endpoints throughout the installation.
Load Balancer: Next, decide whether the availability and topology requirements demand the use of Load Balancers (LBR) or a Reverse proxy. For an introduction to the use of Load Balancers and Reverse proxy in Oracle Fusion Applications topologies, see Network Components.

These decisions are further described in Plan Load Balancer Requirements
Web Tier/HTTP Servers: Make also decisions about the Web Tier. Oracle HTTP Servers (OHS) for Oracle Identity Management and Oracle Fusion Applications are installed on the Web Tier. Again, decide where on the network they reside and whether they are in the DMZ.

This is described in Plan HTTP Server Requirements.

The Virtual Host Mode is a property of the Web Tier that can be name-based, port-based, or IP-based. These options are described in Define Web Tier Virtual Host Mode .
Virtual IPs (VIPs) for Administration and Managed Servers: VIPs apply to all Enterprise topologies for Oracle Identity Management. For Oracle Fusion Applications, VIPs apply only to Enterprise-HA topologies. VIP overview information is described in Define VIPs for Administration and Managed Servers.
When each of these subjects has been reviewed and decisions about them have been made, see Complete the Network-Virtual Hosts Tab of the Oracle Fusion Applications Installation Workbook.

4.1.1 Understand 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 Plan URL Naming Conventions

Naming conventions for network configuration are extremely important, since they define the URLs that are 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 are used by end-users.

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

These names are 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, to clone an installation). Choose environment-neutral names to avoid headaches later.

4.1.3 Plan 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. See 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 is not available with the "Single-host" install. The other alternative, "EDG" topology, prompts for three IDM HTTP endpoints and three LDAP endpoints.

Description of GUID-5EA8543C-FA17-498A-BDCC-546C629FCC74-default.png follows

Description of the illustration GUID-5EA8543C-FA17-498A-BDCC-546C629FCC74-default.png

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

Configure LBR Endpoints: Select this option to configure the Admin, Internal Callbacks, and SSO LBR endpoints for a single-node topology.

In a three-node topology, the Configure LBR Endpoints option is selected by default. In a six-node enterprise deployment topology, the option is selected by default and cannot be deselected.

HTTP/HTTPS Requirements

Table 4-1 Load Balancer SSL Requirements for HTTP

Endpoint Type	SSL?	Description
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	Main application entry point

LDAP Requirements

Table 4-2 Load Balancer SSL Requirements for LDAP Endpoints

Endpoint Type	Description
OID Endpoint	LDAP LBR endpoints are only used for the URLs configured internally for the LDAP endpoints.

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 starting 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 Plan Load Balancer Requirements.

Description of GUID-4D8335F5-F8C2-4082-93EC-B10E115B5639-default.png follows

Description of the illustration GUID-4D8335F5-F8C2-4082-93EC-B10E115B5639-default.png

If selected, this setting 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.

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

4.1.3.3 Network Placement of Load Balancers/Reverse Proxy

ITo 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 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) are 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 Load Balancer Placed Outside the internal Network"

Figure 4-2 Internal/External LBR Configuration

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 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 the 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 the external load balancer has the ability to automatically detect failures, it should be used.
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 the 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 the 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 to 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 to 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 Plan HTTP Server Requirements

Both Oracle Identity Management and Oracle Fusion Applications Provisioning 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 are not configured with an SSL listener and therefore the connection between the LBR and OHS is always 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 is set up with SSL on the external virtual hosts, which requires installing SSL certificates.

4.1.4.1 Define Web Tier Virtual Host Mode

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

Oracle Fusion Applications Provisioning allows to choose a preferred method:

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 are 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 Choosing Virtual Host Mode"

4.1.5 Define 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.

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 Complete 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 Define Web Tier Virtual Host Mode

4.1.6.2 Complete the FA Web Tier Virtual Hosts Table

Completing this table depends on the Virtual Host Mode chosen (Define Web Tier Virtual Host Mode). Each row of the table is described in FA Web Tier Virtual Hosts Table Rows Defined; the mode-based usage is as follows:

Port-Based

Internal and External Hostnames: They are not 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. It is recommended to keep the defaults (see Use Default vs. Custom Port Numbers).

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 Plan URL Naming Conventions. Note: this virtual host mode is not recommend for use with a load balancer, as indicated in Define Web Tier Virtual Host Mode .
Ports: In name-based mode, do 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: In the Oracle Fusion Applications Installation Workbook open the Network - Ports tab, then Fusion Applications Port Numbers, then FA Oracle HTTP Server.
- External Port: In the Oracle Fusion Applications Installation Workbook open the Network-Ports tab, then Fusion Applications Port Numbers , then FA Oracle HTTP Server SSL.

IP-Based

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

Internal and External Hostnames: Select the external and internal hostnames to be used for the Oracle Fusion Applications Web Tier. See Plan URL Naming Conventions.
Ports: It is recommended to keep the default port numbers, as mentioned in Use Default vs. Custom Port Numbers.

In all three modes, the IP Address column should contain the IP address of the host that runs the Oracle Fusion Applications Web Tier. They are normally 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 to 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 a name that differs from the default structure is assigned, it needs to be added to the /etc/hosts file.
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 the 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 a name that differs from the default structure is assigned, it needs to be added to the /etc/hosts file.
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 the 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 are default to the hostname defined in the Topology tab, then Topology table for the component IDM Web Tier, and are grayed out on the Provisioning Wizard.

4.1.6.4 Complete the HTTP LBR Endpoints Table

Select the external and internal hostnames 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 Plan URL Naming Conventions.

It is recommended to keep the default port numbers, as mentioned in Use Default vs. Custom Port Numbers.

4.1.6.5 Complete the LDAP Endpoints Table

Enter the abstract hostname (or real hostname if not using an abstract one) for the node where the IDM Directory component in the Topology tab was assigned. The ports are predefined and should only be changed if required by the enterprise. When running the Oracle Identity Management Provisioning Wizard, these values are automatically pre-populated and greyed out; they cannot be changed.

4.1.6.6 Complete the UCM LBR Endpoint Table

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

Hostname: The load balancer entry here is 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.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). Define only entries for the licensed products.

See 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). Define only entries for the licensed products. For each managed server in the table, define a virtual host name and IP for each scale-out node.

4.2 Network-Ports: Plan 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 the enterprise determines whether these can be used or should be changed; enter accordingly.

4.2.1 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 or 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 verify and warn about any potential port conflicts, ensuring there are no conflicts before installation helps providing a more predictable and smoother installation experience.

4.2.1.1 Complete 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 the enterprise's network setup.

4.3 Storage: Plan Storage Configuration

Storage planning refers to all planning activities related to:

Determining how much storage is needed for Oracle Fusion Applications during installation, runtime, and for upgrade
Defining the file system directories where the software is installed
Defining the type of storage to be used (local, shared), depending on the requirements of both Oracle Fusion Applications and the 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 to maintain the minimum amount of free disk space specified in Table 4-3 to accommodate the initial installation, and a reasonable number of incremental backups, daily or weekly thereafter, and subsequent upgrade activities for future releases. If the environment does not meet the minimum requirements, a warning message is recorded in the provisioning log. Continue with the installation but may encounter insufficient disk space issues.

In Table 4-3, 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-3 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-4 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-4 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 is 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/hwrepo (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 the Workforce Reputation Management feature is planned to be used. Ignore the warning if Workforce Reputation Management feature is not used.	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, performance issues are encountered. In this case, 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 normally holds:

The provisioning repository (see Installation Files and Provision Repository).
All of the Oracle Identity Management and Oracle Fusion Applications software (including their provisioning frameworks). An exception: some of the software are stored elsewhere if Local Config is chosen during provisioning (see Local Storage (if used)) or select the DMZ option (see DMZ Local Storage, if used).
Temporary backup files (see Temporary Backup Files).
The hwrepo directory (HCM only; see The hwrepo Directory).

For more information about the directory structure of the shared storage please refer to Oracle Fusion Applications Directory Structure.

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. 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; delete or move the zip files after the repository is created.

See Installation Repository.

4.3.2.1.2 Temporary Backup Files

The installation procedures described in this guide prompt 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 hwrepo Directory

If the Oracle Fusion Human Capital Management (Oracle Fusion HCM) application offerings are being provisioned, namely Workforce Development and Workforce Deployment, and Workforce Reputation Management feature is planned to be used, create a directory named /mnt/hwrepo on a shared disk for the provisioning hosts. If this directory is not set up, a warning message is displayed in the provisioning log during the pre-verify phase when the offerings for provisioning are selected. Proceed with provisioning the environment and mount the shared disk after provisioning is complete and before starting 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 Local Storage Considerations.

For more information about the directory structure of the local storage, see Oracle Fusion Applications Directory Structure.

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 Topology: Understand 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 Oracle Fusion Applications Directory Structure.

4.3.2.4 Database Storage

Initial database storage requirements are provided in Table 4-4, 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 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

Define also whether each inventory is 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 do not prompt for an inventory location and use the one defined in this file instead. This works well if the same Inventory path is used for all components. If the /etc/oraInst.loc file is not present, the first time an installer is run a central inventory location and group owner are requested. The installer creates the file automatically in the /etc directory, which requires root access. Copy manually that file to all servers using that software.
Local: No /etc/oraInst.loc file should be present. In this case, during install it might necessary 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 creates the local inventory automatically in the specified location and adds 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 Plan Directory Structure and Naming Conventions

Ensure enough shared storage available and is accessible, and enough local storage is available if using that option. When running 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 is maintained across sources and targets, so use environment-neutral directory names and make them unique enough to guarantee this naming is 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
hwrepo 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 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 are created:

Installation	Location	Sub-Directories	Includes
Oracle Identity Management	IDM_LOCAL	/instances /domains	All instance configuration files (for OID, 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

Installation

Location

Sub-Directories

Includes

Oracle Identity Management

IDM_LOCAL

/instances

/domains

All instance configuration files (for OID, 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 Local Storage Decision Tree"

4.3.7 Complete 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.
OS User Owner: The operating system user of the installation owner (e.g. oracle).
OS Group Owner: The operating system group of the installation owner (e.g. orainstall).
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 Plan Directory Structure and Naming Conventions.

To complete the Inventories Table:

Complete the Inventory path with the desired path for the inventories. See oraInventory Planning.

To complete the Temporary Storage Table:

Provisioning Repository: location for the provisioning repository.
Installer Directory: when the Oracle Fusion Applications package is downloaded from e-delivery, a multiple zip file is received. When this file is unzipped, it creates the top-level directory called Installers.
JAVA_HOME: location of the JAVA_HOME.
Temporary Backup Location: plan space to back up during the provisioning process. When everything is installed and validated, delete this.

4.4 Database: Plan Database Configuration

An Oracle Fusion Applications environment has, 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 is used to 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 ORACLE_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 is used.

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

MANDATORY: Use at least two nodes. RAC single-node functionality is not currently supported.

When a provisioning response file is created using the Oracle Fusion Applications Provisioning Wizard, if only one RAC node information is provided for the Oracle Fusion Applications database, then an error is displayed during the install phase. The error is generated due to a limitation in the Oracle Data Integrator (ODI) installer and at least two RAC nodes must be provided. See 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 RAC or Single-instance Database Decision Tree"

4.4.2 Plan for Database Requirements

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

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 the enterprise corporate guidelines for any potential issues and plan accordingly. For details, see:

Oracle Identity Management: About Initialization Parameters

Oracle Fusion Applications: 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: Patch Requirements for Oracle Database 12c, and Patch Requirements for Oracle Database 12c

Oracle Fusion Applications: 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 or OID database and Oracle Fusion Applications database are fixed and cannot be modified. They are created by the Oracle Fusion Middleware RCU (Oracle Identity Management) and Oracle Fusion Applications RCU.

MANDATORY: 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 the option of choosing a different password for each schema, but the same password can be also used for all schemas or groups of schemas as desired.

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 the organization.

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

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

Component	Schema
Oracle Fusion Applications	Includes: 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 HED_FUSION_MDS_SOA FUSION_MDS FUSION_MDS_ESS FUSION_MDS_SPACES
Secure Enterprise Search	SEARCHSYS
Oracle Data Integrator Primary 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 Oracle BI Cloud Adapter	Includes: FUSION_OTBI FUSION_BIA_CLOUD
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 HED_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_RDF FUSION_SOCIAL FUSION_SOCIAL_CEF FUSION_SOCIAL_VIEWS
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
Fusion Applications Read Only Diagnostic	FUSION_RO FUSION_ERO
Fusion Risk and Controls	FUSION_GRC
Oracle Database Vault	Includes: LCM_EXP_ADMIN LCM_OBJECT_ADMIN LCM_SUPER_ADMIN LCM_USER_ADMIN DVOWNER DVACCTMGR
Fusion Middleware Data Source Consolidation	FMW_RUNTIME
Oracle Platform Security Services (OPSS)	FUSION_OPSS

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

Table 4-6 Oracle Identity Management Schemas

Component and Database Name	Schema	Service Name
Oracle Internet Directory OIDDB	Includes: ODSSM ODS	OIDEDG.mycompany.com
Oracle Identity and Access Management IDMDB	Includes: FA_OAM FA_MDS FA_IAU FA_OPSS	IAMEDG.mycompany.com

Component and Database Name

Schema

Service Name

Oracle Internet Directory

OIDDB

Includes:

ODSSM
ODS

OIDEDG.mycompany.com

Oracle Identity and Access Management

IDMDB

Includes:

FA_OAM
FA_MDS
FA_IAU
FA_OPSS

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 the Oracle Fusion Applications RCU is run.

To plan for these DBA directories, decide where the corresponding file system directories are created on the database server and add those locations to the Oracle Fusion Applications Installation Workbook. The locations are requested when the Oracle Fusion Applications RCU is run.

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 to 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 to use a dedicated database for OID (OIDDB), which holds the ODS and ODSSM schemas used by it. With this configuration, only the ODS and ODSSM schemas are placed on a different database, all other IDM schemas are still located in the IDMDB.

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

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

To complete the Fusion Applications Transactional Database table:

FA DB Type: Select a database type from the list.
FA DB Datafiles Location: Enter a location for the FA DB datafiles.
FA DB Service Name: Enter the global database name, such as fadb.mycompany.com.
FA DB Service Instance: Enter the FA DB instances. If RAC is used, separate the instances with commas in the Oracle Fusion Applications Installation Workbook table cell.
RCU Directories: Enter the different RCU directories. When the Repository Creation Utility is started to populate schemas for Oracle Fusion Applications, it asks for these directories. Note that they are local to the database server. See Run the Oracle Fusion Applications RCU to Create Oracle Fusion Applications Database Objects.

To complete the IDM Database table:

IDM DB TYPE: Select a database type from the list.
IDM DB Oracle Home: Enter the directory of the IDM DB ORACLE_HOME.
IDM DB Datafiles Location: Enter a location for the IDM DB datafiles.
IDM DB Service Name: Enter the global database name, such as fadb.mycompany.com.
IDM DB Service Instance: Enter the IDM DB instances. If a RAC is used, separate the instances with commas in the Oracle Fusion Applications Installation Workbook table cell.
IDM DB Prefix: Enter FA in the Oracle Identity Management Provisioning Wizard when prompted. This is for running the Oracle Fusion Middleware RCU utility.

To use the OID database or the Oracle Fusion Applications Data Warehouse, enter the same parameters in their respective tables.

4.5 Identity Management: Plan the 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

Oracle Fusion Applications supports one type of Identity Store: OID. With the OID option, identity information is physically stored in OID.

Integration with other products for single-sign -on (SSO) may have specific requirements, e.g. Ebusiness Suite integration. OID offers additional options. One of them is DIP (Directory Integration Platform), which performs synchronization between OID and other directories.

4.5.2 LDAP Context

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 is based on the domain name, e.g. for a company with domain name "mycompany.com", the ID Store context root chosen is normally "dc=mycompany,dc=com". Provisioning then creates sub-contexts for Users (cn=Users), groups (cn=Groups) among others.

For the Policy Store, Oracle Identity Management Provisioning automatically creates contexts for the two policy stores (IDM and FA), under cn=jpsroot and cn=FAPolicies, respectively. Oracle Identity Management Provisioning does not allow to change them. During Oracle Fusion Applications Provisioning, context root for the FA Policy Store is requested, and although it is possible to choose a different one (Oracle Fusion Applications Provisioning can create it if necessary), it is recommended to use 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:

Service	Default	Directory Type	Can be User-Defined?
Identity Store (Oracle Fusion Applications/Oracle Identity Management) Realm DN	`dc=mycompany,dc=com` (example)	OID	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, the generated files can be found 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 are 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.

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.

Table 4-7

OAM Mode	Description	Available in Fusion Applications Provisioning
Open	Uses un-encrypted communication	No
Simple	Uses encrypted communication through SSL with a public key certificate issued by Oracle	Yes
Cert	Uses encrypted communication through SSL with a public key certificate issued by a trusted third-party certificate authority.	No

4.5.5 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. For information about changing Oracle Internet Directory password policies, see Managing Password Policies in the Oracle Fusion Middleware Administrator's Guide for Oracle Internet Directory .

4.5.6 Complete 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 Complete the LDAP Table

Review LDAP Context to obtain the information required for the DN entries in this table.

Identity Store Realm DN: Format described in the table in LDAP Context.
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
FA JPS root DN: Refer to the table in LDAP Context to derive.

4.5.6.2 Complete the IDM Provisioning Files Table

IDM Properties file location: When Oracle Identity Management Provisioning is complete, a file is 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 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 Complete the Identity Store/Policy Store Table:

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

FA Node Manager Username: Use the default or edit if desired.
LDAP Password Expiration Interval:
Enter the number of days left for the LDAP password to expire.

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 configure their respective components to use SSL connections between the end users and the load balancer or reverse proxy (or Web Tier if an load balancer or reverse proxy 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 to have the endpoint configured for SSL automatically during Oracle Identity Management Provisioning.

If a load balancer is used, the connection between the LBR and the Web Tier is configured as non-SSL, out of the box. Therefore, the HTTP listener on the Oracle HTTP Server is 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 are still SSL, but they terminate at the Web Tier instead. (FA OHS is configured to listen to SSL traffic.)
Oracle Identity Management: All external endpoints are non-SSL. (IDM OHS is configured to listen to regular HTTP traffic.)

4.6.2 SSL Certificate Requirements

SSL Certificate requirements depend on whether the 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 the policies and procedures, along with the instructions provided by the load balancer or reverse proxy manufacturer.

If not using an load balancer or reverse proxy: SSL terminates at OHS, which is configured with a default dummy certificate. As the dummy certificate is not trusted by browsers, end users get certificate warning messages when they access any external URL. To avoid this, 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 Configure Oracle HTTP Server with Custom Certificates.

4.7 Memory Requirements

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

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

Memory Specifics	Requirements
Memory per Managed Servers	2.75GB (2816MB) multiplied by the number of managed servers in the environment, plus 4GB.
Memory Per Administration Servers	1GB multiplied by the number of administration servers in the environment, if the WebLogic domain is not a product family of the product offerings that are selected (see Table 2-2). 2GB multiplied by the number of administration servers in the environment, if the WebLogic domain is a product family of the product offerings that are selected (see Table 2-2).
Business Intelligence Cluster (bi_cluster / BIDomain)	6GB multiplied by the number of managed servers in the environment.
Oracle Enterprise Data Quality Cluster (EDQCluster / CommonDomain)	16GB for one instance of EDQ WebLogic managed server created out-of-the-box if any of the product offerings listed below are selected: CRM: Sales, Marketing, Customer Data Management, Enterprise Contracts. Financials: Financials, Procurement SCM: Product Management, Material Management, Logistics, and Supply Chain Financial Orchestration
Workforce Reputation Cluster (WorkforceReputationCluster / HCMDomain)	8GB multiplied by the number of managed servers in the environment if any of the product offerings listed below are selected: Workforce Deployment Workforce Development See Recommended Memory Requirement for Oracle Fusion Human Capital Management Workforce Reputation Management Product.

4.8 Next Steps

When the Oracle Fusion Applications Installation Workbook is entirely filled out, proceed with Prepare for an Installation.