Oracle E-Business Suite Release 12.2 Configuration in a DMZ

This document is written to guide you through the deployment of the Oracle E-Business Suite Release 12.2 in a DMZ configuration.

The most current version of this document can be obtained in My Oracle Support Knowledge Document 1375670.1. There is a change record at the end of this document.

In This Document

This document contains the following sections:

SECTION 1: OVERVIEW

This document describes methods for making a subset of Oracle E-Business Suite Release 12.2 functionality accessible via the Internet to external users. This document discusses supported network topologies and architectures for the E-Business Suite, including the use of the following:

Hardware-based load-balancers for the deployment of multiple application servers for high availability
Reverse proxy servers in demilitarized zones (DMZ) for enhanced security
Multiple domains with multiple application servers
Single sign-on integration for internal user and external user authentication

This document is intended for administrators who perform Oracle E-Business Suite Release 12.2 administration. It assumes knowledge of networking technologies. The procedures described in this document have security implications. Prior to the implementation of any configuration options described this document, E-Business Suite system administrators are strongly advised to review deployment architectures with their enterprise networking and security groups.

Note: Prior to proceeding with the Oracle E-Business Suite configuration in a DMZ for your environment, you should read and implement security recommendations documented in My Oracle Support Knowledge Document 403537.1, Secure Configuration Guide for Oracle E-Business Suite Release 12. Pay particular attention to correcting issues that are identified after executing the associated Secure Configuration Scripts.

Oracle E-Business Suite Release 12.2 Architecture in a DMZ Configuration

When configuring Oracle E-Business Suite in a DMZ configuration, firewalls are deployed at various levels to ensure that only authorized traffic is allowed to cross the firewall boundaries. The firewalls ensure that if intrusion attempts against machines in the DMZ are successful, the intrusion is contained within the DMZ, leaving the machines in the intranet unaffected. The deployment architecture described in this guide are secure because every functional group of software components is isolated in its own demilitarized zone and all traffic is restricted by protocol and port.

The following configuration options are supported:

Use of separate application tier for external usage
Setting of server level profile values
Associating trust levels to application tier nodes
Limiting available responsibilities to a restricted set for the external application tier node
Deploying a reverse proxy in front of the external application tier node
Configuring a URL firewall and mod security in the reverse proxy
Running only essential Oracle E-Business Suite Application services on the external application tier

Terminology

Below are definitions of some of the terms that are used in this document:

Firewall

Network firewalls control access between the internet and a corporation's internal network or intranet. Firewalls define which internet communications will be permitted into the corporate network, and which will be blocked. A well-designed firewall can foil many common internet-based security attacks.

DMZ

The DMZ, which stands for DeMilitarized Zone consists of the portions of a corporate network that are between the corporate intranet and the Internet. The DMZ can be a simple one segment LAN or it can be broken down into multiple regions . The main benefit of a properly-configured DMZ is better security. In the event of a security breach, only the area contained within the DMZ is exposed to potential damage, while the corporate intranet remains somewhat protected.

Load Balancer

Load balancers distribute an application's load over many identically configured servers. This distribution ensures consistent application availability even when one or more servers fail.

Reverse Proxy

A reverse proxy server is an intermediate server that sits between a client and the actual web server and makes requests to the web server (origin server) on behalf of the client.

Service

A service is a functional set of Oracle E-Business Suite application processes running on one or more nodes.

Node

A node is referred to as a server that runs a set of E-Business Suite R12 application processes or database processes. In a single node installation of Oracle E-Business Suite, all the application processes including the database processes run on one node whereas in a multi node installation, the processes run on multiple nodes.

Internal Applications Tier

The internal applications tier is the server configured for internal users to access Oracle E-Business Suite. It runs the following major application services:

Web and Forms Services
WebLogic Administration service, Node Manager, Oracle HTTP Server, OPMN, WebLogic Managed Servers
Concurrent Manager Services
Reports and Discoverer Services

External Applications Tier

The external applications tier is the server configured for external users for accessing Oracle E-Business Suite. It runs the following application service:

Oracle HTTP Server
WebLogic components like node manager, managed servers etc.

Primary Application Tier Node (or master node)

The application technology stack for Oracle E-Business Suite 12.2 utilizes WebLogic Server. The Primary Application Tier Node is the node that is running the WebLogic administration server.

Secondary Application Tier Node (or slave Node)

The application technology stack for Oracle E-Business Suite 12.2 utilizes WebLogic Server. A secondary application tier node or slave node is a node in a multi-node deployment of Oracle E-Business Suite. The slave node does not run the WebLogic administration server.

Shared Application Tier Filesystem

An application tier file system consists of:

APPL_TOP file system (APPL_TOP and COMMON_TOP directories).
Application tier technology stack file system (OracleAS 10.1.2, Oracle WebLogic Server, and WebTier Oracle Homes).
Instance Home (INST_TOP) file system. Each application tier and each file system edition ( run and patch) has a unique Instance Home associated with it.
OraInventory directory, which stores information about all the components installed in various Oracle Homes

In a Shared Application Tier Filesystem, the APPL_TOP, COMMON_TOP, OracleAS 10.1.2 Oracle Home, Oracle WebLogic Server, and WebTier Oracle Home file systems are mounted on secondary application tier nodes either from the primary application tier node or from an NFS server. For additional information, refer My Oracle Support knowledge Document 1375769.1 Sharing The Application Tier File System in Oracle E-Business Suite Release 12.2

Multiple Domains

Multiple domains may defined to allow different users the ability to access Oracle E-Business Suite via different Web Entry Points.

URL Firewall

URL Firewall is a white list of URLs, for the externally exposed E-Business Suite Modules, that may be accessed from the Internet.

Java Object Cache (JOC)

The Java Object Cache provides caching for expensive or frequently used Java objects when the application servers use a Java program to supply their content. Cached Java objects can contain generated pages or can provide support objects within the program to assist in creating new content. The Java Object Cache automatically loads and updates objects as specified by the Java application.

Java Object Cache (JOC) is used by some of the E-Business suite products to cache frequently used data at the Java layer. In order not to serve the stale data, the products rely on "cache-invalidation" messages between the various application tiers in the intranet and DMZ. When the application tier updates data that is part of cache data set, it will send cache invalidation messages to its peer application tier so that they can throw away their cache and lookup the updated data for their cache.

OPMN

Oracle Process Manager and Notification Server (OPMN) is installed and configured on every tier designated to run the web application. OPMN provides an integrated way to manage all Oracle Application Server components. OPMN consists of two main pieces: the Process Manager and the Notification Server. The Process manager (PM) is the centralized process management mechanism in Oracle Application Server and is used to manage the Oracle HTTP Server. The PM starts, restarts, stops, and monitors every process it manages. It also performs death-detection and automatic restart of the processes. Oracle Notification Server (ONS) is the transport mechanism for failure, recovery, startup, and other related notifications between components in Oracle Application Server.

OHS

Oracle HTTP Server (OHS) is installed and configured on every tier that is designated to run the web application . It provides the key infrastructure required for serving the static and dynamic content generated by Oracle E Business Suite products.

WebLogic Server

Oracle WebLogic Server is a scalable, enterprise-ready Java Platform, Enterprise Edition (Java EE) application server.

WebLogic Cluster

A WebLogic Server cluster consists of multiple WebLogic Server server instances running simultaneously and working together to provide increased scalability and reliability. A cluster appears to clients to be a single WebLogic Server instance. The server instances that constitute a cluster can run on the same machine, or be located on different machines..

WebLogic Proxy Plugin

The WebLogic proxy plug-in maintains a list of WebLogic Server instances that host a clustered servlet or JSP, and forwards HTTP requests to those instances on a round-robin basis

WebLogic Domain

A WebLogic Server domain is a logically related group of WebLogic Server resources.

Administration Server

Every WebLogic domain has a server instance called Administration Server. It is used to configure all other server instances and resources in the domain.

Managed Server

Managed Servers host the components and associated resources that constitute your applications—for example, JSPs and EJBs. When a Managed Server starts up, it connects to the domain's Administration Server to obtain configuration and deployment settings.

Node Manager

Node Manager is a Java utility that runs as separate process from WebLogic Server and allows you to perform common operations tasks for a Managed Server, regardless of its location with respect to its Administration Server.

Web Entry Point

Web Entry Point refers to the host name which is designated to be used by all users to access the Oracle E-Business Suite Release 12.2 system. By default, the web entry point is set to the hostname of the application server where Oracle E-Business Suite is installed. In the case where a load-balancer is used, the Web Entry Point becomes the load-balancer's host name.

Oracle Access Manager ( OAM)

Oracle Access Manager (OAM) is Oracle Identity Management’s solution for web access management and user identity administration.

Section 2: Deployment Options

Each Oracle E-Business Suite configuration in a DMZ deployment as described in Sections 2.1 through 2.4 has the following requirements:

An external application tier with the following configuration:

Define server level profile values required for distinct Web entry points for internal and external users
Restrict access to a limited set of Oracle Applications responsibilities for users logging in via the Internet
Implement URL firewall to restrict access to only the subset of URLs required for external acces

Online Patching specific configuration requirements:

The primary application tier node or the master node requires ssh connectivity to all the secondary application tier nodes. If the external node is in the DMZ, then the network firewall must allow ssh protocol to pass through from the internal primary application tier node to the external application tier nodes.
The secondary application tier or the slave nodes requires t3 ( tcp/ip) protocol connectivity to the WebLogic Administration Server configured on the primary application tier node for both the run and patch edition of the application tier file system. The network firewall must allow the tcp/ip protocol to pass through from the internal primary application tier node to the external application tier nodes and vice versa for the Administration Server port only. Please refer to the applications context variable s_wls_adminport on the run and patch edition file system to determine the port configured. The default port numbers are 7001 and 7002 for a port pool selection of 0 and 1 .
The primary application tier node or the node that hosts concurrent manager service need to ping all the other servers via the ping program that utilize the ICMP protocol. The firewall should allow the ICMP protocol to pass through.
The primary application node or the master node also requires connectivity to the node manager running on various application tier nodes including the ones in the DMZ. Ensure the node manager port is also open for both the run and patch edition file system. Please refer to the applications context variable s_nmport on the run and patch edition file system to determine the port configured. The default port numbers are 5556 and 5557 for a port pool selection of 0 and 1 .

The diagrams in Sections 2.1 through 2.4 include traffic flows. The following describes the traffic flows denoted in the diagrams:

Web traffic is labeled "http/https"
Database traffic is labeled "sqlnet"

See the deployment diagrams in Sections 2.1 through 2.4 for more details regarding ports that need to be opened on the network firewall.

In all the drawings, you can see the flow of the web traffic (http/https) and the database traffic (sqlnet) . In addition to these connections, there may be additional connection netflows related to the Java Object Cache ( JOC) . The JOC is used by some of the E-Business suite products like iStore to cache frequently used data at the Java layer. In order not to serve the stale data, they rely on "cache-invalidation" messages between the various application tiers in the intranet and DMZ. When the application tier updates data that is part of cache data set, it will send cache invalidation messages to it's peer application tier so that they can throw away their cache and lookup the updated data for their cache.

The opening of ports on the firewall related to Java Object Cache is not required for all products. It depends on the products you deploy and how long your data is allowed to be stale in the cache. In some cases you may choose to disable the JOC by setting a low MAX AGE (timeout) for the cache. Check Section 4.6: Enable Distributed Oracle Java Object Cache Functionality and product specific documentation for details and recommendations.

Section 2.1: DMZ Configuration With an External and Internal Application Tier

The architecture diagram shown below represents a simple configuration with an external application tier configured in the demilitarized zone (DMZ) for external users and an internal application tier in the intranet configured for internal users.

The default ports shown in the architecture diagram above is an example and may not reflect the actual values configured on your environment. Please consult with your Oracle E-Business Suite administrator to obtain the correct port numbers configured . The defaults shown above are for the following services

Ports 7001 and 7002 are the WebLogic Administration Server ports for the run and patch edition of the application tier file system.
Ports 5556 and 5557 are the node manager ports for the run and patch edition of the application tier filesystem.

Known Restrictions

The configuration shown above does not allow sharing application tier file system between external and internal application tier nodes.

Section 2.2: DMZ Configuration With a Reverse Proxy and an External Application Tier

The architecture diagram shown below represents a reverse proxy in the demilitarized zone (DMZ) behind an external firewall, and an Oracle E-Business Suite Release 12.2 external application tier in another demilitarized zone behind an internal firewall.

In this configuration, the external Applications tier is required to:

Restrict access to a limited set of Oracle Applications responsibilities for users logging in via the Internet
Allow user access to only Oracle E-Business Suite Release 12 products that can be deployed for Internet access
Mask external application tier details from external users with the use of a reverse proxy server.
Terminate SSL connection at the reverse proxy if required
Implement URL firewall on the reverse proxy server to restrict access only to a subset of URLs

Known Restrictions

The configuration shown above does not allow sharing application tier file system between external and internal application tier nodes.

Section 2.3: DMZ Configuration With Internal and External Application Tiers in the Intranet Sharing the Application Tier File System

The architecture diagram shown below represents a load balancer configured in front of the external and internal application tier nodes. These load balancers are configured to route/balance the http traffic received from the external and internal users to the appropriate application tier nodes.

This configuration is easier to maintain for the following reasons.:

The application tier file systems can be shared among all nodes
There is no requirement to open WebLogic Administration Server port or node manager ports on the firewall
ssh connectivity among application tier nodes doesn't have to cross firewall
There is no requirement to open the Java Object Cache/FND Cache range ports used by JOC

Section 2.4: DMZ configuration with multiple Internal/External application tiers in the Intranet and DMZ

The architecture diagram shown below represents a configuration with multiple internal application tier nodes configured in the intranet sharing a common application tier file system and multiple external application tier nodes configured in the DMZ sharing another file system that is different from the ones shared by the internal application tier nodes. This configuration is sometimes called as a Hybrid setup. There is a load balancer also configured in front of the internal and external application tier nodes to route/balance the http traffic received from the external and internal users to the appropriate application tier nodes.

This configuration in this section includes another firewall for an additional layer of proection. Ports will need to be opened to this firewall for the following.:

WebLogic Administration Server ports
ssh connectivity between application tier nodes

Support Considerations

All customer configurations will be supported. However, the level of supportability will be dependent upon the implementation.

Customers who follow the instructions and implement a tested and certified topology as documented in this Note are fully supported. Oracle recommends the use of one of the configurations or a variant of the configuration described in this Note.
Customers who implement an alternative topology not listed in this note are supported on a best-efforts basis . The Oracle Applications Technology Group will aim to provide an adequate solution to address a customer's problem. Severity 1 bugs in this category will only be accepted for situations where a customer's production system is down. Otherwise, an escalated Severity 2 status is the highest supported severity rating.

Note: For the configurations described in Section 2.3 and 2.4, you may also optionally front end the load-balancer with a reverse proxy server.

Note:: All the deployment options discussed in this document allow for multiple domain s to be configured for both internal and external application tiers. Also the internal/external users may access the Oracle E-Business Suite via URLs that contain different domain names. For example partners.example.com for the external users and employees.example.net for internal users.

SECTION 3: REQUIRED PATCHES FOR DMZ CONFIGURATION

Patch Number/Min Code Level	Description	Instructions
R12.AD.C.Delta.4 and R12.TXK.C.Delta.4	Oracle E-Business suite AD/TXK Delta 4 Patches	Follow Instructions in Document 1617461.1 to apply the required patches. If an update patch for AD/TXK is available, apply those instead of the minimum code level mentioned under Patch Number/Min Code Level.

SECTION 4: COMMON CONFIGURATION STEPS FOR ANY DEPLOYMENT TYPE

This section provide the general configuration step that apply to any deployment model described in this document. Certain common configuration steps must be carried out regardless of which deployment model is used. Some of them may have been already executed as part of the setup that you may already have. Review the steps and perform the appropriate configuration steps wherever necessary.

4.1: Update Hierarchy Type (Required)

Several user profile options are used to construct various URLs in an E-Business Suite R12.2 environment. These user profiles are as follows:

User Profile Name	Internal Name
1. Applications Web Agent	APPS_WEB_AGENT
2. Applications Servlet Agent	APPS_SERVLET_AGENT
3. Applications JSP Agent	APPS_JSP_AGENT
4. Applications Framework Agent	APPS_FRAMEWORK_AGENT
5. ICX:Forms Launcher	ICX_FORMS_LAUNCHER
6. ICX: Oracle Discoverer Launcher	ICX_DISCOVERER_LAUNCHER
7. ICX: Oracle Discoverer Viewer Launcher	ICX_DISCOVERER_VIEWER_LAUNCHER
8. Applications Help Web Agent	HELP_WEB_AGENT
9. Applications Portal	APPS_PORTAL
10. BOM:Configurator URL of UI Manager	CZ_UIMGR_URL
11. QP: Pricing Engine URL	QP_PRICING_ENGINE_URL
12. TCF:HOST	TCF:HOST

The default hierarchy type value for the above profile options is Server type . See diagram below:

The configuration of the E-Business Suite environment for DMZ requires these profile options hierarchy type to be set to SERVRESP.

To change the profile options hierarchy type values to SERVRESP, execute the txkChangeProfH.sql SQL script as shown below:

Source the Run Edition Environment file$ . ./u01/install/APPS/EBSapps.env run
Switch the hierarchy type of the profile options to be of type server-responsibility
$ sqlplus apps/apps @$FND_TOP/patch/115/sql/txkChangeProfH.sql SERVRESP

After the txkChangeProfH.sql script executes successfully, execute AutoConfig on all nodes to set the profile option values at server level

4.2: Enable Oracle E-Business Suite Application Server Security (Required)

Oracle E-Business Suite Release 12.2 is deployed in a multi-node configuration with one Database Server and many possible application tier servers. The servers that communicate with an Oracle E-Business Suite instance include the regular application tier servers running the Oracle HTTP Server, WebLogic components, Oracle forms,reports and also client programs such as Application Desktop Integrator, Oracle Discoverer Admin Edition or an external SOA server. Any program which makes a SQLNET connection to the Oracle E-Business Suite database needs to be trusted at some level. This security feature ensures that such SQLNET connections are coming from trusted machines and/or trusted programs.

The Server Security feature supports authentication of application server machines and code modules in order to access the database. When Server Security is activated, Application Servers are required to supply server IDs (like passwords) and/or code IDs to access a database server. Server IDs identify the machine from which the connection is originating. Code IDs identify the module and patch level from which the connection is originating. Code IDs are included in applications code by development. The database server can be set to allow access only from specific machines and/or by code at a desired patch level.

Ensure that value of application server security authentication autoconfig variable (s_appserverid_authentication) is set to SECURE on all the application tier nodes.

4.3: Update Node Trust Level (Recommended)

Oracle E-Business Suite Release 12.2 has the capability to restrict access to a predefined set of responsibilities based on the application tier server from which the user logs in. This capability is provided by tagging application tier servers with a trust level indicated by the Node Trust Level (NODE_TRUST_LEVEL) server profile option. The Node Trust Level indicates the level of trust associated with a particular application tier node. Currently, three trust levels are supported:

Administrative: Servers marked as Administrative are typically those used exclusively by system administrators. These servers are considered secure and provide access to any and all E-Business Suite functions.
Normal: Servers marked as Normal are those used by employees within a company's firewall. Users logging in from normal servers have access to only a limited set of responsibilities.
External: Servers marked as External are those used by customers or employees outside of a company's firewall. These servers have access to an even smaller set of responsibilities.

The default value for this profile option for all E-Business Suite middle tiers is Normal. If you wish to learn more about the Node Trust Level profile option, please refer to Oracle Applications System Administrators Guide .

Set the NODE_TRUST_LEVEL profile option value on the external application tier in your Oracle E-business Suite Release 12.2 environment to External. See diagram below.

To change the value of the Node Trust Level profile option value to External for a particular node, perform the following steps:

Login to Oracle E-Business Suite as sysadmin user using the internal URL
Select the System Administrator Responsibility
Select Profile / System
From the 'Find system profile option Values' window, select the server that you want to designate as the external web tier
Query for %NODE%TRUST%. You will see a profile option named 'Node Trust Level'. The value for this profile option at the site level will be Normal. Leave this setting unchanged.
Set the value of this profile option to External at the server level. The site level value should remain set to Normal

4.4: Update List of Responsibilities (Recommended)

The steps described in this section are required only if you have marked any of the Oracle E-Business Suite Release 12.2 application tiers as External as described in section 4.2 above.

After updating the server-level profile value for Node Trust Level for the external application tier(s) to External, users can no longer see any responsibilities when they login via the external application tier. In order for a responsibility to be available from the external E-Business Suite application tier, set the Responsibility Trust Level profile option value for that responsibility to External at the responsibility level. For information on additional product specific responsibilities that can be made externally accessible from the external E-Business Suite middle tier, please refer to Appendix B1. Oracle E-Business Suite Product Specific Configurations.

To change the value of the Responsibility Trust Level profile option at the responsibility level for a particular responsibility, perform the following steps:

Login to Oracle E-Business Suite as sysadmin user using the internal URL
Select System Administrator Responsibility
Select Profile / System
From the 'Find system profile option Values' window, select the responsibility that you want to make available to users logging in via the external application tier
Query for %RESP%TRUST%. You will see a profile option named 'Responsibility trust level'. The value for this profile option at site level will be Normal. Leave this setting unchanged.
Set the value of this profile option for the chosen responsibility to External at the responsibility level. The site-level value should remain Normal.
Repeat for all responsibilities that you want to make available from the external application tier.

4.5: Configuring the Web Entry Point for Any Deployment Scenario (Optional)

The deployment options you have chosen may involve configuring an additional Web Entry Point in front of the Oracle HTTP Server running on the internal or external application tier nodes. The following configuration changes need to be performed in the corresponding application tier context file for both the run and patch edition file system . Perform this step only if required.

CONTEXT VARIABLES TO BE UPDATED

s_webentryurlprotocol : set the web entry application tier context variable to  point to the web entry protocol
s_webentryhost : set the web entry application tier context variable to point to the web entry host name
s_webentrydomain : set the web entry application tier context variable to  point to the web entry domain name
s_active_webport : set the web entry application tier context variable to  point to the web entry port number
s_login_page : set the login page context variable to <webentry protocol>://<webentry host>.<webentry domain>:<active web port>. Replace <webentry protocol>, <webentry host>, <webentry domain>, and <active web port> with their respective values
s_endUserMonitoringURL : set the enduser monitoring url context variable to <webentry protocol>://<webentry host>.<webentry domain>:<active web port>. Replace <webentry protocol>, <webentry host>, <webentry domain>, and <active web port> with their respective valuess_external_url : set the external url context variable to <webentry protocol>://<webentry host>.<webentry domain>:<active web port>. Replace <webentry protocol>, <webentry host>, <webentry domain>, and <active web port> with their respective values

SSL TERMINATED CONFIGURATION
s_enable_sslterminator : set the ssl terminator context variable to remove the "#" where ssl connections are terminated at the LBR or Reverse proxy configurations.

4.6: Enable Distributed Oracle Java Object Cache Functionality (Conditional)

The opening of ports on the firewall related to Java Object Cache is not required for all products. It depends on the products you deploy and how long your data is allowed to be stale in the cache. In some cases you may choose to reduce read inconsistencies by setting a low MAX AGE (timeout) for the Java Object Cache. Check product specific documentation for details and recommendations.

The following is the current list of known Oracle E-Business Suite products that use JOC: iProcurement, Oracle Configurator, Oracle Contracts Core, Oracle Inventory Management, Oracle iStore, Oracle Leads Management, Oracle Profitability Manager, Oracle Purchasing, Oracle Quoting, Oracle Sales Online, Oracle Scripting, Oracle Service, Oracle Sourcing and Oracle Transfer Pricing.

If you are using one of the listed products, distributed caching functionality can be enabled in a DMZ environment through the firewall to avoid data inconsistencies. To complete this configuration, follow the steps given below:

Identify the highest number of JVMs that serve the oacore JVM group in the internal and external middle tiers. For eg: if there are 3 JVMs in the internal and 2 JVMs configured for the external middle tier, take the number as 3.
Identify the number of java processes spawned by the concurrent manager tier. For eg: if there are 3 JVMs spawned by the ICM, take the number as 3 . Add this to the number of oacore JVMs . In the example given above, the total number JVMs thus become 6 . So, six ports need to be opened in the firewall. You can use the 'pstree' command to check the number of java processes spawned by the concurrent manager parent process. For eg: pstree -p 26258 where 26258 is the process ID of the FNDSM process.
Identify the ports to open in the firewall that separates the external application tier and the internal application tier . For eg: if the JVM count is 3, you have to open 3 ports on this firewall.
This range of ports need to be specified as a value for the autoconfig variable ( s_fnd_cache_port_range ) . Please make sure that the value is same in all the applications context files . The value should be specified as a range. For eg: 36500-36505. When AutoConfig completes the configuration, the value specified for this variable in the context file will get updated in the FND_CACHE_PORT_RANGE profile option.
In addition to the ports specified above, you must ensure that the Java Object Cache Port specified as a value for the autoconfig variable s_java_object_cache_port is also open on the firewall that separate the external and internal application tiers. Please make sure that the value of the variable s_java_object_cache_port is same in all the applications context files.

For additional information, refer My Oracle Support Document 1108093.1 ( Oracle E-Business Suite Java Caching Framework Developer's Guide, Release 12).

4.7: SSH Connectivity Requirements for Online Patching (Required)

The 12.2 online patching tool adop requires ssh connectivity between the primary application tier node often called as the master node configured in the intranet with other application tier nodes configured in both the Intranet and in the DMZ. This connectivity is required for the remote invocation of the patching procedures on all the nodes. See Set up Secure Shell on Application tier Nodes in the Oracle E-Business Suite Maintenance Guide for more information.

SECTION 5: DETAILED INSTRUCTIONS TO CONFIGURE THE SUPPORTED TOPOLOGIES

Note: This document focuses on enterprise deployment in Linux environments. The same deployment may also be configured on certified UNIX and Windows platforms. Sharing the application tier filesystem is not currently certified on application tier server nodes running Windows.

Section 5.1: DMZ configuration with a reverse proxy and an external application tier

This section explains how to deploy the Oracle E-Business Suite 12.2 in a DMZ configuration with an internal and external application tier . There are two configurations options described in this section

The architecture diagram shown below in this section represents this setup.

The hostname's, the location of the file systems, the SID etc are chosen as an example to describe in detail how the setup described above can be configured. The actual values of these parameters may differ on your environment.

The topology shown above assume the following configuration:

Database Tier

DB HOSTNAME             :  db.example.net
INSTALL BASE            :  /u01/install/VISION
DB ORACLE_HOME          :  /u01/install/VISION/11.2.0
DBF  Files              :  /u01/install/VISION/data
SID : VISION

Primary Application Tier

APPLICATION TIER HOSTNAME : finance.example.net
NODE_TYPE : Internal
INSTALL BASE              :  /u01/install/APPS
Run File System ( FS1)    :  /u01/install/APPS/fs1
Patch File System ( FS2)  :  /u01/install/APPS/fs2
APPL_TOP 1                :  /u01/install/APPS/fs1/EBSapps
APPL_TOP 2                :  /u01/install/APPS/fs2/EBSapps
FMW_HOME 1                :  /u01/install/APPS/fs1/FMW_Home
FMW_HOME 2                :  /u01/install/APPS/fs2/FMW_Home
INST_TOP 1                :  /u01/install/APPS/fs1/inst
INST_TOP 2                :  /u01/install/APPS/fs2/inst

APPLICATION TIER HOSTNAME : supplier.example.com
NODE_TYPE : External
INSTALL BASE              :  /u01/install/APPS
Run File System ( FS1)    :  /u01/install/APPS/fs1
Patch File System ( FS2)  :  /u01/install/APPS/fs2
APPL_TOP 1                :  /u01/install/APPS/fs1/EBSapps
APPL_TOP 2                :  /u01/install/APPS/fs2/EBSapps
FMW_HOME 1                :  /u01/install/APPS/fs1/FMW_Home
FMW_HOME 2                :  /u01/install/APPS/fs2/FMW_Home
INST_TOP 1                :  /u01/install/APPS/fs1/inst
INST_TOP 2                :  /u01/install/APPS/fs2/inst


Web Entry Points
INTERNAL WEB ENTRY POINT : http://finance.example.net:80/
EXTERNAL WEB ENTRY POINTS : https://partners.example.com:443/

Section 5.1.1: Required Oracle E-Business Suite Patches

Apply the required Oracle E-Business Suite patches as mentioned in Section 3: Required Patches for DMZ Configuration of this document.

Section 5.1.2: Instructions to Add Additional Application Tier Nodes

The implementation process described here assume that you have a fully-configured Oracle E-Business Suite Database Tier and a Oracle E-Business Suite primary application tier installed on two separate machines via Rapid Install or Rapid Clone . A two tier configuration as described in this document is the recommended approach for building a DMZ environment. Detailed instruction on how to build a two tier installation from Rapid Install is described in My Oracle Support Document 1375769.1 . See section 2, Planning Deployment options, and section 3, Installing a Shared Application Tier File System with 12.2 Rapid Install.

The example given below will guide you through the process of adding the additional application tier nodes for the configuration displayed in the diagram given in Section 5.1 DMZ configuration with a reverse proxy and an external application tier

Existing Configuration

Database Tier

DB HOSTNAME              :  db.example.net
INSTALL BASE             :  /u01/install/VISIONDB ORACLE_HOME           :  /u01/install/VISION/11.2.0
DBF  Files               :  /u01/install/VISION/data
SID : VISION

Primary Application Tier


APPLICATION TIER HOSTNAME : finance.example.net
INSTALL BASE              :  /u01/install/APPS
Run File System ( FS1)    :  /u01/install/APPS/fs1
Patch File System ( FS2)  :  /u01/install/APPS/fs2
APPL_TOP 1                :  /u01/install/APPS/fs1/EBSapps
APPL_TOP 2                :  /u01/install/APPS/fs2/EBSapps
FMW_HOME 1                :  /u01/install/APPS/fs1/FMW_Home
FMW_HOME 2                :  /u01/install/APPS/fs2/FMW_Home
INST_TOP 1                :  /u01/install/APPS/fs1/inst
INST_TOP 2                :  /u01/install/APPS/fs2/inst

Section 5.1.2.1: Perform Sanity Tests On the Primary Application Tier Node

The process of implementing a multi-node configuration is complex and error prone. Before proceeding with the addition of new nodes, you must ensure the integrity of the primary application tier node. Few of the tasks that you must perform before proceeding are the following:

Sign on to Oracle E-Business Suite Application.
Choose a forms responsibility and launch forms.
Login to the weblogic console and fusion middleware console using the WebLogic admin credentials.
Submit concurrent requests to make sure the concurrent requests can be executed and their output/log can be viewed from the client.
Start and stop the application tier processes from the current run file system. The processes must be started on the primary application tier node first followed by the secondary application tier nodes. The application tier processes processes can be started/stopped using the adstrtal.sh/adstpall.sh script from the <INST_TOP>/admin/scripts directory.
Execute an empty online patching cycle using the online patching utility adop. An empty patching cycle can be executed from the run edition file system by following the instructions given in the table below.

Primary Application Tier


APPLICATION TIER HOSTNAME : finance.example.net
INSTALL BASE              :  /u01/install/APPS
Run File System ( FS1)    :  /u01/install/APPS/fs1
Patch File System ( FS2)  :  /u01/install/APPS/fs2
INST_TOP 1                :  /u01/install/APPS/fs1/inst
INST_TOP 2                :  /u01/install/APPS/fs2/inst
LOCATION OF THE RUN CONTEXT_FILE : /u01/install/APPS/fs1/inst/apps/VISION_finance/appl/admin/VISION_finance.xml
LOCATION OF THE PATCH CONTEXT_FILE : /u01/install/APPS/fs2/inst/apps/VISION_finance/appl/admin/VISION_finance.xml


Source the Run Edition Environment file
$ . ./u01/install/APPS/EBSapps.env run

$ adop phase=prepare

$ adop phase=cutover

Section 5.1.2.2: Update the Hierarchy Type

Perform the following steps on the primary application tier node or the master node. See Section 4.1: Update Hierarchy Type for more information.

Primary Application Tier


APPLICATION TIER HOSTNAME : finance.example.net
INSTALL BASE              :  /u01/install/APPS
Run File System ( FS1)    :  /u01/install/APPS/fs1
Patch File System ( FS2)  :  /u01/install/APPS/fs2
INST_TOP 1                :  /u01/install/APPS/fs1/inst
INST_TOP 2                :  /u01/install/APPS/fs2/inst
LOCATION OF THE RUN CONTEXT_FILE : /u01/install/APPS/fs1/inst/apps/VISION_finance/appl/admin/VISION_finance.xml
LOCATION OF THE PATCH CONTEXT_FILE : /u01/install/APPS/fs2/inst/apps/VISION_finance/appl/admin/VISION_finance.xml


Source the Run Edition Environment file
$ . ./u01/install/APPS/EBSapps.env run

Switch the hirearchy type of the profile options to be of type server-responsibility

$ sqlplus apps/apps @$FND_TOP/patch/115/sql/txkChangeProfH.sql SERVRESP

Section 5.1.2.3: Execute Adpreclone Utility on the run and patch edition File System

The adpreclone utility shipped with Oracle E-Business Suite packages the required application tier components to a staging directory for subsequent clone and add node operations. You must run this utility before proceeding to the later section of this document.

The adpreclone utility requires the WebLogic Administration process to be running from the file system where the utility is run. This is required to package the Oracle Fusion Middleware components and its configuration. Execute the commands given below on both the run and patch edition file systems:

Primary Application Tier


APPLICATION TIER HOSTNAME : finance.example.net
INSTALL BASE              :  /u01/install/APPS
Run File System ( FS1)    :  /u01/install/APPS/fs1
Patch File System ( FS2)  :  /u01/install/APPS/fs2
INST_TOP 1                :  /u01/install/APPS/fs1/inst
INST_TOP 2                :  /u01/install/APPS/fs2/inst
LOCATION OF THE RUN CONTEXT_FILE : /u01/install/APPS/fs1/inst/apps/VISION_finance/appl/admin/VISION_finance.xml
LOCATION OF THE PATCH CONTEXT_FILE : /u01/install/APPS/fs2/inst/apps/VISION_finance/appl/admin/VISION_finance.xml


Source the Run file system env file
$ . ./u01/install/APPS/EBSapps.env run

$ $INST_TOP/admin/scripts/adadminsrvctl.sh start

$ $INST_TOP/admin/scripts/adpreclone.pl appsTier

$ $INST_TOP/admin/scripts/adadminsrvctl.sh stop

$ $INST_TOP/admin/scripts/adnodemgrctl.sh stop

Source the Patch file system env file

$ . ./u01/install/APPS/EBSapps.env patch
$ $INST_TOP/admin/scripts/adadminsrvctl.sh start forcepatchfs

$ $INST_TOP/admin/scripts/adpreclone.pl appsTier

$ $INST_TOP/admin/scripts/adadminsrvctl.sh stop

$ $INST_TOP/admin/scripts/adnodemgrctl.sh stop

Section 5.1.2.4: Add the Secondary Application Tier Node to the Farm

The tasks listed in this section assume that you have completed all the steps mentioned above in this section. It is important that you review the configuration before proceeding with the steps given below. The node to be added now will be known as the secondary application tier node or the slave node. This node can be configured to run all services except for the Oracle WebLogic Administration Server.

Note:

The fully qualified hostname of the application tier node to be added must be present in the sqlnet.ora file in the <Database_Oracle_ Home>/network/admin<context-name> directory if it exists. (See tcp.invited_nodes parameter.)
The database and TNS listener must be running.
The User ID and group ID should be consistent across all nodes to avoid file access permission issues.
The same absolute path must be used for the shared file system mount points on every node.
Ensure that value of the AutoConfig variable "s_atName" is set to the hostname of the current node
The fully qualified hostname of the application tier nodes that you are going to add must be resolvable from the primary application tier node and vice versa either via the Domain Naming System (DNS) or file based resolution.
Every application tier node must have a valid oraInst.loc file in the respective directory ( see Oracle Universal Intaller guide for platform specific location) pointing to a global inventory location. The default location for the Linux platform is /etc directory.

Section 5.1.2.4.1: Copy the Required Application Tier File System to the Secondary Nodes

Follow the instructions given below to copy the file system from the primary application tier node to the secondary application tier node.

APPLICATION TIER HOST FROM WHERE FILE SYSTEM NEED TO BE COPIED: finance.example.net
APPLICATION TIER HOSTS TO WHICH FILE SYSTEM NEED TO BE COPIED : supplier.example.com

The following application tier file system from the INSTALL_BASE need to be copied from the primary node to the secondary application tier node


Run File System (FS1)     :  /u01/install/APPS/fs1/EBSapps
Patch File System (FS2)   :  /u01/install/APPS/fs2/EBSapps
Non-Editioned File System(fs_ne)  :  /u01/install/APPS/fs_ne

Section 5.1.2.4.2: Execute the Post Clone Script on the Run File System

Follow the instructions given below to configure the secondary application tier node run file system . Answer the prompts as shown in the table below. Replace the instance specific values wherever necessary.

Secondary Application Tier Node

SECONDARY APPLICATION TIER NODE: supplier.example.com
$ cd <COMMON_TOP>/clone/bin

$ perl ./adcfgclone.pl appsTier
Answer the prompts as shown below:

Enter the APPS Password : <apps-password>

Enter the WebLogic AdminServer password: <WebLogic-admin-password>

Do you want to add a node (yes/no) : yes

Target System File Edition type [run]: run

Provide the values required for creation of the new APPL_TOP Context file.

Target System Hostname (virtual or normal) [supplier] : supplier

Target System Base Directory set to /u01/install/APPS

Target System Current File System Base set to /u01/install/APPS/fs1

Target System Other File System Base set to /u01/install/APPS/fs2

Target System Fusion Middleware Home set to /u01/install/APPS/fs1/FMW_Home

Target System Web Oracle Home set to /u01/install/APPS/fs1/FMW_Home/webtier

Target System Appl TOP set to /u01/install/APPS/fs1/EBSapps/appl

Target System COMMON TOP set to /u01/install/APPS/fs1/EBSapps/comn

Target System Instance Home Directory [/u01/install/APPS]: /u01/install/APPS

Target System Instance Top set to /u01/install/APPS/fs1/inst/apps/VISION_supplier

Do you want to preserve the Display [localhost5:0] {y/n) :y

Target System Root Service [enabled]: enabled

Target System Web Entry Point Services [enabled]: enabled

Target System Web Application Services [enabled]: enabled

Target System Batch Processing Services [enabled]: disabled

Target System Other Services [disabled]: disabled

Do you want the target system to have the same port values as the source system (y/n) [y] : y
Complete port information available at /u01/install/APPS/fs1/EBSapps/comn/clone/bin/out/VISION_supplier/portpool.lst

UTL_FILE_DIR on database tier consists of the following directories.

1. /usr/tmp
2. /usr/tmp
3. /u01/install/PROD/11.2.0/appsutil/outbound/EBSDB_db
4. /usr/tmp

Choose a value which will be set as APPLPTMP value of the target node [1] : 1

Do you want to startup the Application Services for VISION? {y/n)[n]: n

Section 5.1.2.4.3: Execute the Post Clone Script on the Patch File System

Follow the instructions given below to configure the secondary application tier node patch file system . Answer the prompts as shown in the table below. Replace the instance specific values wherever necessary.

SECONDARY APPLICATION TIER NODE: supplier.example.com
$ cd <COMMON_TOP>/clone/bin

$ perl ./adcfgclone.pl appsTier
Answer the prompts as shown below:

Enter the APPS Password : <apps-password>

Enter the WebLogic AdminServer password: <WebLogic-admin-password>

Do you want to add a node (yes/no) : yes

Target System File Edition type [patch]: patch

Provide the values required for creation of the new APPL_TOP Context file.

Target System Hostname (virtual or normal) [supplier] : supplier

Target System Base Directory set to /u01/install/APPS

Target System Current File System Base set to /u01/install/APPS/fs2

Target System Other File System Base set to /u01/install/APPS/fs1

Target System Fusion Middleware Home set to /u01/install/APPS/fs2/FMW_Home

Target System Web Oracle Home set to /u01/install/APPS/fs2/FMW_Home/webtier

Target System Appl TOP set to /u01/install/APPS/fs2/EBSapps/appl

Target System COMMON TOP set to /u01/install/APPS/fs2/EBSapps/comn

Target System Instance Home Directory [/u01/install/APPS]: /u01/install/APPS

Target System Instance Top set to /u01/install/APPS/fs2/inst/apps/VISION_supplier

Do you want to preserve the Display [localhost5:0] {y/n) :y

Target System Root Service [enabled]: enabled

Target System Web Entry Point Services [enabled]: enabled

Target System Web Application Services [enabled]: enabled

Target System Batch Processing Services [enabled]: disabled

Target System Other Services [disabled]: disabled

Do you want the target system to have the same port values as the source system (y/n) [y] : y
Complete port information available at /u01/install/APPS/fs1/EBSapps/comn/clone/bin/out/VISION_supplier/portpool.lst

UTL_FILE_DIR on database tier consists of the following directories.

1. /usr/tmp
2. /usr/tmp
3. /u01/install/PROD/11.2.0/appsutil/outbound/EBSDB_db
4. /usr/tmp

Choose a value which will be set as APPLPTMP value of the target node [1] : 1

Section 5.1.2.4.4: Configure a Reverse Proxy Infront of the External Application Tier Node

The deployment option covered in this section has a reverse proxy server configured in front of the external application tier node and it requires the Oracle E-Business Suite application tier nodes to be aware of the presence of the reverse proxy server. The web entry point parameters in the application tier context file for both the run and patch edition file system need to be updated to front end the external application tier node with the reverse proxy server. An example is provided in the following table..

External Application Tier Nodes


APPLICATION TIER HOSTNAME : supplier.example.com
INSTALL BASE              :  /u01/install/APPS
Run File System ( FS1)    :  /u01/install/APPS/fs1
Patch File System ( FS2)  :  /u01/install/APPS/fs2
INST_TOP 1                :  /u01/install/APPS/fs1/inst
INST_TOP 2                :  /u01/install/APPS/fs2/inst
LOCATION OF THE RUN CONTEXT_FILE : /u01/install/APPS/fs1/inst/apps/VISION_supplier/appl/admin/VISION_supplier.xml
LOCATION OF THE PATCH CONTEXT_FILE : /u01/install/APPS/fs2/inst/apps/VISION_supplier/appl/admin/VISION_supplier.xml


Reverse Proxy CONFIGURATION

RP WEBENTRY PROTOCOL : https
RP HOSTNAME : partners
RP DOMAINNAME : example.com
RP ENTRYPORT : 443


CONTEXT VARIABLES TO BE CHANGED FOR THE ABOVE LBR CONFIGURATION

<webentryurlprotocol oa_var="s_webentryurlprotocol">https</webentryurlprotocol>

<webentryhost oa_var="s_webentryhost">partners</webentryhost>

<webentrydomain oa_var="s_webentrydomain">example.com</webentrydomain>

<activewebport oa_var="s_active_webport">443</activewebport>

<login_page oa_var="s_login_page">https://partners.example.com:443/OA_HTML/AppsLogin</login_page>

<EndUserMonitoringURL oa_var="s_endUserMonitoringURL">https://partners.example.com:443/oracle_smp_chronos/oracle_smp_chronos_sdk.gif</EndUserMonitoringURL>

<externURL oa_var="s_external_url">https://partners.example.com:443/OA_HTML/AppsLogin</externURL>

Section 5.1.2.4.5: Execute AutoConfig On the External Application Tier Node

Perform the following steps on the external application tier node.

External Application Tier Node


APPLICATION TIER HOSTNAME : supplier.example.com
INSTALL BASE              :  /u01/install/APPS
Run File System ( FS1)    :  /u01/install/APPS/fs1
Patch File System ( FS2)  :  /u01/install/APPS/fs2
INST_TOP 1                :  /u01/install/APPS/fs1/inst
INST_TOP 2                :  /u01/install/APPS/fs2/inst
LOCATION OF THE RUN CONTEXT_FILE : /u01/install/APPS/fs1/inst/apps/VISION_supplier/appl/admin/VISION_supplier.xml
LOCATION OF THE PATCH CONTEXT_FILE : /u01/install/APPS/fs2/inst/apps/VISION_supplier/appl/admin/VISION_supplier.xml


Execute Autoconfig on the run file system
$ . ./u01/install/APPS/EBSapps.env run

$ $INST_TOP/admin/scripts/adautocfg.sh

Upload the Patch file system context file to the Database

$ . ./u01/install/APPS/EBSapps.env patch

$ $ADJVAPRG oracle.apps.ad.autoconfig.oam.CtxSynchronizer action=upload
contextfile=<full path to patch context file> logfile=/tmp/patchctxupload.log

Please note there is no need to execute autoconfig on the patch file system.

Section 5.1.2.4.6: Sync Up the Context File and Update Configuration on All Nodes

Follow the instructions given below on all application tier nodes to sync up the context file and configuration files.

PRIMARY APPLICATION TIER NODE : finance.example.net

SECONDARY APPLICATION TIER NODE : supplier.example.com

Login to all the application tier nodes and execute the the following scripts to sync up the context file and configuration files for the run file systemSource the EBSapps.env file$ . ./u01/install/APPS/EBSapps.env run
$ perl $AD_TOP/bin/adSyncContext.pl contextfile=$CONTEXT_FILE

The following command syntax works with AD/TXK Code Level D4 .
$ perl $FND_TOP/patch/115/bin/txkSetAppsConf.pl -ctxfile=$CONTEXT_FILE -outfile=$APPLRGF/TXK/conf.log

If you are a later version of the AD/TXK Code level, follow the instructions given in section 5.3.2.4-5.3.2.7 (Register the new topology from the newly added application tier node) of My Oracle Support Document 1383621.1, Cloning Oracle E-Business Suite Release 12.2 with Rapid Clone, to register the new topology.

Execute AutoConfig on all application tier nodes

Login to all the application tier nodes and execute the the following scripts to sync up the context file and configuration files for the patch file systemSource the EBSapps.env file$ . ./u01/install/APPS/EBSapps.env patch
$ perl $AD_TOP/bin/adSyncContext.pl contextfile=$CONTEXT_FILE

The following command syntax works with AD/TXK Code Level D4 .
$ perl $FND_TOP/patch/115/bin/txkSetAppsConf.pl -ctxfile=$CONTEXT_FILE -outfile=$APPLRGF/TXK/conf.log

If you are a later version of the AD/TXK Code level, follow the instructions given in section 5.3.2.4-5.3.2.7 (Register the new topology from the newly added application tier node) of My Oracle Support Document 1383621.1, Cloning Oracle E-Business Suite Release 12.2 with Rapid Clone, to register the new topology.

Please note that the log file name may differ depending on the TXK code level present on your environment.

Section 5.1.2.4.7: Perform Sanity Tests

Perform the following sanity tests to check the health of the multi-node application tier system:

Start and stop the application tier processes from the current run file system. The processes must be started on the primary application tier node first followed by the secondary application tier nodes. The application tier processes can be started/stopped using the adstrtal.sh/adstpall.sh script from the <INST_TOP>/admin/scripts directory.
Sign on to Oracle E-Business Suite application from the multiple web entry points.
Choose a forms responsibility and launch forms.
Login to the WebLogic console and fusion middleware console using the WebLogic admin credentials. Make sure you can view all the managed servers in RUNNING status from the servers menu.
Submit concurrent requests to make sure the concurrent requests can be executed and their output/log can be viewed from the client.
Execute an empty online patching cycle using the online patching utility adop. An empty patching cycle can be executed from the run edition file system by following the instructions given in the table below.

Primary Application Tier


APPLICATION TIER HOSTNAME : finance.example.net
INSTALL BASE              :  /u01/install/APPS
Run File System ( FS1)    :  /u01/install/APPS/fs1
Patch File System ( FS2)  :  /u01/install/APPS/fs2
INST_TOP 1                :  /u01/install/APPS/fs1/inst
INST_TOP 2                :  /u01/install/APPS/fs2/inst
LOCATION OF THE RUN CONTEXT_FILE : /u01/install/APPS/fs1/inst/apps/VISION_finance/appl/admin/VISION_finance.xml
LOCATION OF THE PATCH CONTEXT_FILE : /u01/install/APPS/fs2/inst/apps/VISION_finance/appl/admin/VISION_finance.xml


Source the Run Edition Environment file
$ . ./u01/install/APPS/EBSapps.env run

$ adop phase=prepare

$ adop phase=cutover

Section 5.2: DMZ Configuration With Internal and External Application Tiers in the Intranet Sharing the Same File System

This section explains how to deploy the Oracle E-Business Suite 12.2 in a DMZ configuration with internal and external application tiers sharing the same application tier file system. The architecture diagram shown below in this section represents the setup.

The topology shown above assume the following configuration:

Database Tier

DB HOSTNAME              :  db.example.net
INSTALL BASE             :  /u01/install/VISIONDB ORACLE_HOME           :  /u01/install/VISION/11.2.0
DBF  Files               :  /u01/install/VISION/data
SID : VISION

Primary Application Tier


APPLICATION TIER HOSTNAME : finance.example.net
NODE_TYPE : Internal
INSTALL BASE              :  /u01/install/APPS
Run File System ( FS1)    :  /u01/install/APPS/fs1
Patch File System ( FS2)  :  /u01/install/APPS/fs2
Non-Editioned File System (fs_ne) : /u01/install/APPS/fs_ne
APPL_TOP 1                :  /u01/install/APPS/fs1/EBSapps
APPL_TOP 2                :  /u01/install/APPS/fs2/EBSapps
FMW_HOME 1                :  /u01/install/APPS/fs1/FMW_Home
FMW_HOME 2                :  /u01/install/APPS/fs2/FMW_Home
INST_TOP 1                :  /u01/install/APPS/fs1/inst
INST_TOP 2                :  /u01/install/APPS/fs2/inst
All the Secondary Application Tier nodes share the file system from finance.example.net . The file system for the secondary nodes will be exported and mounted on the secondary application tier nodes.

APPLICATION TIER HOSTNAME : procurement.example.net
NODE_TYPE : Internal
INSTALL BASE              :  /u01/install/APPS
Run File System ( FS1)       :  /u01/install/APPS/fs1
Patch File System ( FS2)       :  /u01/install/APPS/fs2Non-Editioned File System (fs_ne) : /u01/install/APPS/fs_ne
APPL_TOP 1                :  /u01/install/APPS/fs1/EBSapps
APPL_TOP 2                :  /u01/install/APPS/fs2/EBSapps
FMW_HOME 1                :  /u01/install/APPS/fs1/FMW_Home
FMW_HOME 2                :  /u01/install/APPS/fs2/FMW_Home
INST_TOP 1                :  /u01/install/APPS/fs1/inst
INST_TOP 2                :  /u01/install/APPS/fs2/inst

APPLICATION TIER HOSTNAME : supplier.example.com
NODE_TYPE : External
INSTALL BASE              :  /u01/install/APPS
Run File System ( FS1)       :  /u01/install/APPS/fs1
Patch File System ( FS2)       :  /u01/install/APPS/fs2
Non-Editioned File System (fs_ne) : /u01/install/APPS/fs_ne
APPL_TOP 1                :  /u01/install/APPS/fs1/EBSapps
APPL_TOP 2                :  /u01/install/APPS/fs2/EBSapps
FMW_HOME 1                :  /u01/install/APPS/fs1/FMW_Home
FMW_HOME 2                :  /u01/install/APPS/fs2/FMW_Home
INST_TOP 1                :  /u01/install/APPS/fs1/inst
INST_TOP 2                :  /u01/install/APPS/fs2/inst

APPLICATION TIER HOSTNAME : sourcing.example.com
NODE_TYPE : External
INSTALL BASE              :  /u01/install/APPS
Run File System ( FS1)       :  /u01/install/APPS/fs1
Patch File System ( FS2)       :  /u01/install/APPS/fs2
Non-Editioned File System (fs_ne) : /u01/install/APPS/fs_ne
APPL_TOP 1                :  /u01/install/APPS/fs1/EBSapps
APPL_TOP 2                :  /u01/install/APPS/fs2/EBSapps
FMW_HOME 1                :  /u01/install/APPS/fs1/FMW_Home
FMW_HOME 2                :  /u01/install/APPS/fs2/FMW_Home
INST_TOP 1                :  /u01/install/APPS/fs1/inst
INST_TOP 2                :  /u01/install/APPS/fs2/inst

Web Entry Points

INTERNAL WEB ENTRY POINT : http://employees.example.net:80/

EXTERNAL WEB ENTRY POINTS : https://partners.example.com:443/

Section 5.2.1: Required Oracle E-Business Suite Patches

Apply the required Oracle E-Business Suite patches as mentioned in Section 3: Required Patches for DMZ Configuration of this document.

Section 5.2.2: Instructions to add additional application tier nodes

The process of implementing a DMZ configuration for your E-Business Suite environment will vary depending on the topology you need for your company. The implementation process described here assume that you have a fully-configured Oracle E-Business Suite Database Tier and a Oracle E-Business Suite primary application tier installed on two separate machines via Rapid Install or Rapid Clone . A two tier configuration as described in this document is the recommended approach for building a DMZ environment. Detailed instruction on how to build a two tier installation from Rapid Install is described in My Oracle Support Document 1375769.1. See section 2, Planning Deployment options, and section 3, Installing a Shared Application Tier File System with 12.2 Rapid Install.

The example given below will guide you through the process of adding the additional application tier nodes for the configuration displayed in the diagram given in Section 2.3: DMZ Configuration with Internal and External Application Tiers in the Intranet Sharing the Application Tier File System

Existing Configuration

Database Tier

DB HOSTNAME              :  db.example.net
INSTALL BASE              :  /u01/install/VISIONDB ORACLE_HOME            :  /u01/install/VISION/11.2.0
DBF  Files                :  /u01/install/VISION/data
SID : VISION

Primary Application Tier


APPLICATION TIER HOSTNAME : finance.example.net
INSTALL BASE              :  /u01/install/APPS
Run File System ( FS1)    :  /u01/install/APPS/fs1
Patch File System ( FS2)  :  /u01/install/APPS/fs2
Non-Editioned File System (fs_ne) : /u01/install/APPS/fs_ne
APPL_TOP 1                :  /u01/install/APPS/fs1/EBSapps
APPL_TOP 2                :  /u01/install/APPS/fs2/EBSapps
FMW_HOME 1                :  /u01/install/APPS/fs1/FMW_Home
FMW_HOME 2                :  /u01/install/APPS/fs2/FMW_Home
INST_TOP 1                :  /u01/install/APPS/fs1/inst
INST_TOP 2                :  /u01/install/APPS/fs2/inst

Section 5.2.2.1: Perform Sanity Tests On the Primary Application Tier Node

Sign on to Oracle E-Business Suite Application
Choose a forms responsibility and launch forms
Login to the WebLogic console and fusion middleware console using the WebLogic admin credentials
Submit concurrent requests to make sure the concurrent requests can be executed and their output/log can be viewed from the client.
Start and stop the application tier processes from the current run file system. The processes must be started on the primary application tier node first followed by the secondary application tier nodes. The application tier processes can be started/stopped using the adstrtal.sh/adstpall.sh script from the <INST_TOP>/admin/scripts directory.
Execute an empty online patching cycle using the online patching utility adop. An empty patching cycle can be executed from the run edition file system by following the instructions given in the table below.

Primary Application Tier


APPLICATION TIER HOSTNAME : finance.example.net
INSTALL BASE              :  /u01/install/APPS
Run File System ( FS1)    :  /u01/install/APPS/fs1
Patch File System ( FS2)  :  /u01/install/APPS/fs2
INST_TOP 1                :  /u01/install/APPS/fs1/inst
INST_TOP 2                :  /u01/install/APPS/fs2/inst
LOCATION OF THE RUN CONTEXT_FILE : /u01/install/APPS/fs1/inst/apps/VISION_finance/appl/admin/VISION_finance.xml
LOCATION OF THE PATCH CONTEXT_FILE : /u01/install/APPS/fs2/inst/apps/VISION_finance/appl/admin/VISION_finance.xml


Source the Run Edition Environment file
$ . ./u01/install/APPS/EBSapps.env run

$ adop phase=prepare

$ adop phase=cutover

Section 5.2.2.2: Perform Required Context File Updates On the run and patch edition File System

The topology described in Section 2.3: DMZ Configuration with Internal and External Application Tiers in the Intranet Sharing the Application Tier File System assume that all application tier nodes share the same file system. This requires the applications context variable "s_atName" to be same across all the application tier nodes in both run and patch edition application context files. The value of the variable s_atName is defaulted to the hostname of the primary application tier node. In addition to setting the s_atName to the hostname of the primary application tier, the value of the applications context variable " s_shared_file_system" also need to be set to true if not already set. An example is provided in the following table..

Primary Application Tier


APPLICATION TIER HOSTNAME : finance.example.net
INSTALL BASE              :  /u01/install/APPS
Run File System ( FS1)    :  /u01/install/APPS/fs1
Patch File System ( FS2)  :  /u01/install/APPS/fs2
Non-Editioned File System (fs_ne) : /u01/install/APPS/fs_ne
INST_TOP 1                :  /u01/install/APPS/fs1/inst
INST_TOP 2                :  /u01/install/APPS/fs2/inst
LOCATION OF THE RUN CONTEXT_FILE : /u01/install/APPS/fs1/inst/apps/VISION_finance/appl/admin/VISION_finance.xml
LOCATION OF THE PATCH CONTEXT_FILE : /u01/install/APPS/fs2/inst/apps/VISION_finance/appl/admin/VISION_finance.xml

CONTEXT VARIABLES TO BE REVIEWED/CHANGED

<APPL_TOP_NAME oa_var="s_atName">finance</APPL_TOP_NAME>
<shared_file_system oa_var="s_shared_file_system">true</shared_file_system>

Section 5.2.2.3: Configure a Load Balancer Infront of the Primary Application Tier Node

Oracle E-Business Suite multi-node configuration require an external load balancer in front of the application tier nodes to load balance the http traffic from the clients. This requires the Oracle E-Business Suite application tier nodes to be aware of the load balancing device. If you have such a configuration, ensure that the following required application tier context file variables are updated. Please note that context file update need to be Performed on both the run and patch edition file system application context file. An example is provided in the following table.

Primary Application Tier


APPLICATION TIER HOSTNAME : finance.example.net
INSTALL BASE              :  /u01/install/APPS
Run File System ( FS1)    :  /u01/install/APPS/fs1
Patch File System ( FS2)  :  /u01/install/APPS/fs2
Non-Editioned File System (fs_ne) : /u01/install/APPS/fs_ne
INST_TOP 1                :  /u01/install/APPS/fs1/inst
INST_TOP 2                :  /u01/install/APPS/fs2/inst
LOCATION OF THE RUN CONTEXT_FILE : /u01/install/APPS/fs1/inst/apps/VISION_finance/appl/admin/VISION_finance.xml
LOCATION OF THE PATCH CONTEXT_FILE : /u01/install/APPS/fs2/inst/apps/VISION_finance/appl/admin/VISION_finance.xml


LBR CONFIGURATION

LBR WEBENTRY PROTOCOL : http
LBR HOSTNAME : employees
LBR DOMAINNAME : example.net
LBR ENTRYPORT : 80


CONTEXT VARIABLES TO BE CHANGED FOR THE ABOVE LBR CONFIGURATION

<webentryurlprotocol oa_var="s_webentryurlprotocol">http</webentryurlprotocol>

<webentryhost oa_var="s_webentryhost">employees</webentryhost>

<webentrydomain oa_var="s_webentrydomain">example.net</webentrydomain>

<activewebport oa_var="s_active_webport">80</activewebport>

<login_page oa_var="s_login_page">http://employees.example.net:80/OA_HTML/AppsLogin</login_page>


<EndUserMonitoringURL oa_var="s_endUserMonitoringURL">http://employees.example.net:80/oracle_smp_chronos/oracle_smp_chronos_sdk.gif</EndUserMonitoringURL>

<externURL oa_var="s_external_url">http://employees.example.net:80/OA_HTML/AppsLogin</externURL>

Section 5.2.2.4: Execute AutoConfig On the Primary Application Tier Node

Perform the following steps on the primary application tier node.

Primary Application Tier


APPLICATION TIER HOSTNAME : finance.example.net
INSTALL BASE              :  /u01/install/APPS
Run File System ( FS1)    :  /u01/install/APPS/fs1
Patch File System ( FS2)  :  /u01/install/APPS/fs2
Non-Editioned File System (fs_ne) : /u01/install/APPS/fs_ne
INST_TOP 1                :  /u01/install/APPS/fs1/inst
INST_TOP 2                :  /u01/install/APPS/fs2/inst
LOCATION OF THE RUN CONTEXT_FILE : /u01/install/APPS/fs1/inst/apps/VISION_finance/appl/admin/VISION_finance.xml
LOCATION OF THE PATCH CONTEXT_FILE : /u01/install/APPS/fs2/inst/apps/VISION_finance/appl/admin/VISION_finance.xml


Execute Autoconfig on the run file system
$ . ./u01/install/APPS/EBSapps.env run

$ $INST_TOP/admin/scripts/adautocfg.sh

Upload the Patch file system context file to the Database

$ . ./u01/install/APPS/EBSapps.env patch

$ $ADJVAPRG oracle.apps.ad.autoconfig.oam.CtxSynchronizer action=upload
contextfile=<full path to patch context file> logfile=/tmp/patchctxupload.log

Please note there is no need to execute autoconfig on the patch file system.

Section 5.2.2.5: Update the Hirearchy Type

Perform the following steps on the primary application tier node or the master node. See Section 4.1: Update Hierarchy Type for more information.

Primary Application Tier


APPLICATION TIER HOSTNAME : finance.example.net
INSTALL BASE              :  /u01/install/APPS
Run File System ( FS1)    :  /u01/install/APPS/fs1
Patch File System ( FS2)  :  /u01/install/APPS/fs2
Non-Editioned File System (fs_ne) : /u01/install/APPS/fs_ne
INST_TOP 1                :  /u01/install/APPS/fs1/inst
INST_TOP 2                :  /u01/install/APPS/fs2/inst
LOCATION OF THE RUN CONTEXT_FILE : /u01/install/APPS/fs1/inst/apps/VISION_finance/appl/admin/VISION_finance.xml
LOCATION OF THE PATCH CONTEXT_FILE : /u01/install/APPS/fs2/inst/apps/VISION_finance/appl/admin/VISION_finance.xml


Source the Run Edition Environment file
$ . ./u01/install/APPS/EBSapps.env run

Switch the hirearchy type of the profile options to be of type server-responsibility

$ sqlplus apps/apps @$FND_TOP/patch/115/sql/txkChangeProfH.sql SERVRESP

Section 5.2.2.6: Execute Adpreclone Utility On the run and patch edition File System

The adpreclone utility shipped with Oracle E-Business Suite package the required application tier components to a staging directory for subsequent clone and add node operations. You must run this utility before proceeding to the later section of this document.

The adpreclone utility requires the WebLogic Administration process to be running from the file system where the utility is run. This is required to package the Oracle Fusion Middleware components and its configuration. Perform the commands shown below on both the run and patch edition file systems:

Primary Application Tier


APPLICATION TIER HOSTNAME : finance.example.net
INSTALL BASE              :  /u01/install/APPS
Run File System ( FS1)    :  /u01/install/APPS/fs1
Patch File System ( FS2)  :  /u01/install/APPS/fs2
Non-Editioned File System (fs_ne) : /u01/install/APPS/fs_ne
INST_TOP 1                :  /u01/install/APPS/fs1/inst
INST_TOP 2                :  /u01/install/APPS/fs2/inst
LOCATION OF THE RUN CONTEXT_FILE : /u01/install/APPS/fs1/inst/apps/VISION_finance/appl/admin/VISION_finance.xml
LOCATION OF THE PATCH CONTEXT_FILE : /u01/install/APPS/fs2/inst/apps/VISION_finance/appl/admin/VISION_finance.xml


Source the Run file system env file
$ . ./u01/install/APPS/EBSapps.env run

$ $INST_TOP/admin/scripts/adadminsrvctl.sh start

$ $INST_TOP/admin/scripts/adpreclone.pl appsTier

$ $INST_TOP/admin/scripts/adadminsrvctl.sh stop

$ $INST_TOP/admin/scripts/adnodemgrctl.sh stop

Source the Patch file system env file

$ . ./u01/install/APPS/EBSapps.env patch
$ $INST_TOP/admin/scripts/adadminsrvctl.sh start forcepatchfs

$ $INST_TOP/admin/scripts/adpreclone.pl appsTier

$ $INST_TOP/admin/scripts/adadminsrvctl.sh stop

$ $INST_TOP/admin/scripts/adnodemgrctl.sh stop

Section 5.2.2.7: Add the Secondary Application Tier Nodes Using Shared File System

The tasks listed in this section assume that you have completed all the steps listed above in this section. It is important that you review the configuration before proceeding with the steps given below. The node to be added now will be known as the secondary application tier node or the slave node. This node can be configured to run all services except for the Oracle WebLogic Administration Server.

Note:

The fully qualified hostname of the application tier node to be added must be present in the sqlnet.ora file in the <Database_Oracle_ Home>/network/admin<context-name> directory if it exists. (See tcp.invited_nodes parameter)
The database and TNS listener must be running.
In a shared file system, User ID and group ID should be consistent across all nodes to avoid file access permission issues.
The same absolute path must be used for the shared file system mount points on each node.
Ensure that value of the AutoConfig variable "s_atName" is set to the hostname of the primary application tier node.
Ensure that value of the AutoConfig variable " s_shared_file_system" is set to "true" ( without the quote) on the primary application tier node. This variable will be automatically set to "true" if the shared file system option was chosen during the Rapid Install.
The fully qualified hostname of the application tier nodes that you are going to add must be resolvable from the primary application tier node and vice versa either via the Domain Naming System (DNS) or file based resolution.
Every application tier node must have a valid oraInst.loc file in the respective directory ( see Oracle Universal Intaller guide for platform specific location) pointing to a global inventory location. The default location for the Linux platform is /etc directory.

Section 5.2.2.8: Export the Required Application Tier File System From the Primary Application Tier Node

Follow the instructions given below to export the required application tier file system from the primary application tier node.

Primary Application Tier


APPLICATION TIER HOSTNAME : finance.example.net
INSTALL BASE              :  /u01/install/APPS
LOCATION OF THE INVENTORY : /u01/install/OraInventory

On a Linux system, execute the following commands as the root user to mount the application tier file system to the secondary nodes. The export options described below may need to be adjusted per security requirements of your company. Also, the available export options may differ on other platforms.

Add the following lines to the /etc/exports file

/u01/install/APPS procurement.example.net(rw,sync,no_root_squash)
/u01/install/APPS supplier.example.com(rw,sync,no_root_squash)
/u01/install/APPS sourcing.example.com(rw,sync,no_root_squash)
/u01/install/OraInventory procurement.example.net(rw,sync,no_root_squash)
/u01/install/OraInventory supplier.example.com(rw,sync,no_root_squash)
/u01/install/OraInventory sourcing.example.com(rw,sync,no_root_squash)

Check whether the NFS daemons are running:

$ /sbin/service nfs status

If the NFS daemons are not running, execute the following command to start them:

$ /sbin/service nfs start

Once the NFS daemons are running, execute the following command to export the application tier file system:

$ /usr/sbin/exportfs -a

Ensure the application tier file systems are exported by executing the following command:

$ /usr/sbin/exportfs

Section 5.2.2.9: Mount the Required Application Tier File System to the Secondary Application Tier Nodes

Follow the instructions given below to mount the required application tier file system to the secondary application tier nodes.

APPLICATION TIER HOST FROM WHERE FILE SYSTEM IS EXPORTED : finance.example.net
APPLICATION TIER HOSTS TO WHICH FILE SYSTEM NEED TO BE MOUNTED : procurement.example.net,supplier.example.com,sourcing.example.com

The following application tier file system need to be mounted on the secondary application tier node from the primary node.

INSTALL BASE              :  /u01/install/APPS
LOCATION OF THE INVENTORY : /u01/install/OraInventory

Check whether the NFS daemons are running:

$ /sbin/service nfs status

If the NFS daemons are not running, execute the following command to start them:

$ /sbin/service nfs start

Create directories as follows on all secondary application tier nodes$ /bin/mkdir -p /u01/install/APPS
$ /bin/mkdir -p /u01/install/OraInventory


Change the ownership and group permissions of these directories to be the same as that of the primary application tier node. For example if oracle is the owner of the file system and is in the group dba, you need to execute the commands shown below:$ /bin/chown -R /u01/install/APPS
$ /bin/chown -R /u01/install/oraInventory
$ /bin/chgrp -R dba /u01/install/APPS
$ /bin/chgrp -R dba /u01/install/oraInventory

Use the following commands to mount the application tier file system from the primary node to the secondary application tier nodes:
$ cd /u01/install/APPS
$ /bin/mount -t nfs -o rw,nointr,bg,hard,timeo=600,wsize=65536,rsize=65536,nfsvers=3,tcp finance.example.net:/u01/install/APPS .
$ cd /u01/install/oraInventory
$ /bin/mount -t nfs -o rw,nointr,bg,hard,timeo=600,wsize=65536,rsize=65536,nfsvers=3,tcp finance.example.net:/u01/install/oraInventory .

Add the remote file system to /etc/fstab so that file system are automatically mounted on the secondary application tier on boot:$ vi /etc/fstab
add the following lines to fstabfinance.example.net:/u01/install/APPS /u01/install/APPS nfs rw,nointr,bg,hard,timeo=660,wsize=65536.rsize=65536,nfsvers=3,tcp 0 0
finance.example.net:/u01/install/oraInventory /u01/install/oraInventory nfs rw,nointr,bg,hard,timeo=660,wsize=65536.rsize=65536,nfsvers=3,tcp 0 0



Please note that nfs version used here is V3 . Customers can also configure the mounted file system to use NFS V4.

Section 5.2.2.10: Prepare the Pairs File for Addition Of the Secondary Application Tier Nodes

The primary decision that an administrator needs to make before proceeding with the steps given below is to decide which services need to be configured on the secondary application tier nodes. The new node that you are planning to add can run any service except for the WebLogic Administration Server, which is only configured on the primary application tier node. Follow the steps given below to prepare the pairs file for adding the secondary application tier nodes.

APPLICATION TIER HOST FROM WHERE FILE SYSTEM IS EXPORTED : finance.example.net
APPLICATION TIER HOSTS TO WHICH FILE SYSTEM NEED TO BE MOUNTED : procurement.example.net,supplier.example.com,sourcing.example.com

APPLICATION TIER HOSTNAMES : procurement.example.net,supplier.example.com,sourcing.example.com
INSTALL BASE              :  /u01/install/APPS
Run File System ( FS1)    :  /u01/install/APPS/fs1
Patch File System ( FS2)  :  /u01/install/APPS/fs2
INST_TOP 1                :  /u01/install/APPS/fs1/inst
INST_TOP 2                :  /u01/install/APPS/fs2/inst
LOCATION OF THE RUN CONTEXT_FILE : /u01/install/APPS/fs1/inst/apps/VISION_finance/appl/admin/VISION_finance.xml
LOCATION OF THE PATCH CONTEXT_FILE : /u01/install/APPS/fs2/inst/apps/VISION_finance/appl/admin/VISION_finance.xml

Prepare the pairs file for configuring the run file system

A sample pairs file for the run file system is instantiated into the relevant instance home on the primary application tier node . The name of the file is <SID>_<primary_node_name>_<file_edition_type>.txt, located in the <INST_TOP>/appl/admin/ directory. For example : for the configuration described in this case study, the file name is /u01/install/APPS/fs1/inst/apps/VISION_finance/appl/admin/VISION_finance_run.txt

Create the required following directories, then copy the pairs file into a directory of your choice for each of the application tier nodes. For example:$ mkdir -p /u01/install/APPS/pairs/procurement
$ mkdir -p /u01/install/APPS/pairs/supplier
$ mkdir -p /u01/install/APPS/pairs/sourcing
$ cp /u01/install/APPS/fs1/inst/apps/VISION_finance/appl/admin/VISION_finance_run.txt /u01/install/APPS/pairs/procurement
$ cp /u01/install/APPS/fs1/inst/apps/VISION_finance/appl/admin/VISION_finance_run.txt /u01/install/APPS/pairs/supplier
$ cp /u01/install/APPS/fs1/inst/apps/VISION_finance/appl/admin/VISION_finance_run.txt /u01/install/APPS/pairs/sourcing


Review and update the pairs file that was copied for each of the application tier nodes. The parameters that need to be filled are under the sections [Instance Specific] and [Services] . The pairs file has detailed instructions on how to fill the appropriate values.For example for the node procurement, you would fill in the required parameters as shown below:

[Web Entry Point Configuration]s_webentryurlprotocol=http
s_webentryhost=employees
s_webentrydomain=example.net
s_active_webport=80
s_endUserMonitoringURL=http://employees.example.net:80/oracle_smp_chronos/oracle_smp_chronos_sdk.gif
s_external_url=http://employees.example.net:80
s_login_page=http://employees.example.net:80/OA_HTML/AppsLogin

[Instance Specific]
s_temp=/u01/install/APPS/fs1/inst/apps/VISION_procurement/temp
s_contextname=VISION_procurement
s_hostname=procurement
s_domainname=example.net
s_cphost=finance
s_webhost=procurement
s_config_home=/u01/install/APPS/fs1/inst/apps/VISION_procurement
s_display=localhost:0.0
s_forms-c4ws_display=procurement:0.0
s_ohs_instance=EBS_web_VISION_OHS2

[Services To be Enabled on the Secondary Application Tier Node]
s_web_applications_status=enabled
s_web_entry_status=enabled
s_apcstatus=enabled
s_root_status=enabled
s_batch_status=disabled
s_other_service_group_status=disabled
s_adminserverstatus=disabled




For example for the node supplier, you would fill in the required parameters as shown below.

[Web Entry Point Configuration]s_webentryurlprotocol=https
s_webentryhost=partners
s_webentrydomain=example.com
s_active_webport=443
s_endUserMonitoringURL=https://partners.example.com:443/oracle_smp_chronos/oracle_smp_chronos_sdk.gif
s_external_url=https://partners.example.com:443
s_login_page=https://partners.example.com:443/OA_HTML/AppsLogin


[Instance Specific]
s_temp=/u01/install/APPS/fs1/inst/apps/VISION_supplier/temp
s_contextname=VISION_supplier
s_hostname=supplier
s_domainname=example.com
s_cphost=finance
s_webhost=supplier
s_config_home=/u01/install/APPS/fs1/inst/apps/VISION_supplier
s_display=localhost:0.0
s_forms-c4ws_display=supplier:0.0
s_ohs_instance=EBS_web_VISION_OHS3

[Services To be Enabled on the Secondary Application Tier Node]
s_web_applications_status=enabled
s_web_entry_status=enabled
s_apcstatus=enabled
s_root_status=enabled
s_batch_status=disabled
s_other_service_group_status=disabled
s_adminserverstatus=disabled
For example for the node sourcing, you would fill in the required parameters as shown below. You can notice here that the web entry point configuration is also included in addition because the web entry points for the application tier nodes supplier and sourcing are different when compared to nodes finance and procurement.


[Web Entry Point Configuration]s_webentryurlprotocol=https
s_webentryhost=partners
s_webentrydomain=example.com
s_active_webport=443
s_endUserMonitoringURL=https://partners.example.com:443/oracle_smp_chronos/oracle_smp_chronos_sdk.gif
s_external_url=https://partners.example.com:443
s_login_page=https://partners.example.com:443/OA_HTML/AppsLogin


[Instance Specific]
s_temp=/u01/install/APPS/fs1/inst/apps/VISION_sourcing/temp
s_contextname=VISION_sourcing
s_hostname=sourcing
s_domainname=example.com
s_cphost=finance
s_webhost=sourcing
s_config_home=/u01/install/APPS/fs1/inst/apps/VISION_sourcing
s_display=localhost:0.0
s_forms-c4ws_display=sourcing:0.0
s_ohs_instance=EBS_web_VISION_OHS4

[Services To be Enabled on the Secondary Application Tier Node]
s_web_applications_status=enabled
s_web_entry_status=enabled
s_apcstatus=enabled
s_root_status=enabled
s_batch_status=disabled
s_other_service_group_status=disabled
s_adminserverstatus=disabled

Prepare the pairs file for configuring the patch file system

A sample pairs file for the patch file system is instantiated into the relevant instance home on the primary application tier node . The name of the file is <SID>_<primary_node_name>_<file_edition_type>.txt, located in the <INST_TOP>/appl/admin/ directory. For example : for the configuration described in this case study, the file name is /u01/install/APPS/fs2/inst/apps/VISION_finance/appl/admin/VISION_finance_patch.txt

Copy the pairs file to the following directories For example:$ cp /u01/install/APPS/fs2/inst/apps/VISION_finance/appl/admin/VISION_finance_patch.txt /u01/install/APPS/pairs/procurement
$ cp /u01/install/APPS/fs2/inst/apps/VISION_finance/appl/admin/VISION_finance_patch.txt /u01/install/APPS/pairs/supplier
$ cp /u01/install/APPS/fs2/inst/apps/VISION_finance/appl/admin/VISION_finance_patch.txt /u01/install/APPS/pairs/sourcing


Review and update the pairs file that was copied for each of the application tier nodes. The parameters that need to be filled are under the sections [Instance Specific] and [Services] . The pairs file has detailed instructions on how to fill the appropriate values.For example for the node procurement, you would fill in the required parameters as shown below:

[Web Entry Point Configuration]s_webentryurlprotocol=http
s_webentryhost=employees
s_webentrydomain=example.net
s_active_webport=80
s_endUserMonitoringURL=http://employees.example.net:80/oracle_smp_chronos/oracle_smp_chronos_sdk.gif
s_external_url=http://employees.example.net:80
s_login_page=http://employees.example.net:80/OA_HTML/AppsLogin


[Instance Specific]
s_temp=/u01/install/APPS/fs2/inst/apps/VISION_procurement/temp
s_contextname=VISION_procurement
s_hostname=procurement
s_domainname=example.net
s_cphost=finance
s_webhost=procurement
s_config_home=/u01/install/APPS/fs2/inst/apps/VISION_procurement
s_display=localhost:0.0
s_forms-c4ws_display=procurement:0.0
s_ohs_instance=EBS_web_VISION_OHS2

[Services To be Enabled on the Secondary Application Tier Node]
s_web_applications_status=enabled
s_web_entry_status=enabled
s_apcstatus=enabled
s_root_status=enabled
s_batch_status=disabled
s_other_service_group_status=disabled
s_adminserverstatus=disabled




For example for the node supplier, you would fill in the required parameters as shown below.

[Web Entry Point Configuration]s_webentryurlprotocol=https
s_webentryhost=partners
s_webentrydomain=example.com
s_active_webport=443
s_endUserMonitoringURL=https://partners.example.com:443/oracle_smp_chronos/oracle_smp_chronos_sdk.gif
s_external_url=https://partners.example.com:443
s_login_page=https://partners.example.com:443/OA_HTML/AppsLogin


[Instance Specific]
s_temp=/u01/install/APPS/fs2/inst/apps/VISION_supplier/temp
s_contextname=VISION_supplier
s_hostname=supplier
s_domainname=example.com
s_cphost=finance
s_webhost=supplier
s_config_home=/u01/install/APPS/fs2/inst/apps/VISION_supplier
s_display=localhost:0.0
s_forms-c4ws_display=supplier:0.0
s_ohs_instance=EBS_web_VISION_OHS3

[Services To be Enabled on the Secondary Application Tier Node]
s_web_applications_status=enabled
s_web_entry_status=enabled
s_apcstatus=enabled
s_root_status=enabled
s_batch_status=disabled
s_other_service_group_status=disabled
s_adminserverstatus=disabled
For example for the node sourcing, you would fill in the required parameters as shown below. You can notice here that the web entry point configuration is also included in addition because the web entry points for the application tier nodes supplier and sourcing are different when compared to nodes finance and procurement.


[Web Entry Point Configuration]s_webentryurlprotocol=https
s_webentryhost=partners
s_webentrydomain=example.com
s_active_webport=443
s_endUserMonitoringURL=https://partners.example.com:443/oracle_smp_chronos/oracle_smp_chronos_sdk.gif
s_external_url=https://partners.example.com:443
s_login_page=https://partners.example.com:443/OA_HTML/AppsLogin


[Instance Specific]
s_temp=/u01/install/APPS/fs2/inst/apps/VISION_sourcing/temp
s_contextname=VISION_sourcing
s_hostname=sourcing
s_domainname=example.com
s_cphost=finance
s_webhost=sourcing
s_config_home=/u01/install/APPS/fs2/inst/apps/VISION_sourcing
s_display=localhost:0.0
s_forms-c4ws_display=sourcing:0.0
s_ohs_instance=EBS_web_VISION_OHS4

[Services To be Enabled on the Secondary Application Tier Node]
s_web_applications_status=enabled
s_web_entry_status=enabled
s_apcstatus=enabled
s_root_status=enabled
s_batch_status=disabled
s_other_service_group_status=disabled
s_adminserverstatus=disabled

Section 5.2.2.11: Prepare the Required Scripts for Adding the Secondary Application Tier Nodes

PRIMARY APPLICATION TIER NODE : finance.example.net
SECONDARY APPLICATION TIER NODES : procurement.example.net,supplier.example.com,sourcing.example.com
INSTALL BASE              :  /u01/install/APPS
Run File System ( FS1)    :  /u01/install/APPS/fs1
Patch File System ( FS2)  :  /u01/install/APPS/fs2
INST_TOP 1                :  /u01/install/APPS/fs1/inst
INST_TOP 2                :  /u01/install/APPS/fs2/inst
LOCATION OF THE RUN CONTEXT_FILE : /u01/install/APPS/fs1/inst/apps/VISION_finance/appl/admin/VISION_finance.xml
LOCATION OF THE PATCH CONTEXT_FILE : /u01/install/APPS/fs2/inst/apps/VISION_finance/appl/admin/VISION_finance.xml

Create the following scripts for each node in their corresponding directories . For example for the procurement node in /u01/install/APPS/pairs/procurementaddprocurementrun.sh

export PATH=/u01/install/APPS/fs1/FMW_Home/webtier/perl/bin:$PATH
cd /u01/install/APPS/fs1/EBSapps/comn/clone/bin
perl ./adclonectx.pl addnode contextfile=/u01/install/APPS/fs1/inst/apps/VISION_finance/appl/admin/VISION_finance.xml \ pairsfile=/u01/install/APPS/pairs/procurement/pairs/VISION_finance_run.txt \ outfile=/u01/install/APPS/fs1/inst/apps/VISION_procurement/appl/admin/VISION_procurement.xml


addprocurementpatch.sh

export PATH=/u01/install/APPS/fs2/FMW_Home/webtier/perl/bin:$PATH
cd /u01/install/APPS/fs2/EBSapps/comn/clone/bin
perl ./adclonectx.pl addnode contextfile=/u01/install/APPS/fs2/inst/apps/VISION_finance/appl/admin/VISION_finance.xml \ pairsfile=/u01/install/APPS/pairs/procurement/pairs/VISION_finance_patch.txt \ outfile=/u01/install/APPS/fs2/inst/apps/VISION_procurement/appl/admin/VISION_procurement.xml
For example for the sourcing node create the following scripts in /u01/install/APPS/pairs/sourcing
addsourcingrun.sh

export PATH=/u01/install/APPS/fs1/FMW_Home/webtier/perl/bin:$PATH
cd /u01/install/APPS/fs1/EBSapps/comn/clone/bin
perl ./adclonectx.pl addnode contextfile=/u01/install/APPS/fs1/inst/apps/VISION_finance/appl/admin/VISION_finance.xml \ pairsfile=/u01/install/APPS/pairs/sourcing/pairs/VISION_finance_run.txt \
outfile=/u01/install/APPS/fs1/inst/apps/VISION_sourcing/appl/admin/VISION_sourcing.xml

addsourcingpatch.sh

export PATH=/u01/install/APPS/fs2/FMW_Home/webtier/perl/bin:$PATH
cd /u01/install/APPS/fs2/EBSapps/comn/clone/bin
perl ./adclonectx.pl addnode contextfile=/u01/install/APPS/fs2/inst/apps/VISION_finance/appl/admin/VISION_finance.xml \ pairsfile=/u01/install/APPS/pairs/sourcing/pairs/VISION_finance_patch.txt \
outfile=/u01/install/APPS/fs2/inst/apps/VISION_sourcing/appl/admin/VISION_sourcing.xml


For example for the supplier node create the following scripts in /u01/install/APPS/pairs/supplier
addsupplierrun.sh

export PATH=/u01/install/APPS/fs1/FMW_Home/webtier/perl/bin:$PATH
cd /u01/install/APPS/fs1/EBSapps/comn/clone/bin
perl ./adclonectx.pl addnode contextfile=/u01/install/APPS/fs1/inst/apps/VISION_finance/appl/admin/VISION_finance.xml \ pairsfile=/u01/install/APPS/pairs/supplier/pairs/VISION_finance_run.txt \
outfile=/u01/install/APPS/fs1/inst/apps/VISION_supplier/appl/admin/VISION_supplier.xml

addsupplierpatch.sh

export PATH=/u01/install/APPS/fs2/FMW_Home/webtier/perl/bin:$PATH
cd /u01/install/APPS/fs2/EBSapps/comn/clone/bin
perl ./adclonectx.pl addnode contextfile=/u01/install/APPS/fs2/inst/apps/VISION_finance/appl/admin/VISION_finance.xml \ pairsfile=/u01/install/APPS/pairs/supplier/pairs/VISION_finance_patch.txt \
outfile=/u01/install/APPS/fs2/inst/apps/VISION_supplier/appl/admin/VISION_supplier.xml

Section 5.2.2.12: Add the secondary application tier nodes to the farm

Note: You must ensure that the WebLogic Administration Server is running from both the run and patch edition file system on the primary application tier node before proceeding with the steps given below. You can check the status of the Weblogic Administration Server for both the run and patch edition file system by executing the command <INST_TOP>/admin/scripts/adadminsrvctl.sh status

Seconday Application Tier Nodes

SECONDARY APPLICATION TIER NODES : procurement.example.net,supplier.example.com,sourcing.example.com
INSTALL BASE              :  /u01/install/APPS
Run File System ( FS1)    :  /u01/install/APPS/fs1
Patch File System ( FS2)  :  /u01/install/APPS/fs2
INST_TOP 1                :  /u01/install/APPS/fs1/inst
INST_TOP 2                :  /u01/install/APPS/fs2/inst
LOCATION OF THE RUN CONTEXT_FILE : /u01/install/APPS/fs1/inst/apps/VISION_finance/appl/admin/VISION_finance.xml
LOCATION OF THE PATCH CONTEXT_FILE : /u01/install/APPS/fs2/inst/apps/VISION_finance/appl/admin/VISION_finance.xml

Login to the secondary application tier nodes and execute the scripts to add the run and patch edition file system. The scripts must be executed in serial mode on all the nodes for the run file system followed by patch. Complete one node first before proceeding to the next.

For example:Logon to the procurement.example.net node, execute$ sh /u01/install/APPS/pairs/procurement/addprocurementrun.sh
$ sh /u01/install/APPS/pairs/procurement/addprocurementpatch.sh

Logon to the supplier.example.com node, execute$ sh /u01/install/APPS/pairs/supplier/addsupplierrun.sh
$ sh /u01/install/APPS/pairs/supplier/addsupplierpatch.sh

Logon to the sourcing.example.com node, execute$ sh /u01/install/APPS/pairs/supplier/addsourcingrun.sh
$ sh /u01/install/APPS/pairs/supplier/addsoucingpatch.sh


verify the EBSprovisioner.log file created in either the current directory or /u01/install/APPS/fs2/EBSapps/comn/clone/bin for any errors

Section 5.2.2.13: Sync Up the Context File and Update Configuration On All Nodes

Follow the instructions given below on all application tier nodes to sync up the context file and configuration files.

PRIMARY APPLICATION TIER NODE : finance.example.net

SECONDARY APPLICATION TIER NODES : procurement.example.net,supplier.example.com,sourcing.example.com

Login to all the application tier nodes and execute the the following scripts to sync up the context file and configuration files for the run file systemSource the EBSapps.env file$ . ./u01/install/APPS/EBSapps.env run
$ perl $AD_TOP/bin/adSyncContext.pl contextfile=$CONTEXT_FILE

The following command syntax works with AD/TXK Code Level D4 .
$ perl $FND_TOP/patch/115/bin/txkSetAppsConf.pl -ctxfile=$CONTEXT_FILE -outfile=$APPLRGF/TXK/conf.log

If you are a later version of the AD/TXK Code level, follow the instructions given in section 5.3.2.4-5.3.2.7 ( Register the new topology from the newly added application tier node) of My Oracle Support Document 1383621.1, Cloning Oracle E-Business Suite Release 12.2 with Rapid Clone, to register the new topology.

Execute AutoConfig on all application tier nodes

Login to all the application tier nodes and execute the the following scripts to sync up the context file and configuration files for the patch file systemSource the EBSapps.env file$ . ./u01/install/APPS/EBSapps.env patch
$ perl $AD_TOP/bin/adSyncContext.pl contextfile=$CONTEXT_FILE

The following command syntax works with AD/TXK Code Level D4 .
$ perl $FND_TOP/patch/115/bin/txkSetAppsConf.pl -ctxfile=$CONTEXT_FILE -outfile=$APPLRGF/TXK/conf.log

If you are a later version of the AD/TXK Code level, follow the instructions given in section 5.3.2.4-5.3.2.7 ( Register the new topology from the newly added application tier node) of My Oracle Support Document 1383621.1, Cloning Oracle E-Business Suite Release 12.2 with Rapid Clone, to register the new topology.

Section 5.2.2.14: Perform Sanity Tests on All Application Tier Nodes

Perform the following sanity tests to check the health of the multi-node application tier system.

Start and stop the application tier processes from the current run file system. The processes must be started on the primary application tier node first followed by the secondary application tier nodes. The application tier processes can be started/stopped using the adstrtal.sh/adstpall.sh script from the <INST_TOP>/admin/scripts directory.
Sign on to Oracle E-Business Suite application from the multiple web entry points.
Choose a forms responsibility and launch forms.
Login to the WebLogic console and fusion middleware console using the WebLogic admin credentials. Make sure you can view all the managed servers in RUNNING status from the servers menu.
Submit concurrent requests to make sure the concurrent requests can be executed and their output/log can be viewed from the client.
Execute an empty online patching cycle using the online patching utility adop. An empty patching cycle can be executed from the run edition file system by following the instructions given in the table below.

Primary Application Tier


APPLICATION TIER HOSTNAME : finance.example.net
INSTALL BASE              :  /u01/install/APPS
Run File System ( FS1)    :  /u01/install/APPS/fs1
Patch File System ( FS2)  :  /u01/install/APPS/fs2
INST_TOP 1                :  /u01/install/APPS/fs1/inst
INST_TOP 2                :  /u01/install/APPS/fs2/inst
LOCATION OF THE RUN CONTEXT_FILE : /u01/install/APPS/fs1/inst/apps/VISION_finance/appl/admin/VISION_finance.xml
LOCATION OF THE PATCH CONTEXT_FILE : /u01/install/APPS/fs2/inst/apps/VISION_finance/appl/admin/VISION_finance.xml


Source the Run Edition Environment file
$ . ./u01/install/APPS/EBSapps.env run

$ adop phase=prepare

$ adop phase=cutover

Section 5.3: DMZ Configuration with Multilple Internal/External Application Tiers in the Intranet and DMZ

This section explains how to deploy the Oracle E-Business Suite 12.2 in a DMZ configuration with multiple internal application tier nodes configured in the intranet sharing a common application tier file system and multiple external application tier nodes configured in the DMZ sharing another file system that is different from the one shared by the internal application tier nodes. The architecture diagram shown below epresents this setup .

The topology shown above assume the following configuration:

Database Tier

DB HOSTNAME              :  db.example.net
INSTALL BASE              :  /u01/install/VISIONDB ORACLE_HOME            :  /u01/install/VISION/11.2.0
DBF  Files                :  /u01/install/VISION/data
SID : VISION

Primary Application Tier


APPLICATION TIER HOSTNAME : finance.example.net
NODE_TYPE : Internal
INSTALL BASE              :  /u01/install/APPS
Run File System ( FS1)    :  /u01/install/APPS/fs1
Patch File System ( FS2)  :  /u01/install/APPS/fs2
Non-Editioned File System (fs_ne) : /u01/install/APPS/fs_ne
APPL_TOP 1                :  /u01/install/APPS/fs1/EBSapps
APPL_TOP 2                :  /u01/install/APPS/fs2/EBSapps
FMW_HOME 1                :  /u01/install/APPS/fs1/FMW_Home
FMW_HOME 2                :  /u01/install/APPS/fs2/FMW_Home
INST_TOP 1                :  /u01/install/APPS/fs1/inst
INST_TOP 2                :  /u01/install/APPS/fs2/inst
.

APPLICATION TIER HOSTNAME : procurement.example.net
NODE_TYPE : Internal
INSTALL BASE              :  /u01/install/APPS
Run File System ( FS1)    :  /u01/install/APPS/fs1
Patch File System ( FS2)  :  /u01/install/APPS/fs2Non-Editioned File System (fs_ne) : /u01/install/APPS/fs_ne
APPL_TOP 1                :  /u01/install/APPS/fs1/EBSapps
APPL_TOP 2                :  /u01/install/APPS/fs2/EBSapps
FMW_HOME 1                :  /u01/install/APPS/fs1/FMW_Home
FMW_HOME 2                :  /u01/install/APPS/fs2/FMW_Home
INST_TOP 1                :  /u01/install/APPS/fs1/inst
INST_TOP 2                :  /u01/install/APPS/fs2/inst

procurement.example.net share the application tier file system with finance.example.net

APPLICATION TIER HOSTNAME : supplier.example.com
NODE_TYPE : External
INSTALL BASE              :  /u01/install/APPS
Run File System ( FS1)    :  /u01/install/APPS/fs1
Patch File System ( FS2)  :  /u01/install/APPS/fs2
Non-Editioned File System (fs_ne) : /u01/install/APPS/fs_ne
APPL_TOP 1                :  /u01/install/APPS/fs1/EBSapps
APPL_TOP 2                :  /u01/install/APPS/fs2/EBSapps
FMW_HOME 1                :  /u01/install/APPS/fs1/FMW_Home
FMW_HOME 2                :  /u01/install/APPS/fs2/FMW_Home
INST_TOP 1                :  /u01/install/APPS/fs1/inst
INST_TOP 2                :  /u01/install/APPS/fs2/inst

APPLICATION TIER HOSTNAME : sourcing.example.com
NODE_TYPE : External
INSTALL BASE              :  /u01/install/APPS
Run File System ( FS1)    :  /u01/install/APPS/fs1
Patch File System ( FS2)  :  /u01/install/APPS/fs2
Non-Editioned File System (fs_ne) : /u01/install/APPS/fs_ne
APPL_TOP 1                :  /u01/install/APPS/fs1/EBSapps
APPL_TOP 2                :  /u01/install/APPS/fs2/EBSapps
FMW_HOME 1                :  /u01/install/APPS/fs1/FMW_Home
FMW_HOME 2                :  /u01/install/APPS/fs2/FMW_Home
INST_TOP 1                :  /u01/install/APPS/fs1/inst
INST_TOP 2                :  /u01/install/APPS/fs2/inst

sourcing.example.com share the application tier file system with supplier.example.com

Web Entry Points

INTERNAL WEB ENTRY POINT : http://employees.example.net:80/

EXTERNAL WEB ENTRY POINTS : https://partners.example.com:443/

Section 5.3.1: Required Oracle E-Business Suite Patches

Apply the required Oracle E-Business Suite patches as mentioned in Section 3: Required Patches for DMZ Configuration of this document.

Section 5.3.2: Instructions to Add Additional Application Tier Nodes

The process of implementing a DMZ configuration for your E-Business Suite environment will vary depending on the topology you need for your company. The implementation process described here assume that you have a fully-configured Oracle E-Business Suite Database Tier and a Oracle E-Business Suite primary application tier installed on two separate machines via Rapid Install or Rapid Clone . A two tier configuration as described in this document is the recommended approach for building a DMZ environment. Detailed instruction on how to build a two tier installation from Rapid Install is described in My Oracle Support Document 1375769.1. See section 2, Planning Deployment options, and section 3, Installing a Shared Application Tier File System with 12.2 Rapid Install.

The example given below will guide you through the process of adding the additional application tier nodes for the configuration displayed in the diagram given in Section 2.4: DMZ Configuration with Multiple Internal/External Application Tiers in the Intranet and DMZ of this document.

Existing Configuration

Database Tier

DB HOSTNAME              :  db.example.net
INSTALL BASE             :  /u01/install/VISIONDB ORACLE_HOME           :  /u01/install/VISION/11.2.0
DBF  Files               :  /u01/install/VISION/data
SID : VISION

Primary Application Tier


APPLICATION TIER HOSTNAME : finance.example.net
INSTALL BASE              :  /u01/install/APPS
Run File System ( FS1)    :  /u01/install/APPS/fs1
Patch File System ( FS2)  :  /u01/install/APPS/fs2
Non-Editioned File System (fs_ne) : /u01/install/APPS/fs_ne
APPL_TOP 1                :  /u01/install/APPS/fs1/EBSapps
APPL_TOP 2                :  /u01/install/APPS/fs2/EBSapps
FMW_HOME 1                :  /u01/install/APPS/fs1/FMW_Home
FMW_HOME 2                :  /u01/install/APPS/fs2/FMW_Home
INST_TOP 1                :  /u01/install/APPS/fs1/inst
INST_TOP 2                :  /u01/install/APPS/fs2/inst

Section 5.3.2.1: Perform Sanity Tests on the Primary Application Tier Node

Sign on to Oracle E-Business Suite Application
Choose a forms responsibility and launch forms
Login to the WebLogic console and fusion middleware console using the WebLogic admin credentials
Submit concurrent requests to make sure the concurrent requests can be executed and their output/log can be viewed from the client.
Start and stop the application tier processes from the current run file system. The processes must be started on the primary application tier node first followed by the secondary application tier nodes. The application tier processes can be started/stopped using the adstrtal.sh/adstpall.sh script from the <INST_TOP>/admin/scripts directory.
Execute an empty online patching cycle using the online patching utility adop. An empty patching cycle can be executed from the run edition file system by following the instructions given in the table below.

Primary Application Tier


APPLICATION TIER HOSTNAME : finance.example.net
INSTALL BASE              :  /u01/install/APPS
Run File System ( FS1)    :  /u01/install/APPS/fs1
Patch File System ( FS2)  :  /u01/install/APPS/fs2
INST_TOP 1                :  /u01/install/APPS/fs1/inst
INST_TOP 2                :  /u01/install/APPS/fs2/inst
LOCATION OF THE RUN CONTEXT_FILE : /u01/install/APPS/fs1/inst/apps/VISION_finance/appl/admin/VISION_finance.xml
LOCATION OF THE PATCH CONTEXT_FILE : /u01/install/APPS/fs2/inst/apps/VISION_finance/appl/admin/VISION_finance.xml


Source the Run Edition Environment file
$ . ./u01/install/APPS/EBSapps.env run

$ adop phase=prepare

$ adop phase=cutover

Section 5.3.2.2: Perform Required Context File Updates on the run and patch edition File System

The topology described in Section 2.4: DMZ Configuration with Multiple Internal/External Application Tiers in the Intranet and DMZ of this document assume that the internal and external application tier nodes share the application tier file system among similar node type. For example all internal application tier nodes share one file system and all the external application tiers share another file system. This configuration requires the applications context variable "s_atName" to be same across all the application tier nodes that share the same file system. The value of the variable s_atName will be defaulted to the hostname of the primary internal or external application tier node from where the file system is shared. For example for the configuration described in this section, the value of s_atName and s_shared_file_system will be set as shown below

APPLICATION TIER HOSTNAME : finance.example.net
s_atName : finance
s_shared_file_system : true

APPLICATION TIER HOSTNAME : procurement.example.net
s_atName : finance
s_shared_file_system : true

APPLICATION TIER HOSTNAME : supplier.example.com
s_atName : supplier
s_shared_file_system : true


APPLICATION TIER HOSTNAME : sourcing.example.com
s_atName : supplier
s_shared_file_system : true

Section 5.2.2.3: Configure a Load Balancer Infront of the Primary Application Tier Node

Primary Application Tier


APPLICATION TIER HOSTNAME : finance.example.net
INSTALL BASE              :  /u01/install/APPS
Run File System ( FS1)    :  /u01/install/APPS/fs1
Patch File System ( FS2)  :  /u01/install/APPS/fs2
Non-Editioned File System (fs_ne) : /u01/install/APPS/fs_ne
INST_TOP 1                :  /u01/install/APPS/fs1/inst
INST_TOP 2                :  /u01/install/APPS/fs2/inst
LOCATION OF THE RUN CONTEXT_FILE : /u01/install/APPS/fs1/inst/apps/VISION_finance/appl/admin/VISION_finance.xml
LOCATION OF THE PATCH CONTEXT_FILE : /u01/install/APPS/fs2/inst/apps/VISION_finance/appl/admin/VISION_finance.xml


LBR CONFIGURATION

LBR WEBENTRY PROTOCOL : http
LBR HOSTNAME : employees
LBR DOMAINNAME : example.net
LBR ENTRYPORT : 80


CONTEXT VARIABLES TO BE CHANGED FOR THE ABOVE LBR CONFIGURATION

<webentryurlprotocol oa_var="s_webentryurlprotocol">http</webentryurlprotocol>

<webentryhost oa_var="s_webentryhost">employees</webentryhost>

<webentrydomain oa_var="s_webentrydomain">example.net</webentrydomain>

<activewebport oa_var="s_active_webport">80</activewebport>

<login_page oa_var="s_login_page">http://employees.example.net:80/OA_HTML/AppsLogin</login_page>

<EndUserMonitoringURL oa_var="s_endUserMonitoringURL">http://employees.example.net:80/oracle_smp_chronos/oracle_smp_chronos_sdk.gif</EndUserMonitoringURL>

<externURL oa_var="s_external_url">http://employees.example.net:80/OA_HTML/AppsLogin</externURL>

Section 5.3.2.4: Execute AutoConfig on the Primary Application Tier Node

Perform the following steps on the primary application tier node:

Primary Application Tier


APPLICATION TIER HOSTNAME : finance.example.net
INSTALL BASE              :  /u01/install/APPS
Run File System ( FS1)    :  /u01/install/APPS/fs1
Patch File System ( FS2)  :  /u01/install/APPS/fs2
Non-Editioned File System (fs_ne) : /u01/install/APPS/fs_ne
INST_TOP 1                :  /u01/install/APPS/fs1/inst
INST_TOP 2                :  /u01/install/APPS/fs2/inst
LOCATION OF THE RUN CONTEXT_FILE : /u01/install/APPS/fs1/inst/apps/VISION_finance/appl/admin/VISION_finance.xml
LOCATION OF THE PATCH CONTEXT_FILE : /u01/install/APPS/fs2/inst/apps/VISION_finance/appl/admin/VISION_finance.xml


Execute Autoconfig on the run file system
$ . ./u01/install/APPS/EBSapps.env run

$ $INST_TOP/admin/scripts/adautocfg.sh

Upload the Patch file system context file to the Database

$ . ./u01/install/APPS/EBSapps.env patch

$ $ADJVAPRG oracle.apps.ad.autoconfig.oam.CtxSynchronizer action=upload
contextfile=<full path to patch context file> logfile=/tmp/patchctxupload.log

Please note there is no need to execute autoconfig on the patch file system.

Section 5.3.2.5: Update the Hirearchy Type

Perform the following steps on the primary application tier node or the master node. See Section 4.1: Update Hierarchy Type for more information.

Primary Application Tier


APPLICATION TIER HOSTNAME : finance.example.net
INSTALL BASE              :  /u01/install/APPS
Run File System ( FS1)    :  /u01/install/APPS/fs1
Patch File System ( FS2)  :  /u01/install/APPS/fs2
Non-Editioned File System (fs_ne) : /u01/install/APPS/fs_ne
INST_TOP 1                :  /u01/install/APPS/fs1/inst
INST_TOP 2                :  /u01/install/APPS/fs2/inst
LOCATION OF THE RUN CONTEXT_FILE : /u01/install/APPS/fs1/inst/apps/VISION_finance/appl/admin/VISION_finance.xml
LOCATION OF THE PATCH CONTEXT_FILE : /u01/install/APPS/fs2/inst/apps/VISION_finance/appl/admin/VISION_finance.xml


Source the Run Edition Environment file
$ . ./u01/install/APPS/EBSapps.env run

Switch the hierarchy type of the profile options to be of type server-responsibility

$ sqlplus apps/apps @$FND_TOP/patch/115/sql/txkChangeProfH.sql SERVRESP

Section 5.3.2.6: Execute Adpreclone Utility on the run and patch edition File System

The adpreclone utility requires the WebLogic Administration process to be running from the file system where the utility is run. This is required to package the Oracle Fusion Middleware components and its configuration. Perform the commands shown below on both the run and patch edition file systems:

Primary Application Tier


APPLICATION TIER HOSTNAME : finance.example.net
INSTALL BASE              :  /u01/install/APPS
Run File System ( FS1)    :  /u01/install/APPS/fs1
Patch File System ( FS2)  :  /u01/install/APPS/fs2
Non-Editioned File System (fs_ne) : /u01/install/APPS/fs_ne
INST_TOP 1                :  /u01/install/APPS/fs1/inst
INST_TOP 2                :  /u01/install/APPS/fs2/inst
LOCATION OF THE RUN CONTEXT_FILE : /u01/install/APPS/fs1/inst/apps/VISION_finance/appl/admin/VISION_finance.xml
LOCATION OF THE PATCH CONTEXT_FILE : /u01/install/APPS/fs2/inst/apps/VISION_finance/appl/admin/VISION_finance.xml


Source the Run file system env file
$ . ./u01/install/APPS/EBSapps.env run

$ $INST_TOP/admin/scripts/adadminsrvctl.sh start

$ $INST_TOP/admin/scripts/adpreclone.pl appsTier

$ $INST_TOP/admin/scripts/adadminsrvctl.sh stop

$ $INST_TOP/admin/scripts/adnodemgrctl.sh stop

Source the Patch file system env file

$ . ./u01/install/APPS/EBSapps.env patch
$ $INST_TOP/admin/scripts/adadminsrvctl.sh start forcepatchfs

$ $INST_TOP/admin/scripts/adpreclone.pl appsTier

$ $INST_TOP/admin/scripts/adadminsrvctl.sh stop

$ $INST_TOP/admin/scripts/adnodemgrctl.sh stop

Section 5.3.2.7: Add Secondary Internal Application Tier Nodes Using Shared File System

The configuration tasks listed below assume that you have completed all the steps listed in this section above. It is important that you review the configuration before proceeding with the steps given below. The node to be added now will be known as the secondary application tier node or the slave node. This node can be configured to run all services except for the Oracle WebLogic Administration Server.

Note:

The fully qualified hostname of the application tier node to be added must be present in the sqlnet.ora file in the <Database_Oracle_ Home>/network/admin<context-name> directory if it exists. (See tcp.invited_nodes parameter.)
The database and TNS listener must be running.
In a shared file system, User ID and group ID should be consistent across all nodes to avoid file access permission issues.
The same absolute path must be used for the shared file system mount points on each node.
Ensure that value of the AutoConfig variable "s_atName" is set to the hostname of the master node
Ensure that value of the AutoConfig variable " s_shared_file_system" is set to "true" ( without the quote) on the primary application tier node. This variable will be automatically set to "true" if the shared file system option was chosen during the Rapid Install.
The fully qualified hostname of the application tier nodes that you are going to add must be resolvable from the primary application tier node and vice versa either via the Domain Naming System (DNS) or file based resolution.
Every application tier node must have a valid oraInst.loc file in the respective directory ( see Oracle Universal Intaller guide for platform specific location) pointing to a global inventory location. The default location for the Linux platform is /etc directory.

Section 5.3.2.8: Export the Required Application Tier File System From the Primary Internal Application Tier Node

Follow the instructions given below to export the required application tier file system from the primary application tier node.

Primary Internal Application Tier

APPLICATION TIER HOSTNAME : finance.example.net
INSTALL BASE              :  /u01/install/APPS
LOCATION OF THE INVENTORY : /u01/install/OraInventory

On a Linux system, execute the following commands as the root user to mount the application tier file system to the secondary nodes. The export options described below may need to be adjusted per the security requirements of your company. Also, the available options may differ for other platforms.

Add the following lines to the /etc/exports file

/u01/install/APPS procurement.example.net(rw,sync,no_root_squash)
/u01/install/OraInventory procurement.example.net(rw,sync,no_root_squash)

Check whether the NFS daemons are running:

$ /sbin/service nfs status

If the NFS daemons are not running, execute the following command to start them:

$ /sbin/service nfs start

Once the NFS daemons are running, execute the following command to export the application tier file system:

$ /usr/sbin/exportfs -a

Ensure the application tier file systems are exported by executing the following command:

$ /usr/sbin/exportfs

Section 5.3.2.9: Mount the Required Application Tier File System to the Secondary Internal Application Tier Nodes

Follow the instructions given below to mount the required application tier file system to the secondary application tier nodes

APPLICATION TIER HOST FROM WHERE FILE SYSTEM IS EXPORTED : finance.example.net
APPLICATION TIER HOSTS TO WHICH FILE SYSTEM NEED TO BE MOUNTED : procurement.example.net

The following application tier file system need to be mounted on the secondary application tier node from the primary node.

INSTALL BASE              :  /u01/install/APPS
LOCATION OF THE INVENTORY : /u01/install/OraInventory

Check whether the NFS daemons are running:

$ /sbin/service nfs status

If the NFS daemons are not running, execute the following command to start them:

$ /sbin/service nfs start

Create directories as follows on all secondary application tier nodes$ /bin/mkdir -p /u01/install/APPS
$ /bin/mkdir -p /u01/install/OraInventory


Change the ownership and group permissions of these directories to be the same as that of the primary application tier node. For example if oracle is the owner of the file system and is in the group dba, you need to execute the commands shown below:$ /bin/chown -R /u01/install/APPS
$ /bin/chown -R /u01/install/oraInventory
$ /bin/chgrp -R dba /u01/install/APPS
$ /bin/chgrp -R dba /u01/install/oraInventory

Use the following commands to mount the application tier file system from the primary node to the secondary application tier nodes:
$ cd /u01/install/APPS
$ /bin/mount -t nfs -o rw,nointr,bg,hard,timeo=600,wsize=65536,rsize=65536,nfsvers=3,tcp finance.example.net:/u01/install/APPS .
$ /bin/mount -t nfs -o rw,nointr,bg,hard,timeo=600,wsize=65536,rsize=65536,nfsvers=3,tcp finance.example.net:/u01/install/oraInventory .

Add the remote file system to /etc/fstab so that file system are automatically mounted on the secondary application tier on boot:$ vi /etc/fstab
add the following lines to fstabfinance.example.net:/u01/install/APPS /u01/install/APPS nfs rw,nointr,bg,hard,timeo=660,wsize=65536.rsize=65536,nfsvers=3,tcp 0 0
finance.example.net:/u01/install/oraInventory /u01/install/oraInventory nfs rw,nointr,bg,hard,timeo=660,wsize=65536.rsize=65536,nfsvers=3,tcp 0 0



Please note that nfs version used here is V3 . Customers can also configure the mounted file system to use NFS V4.

Section 5.3.2.10: Prepare the Pairs File for Addition of the Secondary Internal Application Tier Nodes

APPLICATION TIER HOST FROM WHERE FILE SYSTEM IS EXPORTED : finance.example.net
APPLICATION TIER HOSTS TO WHICH FILE SYSTEM NEED TO BE MOUNTED : procurement.example.net

APPLICATION TIER HOSTNAME : procurement.example.net
INSTALL BASE              :  /u01/install/APPS
Run File System ( FS1)    :  /u01/install/APPS/fs1
Patch File System ( FS2)  :  /u01/install/APPS/fs2
INST_TOP 1                :  /u01/install/APPS/fs1/inst
INST_TOP 2                :  /u01/install/APPS/fs2/inst
LOCATION OF THE RUN CONTEXT_FILE : /u01/install/APPS/fs1/inst/apps/VISION_finance/appl/admin/VISION_finance.xml
LOCATION OF THE PATCH CONTEXT_FILE : /u01/install/APPS/fs2/inst/apps/VISION_finance/appl/admin/VISION_finance.xml

Prepare the pairs file for configuring the run file system

A sample pairs file for the run file system is instantiated into the relevant instance home on the primary application tier node . The name of the file is <SID>_<primary_node_name>_<file_edition_type>.txt, located in the <INST_TOP>/appl/admin/ directory. For example : for the configuration described in this case study, the file name is /u01/install/APPS/fs1/inst/apps/VISION_finance/appl/admin/VISION_finance_run.txt

Create the required following directories, then copy the pairs file into a directory of your choice for each of the application tier nodes. For example:$ mkdir -p /u01/install/APPS/pairs/procurement
$ cp /u01/install/APPS/fs1/inst/apps/VISION_finance/appl/admin/VISION_finance_run.txt /u01/install/APPS/pairs/procurement


Review and update the pairs file that was copied for each of the application tier nodes. The parameters that need to be filled are under the sections [Instance Specific] and [Services] . The pairs file has detailed instructions on how to fill the appropriate values.For example for the node procurement, you would fill in the required parameters as shown below:


[Web Entry Point Configuration]s_webentryurlprotocol=http
s_webentryhost=employees
s_webentrydomain=example.net
s_active_webport=80
s_endUserMonitoringURL=http://employees.example.net:80/oracle_smp_chronos/oracle_smp_chronos_sdk.gif
s_external_url=http://employees.example.net:80
s_login_page=http://employees.example.net:80/OA_HTML/AppsLogin

[Instance Specific]
s_temp=/u01/install/APPS/fs1/inst/apps/VISION_procurement/temp
s_contextname=VISION_procurement
s_hostname=procurement
s_domainname=example.net
s_cphost=finance
s_webhost=procurement
s_config_home=/u01/install/APPS/fs1/inst/apps/VISION_procurement
s_display=localhost:0.0
s_forms-c4ws_display=procurement:0.0
s_ohs_instance=EBS_web_VISION_OHS2

[Services To be Enabled on the Secondary Application Tier Node]
s_web_applications_status=enabled
s_web_entry_status=enabled
s_apcstatus=enabled
s_root_status=enabled
s_batch_status=disabled
s_other_service_group_status=disabled
s_adminserverstatus=disabled




Prepare the pairs file for configuring the patch file system

A sample pairs file for the patch file system is instantiated into the relevant instance home on the primary application tier node . The name of the file is <SID>_<primary_node_name>_<file_edition_type>.txt, located in the <INST_TOP>/appl/admin/ directory. For example : for the configuration described in this case study, the file name is /u01/install/APPS/fs2/inst/apps/VISION_finance/appl/admin/VISION_finance_patch.txt

Copy the pairs file to the following directories For example:$ cp /u01/install/APPS/fs2/inst/apps/VISION_finance/appl/admin/VISION_finance_patch.txt /u01/install/APPS/pairs/procurement


Review and update the pairs file that was copied for each of the application tier nodes. The parameters that need to be filled are under the sections [Instance Specific] and [Services] . The pairs file has detailed instructions on how to fill the appropriate values.For example for the node procurement, you would fill in the required parameters as shown below:

[Web Entry Point Configuration]s_webentryurlprotocol=http
s_webentryhost=employees
s_webentrydomain=example.net
s_active_webport=80
s_endUserMonitoringURL=http://employees.example.net:80/oracle_smp_chronos/oracle_smp_chronos_sdk.gif
s_external_url=http://employees.example.net:80
s_login_page=http://employees.example.net:80/OA_HTML/AppsLogin

[Instance Specific]
s_temp=/u01/install/APPS/fs2/inst/apps/VISION_procurement/temp
s_contextname=VISION_procurement
s_hostname=procurement
s_domainname=example.net
s_cphost=finance
s_webhost=procurement
s_config_home=/u01/install/APPS/fs2/inst/apps/VISION_procurement
s_display=localhost:0.0
s_forms-c4ws_display=procurement:0.0
s_ohs_instance=EBS_web_VISION_OHS2

[Services To be Enabled on the Secondary Application Tier Node]
s_web_applications_status=enabled
s_web_entry_status=enabled
s_apcstatus=enabled
s_root_status=enabled
s_batch_status=disabled
s_other_service_group_status=disabled
s_adminserverstatus=disabled

Section 5.3.2.11: Prepare the Required Scripts for Adding the Secondary Internal Application Tier Nodes

PRIMARY APPLICATION TIER NODE : finance.example.net
SECONDARY APPLICATION TIER NODES : procurement.example.net
INSTALL BASE              :  /u01/install/APPS
Run File System ( FS1)    :  /u01/install/APPS/fs1
Patch File System ( FS2)  :  /u01/install/APPS/fs2
INST_TOP 1                :  /u01/install/APPS/fs1/inst
INST_TOP 2                :  /u01/install/APPS/fs2/inst
LOCATION OF THE RUN CONTEXT_FILE : /u01/install/APPS/fs1/inst/apps/VISION_finance/appl/admin/VISION_finance.xml
LOCATION OF THE PATCH CONTEXT_FILE : /u01/install/APPS/fs2/inst/apps/VISION_finance/appl/admin/VISION_finance.xml

Create the following scripts for each node in their corresponding directories . For example for the procurement node in /u01/install/APPS/pairs/procurementaddprocurementrun.sh

export PATH=/u01/install/APPS/fs1/FMW_Home/webtier/perl/bin:$PATH
cd /u01/install/APPS/fs1/EBSapps/comn/clone/bin
perl ./adclonectx.pl addnode contextfile=/u01/install/APPS/fs1/inst/apps/VISION_finance/appl/admin/VISION_finance.xml \ pairsfile=/u01/install/APPS/pairs/procurement/pairs/VISION_finance_run.txt \ outfile=/u01/install/APPS/fs1/inst/apps/VISION_procurement/appl/admin/VISION_procurement.xml


addprocurementpatch.sh

export PATH=/u01/install/APPS/fs2/FMW_Home/webtier/perl/bin:$PATH
cd /u01/install/APPS/fs2/EBSapps/comn/clone/bin
perl ./adclonectx.pl addnode contextfile=/u01/install/APPS/fs2/inst/apps/VISION_finance/appl/admin/VISION_finance.xml \ pairsfile=/u01/install/APPS/pairs/procurement/pairs/VISION_finance_patch.txt \ outfile=/u01/install/APPS/fs2/inst/apps/VISION_procurement/appl/admin/VISION_procurement.xml

Section 5.3.2.12: Add the Secondary Internal Application Tier Node to the Farm

Seconday Application Tier Nodes

SECONDARY APPLICATION TIER NODES : procurement.example.net
INSTALL BASE              :  /u01/install/APPS
Run File System ( FS1)    :  /u01/install/APPS/fs1
Patch File System ( FS2)  :  /u01/install/APPS/fs2
INST_TOP 1                :  /u01/install/APPS/fs1/inst
INST_TOP 2                :  /u01/install/APPS/fs2/inst
LOCATION OF THE RUN CONTEXT_FILE : /u01/install/APPS/fs1/inst/apps/VISION_finance/appl/admin/VISION_finance.xml
LOCATION OF THE PATCH CONTEXT_FILE : /u01/install/APPS/fs2/inst/apps/VISION_finance/appl/admin/VISION_finance.xml

Login to the secondary application tier nodes and execute the scripts to add the run and patch edition file system. The scripts must be executed in serial mode on all the nodes for the run file system followed by patch. Complete one node first before proceeding to the next.

For example:Logon to the procurement.example.net node, execute$ sh /u01/install/APPS/pairs/procurement/addprocurementrun.sh
$ sh /u01/install/APPS/pairs/procurement/addprocurementpatch.sh


verify the EBSprovisioner.log file created in either the current directory or /u01/install/APPS/fs2/EBSapps/comn/clone/bin for any errors

Section 5.3.2.13: Add secondary external application tier node

The tasks listed in this section assume that you have successfully completed the configuration of the internal application tier node . It is important that you review the configuration before proceeding with the steps given below. The node to be added now will be known as the secondary external application tier node . This node can be configured to run all services except for the Oracle WebLogic Administration Server and does not share the file system with the internal application tier nodes.

Note:

The fully qualified hostname of the application tier node to be added must be present in the sqlnet.ora file in the <Database_Oracle_ Home>/network/admin<context-name> directory if it exists. (See tcp.invited_nodes parameter.)
The database and TNS listener must be running.
In a shared file system, User ID and group ID should be consistent across all nodes to avoid file access permission issues.
The same absolute path must be used for the shared file system mount points on each node..
The fully qualified hostname of the application tier nodes that you are going to add must be resolvable from the primary application tier node and vice versa either via the Domain Naming System (DNS) or file based resolution.
Every application tier node must have a valid oraInst.loc file in the respective directory ( see Oracle Universal Intaller guide for platform specific location) pointing to a global inventory location. The default location for the Linux platform is /etc directory.

Section 5.3.2.14: Copy the Required Application Tier File System to the Secondary External Application Tier Node

Follow the instructions given below to copy the file system from the primary application tier node to the secondary external application tier node.

APPLICATION TIER HOST FROM WHERE FILE SYSTEM NEED TO BE COPIED: finance.example.net
APPLICATION TIER HOSTS TO WHICH FILE SYSTEM NEED TO BE COPIED : supplier.example.com

The following application tier file system from INSTALL_BASE need to be copied from the primary node to the secondary application tier node

Run File System (FS1)     :  /u01/install/APPS/fs1/EBSapps
Patch File System (FS2)   :  /u01/install/APPS/fs2/EBSapps
Non-Editioned File System(fs_ne)  :  /u01/install/APPS/fs_ne

Section 5.3.2.15: Execute the Post Clone Script on the Run File System

Seconday Application Tier Node

SECONDARY APPLICATION TIER NODE: supplier.example.com
$ cd <COMMON_TOP>/clone/bin

$ perl ./adcfgclone.pl appsTier
Answer the prompts as shown below:

Enter the APPS Password : <apps-password>

Enter the WebLogic AdminServer password: <WebLogic-admin-password>

Do you want to add a node (yes/no) : yes

Target System File Edition type [run]: run

Provide the values required for creation of the new APPL_TOP Context file.

Target System Hostname (virtual or normal) [supplier] : supplier

Target System Base Directory set to /u01/install/APPS

Target System Current File System Base set to /u01/install/APPS/fs1

Target System Other File System Base set to /u01/install/APPS/fs2

Target System Fusion Middleware Home set to /u01/install/APPS/fs1/FMW_Home

Target System Web Oracle Home set to /u01/install/APPS/fs1/FMW_Home/webtier

Target System Appl TOP set to /u01/install/APPS/fs1/EBSapps/appl

Target System COMMON TOP set to /u01/install/APPS/fs1/EBSapps/comn

Target System Instance Home Directory [/u01/install/APPS]: /u01/install/APPS

Target System Instance Top set to /u01/install/APPS/fs1/inst/apps/VISION_supplier

Do you want to preserve the Display [localhost5:0] {y/n) :y

Target System Root Service [enabled]: enabled

Target System Web Entry Point Services [enabled]: enabled

Target System Web Application Services [enabled]: enabled

Target System Batch Processing Services [enabled]: disabled

Target System Other Services [disabled]: disabled

Do you want the target system to have the same port values as the source system (y/n) [y] : y
Complete port information available at /u01/install/APPS/fs1/EBSapps/comn/clone/bin/out/VISION_supplier/portpool.lst

UTL_FILE_DIR on database tier consists of the following directories.

1. /usr/tmp
2. /usr/tmp
3. /u01/install/PROD/11.2.0/appsutil/outbound/EBSDB_db
4. /usr/tmp

Choose a value which will be set as APPLPTMP value of the target node [1] : 1

Do you want to startup the Application Services for VISION? {y/n)[n]: n

Section 5.3.2.16: Execute the Post Clone Script on the Patch File System

Secondary Application Tier Node

SECONDARY APPLICATION TIER NODE: supplier.example.com
$ cd <COMMON_TOP>/clone/bin

$ perl ./adcfgclone.pl appsTier
Answer the prompts as shown below:

Enter the APPS Password : <apps-password>

Enter the WebLogic AdminServer password: <WebLogic-admin-password>

Do you want to add a node (yes/no) : yes

Target System File Editition type [patch]: patch

Provide the values required for creation of the new APPL_TOP Context file.

Target System Hostname (virtual or normal) [supplier] : supplier

Target System Base Directory set to /u01/install/APPS

Target System Current File System Base set to /u01/install/APPS/fs2

Target System Other File System Base set to /u01/install/APPS/fs1

Target System Fusion Middleware Home set to /u01/install/APPS/fs2/FMW_Home

Target System Web Oracle Home set to /u01/install/APPS/fs2/FMW_Home/webtier

Target System Appl TOP set to /u01/install/APPS/fs2/EBSapps/appl

Target System COMMON TOP set to /u01/install/APPS/fs2/EBSapps/comn

Target System Instance Home Directory [/u01/install/APPS]: /u01/install/APPS

Target System Instance Top set to /u01/install/APPS/fs2/inst/apps/VISION_supplier

Do you want to preserve the Display [localhost5:0] {y/n) :y

Target System Root Service [enabled]: enabled

Target System Web Entry Point Services [enabled]: enabled

Target System Web Application Services [enabled]: enabled

Target System Batch Processing Services [enabled]: disabled

Target System Other Services [disabled]: disabled

Do you want the target system to have the same port values as the source system (y/n) [y] : y
Complete port information available at /u01/install/APPS/fs2/EBSapps/comn/clone/bin/out/VISION_supplier/portpool.lst

UTL_FILE_DIR on database tier consists of the following directories.

1. /usr/tmp
2. /usr/tmp
3. /u01/install/PROD/11.2.0/appsutil/outbound/EBSDB_db
4. /usr/tmp

Choose a value which will be set as APPLPTMP value of the target node [1] : 1

Section 5.3.2.17: Configure a Load Balancer Infront of the Secondary External Application Tier Node

Oracle E-Business Suite multi-node configuration require an external load balancer in front of the application tier nodes to load balance the http traffic from the clients. This requires the Oracle E-Business Suite application tier nodes to be aware of the load balancing device. If you have such a configuration, ensure that the following required application tier context file variables are updated. Please note that context file update need to be performed both on the run and patch edition file system application context file and AutoConfig utility executed to update the configuration. An example is provided in the following table.

Secondary Application Tier


APPLICATION TIER HOSTNAME : supplier.example.com
INSTALL BASE              :  /u01/install/APPS
Run File System ( FS1)    :  /u01/install/APPS/fs1
Patch File System ( FS2)  :  /u01/install/APPS/fs2
Non-Editioned File System (fs_ne) : /u01/install/APPS/fs_ne
INST_TOP 1                :  /u01/install/APPS/fs1/inst
INST_TOP 2                :  /u01/install/APPS/fs2/inst
LOCATION OF THE RUN CONTEXT_FILE : /u01/install/APPS/fs1/inst/apps/VISION_supplier/appl/admin/VISION_supplier.xml
LOCATION OF THE PATCH CONTEXT_FILE : /u01/install/APPS/fs2/inst/apps/VISION_supplier/appl/admin/VISION_supplier.xml


LBR CONFIGURATION

LBR WEBENTRY PROTOCOL : https
LBR HOSTNAME : partners
LBR DOMAINNAME : example.com
LBR ENTRYPORT : 443


CONTEXT VARIABLES TO BE CHANGED FOR THE ABOVE LBR CONFIGURATION

<webentryurlprotocol oa_var="s_webentryurlprotocol">https</webentryurlprotocol>

<webentryhost oa_var="s_webentryhost">partners</webentryhost>

<webentrydomain oa_var="s_webentrydomain">example.com</webentrydomain>

<activewebport oa_var="s_active_webport">443</activewebport>

<login_page oa_var="s_login_page">https://partners.example.com:443/OA_HTML/AppsLogin</login_page>


<EndUserMonitoringURL oa_var="s_endUserMonitoringURL">https://partners.example.com:443/oracle_smp_chronos/oracle_smp_chronos_sdk.gif</EndUserMonitoringURL>

<externURL oa_var="s_external_url">https://partners.example.com:443/OA_HTML/AppsLogin</externURL>

Section 5.3.2.18: Export the Required Application Tier File System From the Primary External Application Tier Node

Follow the instructions given below to export the required application tier file system from the primary external application tier node.

Primary External Application Tier

APPLICATION TIER HOSTNAME : supplier.example.com
INSTALL BASE              :  /u01/install/APPS
LOCATION OF THE INVENTORY : /u01/install/OraInventory

On a Linux system, execute the following commands as the root user to mount the application tier file system to the secondary nodes. The export options described below may need to be adjusted per the security requirements of your company. Also, the available options may differ for other platforms.

Add the following lines to the /etc/exports file

/u01/install/APPS sourcing.example.com(rw,sync,no_root_squash)
/u01/install/OraInventory sourcing.example.com(rw,sync,no_root_squash)

Check whether the NFS daemons are running:

$ /sbin/service nfs status

If the NFS daemons are not running, execute the following command to start them:

$ /sbin/service nfs start

Once the NFS daemons are running, execute the following command to export the application tier file system:

$ /usr/sbin/exportfs -a

Ensure the application tier file systems are exported by executing the following command:

$ /usr/sbin/exportfs

Section 5.3.2.19: Mount the Required Application Tier File System to the Secondary External Application Tier Node

Follow the instructions given below to mount the required application tier file system to the secondary external application tier node.

APPLICATION TIER HOST FROM WHERE FILE SYSTEM IS EXPORTED : supplier.example.com
APPLICATION TIER HOSTS TO WHICH FILE SYSTEM NEED TO BE MOUNTED : sourcing.example.com

The following application tier file system need to be mounted on the secondary application tier node from the primary node.

INSTALL BASE              :  /u01/install/APPS
LOCATION OF THE INVENTORY : /u01/install/OraInventory

Check whether the NFS daemons are running:

$ /sbin/service nfs status

If the NFS daemons are not running, execute the following command to start them:

$ /sbin/service nfs start

Create directories as follows on all secondary application tier nodes$ /bin/mkdir -p /u01/install/APPS
$ /bin/mkdir -p /u01/install/OraInventory


Change the ownership and group permissions of these directories to be the same as that of the primary application tier node. For example if oracle is the owner of the file system and is in the group dba, you need to execute the commands shown below:$ /bin/chown -R /u01/install/APPS
$ /bin/chown -R /u01/install/oraInventory
$ /bin/chgrp -R dba /u01/install/APPS
$ /bin/chgrp -R dba /u01/install/oraInventory

Use the following commands to mount the application tier file system from the primary node to the secondary application tier nodes:
$ cd /u01/install/APPS
$ /bin/mount -t nfs -o rw,nointr,bg,hard,timeo=600,wsize=65536,rsize=65536,nfsvers=3,tcp supplier.example.net:/u01/install/APPS .
$ /bin/mount -t nfs -o rw,nointr,bg,hard,timeo=600,wsize=65536,rsize=65536,nfsvers=3,tcp supplier.example.net:/u01/install/oraInventory .

Add the remote file system to /etc/fstab so that file system are automatically mounted on the secondary application tier on boot:$ vi /etc/fstab
add the following lines to fstabsupplier.example.net:/u01/install/APPS /u01/install/APPS nfs rw,nointr,bg,hard,timeo=660,wsize=65536.rsize=65536,nfsvers=3,tcp 0 0
supplier.example.net:/u01/install/oraInventory /u01/install/oraInventory nfs rw,nointr,bg,hard,timeo=660,wsize=65536.rsize=65536,nfsvers=3,tcp 0 0



Please note that nfs version used here is V3 . Customers can also configure the mounted file system to use NFS V4.

Section 5.3.2.20: Prepare the Pairs File for Addition of the Secondary External Application Tier Node

The primary decision that an administrator needs to make before proceeding with the steps given below is to decide which services need to be configured on the secondary application tier nodes. The new node that you are planning to add can run any service except for the WebLogic Administration Server, which is only configured on the primary internal application tier node. Follow the steps given below to prepare the pairs file for adding the secondary application tier nodes.

APPLICATION TIER HOST FROM WHERE FILE SYSTEM IS EXPORTED : supplier.example.com
APPLICATION TIER HOSTS TO WHICH FILE SYSTEM NEED TO BE MOUNTED : sourcing.example.com

APPLICATION TIER HOSTNAME : supplier.example.com
INSTALL BASE              :  /u01/install/APPS
Run File System ( FS1)    :  /u01/install/APPS/fs1
Patch File System ( FS2)  :  /u01/install/APPS/fs2
INST_TOP 1                :  /u01/install/APPS/fs1/inst
INST_TOP 2                :  /u01/install/APPS/fs2/inst
LOCATION OF THE RUN CONTEXT_FILE : /u01/install/APPS/fs1/inst/apps/VISION_supplier/appl/admin/VISION_supplier.xml
LOCATION OF THE PATCH CONTEXT_FILE : /u01/install/APPS/fs2/inst/apps/VISION_supplier/appl/admin/VISION_supplier.xml

Prepare the pairs file for configuring the run file system

A sample pairs file for the run file system is instantiated into the relevant instance home on the primary application tier node . The name of the file is <SID>_<primary_node_name>_<file_edition_type>.txt, located in the <INST_TOP>/appl/admin/ directory. For example : for the configuration described in this case study, the file name is /u01/install/APPS/fs1/inst/apps/VISION_supplier/appl/admin/VISION_supplier_run.txt

Create the required following directories, then copy the pairs file into a directory of your choice for each of the application tier nodes. For example:$ mkdir -p /u01/install/APPS/pairs/sourcing
$ cp /u01/install/APPS/fs1/inst/apps/VISION_supplier/appl/admin/VISION_supplier_run.txt /u01/install/APPS/pairs/sourcing/VISION_sourcing_run.txt


Review and update the pairs file that was copied for each of the application tier nodes. The parameters that need to be filled are under the sections [Instance Specific] and [Services] . The pairs file has detailed instructions on how to fill the appropriate values.For example for the node sourcing, you would fill in the required parameters as shown below:

[Web Entry Point Configuration]s_webentryurlprotocol=https
s_webentryhost=partners
s_webentrydomain=example.com
s_active_webport=443
s_endUserMonitoringURL=https://partners.example.com:443/oracle_smp_chronos/oracle_smp_chronos_sdk.gif
s_external_url=https://partners.example.com:443
s_login_page=https://partners.example.com:443/OA_HTML/AppsLogin

[Instance Specific]
s_temp=/u01/install/APPS/fs1/inst/apps/VISION_sourcing/temp
s_contextname=VISION_sourcing
s_hostname=sourcing
s_domainname=example.com
s_cphost=finance
s_webhost=sourcing
s_config_home=/u01/install/APPS/fs1/inst/apps/VISION_sourcing
s_display=localhost:0.0
s_forms-c4ws_display=sourcing:0.0
s_ohs_instance=EBS_web_VISION_OHS4

[Services To be Enabled on the Secondary Application Tier Node]
s_web_applications_status=enabled
s_web_entry_status=enabled
s_apcstatus=enabled
s_root_status=enabled
s_batch_status=disabled
s_other_service_group_status=disabled
s_adminserverstatus=disabled




Prepare the pairs file for configuring the patch file system

A sample pairs file for the patch file system is instantiated into the relevant instance home on the primary application tier node . The name of the file is <SID>_<primary_node_name>_<file_edition_type>.txt, located in the <INST_TOP>/appl/admin/ directory. For example : for the configuration described in this case study, the file name is /u01/install/APPS/fs2/inst/apps/VISION_supplier/appl/admin/VISION_supplier_patch.txt

Copy the pairs file to the following directories For example:$ cp /u01/install/APPS/fs2/inst/apps/VISION_supplier/appl/admin/VISION_supplier_patch.txt /u01/install/APPS/pairs/sourcing/VISION_sourcing_patch.txt


Review and update the pairs file that was copied for each of the application tier nodes. The parameters that need to be filled are under the sections [Instance Specific] and [Services] . The pairs file has detailed instructions on how to fill the appropriate values.For example for the node sourcing, you would fill in the required parameters as shown below:

[Web Entry Point Configuration]s_webentryurlprotocol=https
s_webentryhost=partners
s_webentrydomain=example.com
s_active_webport=443
s_endUserMonitoringURL=https://partners.example.com:443/oracle_smp_chronos/oracle_smp_chronos_sdk.gif
s_external_url=https://partners.example.com:443
s_login_page=https://partners.example.com:443/OA_HTML/AppsLogin

[Instance Specific]
s_temp=/u01/install/APPS/fs2/inst/apps/VISION_sourcing/temp
s_contextname=VISION_sourcing
s_hostname=sourcing
s_domainname=example.com
s_cphost=finance
s_webhost=sourcing
s_config_home=/u01/install/APPS/fs2/inst/apps/VISION_sourcing
s_display=localhost:0.0
s_forms-c4ws_display=sourcing:0.0
s_ohs_instance=EBS_web_VISION_OHS4

[Services To be Enabled on the Secondary Application Tier Node]
s_web_applications_status=enabled
s_web_entry_status=enabled
s_apcstatus=enabled
s_root_status=enabled
s_batch_status=disabled
s_other_service_group_status=disabled
s_adminserverstatus=disabled

Section 5.3.2.21 Prepare the Required Scripts for Adding the Secondary External Application Tier Node

PRIMARY EXTERNAL APPLICATION TIER NODE : supplier.example.com
SECONDARY APPLICATION TIER NODES : sourcing.example.com
INSTALL BASE              :  /u01/install/APPS
Run File System ( FS1)    :  /u01/install/APPS/fs1
Patch File System ( FS2)  :  /u01/install/APPS/fs2
INST_TOP 1                :  /u01/install/APPS/fs1/inst
INST_TOP 2                :  /u01/install/APPS/fs2/inst
LOCATION OF THE RUN CONTEXT_FILE : /u01/install/APPS/fs1/inst/apps/VISION_finance/appl/admin/VISION_supplier.xml
LOCATION OF THE PATCH CONTEXT_FILE : /u01/install/APPS/fs2/inst/apps/VISION_finance/appl/admin/VISION_supplier.xml

Create the following scripts for each node in their corresponding directories . For example for the sourcing node in /u01/install/APPS/pairs/sourcingaddsourcingrun.sh

export PATH=/u01/install/APPS/fs1/FMW_Home/webtier/perl/bin:$PATH
cd /u01/install/APPS/fs1/EBSapps/comn/clone/bin
perl ./adclonectx.pl addnode contextfile=/u01/install/APPS/fs1/inst/apps/VISION_supplier/appl/admin/VISION_supplier.xml \ pairsfile=/u01/install/APPS/pairs/sourcing/pairs/VISION_sourcing_run.txt \ outfile=/u01/install/APPS/fs1/inst/apps/VISION_sourcing/appl/admin/VISION_sourcing.xml


addsourcingpatch.sh

export PATH=/u01/install/APPS/fs2/FMW_Home/webtier/perl/bin:$PATH
cd /u01/install/APPS/fs2/EBSapps/comn/clone/bin
perl ./adclonectx.pl addnode contextfile=/u01/install/APPS/fs2/inst/apps/VISION_supplier/appl/admin/VISION_supplier.xml \ pairsfile=/u01/install/APPS/pairs/sourcing/pairs/VISION_sourcing_patch.txt \ outfile=/u01/install/APPS/fs2/inst/apps/VISION_sourcing/appl/admin/VISION_sourcing.xml

Section 5.3.2.22: Add the secondary external application tier node to the farm

Secondary Application Tier Node

SECONDARY APPLICATION TIER NODES : sourcing.example.com
INSTALL BASE              :  /u01/install/APPS
Run File System ( FS1)    :  /u01/install/APPS/fs1
Patch File System ( FS2)  :  /u01/install/APPS/fs2
INST_TOP 1                :  /u01/install/APPS/fs1/inst
INST_TOP 2                :  /u01/install/APPS/fs2/inst
LOCATION OF THE RUN CONTEXT_FILE : /u01/install/APPS/fs1/inst/apps/VISION_sourcing/appl/admin/VISION_sourcing.xml
LOCATION OF THE PATCH CONTEXT_FILE : /u01/install/APPS/fs2/inst/apps/VISION_sourcing/appl/admin/VISION_sourcing.xml

Login to the secondary application tier node sourcing and execute the scripts to add the run and patch edition file system. The scripts must be executed in serial mode on run file system followed by patch.
For example:Logon to the sourcing.example.com node, execute$ sh /u01/install/APPS/pairs/procurement/addsourcingrun.sh
$ sh /u01/install/APPS/pairs/procurement/addsourcingpatch.sh


verify the EBSprovisioner.log file created in either the current directory or /u01/install/APPS/fs2/EBSapps/comn/clone/bin for any errors

Section 5.3.2.23: Sync Up the Context File and Update Configuration On All Nodes

Follow the instructions given below on all application tier nodes to sync up the context file and configuration files.

PRIMARY APPLICATION TIER NODE : finance.example.net

SECONDARY APPLICATION TIER NODES : procurement.example.net,supplier.example.com,sourcing.example.com

Login to all the application tier nodes and execute the the following scripts to sync up the context file and configuration files for the run file systemSource the EBSapps.env file$ . ./u01/install/APPS/EBSapps.env run
$ perl $AD_TOP/bin/adSyncContext.pl contextfile=$CONTEXT_FILE

The following command syntax works with AD/TXK Code Level D4 .
$ perl $FND_TOP/patch/115/bin/txkSetAppsConf.pl -ctxfile=$CONTEXT_FILE -outfile=$APPLRGF/TXK/conf.log

If you are a later version of the AD/TXK Code level, follow the instructions given in section 5.3.2.4-5.3.2.7 ( Register the new topology from the newly added application tier node) of My Oracle Support Document 1383621.1, Cloning Oracle E-Business Suite Release 12.2 with Rapid Clone, to register the new topology.

Execute AutoConfig on all application tier nodes

Login to all the application tier nodes and execute the the following scripts to sync up the context file and configuration files for the patch file systemSource the EBSapps.env file$ . ./u01/install/APPS/EBSapps.env patch
$ perl $AD_TOP/bin/adSyncContext.pl contextfile=$CONTEXT_FILE

The following command syntax works with AD/TXK Code Level D4 .
$ perl $FND_TOP/patch/115/bin/txkSetAppsConf.pl -ctxfile=$CONTEXT_FILE -outfile=$APPLRGF/TXK/conf.log

If you are a later version of the AD/TXK Code level, follow the instructions given in section 5.3.2.4-5.3.2.7 ( Register the new topology from the newly added application tier node) of My Oracle Support Document 1383621.1, Cloning Oracle E-Business Suite Release 12.2 with Rapid Clone, to register the new topology.

Section 5.3.2.24: Perform Sanity Tests

Perform the following sanity tests to check the health of the multi-node application tier system.

Start and stop the application tier processes from the current run file system. The processes must be started on the primary application tier node first followed by the secondary application tier nodes. The application tier processes can be started/stopped using the adstrtal.sh/adstpall.sh script from the <INST_TOP>/admin/scripts directory.
Sign on to Oracle E-Business Suite application from the multiple web entry points to make sure multiple web entry points work.
Choose a forms responsibility and launch forms.
Login to the WebLogic console and fusion middleware console using the WebLogic admin credentials. Make sure you can view all the managed servers in RUNNING status from the servers menu.
Submit concurrent requests to make sure the concurrent requests can be executed and their output/log can be viewed from the client.
Execute an empty online patching cycle using the online patching utility adop. An empty patching cycle can be executed from the run edition file system by following the instructions given in the table below.

Primary Application Tier


APPLICATION TIER HOSTNAME : finance.example.net
INSTALL BASE              :  /u01/install/APPS
Run File System ( FS1)    :  /u01/install/APPS/fs1
Patch File System ( FS2)  :  /u01/install/APPS/fs2
INST_TOP 1                :  /u01/install/APPS/fs1/inst
INST_TOP 2                :  /u01/install/APPS/fs2/inst
LOCATION OF THE RUN CONTEXT_FILE : /u01/install/APPS/fs1/inst/apps/VISION_finance/appl/admin/VISION_finance.xml
LOCATION OF THE PATCH CONTEXT_FILE : /u01/install/APPS/fs2/inst/apps/VISION_finance/appl/admin/VISION_finance.xml


Source the Run Edition Environment file
$ . ./u01/install/APPS/EBSapps.env run

$ adop phase=prepare

$ adop phase=cutover

SECTION 6: LIST OF EXTERNAL FACING E-BUSINESS SUITE PRODUCTS

Below is a list of Oracle certified E-Business Suite Release 12 products that can be deployed for external use. If you are planning on deploying a product that is not listed in the table below, log a Service Request with Oracle Support requesting certification of that product for external deployment. The "URL Firewall Rules" column indicate whether there are any special rules that need to be enabled in the URL FW for the product to function. An "Yes" in the column indicates there are special rules.

Product Name	Product ID	Product Code	Product Family	URL Firewall Rules
iSupplier Portal	208	POS	Procurement	Yes
Oracle Sourcing	1273	PON	Procurement	Yes
Oracle Receivables	1106	OIR	Financials	Yes
iRecruitment	1193	IRC	Human Resources	Yes
Oracle Time and Labor	310	OTL	Human Resources	Yes
Oracle Learning Management	810	OTA	Human Resources	Yes
Self Service Benefits	290	BEN	Human Resources	No
Self Service Human Resources	1566	SSHR	Human Resources	No
Oracle iSupport	381	IBU	CRM	Yes
Oracle iStore	384	IBE	CRM	Yes
Oracle Marketing	229	AMS	CRM	Yes
Oracle Partner Relationship Management	1065	PRM	CRM	Yes
Oracle Survey	1578	IES	CRM	Yes
Oracle Transportation	1060	FTE	Manufacturing	Yes
Oracle Contracts Core	154	OKC	Manufacturing	N/A
Oracle Service Contracts	432	OKS	Manufacturing	N/A
Oracle Collaborative Planning	1037	SCE	Manufacturing	Yes
Oracle User Management	1475	UMX	Application Object Library	No
Order Information Portal	660	ONT	Order Management	No
Oracle Sales for Handhelds	1558	ASP	CRM	Yes
Oracle Internet Expenses	397	OIE	Financials	No
Oracle Performance Management	2010	OPM	Human Resources	No
Compensation Workbench	4427	CWB	Human Resources	No
Oracle Payroll	506	PAY	Human Resources	No
Oracle Quoting	1296	QOT	CRM	No
Oracle Field Service Third Party Portal	747	FSE	CRM	No

Section 7: Oracle E-Business Suite Product Specific Configuration

Section 7.1: Set the Responsibility Trust Level and Update Required Profile Option Values

If any of the following products are installed and configured, you must refer to the respective documents as shown in the table below for more information on which responsibilities can be made externally accessible from the Internet.

Please refer to Section 4.3: Update List of Responsibilities for the necessary steps to make the responsibilities listed below available for the external users.

To Perform any product-specific profile settings, you must refer to the respective product documents shown below.

Product Name

Externally Accessible Responsibilities

Addtional Profile Settings

Additional Documents

iSupplier Portal

iSupplier Portal Full Access
POS Supplier Guest User
Plan to Pay Supplier View
Plan, Source, Pay Supplier View
Source to Pay Supplier View
Supplier Profile Manager
Procure to Pay Supplier View

POS: External URL
POS: Internal URL

Oracle iSupplier Portal Release Notes (Document 1583748.1)
Enable Web Access By External Supplier Users to Oracle iSupplier Portal and Oracle Sourcing (Document 308271.1)

Oracle Sourcing

Sourcing Supplier

PON: External Applications Framework Agent
PON: External login URL

Oracle Sourcing Release Notes for Release 12.2.3 (Document 1605610.1 )
Enable Web Access By External Supplier Users to Oracle iSupplier Portal and Oracle Sourcing (Document 308271.1)

iSupport

iSupport Business User
iSupport Guest User
iSupport Individual User
iSupport Primary User
iSupport Site: Business User
iSupport Site: Individual User
iSupport Site: Guest User
iSupport Site: Primary User

Oracle iSupport Implementation Guide

iStore

IBE_CUSTOMER

IBE: iStore Secure URL
IBE: iStore Non Secure URL

Oracle iStore Implmentation Guide

iRecruitment

iRecruitment External Site Visitor
iRecruitment External Candidate
iRecruitment Employee Site Visitor
iRecruitment Employee Candidate
iRecruitment Agency

Oracle iRecruitment Implementation and User Guide

Oracle Learning Management

Learner Self-Service

Oracle Learning Management Implementation Guide

Oracle iReceivables

iReceivables Account Managament
iReceivables 2.0 Anonymous Internal

Oracle iReceivables Implementation Guide

Oracle Transportation Execution

Transportation Execution Carrier User

Oracle Transportation Execution User Guide

Oracle Partner Relationship Management

Partner Super User
Default Partner User

PV: Locator Server URL
PV: System Login URL
PV: iStore Login URL
PV:Self Service URL with Workflow Notification

Oracle Partner Management Implementation and Administration Guide

Oracle Marketing

None for this product

AMS : Server URL

Oracle Marketing Implementation Guide

Oracle Contracts Core

OKC: Contracts Online - External Party Access

Oracle Service Contracts

Service Contracts Electronic Renewals
Service Contracts Online Acceptance

Oracle Collaborative Planning

Supply Chain Collaboration Planner
Supply Chain Collaboration Manager

Oracle Collaborative Planning Implementation and User's Guide

Order Information Portal

Order Information External User

OM: Records on Summary Page for External Users
OM: Customer Service Feedback
OM: Customer Service Report Defect

Self Service Human Resource

Employee Self-Service
Manager Self-Service

Oracle Internet Expenses

Internet Expenses
Expenses Analysis and Reporting

Oracle Payroll

Online Payslip (For localizations)
W2 and W4 for US Legislation

Oracle Quoting

Quoting User

Oracle Field Service Third Party Portal

Field Service Technical Portal
Field Service Third Party Administrator Portal
Field Service Third Party Technician Portal

Oracle Sales for Handhelds

Wireless Sales User

Section 7.2: Additional Configurations for Oracle iStore

Section 7.2.1: Time-To-Live Setting for Cached Objects

iStore uses Java caching framework to cache frequently used objects in the JVM. Each JVM will have a copy of an object in the Java Cache. When an object is updated by one JVM, it is invalidated in all JVMs across all Applications tier servers.

At the present time, cache updates in the Applications internal application tier server will not get reflected in the external application tier server. There are a couple of options to work around this known issue:

Shutdown and restart the Oracle HTTP server/WebLogic Managed servers on the Applications external server when an object in a cache is updated on the internal application tier server. When JVMs are restarted, objects will be freshly fetched into the cache.
Set Time-To-Live values for certain cache components so that these cache objects are invalidated on a periodic basis. Cache objects get refreshed when they are accessed for the first time after an invalidation. Since Time-To-Live values themselves are cached, the Oracle HTTP server/WebLogic Managed servers on the external application tier server needs to be bounced once for the new values to take effect.The exact Time-To-Live values will depend upon business requirements, how often objects in a cache component are updated and what the tolerance level is for having stale objects in the cache. Information on setting up Time-To-Live interval is available at:
Oracle Applications CRM System Administrator's Guide in the Virtual Applications Documentation Library
Sections Managing Component Caches and Editing Component Cache Details.
iStore uses Java Cache extensively to cache product catalog objects. Information on iStore Cache Components is available at:
Oracle iStore Implementation and Administration Guide in the Virtual Applications Documentation Library
Section Component Caches for Oracle iStore in JTT.

Section 7.2.2: Deploying iStore Pages in HTTP and HTTPS Configuration

For better performance, it is recommended to deploy iStore public pages under HTTP and employ HTTPS only for those pages and processes that transmit sensitive data. In DMZ deployment, this requires the reverse proxy server to listen on two ports, one for HTTP and the other for HTTPS. Both the HTTP and HTTPS reverse proxy listeners should be configured to forward the requests to the external application tier server. In this configuration, values for profiles "IBE: iStore Non Secure URL" and "IBE: iStore Secure URL" should point to HTTP and HTTPS reverse proxy server URL respectively.

If iStore public pages are also deployed via HTTPS, values of both the profiles "IBE: iStore Non Secure URL" and "IBE: iStore Secure URL" should point to the HTTPS reverse proxy server and port and can not be left empty. Refer to section "Setting up Secure Socket Layer Connections" of OracleÂ iStore Implementation and Administration Guide in the Virtual Applications Documentation Library for more details.

Section 7.2.3: AltBatchValidateURL Setting for iStore Integration with Oracle Configurator

In a DMZ configuration, it is likely that the database installed in the intranet can not communicate with the external application tier server due to fact that the external application tier server http port is not opened on the firewalls that separate the intranet servers from dmz servers. In such situations, the AltBatchValidateURL should be set to the URL for the configurator servlet on the internal application middle tier server.

Section 7.2.4: iStore Restrictions on Multiple Domains

iStore profile options IBE_SECURE_URL and IBE_NON_SECURE_URL are set at the site level for an E-Business Suite environment.

Due to this restriction, deploying iStore in a DMZ configuration where the internal and external domains differ will result in intermittent losses of end-user session information and user redirects to the incorrect minisites. This known issue is expected to be resolved in future iStore releases.

Section 7.3: Forward Proxy Configurations

The DMZ Forward Proxy should be configured whether or not a DMZ Reverse Proxy is used, and must be configured to handle outbound DMZ-to-Internet and outbound DMZ-to-Intranet HTTP traffic.Oracle E-Business Suite Application Tier configured in the DMZ must have access to a forward proxy server. This is required by the external modules configured in the DMZ for connecting to external/internal sites to Perform certain tasks like resume parsing for iRecruitment. Other modules that are known to use the forward proxy are Oracle Transportation Management and Oracle partner relationship management.

Set the proxy variables in the applications context file as shown in the table below and run autoconfig:

Context Variables Name	Default Value	Changed Value	Description
s_proxyhost	null	myproxy.example.com	Forward Proxy Host
s_proxyport	null	80	Forward Proxy Port
s_proxybypassdomain	s_domainname	*.example.com	Forward Proxy Bypass Domain

All application tier nodes both in the DMZ and intranet must use the same proxy server . Please work with your system administrator in obtaining the correct value for the proxy variables.

Firewall Impact:

1.If the DMZ Forward Proxy is separated from the DMZ by a DMZ outbound firewall, then customer needs to change the DMZ outbound firewall configuration to allow for outbound DMZ-to-"DMZ Forward Proxy" HTTP communication.

2. If the DMZ Forward Proxy is within the DMZ, then the customer needs to change the DMZ outbound firewall configuration to allow for outbound "DMZ Forward Proxy"-to-Internet and outbound "DMZ Forward Proxy"-to-Intranet HTTP communication.

Section 7.4: Reverse Proxy Configurations

Note: Oracle does not certify specific reverse proxy solutions from third-party vendors. The instructions included in this document are generally applicable to third-party reverse proxy solutions, including (but not restricted to) Apache, Microsoft Proxy Server, and other products.Always use the latest version of the software wherever applicable for security reasons.

A reverse proxy server is an intermediate server that sits between a client and the actual web server and makes requests to the web server on behalf of the client. The client is unaware of the presence of the reverse proxy.

Benefits of using a reverse proxy server are:

Adds a level of isolation between the client and the actual server
Allows using standard web port numbers (80 and 443) on the external interface while running the actual web server on higher numbered ports thus avoiding having to start the actual web application server processes as root.
Allows certain rules (or filters) to limit the http requests that are presented to the actual web server
Optionally allows for caching of contents

A number of options exist for choosing a reverse proxy:

Use Oracle HTTP Server as a Reverse Proxy Server
Use Oracle Application Server Webcache
Use apache httpd from http://httpd.apache.org
Use any of a number of commercially available reverse proxies, which often provide some level of added security as well.

There are pros and cons for each of these solutions, and the customer must choose according to preferences, supportability, existing IT standards and local policies.

Sample instructions to configure a reverse proxy server are given in the following link

Document 380486.1, Configure Oracle WebCache as a reverse proxy server

Section 7.5: Configuring the URL Firewall

The purpose of the URL Firewall is to ensure that only URLs required for the externally exposed functionality can be accessed from the internet.

The URL firewall is implemented as a whitelist list of URLs required; any URL request that is not matched in the whitelist list is refused. This will limit the exposure of your Oracle E-Business Suite deployment by reducing the attack surface available to external parties.

The URL Firewall can be deployed on the external application tier or in the reverse proxy. If you are deploying a reverse proxy that can process mod_rewrite rules, we recommend that the URL Firewall be deployed on the reverse proxy in order to reject un-authorized requests as early as possible.

The URL Firewall is shipped as an apache configuration file containing rewrite rules interpreted by mod_rewrite. The URL Firewall configuration file (url_fw.conf) will be generated on all the application tiers by the AutoConfig utility. To Include this configuration file in Oracle HTTP Server configuration file (httpd.conf), Perform the following steps:

Change value of the autoconfig variable s_enable_urlfirewall. By default the value of this variable is set to '#' which indicates that the URL firewall is disabled. To enable the URL firewall, the pound sign '#' must be removed .

You must ensure that for nodes that are marked as external, this configuration file should be included in the http server configuration.

The file consists of blocks of URLs that may be required depending on the deployed product mix and ends with a rule that rejects the request if it has not been matched by one of the enabled rules. You will have to manually edit this file to enable the URLs in the block that corresponds to the product(s) you are deploying for external access.

The url_fw.conf file has the following blocks

INITIAL PAGE - defines the default start page
STATIC - static files such as images, stylesheets, javascript and html
COMMON - common components used by multiple products
LOCAL - required for local login
FORMS - if your product mix requires the use of Oracle Forms
XXX - where XXX is a product abbreviation

You will always need the STATIC, COMMON and LOCAL blocks. Depending on the product(s) you are deploying, you may need additional blocks of URLs enabled. This is summarized in the table below.

Product Name	Product Code	Product Family	Blocks Required
iSupplier Portal	POS	Procurement	POS
Oracle Sourcing	PON	Procurement	PON
Oracle iReceivables	OIR	Financials	OIR
iRecruitment	IRC	Human Resources	IRC
Oracle Time & Labor	OTL	Human Resources	OTL
Oracle Learning Management	OTA	Human Resources	OTA
Oracle iSupport	IBU	CRM	IBU
Oracle iStore	IBE	CRM	IBE + CZ* optional
Oracle Marketing	AMS	CRM	AMS
Oracle Partner Relationship Management	PRM	CRM	PRM
Oracle Survey	IES	CRM	IES
Field Sales	ASP	CRM	ASP
Oracle Transportation	FTE	Manufacturing	FTE
Oracle Contracts Core	OKC	Manufacturing	none
Oracle Service Contracts	OKS	Manufacturing	OKS
Personal Portfolio	IGP		IGP
Web Analytics	IBW		IBW
Oracle Collaborative Planning	SCE	Manufacturing	SCE+Forms
Access Gate Application for SSO	TXK	Techstack	AccessGate

*) iStore needs the CZ block if it is integrated with the Configurator.

In addition to uncommenting the blocks of URLs specified above you will have to consider and decide how to handle the following for your deployment:

Initial page - what page should be displayed when external users go to
Help - what should happen when external users click on the Help icon

The syntax of the ErrorDocument directive in url_fw.conf need modification (to use double quotes), if you have configured apache2 as the reverse proxy server.

Section 7.5.1: Configure Initial Page

In the shipping version of url_fw.conf external users will be presented with the standard Apps Login page when they go to / (actually http://yoursite.example.com ) on your external site.

If you are deploying products that allow users to surf part of the site prior to authentication, presenting them with a login page may not make any sense. For example if you are deploying iStore, users have an expectation to be able to browse the goods without logging in. If you are deploying iRecruitment, maybe external users can browse available job postings prior to identifying themselves.

If you are integrating the external access to E-Business Suite via an existing company website, you may want to include a new page with your corporate branding and links to the appropriate entry points of Oracle Applications.

To change the initial (/) page, locate the INITIAL PAGE block and change the first line in that block to provide the page of your choice.

RewriteRule   ^/$   /OA_HTML/AppsLogin [R,L]

the rule says: upon a request for /, redirect ([R]edirect) to /OA_HTML/AppsLogin and stop further rewriting ([L]ast).

If your deployment is only iRecruitment or only iStore the above rule could be replaced with one of the following

RewriteRule   ^/$   /OA_HTML/IrcVisitor.jsp [R,L]orRewriteRule   ^/$   /OA_HTML/ibeCZzpHome.jsp [R,L]

For help in selecting an appropriate initial page, see the Implementation Guide for the products you are deploying externally.

Section 7.5.2: URL Firewall Configuration for Webservices Deployed in the DMZ

A Webservices URL Firewall configuration file url_fw_ws.conf must be generated in the application tier nodes that host the external modules to prevent unauthorized access to SOAprovider servlet. This configuration file can be generated by Performing the following steps:

$ txkrun.pl -script=GenWebServiceUrlFwConf

Successful completion of the the script given above will generate url_fw_ws.conf at Oracle HTTP Server Instance Home . This configuration file will then be automatically included when autoconfig is executed on the external nodes.

Section 8: Oracle E-Business DMZ Configuration in SSO Enabled Environment (Optional)

The architecture diagram shown below represents an Oracle E-Business Suite installation in a DMZ with global Single sign on enabled. The single sign on use Oracle Access Manager and it can be integrated with any of the DMZ topologies documented in this note. For more information , refer to My Oracle Support Knowledge Document 1576425.1, Integrating Oracle E-Business Suite Release 12.2 with Oracle Access Manager, in section "Deploy Oracle E-Business Suite AccessGate in a Demilitarized Zone (DMZ)" .

Known Issues

Date	Known Issue	Resolution	Fixed in
February 24, 2014	Support for clusters based on Web Entry Point:	The workaround is to the ensure that the following configuration updates are made:. Customize the Oracle E-Business Suite applications context file on each node to remove the cluster definition for nodes that are not required to be in the cluster. For example see s_oacore_nodes, s_forms_nodes,s_oafm_nodes,s_forms-c4ws_nodes Customize the Oracle HTTP Server configuration files like mod_wl_ohs.conf, apps.conf present in the webtier instance home to remove the nodes that are not participating in the cluster configuration. Set DynamicServerList to OFF in mod_wl_ohs.conf . The 12.2.3 configuration is shipped with this setting. An example is given below to illustrate the change required in applications context file and config files. The example only mention about the oacore managed server setup. Similar changes must be done for all the managed servers. Perform the required changes on the run edition of the file E-Business Suite file system. The changes will be carried over automatically to the patch edition of the file system during an online patching cycle. Internal application tier nodes: finance.example.net, procurement.example.net Internal web entry point : employees.example.net External application tier nodes : sourcing.example.com, supplier.example.com External web entry point: partners.example.com The default configuration laid down by Rapid Install/Rapid Clone will include all nodes in the cluster configuration as shown below . This configuration is not desirable as the application tier nodes in the configuration belong to two different entry points. Applications context file <oacore_nodes oa_var="s_oacore_nodes">finance.example.net:7203,procurement.example.net:7203,sourcing.example.com:7203,supplier.example.com:7203</oacore_nodes> mod_wl_ohs.conf WebLogicCluster finance.example.net:7203,procurement.example.net:7203,supplier.example.com.com:7203,sourcing.example.com:7203 apps.conf BalancerMember http://finance.example.net:7203/OA_HTML/classes BalancerMember http://procurement.example.net:7203/OA_HTML/classes BalancerMember http://supplier.example.com:7203/OA_HTML/classes BalancerMember http://sourcing.example.com:7203/OA_HTML/classes You need to make manual updates to the application context files on all nodes and the configuration files ( mod_wl_ohs.conf/apps.conf) to remove the unwanted nodes from the cluster configuration. For example on nodes finance/procurement, the adjusted configuration will be as shown below: Applications context file <oacore_nodes oa_var="s_oacore_nodes">finance.example.net:7203,procurement.example.net:7203</oacore_nodes> mod_wl_ohs.conf WebLogicCluster finance.example.net:7203,procurement.example.net:7203 apps.conf BalancerMember http://finance.example.net:7203/OA_HTML/classes BalancerMember http://procurement.example.net:7203/OA_HTML/classes On the supplier/sourcing nodes , the adjusted configuration will be as shown below: Applications context file <oacore_nodes oa_var="s_oacore_nodes">sourcing.example.com:7203,supplier.example.com:7203</oacore_nodes> mod_wl_ohs.conf WebLogicCluster supplier.example.com.com:7203,sourcing.example.com:7203 apps.conf BalancerMember http://supplier.example.com:7203/OA_HTML/classes BalancerMember http://sourcing.example.com:7203/OA_HTML/classes	Fix not available yet

Change Record

Date	Description
17 Oct 2019	Minor updates for standards compliance
07 Nov 2014	NFS mount options updated Sequence numbering mismatch fixed
23 July 2014	SSO integration added.
30 June 2014	Major Revision.

Documentation Accessibility

For information about Oracle's commitment to accessibility, visit the Oracle Accessibility Program website at https://www.oracle.com/pls/topic/lookup?ctx=acc&id=docacc.

Access to Oracle Support

Oracle customers have access to electronic support through My Oracle Support. For information, visit https://www.oracle.com/pls/topic/lookup?ctx=acc&id=info or visit https://www.oracle.com/pls/topic/lookup?ctx=acc&id=trs if you are hearing impaired.

This software and related documentation are provided under a license agreement containing restrictions on use and disclosure and are protected by intellectual property laws. Except as expressly permitted in your license agreement or allowed by law, you may not use, copy, reproduce, translate, broadcast, modify, license, transmit, distribute, exhibit, perform, publish, or display any part, in any form, or by any means. Reverse engineering, disassembly, or decompilation of this software, unless required by law for interoperability, is prohibited.

The information contained herein is subject to change without notice and is not warranted to be error-free. If you find any errors, please report them to us in writing.

If this is software or related documentation that is delivered to the U.S. Government or anyone licensing it on behalf of the U.S. Government, the following notice is applicable:

U.S. GOVERNMENT END USERS: Oracle programs, including any operating system, integrated software, any programs installed on the hardware, and/or documentation, delivered to U.S. Government end users are “commercial computer software” pursuant to the applicable Federal Acquisition Regulation and agency-specific supplemental regulations. As such, use, duplication, disclosure, modification, and adaptation of the programs, including any operating system, integrated software, any programs installed on the hardware, and/or documentation, shall be subject to license terms and license restrictions applicable to the programs. No other rights are granted to the U.S. Government.

This software or hardware is developed for general use in a variety of information management applications. It is not developed or intended for use in any inherently dangerous applications, including applications that may create a risk of personal injury. If you use this software or hardware in dangerous applications, then you shall be responsible to take all appropriate fail-safe, backup, redundancy, and other measures to ensure its safe use. Oracle Corporation and its affiliates disclaim any liability for any damages caused by use of this software or hardware in dangerous applications.

Oracle and Java are registered trademarks of Oracle and/or its affiliates. Other names may be trademarks of their respective owners.

Intel and Intel Xeon are trademarks or registered trademarks of Intel Corporation. All SPARC trademarks are used under license and are trademarks or registered trademarks of SPARC International, Inc. AMD, Opteron, the AMD logo, and the AMD Opteron logo are trademarks or registered trademarks of Advanced Micro Devices. UNIX is a registered trademark of The Open Group.

This software or hardware and documentation may provide access to or information on content, products, and services from third parties. Oracle Corporation and its affiliates are not responsible for and expressly disclaim all warranties of any kind with respect to third-party content, products, and services. Oracle Corporation and its affiliates will not be responsible for any loss, costs, or damages incurred due to your access to or use of third-party content, products, or services.

REFERENCES

NOTE:1367293.1 - Enabling TLS in Oracle E-Business Suite Release 12.2

Tuesday, November 5, 2019