What is Oracle E-Business Suite: it is known on the market by various names such as Oracle

Enterprise Resource Planning (ERP), Oracle Apps, Oracle Applications, Oracle Financials. It is
engineered to work as an integrated system on a common IT infrastructure.
The product offering in E-Business Suite is organized into product families.
Some of the key product families are as follows:
Financials
Procurement
Customer Relationship Management (CRM)
Project Management
Supply Chain Planning and Management
Discrete Manufacturing
Process Manufacturing
Order Management
Human Resources Management System (HRMS)
Applications Technology
In E-Business Suite, each product family usually consists of individual applications. For
example, some of the applications that make up the Oracle Financials product family are General
Ledger, Payables, Receivables, Cash Management, iReceivables, iExpenses, and others.
History of Oracle Apps:
When the Oracle ERP product was initially launched, the screens were built in character mode.
The end users interacted with the system through dumb terminals, which provided a characterbased interface that connected to the back end server. Both Oracle Forms (then known as
SQL*Forms) and Oracle Database were run at the back end tier. Initially, the R10.7 version of
Oracle Applications ran in character mode, as did all the previous releases.
When Oracle released its GUI version called SmartClient, the SmartClient screens were built
with Oracle Forms 4.5 and ran at the desktop client tier, accessing the database over the network.
Although SmartClient provided a better user experience, it was difficult to maintain, as software
updates needed to be distributed on every individual client desktop. Last in that release, Oracle
announced R10.7 NCA (Network Computing Architecture), which was an attempt to integrate
the latest web technologies into Oracles business applications using three-tier architecture,
including database and application
servers; end users interacted with the system using the browser from their client desktops.
The latest releases of E-Business Suite, R11i and R12, are also based on multi-tier architecture.
Most of the screens in Oracle E-Business Suite were initially developed using Oracle Forms.
However, over the last few years, Oracle has started to deliver new screens using pure web-based
technology. These web-based screens do not run within a Java applet, unlike Forms-based

screens. Instead, the HTML-based screens are run with a browser such as Firefox or Internet
Explorer. Oracle initially started developing HTML-based pages in E-Business Suite primarily to
provide a light footprint application or Self-Servicebased applications.

Commitment to the open industry standards usually leads to the increased product
interoperability.
A pure HTML-based web application is lightweight and it runs without the need for a
Java applet in the browser.
An adoption of the new components and emerging technologies such as AJAX, Rich
Internet Applications (RIA), and others ensures a better end user experience.

As a result of the preceding factors, even the new back office screens are now being developed
as HTML-based pages using Oracle Application Framework (OA Framework).
Nowadays, Oracle E-Business Suite developers find themselves working with both Oracle Forms
and OA Framework, as the current releases (Release 11i and Release 12) contain a mixture of
screens using both the technologies.
Configurations, Personalizations, Extensions, and Customizations:
Oracle E-Business Suite was designed and developed to take into consideration various standard
business flows that are common to most organizations. However, each business can have its own
unique requirements.
Eg: A company may want to allow all of its employees to make purchases up to $10
withouthaving such purchases approved. Another company may have a business rule that each
employees approval limit depends on his or her position within the organization.
Oracle E-Business Suite is a package that has to meet not only the needs of both these types of
companies, but also the needs of numerous other companies that may have a completely different
set of requirements and business needs. Thats why Oracle E-Business Suite has been developed
in a configurable manner, so that each customer can buy this package and configure it to meet his
or her specific business requirements. However, if business requirements cannot be met purely
by using setup and configuration options, implementations have to resort to other options such as
system personalizations, extensions, and customizations, which may or may not require custom
code to be written by an E-Business Suite technical developer.
Configurations: E-Business Suite is an package that is both configurable and extensible.
Changes are mostly made to ERP products by means of setup and configurations. Performing a
setup usually means making changes to the product, without writing computer programs. System
or product configuration is normally performed by functional analysts.
Personalizations: The major technologies that enable user personalizations in E-Business Suite
are Oracle Forms and Oracle Application Framework (OAF), often referred to as Forms
Personalizations and OA Framework Personalizations. If business needs cannot be met by

system configuration and setup, this is the first option to look at as it provides the safest way to
change the system.
Customizations and Extensions: certain business requirements cannot be met through the
product configuration and personalization, the technical development team is required either to
extend the existing product functionality or introduce completely new custom modules that
seamlessly integrate with the standard product and functionality.
E-Business Suite Environments: The installations can be either on the same machine or on
different physical machines. Each such installation is called an instance or an environment of
Oracle E-Business
Suite and consists of E-Business Suite software, an Oracle database including the data files, and
Oracle server software.
Master environment This environment is used for the main configuration setup of the system.
Although it does not contain any transactional data, it is important that the master environment is
managed by a very strict change control as this environment contains production (master) setup.
Development environment This is where developers design and build extensions and
customizations. The developers are usually granted very powerful access rights for both EBusiness Suite and the operating system that hosts the system. For instance, the developers may
be granted System Administrator or Application Developer responsibilities.
Testing environment (also known as UAT) Developers usually do not have an APPS database
schema password to this environment. This is where users sign off on customizations and
configuration changes.
Deployment environment Once the users have finished their User Acceptance Testing on a UAT
instance, patches/scripts can then be promoted to a Deployment instance for final checks.
Effectively, applying patches on a Deployment instance is a dry run before applying code
changes to a Production instance.
Patching environment Oracle delivers their code changes, bug fixes, and product updates
through patches. The patches can be downloaded from the Oracle Support website and applied
by E-Business Suite database administrators (Apps DBAs). Apps DBAs can use the patching
environment to perform sanity checks for patches delivered by Oracle.
Support environment if a user reports an issue on the production system, it is a good idea to
reproduce the problem on a copy of the production system. Such copied instances are referred to
as clones. The support environment is exclusive to the support staff, where developers do not
make changes directly. This environment is usually the most frequently cloned environment in
cases where E-Business Suite implementation is running a live production instance. Frequent
cloning helps the E-Business Suite support staff to reproduce production issues.
CRP environment The conference room pilot environment is where someone, usually an
implementation team, gets buy-in to their product offering from the wider user and business

community during an implementation. This environment is usually used for sign-off during new
implementations.
Migration environment For new implementations of Oracle Applications, developers are tasked
with migration of data from the old legacy systems into Oracle E-Business Suite. This is where
repeated data migration can take place before the migration code gets frozen and ready for user
testing.
Production environment This is where the business runs its day-to-day operations.
In very simple terms, the life cycle of extensions and customizations could be summarized as
follows: the developer performs the development and unit testing in the development
environment, and the code gets promoted to the testing environment. Following successful
testing, the changes are applied to the production environment. There can be more than one
development environment for any implementation as well as a live site, especially when some of
the bigger modules are being implemented with different timelines. Nevertheless, the changes in
each development environment should ideally be tested on a common test (UAT) environment.

Shared Data Model: simplied view of data sharing between the modules in Oracle Applications.

Example of Data Sharing

System Components for Both R11 and R12 in Oracle Apps:

Concurrent Program: After you have defined the logic for your program, you must define a
concurrent program that you call from your forms or from Standard Request Submission. You
first define a concurrent program executable that tells the application where to find your program
logic. You then define as many concurrent programs as you need that use your concurrent
program executable. You can define which concurrent programs are incompatible with your
concurrent program, and if you use Standard Request Submission, you define the parameters
used by your executable. You can specify validation information for your parameters to control
the values users select on the Submit Request form.
To develop or customize a report in a Purchasing module, assuming the executable name is
XXPOPRINT.rdf, you need to register the executable with the XXPO application. Hence, this
RDF must be transferred to directory /home/oracle/apps/appl/xxpo/reports/<US>. When the
end user runs this report from the application, Oracle Apps will identify the executable
XXPOPRINT as being attached to the XX Purchase Order application. This application will
have a short name of XXPO and will be mapped
to directory /home/oracle/apps/appl/xxpo/reports/US for reports, which is where the file
XXPOPRINT.rdf resides on the server. Hence, the name of the application will help the Oracle
Apps environment locate the executable file on the server.