This is a paper that was developed as a collaboration with Bill Milligan at Level 3 in the late 90's. We extended the OFA concept of Cary Millsap to the 11.0.3 Apps.
1. An Optimal Flexible Architecture for Oracle Applications
Bill Milligan
Level(3) Communications
Mahesh Vallampati
Oracle Corporation
Introduction
Oracle Applications in its new Network Computing Architecture form offers significant benefits in
administration. We will propose a new standard for deploying multiple application instances in this new
architecture. Using these standards will promote a flexible and optimal way of deploying these
applications. This paper grew out of an effort to manage multiple 10.7SC and Release 11 ICA Instances
at a site with aggressive timelines. This standard helped us support the upgrade effort from 10.7 to
Release 11 in an efficient manner. These standards are basically guidelines we used in this project. The
motivations, challenges and necessities to develop this standard will become evident as we proceed.
Issues Which Impact Oracle Applications
Patching of Oracle Applications: Oracle Applications in its realistic sense needs to be patched and
upgraded on a regular basis to be supported by Oracle Corporation and also for Operational uses.
The Oracle Applications has various stacks, they are;
• The Database stack.
• The Web Stack which enables Network computing.
• The Application stack on the Database Server which are the concurrent programs
• The Application stack which includes the forms and HTML
• The customization stack which encompasses all of the above which are not a part of the standard
applications pack.
All these stacks have to be maintained efficiently.
Some commonly Used Terms explained.
• APPL_TOP: APPL_TOP refers to a directory on an Operating system where the Oracle Application
files are stored.
• APPLFENV: APPLFENV refers to the name of the Environment files and is executed to identify
Oracle Applications and its products.
2. Environments Needed to Support Oracle Applications
We recommend the following environments at the minimum to support Oracle Applications.
• PROD: This is the environment for production and is used for operational and business support.
This is the core system.
• PRODTEST: This is the environment for Production Support and is an exact replica of production.
It could lag production by a day to provide realistic support. This is the environment where
production problems are resolved and addressed.
• SANDBOX: As the name suggests, this environment is a place where people have the luxury of
testing their setup and other testing before actions are done in PRODTEST and then migrated to
PROD.
• DEVEL: This is the environment for developing customizations. This environment should be as
current as possible and hence it is important that customizations should be easily installable if they
have not been migrated to Production.
Other environments should be provided as and when needed to support upgrades, patches and other
functional issues.
Database Stack
“The OFA Standard for Open Systems” is a white paper from Oracle Corporation by Cary Millsap. This
standard has been well accepted and is well known. We recommend that this standard be adhered to
closely to achieve the benefits mentioned in the paper for the database stack.
Application Stack
The Application stack refers to the following components: Forms, Reports, Concurrent Programs, SQL
Code and messages on the Operating System. Most often than not, Operating Systems and hardware
resources are dedicated to supporting Oracle Applications. In the Network computing architecture, the
Forms and HTML are placed on multiple application servers. The Reports and Concurrent programs are
stored on the database server. In the Smart Client architecture, the Forms and HTML used to reside on
the clients, which caused administrative problems. The Network computing architecture offers significant
performance and administrative benefits.
3. The Concept of APPL_BASE
We recognize that the variable APPL_BASE points to a directory on the operating system. Readers
familiar with OFA will recognize the analogy to ORACLE_BASE. The most important difference
between Oracle OFA Architectures and Applications OFA Architectures is that the binary code has to be
replicated too in the case of Oracle Applications. That is to say that a unique Oracle Applications
instance is not just characterized by the database alone, but also with its APPL_TOP. For sake of
convenience, we will adopt /export/home/applmgr/APPS as the APPL_BASE. Further more, we will
assume that the Operating system is UNIX. Multiple Oracle APPL_TOP’s in Windows NT will require a
paper in itself. Due to the limitations of the file system sizes and other considerations, we will specify the
same mount point concept in OFA. The analogy here is that /uxxx/oradata/ORACLE_SID in OFA will be
/uxxx/appl/<release>/ORACLE_SID. Furthermore, for the sake of convenience and standard, we will
create symbolic links from the APPL_BASE directory.
(machine_name) [SID: PRDTEST]/export/home/applmgr/APPS>
CRL3 DEVR11 FAIL2 MRC PRDTEST PROD SANDBOX
PROD -> /d4/appl/R11.0/PROD
PRDTEST -> /d19/appl/R11.0/PRDTEST
SANDBOX -> /d13/appl/R11.0/SANDBOX
DEVR11 -> /d13/appl/R11.0/DEVR11
MRC -> /d18/appl/R11.0/MRC
FAIL2 -> /d6/appl/R11.0/FAIL2
CRL3 -> /d10/appl/R11.0/CRL3
Standardizing the installation of the Oracle RDBMS, JDK and Web server
on each node will provide additional benefits when it comes to
maintenance and portability of the applications. For example, install
the Oracle RDBMS in /u01/app/oracle/product/8.0.5 and the JDK in
/u01/app/jre on each node. The application’s adovars.env file will
never need to be modified. Example of code form adovars.env file.
JAVA_TOP="/d1/app/oracle/product/8.0.5/forms45/java"
export JAVA_TOP
OA_JDK_TOP="/d1/app/jre"
export OA_JDK_TOP
4. The following changes need to be made when cloning or porting an
application database between nodes.
Within the application change or verify the following;
• Site Name
• Application Web Agent
• Help System Base URL
• Change Passwords
Outside of the Application change or verify the following
• Create new DAD and register with PLSQL agent for Data Export and
Workflow Monitor utilities
• Database passwords
• Modify the applsys.env, adovars.env, <sid>.htm
Three Tier Architecture Standards
Oracle Applications Network Computing Architecture is basically a three-tier architecture with one mega
database server, multiple application servers and thin clients accessing the middle tier to access the
database server. For the application server we will present a slightly different variant of the APPL_TOP.
In the application server APPL_TOP, we will include the machine name as a part of the APPL_TOP.
For example, in a two-application server configuration, alpha and beta, where alpha and beta represent
two physical machines, we will establish APPL_TOP as follows.
/uxxx/<machine name >/<release>/<ORACLE_SID>.
In our implementation, where the machines were called steamboat and alta, the APPL_TOP’s looked
something like this. See Appendix A for a detailed output of the applmgr and oracle user environments.
Admin Tier (steamboat)
ACC_GEN az flm l3ar per
L3pay_trg.sql bom fnd l3fa pjm
PRDTEST.env ce ghr l3gl po
acc_gen chv gl l3pa qa
ad cn hxt l3pay rg
admin common icx l3per rla
adsetenv crp ifa l3po
shutapp_PROD
ak cs inv mfg ssp
alr cz ipa mrp
unload.cmd.log
ap dt ja msc veh
5. ar ec je oe wip
as eng jg ota
au fa jl pa
ax ff l3ap pay
Forms Tier (alta)
PRDTEST.env bom ff jg qa
ad ce flm jl rg
admin chv fnd mfg rla
aferror.log cn ghr mrp
sqlnet.log
ak common gl msc ssp
alr crp hxt oe
unload.cmd.log
ap cs icx ota veh
ar cz ifa pa wip
as dt inv pay
au ec ipa per
ax eng ja pjm
az fa je po
Customization Standards
As mentioned before, the Oracle Applications suite is typically customized for enterprises. These
customizations should be done in such a way that a script applies the customization and there is also a
script, which undoes the customization. The reason for this is that the upgrades are designed for the base
release of the Applications and not for the enterprise specific customizations. This concept has the
advantage that a well-documented strap-off, strap-on code will give the enterprise an idea of the effort and
the steps, which were taken to do the customizations. Most often than not, customizations are done in an
ad-hoc fashion and at the end of the implementation, the upgrade path for the applications is pretty much
out of the question. This creates a lot of problems because Application versions typically run out of
support agreements after a period of time and the customer is left with an unsupported combination. New
Versions of the applications enable new technologies and functionality, and this advantage is lost by not
having such a script.
Environment File and the APPSENV Concept
We recommend that the following files be maintained for Oracle Application environments.
• APPSPRE<ORACLE_SID>.env
• APPS<ORACLE_SID>.env
• CUST<ORACLE_SID>.env
• APPSPOST<ORACLE_SID>.env
6. APPSPRE<ORACLE_SID>.env is the file which sets all the pre-required environment variables.
Examples are ORACLE_BASE, APPL_BASE etc.
APPS<ORACLE_SID>.env is the file which contains all the Applications environment information and is
generated by the auto installer program.
CUST<ORACLE_SID>.env is the file which contains all the Customization environment information.
APPSPOST<ORACLE_SID>.env is the file which contains other environment variables which needs to
be set to run the Oracle Applications.
It is not difficult to write a shell script similar to the oraenv, which basically executes the above files
mentioned in that order. We will venture to call this appsenv and will basically look like this.
/var/opt/oracle/appsenv
PRODTEST:/export/home/applmgr/APPS/PRODTEST:Y
SANDBOX:/export/home/applmgr/APPS/SANDBOX:Y
DEV:/export/home/applmgr/APPS/DEV:Y
The third parameter, which contains yes or no could be used to determine whether the concurrent
manager should be started up or not.
About the Author
Bill Milligan is a Senior Analyst at Level(3) Communications. Previously, he was a senior consultant
with Oracle Corporation. He has just completed upgrading Level(3) to release 11.0.2, which included all
financial modules, HR/Payroll, and Capitol Resource Logistics (CRL). The upgrade entailed increased
complexity by including Multi-org, MRC, and data center relocation. Bill can be reached at Level(3) at
303-635-9110 or bill.milligan@level3.com
Mahesh Vallampati is a senior consultant with the Oracle National Telecom Practice. He has 5 years
experience implementing Oracle Databases and 2 years implementing Oracle Applications. He holds a
Master’s degree in Electrical Engineering from Texas A&M University. Mahesh ca be reached at Oracle
at mvallamp@us.oracle.com
7. Appendix A
Admin Tier – Applmgr environment
$(VND_VERTEX)/vap041.o $(VND_MFLIBS) $(VND_CRTLIB)
AD_TOP=/d19/appl/R11/PRDTEST/ad/11.0.28
AK_TOP=/d19/appl/R11/PRDTEST/ak/11.0.28
ALR_TOP=/d19/appl/R11/PRDTEST/alr/11.0.28
APPLBIN=bin
APPLCSF=/d19/appl/R11/PRDTEST/common
APPLDCP=OFF
APPLDOC=docs
APPLFENV=PRDTEST.env
APPLFRM=forms
APPLFULL=FND AD ALR AX AK GL RG AP FA AR AS PA CN PER PAY HXT OTA INV PO
CE EC ICX JG JE JA IPA IFA
APPLIMG=images
APPLINC=include
APPLLIB=lib
APPLLOG=PRDTESTlog
APPLMAIL=NONE
APPLMSG=mesg
APPLORB=ar25runb
APPLORC=ar25run
APPLOUT=PRDTESTout
APPLPAYLINK=cob
APPLPLS=plsql
APPLPTMP=/tmp
APPLREG=regress
APPLREP=reports
APPLRGT=regress
APPLRSC=resource
APPLSAV=save
APPLSHAR=OE FF DT BOM ENG MRP CRP WIP
APPLSQL=sql
APPLTMP=/usr/tmp
APPLUSR=usrxit
APPL_TOP=/d19/appl/R11/PRDTEST
AP_TOP=/d19/appl/R11/PRDTEST/ap/11.0.28
AR=ar
ARFLAGS=rv
AR_TOP=/d19/appl/R11/PRDTEST/ar/11.0.28
AS_TOP=/d19/appl/R11/PRDTEST/as/11.0.28
AU_TOP=/d19/appl/R11/PRDTEST/au/11.0.28
AX_TOP=/d19/appl/R11/PRDTEST/ax/11.0.28
AZ_TOP=/d19/appl/R11/PRDTEST/az/11.0.28
BOM_TOP=/d19/appl/R11/PRDTEST/bom/11.0.28
CC=/opt/SUNWspro/bin/cc
CE_TOP=/d19/appl/R11/PRDTEST/ce/11.0.28
CFLAGS=-Xt -xstrconst -xcg92 $(INCLUDE_FLAGS) -O -DSUN_OS5 -DAFSTUBS
CHMOD=chmod
CHV_TOP=/d19/appl/R11/PRDTEST/chv/11.0.28
CLASSPATH=/d1/app/jre/lib/rt.jar:/d1/app/oracle/product/8.0.4/jdbc/lib/c
lasses11
1.zip:/d1/app/oracle/product/8.0.4/forms45/java:
CN_TOP=/d19/appl/R11/PRDTEST/cn/11.0.28
COBDATA=:/d19/appl/R11/PRDTEST/pay/11.0.28/vertex
COBDIR=/opt/lib/cobol