Tuesday, March 13, 2007

Oracle Application Concepts

The Oracle Applications Architecture, as shown in figure 1 below, is a framework for multi-tiered, distributed computing that supports Oracle Applications products. In this model, various servers are distributed among multiple levels, or tiers.

A server is a process or group of processes that runs on a single machine and provides a particular functionality, often referred to as a service. For example, the HTTP server is a process that listens for and processes HTTP requests, and the Forms server is a process that listens for and processes requests for activities related to Oracle Forms.

A tier is a logical grouping of services, potentially spread across more than one physical machine. The three-tier architecture that comprises an Oracle E-Business Suite installation is made up of the database tier, which supports and manages the Oracle database; the application tier, which supports and manages the various Applications components, and is sometimes known as the middle tier; and the desktop tier, which provides the user interface via an add-on component to a standard web browser.

The Desktop Tier

The client interface is provided through HTML for the newer HTML-based applications, and via a Java applet in a Web browser for the traditional Forms-based interface. In Oracle Applications Release 11i, each user logs in to Oracle Applications through the E-Business Suite Home Page on a desktop client web browser. The E-Business Suite Home Page provides a single point of access to HTML-based applications, Forms-based applications, and Business Intelligence applications.

a) 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 a collection of Java Archive (JAR) files. The JAR files contain all Java classes required to run the presentation layer of Oracle Applications forms.

b) Oracle JInitiator

The Forms client applet must run within a Java Virtual Machine (JVM) on the desktop client. The Oracle JInitiator component allows use of the Oracle JVM on web clients, instead of the browser’s own JVM. JInitiator is implemented as a plug-in (Netscape) or ActiveX component (Microsoft Internet Explorer). JInitiator is only invoked when a user chooses to access functions that require it, such as running a form. If JInitiator has not been installed, the Web browser prompts the user to download the required installation executable.

The Forms client applet and commonly used JAR files are downloaded from the Web server at the beginning of the client’s first session. Less commonly used JAR files are downloaded as needed. The JAR files are cached in a directory specified when JInitiator was installed.

The Application Tier

The application tier has a dual role: hosting the various servers that process the business logic, and managing communication between the desktop tier and the database tier. This tier is sometimes referred to as the middle tier. Oracle9i Application Server (9iAS) provides the technology used on the application tier. Six servers comprise the application tier for Oracle Applications:

a) Web server

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

- Web Listener
- Java Servlet Engine
- JavaServer Pages (JSP)

The Web listener component of the Oracle HTTP server accepts incoming HTTP requests (for particular URLs) from client browsers.

b) Forms Server

The Forms server hosts the Oracle Applications forms and associated runtime engine that support the professional interface. It is an Oracle Developer 6i component that mediates the communication between the desktop client and the Oracle database server, displaying client screens and initiating changes in the database according to user actions.

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

c) Reports Server

The Reports server is automatically installed on the same node as the Concurrent Processing Server and its reports are contained in the same directory as the concurrent processing reports. However, reports generated by the Reports server are monitored and administered separately from concurrent processing reports.

d) Discoverer Server (optional)

The Discoverer server comprises Oracle Discoverer 4i, a key component of the Oracle9i Application Server (9iAS). Discoverer 4i is tightly integrated with Oracle E-Business Suite Release 11i, allowing E-Business Suite users to employ Discoverer to analyze data from selected business areas in Financials, Operations, Human Resources, Purchasing, Process Manufacturing, Activity Based Management, and other products. The Discoverer server complements the Reports server, by allowing performance of ad hoc queries and analysis of the resulting query output. It also allows users to perform projections based on possible changes to the business environment or other strategic factors.

e) Concurrent Processing Server

There are various reporting programs and data updating programs in Oracle Applications that need to run either periodically, or 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, and are run using the concurrent processing architecture. To ensure that resource-intensive concurrent processing operations do not interfere with interactive operations, they are run on a specialized server, the Concurrent Processing server.

Processes that run on the concurrent processing server are called concurrent requests. When you submit such a request, either through HTML-based or Forms-based Applications, a row is inserted into a database table specifying the program to be run. A concurrent manager then reads the applicable requests in the table, and starts the associated concurrent program. 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.

f) Admin Server

The Admin (Administration) 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

In general, Applications patches consist of files and scripts that update the file system and database objects. You use the AutoPatch utility (adpatch) to perform these updates. AutoPatch may alsobe used to apply cumulative patches such as mini-packs (for example, 11i.AD.H) and maintenance packs (for example, 11.5.10).

Some features, such as Multiple Reporting Currencies, require regular maintenance to ensure that updates are propagated to the additional tables and schemas they use. The AD Administration utility (adadmin) enables you to carry out this and various other file system and database maintenance tasks.

The Database Tier

The database tier contains the Oracle database server, which stores all the data maintained by Oracle Applications. The database also stores the Oracle Applications online help information. 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 clients.

No comments: