Concurrent Manager as name suggest is Manager which manages your concurrent requests in Oracle Apps 11i. You can assign single request or batch job & let concurrent manager manage these request. Without going to technical definition & explanation about them I will go straight to the point which you might be interested in looking as Sysadmin or Oracle Apps DBA i.e. from startup/shutdown to configuration then finally to tuning. So tie up your belt & get ready for ride to CM.
How to Start/Stop Concurrent Manager ? In Oracle Applications 11i as you might already be aware that all startup shutdown scripts in 11i(11.5.10) are in $OAD_TOP/admin/script/$CONTEXT_NAME where $OAD_TOP is also called as $COMMON_TOP and $CONTEXT_NAME is your SID_hostname , lets say your SID or Instance Name is VISION and its on machine with name machine1 so your CONTEXT_NAME will be VISION_machine1. So script to start/stop concurrent manager is adcmctl.sh where ad (In my view) is application dba , cm is concurrent manager & ctl means control. Well if you really want to explore more I'll suggest you open this file & go through it . If you open this script you will see syntax to run it in start or stop mode so I am not going to spoon feed you by giving syntax. When you run adcmctl.sh it records execution of this command in text file with name adcmctl.txt at directory $COMMON_TOP/admin/log/$CONTEXT_NAME. adcmctl.sh called another script startmgr which in turn calls batchmgr in $FND_TOP/bin and this is actual file which fire up Internal Concurrent Manager Process (Open these two files as they are text file and read content in these files.
Lets check important parameter in this file
DISPLAY Set it to some valid XServer , if this is not set properly your reports display will fail (specially one with PDF or Bar code dislay)
DIAG_PARAM Diagnosis parameter it will take value Y or N with default N, If you encounter some error while starting Concurrent Manager you change this to Y and then extra logging will be enabled then check Concurrent Manager log file.
CONCSUB stands for CONC(Concurrent) SUB(Submit) , used to submit concurrent request like shut down concurrent manager.
Thursday, June 5, 2008
File System In 11i
Oracle Applications product files, technology stack files, environment files, and
common files are held in the file system on the application tier. In Release 11i, only the downloaded JAR files are stored on the desktop client and the database server holds only database files. Environment settings indicate the location of files in the file system.
■ Top-Level Directories
■ Product Directories
■ Environment Settings .
Top-Level Directories :
The Oracle Applications 11i system uses components from many Oracle products.
It stores these product files within several top-level directories as follows :
■ TheDATA or DATA_TOP directory is located on the database server
and it contains the system tablespaces, redo log files, data tablespaces, index
tablespaces, and database files.
■ TheDB directory is located on the database server and it contains the
Oracle Home for the Oracle9i RDBMS.
■ TheAPPL or APPL_TOP directory contains the product directories
and files for Oracle Applications.
■ TheORA directory contains the Oracle Homes for the Applications
technology stack components.
■ TheCOMN or COMN_TOP (or COMMON_TOP) directory contains
directories and files used across products.
Note: is the name of your system determined through
Rapid Install at the time of installation. For example, PROD.
TheDATA Directory
TheDATA file system contains the .dbf files of the Oracle9i database.
Rapid Install installs all the system, data, and index files in up to four different
mount points on the database server. You can specify the directory names of the
mount points on the database server during installation.
DB and ORA Directories
Oracle Applications supports running a database of one version, while linking
Oracle Applications programs using the tools from a second or third version of the
database server. This is known as multiple Oracle Homes. This model allows Oracle to
support features in later database server versions and still maintain compatibility
with an earlier release. Release 11i has three Oracle Homes.
The 9.2.0 ORACLE_HOME (or database home) is located in theDB
directory. It contains the files for running and maintaining the Oracle9i database on
the database server.
To take advantage of the latest features of the applications technology stack
components, there are two ORACLE_HOME directories under theORA
directory. The 8.0.6 directory contains the ORACLE_HOME for the Developer 6i
products (Forms, Reports, and Graphics). The iAS directory contains the
ORACLE_HOME for the Oracle HTTP Server.
TheCOMN Directory
TheCOMN or COMMON_TOP directory contains files that are used by
many different Oracle Applications products, and that may be used with
third-party products.
The admin directory in the COMMON_TOP directory contains the log and output
directories for concurrent managers. When the concurrent managers run Oracle
Applications reports, they write the output files, as well as diagnostic log files and temporary files, to the log and out directories in this admin directory.
You can change the location the concurrent managers write these files to, so that, for example, the log and output files are written to directories in each_TOP
directory. The default, however, is to write the files to the log and out directories in the COMMON_TOP/admin/log and COMMON_TOP/admin/out directories.
The admin/install directory contains scripts and log files used by Rapid Install
during installation. The admin/scripts directory contains scripts to start and stop
services such as listeners and concurrent managers.
The html directory The OA_HTML environment setting points to the html directory.
The Oracle Applications html sign-on screen and Oracle Self-Service Applications
html files are installed here. The html directory also contains other files used by the
html-based products, such as Java Server Page (JSP) files, java scripts, xml files, and
style sheets. Rapid Install and the AD utilities copy the html-based product files
from each_TOP directory to subdirectories in the html directory.
The java directory The JAVA_TOP environment setting points to the java directory.
Rapid Install installs all Oracle Applications JAR files in the Oracle namespace of
this JAVA_TOP directory. The java directory also holds third-party java files used by
Oracle Applications as well as other zip files.
Most Java code used by Oracle Applications is version-controlled in the apps.zip
file contained in the AU_TOP directory. Patches, for example, update individual
classes in apps.zip under the AU_TOP directory, and from this apps.zip file JAR
files are generated both in the JAVA_TOP and the_TOP directories. The same
apps.zip file exists in both the AU_TOP and JAVA_TOP directories.
The portal directory The portal directory contains the Rapid Install Portal files. The
Rapid Install Portal is a web page that includes the post-install tasks that may be
necessary for your installation, Server Administration scripts, installation
documentation, and online help. Using a browser, you can view the Rapid Install
Portal after you run Rapid Install.
The temp directory The temp directory is used for caching by some processes such as
Oracle Reports.
The util directory The util directory contains the third-party utilities licensed to ship with Oracle Applications. These include, for example, JRE, JDK, and the unzip
utility.
TheAPPL Directory
Oracle Applications files are stored in theAPPL directory, known as the
APPL_TOP directory.
The APPL_TOP directory contains:
■ The main applications environment file, called the.env file
■ The consolidated environment file, APPS.env (where SID is the name of
the database)
■ The core technology directories
■ The product directories for all products
Rapid Install creates a directory tree for every Oracle Applications product in this
APPL_TOP directory, licensed or not.
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 in a newAPPL directory tree.
Each Applications top directory is associated with a single Oracle Applications
database on the Oracle9i server. If you install both a Vision Demo system and a test
system, you must use Rapid Install to lay down two file systems: one for each
system.
Product Directories
Each product has its own subdirectory under APPL_TOP named for its standard
abbreviation, such as gl for Oracle General Ledger. Within each product directory,
is a subdirectory named for the base release version number, such as 11.5.0. Within
this directory are the various subdirectories for the product files.
The_TOP
The// path is known as the product top
(_TOP) and it is stored in the _TOP environment setting. For
example, if APPL_TOP=/d01/oracle/prodapps, then the value contained in the
AD_TOP environment setting is /d01/oracle/prodapps/ad/11.5.0 and the
AD_TOP environment setting points to the/ad/11.5.0 directory.
Similarly, the value of AU_TOP is /d01/oracle/prodapps/au/11.5.0, and the
AU_TOP environment setting points to the/au/11.5.0 directory. This
is the same for all directories except for the admin directory.
Product Files .
Each_TOP directory, such as APPL_TOP/gl/11.5.0, contains subdirectories
for product files. Product files include forms files, reports files, and other 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
11.5.0 directory.
common files are held in the file system on the application tier. In Release 11i, only the downloaded JAR files are stored on the desktop client and the database server holds only database files. Environment settings indicate the location of files in the file system.
■ Top-Level Directories
■ Product Directories
■ Environment Settings .
Top-Level Directories :
The Oracle Applications 11i system uses components from many Oracle products.
It stores these product files within several top-level directories as follows :
■ The
and it contains the system tablespaces, redo log files, data tablespaces, index
tablespaces, and database files.
■ The
Oracle Home for the Oracle9i RDBMS.
■ The
and files for Oracle Applications.
■ The
technology stack components.
■ The
directories and files used across products.
Note:
Rapid Install at the time of installation. For example, PROD.
The
The
Rapid Install installs all the system, data, and index files in up to four different
mount points on the database server. You can specify the directory names of the
mount points on the database server during installation.
Oracle Applications supports running a database of one version, while linking
Oracle Applications programs using the tools from a second or third version of the
database server. This is known as multiple Oracle Homes. This model allows Oracle to
support features in later database server versions and still maintain compatibility
with an earlier release. Release 11i has three Oracle Homes.
The 9.2.0 ORACLE_HOME (or database home) is located in the
directory. It contains the files for running and maintaining the Oracle9i database on
the database server.
To take advantage of the latest features of the applications technology stack
components, there are two ORACLE_HOME directories under the
directory. The 8.0.6 directory contains the ORACLE_HOME for the Developer 6i
products (Forms, Reports, and Graphics). The iAS directory contains the
ORACLE_HOME for the Oracle HTTP Server.
The
The
many different Oracle Applications products, and that may be used with
third-party products.
The admin directory in the COMMON_TOP directory contains the log and output
directories for concurrent managers. When the concurrent managers run Oracle
Applications reports, they write the output files, as well as diagnostic log files and temporary files, to the log and out directories in this admin directory.
You can change the location the concurrent managers write these files to, so that, for example, the log and output files are written to directories in each
directory. The default, however, is to write the files to the log and out directories in the COMMON_TOP/admin/log and COMMON_TOP/admin/out directories.
The admin/install directory contains scripts and log files used by Rapid Install
during installation. The admin/scripts directory contains scripts to start and stop
services such as listeners and concurrent managers.
The html directory The OA_HTML environment setting points to the html directory.
The Oracle Applications html sign-on screen and Oracle Self-Service Applications
html files are installed here. The html directory also contains other files used by the
html-based products, such as Java Server Page (JSP) files, java scripts, xml files, and
style sheets. Rapid Install and the AD utilities copy the html-based product files
from each
The java directory The JAVA_TOP environment setting points to the java directory.
Rapid Install installs all Oracle Applications JAR files in the Oracle namespace of
this JAVA_TOP directory. The java directory also holds third-party java files used by
Oracle Applications as well as other zip files.
Most Java code used by Oracle Applications is version-controlled in the apps.zip
file contained in the AU_TOP directory. Patches, for example, update individual
classes in apps.zip under the AU_TOP directory, and from this apps.zip file JAR
files are generated both in the JAVA_TOP and the
apps.zip file exists in both the AU_TOP and JAVA_TOP directories.
The portal directory The portal directory contains the Rapid Install Portal files. The
Rapid Install Portal is a web page that includes the post-install tasks that may be
necessary for your installation, Server Administration scripts, installation
documentation, and online help. Using a browser, you can view the Rapid Install
Portal after you run Rapid Install.
The temp directory The temp directory is used for caching by some processes such as
Oracle Reports.
The util directory The util directory contains the third-party utilities licensed to ship with Oracle Applications. These include, for example, JRE, JDK, and the unzip
utility.
The
Oracle Applications files are stored in the
APPL_TOP directory.
The APPL_TOP directory contains:
■ The main applications environment file, called the
■ The consolidated environment file, APPS
the database)
■ The core technology directories
■ The product directories for all products
Rapid Install creates a directory tree for every Oracle Applications product in this
APPL_TOP directory, licensed or not.
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 in a new
Each Applications top directory is associated with a single Oracle Applications
database on the Oracle9i server. If you install both a Vision Demo system and a test
system, you must use Rapid Install to lay down two file systems: one for each
system.
Product Directories
Each product has its own subdirectory under APPL_TOP named for its standard
abbreviation, such as gl for Oracle General Ledger. Within each product directory,
is a subdirectory named for the base release version number, such as 11.5.0. Within
this directory are the various subdirectories for the product files.
The
The
(
example, if APPL_TOP=/d01/oracle/prodapps, then the value contained in the
AD_TOP environment setting is /d01/oracle/prodapps/ad/11.5.0 and the
AD_TOP environment setting points to the
Similarly, the value of AU_TOP is /d01/oracle/prodapps/au/11.5.0, and the
AU_TOP environment setting points to the
is the same for all directories except for the admin directory.
Product Files .
Each
for product files. Product files include forms files, reports files, and other 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
11.5.0 directory.
How to Become Oracle Apps DBA
“How do I become an Oracle apps DBA” I have been asked this question lots of time. Well my answer is always, “To start with, you should be an Oracle DBA”. Oracle DBA skills are must to learn anything about apps dba. You can also be a good apps developer and still become an Oracle Apps DBA (There are developer there who asked me this question !!), but route is same, learn Oracle DBA.
Once you are good at Oracle DBA you can start learning apps stuff. Good place to start is to read Oracle Applications Concepts manual. You can find Oracle apps documentation at:
11i (11.5.10.2+ virtual) Documentation Library
You should devote time to understand oracle applications architecture. Understanding oracle apps architecture is as important as learning to walk before you run.
Apps Architecture
Rest of the stuff in concepts manual (apart from chapter 1, apps archi) will be OHT (Over-head Transmission) for the beginners ;-). Dont worry and just keep on reading (If you find it interesting). Believe me, I could comprehend just 20% of the manual when I first read it.
As you move on everything will start falling into its place and you will understand the concepts.
Next thing will be to learn installation. Its pretty simple and most of it is java GUI based. Installation manual is the first one in the Apps Document Doc link that I mentioned above. I will also discuss installation in my blog entry here :
Apps Installation
At this point you would have learned two important topics in apps dba. Other things that you will have to learn as apps DBA e.g. AD Utilities like Patching and Cloning etc, Upgrade and more.
Once you are good at Oracle DBA you can start learning apps stuff. Good place to start is to read Oracle Applications Concepts manual. You can find Oracle apps documentation at:
11i (11.5.10.2+ virtual) Documentation Library
You should devote time to understand oracle applications architecture. Understanding oracle apps architecture is as important as learning to walk before you run.
Apps Architecture
Rest of the stuff in concepts manual (apart from chapter 1, apps archi) will be OHT (Over-head Transmission) for the beginners ;-). Dont worry and just keep on reading (If you find it interesting). Believe me, I could comprehend just 20% of the manual when I first read it.
As you move on everything will start falling into its place and you will understand the concepts.
Next thing will be to learn installation. Its pretty simple and most of it is java GUI based. Installation manual is the first one in the Apps Document Doc link that I mentioned above. I will also discuss installation in my blog entry here :
Apps Installation
At this point you would have learned two important topics in apps dba. Other things that you will have to learn as apps DBA e.g. AD Utilities like Patching and Cloning etc, Upgrade and more.
Oracle Apps 11i Architecture
The three disctinct “Tiers” in Oracle apps 11i are:
1. Desktop Tier
2. Application Tier
3. Database Tier
The 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-enabledWeb
browser. The desktop client with Oracle JInitiator downloads the applet on demand
and the applet is cached locally for future use.
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 JInitiator-enabled Web browser.
Oracle JInitiator
The Forms client applet must run within a Java Virtual Machine (JVM) on the
desktop. For Oracle Applications, the JVM is supplied by Oracle JInitiator. Oracle
JInitiator works in conjunction with theWeb browser. It is implemented on the
desktop client as a plug-in (Netscape Communicator) or ActiveX component
(Microsoft Internet Explorer).
When a user enters the desired Oracle Applications signon URL within theWeb
browser, Oracle JInitiator is executed. If Oracle JInitiator has not been installed, the
Web browser prompts the user to download the necessary installation executable to
the desktop client. Once installed, Oracle JInitiator runs the Forms client applet and
starts an Oracle Applications session.
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. Oracle 9i Application Server (9iAS) provides the
technology stack used on the application tier. Six servers comprise the application
tier for Oracle Applications:
■ Web server
■ Forms server
■ Concurrent Processing server
■ Reports server
■ Discoverer server (optional)
■ Admin server
The Application Tier
Load Balancing
The application tier supports load balancing among many of its servers to provide
higher availability, fault tolerance, reliability, and optimal scalability.
Load balancing occurs when there are multiple installations of the following:
■ Web server
■ Forms server
■ Reports server
■ Concurrent Processing server
■ Discoverer server
Web Server
The Oracle HTTP server (powered by Apache) is theWeb server. It processes the
requests received over the network from the desktop clients. It includes additional
components such as:
■ Web Listener
■ Java Servlet Engine
■ Portal
■ Java Server Pages (JSP)
The Web listener component of the Oracle HTTP server accepts incoming HTTP
requests (URLs) from desktop clients (browsers). If possible, theWeb 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.
Self-Service Applications Architecture
The Oracle Self-Service Applications:
■ 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
■ JRAD (Oracle Applications Extensions to JDeveloper) in OA Framework 5.7
■ Operate by direct connection to theWeb server
OA Framework is the development and deployment platform for self-service
applications. It is a 100% Java, middle-tier application framework and services for
the rapid development and deployment of HTML-based applications.
OA Framework-based applications logic is controlled by procedures that execute
through the Java servlet engine. The Apache JServ module provides the Java servlet
engine. For the Self-Service Applications, the Web server communicates with the
database using JDBC.
The Self-Service module uses 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 (JServ) 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 presentation of the HTML page.
5. The resulting HTML page is passed back to the browser, by way of theWeb
server.
Oracle Applications Framework Architecture Following is a more detailed description of
the processing that occurs in Step 4 of the previous section. 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.
Oracle Applications Framework Architecture
1. AOL/J validates user access to the page.
2. The page definition is loaded fromtheMetadata Repository on the database tier
into the applications tier (Metadata UI Definition).
3. The BC4J objects that contain the applications logic and access the database are
instantiated.
4. The Java Controller programmatically manipulates the page definition as
necessary based on dynamic UI rules.
5. UIX (HTML UI Generator) interprets the page definition and creates the
corresponding HTML in accordance with UI standards and sends the page to
the browser.
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 6i 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.
Forms Server 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 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.
Once a connection has been made, many operations can be performed with little or
no 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.
Load Balancing Among Forms Servers
Oracle Applications supports automatic load balancing among multiple Forms
servers. In a load-balancing configuration, all Forms server requests have a single
point of coordination called the Metrics Server, located on one application server.
Metrics clients located on the other application servers periodically send load
information to the Metrics Server so that it can determine which application server
has the lightest load.
1. The client requests a Forms session and the request is sent to the Load Balancer
(Metrics Server) via the Web Listener.
2. The load balancer determines the least-loaded Forms server and returns its
name in the form of an HTML page.
3. The client can now access the least-loaded Forms server directly.
4. From this point on, all communication is between the client desktop and the
designated Forms server.
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.
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.
Business Intelligence System (BIS)
The Business Intelligence System is a decision support solution integrated with
Oracle Applications. Using the BIS products, a manager can query the Oracle
Applications database to monitor recent business performance across multiple
organizations. For example, a manager can set a sales goal and then use BIS to
determine how close actual sales amounts are to the goal. A manager can set
tolerances and have the system inform people when those tolerances are exceeded.
With the BIS Performance Manager Framework, some corrective actions can be
performed automatically. If, for example, sales actual amounts are more than 10%
below goals, BIS can send automatic notifications to regional sales managers.
BIS products do not use the Forms server or Forms client. Instead, BIS products use
the Oracle Discoverer server and Oracle Reports server on the application tier. A
Java applet running on the desktop client communicates with the HTTP server,
which connects to the Oracle Discoverer server or Oracle Reports server. The
Discoverer server provides ad hoc analysis; the Reports server uses summary tables
such as monthly aggregates of data, and returns them to the browser as HTML.
Reports Server
The Reports server is used primarily to produce reports for BIS products. It is
automatically installed on the same node as the Concurrent Processing server and
its reports are contained in the same directory with the concurrent processing
reports. However, reports generated by the Reports server are monitored and
administered separately from concurrent processing reports.
The Reports server dynamically selects language at runtime and users see each
report in the preferred language.
Reports Server Architecture
The request for an HTML-based report is similar to the flow of a Self-Service
Applications request:
1. The user clicks the hyperlink of a function from a browser.
2. The browser makes a URL request to the Web listener.
The Application Tier
1-14 Oracle Applications Concepts
3. The Web listener contacts the Reports server through the reports Web CGI. The
reports Web CGI allows the desktop client to run reports and see the output
through theWeb browser.
4. The Reports server starts the Reports runtime engine.
5. The Reports runtime engine locates the necessary reports and connects to the
database to query the requested information.
6. The queried information is presented to the user in the form of an HTML page.
Clustering and Load Management
When there are a large number of BIS users, it may be beneficial to have multiple
Reports servers.
In this configuration, one of the Reports servers is designated as the master server.
The master Reports server receives the initial request and distributes it to one of the
other Reports servers depending on the load each can handle. The master Reports
server is capable of determining how many runtime engines each of the Reports
servers can support.
Release 11i supports multiple languages on a single Reports server.
Discoverer Server
The Discoverer server complements the Reports server as a tool to perform ad hoc
queries and analysis of the resultant query output. It also allows users to perform
projections as various business and strategic factors are changed.
End User Layer
The End User Layer is the key to providing ease of use. The End User Layer is a
layer of metadata that sits in the Oracle Applications database, but on top of the
Oracle Applications data.
Oracle Discoverer hides the complexity of the database and converts it to an easy to
understand interface for users. It maps the unfamiliar terms in the database, such
as tables and columns, to familiar terms for the user. Therefore, analysts or
managers with no database syntax familiarity can access key information using
terms common to them, such as customer, name, and revenue.
The End User Layer is one of the key components of the Discoverer process. It is in
the database, but is separate from the Oracle Applications data.
There are two important software packages that access the End User Layer. They
are:
■ Administrator Edition - allows the creation of the End User Layer and manages
the administration of responsibilities and roles.
■ User Edition - used to create workbooks (saved queries) and view information
about the business. Oracle provides predefined workbooks which can be used
as bases for ad hoc queries.
In Release 11.0, the User Edition was located on the client. For Release 11i, it is
located in the Discoverer server. This allows for central administration of the
software.
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 database 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, 11i.GL.D) and maintenance packs (for example, 11.5.9).
■ Maintaining Oracle Applications data
Some features such as Multiple Reporting Currencies require regular
maintenance to ensure updates are propagated to the additional tables and
schemas used by this feature. The AD Administration utility (adadmin) allows
you to do this as well as other file system and database maintenance tasks.
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 11i, 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
1. Desktop Tier
2. Application Tier
3. Database Tier
The 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-enabledWeb
browser. The desktop client with Oracle JInitiator downloads the applet on demand
and the applet is cached locally for future use.
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 JInitiator-enabled Web browser.
Oracle JInitiator
The Forms client applet must run within a Java Virtual Machine (JVM) on the
desktop. For Oracle Applications, the JVM is supplied by Oracle JInitiator. Oracle
JInitiator works in conjunction with theWeb browser. It is implemented on the
desktop client as a plug-in (Netscape Communicator) or ActiveX component
(Microsoft Internet Explorer).
When a user enters the desired Oracle Applications signon URL within theWeb
browser, Oracle JInitiator is executed. If Oracle JInitiator has not been installed, the
Web browser prompts the user to download the necessary installation executable to
the desktop client. Once installed, Oracle JInitiator runs the Forms client applet and
starts an Oracle Applications session.
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. Oracle 9i Application Server (9iAS) provides the
technology stack used on the application tier. Six servers comprise the application
tier for Oracle Applications:
■ Web server
■ Forms server
■ Concurrent Processing server
■ Reports server
■ Discoverer server (optional)
■ Admin server
The Application Tier
Load Balancing
The application tier supports load balancing among many of its servers to provide
higher availability, fault tolerance, reliability, and optimal scalability.
Load balancing occurs when there are multiple installations of the following:
■ Web server
■ Forms server
■ Reports server
■ Concurrent Processing server
■ Discoverer server
Web Server
The Oracle HTTP server (powered by Apache) is theWeb server. It processes the
requests received over the network from the desktop clients. It includes additional
components such as:
■ Web Listener
■ Java Servlet Engine
■ Portal
■ Java Server Pages (JSP)
The Web listener component of the Oracle HTTP server accepts incoming HTTP
requests (URLs) from desktop clients (browsers). If possible, theWeb 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.
Self-Service Applications Architecture
The Oracle Self-Service Applications:
■ 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
■ JRAD (Oracle Applications Extensions to JDeveloper) in OA Framework 5.7
■ Operate by direct connection to theWeb server
OA Framework is the development and deployment platform for self-service
applications. It is a 100% Java, middle-tier application framework and services for
the rapid development and deployment of HTML-based applications.
OA Framework-based applications logic is controlled by procedures that execute
through the Java servlet engine. The Apache JServ module provides the Java servlet
engine. For the Self-Service Applications, the Web server communicates with the
database using JDBC.
The Self-Service module uses 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 (JServ) 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 presentation of the HTML page.
5. The resulting HTML page is passed back to the browser, by way of theWeb
server.
Oracle Applications Framework Architecture Following is a more detailed description of
the processing that occurs in Step 4 of the previous section. 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.
Oracle Applications Framework Architecture
1. AOL/J validates user access to the page.
2. The page definition is loaded fromtheMetadata Repository on the database tier
into the applications tier (Metadata UI Definition).
3. The BC4J objects that contain the applications logic and access the database are
instantiated.
4. The Java Controller programmatically manipulates the page definition as
necessary based on dynamic UI rules.
5. UIX (HTML UI Generator) interprets the page definition and creates the
corresponding HTML in accordance with UI standards and sends the page to
the browser.
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 6i 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.
Forms Server 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 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.
Once a connection has been made, many operations can be performed with little or
no 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.
Load Balancing Among Forms Servers
Oracle Applications supports automatic load balancing among multiple Forms
servers. In a load-balancing configuration, all Forms server requests have a single
point of coordination called the Metrics Server, located on one application server.
Metrics clients located on the other application servers periodically send load
information to the Metrics Server so that it can determine which application server
has the lightest load.
1. The client requests a Forms session and the request is sent to the Load Balancer
(Metrics Server) via the Web Listener.
2. The load balancer determines the least-loaded Forms server and returns its
name in the form of an HTML page.
3. The client can now access the least-loaded Forms server directly.
4. From this point on, all communication is between the client desktop and the
designated Forms server.
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.
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.
Business Intelligence System (BIS)
The Business Intelligence System is a decision support solution integrated with
Oracle Applications. Using the BIS products, a manager can query the Oracle
Applications database to monitor recent business performance across multiple
organizations. For example, a manager can set a sales goal and then use BIS to
determine how close actual sales amounts are to the goal. A manager can set
tolerances and have the system inform people when those tolerances are exceeded.
With the BIS Performance Manager Framework, some corrective actions can be
performed automatically. If, for example, sales actual amounts are more than 10%
below goals, BIS can send automatic notifications to regional sales managers.
BIS products do not use the Forms server or Forms client. Instead, BIS products use
the Oracle Discoverer server and Oracle Reports server on the application tier. A
Java applet running on the desktop client communicates with the HTTP server,
which connects to the Oracle Discoverer server or Oracle Reports server. The
Discoverer server provides ad hoc analysis; the Reports server uses summary tables
such as monthly aggregates of data, and returns them to the browser as HTML.
Reports Server
The Reports server is used primarily to produce reports for BIS products. It is
automatically installed on the same node as the Concurrent Processing server and
its reports are contained in the same directory with the concurrent processing
reports. However, reports generated by the Reports server are monitored and
administered separately from concurrent processing reports.
The Reports server dynamically selects language at runtime and users see each
report in the preferred language.
Reports Server Architecture
The request for an HTML-based report is similar to the flow of a Self-Service
Applications request:
1. The user clicks the hyperlink of a function from a browser.
2. The browser makes a URL request to the Web listener.
The Application Tier
1-14 Oracle Applications Concepts
3. The Web listener contacts the Reports server through the reports Web CGI. The
reports Web CGI allows the desktop client to run reports and see the output
through theWeb browser.
4. The Reports server starts the Reports runtime engine.
5. The Reports runtime engine locates the necessary reports and connects to the
database to query the requested information.
6. The queried information is presented to the user in the form of an HTML page.
Clustering and Load Management
When there are a large number of BIS users, it may be beneficial to have multiple
Reports servers.
In this configuration, one of the Reports servers is designated as the master server.
The master Reports server receives the initial request and distributes it to one of the
other Reports servers depending on the load each can handle. The master Reports
server is capable of determining how many runtime engines each of the Reports
servers can support.
Release 11i supports multiple languages on a single Reports server.
Discoverer Server
The Discoverer server complements the Reports server as a tool to perform ad hoc
queries and analysis of the resultant query output. It also allows users to perform
projections as various business and strategic factors are changed.
End User Layer
The End User Layer is the key to providing ease of use. The End User Layer is a
layer of metadata that sits in the Oracle Applications database, but on top of the
Oracle Applications data.
Oracle Discoverer hides the complexity of the database and converts it to an easy to
understand interface for users. It maps the unfamiliar terms in the database, such
as tables and columns, to familiar terms for the user. Therefore, analysts or
managers with no database syntax familiarity can access key information using
terms common to them, such as customer, name, and revenue.
The End User Layer is one of the key components of the Discoverer process. It is in
the database, but is separate from the Oracle Applications data.
There are two important software packages that access the End User Layer. They
are:
■ Administrator Edition - allows the creation of the End User Layer and manages
the administration of responsibilities and roles.
■ User Edition - used to create workbooks (saved queries) and view information
about the business. Oracle provides predefined workbooks which can be used
as bases for ad hoc queries.
In Release 11.0, the User Edition was located on the client. For Release 11i, it is
located in the Discoverer server. This allows for central administration of the
software.
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 database 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, 11i.GL.D) and maintenance packs (for example, 11.5.9).
■ Maintaining Oracle Applications data
Some features such as Multiple Reporting Currencies require regular
maintenance to ensure updates are propagated to the additional tables and
schemas used by this feature. The AD Administration utility (adadmin) allows
you to do this as well as other file system and database maintenance tasks.
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 11i, 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
Subscribe to:
Posts (Atom)
