Document 1375670.1-DMZ

11/27/2019 Document 1375670.
1
Copyright (c) 2019, Oracle. All rights reserved. Oracle Confidential.
Oracle E-Business Suite Release 12.2 Configuration in a DMZ (Doc ID 1375670.1)
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
Oracle E-Business Suite Release 12.2 Architecture in a DMZ Configuration
Terminology
Section 2: Deployment Options
Section 2.1 DMZ Configuration with an Internal and an External Application Tier
Section 2.2 DMZ Configuration with a Reverse Proxy and an External Application Tier
Section 2.3: DMZ Configuration with Internal and External Application Tiers in the Intranet Sharing the
Application Tier File System
Section 2.4: DMZ Configuration with Multiple Internal/External Application Tiers in the Intranet and DMZ
Section 3: Required Patches for DMZ Configuration
Section 4: Common Configuration Steps for any Deployment Type
Section 4.1: Update Hierarchy Type
Section 4.2: Enable Distributed Oracle Java Object Cache Functionality
Section 4.3: Update Node Trust Level
Section 4.4: Update List of Responsibilities
Section 4.5: Configuring the Web Entry Point for Any Deployment Scenario
Section 4.6: Enable Distributed Oracle Java Object Cache Functionality
Section 4.7: SSH Connectivity Requirements for Online Patching
Section 5: Detailed Instructions to Configure the Supported Topologies
Section 5.1: DMZ Configuration with a Reverse Proxy and an External Application Tier
Section 5.1.1: Required Oracle E-Business Suite Patches
Section 5.1.2: Instructions to Add Additional Application Tier Nodes
Section 5.2: DMZ Configuration With Internal and External Application Tiers in the Intranet Sharing the Same
File System
Section 5.3: DMZ Configuration with Multiple Internal/External Application Tiers in the Intranet and DMZ
Section 6: List of External Facing Oracle E-Business Suite Products
Section 7: Oracle E-Business Suite Product Specific Configuration
Section 7.1: Set the Responsibility Trust Level and Update Required Profile Option Values
Section 7.2: Additional Configurations for Oracle iStore
Section 7.3: Forward Proxy Configurations
Section 7.4: Reverse Proxy Configurations
Section 7.5: Configuring the URL Firewall
Section 8: Oracle E-Business Suite DMZ Configuration in SSO Enabled Environment
Related Documentation
Known Issues
Change Record
SECTION 1: OVERVIEW
https://support.oracle.com/epmos/faces/DocumentDisplay?_adf.ctrl-state=mycvoxfi5_506&id=1375670.1 1/74
11/27/2019 Document 1375670.1
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.
11/27/2019 Document 1375670.1
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
11/27/2019 Document 1375670.1
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
11/27/2019 Document 1375670.1
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:
1. Define server level profile values required for distinct Web entry points for internal and external users
2. Restrict access to a limited set of Oracle Applications responsibilities for users logging in via the Internet
3. Implement URL firewall to restrict access to only the subset of URLs required for external acces
Online Patching specific configuration requirements:
1. 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.
2. 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 .
11/27/2019 Document 1375670.1
3. 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.
4. 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.
11/27/2019 Document 1375670.1
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
1. Ports 7001 and 7002 are the WebLogic Administration Server ports for the run and patch edition of the application tier
file system.
2. 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
11/27/2019 Document 1375670.1
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:
1. Restrict access to a limited set of Oracle Applications responsibilities for users logging in via the Internet
2. Allow user access to only Oracle E-Business Suite Release 12 products that can be deployed for Internet access
3. Mask external application tier details from external users with the use of a reverse proxy server.
4. Terminate SSL connection at the reverse proxy if required
5. 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
11/27/2019 Document 1375670.1
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.
11/27/2019 Document 1375670.1
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.
1. 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.
2. 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.
11/27/2019 Document 1375670.1
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- Follow Instructions in Document 1617461.1 to apply the
Business suite required patches. If an update patch for AD/TXK is available,
AD/TXK Delta apply those instead of the minimum code level mentioned
4 Patches 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
11/27/2019 Document 1375670.1
User Profile Name Internal Name
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
11/27/2019 Document 1375670.1
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:
1. Login to Oracle E-Business Suite as sysadmin user using the internal URL
2. Select the System Administrator Responsibility
3. Select Profile / System
4. From the 'Find system profile option Values' window, select the server that you want to designate as the external web
tier
5. 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.
6. Set the value of this profile option to External at the server
level. The site level value should remain set to Normal
11/27/2019 Document 1375670.1
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:
1. Login to Oracle E-Business Suite as sysadmin user using the internal URL
2. Select System Administrator Responsibility
3. Select Profile / System
4. 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
5. 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.
6. Set the value of this profile option for the chosen responsibility to External at the responsibility
level. The site-level
value should remain Normal.
7. Repeat for all responsibilities that you want to make available from the external application tier.
11/27/2019 Document 1375670.1
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 values
s_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.
11/27/2019 Document 1375670.1
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:
1. 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.
2. 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.
3. 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.
)
4. 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.
5. 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.
11/27/2019 Document 1375670.1
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
Section 2.1 DMZ Configuration with an Internal and an External Application Tier
Section 2.2 DMZ Configuration with a Reverse Proxy and an External Application Tier
The architecture diagram shown below in this section represents this setup.
11/27/2019 Document 1375670.1
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
FMW_HOME 1 : /u01/install/APPS/fs1/FMW_Home
11/27/2019 Document 1375670.1
INST_TOP 1 : /u01/install/APPS/fs1/inst
APPLICATION TIER HOSTNAME : supplier.example.com

NODE_TYPE : External
Web Entry Points
INTERNAL WEB ENTRY POINT : http://finance.example.net:80/
EXTERNAL WEB ENTRY POINTS : https://partners.example.com:443/
Apply the required Oracle E-Business Suite patches as mentioned in Section 3: Required Patches for DMZ Configuration of this
document.
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
SID : VISION

11/27/2019 Document 1375670.1
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.

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 :
$ 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.

11/27/2019 Document 1375670.1
Switch the hirearchy type of the profile options to be of type server-responsibility
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:

Source the Run file system env file
$ $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
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.)
11/27/2019 Document 1375670.1
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
11/27/2019 Document 1375670.1
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
Target System File Edition type [patch]: patch

11/27/2019 Document 1375670.1

1. /usr/tmp
2. /usr/tmp
4. /usr/tmp
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

/u01/install/APPS/fs1/inst/apps/VISION_supplier/appl/admin/VISION_supplier.xml
Reverse Proxy CONFIGURATION
RP WEBENTRY PROTOCOL : https

RP HOSTNAME : partners
RP DOMAINNAME : example.com
11/27/2019 Document 1375670.1
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<
<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

Execute Autoconfig on the run file system
$ $INST_TOP/admin/scripts/adautocfg.sh
Upload the Patch file system context file to the Database
$ $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 system
Source the EBSapps.env file
11/27/2019 Document 1375670.1
$ 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

file and configuration files for the patch file system

section 5.3.2.4-5.3.2.7 (Register the new topology from the newly added application tier
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:
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.
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.
from the client.

11/27/2019 Document 1375670.1
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.
Database Tier
SID : VISION
11/27/2019 Document 1375670.1

Non-Editioned File System (fs_ne) : /u01/install/APPS/fs_ne
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


APPLICATION TIER HOSTNAME : sourcing.example.com

Web Entry Points
INTERNAL WEB ENTRY POINT : http://employees.example.net:80/
document.
Section 5.2.2: Instructions to add additional application tier nodes
11/27/2019 Document 1375670.1
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.
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
Database Tier
SID : VISION

Section 5.2.2.1: Perform Sanity Tests On the Primary Application Tier Node
new nodes, you must ensure the integrity of the primary application tier node. Few of the tasks that you must Perform before
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
from the client.

11/27/2019 Document 1375670.1
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..

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.

11/27/2019 Document 1375670.1
LBR CONFIGURATION
LBR WEBENTRY PROTOCOL : http

LBR HOSTNAME : employees
LBR DOMAINNAME : example.net
LBR ENTRYPORT : 80
<webentryurlprotocol oa_var="s_webentryurlprotocol">http</webentryurlprotocol>
<webentryhost oa_var="s_webentryhost">employees</webentryhost>
<webentrydomain oa_var="s_webentrydomain">example.net</webentrydomain>
<login_page oa_var="s_login_page">http://employees.example.net:80/OA_HTML/AppsLogin</login_page>
oa_var="s_endUserMonitoringURL">http://employees.example.net:80/oracle_smp_chronos/oracle_smp_chronos_sdk.gif</
<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.


Section 5.2.2.5: Update the Hirearchy Type
11/27/2019 Document 1375670.1

Switch the hirearchy type of the profile options to be of type server-responsibility
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
this document.
This is required to package the Oracle Fusion Middleware components and its configuration. Perform the commands shown

11/27/2019 Document 1375670.1
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
Note:
parameter)
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.
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.

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)
11/27/2019 Document 1375670.1
/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.

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
finance.example.net:/u01/install/oraInventory .
11/27/2019 Document 1375670.1
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 fstab
finance.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
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 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

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
/u01/install/APPS/pairs/supplier
/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.g
s_external_url=http://employees.example.net:80
s_login_page=http://employees.example.net:80/OA_HTML/AppsLogin
[Instance Specific]
11/27/2019 Document 1375670.1
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.

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.
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_forms-c4ws_display=supplier:0.0

s_apcstatus=enabled
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.

11/27/2019 Document 1375670.1
[Instance Specific]
s_temp=/u01/install/APPS/fs1/inst/apps/VISION_sourcing/temp
s_contextname=VISION_sourcing
s_hostname=sourcing
s_cphost=finance
s_webhost=sourcing
s_config_home=/u01/install/APPS/fs1/inst/apps/VISION_sourcing
s_forms-c4ws_display=sourcing:0.0

s_apcstatus=enabled
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
/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/supplier
/u01/install/APPS/pairs/sourcing

s_active_webport=80
[Instance Specific]
s_cphost=finance

s_apcstatus=enabled
11/27/2019 Document 1375670.1
For example for the node supplier, you would fill in the required parameters as shown below.

[Instance Specific]
s_temp=/u01/install/APPS/fs2/inst/apps/VISION_supplier/temp
s_contextname=VISION_supplier
s_hostname=supplier
s_cphost=finance
s_webhost=supplier
s_config_home=/u01/install/APPS/fs2/inst/apps/VISION_supplier
s_forms-c4ws_display=supplier:0.0

s_apcstatus=enabled
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.

[Instance Specific]
s_hostname=sourcing
s_cphost=finance
s_webhost=sourcing

11/27/2019 Document 1375670.1
s_apcstatus=enabled
Section 5.2.2.11: Prepare the Required Scripts for Adding the Secondary Application Tier Nodes

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

Create the following scripts for each node in their corresponding directories . For example for the
procurement node in /u01/install/APPS/pairs/procurement
addprocurementrun.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
pairsfile=/u01/install/APPS/pairs/procurement/pairs/VISION_finance_patch.txt \
For example for the sourcing node create the following scripts in /u01/install/APPS/pairs/sourcing
addsourcingrun.sh
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
pairsfile=/u01/install/APPS/pairs/sourcing/pairs/VISION_finance_patch.txt \
For example for the supplier node create the following scripts in /u01/install/APPS/pairs/supplier
11/27/2019 Document 1375670.1
addsupplierrun.sh
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
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

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
11/27/2019 Document 1375670.1
Section 5.2.2.13: Sync Up the Context File and Update Configuration On All Nodes

section 5.3.2.4-5.3.2.7 ( Register the new topology from the newly added application tier


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.
Sign on to Oracle E-Business Suite application from the multiple web entry points.
from the client.

11/27/2019 Document 1375670.1
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 .
11/27/2019 Document 1375670.1
Database Tier
SID : VISION

11/27/2019 Document 1375670.1

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


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/
document.
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.
11/27/2019 Document 1375670.1
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.
Database Tier
SID : VISION

Section 5.3.2.1: Perform Sanity Tests on the Primary Application Tier Node
new nodes, you must ensure the integrity of the primary application tier node. Few of the tasks that you must perform before
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
from the client.

11/27/2019 Document 1375670.1
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

s_atName : finance
s_shared_file_system : true

s_atName : finance

s_atName : supplier

s_atName : supplier
Section 5.2.2.3: Configure a Load Balancer Infront of the Primary Application Tier Node
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.

LBR CONFIGURATION
LBR WEBENTRY PROTOCOL : http

LBR HOSTNAME : employees
LBR DOMAINNAME : example.net
LBR ENTRYPORT : 80
11/27/2019 Document 1375670.1
<webentryurlprotocol oa_var="s_webentryurlprotocol">http</webentryurlprotocol>
<webentryhost oa_var="s_webentryhost">employees</webentryhost>
<webentrydomain oa_var="s_webentrydomain">example.net</webentrydomain>
<login_page oa_var="s_login_page">http://employees.example.net:80/OA_HTML/AppsLogin</login_page>
oa_var="s_endUserMonitoringURL">http://employees.example.net:80/oracle_smp_chronos/oracle_smp_chronos_sdk.gif</
<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:


Section 5.3.2.5: Update the Hirearchy Type

11/27/2019 Document 1375670.1
Switch the hierarchy type of the profile options to be of type server-responsibility
Section 5.3.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
this document.
This is required to package the Oracle Fusion Middleware components and its configuration. Perform the commands shown

Section 5.3.2.7: Add Secondary Internal Application Tier Nodes Using Shared File System
11/27/2019 Document 1375670.1
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
Note:
parameter.)
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.
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

the security requirements of your company. Also, the available options may differ for other
platforms.
/u01/install/APPS procurement.example.net(rw,sync,no_root_squash)
/u01/install/OraInventory procurement.example.net(rw,sync,no_root_squash)
system:
11/27/2019 Document 1375670.1
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 HOSTS TO WHICH FILE SYSTEM NEED TO BE MOUNTED : procurement.example.net


finance.example.net:/u01/install/APPS .
finance.example.net:/u01/install/oraInventory .
$ vi /etc/fstab
finance.example.net:/u01/install/APPS /u01/install/APPS nfs
finance.example.net:/u01/install/oraInventory /u01/install/oraInventory nfs
Section 5.3.2.10: Prepare the Pairs File for Addition of the Secondary Internal Application Tier Nodes
11/27/2019 Document 1375670.1
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 HOSTS TO WHICH FILE SYSTEM NEED TO BE MOUNTED : procurement.example.net

/u01/install/APPS/fs1/inst/apps/VISION_finance/appl/admin/VISION_finance_run.txt
$ mkdir -p /u01/install/APPS/pairs/procurement

s_active_webport=80
[Instance Specific]
s_cphost=finance

s_apcstatus=enabled
11/27/2019 Document 1375670.1
/u01/install/APPS/fs2/inst/apps/VISION_finance/appl/admin/VISION_finance_patch.txt


s_active_webport=80
[Instance Specific]
s_cphost=finance

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

SECONDARY APPLICATION TIER NODES : procurement.example.net

procurement node in /u01/install/APPS/pairs/procurement
addprocurementrun.sh
11/27/2019 Document 1375670.1
pairsfile=/u01/install/APPS/pairs/procurement/pairs/VISION_finance_run.txt \
addprocurementpatch.sh
pairsfile=/u01/install/APPS/pairs/procurement/pairs/VISION_finance_patch.txt \
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

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

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.
11/27/2019 Document 1375670.1
Note:
parameter.)
issues.
The same absolute path must be used for the shared file system mount points on each node..
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
Follow the instructions given below to configure the secondary application tier node run file system . Answer the prompts as
Seconday Application Tier Node
11/27/2019 Document 1375670.1
Target System File Edition type [run]: run

1. /usr/tmp
2. /usr/tmp
4. /usr/tmp
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
Follow the instructions given below to configure the secondary application tier node patch file system . Answer the prompts as

11/27/2019 Document 1375670.1
Target System File Editition type [patch]: patch

1. /usr/tmp
2. /usr/tmp
4. /usr/tmp
Section 5.3.2.17: Configure a Load Balancer Infront of the Secondary External Application Tier Node
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

11/27/2019 Document 1375670.1

LBR CONFIGURATION
LBR WEBENTRY PROTOCOL : https

LBR HOSTNAME : partners
LBR DOMAINNAME : example.com
LBR ENTRYPORT : 443
<webentryurlprotocol oa_var="s_webentryurlprotocol">https</webentryurlprotocol>
<webentryhost oa_var="s_webentryhost">partners</webentryhost>
<webentrydomain oa_var="s_webentrydomain">example.com</webentrydomain>
<login_page oa_var="s_login_page">https://partners.example.com:443/OA_HTML/AppsLogin</login_page>
oa_var="s_endUserMonitoringURL">https://partners.example.com:443/oracle_smp_chronos/oracle_smp_chronos_sdk.gif<
<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

the security requirements of your company. Also, the available options may differ for other
platforms.
/u01/install/APPS sourcing.example.com(rw,sync,no_root_squash)
/u01/install/OraInventory sourcing.example.com(rw,sync,no_root_squash)
11/27/2019 Document 1375670.1
system:
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


supplier.example.net:/u01/install/APPS .
supplier.example.net:/u01/install/oraInventory .
$ vi /etc/fstab
supplier.example.net:/u01/install/APPS /u01/install/APPS nfs
supplier.example.net:/u01/install/oraInventory /u01/install/oraInventory nfs
11/27/2019 Document 1375670.1
Section 5.3.2.20: Prepare the Pairs File for Addition of the Secondary External Application Tier Node
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

/u01/install/APPS/fs1/inst/apps/VISION_supplier/appl/admin/VISION_supplier_run.txt
$ 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
For example for the node sourcing, you would fill in the required parameters as shown below:

[Instance Specific]
s_hostname=sourcing
s_cphost=finance
s_webhost=sourcing

11/27/2019 Document 1375670.1
s_apcstatus=enabled
/u01/install/APPS/fs2/inst/apps/VISION_supplier/appl/admin/VISION_supplier_patch.txt

$ cp /u01/install/APPS/fs2/inst/apps/VISION_supplier/appl/admin/VISION_supplier_patch.txt
/u01/install/APPS/pairs/sourcing/VISION_sourcing_patch.txt
For example for the node sourcing, you would fill in the required parameters as shown below:

[Instance Specific]
s_hostname=sourcing
s_cphost=finance
s_webhost=sourcing

s_apcstatus=enabled
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

11/27/2019 Document 1375670.1
/u01/install/APPS/fs1/inst/apps/VISION_finance/appl/admin/VISION_supplier.xml
/u01/install/APPS/fs2/inst/apps/VISION_finance/appl/admin/VISION_supplier.xml
sourcing node in /u01/install/APPS/pairs/sourcing
addsourcingrun.sh
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 \
addsourcingpatch.sh
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 \
Section 5.3.2.22: Add the secondary external application tier node to the farm
SECONDARY APPLICATION TIER NODES : sourcing.example.com

/u01/install/APPS/fs1/inst/apps/VISION_sourcing/appl/admin/VISION_sourcing.xml
/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

11/27/2019 Document 1375670.1
Section 5.3.2.23: Sync Up the Context File and Update Configuration On All Nodes



Section 5.3.2.24: Perform Sanity Tests
Perform the following sanity tests to check the health of the multi-node application tier system.
Sign on to Oracle E-Business Suite application from the multiple web entry points to make sure multiple web entry
points work.
from the client.

11/27/2019 Document 1375670.1
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 Product URL Firewall Patch

Product Name Product Family
ID Code Rules Requirement
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 1065 PRM CRM Yes
Management
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
11/27/2019 Document 1375670.1
Product Product URL Firewall Patch

Product Name Product Family
ID Code Rules Requirement
Oracle User Management 1475 UMX Application Object No

Library
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 747 FSE CRM No

Portal
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.
Externally Accessible Addtional Profile

Product Name Additional Documents
Responsibilities Settings
iSupplier Portal
iSupplier Portal Full Access POS: External URL Oracle iSupplier Portal
POS Supplier Guest User POS: Internal URL Release Notes (Document
Plan to Pay Supplier View 1583748.1)
Plan, Source, Pay Supplier Enable Web Access By
View External Supplier Users to
Source to Pay Supplier Oracle iSupplier Portal and
View Oracle Sourcing (Document
Supplier Profile Manager 308271.1)
Procure to Pay Supplier
View
Oracle Sourcing
Sourcing Supplier PON: External Oracle Sourcing Release
Applications Notes for Release
Framework Agent 12.2.3 (Document 1605610.1
PON: External login )
URL Enable Web Access By
External Supplier Users to
Oracle iSupplier Portal and
11/27/2019 Document 1375670.1
Oracle Sourcing (Document

308271.1)
iSupport
iSupport Business User Oracle iSupport
iSupport Guest User Implementation Guide
iSupport Individual User
iSupport Primary User
iSupport Site: Business
User
iSupport Site: Individual
User
iSupport Site: Guest User
iSupport Site: Primary
User
iStore
IBE_CUSTOMER IBE: iStore Secure Oracle iStore Implmentation
URL Guide
IBE: iStore Non
Secure URL
iRecruitment
iRecruitment External Site Oracle iRecruitment
Visitor Implementation and User
iRecruitment External Guide
Candidate
iRecruitment Employee
Site Visitor
iRecruitment Employee
Candidate
iRecruitment Agency
Oracle Learning
Management Learner Self-Service Oracle Learning Management
Implementation Guide
Oracle iReceivables
iReceivables Account Oracle iReceivables
Managament Implementation Guide
iReceivables 2.0
Anonymous Internal
Oracle
Transportation Transportation Execution Oracle Transportation
Execution Carrier User Execution User Guide
Oracle Partner
Relationship Partner Super User PV: Locator Server Oracle Partner Management
Management Default Partner User URL Implementation and
PV: System Login Administration Guide
URL
PV: iStore Login
URL
PV:Self Service URL
with Workflow
Notification
Oracle Marketing
11/27/2019 Document 1375670.1
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 Oracle Collaborative Planning
Planner Implementation and User's
Supply Chain Collaboration Guide
Manager
Order Information
Portal Order Information OM: Records on
External User 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 Field Service Technical

Third Party Portal Portal
Field Service Third Party
Administrator Portal
Field Service Third Party
Technician Portal
Oracle Sales for

Handhelds Wireless Sales User
11/27/2019 Document 1375670.1
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:
1. 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.
2. 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.
11/27/2019 Document 1375670.1
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:
1. Use Oracle HTTP Server as a Reverse Proxy Server

2. Use Oracle Application Server Webcache
3. Use apache httpd from http://httpd.apache.org
4. Use any of a number of commercially available reverse proxies, which often provide some level of added security as
well.
11/27/2019 Document 1375670.1
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
11/27/2019 Document 1375670.1
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.
11/27/2019 Document 1375670.1
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)" .
Related Documentation
Oracle Tested Load Balancers, Firewalls and SSL Accelerators
Document 1388152.1, Overview of Single Sign -On Integration Options for Oracle E-Business Suite
Document 1576425.1, Integrating Oracle E-Business Suite 12.2 with Oracle Access Manager
Document 1371932.1, Integrating Oracle E-Business Suite 12.2 with Oracle Internet Directory 11gR1
11/27/2019 Document 1375670.1
Known Issues
Known
Date Resolution
Issue
February Support The workaround is to the ensure that the following configuration updates are made:
24, 2014 for .
clusters
based Customize the Oracle E-Business Suite applications context file on each node to remove the cluster d
on Web cluster. For example see s_oacore_nodes, s_forms_nodes,s_oafm_nodes,s_forms-c4ws_no
Entry
Point: Customize the Oracle HTTP Server configuration files like mod_wl_ohs.conf, apps.conf present i
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
An example is given below to illustrate the change required in applications context file and config files. The
server setup. Similar changes must be done for all the managed servers. Perform the required changes on
The changes will be carried over automatically to the patch edition of the file system during an online patch
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 configu
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.co
mod_wl_ohs.conf
WebLogicCluster finance.example.net:7203,procurement.example.net:7203,supplier.example.com.com:720
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 (
unwanted nodes from the cluster configuration. For example on nodes finance/procurement, the adjusted c
<oacore_nodes oa_var="s_oacore_nodes">finance.example.net:7203,procurement.example.net:7203</oa
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
11/27/2019 Document 1375670.1
On the supplier/sourcing nodes , the adjusted configuration will be as shown below:
<oacore_nodes oa_var="s_oacore_nodes">sourcing.example.com:7203,supplier.example.com:7203</oaco
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
Change Record
Date Description
17 Oct 2019 Minor updates for standards compliance
NFS mount options updated

07 Nov 2014
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.
Copyright © 2014, 2019, Oracle and/or its affiliates. All rights reserved.
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.
11/27/2019 Document 1375670.1
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
Didn't find what you are looking for?

Document 1375670.1-DMZ

Încărcat de

Informații document

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

Document 1375670.1-DMZ

Încărcat de

Drepturi de autor:

Formate disponibile

11/27/2019 Document 1375670.

Oracle E-Business Suite Release 12.2 Configuration in a DMZ (Doc ID 1375670.1)

Oracle E-Business Suite Release 12.2 Configuration in a DMZ

This document contains the following sections:

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

The following configuration options are supported:

Use of separate application tier for external usage

Internal Applications Tier

Web and Forms Services

External Applications Tier

Oracle HTTP Server

Primary Application Tier Node (or master node)

Secondary Application Tier Node (or slave Node)

Shared Application Tier Filesystem

An application tier file system consists of:

APPL_TOP file system (APPL_TOP and COMMON_TOP directories).

Java Object Cache (JOC)

WebLogic Proxy Plugin

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

Web Entry Point

Oracle Access Manager ( OAM)

Section 2: Deployment Options

An external application tier with the following configuration:

Online Patching specific configuration requirements:

Web traffic is labeled "http/https"

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

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

WebLogic Administration Server ports

SECTION 3: REQUIRED PATCHES FOR DMZ CONFIGURATION

Patch Number/Min Code Level Description Instructions

SECTION 4: COMMON CONFIGURATION STEPS FOR ANY DEPLOYMENT TYPE

4.1: Update Hierarchy Type (Required)

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

7. ICX: Oracle Discoverer Viewer Launcher ICX_DISCOVERER_VIEWER_LAUNCHER

8. Applications Help Web Agent HELP_WEB_AGENT

User Profile Name Internal Name

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

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

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

4.3: Update Node Trust Level (Recommended)

4.4: Update List of Responsibilities (Recommended)

CONTEXT VARIABLES TO BE UPDATED

SSL TERMINATED CONFIGURATION

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

4.7: SSH Connectivity Requirements for Online Patching (Required)

SECTION 5: DETAILED INSTRUCTIONS TO CONFIGURE THE SUPPORTED TOPOLOGIES

The topology shown above assume the following configuration:

Primary Application Tier

APPLICATION TIER HOSTNAME : finance.example.net

APPLICATION TIER HOSTNAME : supplier.example.com

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

Section 5.1.2: Instructions to Add Additional Application Tier Nodes