4/16/2014 Document 726953.

Case History: Implementing a Reverse Proxy Alone in a DMZ Configuration - R12 (Doc ID 726953.1)
Modified: 13-May-2013 Type: WHITE PAPER

In this Document

Abstract
History
Details
Setting up the Virtually External Node
Step 1: Create a Home for the Virtually External R12 Tier
Step 2: Create a new Context File for the Virtually External Release 12 Web Node
Step 3: Additional Manual Steps
Step 4: Verify and Edit the Newly Created Context File (Check for Port Conflicts)
Step 5: Final Edits to the Newly Created Context File (Reverse Proxy Setup)
Step 6: Instantiate the New Configuration Files and Profile Options Based on the New Context File
Step 7: Finishing Steps
Touring the New Environment
Outstanding Issues
References

APPLIES TO:

Oracle Applications Technology Stack - Version 12.0.3 to 12.1.3 [Release 12.0 to 12.1]
Information in this document applies to any platform.
Checked for relevance on 17-DEC-2012

ABSTRACT

In the spirit of Note:364439.1 and Note:438744.1, this whitepaper covers an example of an actual implementation of the complex
"Reverse Proxy Alone in the DMZ" configuration as described succinctly in Note:380490.1, section 2.4, Figure F9 for E-Business Suite
Release 12.

This is a companion document to Note:380490.1 and Note:364439.1 and is meant to be read only after a thorough understanding of both
notes has been attained. Note:380490.1 provides the technical overview of supported DMZ topologies and configuration while 364439.1
provides troubleshooting scripts and conceptual discussions to provide technical background information required for troubleshooting
such advanced topologies. These concepts will be expanded on in this practical example.

Note:380490.1-Oracle E-Business Suite Release 12 Configuration in a DMZ

Note:364439.1-Tips and Queries for Troubleshooting Advanced Topologies

HISTORY

Author : Dan Collier

Create Date 13-JUL-2008
Update Date 22-SEP-2010
Expire Date distant future

DETAILS

Setting up the Virtually External Node

Upgrading from a simple single-tier or even multiple tier environment to a DMZ or other advanced topology is extremely difficult without
some sort of preconceived plan in writing. When requesting support for an advanced configuration, customers should expect that a
request for a topology diagram will be made before any advice beyond the generic can be offered. The "Reverse Proxy Alone in the DMZ"
topology is no exception.

https://support.oracle.com/epmos/faces/DocumentDisplay?_adf.ctrl-state=url5rdg1r_188&id=726953.1 1/9
4/16/2014 Document 726953.1
As always, the drawing should show each machine that is part of the instance, to include each server, firewall, and hardware load
balancer (if any) with each described by their name, alias (if any), IP address, and the type of node installed (database, apache, forms,
etc.) with appropriate version information. In general, the drawing should look something like those featured in Note 380490.1 and the
top of Note 364439.1 with appropriate labels specific to the customer configuration. The problems most often faced are configuration
related and it is not possible to know from the traces and configuration files where the functionality goes awry without a previous
understanding of what it should look like. When troubleshooting, we start with the drawing and confirm that the various configuration
parameters match the drawing.

In the above conceptual drawing, the classic DMZ configuration is split. Within the DMZ there is only the reverse proxy server, while
within the internal network a single server makes use of the shared APPL_TOP and shared ORACLE_HOME technology to host and
effectively perform the functions of both the internal as well as the external web tier. This concept is entirely different from virtual web
hosts because the server hosts two instances of the Oracle Application Server 10g using shared binaries, but entirely separate log and
configuration files.

Initially, the internal web tier should already have an entry in the fnd_nodes table with the IP address of the server itself. When the
configuration is complete, the virtually external web tier will be registered in the fnd_nodes table with the IP address of the reverse proxy
server by using the new AutoConfig variable s_server_ip_address. In this case, the term "virtually external" is used to denote the fact
that the external web node, in common DMZ nomenclature, is physically located on the internal server within the internal network while
appearing to Internet users to be a standalone, external server in the DMZ.

For background information on the use of shared ORACLE_HOME and shared APPL_TOP technology beyond this special case, see the
following note:

Note 384248.1-Sharing the Application Tier File System in Oracle E-Business Suite 12

The virtually external web tier will still be run as the same applmgr user as the internal tier on this same server. Attempting to do this as
another operating system user is difficult. Normally a shared APPL_TOP gets its permissions via an NFS share rule, but we won't be
sharing via NFS in this case; the shared architecture of Note:380490.1/Section 2.4 is a clever derivation of this. For this virtually external
web tier, the first step is to create a config directory ahead of time. In a normal, shared environment this would be on a separate server,
but in this case it is on this same server.

For this topology, a reverse proxy server is required to isolate the internal/virtually external nodes from the Internet. For this exercise,
my reverse proxy was created using the following note:

Note 380486.1-Installing and Configuring Web Cache 10g and Oracle E-Business Suite 12

Step 1: Create a Home for the Virtually External R12 Tier

https://support.oracle.com/epmos/faces/DocumentDisplay?_adf.ctrl-state=url5rdg1r_188&id=726953.1 2/9
4/16/2014 Document 726953.1
When using a shared filesystem, as covered by the referenced notes, not everything is shared. For example, the new node will need to
have its own AutoConfig context file, environment files, and configuration files. Where you choose to put these is a matter of personal
choice; just keep it tidy. For example, when using Rapid Install to install an application node with a shared APPL_TOP, the node specific
files install into $INST_TOP by default. In my case, the config directory I created and specified is: /space/virtualext and is owned by the
applmgr user:

drwxr-x--- 2 appv121 dba 4096 Aug 9 22:58 virtualext

Step 2: Create a new Context File for the Virtually External Release 12 Web Node

Using the cloning script adclonectx.pl, as the existing web tier's applmgr user and my example of a config directory, the command syntax
is simply:

First:
cd $COMMON_TOP/clone/bin

Then, all on one line:

perl adclonectx.pl
contextfile=/space/v121/inst/apps/V121_dcoll12xc/appl/admin/V121_dcoll12xc.xml
outfile=/space/virtualext/V121_external.xml

In my case, the key questions from adclonectx.pl and my answers were:

Target System Hostname (virtual or normal) [dcoll12xc] : external

While the name of the virtually external web tier is technically arbitrary, it is common practice to use the name of the reverse proxy
server for the "Target System Hostname". This gives a more streamlined appearance so that when selecting profile options (much later)
at the Server/ServResp level, the illusion that the RP and the virtually external node are one and the same is preserved since the LOV list
will show the RP name as opposed to a name like "external". I personally prefer to keep these concepts separate and not have the name
of the RP ambiguously refer to the reverse-proxy server and also the apache listener working as the virtually external web tier.

I took the default for essentially all of the other questions. This is important to do since this is not a normal clone. In this case, you
definitely do want to use the same port pool as prompted by the adclonectx.pl script. Unlike a typical clone, you are not going to clone
the database. You will be using the same database as the existing web tier. Also, remember that the username and group for
"Applications File System" should be the same applmgr user you used to run adclonctx.pl (which is the default) for the reasons discussed
earlier.

When adclonectx.pl finished, it said:

The new APPL_TOP context file has been created :

/space/virtualext/V121_external.xml

Log file located at /space/virtualext/log/CloneContext_08091724.log

contextfile=/space/virtualext/V121_external.xml
Check Clone Context logfile /space/virtualext/log/CloneContext_08091724.log
for details.

Troubleshooting Tip:
The adclonectx.pl script may seem to hang after asking about the port values. The perceived hang is largely due to the script being
so chatty earlier. At this point, it is actually busy building the context file and writing quite a bit of useful information to the
CloneContext file it mentioned and the portpool.lst in the out directory just above the log directory where the CloneContext.log was
written. You can "tail -f" these if you get concerned.

Step 3: Additional Manual Steps

In order to successfully run AutoConfig in step 5, there are directories referenced in the newly created AutoConfig context file that must
be created ahead of time.

3a. Create the s_config_home directory per the following example:

Get the name of the directory needed for s_config_home:

https://support.oracle.com/epmos/faces/DocumentDisplay?_adf.ctrl-state=url5rdg1r_188&id=726953.1 3/9
4/16/2014 Document 726953.1
> grep s_config_home /space/virtualext/V121_external.xml
<config_home oa_var="s_config_home">/space/v121/inst/apps/V121_external< /config_home>

and then create the directory:

/space/v121/inst/apps> mkdir /space/v121/inst/apps/V121_external

/space/v121/inst/apps> ls -l

drwxr-x--- 14 appv121 dba 4096 Jul 4 04:40 V121_dcoll12xc

drwxr-xr-x 2 appv121 dba 4096 Aug 10 00:13 V121_external

3b. Similar to the above example, also create directories for the following:

s_ora_config_home
s_logs_dir
s_pids_dir

Step 4: Verify and Edit the Newly Created Context File (Check for Port Conflicts)

As per Note:380490.1, several parameters must be manually modified. The first are the various ports which must be modified so as to
not conflict with the existing, internal web tier. MOST of these ports will remain the same. You can use the below example to determine
what ports to change.

An amusing method for determining what ports on the virtually external tier will likely conflict with the existing tier is to borrow a tool
from the Rapid Installation Wizard.

4a. Start the internal web tier to make the used ports busy:

> adopmnctl.sh startall

> adopmnctl.sh status

You are running adopmnctl.sh version 120.4.12000000.3

Checking status of OPMN managed processes...

Processes in Instance: V121_dcoll12xc.dcoll12xc.us.oracle.com

-------------------+--------------------+---------+---------
ias-component | process-type | pid | status
-------------------+--------------------+---------+---------
OC4J | oafm | 4912 | Alive
OC4J | forms | 4911 | Alive
OC4J | oacore | 4910 | Alive
HTTP_Server | HTTP_Server | 4909 | Alive

4b. Check for conflicts using the PortPool check utility:

As always, this should be run as applmgr from the applmgr environment.

> which java

/space/v121/apps/tech_st/10.1.3/appsutil/jdk/jre/bin/java

> grep s_port_pool /space/virtualext/V121_external.xml

<PORT_POOL oa_var="s_port_pool">0</PORT_POOL>

In the following command, the "-e" parameter refers to the context file and the "-pool" parameter refers to the value of s_port_pool
within that context file. In my case the command becomes the following since my context file had s_port_pool of 0:

> java oracle/apps/ad/util/PortPool -e /space/virtualext/V121_external.xml -pool 0

Log file located at PortPool_08091845.log
PORT POOL 0 is in use

4c. Now check the above log for conflicts (using your own log file name, of course).

> grep RC-50204 PortPool_08091845.log

RC-50204: Error: - Web SSL Port in use: Port Value = 4443
RC-50204: Error: - ONS Local Port in use: Port Value = 6100
RC-50204: Error: - ONS Remote Port in use: Port Value = 6200

https://support.oracle.com/epmos/faces/DocumentDisplay?_adf.ctrl-state=url5rdg1r_188&id=726953.1 4/9
4/16/2014 Document 726953.1
RC-50204: Error: - ONS Request Port in use: Port Value = 6500
RC-50204: Error: - Web Listener Port in use: Port Value = 8000
RC-50204: Error: - OC4J JMS Port Range for Oacore in use: Port Value = 23000
RC-50204: Error: - OC4J JMS Port Range for Forms in use: Port Value = 23500
RC-50204: Error: - OC4J JMS Port Range for Oafm in use: Port Value = 24500
RC-50204: Error: - OC4J AJP Port Range for Oacore in use: Port Value = 21500
RC-50204: Error: - OC4J AJP Port Range for Forms in use: Port Value = 22000
RC-50204: Error: - OC4J AJP Port Range for Oafm in use: Port Value = 25000
RC-50204: Error: - OC4J RMI Port Range for Oacore in use: Port Value = 20000
RC-50204: Error: - OC4J RMI Port Range for Forms in use: Port Value = 20500
RC-50204: Error: - OC4J RMI Port Range for Oafm in use: Port Value = 25500

For the most part, the specific ports DO have to be changed, but the port ranges do not. In almost all cases, the port ranges supplied are
large enough to comfortably accomodate both web tiers.

Note that in the R12 AutoConfig context file syntax, the value that is used in the configuration files is between the "> <", but the PortPool
checker checks the value in quotes after "base=" so you have to change both values if you want to run the PortPool check over again to
check your work:

For example:

Before: (this isn't the only 4443 in the context file)

<web_ssl_port oa_var="s_webssl_port" oa_type="PORT" base="4443" step="1"

range="-1" label="Web SSL Port">4443</web_ssl_port>

After:

<web_ssl_port oa_var="s_webssl_port" oa_type="PORT" base="4444" step="1"

range="-1" label="Web SSL Port">4444</web_ssl_port>

.......
Before: (notice both are 8000)

<web_port oa_var="s_webport" oa_type="PORT" base="8000" step="1" range="-1"

label="Web Listener Port">8000</web_port>
<activewebport oa_var="s_active_webport" oa_type="DUP_PORT" base="8000"
step="1" range="-1" label="Active Web Port">8000</activewebport>

Troubleshooting Tip:
If a port number is called out as busy, the PortPool program will only call out the first entry in the context file that uses that port.
There may be other entries also using that port such as in my case where "Web SSL Port" was called out, but the following
parameter ALSO had to be changed:

<httpslistenparameter oa_var="s_https_listen_parameter">4443</httpslistenparameter>

This oversight on an early trial run through this procedure had caused apache to fail to start because:

[crit] (98)Address already in use: make_sock: could not bind to port 4443

Re-running PortPool to check your work even after your changes DOES find problems like this.

Step 5: Final Edits to the Newly Created Context File (Reverse Proxy Setup)

Towards the top of the context file are numerous entries of the form "s_isXXX" which may be set to either yes or no since they were
copied from the original context file. These indicate the purpose of the node and for this example the virtually external tier is only a web
node and should be changed appropriately:

<TIER_DB oa_var="s_isDB">NO</TIER_DB>
<TIER_ADMIN oa_var="s_isAdmin">NO</TIER_ADMIN>
<TIER_WEB oa_var="s_isWeb">YES</TIER_WEB>
<TIER_FORMS oa_var="s_isForms">NO</TIER_FORMS>
<TIER_NODE oa_var="s_isConc">NO</TIER_NODE>

https://support.oracle.com/epmos/faces/DocumentDisplay?_adf.ctrl-state=url5rdg1r_188&id=726953.1 5/9
4/16/2014 Document 726953.1
<TIER_FORMSDEV oa_var="s_isFormsDev">NO</TIER_FORMSDEV>
<TIER_NODEDEV oa_var="s_isConcDev">NO</TIER_NODEDEV>
<TIER_WEBDEV oa_var="s_isWebDev">YES</TIER_WEBDEV>

Continuing on with Note:380490.1, option 2.4:

1. Set the webentry point, s_webentryhost, to the reverse proxy server hostname.

2. Set the webentry domain, s_webentrydomain, to the domain name of the reverse proxy server.

3. Set the active webport, s_active_webport, to the reverse proxy listener port.

4. Set the webentry protocol, s_webentryurlprotocol, to the webentry point protocol e.g.; "http" or "https".

5. Set the login page, s_login_page, to <webentry protocol>://<webentry point>.<webentry domain>:<active webport>. Replace
<webentry protocol>, <webentry point>, <webentry domain>, and <active webport> with their respective values.

6. Set the reverse proxy server address, s_server_ip_address to the IP address of the reverse proxy server.

7. Confirm that the value of s_oc4j_cluster_nodes indicates the actual middle tier and free port and not the name of the reverse proxy
server. For example:

Original (clearly wrong):

<oc4j_cluster_nodes
oa_var="s_oc4j_cluster_nodes">external.us.oracle.com:6200</oc4j_cluster_nodes>

Change (Use internal tier hostname and new port. This port is the same as the s_ons_remoteport which may be busy. See "Outstanding
Issues 1, below) :

<oc4j_cluster_nodes
oa_var="s_oc4j_cluster_nodes">dcoll12xc.us.oracle.com:6201</oc4j_cluster_nodes>

8. If your reverse proxy server is also working as an SSL accelerator, then remove the '#' to use ssl_terminator.conf in ssl terminated
environments. In XML syntax, this means:

Change the following line from this:

<sslterminator oa_var="s_enable_sslterminator">#</sslterminator>
to this:
<sslterminator oa_var="s_enable_sslterminator"/>

The need for this is detailed in Note:376700.1-Enabling SSL in Release 12

Step 6: Instantiate the New Configuration Files and Profile Options Based on the New Context File

6a. The DMZ configuration requires the use of the new ServResp profile option hierarchy for the profile options. If you haven't already
done so, change the profile options hierarchy type to ServResp by executing the txkChangeProfH.sql SQL script as shown below:

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

Troubleshooting Tip:
Note:364439.1 gives a long explanation of why this is necessary. The change can be seen via the "enabled query".

6b. Run AutoConfig.

Note that the "adautocfg.sh" wrapper script that you already have for the internal tier is tied to the context file for the internal tier. Until
you finish running AutoConfig, you won't have an "adautocfg.sh" script for the virtually external tier. Therefore, you must use the
"adconfig.sh" from $AD_TOP/bin which will prompt you for the context file name.

> $AD_TOP/bin/adconfig.sh
Enter the full path to the Context file: /space/virtualext/V121_external.xml
Enter the APPS user password: xxxx
....
AutoConfig completed successfully.

https://support.oracle.com/epmos/faces/DocumentDisplay?_adf.ctrl-state=url5rdg1r_188&id=726953.1 6/9
4/16/2014 Document 726953.1

Step 7: Finishing Steps

After AutoConfig completes successfully, there should be a new scripts directory just below the $INST_TOP such as the following:

> ls -l $INST_TOP/..
total 8
drwxr-x--- 14 appv121 dba 4096 Jul 4 04:40 V121_dcoll12xc
drwxr-xr-x 13 appv121 dba 4096 Aug 10 02:20 V121_external

In this example, V121_dcoll12xc is from my original, internal tier. V121_external is the newly created directory for the virtually external
R12 tier. You can start this new tier with the included adopmnctl.sh script and it will listen on the port you told it to listen on. This port
should be the same port that your reverse proxy server proxies to.

> ls $INST_TOP/../V121_external/admin/scripts
adalnctl.sh adformsctl.sh adopmnctl.sh gsmstart.sh mwactl.sh
adapcctl.sh adformsrvctl.sh adpreclone.pl ieo mwactlwrpr.sh
adautocfg.sh adoacorectl.sh adstpall.sh java.sh
adexecsql.pl adoafmctl.sh adstrtal.sh jtffmctl.sh

The ".." after INST_TOP in the above example is needed because the above 'ls' was done with the internal tier's environment sourced. It
is entirely safe to run these scripts from this environment because the scripts themselves will source the appropriate environment.

At this point you have a functioning, virtually external tier ready for DMZ configuration.

Touring the New Environment

In the existing, now shared, APPL_TOP/admin we have new environment files (Aug 12):

appv121:dc121xc:/space/v121/apps/apps_st/appl> ls -l *.env
-rwxr-x--- 1 appv121 dba 1057 Jul 6 06:48 APPSV121_dcoll12xc.env
-rw-r--r-- 1 appv121 dba 1047 Aug 12 23:24 APPSV121_external.env
-rwxr-x--- 1 appv121 dba 15852 Jul 6 06:48 V121_dcoll12xc.env
-rw-r--r-- 1 appv121 dba 15781 Aug 12 23:24 V121_external.env

Sourcing the sid_server env file sets the environment for the virtually external tier so that we can wander around. This is otherwise
unnecessary since the new scripts in the new scripts directory source them automatically.

appv121:dc121xc:/space/v121/apps/apps_st/appl> . ./V121_external.env

After this, a simple grep of the environment shows a number of useful environment variables (edited for content):

appv121:dc121xc:/space/v121/apps/apps_st/appl> env | grep ext | sort

ADMIN_SCRIPTS_HOME=/space/v121/inst/apps/V121_external/admin/scripts
APPLCSF=/space/v121/inst/apps/V121_external/logs/appl/conc
APPLFENV=V121_external.env
APPLTMP=/space/v121/inst/apps/V121_external/appltmp
CONTEXT_FILE=/space/virtualext/V121_external.xml
CONTEXT_NAME=V121_external
FND_SECURE=/space/v121/inst/apps/V121_external/appl/fnd/12.0.0/secure
FORMS_TRACE_DIR=/space/v121/inst/apps/V121_external/logs/ora/10.1.2/forms
FORMS_WEB_CONFIG_FILE=/space/v121/inst/apps/V121_external/ora/10.1.2/forms/server/appsweb.cfg
INST_TOP=/space/v121/inst/apps/V121_external
LOG_HOME=/space/v121/inst/apps/V121_external/logs
ORA_CONFIG_HOME=/space/v121/inst/apps/V121_external/ora

The LOG_HOME directory has the logfiles for this instance useful for troubleshooting if this doesn't start right off (edited for content):

appv121:dc121xc:/space/v121/inst/apps/V121_external/logs/ora/10.1.3> ls -lR
.:
drwxr-xr-x 2 appv121 dba 4096 Aug 29 00:00 Apache
drwxr-xr-x 5 appv121 dba 4096 Aug 10 02:19 j2ee
drwxr-xr-x 3 appv121 dba 4096 Aug 10 02:19 javacache
drwxr-xr-x 5 appv121 dba 4096 Aug 13 00:21 opmn

./Apache:
-rw-r--r-- 1 appv121 dba 359744 Aug 29 22:42 access_log.1219968000

https://support.oracle.com/epmos/faces/DocumentDisplay?_adf.ctrl-state=url5rdg1r_188&id=726953.1 7/9
4/16/2014 Document 726953.1
-rw-r--r-- 1 appv121 dba 255 Aug 18 16:13 error_log.1219017600

./j2ee:
total 12
drwxr-xr-x 3 appv121 dba 4096 Aug 10 03:04 forms
drwxr-xr-x 3 appv121 dba 4096 Aug 10 03:04 oacore
drwxr-xr-x 3 appv121 dba 4096 Aug 12 23:27 oafm

./j2ee/oacore:
total 4
drwxr-xr-x 2 appv121 dba 4096 Aug 10 03:04 oacore_default_group_1

./j2ee/oacore/oacore_default_group_1:
total 4072
-rw-r--r-- 1 appv121 dba 2052 Aug 22 05:31 application.log
-rw-r--r-- 1 appv121 dba 458 Aug 12 23:28 global-application.log
-rw-r--r-- 1 appv121 dba 123 Aug 12 23:28 jms.log
-rw-r--r-- 1 appv121 dba 12914 Aug 12 23:30 log.xml
-rw-r--r-- 1 appv121 dba 246 Aug 12 23:28 rmi.log
-rw-r--r-- 1 appv121 dba 41261 Aug 29 22:42 server.log
-rw-r--r-- 1 appv121 dba 123 Aug 12 23:28 system-application.log

./opmn:
total 272
drwxr-xr-x 2 appv121 dba 4096 Aug 10 03:04 forms_default_group_1
-rw-r--r-- 1 appv121 dba 740 Aug 12 23:27 HTTP_Server~1
drwxr-xr-x 2 appv121 dba 4096 Aug 10 03:04 oacore_default_group_1
drwxr-xr-x 2 appv121 dba 4096 Aug 10 03:04 oafm_default_group_1
-rw-r--r-- 1 appv121 dba 67508 Aug 29 22:41 OC4J~forms~default_group~1
-rw-r--r-- 1 appv121 dba 38348 Aug 29 22:21 OC4J~oacore~default_group~1
-rw-r--r-- 1 appv121 dba 123709 Aug 29 22:39 OC4J~oafm~default_group~1

./opmn/oacore_default_group_1:
total 8
-rw-r--r-- 1 appv121 dba 537 Aug 12 23:28 oacorestd.err
-rw-r--r-- 1 appv121 dba 225 Aug 12 23:29 oacorestd.out

Outstanding Issues

1. The PortPool test may not detect the port conflict with "s_ons_remoteport" and this will prevent OPMN from starting.

/space/v121/inst/apps/V121_external/logs/ora/10.1.3/opmn> more opmn.log

...
08/08/10 02:41:36 [ons-listener] 10.148.53.47,6200: BIND (Address already in use)

This can be fixed with just one more edit to the AutoConfig context file as noted in step 5, item 7.

Copyright � 2008 Oracle. All rights reserved. Oracle is a registered trademark of Oracle. Various product and service
names referenced herein may be trademarks of Oracle. All other product and service names mentioned may be
trademarks of their respective owners.

Disclaimer: This document is provided for information purposes only and the contents hereof are subject to change
without notice. Oracle does not warrant that this document is error-free, nor does it provide any other warranties or
conditions, whether expressed orally or implied in law, including implied warranties and conditions of merchantability or
fitness for a particular purpose. Oracle specifically disclaims any liability with respect to this document and no
contractual obligations are formed either directly or indirectly by this document. This document may not be reproduced
or transmitted in any form or by any means, electronic or mechanical, for any purpose, without the prior written
permission of Oracle.

REFERENCES

https://support.oracle.com/epmos/faces/DocumentDisplay?_adf.ctrl-state=url5rdg1r_188&id=726953.1 8/9
4/16/2014 Document 726953.1

https://support.oracle.com/epmos/faces/DocumentDisplay?_adf.ctrl-state=url5rdg1r_188&id=726953.1 9/9