Single-Tier Topology

Any application architecture with single-tier topology utilizes one physical server for all three logical layers of an application, namely web, application, and database. This is a suitable topology for non-production and demo instances where data security policy is not strictly imposed. There is only one supported topology for single-tier implementation of Oracle Fusion Applications, where we can use two servers for Identity Management and Fusion Applications installation, one for each. Figure 2-1 shows the only possible supported single-tier topology.

Figure 2-1. Single-tier topology with two nodes

Note that the chapter section uses these acronyms for better readability:

• IDM: Oracle Identity Management

• FA: Oracle Fusion Applications

The physical servers/hosts are represented using dotted lines in the diagrams.

Single-tier topology with two nodes is the simplest of all possible topologies and also requires a minimum configuration of nodes for an Oracle Fusion Applications on-premise installation. It has only one server each for the Oracle Identity Management and Oracle Fusion Applications components. The first node’s hardware requirements are modest compared to the second node, which hosts the bulk of Oracle WebLogic Server domains. As mentioned earlier, we will discuss the specific hardware requirements of each of these servers in next section. The following components are hosted on each node in this topology:

• Node 1 (IDMHOST): IDM Web Server, IDM Application Server, IDM Directory Server, and IDM Database

• Node 2 (FAHOST): FA Web Server, FA Application Server, and FA Database

Two-Tier Topologies

Any application architecture utilizing this topology uses two distinct servers for the database and application/web tiers. Let’s look at some of the architecture choices for two-tier implementation of an Oracle Fusion Applications instance. Figure 2-2 shows an example of a two-tier topology with three nodes.

Figure 2-2. Two-tier topology with three nodes

The topology shown in Figure 2-2 isolates databases into different tiers, which is the ideal way of implementing any enterprise application. The remaining components are the same as in the previous topology. In this example, we have hosted IDM and FA databases a on single physical server. In this case, the database host must have a sufficient hardware configuration in order to provide optimal database performance for the IDM and FA databases.

The following components are hosted on each node:

• Node 1 (IDMHOST): IDM Web Server, IDM Application Server, and IDM Directory Server

• Node 2 (FAHOST): FA Web Server and FA Application Server

• Node 3 (DBHOST): IDM Database and FA Database

Next we will look at an example of a two-tier topology with four nodes, as shown in Figure 2-3.

Figure 2-3. Two-tier topology with four nodes

The topology shown in Figure 2-3 is an extension of the previously discussed topology, but in this case the IDM and FA databases are hosted on different physical hosts. This eliminates the performance bottleneck during peak-load situations. This also helps when you have two moderately sized database servers instead of a single high-configuration database server. This topology is best suited for non-production setups among those discussed so far. If your organization does not have strict policy for three-tier architecture then this topology allows rapid provisioning and simpler management of an Oracle Fusion Applications instance.

The following components are hosted on each node:

• Node 1 (IDMHOST): IDM Web Server, IDM Application Server, and IDM Directory Server

• Node 2 (FAHOST): FA Web Server and FA Application Server

• Node 3 (IDMDBHOST): IDM Database

• Node 4 (FADBHOST): FA Database

Three-Tier or Enterprise Topologies

Three-tier topology is also referred to as an enterprise topology. It is the recommended topology as per most security standards adopted by large enterprises. This section discusses three-tier topologies that are generally used in deploying any standard enterprise applications, including a production installation. Let’s look at some of the supported installation options in this topology. We will begin with an example of a three-tier topology with four nodes, as shown in Figure 2-4.

Figure 2-4. Three-tier topology with four nodes

The topology shown in Figure 2-4 is one of the simplest forms of the three-tier architecture, showing the minimum required four hosts. The major difference here is the isolation of the web host. This allows you to keep the application and database servers in more secure networks while the users can access only the web host or network load balancers in the web or DMZ tiers. We will discuss network load balancers and DMZ in next sections and chapters. The following components are installed on each of the physical hosts:

• Node 1 (WEBHOST): IDM Web Server and FA Web Server

• Node 2 (IDMHOST): IDM Application Server and IDM Directory Server

• Node 3 (FAHOST): FA Application Server

• Node 4 (DBHOST): IDM Database and FA Database

Next we will see an extension of the previous topology, which is a three-tier topology with five nodes, as shown in Figure 2-5.

Figure 2-5. Three-tier topology with five nodes

In Figure 2-5 you can see that both databases have been moved to dedicated hosts. This topology requires five servers. The WEBHOST, IDMHOST, IDMDBHOST, and FADBHOST servers require mid-range server configuration. The maximum load remains on FAHOST, which contains all products WebLogic domains, hence it requires high server configuration. The actual amount of memory required will be discussed in following section. Here are the components on each node:

• Node 1 (WEBHOST): IDM Web Server and FA Web Server

• Node 2 (IDMHOST): IDM Application Server and IDM Directory Server

• Node 3 (FAHOST): FA Application Server

• Node 4 (IDMDBHOST): IDM Database

• Node 5 (FADBHOST): FA Database

This topology still does not have dedicated hosts for IDM as well as FA on each tier. Take a look at an example of a three-tier topology with six nodes, shown in Figure 2-6. This is the first topology with a dedicated host at each tier for IDM as well as with FA components.

Figure 2-6. Three-tier topology with six nodes

As shown in Figure 2-6, the three-tier topology with six nodes represents a clear three-tier architecture for both IDM and FA. It includes three individual nodes for IDM components and three nodes for FA components.

In this configuration, the maximum load remains on FAHOST due to the large number of technology components and application deployments. As you can see, the dedicated web nodes are have the lightest load so you should be able to use an entry-level server for this tier. Let’s look at the components on each of these nodes in this topology:

• Node 1 (IDMWEBHOST): IDM Web Server

• Node 2 (FAWEBHOST): FA Web Server

• Node 3 (IDMHOST): IDM Application Server and IDM Directory Server

• Node 4 (FAHOST): FA Application Server

• Node 5 (IDMDBHOST): IDM Database

• Node 6 (FADBHOST): FA Database

Now we will discuss two more non-high available three-tier topologies with further distribution of load across multiple nodes. We will start with an example of a three-tier topology with seven nodes, as shown in Figure 2-7.

Figure 2-7. Three-tier topology with seven nodes

The topology shown in Figure 2-7 is an extension of the true three-tier architecture with two hosts used to accommodate Fusion Applications middle-tier components on dedicated nodes. The advantage of this strategy is that you can reduce the load on a single FA Application node. This is achieved by manually selecting the application managed servers to be deployed on one node (APPHOST), while keeping the middleware managed servers on a second node (MWHOST). You will see this in Chapter 9 during provisioning response file creation and you will notice that it is not mandatory to segregate the managed servers in Application and Middleware managed servers. Instead, you can manually pick which managed server should be hosted on which node. On the other hand, the provisioning process becomes a bit complex since each installation phase needs to finish on all FA nodes before moving to next phase. Let’s look at the components installed on each host in this topology:

• Node 1 (IDMWEBHOST): IDM Web Server

• Node 2 (FAWEBHOST): FA Web Server

• Node 3 (IDMHOST): IDM Application Server and IDM Directory Server

• Node 4 (APPPHOST): FA WebLogic Administration Servers and Application WebLogic Managed Servers

• Node 5 (MWHOST): Middleware WebLogic Managed Servers

• Node 6 (IDMDBHOST): IDM Database

• Node 7 (FADBHOST): FA Database

Now let’s look at another supported option for true three-tier topology with non-high availability. Figure 2-8 shows an example of a three-tier topology with five+n nodes, where n depends on the amount of load distribution required. It can be any number from 1 to the total number of WebLogic domains, depending on offerings selected for provisioning.

Figure 2-8. Three-tier topology with five+n nodes

Figure 2-8 shows the last type of non-high available topology we will discuss here. We can view this topology as a true three-tier architecture from an individual Oracle WebLogic domain point of view. Each domain has components hosted in three different tiers on three different hosts. The FA WebLogic domains are hosted on individual dedicated nodes. The prime benefit of this topology is that you can reuse the organization’s existing mid-range servers for each host instead of going for very high hardware configuration servers. In case of ad hoc performance issues with one server, it will not impact other product domains’ performance.

We will look at this selection screen in Chapter 9, where we will be allowed to select specific physical nodes for one or more WebLogic domains. Depending on the number of nodes selected in this screen, this topology will have five+n nodes. Let’s look at the components installed on each of the nodes in this topology:

• Node 1 (IDMWEBHOST): IDM Web Server

• Node 2 (FAWEBHOST): FA Web Server

• Node 3 (IDMHOST): IDM Application Server and IDM Directory Server

• Node 4 (IDMDBHOST): IDM Database

• Node 5 (FADBHOST): FA Database

• Node 6 (FAHOST1): One or more Product WebLogic domains

• Node n (FAHOSTn): One or more Product WebLogic domains

High-Availability Topologies

We will discuss high-availability topologies in general only since by default the Oracle Fusion Applications installation does not have an out-of-the-box option for selecting true high-availability during the provisioning process. The provisioning wizard allows each WebLogic domain to be hosted on one node, so you need to scale out the WebLogic nodes, databases, or other components after finishing the provisioning process. Note that high-availability can be achieved in any of the previous architectures. Figure 2-9 shows a generic architecture that you can achieve by scaling out any existing topology.

Figure 2-9. Three-tier topology with high-availability

Oracle Identity Management Directory Structure

Let’s begin with understanding the directory structure of Identity Management nodes. Figure 2-10 shows some of the important directories on the IDM node after the Identity Management components are installed and configured.

Figure 2-10. IDM base directory structure

The root directory for the installation (for example, /app/oracle) is called IDM_BASE and it contains the following major subdirectories.

• provisioning: This directory is created and used during IDM provisioning. It contains the provisioning plan and the status information for each provisioning phase for every server in the topology.

• products: This directory contains the Identity Management product suites and the related home directories for WebLogic Server, OAM, OIM, OID, SOA, and so on.

• config: This directory contains instance-specific configuration for middleware components. We will discuss the contents of this directory separately in the following section.

In Figure 2-10, you can also see another directory called config , which contains the shared configuration for the IDM instances including but not limited to WebLogic domains, Oracle HTTP Server configurations, and Oracle Internet directory configurations. Let’s look at the contents of the config directory, shown in Figure 2-11.

Figure 2-11. IDM Config directory structure (components specific to a Fusion Applications installation)

The config directory contains the following important subdirectories:

• fa: This directory is specifically required for Oracle Fusion Applications provisioning in the next step. It contains a file named idmsetup.properties, which is created during IDM provisioning and used for Fusion Applications provisioning response file creation to automatically populate IDM-specific information.

• domains: This directory contains the WebLogic domain specific configuration, startup parameters for managed servers, and log information.

• instances: This directory contains the instance configuration for the Oracle HTTP Server, Oracle Internet Directory instances, and optional Identity Federation instance configuration.

If you enable Local Configuration during the installation, you can see the following two directories in the local non-shared location. These directories include local node-specific instance configuration. This allows you to tune the local node independently to troubleshoot issues specific to node. The location of the local directory should be outside the shared IDM_BASE directory. For example, /app/local.

• domains

• instance

Oracle Fusion Applications Directory Structure

We have seen the Oracle Identity Management directory structure, which mainly focuses on a single WebLogic domain that hosts all the Identity Management components. Oracle Fusion Applications node’s directory structure is more complex compared to IDM nodes. We will look at the major directories in an installed Oracle Fusion Applications instance, which are essential for you to know. This will help you better understand the installation process as well as manage the instance efficiently.

Let’s first look at the main applications base directory, which acts as a root directory for a complete Fusion Applications installation, as shown in Figure 2-12.

Figure 2-12. Fusion Applications base directory structure

You can see a shared configuration directory named instance under the application base, similar to what you have seen in the IDM node. This directory is referred to as APPLICATIONS_CONFIG. The major difference here is that we have more than one WebLogic domain and they can span across multiple servers. You may see the host-specific directory under the domains subdirectory to identify the domains hosted on that particular node. Let’s look at the major directories of importance in the Fusion Applications base.

• instance: This directory contains individual instance-specific configurations for Web Server (CommonDomain_webtier) and Business Intelligence (BIInstance) in addition to applications-specific configurations. It also contains the node manager configuration, which is required for monitoring and controlling of provisioned WebLogic managed servers. It also contains configuration for each product WebLogic domain under the directory specific to the node that hosts that product domain.

• dbclient: Contains Oracle client software.

• webtier_mwhome: Web Server home directory.

• InformaticaIR: Optional Informatica Identity Resolution component that’s installed and configured along with any CRM products.

• provisioning: Contains status and restart information for all phases on each node during an Oracle Fusion Applications provisioning process.

You can see a directory named fusionapps in Figure 2-12. This is the main middleware home directory that contains all middleware and applications components. Figure 2-13 shows major subdirectories of importance in this directory.

Figure 2-13. Fusion Applications home directory structure

Figure 2-13 focuses on the Fusion Applications Home directory, which is called applications under Middleware Home. It contains the top-level directories for each product family, including fin, hcm, crm, scm, prc, prj, and so on. These directories in turn contain individual products directories included in that family. The organization is similar to E-Business Suites, except here we have a hierarchy based on the product family and the individual products. Those who are familiar with E-Business Suite administration will know the other directories like admin (contains patch logs and administration files), bin (scheduler specific binaries), lib (library files), and OPatch. In addition to this, we can see the lcm directory for Oracle Fusion Applications Lifecycle Management components. It also contains AD directory, which is similar to E-Business Suite, but contains a new patching framework and startup/shutdown scripts. We will discuss this directory in detail in the Oracle Fusion Applications administration chapters.

If you select Enable Local Applications Configuration during the provisioning response file creation (explained in Chapter 9), the installer will make a local copy of the following directories on each node where the respective product domain will be installed. The root directory for this local configuration can be any directory that resides outside the shared configuration location, such as /oracle/local.

• domains/<local hostname>

• BIInstance

Deciding the Product Offerings To Be Provisioned

We discussed the relationship between a product family and a product offering in Chapter 1. Before you choose the products to be installed, you need to understand the concept of provisioning configurations. There are predefined provisioning configurations during Oracle Fusion Applications installation that allow you to select from the following major group of product offerings.

• Oracle Fusion Customer Relationship Management

  • Marketing

  • Sales

• Oracle Fusion Financials

  • Financials

  • Procurement

  • Projects

• Oracle Fusion Human Capital Management

  • Workforce Deployment

  • Workforce Development

  • Compensation Management

• Oracle Fusion Supply Chain management

  • Product Management

  • Order Orchestration

  • Material Management and Logistics

  • Supply Chain Financial Orchestration

• Oracle Fusion Accounting Hub

• Customer Data Hub

• Enterprise Contracts

• Oracle Fusion Incentive Compensation

It is important to note that regardless of which specific product offerings are selected for provisioning, the installer will provision, configure, and deploy all the product offerings within the configuration. But it will enable only the required WebLogic managed servers for automatic startup. However, we can enable the product offerings from Oracle Fusion Functional setup screen later as well. This will help us reduce the number of managed servers started and hence the amount of memory required for the instance. We can always enable the features within same configuration whenever required.

Based on your business requirements, you may select a combination of provisioning configurations and a selection of individual product offerings within a configuration (except configurations with standalone product offerings, which do not have further selections).

Deciding the Installation Topology

Although we have seen example topologies with a combination of Oracle Identity Management and Oracle Fusion Applications nodes, you can also decide their topologies independently. Since Oracle Identity Management doesn’t consume a lot of resources, you can decide to consolidate multiple tiers as well unless the Organization Policy restricts you only to use a three-tier topology.

Note that even if you are planning to host the database on a shared DB host or the same host as application server, we recommend you use a different hostname for DB by adding an alias to the same IP in DNS or hosts files in order to enable migrating the database to dedicated servers in the future if required. This will be explained in detail in Chapter 3 when you learn to prepare the servers for provisioning. For the purposes of this book, we are going to keep a two-tier topology as follows.

• Node 1: Oracle Identity Management Web Server and Oracle Identity Management Application Sever

• Node 2: Oracle Identity Management Database

As discussed in an earlier section, the Oracle Fusion Applications nodes can be deployed in single-tier, two-tier, or three-tier topologies. Except for the high-availability architecture, the total memory and disk sizing will remain more or less same for all these topologies. This is because each component takes its own required memory and disk size so it does not really matter where the component is installed. So the trade-off here is that if you go for a single-tier topology, you will need a single high-configuration server. For multi-tier topologies, you can utilize multiple medium configuration servers at each tier.

For the purpose of this book, we are going to select a two-tier topology for Fusion Applications nodes, similar to what we selected for the Oracle Identity Management Server.

• Node 1: Fusion Applications Web Server, all Products WebLogic domains

• Node 2: Fusion Applications Database

Memory Sizing for the Servers

The first question that most Enterprise architects ask is, “Why does Oracle Fusion Applications require such a large amount of memory (RAM)?” You may need to justify to management why you need all that memory in order to get the hardware procurement or allocation approved. This section explains how to calculate the amount of memory required for an Oracle Fusion Applications installation.

Here, we discuss recommended and minimum memory requirements. Recommended memory requirements suggest the amount of memory that will allow your Oracle Fusion Applications instance to perform optimally, while minimum memory requirements suggest the minimum prerequisite memory size that the installer will check for and throw a warning message if the requirements are not met.

Calculating Memory Requirements for an Installation

Note that the final number might not exactly match the one that the installer checks during prerequisite check phase. You might wonder how the installer comes up with the minimum memory requirements and why that number does not match the recommended memory requirements.

The recommended memory size assumes a standard 2 GB memory for all managed servers to keep some free memory after the components are started. The absolute bare minimum memory required is based on the actual JVM size specified for each WebLogic server to be provisioned. Table 2-3 shows an example table prepared from the Oracle Fusion Applications 11g, Release 9. A similar table can be prepared for all other releases as well. This table shows the exact amount of JVM memory required for each administration server, managed server, or cluster to be provisioned for each product family WebLogic domain. The Main column shows values for JVM if the managed server belongs to the product selected for provisioning. The Non-Main column shows values for JVM if the managed server belongs to a product domain being installed due to dependency only.

Table 2-3. The Minimum Memory Requirements for Oracle Fusion Applications WebLogic Domains

Domain	WebLogic Cluster	Main	Non-Main
Default	Default	2048m	1024m
CommonDomain	AdminServer ESSCluster FS_SOACluster FunctionalSetupCluster GrcCoreCluster HelpPortalCluster HomePageCluster IPMCluster WLCSCluster WLCSSIPCluster SESCluster UCMCluster EDQCluster FS_SPACESCluster FS_SERVICESCluster	2048m 1024m 2048m 2048m 1200m 2560m 2048m 1024m 1024m 1024m 1024m 1024m 8192m 1024m 1024m
CRMDomain	AdminServer ContractManagementCluster CRMAnalyticsCluster CRMCommonCluster ESSCluster ODICluster CRMPerformanceCluster CRMSearchCluster CRM_SOACluster CustomerCluster EmailMarketingCluster MarketingCluster OrderCaptureCluster SalesCluster	2048m 2048m 1024m 2048m 2048m 2048m 2048m 2048m 2048m 2048m 1500m 2048m 2048m 2048m	1024m 1024m 2048m 1500m 1024m 1024m 1500m
FinancialDomain	AdminServer FinancialAnalyticsCluster FinancialCommonCluster ESSCluster FinancialSearchCluster FIN_SOACluster GeneralLedgerCluster PayableCluster ReceivableCluster	2048m 2048m 2048m 2048m 2048m 2048m 2048m 2048m 2048m	1024m 1024m 1024m 1024m 1024m 1024m 1024m 1024m 1024m
SCMDomain	AdminServer AdvancedPlanningCluster CostManagementCluster LogisticsCluster OrderOrchestrationCluster OrchestrationInfrastructureCluster ProductManagementCluster SCMCommonCluster ESSCluster ODICluster SCM_SOACluster ConfiguratorCluster FinancialOrchestrationCluster	2048m 2048m 2048m 2048m 2048m 1200m 2048m 2048m 2048m 2048m 2048m 1200m 1200m	1024m 1500m 1500m 1500m 1024m 1200m 1024m 1024m 1024m 1024m 1500m 1200m 1200m
HCMDomain	AdminServer BenefitsCluster CompensationCluster CoreProcessesCluster CoreSetupCluster HCMAnalyticsCluster ESSCluster ODICluster HCM_SOACluster PayrollCluster HCMSearchCluster TalentManagementCluster WorkforceMgmtCluster WorkforceReputationCluster	2048m 2048m 2048m 2048m 2048m 2048m 2048m 2048m 2048m 2048m 2048m 2048m 2048m 2048m	1024m 1024m 1500m 1024m 1024m 1024m 1500m 1024m 1200m 1024m
ProjectsDomain	AdminServer ESSCluster ProjectsFinancialsCluster ProjectsManagementCluster PRJ_SOACluster	2048m 2048m 2048m 2048m 2048m	1024m 1024m 1024m 1024m 1024m
ProcurementDomain	AdminServer ESSCluster ProcurementCluster PRC_SOACluster SupplierPortalCluster	2048m 2048m 2048m 2048m 2048m	1024m 1024m 1024m
ICDomain	AdminServer ESSCluster ODICluster IncentiveCompensationCluster IC_SOACluster	2048m 2048m 2048m 2048m 2048m	1024m 1024m 1024m 1200m 1024m
BIDomain	AdminServer bi_cluster obi	1024m 6144m 2048m
OSNDomain	AdminServer OSNCluster	512m 512m

If you cannot find a value for a specific managed server in the Main or Non-Main category, you can use the default value specified in the first line. When you calculate the memory requirement based on this table, you may get the exact number that the provisioning wizard prerequisite check function yields. The memory size calculated with this may be enough for starting an Oracle Fusion Applications instance, but it may not run with optimal performance. If you are running short of hardware resources or the particular installation is for demo purposes only, you can go ahead with this memory size.

Tip

Due to an incorrect value in the provisioning framework shipped with Fusion Applications 11g Release 8, the Workforce Management Cluster in Fusion HCM used to be configured with 1200 MB instead of the required 2048 MB. This issue has been fixed in Fusion Applications 11.1.9. Table 2-3 reflects the correct values. Similarly, BI Cluster of the BI domain has been enhanced from 2048 MB to 6144 MB in Release 9.

Let’s consider an example to understand the memory sizing calculation. We will select the Oracle Fusion Human Capital Management configuration with all three available product offerings, namely Workforce Deployment, Workforce Development, and Compensation Management. For more details, you can refer to the “Provisioning Response File Creation” section in Chapter 9. Figure 2-14 shows a screenshot of the configuration selection. Note that this is only an example and the actual selection and values for the selected release at the time of your installation may vary.

Figure 2-14. List of WebLogic managed servers selected for Fusion HCM provisioning

You will see that this configuration selects five Admin Servers, 19 application managed servers, and 15 middleware managed servers. Since CommonDomain and BIDomain are configured regardless of product selection, the recommended memory size can be calculated as follows:

• Admin servers: 3 x 2 GB + 2 x 1 GB = 8 GB

• Managed servers: 34 x 2 GB = 68 GB

• OS free memory: 4 GB

• Web server: Approx. 2 GB

• Total: 82 GB

If you want to calculate bare minimum memory required to match the installer’s requirements, you can calculate as per the numbers mentioned in Table 2-3.

• Admin servers: 2 x 2 GB + 3 x 1 GB = 7 GB

• Managed servers: 61,880 MB (Approx. 61 GB)

• Total (excluding OS free and web server) = 68 GB

So the installer will only check for 68 GB, despite the fact that the recommended memory is 82 GB. This is the bare minimum required memory for Fusion HCM instance alone (assuming the database instance is on a different node). In addition to this, a minimum of 8 GB is required for Oracle Identity Management node. You also have similar memory requirements for both Oracle Database instances, as discussed earlier.

Planning Network and Storage

A successful Fusion Applications installation depends on sound planning of the infrastructure components, which includes network, storage, and security devices. We will look at network as well as storage requirements in this section.

Web Proxy Requirements

If you need any external integration (web services hosted on servers outside your internal network) from within Fusion Applications, you may need to configure Web Proxy to allow external requests from Fusion Applications Servers. The internal and external firewalls also need to allow such traffic from Application Servers to external hosts.

Let’s look at a couple of sample network architecture diagrams with load balancer and DMZ with high-availability, as shown in Figure 2-15.

Figure 2-15. Sample network architecture diagrams for a Fusion Applications instance