OAF Basics

1. Introduction to OAF
Oracle Application Framework (OA Framework) is the Oracle Applications
development and deployment platform for HTML-based business applications.
OA Framework consists of a set of middle-tier runtime services and a design-
time extension to Oracle JDeveloper called Oracle Applications Extension (OA
Extension). OA Frame work provides a JAVA framework to build an enterprise
application.OA Framework has emerged as an integrated platform for
developing and deploying Oracle E-Business Suite HTML-based applications,
leveraging technological advances without taking on associated complexity.

2. WHY OAF
1. End User Productivity :The shift from client-server to multi-tier
deployments comes with many cost savings, but not without compromise. HTML-
based applications started out very much like old mainframe terminals; actions on
the client side resulted in a round trip to the middle tier. Over time, user interface
interactivity improved. OA Framework has always kept user interface interactivity a
top priority with features such as partial page rendering (PPR), hot keys, smart
choice lists and auto-completion of fields with lists of values. In addition, Oracle
focuses a wealth of resources and expertise on user behavior and psychology, to
develop a set of user interface layout and interaction standards, commonly known
as the BLAF (Browser-Look-And-Feel) guidelines. BLAF is the default look and feel
that all OA Framework applications assume, but can be personalized in many ways
to meet customer branding and style requirements. OA Framework's
implementation of BLAF standards yields a consistent user experience and further
enhances user productivity.

2. Enterprise-Grade Performance and Scalability: OA Framework

has aggressive performance and scalability targets. Most Oracle E-Business Suite
application pages have sub-second response times to most user interactions. It
takes a bit longer the first time a page is accessed within the same Java Virtual
Machine, but thereafter, most of the commonly needed information(such as user
information) is cached in the middle tier, allowing faster response. Resources are
conserved through a number of resource pooling mechanisms and the swapping of
idle resource data between memory and database.
3. Developer Productivity: OA Framework is designed around the simple
Model-View-Controller (MVC) architecture. To shield application, developers
from costs associated with the rapidly changing technological landscape,
Oracle has adopted a declarative flavor of the MVC architecture. Key building
blocks of an application are defined in a descriptive manner using a simple
JDeveloper user interface and then saved in an industry standard XML format.
Oracle is extending access and benefits of the OA Framework development
environment to all Oracle E-Business Suite customers and partners.
Customers and partners can leverage the proven OA Framework technology
to add extensions to their Oracle E-Business Suite applications.

4. Application Customizability: The OA Framework architecture focuses on

a very compelling solution with plenty of flexibility to tailor the user interface
(look-and-feel) and business logic. Thanks to the declarative and object
oriented nature of OA Framework, application personalization and
extensibility is readily available at a fraction of the industry startup cost and
at a very minimal maintenance cost, if any.

5. OpenStandards: OA Framework technologies have driven several industry

standards and have adopted several others as they were published. Several
Oracle technology architects are active members on a number of standards
drafting committees. OA Framework is J2EE(J2EE is a platform-independent,
Java-centric environment from Sun for developing, building and deploying
Web-based enterprise applications online. The J2EE platform consists of a set
of services, APIs, and protocols that provide the functionality for developing
multitiered, Web-based applications.) based and features several industry
standards such as XML, HTML, Java, JSP, SQL and Web Services.

3. OA FRAMEWORKARCHITECTURE
OA Framework is based on the industry-standard J2EE MVC design pattern.
The M(Model)V (View)C (Controller) architecture is a component-based design
pattern with clean interfaces between the Model, View, and Controller. The
Model is where the application implements its business logic. The View is
where the application implements its user interface and the Controller is
where the application handles user interaction and directs business flow.
 Below figure describes the MVC architecture

The OA Framework Model is implemented using Oracle Business Components for

Java (BC4J). BC4J provides optimized, ready-to-use implementations of the J2EE
design patterns that developers otherwise would have to code, debug, and test by
hand. By leveraging BC4J's combination of tested code and productivity tools inside
the Oracle JDeveloper IDE, development teams can focus immediately and only, on
writing business logic and user interfaces instead of on designing, coding, and
debugging handcrafted application "plumbing" code. The model encapsulates the
underlying data and business logic of the application. A BC4J application module is
essentially a container that manages and provides access to "related" BC4J model
objects. It contains Entity objects, View objects, Association Objects, Application
module etc.

OA Framework View is implemented using UI XML (UIX). UIX uses XML to describe
the components and hierarchy that make up an application page. UIX also provides
runtime capabilities to translate that metadata into HTML output so that it can be
shown on a Browser or a mobile device. The metadata ( Metadata describes
other data. It provides information about a certain item's content.
For example, an image may include metadata that describes how
large the picture is, the color depth, the image resolution, when the
image was created) used to describe the UI is loaded into a database
repository, called Meta Data Services (MDS), at deployment time and optionally at
design time as well.

The OA Controller, which is a pure Java class implementation, handles user and
application-driven interactions. Simple page flows (such as a 2-step transaction) are
implemented directly into the Controller object; others are implemented using
Oracle Workflow. In a future release, business flows will be implemented in a
declarative manner similar to that used to define model and view objects.

The below figure illustrates a conceptual overview of MVC Architecture

Below are the key features of OA Frame work

1. Integrated Development Environment:

Oracle JDeveloper with OA Extension (OA Extension) is a world-class J2EE-
based integrated development environment. Oracle customers and third
party consultants have access to the same tools used by Oracle E-Business
Suite developers to build complementary applications as well as extend the
Oracle E-Business Suite applications. OA Extension provides features such as
easy-to-use wizards, a hierarchy navigator, and a property sheet. These
features enable developers to populate the metadata for declarative
application business logic and user interfaces. JDeveloper offers a wealth of
productivity tools such as the UML modeler, code coach, integrated
debugger, local testing environment and documentation generator.

2. Durable Personalization and Extensions:

Personalization is about declaratively tailoring the UI look-and-feel, layout or
visibility of page content to suit a business need or a user preference.
Examples of personalization include:

Tailoring the color scheme of the UI.

Tailoring the order in which table columns are displayed.

Tailoring a query result

Extensibility is about extending the functionality of an application beyond

what can be done through personalization. Examples of extensibility include:

Adding new functional flows.

Extending or overriding existing functional flows.

Extending or overriding existing business logic.

OA Framework is designed with durable personalization and extensibility

capabilities, achieved through the declarative architecture and the underlying
object oriented implementation.

Declarative UI component definitions are stored in the form of metadata in a

database repository. Personalizations are translated into offsets from the
 base metadata definition and stored separately. At runtime, all applicable
personalization metadata is loaded from the repository and layered over the
base metadata definition to produce the net effect. Product upgrades and
patching only affect the base metadata definition so that customer
personalizations are preserved and continue to function properly.

Personalizations can be implemented at several levels by one of three

authors: application developer, application administrator and end user.

An end-user can create a personalization to be applied to specific user

interface components that is only visible in the context of that authoring user.
For example, an end user may save an employee search result sorted by
manager and hide the employee's date of birth column. Once this
personalized view is saved under a given name, the user can retrieve that
view again in the future by that name.

Application administrators and application developers have the flexibility to

tailor the user experience at several levels. They can author personalizations
that affect all users, users of a particular locale, and users of a particular
organization, users with a particular role and in the context of a particular
function. Several levels can apply at the same time with a predetermined
precedence order that yields a very personalized user experience.

Using a combination of OA Extension wizards and built-in personalization

screens, several user interface and business logic extensions are made
possible at a minimal cost to development with little-to-no maintenance cost.
In addition, Oracle E-Business Suite customers continue to enjoy the
extensibility features offered by Oracle Flexfeilds, Oracle Workflow and
Business Events.

3. Consistent and Compelling User Interface:

OA Framework offers developers a wide range of user interface components
that make the building of applications into a more assembly process, freeing
developers from the repetitive composition of common user interface
constructs. Moreover, OA Framework's declarative approach to building
application user interfaces frees developers from the need to learn a vast
array of changing technologies, while offering end users a consistent
application look and experience. OA Framework user interface components
range from simple widgets such as buttons and fields to compound
components such as tables-in-tables and hierarchical grids.

4. User Interface Interactivity:

OA Framework is always exploring the technology frontiers to enrich the
interactivity of HTML-based user interfaces. Along those lines, OA Framework
 provides several features like PPR (Partial Page Rendering) and LOV Auto
Completion and Enhanced Save Model.

5. Object Oriented Reuse:

OA Framework applications can be abstracted into a series of concentric
layers, like an onion. The core layer 20 represents the database and the
surface layer represents the application pages. In between is a number of
business logic and user interface layers. This layering allows for generic code
and components to be implemented at the inner layers to maximize their
reuse across the outer layers. For example, attribute validation is
implemented at the Entity Object (a BC4J object-oriented representation of a
database table in the middle tier) level. All application pages that provide the
user with the ability to populate or update the value of the subject attribute
would receive attribute validation for free through the underlying entity
object. On the user interface side, reusable components can be saved as
shared regions in the metadata services (MDS) repository and reused across
several pages. An administrator can choose to personalize the shared region
such that the personalization impacts all instances of the same region across
pages or personalize the shared region only in the context of the current
page.
 6. Oracle Portal Interoperability

OA Framework offers developers a simple approach to publishing OA Framework

components (commonly known as regions) as Oracle Portal-compatible portlets.
Oracle Portal provides you with a common, integrated starting point for accessing
all your data. Since Oracle Portal lets you personalize the content and look of your
page, you can also personalize the application region that is displayed as a portlet.
Any personalizations you make to that portlet region appear only when you display
that region from the same portlet.

7. Built-in Security

HTML-based applications offer great user and administrator convenience, but

special care must be taken to ensure that these applications are secure. Developing
HTML applications that are truly unbreakable is very difficult, historically requiring
application developers to also be security experts. In fact, most application
developers are not security experts, and they should not need to be. It is the
responsibility of the application framework to ensure that HTML transactions are
authorized, private, and free from tampering. OA Framework provides built in
protection against known HTML hacking strategies, leaving the application
developer free to concentrate on application functionality. Also, since UI
components are defined in metadata rather than in code, the security protection
offered by OA Framework can be advanced to keep up with the state of the art,
without requiring applications to be rewritten.

8. Deployment Environment

OA Framework applications are deployed using standard Oracle 10g AS / Apache

and Oracle10g Database servers. Application pages can be rendered on Internet
Explorer 5.0 or above, Netscape 4.73 or above and Mozilla 1.5 or above. The data
and middle tiers can be deployed on several platforms including Linux, UNIX and
Windows.

3.1 MVC COMPONENTS

3.1.1 Model Components/BC4J Components

The Model encapsulates the underlying data and Business logic of the
application. It involves the following BC4J components.

Entity Objects:an entity object implements the business rules for a given table,
view, or snapshot. Entity objects are intended to be used in many clients
(not just an OA Framework UI), and as such, should consolidate all of the
 relevant validation/behavior for the table. Each table should have at most
one entity object. Entity objects should include attributes for all columns in
its table.

Association Objects: Associations let you create declarative relationships

between entity objects. At runtime, BC4J uses these relationships to
coordinate the related objects. There are two basic types of associations:

Composition - A strong association where the source entity object owns the
destination entity object. In other words, the destination cannot exist independent
of its source. For example, a purchase order header is comprised of purchase order
lines, which have no meaning or life span outside the context of their header.

Reference - A weak association where the source entity object only

references the destination entity object. For example, a purchase order header
references a supplier, but the supplier can still exist regardless of whether a
purchase order references it or not.

View Objects: view objects encapsulate database queries and provide

access to associated entity objects. One of the most important view object
design decisions is whether it should be based on plain SQL, or on entity
objects. All other view objects created for the UI, regardless of whether they
are updateable, are based on entity objects. View objects, like any BC4J
objects, can be created declaratively and programmatically. For performance
reasons it is preferable, if you can, to declaratively define the view object.

Each VO should have(Files VO Should have)

<YourName>VO.xml

Declarative information about VO

<YourName>VOImpl.java (optional)

Add initQuery method if needed

<YourName>ViewRowImpl.java (required)

Contains accessors (setters and getters) for VO attributes

Behind the scenes, these accessors call corresponding methods

in your EOImpl.java

View Links:an association defines a relationship between two entity

objects. Similarly, a view link defines a relationship between two view objects
that BC4J uses to automatically query and coordinate the destination view
 object based on the current source view object. View links can be based on
an association or a declarative join relationship between two view objects. For
example, suppose two tables have a master-detail relationship based on a
foreign key. The corresponding entity objects are related via an association,
and view objects based on those entity objects can be related by a view link
based on the association.

Although view links can be very convenient, use them sparingly in the web
applications pages because they cache both the master and detail records as
the user navigates from one master row to the next -- and this can be
expensive. Use view links only in the following cases:

When specific beans (like the HGrid) require them.

When you have updateable master/detail view objects (on the same or
different pages) whose underlying entity objects are related using
composition, you must define a view link between them (we discuss this
further in Chapter 5).

When you have a read-only master and detail view object on the same page,
and navigating to a master row should cause the children to query
automatically.

Application Modules:A BC4J application module is essentially a container

that manages and provides access to "related" BC4J model objects. The
Application Module-a container for Entity Object (EO), View Object (VO) and
other BC4J components.The AM is the transaction container.

In this context, objects are "related" by virtue of participating in the same

task. For example, all the BC4J objects that comprise a single transaction
participate in the same task -- even if the corresponding user interface
requires that the user visit multiple pages. The following is a list the distinct
roles that application modules can play in an application:

UI Root Application Module - Establishes the transaction context for one or several related
UI pages. Every page has a root application module which includes any view objects and
nested application modules used by the page.

UI Shared Region Application Module - Any UI region with created for use in
multiple pages should have its own containing application module. When this
region is used in a page, OA Framework automatically nests its application
module beneath the page's root application module

UI List of Values Application Module - This is a special case of the previous role.
When List of Values (LOV) view objects is created, these components can be
added to an application module dedicated to the job of aggregating LOVs for
 a given package.

Validation Application Module - A validation application module aggregates

related view objects created for the purpose of performing lightweight SQL
validations. Entity objects and experts make use of validation application
modules, which have nothing to do with the user interface.

3.1.2 VIEW COMPONENT

The View component in MVC architecture describes the User interface for
examples the page layout, regions etc. The view formats and presents model
data to the user. Pages comprises of regions and items. Items are simple
widgets like buttons, fields, images and so on which contain no children.
Regions are container objects that can hold items and other regions.
Examples of regions include headers, tables, and special layout components.

Each region and item that you define has a style property that tells the OA
Framework what web bean object to instantiate for it at runtime (and this in
turn dictates what HTML is generated for the bean). For example, if you
define a region whose style property is "table," the OA Framework will
instantiate an oracle.apps.fnd.framework.webui.beans.table.OATableBean.

All pages must have a single top-level region (often called the "root region")
whose style is pageLayout.This is instantiated as an
oracle.apps.fnd.framework.webui.beans.layout.OAPageLayoutBean.

The sequence in which regions and items appear in JDeveloper page tree
(and the corresponding XMLfile) tells the Framework where to add these
objects to the runtime bean hierarchy.

3.1.3 CONTROLLER

The controller responds to user actions and directs application flow. Controllers can
be associated with the view at the region level (in more general terms, any OA
Framework web beans that implement the
oracle.apps.fnd.framework.webui.beans.OAWebBean Container interface can
have

associated controllers).The controller class is where you define how the web beans

Behave. Specifically, you write controller code to: Manipulate/initialize the UI

at runtime (including any programmatic layout that you are unable to do

Declaratively) and Intercept and handle user events like button presses. The
Controller has three methods

o ProcessRequest()

o ProcessForm Request()

o Process Form Data()