Oracle EBS, Oracle Database, Oracle Technical, Oracle Functional: ORACLE EBS TECHNICAL TRAINING

This is a training manual to the implementation of the Oracle E-Business suite. The intended audience of this manual is the Oracle Applications System Administrator, Oracle Applications DBA and Developers who would be integrating custom forms and reports with Oracle Applications

We will be covering following topics in the document:

Oracle Application Architecture
Applications File System
File Structure for Oracle Applications
The Oracle Database in context of Oracle Applications
Oracle Applications Server Administration Scripts
Oracle Application System Administration Menu
Profile Options
Concurrent Request, Program & Processes
Installation

1.1 Application Software

Oracle Applications R12 will be installed and following table describes patch set level of different applications: (fnd_product_installations)

Application Name Level	Patch Level
Application Object Library	R12.FND.B.1
General Ledger	R12.GL.B.1
Assets	R12.FA.B.1
Payables	R12.AP.B.1
Recevables	R12.AR.B.1
Cash Management	R12.CE.B.1
Bills of Material	R12.BOM.C.1
Work In Process	R12.WIP.B.1
Purchasing	R12.PO.B.1
Inventory	R12.INV.B.1
Order Management	R12.ONT.B.1
Order Entry	R12.OE.B.1
Shipping Execution	R12.WSH.B.1

2 Oracle Application Architecture

Oracle Applications architecture is a framework for multi-tiered, distributed computing that supports Oracle Applications products. In this model, various services are distributed among multiple levels, or tiers.

A Service is a process or group of processes running on a single machine that provides a particular functionality. The HTTP service is a process that listens and processes HTTP requests, and the Forms service is a process that listens and processes requests for Oracle Forms.

A tier is a group of services, potentially across physical machines. The tiers that compose Oracle Applications are the database tier, which manages the Oracle database; the application tier, which manages Oracle Applications and other tools; and the desktop tier, which provides the user interface display. Only the presentation layer of Oracle Applications is on the desktop tier in the form of a plug-in to a standard Internet browser. Note that the tiers are logical groupings, and do not represent physical nodes or machines. Each tier can consist of one or more nodes and each node can accommodate more than one tier. For instance, the database server can reside on the same node as one or more servers in the application tier.

Because Oracle Applications software is centralized, the need to install and maintain application software on each desktop client is eliminated. The software on the application tier also enables Oracle Applications to scale with load and to keep network traffic low.

Figure 2-1

The connection between the application tier and the desktop tier can operate over a WAN/LAN. The desktop and application tiers exchange a minimum amount of information, such as field value comparison differences. In a global operation with users at diverse locations, less network traffic means less telecommunications expense and better performance.

2.1 Desktop Tier

The client interface is provided through HTML for the Self-Service interface, and a Java applet for the professional, forms-based interface using a Java -enabled Web browser. The desktop client with Java Virtual Machine downloads the applet on demand and the applet is cached locally for future use.

Figure 2-2

Forms Client Applet

The forms client applet is a general-purpose presentation applet that supports all Oracle Applications forms-based products, including those with customizations and extensions. The Forms client applet is packaged as Java archive (JAR) files. The JAR files contain all Java classes required to run the presentation layer of Oracle Applications forms.
The Forms client applet and commonly used JAR files are downloaded from the Web server at the beginning of the client’s first session. Other less commonly used JAR files are downloaded as needed. The JAR files remain in the disk cache on the desktop, ready for future sessions, minimizing network traffic.

All updates are installed on the application tier and downloaded to the client automatically through the use of the Java-enabled Web browser.

Desktop Java Client

The Forms client applet must run within a Java Virtual Machine (JVM) on the desktop client. The Sun J2SE Plug-in component allows use of the Oracle JVM on web clients, instead of the browser's own JVM. This is implemented as a browser plug-in. In the traditional, Forms-based Oracle Applications environment, the JVM (which in earlier releases was known as Oracle JInitiator) was run as part of the standard Applications sign-on process. Now, with the move to a mainly HTML-based environment, the JVM (now the J2SE Plug-in) is only invoked when a user chooses to access functions that require it, such as running a form. If the J2SE Plug-in has not been installed, the browser prompts the user to download the required installation executable. After you download and install the plug-in, you will be able to run Forms-based applications.

2.2 The Application Tier

The application tier hosts the servers that process the business logic and provides the communication between the desktop tier and the database tier. This tier is also referred to as the middle tier. The web and form services are provided by Oracle Application Server (OracleAS) 10 g.

· Web server
· Forms server

· Concurrent Processing server
· Admin server

Web Server

The Oracle HTTP server (powered by Apache) is the Web server. It processes the requests received over the network from the desktop clients. It includes additional components such as:

· Web Listener

· Java Servlet Engine

The Web listener component of the Oracle HTTP server accepts incoming HTTP requests (URLs) from desktop clients (browsers). If possible, the Web server services the requests itself, for example, by returning an HTML 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.

The Forms Server

The Forms server hosts the Oracle Applications forms and the forms runtime engine that support the professional interface. The Forms server is an Oracle Developer 10g component which mediates the communication between the desktop client and the Oracle data server by displaying client screens and initiating changes in the database records based on user actions.

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 these protocols:

· Secure HTTPS network connection

· Standard HTTP network connection
· TCP/IP connection

HTTP and HTTPS support enables operation over a firewall. The Forms server communicates with the Oracle data server using Net8.

Figure 2-3

Concurrent Processing Server

User interactions with Oracle Applications data are conducted through the Self-Service
Applications and the Forms -based Professional interface. However, there are reporting
programs and data updating programs that run periodically on an ad hoc basis. These
programs, which operate in the background while users continue to work on other tasks,
may contain a very large number of data-intensive computations. To ensure that they do
not interfere with interactive operations, they are run on the Concurrent Processing
server.

Processes that run on the Concurrent Processing server are called concurrent requests. When you submit a request, either through Forms or Self-Service Applications, a row is inserted into a database table specifying the program to be run. Concurrent managers read the applicable requests in the table and start the concurrent programs. The Internal Concurrent Manager service monitors the database table for new requests, controls the other concurrent managers, and determines when a request should be processed and which concurrent manager should carry it out. Log and output files are generated on the Concurrent Processing server.

Figure 2-4

Accessing Concurrent Processing Output

The Concurrent Processing server communicates with the data server using Net8. The resultant log or output file from a concurrent request is passed back to the Report Review Agent, also known as the Web Review Agent. The Report Review Agent passes a file containing the entire report to the Forms server. The Forms server passes the report back to the user’s browser one page at a time. You can use profile options to control the size of the files and pages passed through the system.

Admin Server

The Admin server is located on the node where you maintain the data model and data in
your Oracle Applications database. You carry out the following operations from this
server.

Upgrading Oracle Applications

This process is conducted only when you are upgrading to a new release (from an earlier one, such as 10.7 or 11.0). You use the AutoUpgrade utility (adaimgr) to upgrade Oracle Applications.

Applying patches to Oracle Applications

Most patches consist of files and scripts that update the file system and/or database objects. You use the AutoPatch utility (adpatch) to perform these updates. AutoPatch may also be used to apply cumulative patches such as minipacks (for example, R12.GL.A) and maintenance packs.

The Database Tier

The database tier contains the database server, which stores all the data maintained by Oracle Applications. It also contains some processing code that is stored in the database to optimize performance. In Release R12.1.1, the database includes the Oracle Applications online help information as well.

More specifically, the database tier contains the Oracle data server files and Oracle Applications database executables that physically store the tables, indexes, and other database objects for your system.

In general, the database server does not communicate directly with the desktop clients, but rather with the servers on the application tier, which mediate the communications between the database server and the client.

3 Applications File System

An Oracle Applications Release 12 system utilizes components from many Oracle products. These product files are stored below a number of key top-level directories on the database and application server machines.

Note: No Applications files are installed on desktop client machines, although JAR files and their supporting utilities are downloaded as required.

Depending on how you chose to install Applications, these product directories may be located on a single machine (the simplest case) or on multiple machines (the most common type of deployment). Operating system environment settings indicate the location of the various files in the file systems of the database and application server machines. This chapter discusses the association between these environment settings and the corresponding files and directories.

Figure 3-1

• The db/apps_st/data (DATA_TOP) directory is located on the database node machine, and contains the system tablespaces, redo log files, data tablespaces, index tablespaces, and database files

• The db/tech_st/11.1.0 directory is located on the database node machine, and contains the ORACLE_HOME for the Oracle 11g database

• The apps/apps_st/appl (APPL_TOP) directory contains the product directories and files for Oracle Applications

• The apps/apps_st/comn or (COMMON_TOP or COMN_TOP) directory contains directories and files used across products

• The apps/tech_st/10.1.2 directory contains the ORACLE_HOME used for the Applications technology stack tools components

• The apps/tech_st/10.1.3directory contains the ORACLE_HOME used for the Applications technology stack Java components

3.1 Oracle Applications Environment

Oracle Applications makes extensive use of environment settings to locate executable programs and other files essential to Applications operation. These environment settings are defined when you install Oracle Applications. Many of the settings are defined by information you provide when running Rapid Install, while others have the same values in all installations.

The environment settings and their associated values are stored in environment files, which have a .env suffix on UNIX.

Figure 3-2

Read-Only File Systems

A key benefit of moving to the new Instance Top model is that AutoConfig no longer writes to the APPL_TOP or ORACLE_HOME directories, so these can both be made read-only file systems if required. In previous Applications releases, the adpatch utility wrote to $APPL_TOP/admin on a patching/admin node: under the new model, $APPL_CONFIG_HOME/admin is used instead. $APPL_CONFIG_HOME will equate to a value such as <diskresource>/appmgr/apps/apps_st/appl.

Log Files

Another advantage of employing the concept of an Instance Home is that log files can be stored centrally for an instance, and therefore managed more easily. This is particularly important for security, as log files may contain data that should not be seen by unauthorized users.

The following diagram shows the directory structure used for log files in Release 12, with some of the subdirectories used to categorize the log files:

Figure 3-3

3.2 Top-Level Directories

The data Directory

The db/apps_st/data file system contains the data (.dbf) files of the Oracle database. Rapid Install installs the system, data, and index files in directories below several mount points on the database server. You can specify the directory names of the mount points on the database server during installation.

The db Directory

Oracle Applications supports employing an Applications database running out of one ORACLE_HOME, while running other Applications components out of additional ORACLE_HOMEs. This multiple ORACLE_HOMEs configuration allows Applications to utilize new features of the Oracle database and associated technologies in the most

flexible manner.

Release 12 utilizes a 10g Release 2 (10.2) ORACLE_HOME, (Applications database home) whose files are located under the db directory. These files are needed for running and maintaining the Oracle Applications database.

The comn Directory

The apps/apps_st/comn (COMMON_TOP) directory contains files used by many different Oracle Applications products, and which may also be used with third-party products.

Figure 3-4

The html directory

The OA_HTML environment setting points to the html directory. The Oracle Applications HTML-based sign-on screen and Oracle HTML-based Applications HTML files are installed here. The html directory also contains other files used by the HTML-based products, such as JavaServer Page (JSP) files, Java scripts, XML files, and style sheets. Typically, the path will look like:<diskresource> /appmgr /apps/apps_st /comn /webapps /oacore /html.

The java directory

Rapid Install installs all Oracle Applications class files in the COMMON_TOP/classes directory, pointed to by the $JAVA_TOP environment variable. Zip and jar files are installed in the $COMMON_TOP/lib directory, pointed to by the $AF_JLIB environment variable.The top-level Java directory, $COMMON_TOP/java, is pointed to by the $JAVA_BASE environment variable.

The util directory

The util directory contains the third-party utilities licensed to ship with Oracle Applications. These include, for example, the Java Runtime Environment (JRE), Java Development Kit (JDK), and the Zip utility.

The appl (APPL_TOP) Directory

Oracle Applications files are stored in the <dbname>APPL directory, which is known as the APPL_TOP directory.

APPL_TOP Directory Structure

Figure 3-5

The APPL_TOP directory contains:

• The core technology files and directories.

• The product files and directories (for all products).

• The main applications environment file, called <CONTEXT_NAME>.env on UNIX.

• The consolidated environment file, called APPS<CONTEXT_NAME>.env on UNIX.

Warning: All Oracle Applications products are installed in the database and the file system, regardless of registration status. Do not attempt to remove files for any unregistered products. Rapid Install installs a new Applications top directory when you upgrade. Rapid Install does not delete any existing product files from earlier releases, but unloads new product files into a new apps/apps_st/appl directory tree.

Each Applications top directory is associated with a single Oracle Applications database on the Oracle database server. If you install both a Vision Demo system and a test system, Rapid Install will lay down two file systems, one for each of these Applications systems.

3.3 Product Directories

Each product has its own subdirectory under APPL_TOP. The subdirectories are named in accordance with the product's standard abbreviation, such as gl for Oracle General Ledger. Within each product directory is a subdirectory that is named using the base Oracle Applications release number, such as 12.0.0. This directory contains the various subdirectories for the product files.

<PROD>_TOP Directory

The <APPL_TOP>/<prod>/<version> path is known as the product top directory (<PROD>_TOP), and its value is stored in the <PROD>_TOP environment variable. For example, if APPL_TOP=/oracle/apps/apps_st/appl, then the value contained in the AD_TOP environment variable is /oracle/apps/apps_st/appl/ad/12.0.0, and the AD_TOP environment variable points to the <APPL_TOP>/ad/12.0.0 directory. For the same APPL_TOP, the value of AU_TOP is /d01/oracle/prodapps/au/12.0.0, and the AU_TOP environment variable points to the <APPL_TOP>/au/12.0.0 directory. The same principle applies to all directories, apart for the admin directory.

Product Files

Each <PROD>_TOP directory, such as <APPL_TOP>/gl/12.0.0, contains subdirectories for product files. Product files include forms files, reports files, and files used to upgrade the database. To display data entry forms for Oracle General Ledger, for example, Oracle Applications accesses files in the forms subdirectory under the 12.0.0 directory.

Figure 3-6

Within each <PROD>_TOP directory, the product's files are grouped into subdirectories according to file type and function. The next figure expands the inset to show the full directory structure for gl.

Figure 3-7

The following table summarizes the product subdirectories and the types of files each one may contain.

3.4 Application Directory and file types

Subdirectory Name	Description
Admin	The <PROD_TOP>/admin directory contains product specific files used to upgrade each product. This is in distinction to the <APPL_TOP>/admin directory, which contains upgrade-related files for all products.
Driver	Contains driver files (.drv files) used in upgrading.
Import	Contains Data Merge files used to upgrade seed data.
Odf	Contains object description files (.odf files) used to create tables and other database objects.
Sql	Contains SQL*Plus scripts used to upgrade data and .pkh, .pkd and .pls scripts to create PL/SQL stored procedures.
Bin	Contains concurrent programs, other c language programs and shell scripts for each product.
Forms	Contains Oracle Forms generated runtime (.fmx) fiels.
Help	Contains the online help source files. Within this directory are subdirectories for each language installed.
Html	Contains HTML, Java Script and Java server Page (JSP) files, primarily for HTML based Application products.
Include	Contains C language header (.h) files that may be linked with files in the lib directory. Not all products require this directory.
Java	Contains JAR files (Java Archive files) and Java dependency files. Copies of JAR files are also located in the $AF_JLIB directory.
Lib	Contains files used to relink concurrent programs with the Oracle server libraries. These files include: Object files (.o on UNIX, .OBJ on windows), with compiled code specific to one of the products programs. Library files (.a on UNIX, various including .DLL on Windows), with compiled code common to the product’s programs. Make files (.mk) that specify how to create executables from object files and library files.
log and out	Contains output files for concurrent programs: .mgr (master log file for concurrent manager) .req (log file for a concurrent process) Note that log and out subdirectories under a product directory are not used if you choose to set up a common directory for log and output files (FND_TOP is the only exception to this).
Media	Contains .gif files used in the display of text and graphics on the desktop client.
Mesg	Concurrent programs also print messages in the log and output files. This directory contains the .msb files (binary message files used at runtime) and language specific message files (such as US.msb file for American English and D.msb file for German). The files contain the forms messages that are displayed at the bottom of the screen or in popup windows.
Patch	Updates to the data or data model utilize this directory to store the patch files.
Reports	Contains Oracle reports platform specific .rdf binary report files for each product. Reports for each language are stored in subdirectories of the reports directory.
Resource	Contains .pll files (PL/SQL library files for Oracle Forms) which like the plsql directory fiels are later copied to AU_TOP.
Sql	Contains .sql fiels (SQL*Plus scrips) for concurrent processing.

3.5 Locations of Applications Environment Files

The location of these environment files is shown in the following table.

Filename	Location	Path	Environment
<CONTEXT_NAME>.env or <CONTEXT_NAME>.cmd	ORACLE_HOME	db/tech_st/11.1.0	Oracle Server Enterprise Edition
<CONTEXT_NAME>.env or <CONTEXT_NAME>.cmd	As 10.1.2 ORACLE_HOME	inst/apps/<context>/ora/10.1.2	Oracle tools technology stack
<CONTEXT_NAME>.env or <CONTEXT_NAME>.cmd	As 10.1.3 ORACLE_HOME	inst/apps/<context>/ora/10.1.3	Java technology stack
<CONTEXT_NAME>.env or <CONTEXT_NAME>.cmd	APPL_TOP	apps/apps_st/appl	Application
<CONTEXT_NAME>.env or <CONTEXT_NAME>.cmd	APPL_TOP	apps/apps_st/appl	Consolidated setup file

The following table lists the key environment settings in

APPS<CONTEXT_NAME>.env.

Parameter	Description
APPLFENV	The name of the environment file, <CONTEX_NAME>.env. If your rename the environment file, this parameter setting must be updated.
PLATFORM	The operating system in use. The value (e.g LINUX) should math the value in the APPL_TOP/admin/adpltfrm.txt file.
APPL_TOP	The top level directory for this Oracle Applications installation.
ADMIN_SCRIPTS_HOME	Directory under $INST_TOP that identifies the location of scripts such as adautocfg.sh, adpreclone.sh, adstrtal.sh and adstpall.sh.
FNDNAM	The name of the ORACLE schema to which the System Administrator responsibility connects. The default is APPS.
GWYUID	The public ORACLE username and password that grants access to the Oracle Applications initial sign on form. The default is APPLSYSPUB/PUB.
FND_TOP	The path to the Application Object Library directory. For example, apps/apps_st/appl/au/12.0.0.
AU_TOP	The path to the Applications Utilities directory. For example, apps/apps_st/appl/au/12.0.0.
PROD_TOP	The path to a product’s top directory. There is one entry for each Oracle Applications product.
PATH	Sets the directory search path, for example for FND_TOP and AD_TOP.
APPLDCP	Specifies whether distributed concurrent processing is being used. Distributed concurrent processing distributes processing load across multiple concurrent processing nodes.
APPCPNAM	Indicates whether the format of the concurrent manager log and output files follow 8.3 file name conventions (maximum of 8 characters to the left of the dot and 3 to the right, for example, alogfile.log). If this parameter is set to “REQID” (required), the concurrent manager uses file names that meet 8.3 naming requirements.
APPLCSF	Identifies the top level directory for concurrent manager log and output files if they are consolidated into a single directory across all products. For example, /inst/apps/<context>/logs/appl/conc.
APPLLOG	The subdirectory for concurrent manager log files. The default is log.
APPLOUT	The subdirectory for concurrent manager output files. The default is out.
APPLTMP	Identifies the directory for Oracle Applications temporary files. The default is /tmp on UNIX and C:\temp on Windows.
APPLPTMP	Identifies the top level directory for this instance. For example, inst/apps/<context>. Introduced with Release 12.
INST_TOP	Identifies the top level directory for this instance. Form example, inst/apps/<context>. Introduced with Release 12.
NLS_LANG	The language, territory and character set installed in the database. The default for a fresh install is “AMERICAN_AMERICA.US7ASCII”.

Parameters Specified in the adovars.env File

Parameter	Description
AF_JLIB	Indicates the directory to which all java archive files are copied. For example, apps/apps_st/comn/java/lib. Introduced with Release 12.
JAVA_BASE	Indicates the top level Java directory. For example, apps/apps_st/comn/java. Introduced with Release 12.
JAVA_TOP	Indicates the directory to which all Java class files are copied. For example, apps/apps_st/comn.java/classes. Definition has changed with Release 12.
OA_JAVA	Indicates the directory to which all Java archive files are copied. For example, apps/apps_st/comn/java/classes.
OA_JRE_TOP	Indicates the location where the JRE is installed. For example, local/java/jdk1.5.0_08.
OAH_TOP	Defines the location to which HTML files are copied .for example, apps/apps_st/comn/webapps/oacore.
OAD_TOP	Defines the locations to which context sensitive documentation files are copied .for example, apps/apps_st/comn.
LD_LIBRARY_PATH	Path used on many UNIX platforms to list the directories that are to be scanned for dynamic library files needed at runtime.
CLASSPATH	Lists the directories and zip files scanned for Java class files needed at runtime.

The adconfig.txt file

AD utility programs performs a variety of database and file management tasks. These utilities need to know certain configuration information to run successfully. This configuration information is specified when Oracle Applications installed and subsequently stored in the adconfig.txt file in the <APPL_TOP>/admin directory. Once it has been created, this file is used by other Oracle Applications utilities.

Note: adconfig.txt is created with the APPL_TOP file system, and it shows the tiers that have been configured on a particular node. It is distinct from the config.txt file employed by Rapid Install.

The fndenv.env file

This file sets additional environment variables used by the Application Object Library. For example, it sets APPLBIN as the name of the subdirectory where product executable programs and shell scripts are stored (bin). This file should not be modified: the default values are applicable for all customers. The file is located in the FND_TOP directory.

The devenv.env file

This file sets variables that let you link third-party software and your own custom-developed applications with Oracle Applications. In Release 12, this script is located in FND_TOP/usrxit, and is automatically called by fndenv.env. This allows you to compile and link custom Oracle Forms user exits and concurrent programs with Oracle Applications.

4 The Oracle Database in context of Oracle Applications

4.1 Basic Data Model

A database can contain only one installation of Oracle E-Business Suite products. Generally, product data objects are stored in product Oracle schemas and product code objects are stored in the APPS schema.

4.2 Oracle User IDs

Each Oracle E-Business Suite product has a default Oracle user ID with the product abbreviation as both the schema name and password. For example, the default Oracle user ID for Oracle General Ledger is GL/GL.

A product’s schema determines the ownership of the product’s data objects, such as sequences, tables, and indexes.

Attention: We recommend you do not change the default user IDs, but you should change the password.

Since a product’s data objects are created in their own schema (such as the GL schema) but the user accesses all data objects through the APPS schema, there are necessary grants and synonyms between the APPS schema and the base product schemas.

4.3 APPS Schema

The APPS schema has access to the complete Oracle E Business Suite data model. It is analogous to the SYSTEM schema, which has access to the entire database. Oracle Applications responsibilities connect to an APPS schema and the environment variable FNDNAM is set to the name of the APPS schema.

4.4 Base Product Schemas

There is one schema for each product—a base product schema —that owns the data
objects for that product. There is one schema —APPS—that owns all the code objects for
the E-Business Suite and has access to all data objects. There is one APPS schema for
every product installation group. The following code objects are installed in the APPS
schema:

· Views
· Packages
· Procedures
· Functions
· Triggers

The following objects are installed in the base product schemas:
· Tables

· Sequences
· Indexes

· Constraints

In addition, there are grants from the tables and sequences to the APPS schema, as well as synonyms from the APPS schema to those objects.

The figure below shows APPS Schema and Base Product Schemas

Figure 4-1

4.5 Custom Schema Access

In some circumstances you may wish to create a schema that has limited or read-only access to Oracle Applications data. For example, you might do this so your users can query Oracle Applications using a data query tool like SQL*Plus. Grant access on objects to the user schema from the base product schema.

Warning: Since the APPS schema has all privileges to all Oracle Applications objects, you should not give users direct access to this schema.

4.6 Data Access

Some views access packages or functions, but the value returned by the package or function may depend on the environment. The environment is initialized automatically when accessing Oracle Applications through the Sign-On screen or when using concurrent processing with Oracle Reports or SQL scripts.

If you connect directly to a schema, the rows returned by the view may be different from those returned if you are running in an Oracle Applications environment. For example, some views reference profile options. When accessed from SQL*Plus directly, the site value of the profile option is used, not the setting for a particular applications user.

Note: You may need to re-grant access if the underlying object is dropped and recreated.

5 Maintenance and Performance

5.1 Performance tuning through statistics

The R12 application was written to use the CBO.CBO stands for Cost Based Optimization. It determines the most efficient way to execute a SQL statement based on statistical data stored in the data dictionaries. These stored statistics are used to compute the cost of executing the SQL. The execution plan with the lowest cost is the one chosen by the optimizer.

You can also run the following concurrent programs from System Administrator to generate statistics:

· Gather Schema Statistics

· Gather Table Statistics

· Gather Column Statistics

When you gather statistics for a table or a whole schema, it cascades down and gathers also the statistics for all indexes on each table and all columns for that particular table or schema.

Gather Schema Statistics

This concurrent program gathers the specified schema level statistics. Before gathering the statistics, this program also creates a backup of the existing statistics so that if the database slows down after gathering new statistics, you can restore the system to its previous status. The statistics ID used for this backup is NULL. After gathering the schema level statistics this program creates the histogram for the specified columns in the FND_HISTOGRAM_COLS tables.

Also, this program populates default statistics for all the INTERFACE tables as specified in the FND_EXCLUDE_TABLE_STATS table. You should run this concurrent program periodically.

Gather Table Statistics

The Gather Table Statistics program gathers the table statistics for the specified table. This program keeps a backup of existing statistics in the FND_STATTAB table before gathering new statistics. This program also gathers the related index statistics by default.

Gather Column Statistics

This concurrent program is actually two procedures, which gather column statistics. One procedure gathers the column statistics for all the columns specified in the SEED data table FND_HISTOGRAM_COLS. The second procedure gathers the column statistics for a specified column name in a given table. The procedure takes a backup into the FND_STATTAB table before gathering the statistics.

5.2 Define Multiple Managers

Define separate Manager for program taking heavy resources.

Figure 5-1

5.3 Network Test

In order to test the speed of your LAN or WAN you can use the standard function available in Oracle Application.

1. Logon as System Administrator.

2. Navigate to Application -> Network Test

Figure 5-2

Network Test Form will appear, Click on “Run Test” Button

Figure 5-3

The Network Test consists of a latency test and a bandwidth test. Latency is the time it takes for a single packet to make a round trip from your client side application to the server. The bandwidth test examines the data rate to see how many bytes per second your network can transfer from the server to the client

5.4 Common Maintenance Tasks

1- Compile Invalid Objects

2- File Versions
3- Kill Session

4- Knowing Patches and Patch set Level
5- Terminate Request

6- Run adadmin

7- Trace & Tkprof
8- Script Execution

6 Start Stop Services

Both database and application can be started and stopped through scripts on following locations.

6.1 DB Services

Two scripts used for this (i.e. for db and listener), which are mentioned as last two entries in the table below. These are located at ORACLE_HOME/appsutil/scripts/<SID>_<HOSTNAME>

6.2 Application Services

Rest of the scripts in table below are for application and located at inst/apps /<SID>_<HOSTNAME> /admin/scripts Each of these scripts set their own environment, so you do not need to have an environment set prior to running it.

6.3 Verify Current Status

To verify whether a service is currently running or not. We can check its process with following command:

ps -ef |grep <GREP VALUE>

Substitute the variable <GREP VALUE> with the value given in last column of table below for each component.

6.4 Start Stop Order

The table below lists the services in the order in which these services should be stopped. For starting reverse the order.

Script	Process	Executable	Log	Parameters	Grep Value
Adcmctl.sh	Concurrent Manager	startmgr	None	{start\|stop} APPS/APPS	FNDLIBR
Adfrmctl.sh	Forms Serve Listener	F60ctl	f60svrm.txt	(start\|stop)	f60srvm
adfmctl.sh	Form Matrics Server	D2s60	d2ls60.txt	(start\|stop)	d2ls60
Adrepctl.sh	Reports Server	Rwmts60	adrepctl.txt	(start\|stop)	rwmts60
adtcfctl.sh	TCF Server	Jre	adtcfctl.txt	(start\|stop)	Jre
adfmcctl.sh	Form Matrics Server	D2lc60	d2lc60.txt	(start\|stop)	d2lc60
Adapcctl.sh	Apache Listener	Apachectl	error_log*	(start\|stop)	Apache*
Adalnctl.sh	APPS Listener	Lsnrctl	adalnctl.txt	(start\|stop) tnslsnr APPS_<SID>	tnslsnr
Addlnctl.sh	Database Listener	addlnctl.sh	None	(start\|stop) <SID>	tnslsnr
addbctl.sh	Database	Sqlplus	None	(start\|stop)	smon

*/oracle/inst/apps/PROD_testoracle/logs/ora/10.1.3/Apache/error_log

7 Oracle Application System Administration Menu

A System Administrator is a person responsible for controlling access to Oracle Applications and assuring smooth ongoing operation. Each site where Oracle Applications is installed needs a system administrator to perform tasks such as:

· Managing and controlling security:

Decide which users to create and which user have access to each application, and within an application, which forms, functions, and reports a user can access.

· Setting user profiles:

A user profile is a set of changeable options that affects the way Oracle Applications look and behave. A System Administrator can set user profile values at the site, application, responsibility, and user levels.

· Managing concurrent processing:

Concurrent Processing is an Oracle Applications facility that lets long-running, data-intensive tasks run simultaneously with online operations, taking full advantage of multitasking and parallel processing. A System Administrator can monitor and control concurrent processing using a few simple forms.

As System Administrator, you define Oracle Applications users, and assign one or more responsibilities to each user.

7.1 Defining Application Users

You allow a new user to sign-on to Oracle Applications by defining an application user. An application user has a username and a password. You define an initial password, then the first time the application user signs on; they must enter a new password. When you define an application user, you assign to the user one or more responsibilities.

Use this window to define an application user. An application user is an authorized user of Oracle Applications and/or Oracle Self-Service Applications who is uniquely identified by an application username. Once defined, a new application user can sign on to Oracle Applications and access data through Oracle Applications windows.

Figure 7-1

User Name Enter the name of an application user. An application user enters this username to sign on to Oracle Applications.

·The username must not contain more than one word.

·You should use only alphanumeric characters (’A’ through ’Z’, and ’0’ through ’9’) in the username.

Please note that you must limit your username to the set of characters that your operating system supports for filenames.

Suggestion: We recommend that you define meaningful usernames, such as the employee’s first name followed by a dot and then the last name, e.g. Ali.Akram Or, for a group account, you can
define the application username so as to indicate the purpose or nature of the group account.

Password Enter the initial password of an application user. An application user enters this password along with her or his username to sign on to Oracle Applications.

· A password must be at least five (5) characters and can be up to thirty (30) characters.

· All characters are allowed except control characters, which are non-printable. Oracle encourages the use of non-alphanumeric characters because they add complexity, making passwords harder to guess.

This window does not display the password you enter. After you enter a password, you must re-enter it to ensure you did not make a typing error.

If the application user already exists and the two entries do not match, the original password is NOT changed, and you navigate automatically to the next field.

If you are defining a new application user and the two entries do not match, you are required to enter the password again. For a new user, you cannot navigate to the next field until the two entries match. The first time an application user signs on, they must change his or her password. If a user forgets their password, you can reassign a new password in this field.

Password Expiration As System Administrator, you can set an initial password or
change an existing password, but you cannot access the user’s chosen password. You can
set the minimum length of Oracle Applications user passwords using the profile option
Signon Password Length. If this profile option is left unset, the minimum length defaults
to 5.

You can set the minimum number of days that a user must wait before being allowed to reuse a password with the Signon Password No Reuse profile option. You can use the profile option Signon Password Hard to Guess to set rules for choosing passwords to ensure that they will be ”hard to guess.” A password is considered hard-to-guess if it follows these rules:

· The password contains at least one letter and at least one number.

· The password does not contain the username.

· The password does not contain repeating characters.

Person, Customer, and Supplier Use these fields to enter the name of an employee (person), customer, or supplier contact. Enter the last name and first name, separated by a comma, of the employee, customer, or supplier who is using this application username and password. Use the List of Values to select a valid name.

E-Mail/Fax Enter the E-mail address and/or fax number for this user.

Days enter the maximum number of days between password changes. A pop-up window prompts an application user to change her or his password after the maximum number of days you specify has elapsed.

Accesses enter the maximum allowed number of sign-ons to Oracle

Effective Date the user cannot sign onto Oracle Applications before the start date and after the end date.

The default for the start date is the current date. If you do not enter an end date, the username is valid indefinitely.

You cannot delete an application user from Oracle Applications because this information helps to provide an audit trail. You can deactivate an Oracle Applications user at any time by setting the End Date to the current date.

If you wish to reactivate a user, change the End Date to a date after the current date, or clear the End Date field.

Responsibility Select the name of a responsibility you wish to assign to this application user. A responsibility is uniquely identified by application name and responsibility name.

Security Group this field is for HRMS security only.

From/To you cannot delete a responsibility because this information helps to provide an audit trail. You can deactivate a user's responsibility at any time by setting the End Date to the current date.

Securing Attributes Securing attributes are used by Oracle Self-Service Web
Applications to allow rows (records) of data to be visible to specified users or
responsibilities based on the specific data (attribute values) contained in the row.
You may assign one or more values for any of the securing attributes assigned to the user.
If a securing attribute is assigned to both a responsibility and to a user, but the user does
not have a value for that securing attribute, no information is returned for that attribute.
For example, to allow a user in the ADMIN responsibility to see rows containing a
CUSTOMER_ID value of 1000, assign the securing attribute of CUSTOMER_ID to the
ADMIN responsibility. Then give the user a security attribute CUSTOMER_ID value of
1000.

When the user logs into the Admin responsibility, the only customer data they have access to has a CUSTOMER_ID value of 1000.

Attribute Select an attribute you want used to determine which records this user can access. You can select from any of the attributes assigned to the user's responsibility.

Value Enter the value for the attribute you want used to determine which records this user can access.

7.2 Defining Application Menus

Define a new menu or modify an existing menu.

A menu is a hierarchical arrangement of functions and menus of functions. Each responsibility has a menu assigned to it.

A "full access" responsibility with a menu that includes all the functions in an application
is predefined for each Oracle Applications product. As a System Administrator, you can
restrict the functionality a responsibility provides by defining rules to exclude specific
functions or menus of functions. In fact, we recommend that you use exclusion rules to
customize a responsibility in preference to constructing a new menu hierarchy for that
responsibility.

If you cannot create the responsibility you need by applying exclusion rules, you may build a custom menu for that responsibility using predefined forms (i.e., form functions) and their associated menus of sub functions. However, we recommend that you do not disassociate a form from its developer-defined menus of sub functions.

After you save your changes in this form, a request is submitted to compile the menu
data.

Figure 7-2

Menu Choose a name that describes the purpose of the menu. Users do not see this menu name.

View Tree Once you have defined a menu, you can see its hierarchical structure in the "View Tree..." button.

User Menu Name You uses the user menu name when a responsibility calls a menu or when one menu calls another.

Menu Type Optionally specifies a menu type to describe the purpose of your menu.
· Standard

· Interface Constants

· Global Menu

· Home Page

· Interface

· App Pref Menu Container

· Permission Set

· HTML SideBar

· HTML SideList

· HTML Side Navigator Menu

· HTML Sub Tab

· HTML Tab

Sequence Enter a sequence number to specify where a menu entry appears relative to other menu entries in a menu. The default value for this field is the next whole sequence number.

Navigator Prompt Enter a user-friendly, intuitive prompt your menu displays for this menu entry. You see this menu prompt in the hierarchy list of the Navigator window.

Submenu Call another menu and allow your user to select menu entries from that menu.

Function Call a function you wish to include in the menu. A form function (form) appears in the Navigate window and allows access to that form. Other non-form functions (sub functions) allow access to a particular subset of form functionality from this menu.

Description Descriptions appear in a field at the top of the Navigate window when a menu entry is highlighted.

Grant the Grant check box should usually be checked. Checking this box indicates that this function is automatically enabled for the user. If this is not checked then the function must be enabled using additional data security rules.

7.3 Defining Application Responsibilities

Use this window to define a responsibility. Each application user is assigned at least one responsibility. A responsibility determines if the user accesses Oracle Applications or Oracle Self-Service Web Applications, which applications functions a user can use, which reports and concurrent programs the user can run, and which data those reports and concurrent programs can access.

Figure 7-3

An application name and a responsibility name uniquely identify a responsibility.

Responsibility Name if you have multiple responsibilities, a pop-up window includes this name after you sign on.

Application this application name does not prevent the user of this responsibility from accessing other applications' forms and functions if you define the menu to access other applications.

Responsibility Key this is a unique name for a responsibility that is used by loader
programs. Loaders are concurrent programs used to "load" such information as messages,
user profiles and user profile values into your Oracle Applications tables. To help ensure
that your responsibility key is unique throughout your system, begin each Responsibility
Key name with the application short name associated with this responsibility.

Effective Dates

From/To Enter the start/end dates on which the responsibility becomes active/inactive. The default value for the start date is the current date, and if you do not enter an end date, the responsibility is valid indefinitely.

You cannot delete a responsibility because its information helps to provide an audit trail. You can deactivate a responsibility at any time by setting the end date to the current date. If you wish to reactivate the responsibility, change the end date to a date after the current date, or clear the end date.

Available From A responsibility may be associated with only one applications system.

Data Group

Name/Application: The data group defines the pairing of application and ORACLE username.

Menu: The menu whose name you enter must already be defined with Oracle Applications.

Web Host Name: If your Web Server resides on a different machine from your database, you must designate the host name (URL) here. Otherwise, the Web Host Name defaults to the current database host server.

Web Agent Name: Enter the PL/SQL Agent Name for the database used by this responsibility. If you do not specify an Agent Name, the responsibility defaults to the agent name current at log-on.

Request Group

Name/Application: If you do not assign a request security group to this responsibility, a user with this responsibility cannot run requests, request sets, or concurrent programs from the Submit Requests window, except for request sets owned by the user. The user can access requests from a Submit Requests window you customize with a request group code through menu parameters.

Menu Exclusions Block: Define function and menu exclusion rules to restrict the application functionality accessible to a responsibility.

Type: Select either Function or Menu as the type of exclusion rule to apply against this responsibility.

Name: Select the name of the function or menu you wish to exclude from this responsibility. The function or menu you specify must already be defined in Oracle Applications.

8 Customized Reports in Oracle Application

8.1 Creating Value Sets

The value sets you define using these windows appear in lists of values (LOV).If you are
defining reports that your users run from the Submit Requests window, use this window
to define value sets for your report arguments. The value sets you define using this
window also appear when you define report parameters using the Concurrent Programs
window.

Figure 8-1

8.2 Report Integration

This section describes how to integrate a report developed in Oracle Report Builder (with an .rdf extension) with Oracle Applications.

1. Move the report (.rdf) file to the PRODUCT_TOP in the concurrent server
machine. For example, if it is a report for accounts payables, the the
PRODUCT_TOP would be /oracle//apps/apps_st/appl/ap/12.0.0/reports/US/. If you

put the rdf through samba you need to change its owner to oracle and mode to full

permissions by issuing following commands.

$Chown oracle:oinstall <file_name>

$chmod 777 <file_name>

2. Navigate to the             “concurrent --> program --> define” path from the System
    Administrator or Application Developer responsibility and enter information as
    shown in the example below:

Figure 8-2

The executable file name has to be the same as that on the sever without the .rdf extension

3. Click on the save button and close this form.

4. Navigate to the path “concurrent --> program --> executable” and enter information as shown in the example below

Figure 8-3

Enter the parameters with exactly the same name as done in Oracle Report Builder. The value set can be selected as either one of the system value sets or a customized one.

5. Save your work.

6. On saving successfully the report is registered with Oracle Applications. Next assign this report to a request set in Security - >Responsibility- > Request

9 Concurrent Request, Program & Processes

In Oracle Applications, concurrent processing simultaneously executes programs running in the background with online operations. As System Administrator, you can manage when programs are run and how many operating system processes Oracle Applications devotes to running programs in the background.

When a user runs a report, a request to run the report is generated. The command to run the report is a concurrent request. The program that generates the report is a concurrent program. Concurrent programs are started by a concurrent manager.

Concurrent manager starts concurrent program Every time your users request a concurrent program to be run, their request is inserted into a database table, and is uniquely identified by a request ID. Concurrent managers read requests from this table.

Running concurrent program A concurrent program actually starts running based on:
· When it is scheduled to start

· Whether it is placed on hold

· Whether it is incompatible (cannot run) with other programs

· Its request priority

Concurrent Request Priorities The priority of a concurrent request is determined by application username, and is set by the System Administrator using the Concurrent: Priority user profile option. The first available concurrent manager compares the request’s priority to other requests it is eligible to process, and runs the request with the highest priority. When choosing between requests of equal priority, the concurrent manager runs the oldest request first.

Parent requests and Child requests Often, several programs may be grouped together, as in a request set. Submitting the request set as a whole generates a request ID, and as each member of the set is submitted it receives its own request ID. The set’s request ID identifies the Parent request, and each of the individual programs’ requests ID identifies a Child request.

Life cycle of a concurrent request A concurrent request proceeds through three, possibly four, life cycle stages or phases:

Pending Request is waiting to be run

Running Request is running

Completed Request has finished

Inactive Request cannot be run

9.1 Defining Concurrent Manager

You can define as many concurrent managers as you want. When you define a manager,
you:

· Assign a predefined library of immediate concurrent programs to your manager.

Immediate concurrent programs are subroutines associated with concurrent managers. All other concurrent programs are spawned as independent processes at run time.

· Assign work shifts to your manager, which determines what days and times the manager works.

· For each work shift, you define the maximum number of operating system processes the manager can run concurrently to read requests (start programs) during the work shift.

· Specialize your manager to read only certain kinds of requests.

9.2 Concurrent Manager Window

Use this window to define your concurrent managers. You can determine when a manager runs and how many programs a manager can start simultaneously when you assign work shifts to the manager. Determine which programs a manager can start by defining specialization rules.

Figure 9-1

Application The application name does not prevent a manager from starting programs associated with other applications. To restrict a manager to only running programs associated with certain applications, go to the Specialization Rules window.

Type Once you define a concurrent manager, you cannot update this field. There are several types of managers:

Concurrent Manager Concurrent Managers start concurrent programs running.

Internal Monitor Internal Monitors monitor the internal concurrent manager in a parallel concurrent processing environment. If the Internal Concurrent Manager exits abnormally (for example, because its node or its database instance goes down), an Internal Monitor restarts it on another node.

Transaction Manager Transaction managers handle synchronous requests from client machines.

Cache Size (Concurrent Manager only) Enter the number of requests your manager remembers each time it reads which requests to run. For example, if a manager's workshift has 1 target process and a cache value of 3, it will read three requests,, and will wait until these three requests have been run before reading new requests.

In reading requests, the manager will only put requests it allowed to run into its cache. For example, if you have defined your manager to run only Order Entry reports then the manager will put only Order Entry requests into its cache.

If you enter 1, the concurrent manager must look at its requests list each time it is ready to process another request.

By setting the cache size at a higher number, the concurrent manager does not have to read its requests list each time it runs a request. However, the manager does not recognize any priority changes you make for a particular request if it has already read that request into its cache. Further, even if you give a higher priority to a new request, that new request must wait until the buffer is empty and the manager returns to look at the requests list. That request may have to wait a long time if you set the buffer size to a high number. You should use cache size to tune your concurrent managers to work most efficiently for you site's needs. If your organization tends to reprioritize jobs going to a certain manager, that manager should have its buffer size set fairly low.

Suggestion: Enter a value of 1 when defining a manager that runs long, time-consuming jobs, and a value of 3 or 4 for managers that run small, quick jobs.

Data Group (Transaction Manager only)

The data group the transaction manager uses to connect to the database. Transaction managers only run programs submitted from responsibilities that use the same data group as the transaction manager.

Resource Consumer Group

The Database Resource Manager in Oracle9i is used to allocate and manage resources among database users and applications.

Node If you are operating in a parallel concurrent processing environment and you want your manager to operate on a specific node, select the name of the node.

The primary node, if available, is the node your concurrent manager operates on. If the primary node or the database instance on it goes down, your concurrent manager migrates to its secondary node. Your concurrent manager migrates back to its primary node when that node becomes available.

Nodes must be previously registered with Oracle Applications, using the Nodes form.

System Queue If you are operating in a parallel concurrent processing environment and you want your manager to use a platform-specific queue management system instead of generic concurrent processing queue management, specify the queue or class name of that system. For example, you may choose a system queue name from a platform-specific queue management system like NQS or IBM Load Leveler.

The primary system queue is the queue you associate with the primary node. The secondary system queue is the queue you associate with the secondary node.

Attention: To ensure that your manager uses your platform-specific queue management system, you should start the concurrent managers in the proper mode (set APPLDCP = OSQ). Refer to platform-specific documentation to determine if your platform supports interfacing with system queues. For Unix platforms, refer to the appropriate Oracle Applications Installation Update. For all other platforms, refer to the appropriate Oracle Applications Installation Guide.

Immediate concurrent programs must be registered in a program library by an applications developer using Oracle Application Object Library.

Program Library Concurrent managers can run only those immediate concurrent programs listed in their program library. They can also run concurrent programs that use any other type of concurrent program executable as long as the specialization rules include them.

Transaction Managers can only run programs listed in their program library.

9.3 Work Shift Window

Assign work shifts to a concurrent manager. A work shift defines the dates and times the manager is enabled. For each work shift you define the number of processes the manager starts running. Work shifts are defined using the Work Shifts form.

Figure 9-2

Processes Enter the number of operating system processes you want your work shift to run simultaneously. Each process can run a concurrent request.

For example, if a work shift is defined with three (3) target processes, the manager can run up to three requests simultaneously.

Parameter Enter the parameter string for a service under Generic Service Management. The value of this field is dependent on the service type definition.

Sleep Seconds Enter the sleep time for your manager during this work shift. Sleep time is the number of seconds your manager waits between checking the list of pending concurrent requests (concurrent requests waiting to be started).

Suggestion: Set the sleep time to be very brief during periods when the number of requests submitted is expected to be high

9.4 Specialization Rules Window

Specialize your manager to run only certain kinds of requests. Without specialization rules, a manager accepts requests to start any concurrent program.

Figure 9-2

Include/Exclude Select from the pop list whether or not to include or exclude those requests that are based on the rule to run.

Type Select the type of specialization rule you want to assign to your manager. Based on the rule's action you selected, allow or disallow, requests can be run by your manager according to

Combined Rule For example, only requests that satisfy the combined rule you select are allowed to be run by your manager. Or conversely, requests that satisfy a certain combined rule are excluded from running.

ORACLE ID. For example, programs with a certain ORACLE ID are excluded from running. Or conversely, a concurrent manager only includes programs with a specific ORACLE ID.

Program. For example, only the program you select is excluded from running. Or
conversely, a concurrent manager only includes the programs you select. You can also
include or exclude all programs belonging to a specific application using the Program
type by entering the application in the Application field and leaving the Name field
empty.

Request Type (of the program) For example, programs of a certain request type are excluded from running. Or conversely, a concurrent manager only includes programs with the request type you select.

User (application username at sign on) For example, all programs submitted by a certain user are excluded from running. Or conversely, a concurrent manager includes only programs submitted by the user you select.

10 Patching

Throughout the course of the Oracle Applications life cycle, patches are applied for a number of reasons, including:

Updating to a higher maintenance level
Applying the latest product enhancements
Adding a new feature or functionality
Fixing an existing issue

Depending on the type of patch, it may update the file system, or the database, or both.

10.1 Patch Types

Patches are defined by type and by format. The patch type describes the purpose of the patch. For example, a patch may add product functionality, or it may fix an existing issue. There are several types of patches that you may be asked to apply to your Oracle Applications system. They are described in the following table

Patch Type	Description
Bug fix	Fixes an existing issue.
New feature	Adds new functionality.
Interoperability	Contains Oracle Applications files and database objects to make the current version of Oracle Applications compatible with a newer version of the database or a technology stack component. For example, to enable an Oracle 11g database to work with Oracle Applications Release 12.
Diagnostic	Released specifically to determine the source of an issue. A diagnostic patch does not contain fixes.
Translation	Contains Oracle Applications files that have been translated from English to another language. A translation patch may also run tasks to load or update data in the database.
Performance	Fixes a problem with, or improves the performance of, an upgrade from a previous major release, such as 11.5.9 to 12.
Documentation	Updates Oracle Applications Online Help. When applying a product minipack or a stand-alone patch that adds a new feature, review the Features Summary Matrices on OracleMetaLink for the associated documentation patch.

10.2 Patch Formats

Patch format describes the way the patch is packaged and applied. For example, a stand-alone patch focuses on a single, specific issue, while a minipack is a merged patch that consolidates all patches for a specific product for a specific period of time.

Patches are released in the following formats. If a patch format is described as cumulative, that patch contains a consolidation of updates from the inception of Release 12, up to, and including, the latest release level

Patches	Description
Stand-alone	A patch that fixes a specific issue or provides new functionality.
High-priority	A patch identified by Oracle as having an impact that is broad enough to merit application by all customers who have installed the affected product.
Rollup	An aggregation of patches that may be at a specific product or family release level.
Minipack	A consolidation of all patches for a product that upgrades the product to a new codelevel. The naming convention is R12.<product>.<codeline> such as R12.AD.A. Minipacks with a higher <codeline> supersede previous versions. They are cumulative.
Family pack	A consolidation of a set of minipacks and other patches for a product family. Family packs with a higher number supersede previous versions. They are cumulative.
Consolidated Update (CU)	An update containing generally recommended patches and additional targeted patches combined into a single patch. Applying a consolidated update brings a release to the latest recommended patch level. For example, R12 CU2.
Family consolidated upgrade patch	All upgrade-related, high-priority patches consolidated from all the products within a product family. Family consolidated upgrade patches are released as needed. The Oracle Applications Release Notes lists the most recent family consolidated upgrade patches.
Maintenance pack	A consolidation of all minipacks for all products. A maintenance pack updates a system to a new point release of Oracle Applications, such as from release 11.5.10 to 12. Maintenance packs with a higher number supersede previous versions. They are cumulative.

10.3 Patch File Structure

Patches generally consist of a top-level directory, several files in the top-level directory, and one or more subdirectories. The top-level directory is named <patchnum>, where <patchnum> is the number of the patch. The most important files in the top-level directory are: README.txt, README.html and the u<patchnum>.drv driver file. For most patches, applying the patch driver file is the only action required.

The README.txt or README.html file for each patch describes what the patch does, and how to generate customized installation instructions for applying the patch.

Patch Driver File The unified driver contains the commands necessary to change files and database objects, and to generate new objects.

Unified Driver The unified driver now contains copy, database, and generate portions in a single driver file. It is named u<patchnum>.drv. Run the unified driver on all APPL_TOPs and AutoPatch runs only the actions that are required for the current APPL_TOP.

Copy Portion of a Unified Driver

When the copy portion of a unified driver runs, AutoPatch performs the following actions:

Extracts the appropriate files from the C library of each product.
Compares the extracted object modules with their corresponding files in the patch directory. It also makes this type of comparison with files such as forms, reports, and SQL scripts.
Backs up any product file with a more recent version in the patch directory to a subdirectory in the patch directory. For example, if <patch_dir> is the patch directory, <system_name> is the Applications System name, <appl_top_name> is the APPL_TOP name, and <prod> is the name of the product being patched, it

backs up: <PROD>_TOP/<subdir(s)>/<old_file_name>

<patch_dir>/backup/<system_name>/<appl_top_name>/ \<prod>/<subdir(s)>/<old_file_name>

Replaces the outdated files of each product with newer files from the patch directory.
Loads the new object modules into the C libraries.
Relinks the Oracle Applications products with the operating system, Oracle server, and other Oracle products libraries.
Applies changed Java class files and regenerates JAR files as needed.
Copies any specified HTML or media files to their respective destinations.
Compiles out-of-date Java Server Page (JSP) files (if any JSP files are included in the patch).

Database Portion of a Unified Driver

When the database portion of a driver runs, AutoPatch performs these actions:

Gets a list of current invalid objects in the APPS schema.
Determines whether the action was performed in a previous patch.
Runs SQL scripts and EXEC commands, which change Oracle Applications database objects. By default, AutoPatch runs scripts and commands in parallel.
Compiles invalid objects in the database.
Assembles a list of current invalid objects in the APPS schema.

Generate Portion of a Unified Driver

Apply the generate portion of a unified driver on all APPL_TOP directories containing one or more files being generated by the patch. If in doubt, apply it to all APPL_TOP directories on all nodes. When the generate portion of a driver runs, AutoPatch performs these actions:

Generates Oracle Forms PL/SQL library files.
Generates Oracle Forms menu files.
Generates Oracle Forms executable files.
Generates Oracle Reports PL/SQL library files.
Generates Oracle Reports files.
Generates message files.
Generates Oracle Workflow resource files.

10.4 Patching Utilities

Patches are applied and tracked as needed by using one of the utilities designed specifically for that purpose. The following utilities are run from the command line.

AutoPatch AutoPatch is the utility used to apply all patches to the Oracle Applications file system or database.

Use AutoPatch to apply patches to the Oracle Applications file system or database. It gathers necessary information about your system through a series of prompts. When you have completed the prompts, AutoPatch performs all the tasks required to apply the patch, including the following:

Reads patch metadata to determine patch dependencies and requirements.
Uploads patch information from a prior patch session to the database (if needed).
Reads and validates the patch driver file and reads the product driver files.
Compares version numbers of object modules from the product libraries and version numbers of the existing files against the patch files.
Backs up all existing files that will be changed by the patch.
Copies files.
Archives files in libraries.
Relinks executables.
Generates forms, reports, message, graphics, and Java archive (JAR) files.
Compiles JSP files and invalid database objects.
Updates database objects.
Runs AutoConfig to update configuration files, if any template files are introduced or updated by the patch.
Saves patch information to the database.

AutoPatch takes no action if a patch contains no new updates to files or database objects in your system. If AutoPatch detects that there is a previously failed AutoPatch session, it will attempt to recover that session.

Preparing your System for Patching Before you begin a patching session, there are some important tasks you need to complete.

Enable Maintenance Mode Before you initiate an AutoPatch session, you must shut down the Workflow Business Events System and set up function security so that no Oracle Applications functions are available to users. This ensures optimal performance and reduces downtime when applying a patch. Maintenance mode provides a clear separation between normal runtime operation of Oracle Applications and system downtime for maintenance.

During a maintenance mode downtime, user login is restricted. Users are redirected to a system downtime URL, which informs them that the maintenance session is in progress. The Oracle Applications Manager (OAM) Maintenance Mode page allows you to schedule system downtime and send alert messages to notify users of the downtime schedule.

To enable or disable maintenance mode, use the Change Maintenance Mode menu in AD Administration.

Shut Down Services If you are applying a patch that updates or relinks files, shut down the corresponding concurrent manager, Web server listeners, or forms server listeners. For example, if the files are on the node that contains the concurrent processing server, shut down the concurrent managers.

Log Files In addition to the main log file (adpatch.log), AutoPatch also creates several other log files for specific purposes, for example, to record all the actions associated with parallel workers. The log files are written to $APPL_TOP/admin/<SID>/log (UNIX), where <SID> is the value of your ORACLE_SID or TWO_TASK variable, or in %APPL_TOP%\admin \<SID>\log (Windows), where <SID> is the value of ORACLE_SID or LOCAL. Review these files when the AutoPatch session is complete.

The log directory contains adpatch.log and adpatch.lgi, and may contain one or more additional files as described in the following table. If AutoPatch does not perform an action, it does not generate the log file associated with that type of action.

Log File	Description
adpatch.lgi	for AutoPatch informational messages (default name)
adrelink.log	for relinking
adlibin.log	for moving C object files into the C library of a product
adlibout.log	for moving C object files out of the C library of a product
adworkxxx.log	for database operations run in parallel
<language>_<filename>_ldt.log	for seed data loader files

Prompts In addition to the standard prompts common to most AD utilities, AutoPatch also asks for information specific to the patching process. You must respond to all the prompts for each driver you run.

Main Log File Name The main AutoPatch log file is named adpatch.log by default. We recommend you change the name to indicate the associated driver file, using a .log extension. For example, for the u1234567.drv driver, the log file should be u1234567.log.

SYSTEM and AOL User Passwords AutoPatch prompts for the SYSTEM and AOL user passwords.

Patch Directory AutoPatch asks you to specify the directory where the patch files have been unzipped. The default is the directory from which you started AutoPatch. If necessary, specify the full path name to the directory where you unzipped the patch files. The operating system user running AutoPatch must have write permissions to that directory.

Patch Driver File AutoPatch prompts for the name of the patch driver file. By default, it does not check the integrity of the patch — whether the version of each file referenced in a driver file copy action matches the version present in the patch — as Oracle Applications patches are tested to ensure they contain the correct files before they are released.

Number of Parallel Workers By default, AutoPatch runs database updates and file generation commands in parallel and prompts you for the number of workers. Tasks are assigned to workers, the workers run the tasks to completion, and AutoPatch assigns new tasks.

The default value for the number of workers is two times the number of CPUs on the node from which you run AutoPatch. Oracle recommends specifying 2 to 4 times the number of workers as CPUs.

After you specify the number of workers, AutoPatch displays messages like the following as it begins to update the Oracle Applications products:

Performing version checking for driver files...

Copying driver files into installation area...

Determining valid on-site files...

Screening out files not valid for this installation...

Extracting object modules from product libraries...

Performing version checking...

Determining what executables to link...

Determining what Oracle Forms files to generate...

Determining what Oracle Reports libraries to generate...

Determining what Oracle Reports files to generate...

Customized Files AutoPatch reviews the AD_FILES table to determine if any customized files (Registered Flagged Files) will be replaced by the patch. If so, it displays a message listing the customized files it will replace.

NLS If the patch you are applying has an NLS-related version, and if you are an NLS customer, AutoPatch prompts you about the NLS-related version of the patch before allowing you to continue.

Successful Completion Message AutoPatch displays messages like the following when processing is complete. If you do not see a completion message, investigate the reason why. A job timing report has been generated for the current session.

You should check the file

/slot03/appmgr/prodappl/admin/PROD/out/adt323790.lst for details.

Purging timing information for prior sessions.

sqlplus -s APPS/***** @/slot03/appmgr/prodappl/ad/12.0.0/sql/adtpurge.sql 10 1000

Done purging timing information for prior sessions.

AutoPatch is complete.

AutoPatch may have written informational messages to the file

/slot03/appmgr/prodappl/admin/PROD/log/adpatch.lgi

Errors and warnings are listed in the log file

/slot03/appmgr/prodappl/admin/PROD/log/adpatch.log and in other log files in the same directory.

Backup Directory When AutoPatch runs, a backup directory is created in the directory where you unzip the patch. The old version of each file updated by the patch is copied into the backup directory. When applying large patches (like minipacks, family packs, and maintenance packs), ensure there is enough disk space on the system where you unzip the patch, or the patching process might fail. Oracle recommends having at least twice the amount of disk space as the unzipped patch file.

Periodically, you can delete the files in the backup directory to free up space.

10.5 The AutoPatch Interface

Run AutoPatch from the command line. It relies on prompts for information, not input screens.

Running AutoPatch

Perform the following steps to start AutoPatch

Step 1 Set the environment You must set the environment to apply the configuration parameters that define your system. This task is common to many AD utilities.

Step 2 Unzip the patch Create a patch top directory, if it does not already exist. Download the patch into the patch top directory and unzip it.

Step 3 Review the information in the README file In the directory where you unzipped the patch, you will find a README.txt file and a README.html file. Review either README file for information about the patch and for instructions on running the admsi.pl script.

Step 4 Run the admsi.pl script Run the admsi.pl script to generate customized installation instructions for the patch. Follow the steps in the customized installation instructions to complete the patching process.

10.6 Applying a Patch Interactively

After you have determined that you need to apply a patch, download the patch and use AutoPatch to apply it to your system. Apply the unified driver to all APPL_TOPs, and AutoPatch sorts out which actions are required for the current APPL_TOP.

Patches may require prerequisite patches and manual steps. Run the admsi.pl script to generate customized installation instructions for the patch. These instructions contain all the required manual steps.

Steps This procedure describes the typical steps for applying a patch. Subsequent procedures describe command line options that change the default behavior of AutoPatch.

1. Log in as applmgr (Applications file system owner) and set the environment. To set the environment:

The environment file is typically APPS<CONTEXT_NAME>.env, and is located under the APPL_TOP. From a Bourne, Korn, or Bash shell, enter the following:

$ . APPS<CONTEXT_NAME>.env

2. Create a patch top directory, if it does not already exist. Download the patch into a staging directory and unzip the patch into the patch top directory. Do not use the patch subdirectory under the <PROD>_TOP directories as your patch top directory.

3. Change directory to the patch top directory where you unzipped the patch.

4. Review the README file in the patch top directory. Review the README file (README.txt or README.html), located in the directory where you unzipped the patch. The README contains an abstract of the patch and instructions for running the admsi.pl script.

5. Run the admsi.pl script to generate customized installation instructions for applying the patch. You will need to provide the location of your patch top directory and the applmgr password.

Run admsi.pl with the proper parameter values as follows -

cd $AD_TOP/bin

perl admsi.pl -patch_top=<patch-top-directory> -appspass=<apps-password>

For example,

perl admsi.pl -patch_top=/u01/apps/patches/3636980 -appspass=apps

The following general steps are contained in the customized installation instructions generated by the admsi.pl script. Additional steps are also detailed in the customized installation instructions depending on the patch, the state of your system, and the products you have installed.

Use the following steps, in addition to the steps detailed in the customized installation instructions, to apply the patch.

6. Shut down services.

Run the adstpall.sh script to shut down the services appropriate to your system. You will need to provide the applmgr user name and password.

$ adstpall.sh

7. Enable Maintenance Mode.

Use the Change Maintenance Mode menu of AD Administration to enable maintenance mode. Select option 1 to enable maintenance mode.

8. Start AutoPatch.

Use the adpatch command to start AutoPatch from the patch top directory (the directory where you downloaded the patch files).

9. Respond to the AutoPatch prompts. You are prompted for the following information required to apply the patch:

APPL_TOP name where you want to apply the patch.
Log file name: Select a name for the log file, for example, u<patchnum>.log.
Email where you want to receive notifications.
Batch size, the default is 1000.
Database name.
Patch top directory where you unzipped the patch.
Driver file name: Provide the name of the driver file located in the patch top directory, for example, u<patchnum>.drv.

10. Apply the driver.

When AutoPatch prompts for the driver name, specify the name of the driver.

11. Review customizations.

Customized files are registered in the Registered Flagged Files page of OAM. If AutoPatch displays a message indicating that previously registered, customized files will be replaced by the patch, review those files in the Registered Flagged Files page to determine if the customizations need to be reregistered or removed.

12. After AutoPatch exits, review the log files.

Review the AutoPatch log file after the application of each driver file for warnings or errors. The log file is located in <APPL_TOP>/admin/<SID>/log. This is the file you named u<patchnum>.log in step 9. In addition, some patch tasks may create separate log files in the same directory. If the patching process used multiple workers, each worker creates its own log file.

13. Preallocate space for packages, functions, and sequences (optional).

If AutoPatch has modified Oracle Applications database objects, you may want to run ADXGNPIN.sql and ADXGNPNS.sql to allocate space ("pin") for new packages and sequences in the Oracle System Global Area. These scripts are located in AD_TOP/sql.

14. Disable Maintenance Mode.

Use the Change Maintenance Mode menu of AD Administration to disable maintenance mode. Select option 2 to disable maintenance mode.

15. Restart server processes.

After verifying that the patch was applied successfully, start all server processes and allow users to access the system.

$ adstrtal.sh

16. Delete or archive AutoPatch backup files (optional).

After you have tested the patched system, you can delete the backup copies of files from the patch top directories to recover disk space, as necessary. Oracle recommends archiving these files if you have space available.

10.7 Applying Patches to a Multi-node System

In a multi-node system, servers are installed on more than one node. The core technology directories (admin, ad, au, and fnd) and all product directories are installed under the APPL_TOP on all nodes, except for any node that contains only a RDBMS.

You can maintain the APPL_TOPs separately, or you can configure your system to share an APPL_TOP. In a shared application tier file system, the APPL_TOP, COMMON_TOP, 10.1.2 Oracle home, and 10.1.3 Oracle home file systems are installed on a shared disk resource mounted to each node in the system. Any changes made to a shared file system are immediately available on all nodes.

Steps Apply the unified driver as follows:

Complete Steps 1 – 9 in the previous section (9.6).
Apply the unified driver on the node where the administration server is located.
Apply the unified driver on the node where the concurrent processing server is located.
Start the concurrent managers.
Apply the unified driver on the remaining nodes in the application tier.
Disable Maintenance Mode. Use the Change Maintenance Mode menu of AD Administration to disable
Start other services and restart Web server, if necessary

Please Subscribe my blog Qamar Zahoor, YouTube Channel YouTube, Join the Facebook group

Facebook Group and do follow on Twitter Twitter to get knowledge of Oracle EBS, Database, Ecommerce, Amazon, Ebay and Digital Marketing. Keep learning.

Search This Blog

Translate

Thursday, 19 June 2014

ORACLE EBS TECHNICAL TRAINING

2 Oracle Application Architecture

9 Concurrent Request, Program & Processes

No comments:

Post a Comment