11i Apps Overview & Best

Practices

Mike Swing

UTOUG Training Days, 2007

 Agenda
• Overview of Best Practices
• Business Continuance Volumes
• 11i Architecture
– Web
– Forms
– JSPs
– OA Framework
• Patching, Testing, Cloning, Install
 Agenda
• Personalizations
– Forms
– OA Framework
• Timeouts
• Purging Workflow
• Release 12
 Who Cares?
• Managers
• Superusers
• Testers
• DBAs
 Best Practices
• Storage System
– Use shared disk
– Use BCV/snapshots (block virtualization)
• Use the BCV for:
Backup/Recovery
Cloning
 Best Practices
• Use the Tiered Architecture of Oracle
Applications to separate processing onto
individual servers when increased
scalability or additional security are
required.
• Use Load Balancing when appropriate
• Run seeded concurrent requests to keep
the system up to date
 Best Practices
• Understand the Application Architecture
– Forms
– HTML
– JSP
– OA Framework
 Patching Best Practices
• Schedule periodic downtime for proactive
maintenance (functional and technical)
• Keep up-to-date on latest AD code
• Keep your test system current with production
• Keep a separate host/instance for emergency
patching/testing
• Perform “uptime” maintenance
• Gather schema stats
• Patch help system
• Apply translation database updates
 Patching Best Practices
• Use shared disk to enable shared APPL_TOP
and Distributed AD
• Avoid extent allocation errors with autoextend
• Combine patches with AD Merge Patch
• If you merge your patches, you must carefully
document the patches that are contained in the
merged patch. The database won’t have any
patch numbers to record in ad_applied_patches.
• Use a staged APPL_TOP
• Use non-interactive patching when appropriate
 Testing Best Practices
• Superusers / Testers should have canned
scripts they can execute to test modules
• DBA/Developers should run technical tests
before releasing to the users/ testers for
functional testing
• Functional Supersers should be familiar
with the patch README and New
Functionality section
 Testing Best Practices
• Tell the Testers what’s changed in the
patch
• Use the changed forms, .odf’s as a guide
to what test
• Convert the short form name to long form
name, so users know what to test
 Cloning Best Practices
Cloning is faster and easier with:
• Shared APPL_TOP with shared disk (NFS,
NAS, SAN)
• Snapshots and Business Continuance
Volumes (BCVs)

Finish the Clone!

 Install Best Practices
• Save the config.txt to a permanent directory, not /tmp
• Use VNC
• Set DISPLAY
• Install J2SE before the install, except for SUN and Linux
• Enable DISPLAY, as root,
xhost +
Then, set DISPLAY=192.168.1.15:0.0; export DISPLAY,
as an example
• Set ulimit to unlimited
 Best Practices
• Use Personalizations
– Forms Persoanlizations
• Custom Library
– OA Framework Personalizations
 Tiers
The application tier has a dual role: hosting the various
servers and service groups that process the business
logic, and managing communication between the
desktop tier and the database tier. This tier is sometimes
referred to as the middle tier.
Four servers or service groups comprise the basic
application tier for Oracle Applications:
• Web services
• Forms services
• Concurrent Processing server
• Admin server
 Tiers
HTML Web Server (Self- Service)
Interface

Forms Server (Prof Java)

Web Browser Concurrent

Concurrent Processing
Processing e
JInitiator
Admin Server

JAVA iSupplier SSL Server

Interface

Discoverer Server Data

Desktop Reports Server

Demand Planning Server Database

Tier
Application Tier
 Concurrent Processing Server
Reporting programs and data updating programs that need to run
either periodically, or on an ad hoc basis. These programs,
which run in the background while users continue to work on
other tasks, may require a large number of data-intensive
computations, and are run using the Concurrent Processing
architecture.
Concurrent Processing is an Oracle Applications feature that
allows non–interactive and potentially long-running functions to
be executed efficiently alongside interactive operations.
It uses operating system facilities to facilitate background
scheduling of data- or resource-intensive jobs, via a set of
programs and forms.
To ensure that resource-intensive concurrent processing
operations do not interfere with interactive operations, they are
run on a specialized server, the Concurrent Processing server.
 Concurrent Requests
• Processes that run on the Concurrent
Processing server are called concurrent
requests.

• When you submit such a request, either through

HTML-based or Forms-based Applications, a
row is inserted into a database table specifying
the program to be run. A concurrent manager
then reads the applicable requests in the table,
and starts the associated concurrent program.
 Business Continuance Volumes
• As databases grow in size, faster backup and restore solutions are critical.
BCV’s can be utilized for backups and cloning to decrease the time required
to copy Oracle datafiles and Oracle Applications files.
• BCVs or snapshots, from EMC, NetApp or StoneFly enable backup, re-
silver and restore, of large amounts of data using a technique known as
Block Virtualization.
• A BCV is a copy of an EMC Symmetrix standard device. BCV devices can
be accessed by one or more separate hosts while the standard devices are
on-line for normal I/O operations from their host(s).
• A standard device is established with a BCV device, making a BCV pair.
The BCV device can be split, re-established (re-silvered or re-
synchronized), and restored.
• Several hosts can attach to the same array. When the BCV devices are split
from standard devices, the BCVs can be referenced by the same or by a
different host.
• Each BCV device has its own unique device name. When established, BCV
devices are not accessible by any other hosts.
 BCV
DEV PROD

BCV Example
 Establish - Restore
• When BCV devices are split from the standard devices,
the BCV devices represent a mirror of the standard
device. After splitting from a pair, a BCV device can then
be read and written.
– full synchronization - a copy of the standard device onto the BCV
devices
– incremental re-synchronization propagates only the changed
tracks onto the BCV devices. If the BCV device was modified
after the split and before re-establishing, those changes are
overwritten by the data from the standard device. Once the BCV
is successfully established or re-established, the BCV acts like
another mirror to the standard device.
– restore - Similar to the establish operation, a full or incremental
restore can be performed.
 BCV
• Device A and Device B are
accessed by the same host.
Device A is mirrored. The BCV
device can be established, re-
established, or, restored onto
the standard device.
• When the BCV is assigned to
the standard device and is
established, the combination of
the BCV device and standard
device is deemed a BCV pair.
• When the BCV is split from the
pair, the BCV can be accessed
by the same host or by other
hosts.
 Backups with BCVs
• BCV’s can be utilized for backups to eliminate downtime
with Oracle Hot Backups. This method requires no
downtime to split the BCV.

• The database can be brought down (cold backup) and

the BCV split to ensure a clean backup (testing will
validate the hot backup method or stop the database to
split the BCV for a cold backup).
 Backups with BCVs
• The Cold Backup method requires about 10
minutes to stop the database, split the BCV and
restart the database and applications. Backups
can be offloaded to another host if required.
Tape devices should backup the directory on the
backup host for an additional level of protection.
• Re-establishing the BCV with the Production
database, after creating the Development
instance, can be done while the database is
open.
 Application Architecture
11i is made up of four primary development
architectures:
• Forms – Primary UI for ERP
• HTML – most of the HTML code has
been converted to OA Framework
• JSP
– CRM / JTT / JTF
– OA Framework – All Self Service Applications
iProc, iExp, Workflow
 11i Architecture
Professional
OA Framework JTT-JTF Java Interface
Servlets CGI

Forms Server
Apache JServ

JInitiator

HTML JAVA
Interface

Web Browser
 Forms
• The Forms server hosts the Oracle Applications forms
and the forms runtime engine that support the core
Applications. The forms server is part of Oracle
Developer software and can provide more advanced field
and form validation. This serves up the forms and
coordinates communication with the browser and the
database.
• The Forms server caches data and provides it to the
client as needed, such as when scrolling through multiple
order lines that exceed the limitations of a single screen.
The Forms server communicates with the desktop client
using HTTPS, HTTP and TCP/IP.
 Forms 6i Server
When a user initiates an action in the Forms client
applet, such as entering data into a field or
clicking a button, data is passed to the Forms
server on the application tier. The user interface
logic runs in the Forms server and determines
the appropriate user interface effect based on
the user’s action. For example, a window may
open or another field value may be populated. If
necessary, the database tier is contacted for any
data not already cached on the application tier,
or for data-intensive processing.
 Forms 6i Server
• Oracle Forms 6i Server can operate in three separate
modes: socket, http and https. http and https mode can
be used for internet transactions (outside the firewall),
whereas socket mode can only be used for an
organization's intranet (inside the firewall). https
corresponds with SSL and is strongly recommended if a
company is to allow transactions over the internet.
• The implementation of SSL for the Oracle forms 6i
Server involves the tool Oracle Wallet Manager, which is
included in the Developer 6i Server install under the
application server Oracle home from version 8.0.6
onwards. The tool is Java-based.
 JInitiator
• JInitiator is used to run Java applets on a
desktop client, and it provides a delivery
mechanism that enables Oracle Developer
applications to be run from within a browser in a
stable and supported manner. In addition to
addressing critical bug fixes, Oracle JInitiator
provides a number of additional features to
enhance application performance, such as JAR
file caching, incremental JAR file loading and
applet caching.
 Forms – Professional Java Interface
Forms are
HTML Web Server (Self- Service)
served up by the Interface
forms runtime Forms Server (Prof Java)
engine. This is
also know as the Web Browser Concurrent
Concurrent Processing
Processing e
Professional JInitiator Admin Server
Java Interface.
JAVA iSupplier SSL Server
Interface

Discoverer Server Data

Desktop Reports Server

Demand Planning Server Database

Tier
Application Tier

The forms server is part of Oracle Developer software and can provide more
advanced field and form validation than HTML and Java. This serves up the
forms and coordinates communication with the browser and the database.
 Oracle Forms Services

• Oracle Forms Services consists of a listener and a runtime engine,

where the application logic is stored. On the client tier, Oracle
Forms Services consists of a Java applet, which provides the user
interface for the runtime engine, and Oracle JInitiator (a Java plug-
in) that provides the ability to specify the use of a specific Java
virtual machine on the client.
• In Oracle9i Application Server, when a user submits a URL to
launch an Oracle Forms-based application, the Web listener
accepts the request and downloads the Oracle Forms applet to the
user's browser. Then, the Oracle Forms applet establishes a
persistent connection to an Oracle Forms runtime engine. All
processing takes place between the Oracle Forms applet and the
Oracle Forms Services runtime engine.
 Dev60cgi/f60cgi/
• Forms are based on CGI, as shown in the URL calling
f60cgi.
http://rh1.trutek.com:8000/dev60cgi/f60cgi
 jsp’s
In the Oracle 9iAS Application Server, servlets are managed by the
OC4J servlet container; EJBs are managed by the OC4J EJB
container. These containers, together with the JavaServer Pages
container, form the core of OC4J.
• JavaServer Pages (JSP) is another server-side component type.
JSP pages also involve the servlet container, because the JSP
container itself is a servlet and is therefore executed by the servlet
container. The JSP container translates JSP pages into page
implementation classes, which are executed by the JSP container
but function similarly to servlets.
• Most servlets generate HTML text, which is then sent back to the
client for display by the Web browser, or is sent on to other
components in the application. Servlets can also generate XML, to
encapsulate data, and send this to the client or to other
components.
 Servlets
• In recent years, servlet technology has emerged as a powerful way
to extend Web server functionality through dynamic HTML pages. A
servlet is a Java program that runs in a Web server (as opposed to
an applet, which is a Java program that runs in a client browser).
The servlet takes an HTTP request from a browser, generates
dynamic content (such as by querying a database), and provides an
HTTP response back to the browser.
• Prior to servlets, CGI (Common Gateway Interface) technology was
used for dynamic content, with CGI programs being written in
languages such as Perl and being called by a Web application
through the Web server. CGI is less scalable, but was suitable for
this particular application.
• Servlet technology, in addition to improved scalability, offers the
well-known Java advantages of object orientation, platform
independence, security, and robustness. Servlets can use all
standard Java APIs, including the JDBC API (for Java database
connectivity, of particular interest to database programmers).
 Advantages of Servlets
• Servlet technology offers advantages over applet technology for
server-intensive applications such as those accessing a database.
One advantage is that a servlet runs in the server, which is usually a
robust machine with many resources, minimizing use of client
resources.
• An applet, by contrast, is downloaded into the client browser and
runs there. Another advantage is more direct access to the data.
• The Web server or data server in which a servlet is running is on the
same side of the network firewall as the data being accessed. An
applet running on a client machine, outside the firewall, requires
special measures (such as signed applets) to allow the applet to
access any server other than the one from which it was
downloaded.
 Advantages of Servlets
• Servlet programming offers advantages over earlier models of
server-side Web application development, including the following:
• Servlet programming is a mature and popular standard, effectively
replacing early techniques, such as CGI scripts, for generating
dynamic HTML.
• A servlet handles concurrent requests. There is only a single
instance of each servlet, and servlets have a well-defined lifecycle.
For higher performance, servlets can be loaded when OC4J starts.
• Servlets are fully integrated into the J2EE framework.
• The servlet request and response objects provide a convenient way
to handle HTTP requests and send text and data back to the client.
• Servlets are fully integrated with the Java language and its standard
APIs. The J2EE framework provides an extensive set of services
that your Web application can use, such as JNDI, JMS, RMI, and
security.
 Servlets
• Because servlets are written in the Java
programming language, they are supported on
any platform that has a Java virtual machine and
a Web server that supports servlets.
• Servlets can be used on different platforms
without recompiling. You can package servlets
together with associated files such as graphics,
sounds, and other data to make a complete Web
application. This simplifies application
development and deployment.
Servlets outperform earlier technologies for
generating dynamic HTML, such as
server-side "includes" or CGI scripts. Once
a servlet is loaded into memory, it can run
on a single lightweight thread; CGI scripts
must be loaded in a different process for
every request.
 JavaServer Pages

• JavaServer Pages(TM) is a technology specified by Sun

Microsystems as a convenient way of generating
dynamic content in pages that are output by a Web
application (an application running on a Web server).
With JSP you can:
• mix regular, static HTML with dynamically generated
content from servlets
• JSP enable a separation of business logic from the User
Interface
• Most of the page may consist of regular HTML, that is
passed to the web user unchanged. Anything that can be
included in a normal HTML page can be included in a
JSP page.
 Java Server Pages
• A JSP page is translated into a Java servlet before being
executed, and processes HTTP requests and generates
responses similarly to any other servlet. JSP technology
offers a convenient way to code the servlet. The
translation typically occurs on demand, but sometimes in
advance.
• Furthermore, JSP pages are fully interoperable with
servlets. JSP pages can include output from a servlet or
forward to a servlet, and servlets can include output from a
JSP page or forward to a JSP page.
• Combining Java code and Java calls into an HTML page is
more convenient than using straight Java code in a servlet.
JSP syntax gives you a shortcut for coding dynamic Web
pages, typically requiring much less code than Java servlet
syntax
 Displaying Information Accessed from
Servlets and Java Server Pages
An OSSWA function displays information
as dynamically generated web pages, the
following sequence of events takes place:
1. The user clicks the hyperlink of a
function on an OSSWA menu. A URL
embedded in the HTML source code is
accessed from the browser that calls for a
Java servlet.
2. The Oracle HTTP Server, powered by
Apache, routes the request to mod_jserv.
3. mod_jserv takes requests and forwards
them to Apache Jserv, the servlet engine.

4. The servlet engine generates the response, using JDBC to connect. When the servlet
executes Java Server Pages (JSP) it calls Oracle JSP. Oracle JSP is a translator and
runtime environment for JSPs.
5. The response is returned to mod_jserv.
6. The HTTP Server returns the response to the client.
 Model Architectures for the Web

• Model 1 and Model 2 simply refer to the absence or presence

(respectively) of a controller servlet that dispatches requests from
the client tier and selects views.

• “A Model 1 architecture consists of a Web browser directly

accessing Web-tier JSP pages. The JSP pages access Web-tier
JavaBeans that represent the application model, and the next view
to display (JSP page, servlet, HTML page, and so on) is determined
either by hyperlinks selected in the source document or by request
parameters. A Model 1 application control is decentralized, because
the current page being displayed determines the next page to
display. In addition, each JSP page or servlet processes its own
inputs (parameters from GET or POST). In some Model 1
architectures, choosing the next page to display occurs in scriptlet
code, but this usage is considered poor form. “
jtflogin.jsp
• Model 1 architecture
(see Figure 1) leaves
the routing between
pages to the JSP itself.
So the JSP needs to
have hardcoded links
or navigation logic
embedded within the
page. This strategy
solves one problem,
but introduces another.
Because the
presentation and
navigation logic are
mixed, the page cannot
easily be reused. Even
simple page flows that
use JSP Model 1 can
quickly become
complex. Each page
needs knowledge of
every other page that it
links to.
AppsLocalLogin.jsp
• JSP Model 2 (see Figure 2) is a response to this problem. In the
case of the Model 2 architecture, the page flow is not handled by the
JSP. Rather, the architecture lets a separate servlet decide what the
routing should be, based on the information submitted with the page,
thus freeing pages from having to know about every other page that
they are logically linked to. This servlet is called a Controller.
 Controller Servlet
• “A Model 2 architecture introduces a controller servlet
between the browser and the JSP pages or servlet
content being delivered.
• The controller centralizes the logic for dispatching
requests to the next view based on the request URL,
input parameters, and application state.
• The controller also handles view selection, which
decouples JSP pages and servlets from one another.
• Model 2 applications are easier to maintain and extend,
because views do not refer to each other directly.
• The Model 2 controller servlet provides a single point of
control for security and logging.
OA Framework
 Model-View-Controller (MVC)
MVC separates an
application's data View
Data
Model
model, user interface, Page Meta
View Object
Data
and control logic into Web Bean Hierarchy SuppliersVO
three distinct Response <?xml …

components so that <page

</page>
modifications to the View Row

view component can

be made with minimal
Controller controls the View
impact to the data
model component. processRequest get <Attr>
validateEntity
(
… set <Attr>
Separating the view ) processRequest
from the model makes Request ( Supplier
… Data
the model more robust, ) Actions
remove()
because the developer
is less likely to "break" Controller read/write
create()

the model while

reworking the view.
 MVC
1. user interacts with the user interface in some way
(e.g., user presses a button)
2. controller receives notification of the user action from
the user interface objects
3. controller accesses the model, possibly updating it in a
way appropriate to the user's action (e.g., controller
updates user's shopping cart)
4. controller delegates to the view for presentation
5. The view uses the model to generate an appropriate
user interface (e.g., the view produces a screen listing
of the shopping cart contents).
6. user interface waits for further user interactions, and
begin the cycle again.
 OA Framework
• The OA Framework Model is implemented using Oracle
Business Components for Java (BC4J). BC4J provides
optimized, ready-to-use implementations of the J2EE
design patterns that developers otherwise would have to
code, debug, and test.
• The OA Framework View is implemented using UI XML
(UIX). UIX uses XML to describe the components and
hierarchy that make up an application page. UIX also
provides runtime capabilities to translate that metadata
into HTML output so that it can be shown on a Browser
or a mobile device.
 OA Framework
OC4J
1. URL Request
from Browser to Web
Browser
HTML
Interface
Web
Listener
JServ
Display Manager

Web Listener Application Objects

Domain Bus. Objects
JAVA Core Serv. Objects
2. AOL/J authorizes JInitiator Interface Web Data

the user access Server OJSP

<HTML>
JDBC

to the web page (Apache)

Catalog Bean
<HTML>

3. Page definition
from the Java MetaData UI
Metadata Controller Definition
Dictionary is Metadata
Dictionary
loaded into the UIX HTML UI Generator
Repository
web server MDS

Metadata UI AOL/J BC4J

Definition OA Framework Database

4. BC4J objects that contain the application logic and access the database are
instantiated
5. Java Controller changes page based on dynamic UI rules from the
MetaData UI Definition
6. UIX Generates page by interprets the page definition, creates the
corresponding HTML in accordance with UI standards & sends to browser
 New Metadata Repository
• The metadata used to describe the UI is loaded into a
database repository, called Meta Data Services (MDS),
at deployment time and optionally at design time as well.
User- and application-driven interactions are handled by
the OA Controller.

• Previously, the OA framework used the AK tables to

store application metadata. The MDS model now
supersedes the old AK tables. MDS application metadata
can be stored either in XML files or in the MDS
Repository tables. The personalization data is included in
the new MDS repository.
 Oracle Applications Framework
• Oracle Applications Framework uses additional
components, including:
• BC4J (Business Components for Java), included in
Oracle JDeveloper, is used to create Java business
components for representing business logic. It also
provides a mechanism for mapping relational tables to
Java objects. It allows the separation of the application
business logic from the UI.
• AOL/J provides the Oracle Applications Framework with
underlying security and applications Java services. It
provides the Oracle Applications Framework with its
connection to the database and with application-specific
functionality, such as flexfields and attachments.
 Personalizations
• The OA Framework was designed with durable
personalization capabilities.
• Declarative UI component definitions are stored in the
form of meta-data in a database repository.
• Personalizations are translated into offsets from the base
meta-data definition and stored separately. At runtime
the various applicable personalization meta-data is
uploaded from the repository and layered over the base
meta-data definition to produce the net effect.
• Product upgrades and patching only affects the base
meta-data definition and customer personalizations
continue to function properly as far as applicable.
 Request to OA.jsp for a Page
1. The
Java Virtual Machine (JVM)
oracle.apps.fnd.framewo 10g DB
rk.webui.OAPageBean
(the main OA Servlet Session Web Apps Context

Framework page Application State Application State

processing class) uses

the page name to find OA.jsp Uses
the root application ICX OADBTransaction
module, so it can check SESSIONS
OAPageBean Application State
it out from the
application module pool. Rendered
This application module HTML OAPageContent

also checks out a JDBC Application State

connection from the Browser References
Web Bean Hierarchy

connection pool, and the Session Request Caches

transaction context for Cookie
Application State
Contains

the page is established. Session

ZZZ
RootAppModuleAMImpl

2. The user session is validated; if invalid, a login page is displayed, this is a

simplification.
3. Assuming the user is valid, the OAPageBean evaluates request parameters to
figure out if it is dealing with an HTTP POST or a GET.
 OA.jsp
Java Virtual Machine (JVM)
10g DB
When the user logs in to an Servlet Session Web Apps Context
OA Framework application, Application State Application State
the OA Framework creates an
AOL/J OA.jsp Uses
oracle.apps.fnd.common.Web ICX OADBTransaction
AppsContext object and a SESSIONS
Application State
browser session-based OAPageBean

cookie that together keep Rendered

track of key Oracle HTML OAPageContent
Applications context Application State
information like the current Browser References
Web Bean Hierarchy
responsibility, and Session Request
organization id. Cookie Caches
Contains
Application State
Session RootAppModuleAMImpl
ZZZ

The cookie contains an encrypted key identifier for a session row stored in the
Applications database (this is the servlet session ID, in its decrypted form, and
serves as the primary key in the ICX_SESSIONS table)
The WebAppsContext retrieves this key value after each request, and uses it to
query the current session state The Oracle Applications user session is associated
with a servlet session, however, it has its own life cycle and time-out characteristics.
 Servlet Sessions
• An Oracle Applications user session might be associated with
multiple servlet sessions (if, for example, the servlet session times
out while the user takes a phone call in the middle of creating an OA
Framework expense report, and then resumes work before the
Oracle Applications user session times out).
• A servlet session might be associated with multiple Oracle
Applications user sessions (if, for example, a user logs out and then
back in again without closing the browser window).
• If the Oracle Applications user session times out, as long as the
user does not close the browser window (so the browser session-
based cookie isn't lost) and no one deletes the corresponding
session row in the ICX_SESSIONS table, the user can resume her
transaction at the point where she stopped working after being
prompted to log back in.
 Timeouts
• ICX: Session Timeout , controls the time of inactivity of the session. If set to 30
minutes, then after no activity for 30 minutes you will get the popup window.
ICX:Limit Time, controls the total time a session can be logged in. If set to 8
hours, then after 8 hours you will get the popup window, regardless of what
activity is being done.
ICX:Limit connect, This profile option determines the max. number of
connection requests a user can make in a single session. If a user sends more
requests than the value specified by this profile option in a single session, then
the session will expire. This needs to be bumped up to 2000 +, because each
time Session Time is checked it adds another ICX connection. This IS NOT
DETERMEND BY THE NUMBER OF USER CONNECTIONS. The more ICX
checks its self the more ICX connections you are going to see for a user.
Session.timeout, is set under the Apache’s zone.properties. This should be set
to default which is 1800000. Anything higher can result in performance and out
of memory errors.
Typically session.timeout and ICX:Session Timeout are set to the same value.
 CRM Timeouts
• ICX:Session Timeout,
ICX:Limit Time, and
JTF_INACTIVE_SESSION_TIMEOUT

• JTF_INACTIVE_SESSION_TIMEOUT
affects CRM-based products only, and
serves the same purpose as the
ICX:Session Timeout profile. This profile
exists for legacy reasons, and its value
should be set to the same as ICX:Session
Timeout.
 Forms Timeouts
• ICX:Session Timeout,
• and ICX:Limit Time
 OA Framework Timeouts
• ICX:Session Timeout,
• ICX: Limit Time,
• and JServ Timeout
 Timeouts
• Oracle recommends setting the different timeout
parameters to between 30 minutes (default) to 60
minutes. In practice, timeouts as long as 8 hours are
common.
• ICX: Session Timeout - (Forms) 480 (minutes) – 8 hours
• ICX:Limit Time - 12 hours
• ICX:Limit connect – 2000+
• Session.timeout (zone.properties) 28800000 – 8 hours
• ICX: Session Timeout and Session.timeout should have
the same value.
 Timeouts
• The defaults in 11.5.10.2:
• ICX: Limit time 999 (hours)
• ICX: Limit connect 9000 (# ICX
connects)
• ICX:Session Timeout 30 (minutes)
 Timeouts
• The ICX Profiles handle the Forms Session. This
can be confusing since ICX in the past is known
to be associated with Self Service. This is no
longer the case since the release of Framework
for the ICX Profiles that control the Timeout
Functionality.
• The Time Out functionality has been setup to
work with the URL that calls AppsLocalLogin.jsp
during login. The Old ICXINDEX.htm has been
replaced since the release of FND G and 11.5.9.
 Load Balancing
• The application tier supports load balancing
among many of its servers and services to help
provide higher availability, fault tolerance,
reliability, and optimal scalability. If you have
more than one of any of the following types of
server, load balancing can be employed:
• Web services
• Forms services
• Concurrent Processing server
 TruTek
Load Balancing – Forms Servers
Web Server (OSSWA)
HTML
Interface Web Metadata
1 Listener
JServ Dictionary

Web Browser
2 jsp
JInitiator

JAVA Metric Forms Server1 Data

Interface 4 Server
3
.fmx
Desktop
165787 Forms Server2
148516 Database
148155 .fmx
Forms Server (Prof Java)
 Patching
• Schedule periodic downtime for proactive
maintenance (functional and technical)
• Keep up-to-date on latest AD code
• Keep your test system current with production
• Keep a separate host/instance for emergency
patching/testing
• Perform “uptime” maintenance
• Gather schema stats
• Patch help system
• Apply translation database updates
 Patching
• Use shared disk to enable shared APPL_TOP
and Distributed AD
• Avoid extent allocation errors with autoextend
• Combine patches with AD Merge Patch
• If you merge your patches, you must carefully
document the patches that are contained in the
merged patch. The database won’t have any
patch numbers to record in ad_applied_patches.
• Use a staged APPL_TOP
• Use non-interactive patching when appropriate
 Install/Cloning Technology
• Rapid Install “-techstack” option
– iAS 1.0.2.2.2
– RDBMS 9.2.0.3
• Complex cloning
– Multi-node to single-node
– RAC support
• iSetup Integration
 Patching Enhancements
• Parallel index creation
• In progress patch status
• Improved patch reporting
• Additional impact analysis
• Eliminate MRC schema
• Concurrent AD sessions
11i Patch Utility Enhancements
(#1)
• Checkfile feature
– Activated with database drivers
– Records file and version information in the database
– Executes commands only if they have not executed
previously for the highest onsite version of the file
– Eliminates need for package revision cache
• Automatic job deferral
– Re-tries failed jobs at the end of the phase
– Replaces auto restart
11i Patch Utility Enhancements
(#2)
• Unified Driver
– Requires a single AD Patch run
• AD Merge Patch improvements
– Can merge all patch types and driver types
– Characterset is converted during merge
– Significant performance improvement

• Automated Pre-requisite checking

– AD Patch confirms prerequisite is satisfied
– Allows for smaller patches, less overhead
– Duplicate patch avoidance
11i Patch Utility Enhancements
(#3)
• Password Hider
– Passwords automatically removed from log files
• Manual Step Elimination
– Automatically compiles Apps
– Automatically Maintains MRC
– Automatically compiles JSP
• Technology Stack Validation Utility
– Confirms minimum techstack requirements
– Refers to appropriate MetaLink notes
11i Patch Utility Enhancements
(#4)
Distributed AD
– Apply patches using all your middle tier horsepower to
significantly reduce downtime

adpatch adworker06 adworker11 adworker16

adworker01 … … …
… adworker10 adworker15 adworker20
adworker05
 Non-interactive Patching
• time adpatch
defaultsfile=$APPL_TOP/admin/CONTEXT
_defaults.txt logfile=adpatch_3368689.log
patchtop=/d01/patch/3368689 workers=3
interactive=yes options=novalidate
 Testing
While Oracle Applications Users are primarily responsible for complete
functional testing, 11i DBA’s and Developers usually provide some
level of testing to ensure the technical elements of 11i are all
functioning properly before turning the instance over to the users for
more complete testing. The technical elements to test include:
– Database
– Forms
– Apache
– JSP
– JDBC
– File>Export
– Tools>Copy File
Users should have a set of canned scripts that they run to finish
validating the instance. Inevitably, some testing is missed and
errors occur in production.
 What to Test?
• The users should review the patch readme, but
usually don’t. Often, they aren’t aware of new
functionality that is introduced by the patch.
• DBAs should summarize the new functionality
for the new patches that are being tested. DBAs
should also give the users a list of Forms that
changed due to the patch. These forms should
be tested.
• Use the unified driver that comes with each
patch to determine the new .fmb’s being copied
into the instance. These are the new forms that
need to be tested.
Convert Short Form Name to Long Form Name

SELECT fnd_form.form_name,
fnd_form_tl.user_form_name,
fnd_form.last_update_date,
fnd_form_tl.last_update_date
FROM applsys.fnd_form, applsys.fnd_form_tl
WHERE ((fnd_form.form_id = fnd_form_tl.form_id))
 ATG RUP 3 vs ATG RUP4
Long Form Name Module Files in ATG RUP3 File Difference
Application Module Parameters Registry AK Common Modules Developer AKDAPREG.fmb
Define Attributes AKDATTRS.fmb

Flow Workbench AKDFLOWB.fmb

Define Flows AKDFLOWS.fmb
Define Foreign Keys AKDOBFKS.fmb
Object Workbench AKDOBJWB.fmb
Define Primary Keys AKDOBPKS.fmb
Run Flows AKDPICKF.fmb
Define Query Objects AKDQUERY.fmb
Define Regions AKDREGNS.fmb
Define LOV Relations AKDRELOR.fmb
Alerts ALERTS ALRALERT.fmb
Define Distribution Lists ALRASDDL.fmb
Define Periodic Sets ALRASDPG.fmb
ALRDAA.fmb
Request Periodic Alert Check ALRPRRPA.fmb
Review Alert Actions ALRRHRAA.fmb

Define Trading Partner User APPSTAND.fmb

Update Table Information AOL - Foundation FNDADDTC.fmb
Document Category FNDATCAT.fmb
Define Audit Tables FNDATDAT.fmb
Documents FNDATDOC.fmb

ECEOUTDF.fmb
 Diagnostic Tests – trusted.conf
All the directives for restricting access to monitoring services are listed
in file trusted.conf.
Follow the steps below to comment the inclusion of trusted.conf:

• Stop Apache using script

$COMMON_TOP/admin/scripts/host_sid/adapcctl.sh stop
• Comment the following line in
$IAS_ORACLE_HOME/Apache/Apache/conf/apps.conf
configuration file.
• #include "/d01/oracle/visora/iAS/Apache/Apache/conf/trusted.conf"
• Start Apache using script
• $COMMON_TOP/admin/scripts/host_sid/adapcctl.sh start
• Note: This is not a permanent change. Once autoconfig is run, will
revert the changes made to apps.conf.
Admin Forms A, B Web A, B CP A, B

Multi-Node Environment
One Admin Node
Two Forms Nodes
Two Web Nodes
Two Concurrent Processing Nodes
Not using Shared APPL_TOP
 Standard AD

Admin Forms A, B Web A, B CP A, B

1) C driver on Admin node 8) D driver on Admin node

2) C driver on Forms node A 9) G driver on Forms node A
3) C driver on Forms node B 10) G driver on Forms node B
4) C driver on Web node A 11) G driver on Web node A
5) C driver on Web node B 12) G driver on Web node B
6) C driver on CP node A 13) G driver on CP node A
7) C driver on CP node B 14) G driver on CP node B
 Admin Forms A, B Web A, B CP A, B

1) C driver on ALL nodes simultaneously

2) D driver on admin node and G driver on all nodes simultaneously

AD Concurrent Sessions
 Shared APPL_TOP System
A traditional multi-node installation of Release 11i requires
each application tier node to maintain its own application
tier file system, consisting of the APPL_TOP file system
(APPL_TOP and COMMON_TOP directories) and the
application tier technology stack file system (8.0.6 and
iAS Oracle homes).

• In 2003, the "shared APPL_TOP" architecture was introduced, that

allows the sharing of a single APPL_TOP file system with all the
application tier nodes of a multi-node system. In Release 11.5.10,
the ability to share the APPL_TOP file system was combined with
the ability to share the application tier technology stack file system,
resulting in the "shared application tier file system" architecture.
Shared Application Tier File System

In a shared file system, all application tier files are

installed on a single shared disk resource that is
mounted from each application tier node. Any
application tier node can be configured to
perform any of the standard application tier
services, such as serving forms or web pages,
or concurrent processing. All changes made to
the shared file system are immediately
accessible to all the application tier nodes.
 Shared Application Tier File System
Rapid Install configures multi-node systems to use a shared application tier file
system as the default. Before you run Rapid Install, you must do the
following:
• Determine the shared file system mount points
Rapid Install must be able to access the file system from the same mount
point on all the application tier nodes. For example:
– Shared COMMON_TOP: /d01/shared_mount/viscomn
– Shared APPL_TOP: /d01/shared_mount/visappl
– Shared 806 ORACLE_HOME: /d01/shared_mount/visora/8.0.6
– Shared iAS ORACLE_HOME: /d01/shared_mount/visora/iAS
• Specify mount points in Rapid Install
When prompted by the Rapid Install wizard, define the paths to be shared to
be the same for each node in the 11i Applications system. The following
paths must be the same on each node where the Rapid Install is executed:
– APPL_TOP
– COMMON_TOP
– 8.0.6 ORACLE_HOME
– iAS 1.0.2.2.2 ORACLE_HOME
 Merging existing APPL_TOPs
• Oracle recommends that the different APPL_TOPs should be
merged into a completely new APPL_TOP to facilitate rollback
incase of merge failure.
• Apply application tier patches
Verify that these minimum software levels are met. If necessary,
update to the required level by applying the appropriate patch.
• SoftwareMinimum VersionDetailsAD Mini-pack I.1 or higherApply
patch 40389644038964
• Maintain snapshot information
Log in to each application tier node as the APPLMGR user and run
the maintain snapshot task in AD Administration. See
Oracle Applications Maintenance Utilities for more Oracle
Applications Maintenance Utilities for more information.
• Merge existing APPL_TOPs
Merging existing APPL_TOPs
– Prepare the source system application tier for
merging
Choose one of the source system nodes to be the
primary node. This document refers to it as "Node A".
• Log in to Node A as the APPLMGR user and run:

$ cd <COMMON_TOP>/admin/scripts/<CONTEXT_NAME>
$ perl adpreclone.pl appsTier merge

• Log in as the APPLMGR user to each of the secondary

nodes being merged and run:

$ cd <COMMON_TOP>/admin/scripts/<CONTEXT_NAME>
$ perl adpreclone.pl appltop merge
Merging existing APPL_TOPs
– Create a copy of Node A  (preferred)
If you want to place the merged APPL_TOPs in a new location
instead of using an existing APPL_TOP location, create a copy
of Node A (the other nodes in the system do not need to be
copied). Include the following directories from Node A:

<APPL_TOP>
<OA_HTML> (when this directory exists)
<OA_JAVA>
<COMMON_TOP>/util
<COMMON_TOP>/clone
<COMMON_TOP>/_pages (when this directory exists)
<806 ORACLE_HOME>
<iAS ORACLE_HOME>
Merging existing APPL_TOPs
– Copy the required files for merging
Log in as the APPLMGR user to each source node and
recursively copy:
• directory <COMMON_TOP>/clone/appl
- to -
• directory <COMMMON_TOP>/clone/appl on Node A
(or the copy of Node A).

Do not copy any other directories from these nodes.

– Configure the application tier server nodes
• Shut down all services on each application tier node, including Node
A. The database and its listener should remain up.
• Log in to the merged APPL_TOP node as the APPLMGR user and
execute the following commands:

$ cd <COMMON_TOP>/clone/bin
$ perl adcfgclone.pl appsTier
Merging existing APPL_TOPs

– Finishing tasks
• Log in to the target system application tier node as the
APPLMGR user.
• Run the following tasks in adadmin for all products:
– generate JAR files
– generate message files
– relink executables
– copy files to destination
• Depending on which tier you chose as the primary node,
certain files may be missing. Run adadmin to verify files
required at runtime. If any files are listed as missing files, you
must manually copy them to the merged APPL_TOP.
• Remove the temporary directory
<COMMON_TOP>/clone/appl to reduce disk space usage.
Shared Application Tier File System

• If your system does not have a single

APPL_TOP already, you can choose to either
share each individual APPL_TOP, or you can
merge APPL_TOPs into a single APPL_TOP.
Sharing the individual APPL_TOPs will not
provide the complete benefits of a shared file
system, but does allow immediate ability to scale
an existing node type by adding more hardware
resources. Merging APPL_TOPs will allow the
full benefits of the shared file system.
 Cloning
Cloning is faster and easier with:
• Shared APPL_TOP with shared disk (NFS, NAS, SAN)
• Snapshots and Business Continuance Volumes (BCVs)
 Cloning without a BCV
PROD Network DEV

1. Cleanup DEV
2. Shutdown PROD Instance
(350GB)
3. Copy Data to Staging Area (4 hrs)
4. Startup PROD Instance
5. Copy Staged Data to DEV (6 hrs)
6. In parallel, copy COMN, APPL
and ORA, & 10g home
Disks 7. adcfgclone.pl (1 hr) Disks
8. Copy APPL, ORA, and COMN to
APPDEV2 (3 Hours)
2. 9. Add Tier
10. Post Clone Steps (4 hours)

Areas of improvement – save 10

hours by using BCV (steps 3 & 5),
save 3 hours (step 8) by using
shared disk
 Cloning with a BCV
DEV PROD
1. Create BCV
2. Full Establish – Sync BCV with STD,
while PROD is up and running with light
load
3. Shutdown PROD Instance (10 Min)
4. Split BCV (10 min)
5. Startup PROD (10 min)
6. BCV is now accessible by DEV
7. Copy BCV to STD devices on DEV, or
8. Start DEV Instance using BCV

Advantages
Reduced Coordination with UNIX SAs
3.5 hours less downtime while making copy
Less Network Bandwidth required

BCV can be accessed by both Servers

 Cloning Finishing Steps
Table Name Column Name Column Value Details

WF_NOTIFICATION_ATTRIBUTES TEXT_VALUE Value starts with http://<old web host> : Update to new web host

WF_ITEM_ATTRIBUTE_VALUES TEXT_VALUE Value starts with "http://<old web host> : Update to new web host

Create a new system defined as the new global database name using the
WF_SYSTEMS GUID
Workflow Administrator Web Applications responsibility.

WF_SYSTEMS NAME Value needs to be replaced with the database global name

WF_AGENTS ADDRESS Update database link with the new database global name.

FND_FORM_FUNCTIONS WEB_HOST_NAME Update with the new web host name

FND_FORM_FUNCTIONS WEB_AGENT_NAME Update to point at the new PLSQL listener name

FND_CONCURRENT_REQUESTS LOGFILE_NAME Update with the correct path to the logfile directory

FND_CONCURRENT_REQUESTS OUTFILE_NAME Update with the new directory path on the target system
Business Event System
 Cloning Finishing Steps
If OWF.H or higher is applied, run txkWfClone.sh
$COMMON_TOP/admin/install/<context>/txkWfClone.sh.
This script updates all of the WF tables from source to target.

Syntax:
sh $COMMON_TOP/admin/install/$CONTEXT_NAME/txkWfClone.sh
apps <apps_pw>

Example:
source APPSORA.env
sh $COMMON_TOP/admin/install/$CONTEXT_NAME/txkWfClone.sh
apps apps
 Install

• Save the config.txt to a permanent directory, not /tmp

• Download the latest RapidWiz from
http://edelivery.oracle.com/
-> Select English -> Continue -> Select:
Product Pack : E-Business Suite
Platform : ie Linux x86 Click Go
Make Sure you have J2SE installed. Before Installing 11i,
on 11.5.10, Rapidwiz, installs the J2SE 1.4.2
automatically for systems running on Sun Solaris, Linux,
or Windows Operating Systems.
If your system runs on HP-UX PA-RISC, HP-Tru64, or IBM
AIX, you must download and install J2SE BEFORE you
continue with the installation or upgrade.
 X Display Server
Enable All the X Clients :
# xhost +
This command, will grant the security to execute Xwindows on all the
clients.
Set the DISPLAY environment variableVerify that your DISPLAY
variable is correctly set pointing to your PC Client running the
XServer.
For Example: DISPLAY=192.168.1.15:0.0 export DISPLAY
Set umask 022 :To be sure that Rapidwiz will create directories and
files with sufficient permissions, set the umask value to 022 before
starting the installation. Setting umask to 022 ensures that group
and others have read and execute permissions, but not write
permission.
Note 124816.1 : Set umask correctly before starting 11i Rapidwiz
Note 68304.1 : What is umask ?
 ulimit
Set 'ulimit' Parameters as 'unlimited' : (Using
Korn Shell)
Set all of them as
The following command will display the current
ulimit settings : unlimited as follows :
$ ulimit -a
ulimit -t unlimited
time(seconds) : unlimited file(blocks) : ulimit -f unlimited
unlimiteddata(kbytes) : 131072 ulimit -d unlimited
stack(kbytes) : 2048 ulimit -s unlimited
memory(kbytes): 216272 ulimit -m unlimited
coredump(blocks) : unlimited ulimit -c unlimited
nofiles(descriptors) : 4096 ulimit -n unlimited
vmemory(kbytes) : 1048576 ulimit -v unlimited
 Forms Personalization in Oracle
Applications
The Forms Personalization feature allows you to
declaratively alter the behavior of Forms-based screens,
including changing properties, executing builtins,
displaying messages, and adding menu entries.
• Allows you to make declarative changes to a form.
• Changes get applied at runtime when the proper trigger
event occurs.
• Changes can get applied based on who you are and
other conditions
• You can:
– Change object properties
– Execute certain Forms builtins
– Display messages
– Activate menu entries
 Form Personalizations
• Form Personalizations allows you to
fundamentally alter the behavior of the
product that Oracle ships, and access any and
all data. Therefore,
• This feature should only be made available to
trusted users.
• Avoid building Personalizations on a production
system.
– Form Personalizations should first be entered and
thoroughly QA’ed on a test system before they are
loaded to a production system
 How to Personalize
Run the form that you want to modify
• Select Help > Diagnostics > CustomCode
> Personalize from the pulldown menu
– Profiles ‘Utilities: Diagnostics’ and ‘Hide
Diagnostics menu entry’ control access to this
entry
• The Personalizations screen will now run
– It will automatically query any rules if they
exist for that function
 Forms Personalizations
• Personalizations are created by invoking Help >
Diagnostics > Custom Code > Personalize on the
pulldown menu
• Profile ‘Hide Diagnostics menu entry’
– ‘No’: makes the Diagnostics menu entry visible
– ‘Yes’: hides the menu entry completely
• Profile ‘Utilities:Diagnostics’
– ‘Yes’: allows direct access of the feature
– ‘No’: requires entry of the Apps password first
• These same profiles control access to features like
‘Examine’, ‘Item Properties’ and ‘Trace’
– Like Form Personalizations, these features can be used to
change or view any data!
 Forms Personalizations
• Setting both ‘Hide Diagnostics’ and ‘Utilities:
Diagnostics’ to ‘No’ for all users is highly
desirable. This way, if a clerk has an issue a
DBA can stop by and immediately enable
debugging features by supplying the Apps
password. HOWEVER, you must log out after
doing that otherwise the clerk will have access to
those dangerous functions.
• Personalizations are created per Function, not
per Form
Forms Personalizations
 Forms Personalizations
• Rules govern when personalizations get evaluated:
• Function Name: the name of the function that you ran.
Personalizations are made for a function, not a form.
• Seq: an ordering from 1 (first) to 100 (last)
• Description: allows you to record why you are making the
change
• Enabled: used to temporarily disable a rule
• Trigger Event: the event within the form that causes
invocation of the rule
• Trigger object: the context for the trigger event, such as a
particular block or item
• Condition: an optional SQL fragment that, when it evaluates
to TRUE, allows the rule to execute. An Advanced class
describes Conditions.
Forms Personalizations
 Forms Personalizations
Context controls who personalizations apply to:
• Level: Site, Responsibility, Industry, or User
• Value: The specific value when level is Responsibility, Industry, or
User
• At runtime, if the user’s context matches any context of a rule, that
rule is executed.

Context is not a hierarchy

• If a Rule has a context of ‘Site’, it will be applied for everyone
• A rule with a context of Responsibility does not ‘override’ Site
• A rule with a context of User does not ‘override’ Site or
Responsibility
• If 2 rules have the same Trigger Event, and Actions that change the
same property, the rule with the higher sequence number will be
performed last, thus it will ‘win’
 Forms Personalizations
• When an event occurs in the form, we look for all
Rules that match that Trigger Event and Trigger
Object
– Starting with the Rule that has the lowest sequence,
• if the Condition is empty or evaluates to TRUE, we process
each enabled Action, in the order of the Action Sequence
– Then we look for the next-highest sequenced Rule
and process it, until there are no more Rules for that
Event.
– Then the event is passed to the CUSTOM library
 Forms Personalizations
Actions determine what the personalization does:
• Seq: an ordering from 1 (first) to 100 (last)
• Type: Property, Message, Builtin, or Special
• Depending on the Type, the panel will change to show
additional fields
• Description: allows you to record why you are making the
change
• Language: a list of installed languages, and ‘ALL’
• An action associated with a specific language will only be
executed in the context of that language
• Enabled: used to temporarily disable an action
 Select By Text

Used to set a property of an item

•Select By Text…: choose an object by it’s onscreen text
•Object Type and Target Object: internal identifier of the object
•Property Name: the property to change
•Value: the new value
•Get Value: extract the current property value into the Value field
Actions: Property Example
 Actions: Message

Used to display a popup message

Message Type: Error, Warning, Hint, Question,
Debug
Message Text: the text of the message
Actions: Message Example
 Custom Library
• CUSTOM is a stub library Oracle ships that
receives Trigger Events. Customers are free to
add any code they like to it.
• CUSTOM and Form Personalizations drive off
the same Trigger Events
– Form Personalizations are processed first, then the
event is sent to CUSTOM
• CUSTOM can do more because it has complete
access to all PL/SQL and SQL
• But for most changes, Form Personalizations
are adequate and are significantly simpler.
 Custom Library
• The CUSTOM library is an alternative mechanism for
changing behavior, which requires coding
– It can do more than Form Personalization because it has the full
power of the PL/SQL
• Form Personalization and CUSTOM drive off the exact
same events.
– Form Personalization processes them first, then passes them to
the CUSTOM library.
• Both respond identically to the Custom Code events
'Normal', 'Off' and 'Core Code Only'.
• Use the Form Personalization feature whenever possible
– Only use the CUSTOM library when significantly more complex
processing is required.
 Personalization in Oracle
Applications Framework
Personalization Levels
The built-in personalization UI facilitates a variety
of personalization features at a number of levels
by user group.
Oracle Applications Developer
Oracle Applications Administrator
Oracle Applications User
Application Users can save personalized views of a query results
region and retrieve them at a later time. User level personalizations
aren't seen by other users
OA Framework Personalization
 OA Personalization Framework
OA Framework includes the OA Personalization Framework and allows
you to personalize your user interface (UI) of Oracle Self-Service
Web Applications without modifying any underlying code.
Personalizing the appearance of or the data displayed in an Oracle
Self-Service Web Application page is as easy as changing your web
browser preferences.
• Following are some common types of personalizations you can
accomplish with OA Personalization Framework:
– Change the prompt for a field or other text on a page
– Hide or show a field on a page
– Reorder fields or items on a page
– Restrict data that a user can access
– Add new buttons, links, text items, images, etc.
– Restrict query results in a table
• With OA Personalization Framework, your personalizations are
reflected immediately on the page
 Personalizing OA Framework
Applications
• There are many aspects of OA Framework applications that system
administrators, developers and end-users can personalize.

Menus and Responsibilities

• Use the Menu and Responsibility forms to personalize and maintain
security for Oracle Self-Service Web Applications. Use the forms to
assign specific responsibilities to your users and designate the
menus that are available to the users of a given responsibility.

FND Messages and Lookups

• Use the Messages and Lookups forms to modify existing, or define
new messages and lookups, respectively. For example, you may
need to create additional messages for an application for your users
or may want to add new lookup values to a lookup type for your site.
 Oracle Applications
Administrator
• Site Level: the local administrator can introduce global
personalizations that affect all users with access to the subject
UI component, such as, the number of rows displayed in a table
• Responsibility Level: the local administrator can create
personalizations that apply to all users with a specific
responsibility that access a particular UI component.
• Organization Level: the local administrator can introduce
personalizations that affect all users belonging to a particular
organization or business unit with access to the subject UI
component.
• Function Level: the local administrator can define functions and
use them as a context for granular level personalizations.
• Localization Level: the local administrator can use locales as
context for personalizations, for example, using a different postal
code format based on country settings.
 Administrator Personalizations
• Number of rows displayed in a table.
• Product branding (image).
• Region header icon.
• Hide or show regions and items.
• Layout order of regions and items within the boundaries
of the parent region.
• Include or exclude descriptive flexfield segments.
• Up to three sorting levels for tabulated data.
• Filtering (restrict querying) of tabular data.
• Item labels and region headers.
• Required state of non-mandatory items.
 System Personalizations
The following are some cross application personalizations
facilitated by both the OA Framework and AOL:
• Branding
• Style sheets
• Attribute Sets
• Images
• Responsibilities
• Menus
• Messages
• Lookup Codes
• Pre-packaged Flexfields
 End User Personalizations
• Unlike Administrators, Users can create and save several
personalized views that can be retrieved conveniently at anytime
thereafter. That said, end User personalized views are limited in
scope to Query regions with search results tables. For these
regions, end Users can personalize any of the following features:
• Number of rows displayed in a table.
• Hide or show regions and items (results table columns are a popular
example).
• Change the layout order of regions and items within the boundaries
of the parent region (order of 10 results table columns are a popular
example).
• Up to three sorting levels for tabulated data.
• Filter (restrict query) tabular data.
• Item labels and region headers.
• Totals for table columns, when applicable.
 Profile Options Required By the OA
Personalization Framework
Two system profile options affect the behavior of the OA Personalization
Framework:
Personalize Self-Service Defn (FND_CUSTOM_OA_DEFINTION)
• Set this profile option to Yes or No at the user level for an administrator or at
the responsibility level for the system administrator. When you set this
profile option to Yes, two things occur when you log on as an Admin-level
user or responsibility:
– A global Personalize button appears on each self-service web application page.
When you select the global Personalize button on any page, the personalization
user interface prompts you for the administrative level at which you wish to
create your personalizations. A navigation tree then lets you navigate to the
region (or nested region) to personalize.
– Personalize Region links appear for every personalizable region on each self-
service web application page. When you select a Personalize Region link, the
personalization user interface first prompts you for the administrative level at
which you wish to create your personalization, then takes you directly to the page
to personalize.
• You can choose the Personalize button or Personalize Region links to
create your personalizations.
OA Framework Personalization
 Profile Options Required By the OA
Personalization Framework
Disable Self-Service Personal
(FND_DISABLE_OA_CUSTOMIZATIONS)
• You can set this profile option to Yes or No at the site or
application level. If this system profile option is set to
Yes, any personalizations you make, regardless of the
level at which you make the personalizations, will not be
applied.
• Only the original base definition of each self-service web
application page is ever displayed. Use this profile option
to help Oracle support staff determine whether a
problem arises from applied personalizations or from the
base application.
 Creating Admin-Level
Personalizations
Before anyone can personalize a region at an Admin level, you must
perform these initial steps:

1. Define an administrative user in Oracle Applications.

2. Set the "Personalize Self-Service Defn" profile option to Yes for that
user.

Every self-service web application page contains a global Personalize

button. This profile option enables the global Personalize button on
every page and displays Personalize Region links for every
personalizable region so that the administrative user can personalize
any page or region.
Per instance personalizations are available with OA Framework 11.5.10.
 Personalize a Region at the
Admin level
1. Sign-on to Oracle Self-Service Web Applications as a
user who has Admin-level personalization access.
2. Select a responsibility.
3. Navigate to the application page that contains the region
you wish to personalize.
4. Choose the Personalize ... link above the region you
wish to personalize or select the Personalize Region
global button.
• Note: If the region is a table, the Personalize Region link appears below the
table.
• Attention: If you wish to create an "Admin-seeded user-level"
personalization for a table (or hierarchy table) in a Query region, select the
Personalize Region link below the table. Do not use the Personalize Region
global button, as this eventually requires you to drill through the entire
region hierarchy tree, which is not supported when you personalize at the
Admin-seeded user-level.
 Personalize a Region at the
Admin level
5. In the Personalization Level field, select the administrative level at which you
wish to personalize the region.

Attention: To create an "Admin-seeded user-level" personalization, select the

value User in the Personalization Level field.

6. On the next page, enter a value appropriate for the Personalization level you
selected.

The Site and User levels do not require any value as the personalization
applies to all users of the current site. Other levels, such as Responsibility
or Function, for example, require a specific responsibility or function name,
respectively.

7. If you initially selected the Personalize Region link for a specific region, the
Create View or Update View page for that region should appear. Use the
Create View or Update View page to create a new view or update the
existing personalized view of the region.
 Personalize a Region at the
Admin level
8. If you initially selected the global Personalize Region button, a
navigation tree appears to the left of the Create View or Update
View page. The tree displays the hierarchy of all the regions that
make up the current application page and allows you to navigate to
any region within the page. Select the region you wish to
personalize from the navigation tree to display the Create View or
Update View page for that region.

9. If you selected to personalize a table (or hierarchy table) within a

query region at the User level, a list of available seeded views for
that table region appears in the Personal Table Views page. You
may select one of these views to edit in the Update View page. You
may also select the Create View button to create a new seeded
user-level view. The new seeded user-level personalization is later
listed in the Personal Table Views region.
Target Workflow Tables for Purging:
wf_items
• wf_item_attribute_values
• wf_notification_attributes
• wf_notifications
• wf_item_activity_statuses
• wf_item_activity_statuses_h
• wf_activities
• wf_activity_attributes
• wf_process_activities
• wf_activity_values
• wf_activity_transactions
 Workflow Administration
Purging

The following steps combined to form one approach that has been used with success.

1. Submit the Purge Obsolete Workflow Runtime Data concurrent request (FNDWFPR)
You can do this at any time. This is the first thing to do, as it will purge any and all data
related to Worflow processes that have terminated normally. If process data does not
get purged using this method, then move on to the next step.
Use the standard concurrent program FNDWFPR ”Purge Obsolete Workflow Runtime
Data” to purge old data from the Oracle Workflow runtime tables regularly.

You can supply the following parameters for the ”Purge Obsolete Workflow Runtime
Data” concurrent program:
Item Type — The item type to purge. Leaving this field blank
defaults to purging the runtime data for all item types.
Item Key — The item key to purge. Leaving this field blank
defaults to purging the runtime data for all item keys.
Age — Minimum age of data to purge, in days.
 wfstat.sql
From within SQL, run the wfstat.sql script to list any
particular process item type that is not being purged.
• If it returns a status of 'ACTIVE' in the
WF_ITEM_ACTIVITY_STATUSES table, yet the
WF_NOTIFICATIONS table shows the status for this
item as being 'CLOSED', then there may be a problem
with how the process was executed.
• The process may have never run to completion for
whatever reason, or it may have terminated abnormally.
If only a few are not being purged, try updating the table
status, or move on to the next step.
 bde_wf_data.sql
• Run the script bde_wf_data.sql -
Note 165316.1
• This queries all data that is considered to
be eligible for purging. This is a useful and
highly recommended script
 wfrmitms.sql - wfrmtype.sql
Run wfrmitms.sql and wfrmtype.sql
You can also use two provided SQL scripts to assist in the
purge process:

$FND_TOP/sql/wfrmitms.sql
$FND_TOP/sql/wfrmtype.sql

Again, please use these scripts with caution. Any process

notifications that the scripts purge by accident will need
to be re-submitted.
 Target workflow tables for purging
• wf_items
• wf_item_attribute_values
• wf_notification_attributes
• wf_notifications
• wf_item_activity_statuses
• wf_item_activity_statuses_h
• wf_activities
• wf_activity_attributes
• wf_process_activities
• wf_activity_values
• wf_activity_transactions
Purge Scripts - Step by Step
select count(*), item_type from wf_items group by
item_type

Running script to cleanup the workflow data

Go to $FND_TOP/sql , login SQLPLUS as apps and do
the following:
SQL>@wfrmtype
Enter Item Type to purge: PAAPINVW
Purge ALL items associated with this item type, or only
completed items?
Enter ALL for all data, leave blank to delete only complete
data: ALL
SQL>@wfrmtype
Enter Item Type to purge: PAXWFHRU
Purge ALL items associated with this item type, or only
completed items?
Enter ALL for all data, leave blank to delete only complete
data: ALL
 Purging Notifications
a) Login to Sqlplus as the Apps user and run the following query:
select notification_id, end_date
from wf_notifications;

This will return all the rows still remaining in the table after having gone
through a normal purge process.

b) Select one of the remaining ones that have an old end_date and run
this query:
select item_type, item_key
from wf_item_activity_statuses
where notification_id = <#> ;this corresponds to the
notification_id you picked.

This will more than likely return a row.

 Purging

c) Run the next query for your item type:

select * from wf_items
where item_type = 'item_type' ;this corresponds to the
item_type you have

That will also have an entry.

d) Execute the following procedure to remove all entries
related to the item:
SQL> execute wf_purge.total('item_type','item_key')
 Purging
e) Run $FND_TOP/sqlwfstat.sql script

Specify the item_type, and item_key from step 5.(d). It

should return no rows.

f) If the item still shows in table wf_notifications, run the

following procedure from SQL:

SQL> execute wf_purge.notifications(null,'end_date')

Here, either specify an end_date if you have a large

number of old remaining notifications, or specify an
item_type or item_key.
 Purging
These scripts are used to further analyze the data:
1) select count(*), item_type from wf_items
group by item_type
COUNT(*) ITEM_TYPE
23342 XDPWFSTD
16212 WFERROR
1204 OEOL
1144 HRSSA
332 OEOH
149 POWFRQAG
148 CS_KB_WF
98 POSPOACK
 Purging
select count(*), status, mail_status, recipient_role from applsys.wf_notifications
group by status, mail_status, recipient_role
order by count(*) desc

COUNT(*) STATUS MAIL_STATUS RECIPIENT_ROLE

53666 OPEN FND_RESP535:21704
16511 OPEN MAIL SYSADMIN
365 CLOSED FND_RESP535:21704
151 CLOSED SENT SYSADMIN
141 CLOSED SYSADMIN
90 CANCELED SYSADMIN
67 CANCELED SENT SYSADMIN
62 CANCELED ASMITH
52 CLOSED DALE
41 CLOSED MMAC
36 CLOSED JOHN
31 OPEN ERROR SYSADMIN
29 CANCELED MKTMGR
25 OPEN STEVEM
R12 Architecture
R12 Architecture
R12 Architecture
 Shared Apps Tier Mount Points
• The following is an example of mount points shared on each application tier
node:
• COMMON_TOP: /d01/shared_mount/apps/apps_st/viscomn
• APPL_TOP: /d01/shared_mount/apps/apps_st/visappl
• 10.1.2 ORACLE_HOME: /d01/shared_mount/apps/tech_st/visora/10.1.2
• 10.1.3 ORACLE_HOME: /d01/shared_mount/apps/tech_st/visora/10.1.3
• In the figure shown below, entitled "Shared Application Tier File System",
Server-ap6012rt is the primary application tier node, and uses the file
systems "/d01/shared_mount" and "/d01/local" . The file system "/d01/local"
contains the Instance Home, and "/d01/shared_mount" contains the
APPL_TOP, COMMON_TOP, 10.1.2 Oracle Home and 10.1.3 Oracle
Home.
• Server-ap6011rt is the secondary application tier node, and the shared file
system "/d01/shared_mount" is also mounted on this node. The file systems
"/d01/local/apps/<CONTEXT NAME for Server-ap6012rt>" and
"/d01/local/apps/<CONTEXT NAME for Server-ap6011rt>"are only visible
on the respective nodes.
Release 12 Architecture
Release 12
• The latest version of Oracle
Containers for Java (OC4J), the
successor to JServ, is
included in Oracle Application
Server 10g 10.1.3.

• All major services are started out

of the 10.1.3 ORACLE_HOME.

• The Applications modules

(packaged in the file
formsapp.eap) are deployed into
the OC4J-Forms instance running
out of the 10.1.3 ORACLE_HOME,
while the frmweb executable is
invoked out of the 10.1.2
ORACLE_HOME.
ORACLE_HOMEs
• The 10g Release 2 (10.2) Database
Server ORACLE_HOME replaces the
Oracle9i ORACLE_HOME used in
Release 11i.

• The Application Server 10.1.2

ORACLE_HOME (sometimes referred to
as the Tools, C, or Developer
ORACLE_HOME) replaces the 8.0.6
ORACLE_HOME provided by Oracle9i
Application Server 1.0.2.2.2 in Release
11i.

• The Application Server 10.1.3

ORACLE_HOME (sometimes referred to
as the Web or Java ORACLE_HOME)
replaces the 8.1.7-based
ORACLE_HOME provided by Oracle9i
Application Server 1.0.2.2.2 in Release
11i.
 Web Services
The Web services component of Oracle
Application Server processes requests
received over the network from the
desktop clients, and includes the following
components:
• Web Listener (Oracle HTTP Server
powered by Apache)
• Java Servlet Engine (OC4J)
• Oracle Process Manager (OPMN)
 Web Server
The Web listener component of the Oracle HTTP server
accepts incoming HTTP requests (for particular URLs)
from client browsers, and routes the requests to the
appropriate OC4J container.

If possible, the Web server services the requests itself, for

example by returning the HTML to construct a simple
Web page. If the page referenced by the URL needs
advanced processing, the listener passes the request on
to the servlet engine, which contacts the database server
as needed.
HTML-Based Applications and the Oracle
Applications Framework
The Oracle HTML-based Applications (formerly
known as Self-Service Applications) have the
following characteristics:
• Do not use Oracle Forms for the interface
• Are designed in pure HTML and JavaScript
• Dynamically generate HTML pages by executing
Java code
• Use a metadata dictionary for flexible layout
• Operate by direct connection to the Web server
 Oracle Applications Framework
The Oracle Applications Framework is the development platform for HTML-based
applications. It consists of a Java-based application tier framework and associated
Services.

• Business Components for Java (BC4J), included in Oracle JDeveloper, is used to

create Java business components for representing business logic. It also provides a
mechanism for mapping relational tables to Java objects, and allows the separation of
the application business logic from the user interface.

• AOL/J supplies the Oracle Applications Framework with underlying security and
applications Java services. It provides the Oracle Applications Framework with its
connection to the database, and with application-specific functionality such as
flexfields.

The Framework-based applications logic is controlled by procedures that execute

through the Java servlet engine, which is provided by the Apache JServ module.

The servlet engine uses the metadata dictionary in constructing the Framework UI.
Java Servlet Access with HTML
Applications
HTML-based Applications use the
following access path:

1. The user clicks the hyperlink of a

function from a browser.
2. The browser makes a URL request
to the Web listener.
3. The Web listener contacts the
Servlet engine (OC4J), where it runs a
JSP.
4. The JSP obtains the content from
the Applications tables and uses
information from the metadata
dictionary to construct the HTML page.
5. The resulting HTML page is passed
back to the browser, via the Web
server.
 Forms Services
By default, Forms services in Oracle Applications Release
12 are provided by the Forms listener servlet, which, as
described further below, facilitates the use of firewalls,
load balancing, proxies, and other networking options.

Benefits of using the Forms listener servlet include:

• Ability to re-establish dropped network connections

• Fewer machines and ports need to be exposed at the
firewall
• Easier firewall/proxy server configuration
• More robust and secure deployment over the Internet
 Forms Listener Servlet Architecture
The Forms listener servlet is a Java servlet that allows Oracle Forms
applications to run over HTTP or HTTPS connections. It hosts the Oracle
Applications forms and associated runtime engine, mediating the
communication between the desktop client and the Oracle database server,
displaying client screens, and initiating changes in the database.

The Forms listener servlet caches data and provides it to the client as needed,
for example when scrolling through multiple order lines that exceed the
limitations of a single screen.

Forms listener servlet can communicate with the desktop client using these
network protocols:

• Standard HTTP network connection

• Secure HTTPS network connection
• TCP/IP connection
 Forms Listener Servlet
The Forms listener servlet communicates with the Oracle
database server using the Oracle Netnetworking
infrastructure.
The Forms listener servlet manages the creation of a Forms
runtime process for each client, as well as network
communications between the client and its associated
Forms runtime process. The client sends HTTP requests
and receives HTTP responses from the Web services,
which acts as the network endpoint for the client.
Note: Although the OC4J-Forms instance runs out of the
Oracle Application Server (AS) 10.1.3 ORACLE_HOME,
the frmweb executable is invoked out of the AS 10.1.2
ORACLE_HOME.
Forms Socket Mode Architecture
In the traditional Forms server socket mode architecture,
when a user initiates an action in the Forms client applet
(such as entering data into a field or clicking a button),
data is passed to a Forms server on the application tier.

The user interface logic runs in the Forms server, and

determines the appropriate user interface effect based
on the user's action.

For example, a window may open, or another field value

may be populated. If necessary, the database tier is
contacted for any data not already cached on the
application tier, or for data-intensive processing.
Forms Socket Mode
Once a connection has been
made, many operations can be
performed with little or no
further interaction with the Forms
server.

For example, when a few field

values change in response to a
user action, there is no need to
update the entire screen. In this
scenario, only the changed fields
are updated with the new values.
 Choice of Mode
By default Oracle Applications Release 12 utilizes
Forms listener servlet mode. However, socket
mode is still fully supported, and its use may be
required in a WAN environment, to improve
performance.

Note: For more details of utilizing Forms Socket

Mode, see Oracle MetaLink Note 384241.1.