Introduction To Oracle Applications R12

Introduction to Oracle
Applications R12
Overview
Copyright © 2007, Oracle. All rights reserved.
Introduction to Oracle Applications R12 510946415.doc

Effective Paradigm_effective Page 1 of 43 Rev Paradigm_revision
Introduction to Oracle Applications R12
System References
None
Distribution
Job Title*
Ownership
The Job Title [[email protected]?Subject=EDUxxxxx] is responsible for ensuring that
this document is necessary and that it reflects actual practice.

Introduction to Oracle Applications R12

Course Objectives

Oracle E-Business Suite

Complete E-Business Suite from Oracle
Complete E-Business Suite from Oracle

Oracle E-Business Suite is a comprehensive set of enterprisewide business applications that
runs entirely on the Internet. Here, you have the choice to either implement one module or the
entire suite. Oracle E-Business Suite (EBS) helps an enterprise make smarter decisions with
better information, share unified information across the enterprise, reduce Information
Technology (IT) expenses, and enable businesses to run more efficiently.
Oracle EBS extends support for internal processes beyond enterprise boundaries to include
customers, suppliers, and other trading partners. Collaboration enables you to include your
customers and suppliers early on—in product development, planning, procurement, order
fulfillment, and other business processes. You can easily share real-time information with
partners, such as designs, forecasts, orders, and delivery status.
Linking your enterprise with your customers and suppliers offers global visibility and enables
bidirectional flow of business information. For instance, your customers can easily configure,
price, and order products in real-time on a Web store; and the order information flows
seamlessly to order management and shipping for fulfillment.
Similarly, suppliers can get self-service access to orders, schedules, and payment status on
their personalized portal, which is accessible through a simple Web browser. Connecting

enterprises enables you to rapidly respond to dynamic market conditions while improving your
ability to meet customer commitments.

Integrated, Yet Modular
Integrated, Yet Modular

Managing a heterogeneous environment with multiple connections between solutions is
expensive and complex. Because, whenever you update a point solution, you must go back and
review all the integration points and potentially update the integration software itself.
Oracle EBS is engineered to work as an integrated system on a common IT infrastructure.
Therefore, you can directly pass information from one application to another without incurring
incremental integration costs.
Oracle’s applications are not only integrated, they are also modular. Based on your business
needs, you can implement one module, several modules, or the entire suite. Oracle’s open,
standards-based architecture allows you to easily integrate into a heterogeneous environment,
enabling you to fully leverage your investment in existing applications.

Benefits of Oracle E-Business Suite
Benefits of Oracle E-Business Suite

• Oracle E-Business Suite supports multiple languages, all currencies, and many regulatory
requirements in a single database. You can install all languages in the same Unicode
instance. Trading partners can receive business documents in a language of their choice;
users can view and enter dates, numbers, and currencies in a format they prefer. There is
no separate version of the EBS for the U.S., Japan, or France.
• Oracle EBS is the first and only comprehensive set of enterprise applications that is
integrated around a single, common data model. The unified information architecture of
Oracle EBS enables consolidation of data from Oracle and non-Oracle applications, and
allows a consistent definition of customers, suppliers, partners, employees, and all
business entities across the enterprise. You can create a single, global definition that
allows everyone (worldwide) to have access to the same data. The single, common data
model ensures that accurate and consistent information and transaction flows across all
applications.
• Oracle EBS extends internal process support beyond enterprise boundaries to include
customers, suppliers, and other trading partners. Linking your enterprise with your
customers and suppliers offers global visibility and enables bidirectional flow of business
information.

Information-Driven Applications

Major Oracle Application Product Families

R12 E-Business Suite Footprint

You can access the following URLs for more information about the specific Oracle
Applications products (listed in parenthesis):
• http://www.oracle.com/applications/e-business-suite.html (E-Business Suite Applications)
• http://www.oracle.com/applications/financials/intro.html (Oracle Financials)
• http://www.oracle.com/applications/cpm/index.html (Corporate Performance Management
and Daily Business Intelligence)

R12 E-Business Suite Footprint (continued)

• http://www.oracle.com/applications/human_resources/intro.html (Human Resources
Management System)
• http://www.oracle.com/applications/projects/intro.html (Projects)


• http://www.oracle.com/applications/scm/index.html (Supply Chain Planning)
• http://www.oracle.com/applications/order_mgmt/intro.html (Order Management)
• http://www.oracle.com/applications/maintenance/eam.html (Asset Lifecycle Management)


• http://www.oracle.com/applications/scm/index.html (Procurement)
• http://www.oracle.com/applications/manufacturing/intro.html (Manufacturing)


• http://www.oracle.com/applications/logistics/intro.html (Logistics)
• http://www.oracle.com/applications/plm/intro.html (Product Lifecycle Management)
• http://www.oracle.com/master-data-management/index.html (Master Data Management)


• http://www.oracle.com/applications/crm/index.html (Customer Relationship Management
including Marketing, Sales, Service and Interaction Center Technology)

Oracle Applications R12 Architecture

Understanding the Oracle Applications R12 Architecture
Understanding the Oracle Applications R12 Architecture

It is easy to talk about the technical architecture of R12 EBS at the very first. In fact, most
presentations on R12 architecture do just that. But, the technical architecture is important to
support the business needs of R12 E-Business Suite.
It is, in fact, the business architecture that supports the business needs of the company. Though
it may seem to be just a marketing issue, in an integrated E-Business Suite, the software must
support the business needs by being engineered to do so from the start.
It is only after the business needs have been addressed that the technical architecture can be
determined. In most cases, the technical architecture will be dictated by the business needs. If
you do not use this engineering approach, your technical architecture will dictate the business
needs that you can fulfill.

Business Architecture: Oracle Applications R12
Business Architecture: Oracle Applications R12

The R12 E-Business Suite has five principles that drive its business architecture. The principles
are as follows:
1. The R12 E-Business Suite is built on a “modern foundation.” Oracle has embedded all
of its new R12 development into open, scalable standards. These standards include using
Java/J2EE, HTML, JavaScript (JSP), Internet-accessibility, and centralized management.
2. The R12 E-Business Suite is a complete e-business system. The R12 E-Business Suite
provides a comprehensive solution for manufacturing, supply chain management,
financial, project, human resource management, marketing, sales and service processes,
thereby providing a 360-degree view of the company.
3. R12 E-Business Suite provides a comprehensive solution through an integrated
architecture. Crucial to the Oracle Applications R12 architecture, R12’s integration is
engineered into the product, thereby providing a fully integrated package—one that is not
realized through system integrations and customizations.
4. R12 E-Business Suite is fully globalized. R12 E-Business Suite is accessible via global
networks. It accommodates multiple languages and currencies; supports international
features, such as flexible date formats and multiple radix support; supports data in the

Unicode Character Set (UTF-8); and has accounting and business localizations built into
it.
5. R12 E-Business Suite brings considerable tools to the implementation task.
These tools include a rapid installation tool, patch application tools, and a host of
configuration files and customizable Help files to allow the customer to configure the
system to meet their needs. All of these tools help to significantly reduce implementation
time.

Technical Architecture: Oracle Applications R12
Technical Architecture: Oracle Applications R12

The R12 technical architecture is a direct response to the business needs of the customer. In
support of these business needs, R12 has developed four architectural modes for users that are
accessed and controlled through the Personal Home Page (PHP) or Portal.
PHP becomes the gateway through which the user has rights to access all the information to
which they have been granted access. Thus, R12 administrative tasks are simplified while
operations costs are reduced.
The architectural modes equate to common classes of users. Forms-based users are typically
people involved in the transactional operations of an organization. They are full-time users
who need and demand a robust, full-featured interface.
Self-service users are infrequent users who want their interface with R12 to be as simple and as
quick as possible. Most users fall in this category.
Business intelligence users are senior executives who want an easy-to-use interface that can be
used to reveal critical business information. By using a browser, the business intelligence
products eliminate the need for users to learn a new system. If they are familiar with browsing,
they know the basics of the business intelligence interface.

Finally, mobile users cover a surprisingly large range of users whose jobs are likely to keep
them away from a readily available, network-connected computer. These users can range from
sales representatives through inventory users. By utilizing the mobile interface, they are able to
send and receive information at points where it is important and convenient for them.

Basic Technical Architecture of Oracle Applications R12
Basic Technical Architecture of Oracle Applications R12

A tier is a logical grouping of services, spread across more than one physical machine. Oracle
E-Business Suite consists of a three-tier architecture. The diagram in the slide represents the
basic technical architecture of the R12 E-Business Suite.
• Desktop/Client tier: This tier provides the user interface that could comprise desktop
computers, laptops, or mobile devices (such as PDAs). Its purpose is to capture and/or
display information to the user.
• Application tier: This tier, sometimes referred to as the middle-tier, is responsible for
holding the application logic that supports and manages the various Applications
components.
• Database tier: This tier supports and manages the Oracle database and is responsible for
storing and retrieving application data.
Note: The connection between the application tier and desktop tier can operate successfully
over a wide area network (WAN), because the desktop and application tiers exchange a
minimum amount of information—for example, field value comparison differences. In a global
operation that has users at various locations, requiring less network traffic reduces the
telecommunications costs and improves response times for users.

Desktop/Client Tier
Desktop/Client 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.
The desktop tier is responsible for forms that can only be displayed. They can be displayed
using Java (forms-based access) or HTML/JavaScript (self-service, business intelligence, or
mobile access).
The Web listener will download many Java Archive files (.jar files) to your computer, where
they are cached. The first time these files are required, it will take longer to start the R12
session because these files need to be downloaded. Subsequently, the cache will greatly
increase the speed of the startup.
You will need to download the JAR files again only when they have been updated and the copy
in cache is no longer valid. For any of the additional modes, the browser is inherently capable
of handling the HTML and JavaScript. No additional downloads are necessary.
Note: The forms-based mode can communicate to the forms server using sockets, HTTP, or
HTTPS protocols. This allows the forms-based mode to be deployed in a number of
circumstances. HTTP or HTTPS is also used for the other modes. However, they are not as
efficient as sockets.

• Hypertext transfer protocol (HTTP) is a non-persistent protocol that is the basis for a vast
majority of Internet traffic. Therefore, each time you communicate with the server, you
must open the connection, communicate, and then close the connection. This non-
persistent protocol is the source for many HTTP-related performance challenges.
• Hypertext transfer protocol secure (HTTPS) adds encryption to HTTP and helps to secure
information traffic, especially over the Internet. However, since encryption is added, the
performance challenges may be further increased.
• Sockets is a persistent protocol in which a connection is opened for a session and stays
open until the session ends. Therefore communication can occur between a desktop and
server without going through the OPEN/CLOSE steps each time. HTTP/HTTPS may be
preferred over sockets when sending traffic over a public network, like the Internet,
whereas Sockets may be the preferred protocol for forms-based traffic.

Applications Tier
Applications Tier
The applications tier is responsible for storing and executing most of the business logic
associated with R12. It also provides all the non-database services required in an R12 instance
(for example, Web listeners, Forms servers, Reports servers, Concurrent Processing, and so
on). The application tier is the key tier consisting of a host of services within the R12
architecture.
It is simpler to state that all components that are not part of either the desktop tier (that is,
Forms display) or the database tier are assigned to the applications tier.
Prominently, six servers comprise the application tier for Oracle Applications:
• 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.

• Forms server: The Forms server hosts the Oracle Applications forms and associated run-
time engine that supports the professional interface. It is a component of the Oracle
Developer 6i, which 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. It caches data and provides it to the client as required—for
example, 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:
- Standard HTTP network connection
- Secure HTTPS network connection
- TCP/IP connection
• 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 the concurrent processing reports. It
dynamically selects the language of the report at run time, so that users see the reports in
the language they prefer.
• Discoverer server (optional): 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.
• Concurrent Processing server: User interactions with Oracle Applications data are
conducted via HTML-based Applications or the more traditional Forms-based
Applications. However, there are reporting programs and data update programs that need
to run either periodically, or on an ad hoc basis. These programs that operate in the
background while users continue to work on other tasks, may contain a large number of
data-intensive computations, and 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.
• Administration server: The Administration server is located on the node on which you
maintain the data model and the data in your Oracle Applications database. You carry out
the following operations from this server:
- Upgrading Oracle Applications
- Applying database patches to Oracle Applications
- Maintaining Oracle Applications data
Note: The Oracle HTML-based (formerly known as 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
• Operate by direct connection to the Web server

Database Tier
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 with the servers on the application tier, which mediates the
communications between the database server and the clients.
The database tier is responsible for the storage, retrieval, and management of all of the data
associated with your R12 instance. This means that any SQL or PL/SQL will ultimately be
executed on the database tier machine. The database tier is involved in almost everything,
because, regardless of the mode, all data is queried, inserted, updated, or deleted on the
database tier.
The database tier can now significantly benefit from Oracle’s clustering technology, by
spreading the database activity across a cluster of machines.

The Network
The Network
Most discussions about architecture make little, if any, reference to it. And yet, it can have a
great impact on your performance. The network is the most important but the least visible
component of the R12 architecture. The connection links themselves can vary from slow-speed
dial-up connections to high-speed fiber optic channels.
For example, you can have a fast PC running on an R12 instance with a good applications tier
and a clustered database tier, but still end up with bad results. If you are using a slow
connection either directly from that machine (for example, a dial-up connection) or a shared
connection with considerable traffic (a corporate T-1 line that already has considerable
bandwidth usage), then you can experience poor performance. This problem cannot be
attributed to a tier because it is a network-related issue.

Oracle Applications Technology Layer
Oracle Applications Technology Layer

The Oracle Applications technology layer is an integrated collection of components whose
functionality is applicable to all Oracle Applications modules. Components in the Oracle
Applications technology layer include:
• Applications DBA (AD)
• Application Object Library (FND)
• Applications Utilities (AU)
• Common Modules (AK)
• Workflow (WF)
• Alert (ALR)
• OA Framework (FWK)
• Oracle XML Publisher (XDO)

Oracle Homes
Oracle Homes
Oracle E-Business Suite (EBS) uses the latest database version, Oracle 10g. On the middle tier,
Release 12 uses Oracle Application Server 10g and Oracle JDeveloper 10.1.3 for Web-based
Framework applications. On the client, Oracle EBS uses version 5.0 of the Sun Java Plug-in.
Instructor Note
These ORACLE_HOME changes represent a significant update to the architecture and should be
given appropriate consideration.

Oracle Application File System

Oracle Applications File System: Application Tier
Oracle Applications File System: Application Tier

Oracle Applications uses components from different Oracle products. The product files are
stored in several top-level directories, including the following:
• 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.3 directory contains the ORACLE_HOME used for the Applications
Technology stack Java components.

Oracle Applications File System: Database Tier
Oracle Applications File System: Database Tier

Oracle Applications uses components from different Oracle products. The product files are
stored in several top-level directories, including the following:
• 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 the database files.
• The db/tech_st/10.2.0 directory is located on the database node machine, and contains the
ORACLE_HOME for the Oracle10g Database.

Oracle Applications Product Directories
Oracle Applications Product Directories

Each product has its own subdirectory under APPL_TOP, and the Oracle Applications base
release is typically reflected in the name of the subdirectory. For R12, the base release is
12.0.0.
The directory path for a particular product is defined by the value of the environment variable
<PROD>_TOP, where < PROD> is the name of the product schema. For example, the slide
above displays three product directories. If the directory path to APPL_TOP is
/d01/prodappl, the paths to these product directories would be specified in the
<CONTEXT_NAME>.env file as follows:
• APPL_TOP=/u01/oracle/VIS/apps/apps_st/appl
• AU_TOP= /u01/oracle/VIS/apps/apps_st/appl/au/12.0.0
• FND_TOP = /u01/oracle/VIS/apps/apps_st/apps/fnd/12.0.0
• INV_TOP= /u01/oracle/VIS/apps/apps_st/apps/inv/12.0.0
All Oracle Applications products, regardless of the license status, are installed in the database
and the file system. However, files for unlicensed products should not be removed. Conversely,
multiple releases and product versions must not be installed in a single APPL_TOP directory.

Oracle Applications Manager
Oracle Applications Manager

Oracle Applications Manager (OAM) is a sophisticated tool that supports managing and
monitoring of an Oracle Applications system from an HTML-based central control console.
Among other tasks, Oracle Applications Manager can help you to:
• Configure and administer your system
• Diagnose and correct problems
• Manage patches
• Monitor and tune performance
• Monitor system security
OAM is built into Oracle Applications and complements the features of Oracle Enterprise
Manager.

Rapid Install
Rapid Install
Rapid Install comprises information about the Rapid Install Wizard interface, and the setup
steps to be completed before you begin an installation or upgrade of an Oracle Applications
system.
Performing an Installation
To set up a new Applications system, follow the appropriate screens in the Rapid Install
Wizard.
Performing an Upgrade
Rapid Install is used in both pre-upgrade and post-upgrade processing during an upgrade from
Oracle Applications, Release 11i, to Release 12.
Installing Technology Stack Components
Use Rapid Install to install new or updated software components as part of a technology stack
upgrade.
Finishing Tasks

The finishing tasks are necessary to finish a new installation, an upgrade, or a technology stack
installation for Oracle Applications, Release 12. There are also other tasks, such as required
and conditional tasks that may be needed only for systems with a specific functionality.
The following are the components of Rapid Install:
• Oracle database with all the necessary database files (dbfs)
• Applications Technology stack comprising Oracle Developer products and includes the
Forms server, the Reports server and graphics, and Internet Application Server (iAS),
which includes the Oracle HTTP Server
• Oracle Applications file system

Rapid Install Utility

Rapid Install: Tasks
Rapid Install: Tasks

Rapid Install employs the Rapid Install Wizard interface that guides you through the screens
used to carry out the selected task. On the Wizard screens, you enter configuration values for
your system; these will typically be saved in the Applications database for later use.
Previous releases of Oracle Applications used only a text file, config.txt, to store the
supplied configuration values. Release 12 also uses this file (config.txt)in cases where
the database has not yet been created, perhaps because of an interruption in the installation
process.
In Release 12, the name of this configuration file has changed, and it now includes the database
SID, to give a file name of conf_<SID>.txt (for example, conf_PROD.txt). This file
stores the information collected by Rapid Install for all database and Applications nodes.
Rapid Install stores the same conf_<SID>.txt file in three separate locations:
• Database 10g R2 <ORACLE_HOME>/appsutil: Used on database nodes, on
Applications nodes in multinode installations, and in upgrades. It is permanently stored
and not deleted.
• $INST_TOP: Used on Applications nodes in multinode installations, and in upgrades. It
is permanently stored and not deleted.

• /tmp/<time stamp>: Used by Rapid Install during the installation run. It is deleted
when the installation is completed.
The configuration file is also employed in multinode (distributed) installations, where you want
to repeat the installation on multiple machines (nodes). In such a case, you can copy the
configuration file from one machine to another to avoid having to re-enter the information on
each machine. Re-entering information would be time-consuming and prone to error. Storing
the configuration details allows you to enter the information only once, and then use same
system configuration to run the installation on all required machines.
If you are installing in an environment in which different machines are used to support the
database and Applications tiers (as is typically the case), you run Rapid Install on each
machine in turn, starting with the database machine. For example, you might have three
machines: one for the database tier and two for the Applications tier. So you would run Rapid
Install three times, once on each machine. Though the order in which you run Rapid Install on
the Applications tier machines does not matter, you cannot run it on more than one machine in
an Applications system at the same time.
Rapid Install uses AutoConfig as the main configuration engine. It supplies configuration
information to AutoConfig, which stores the configuration for each node in a node-specific
configuration file called a context file.
Note: AutoConfig is delivered with, and required by, a new installation of Oracle Applications,
Release 12. AutoConfig simplifies and standardizes the management of your system
configuration; at any time after the initial installation, you can use the Configuration Editor in
Oracle Applications Manager to update various system settings, and then run an AutoConfig
script to populate the system configuration files with new values.

Summary


Introduction To Oracle Applications R12

Uploaded by

Copyright:

Available Formats

Introduction To Oracle Applications R12

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Introduction To Oracle Applications R12

Uploaded by

Copyright:

Available Formats

Introduction to Oracle

Copyright © 2007, Oracle. All rights reserved.