Oracle Application Framework

Structure of OAF

Let us discuss the architecture followed by OAF:

As J2EE follows MVC architecture, OAF also follows MVC architecture as its based on and follows J2EE.
The abbreviation of MVC is Model View Controller.
MVC is the clean design interface between Model, View, and Controller.
MVC is software pattern for implementing the user interface.
It divides a software application into three interconnected parts which makes the implementation of
request and response easier.

Model mainly consists of application data, business rules, logic and functions.

Model contains the components which handles data directly from Database. It includes business components
for Java which mainly are:

Entity Object (EO)
View Object (VO)
Callable Statement (PL/SQL Statement)
Prepare Statement (Single Select Statement)
OADB Transactions (Oracle Apps Data Base Transactions)

View can be any output representation of information, such as a chart or a diagram. is nothing but
the OAF Page Output.

View is implemented by UIX (User Interface XML). A view is told by the controller all the information i
t needs for generating an output.

The view is updated with the change and the representation as given by the model time to time.

The view in OAF comprises of various page level items like text fields, buttons, regions, links etc.
These are visible on any OAF page.
 
Controller accepts input and converts it into commands for the model or view.It can also change the views
presentation of the model.

Controller has got three methods:

Process Request ( The request is called when the page is rendered)
Process Forms Request (HTTP Get)
Process Form Data (HTTP Post)
HTTP get: This method is used only to read the information. It is to obtain a resource without changing anything on the server.

HTTP Post: This method is used to modify the information and update the information on the server.

The figure given below shows the interaction between Model, View, and Controller:

Onion Structure of OAF

Onion structure is another structure of OAF.
The OA Framework can be extracted into a series of concentric layers.
Each layer knows only about its next consecutive layer.
The below figure shows the Onion Structure, in which AM interacts with the VO.

The core layer 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
VO interacts with EO. EO interacts with Data Base.

Advantages and Disadvantages of OAF

The advantages of OAF are as follows:

End user Productivity
Enterprise Grade Performance and Scalability
Highly extensible Architecture
These pages have only region and items, so we can develop pages faster.
Transaction rate is high when compared to internet.
Application Customizability.
Developer Productivity.
It mostly does not require support and training for users and is user friendly.

The disadvantages of OAF are:

Cannot see the layout at design time.
OAF Pages are integrated / compatible only with the Oracle Apps.
Drag and Drop options are not available.
More R&D is required to design a form layout which is time consuming.

About Model

The entire Database related transactions in OAF pages will be taken care by the MODEL.

Model is where the application implements business logic.
Model will implement all the Data Base transactions.
Model component is implemented using BC4J where BC4J is Business Component for Java.
BC4J consists of three components:
Entity Object and Entity Associations
View Objects and View Links
Application Module
Model contains six components including BC4J components, additionally the other
three components are:

Callable Statement
Prepare Statement
OADB Transactions
Callable statement is used to call a PL/SQL statements, Prepare statements are used if we are using
single SELECT statement, and OADB transactions will take care of Oracle APPS related
Data Base transactions.

Entity Objects and Entity Association

Entity Objects:

The entity objects are used if one wishes to do some insert/update operations.
Entity Objects represents a Data Base Row of a table.
Entity Objects will be based on the View (Oracle View), Synonyms or snapshots.
We need to create Entity Object if we want to perform DML operations on the OAF Page.
All the Entity Objects end with the EO.
Example:  employeeEO

When we create Entity Object (EO) one subclass will generate.

We have two types of Entity Objects

I. PL/SQL based Entity Objects

II. Java based Entity Objects

Note: We have two types of tables in Oracle Apps they are Custom Tables and Seeded Tables.

If we want to perform the DML operations on the standard (Seeded) table then we go for PL/SQL based
Entity Object and if we want to perform the DML operations on the custom table then we go for
Java Based Entity Object.

Entity Association:

Entity Association is the relationship between two Entity Objects having one common column.
All the Entity Association ends with the AO (Association Object).
Example:  EmpDeptAO

If we want to perform DML operations on Master Detail page then we go for Entity Association.
If we want to know common column between two tables then we will go for Entity Association.

View Objects and View Links

View Objects:

View Objects are used when we want some data to be displayed on page.
View Objects are used just for displaying purpose.
View Objects access the result set of a SQL statement, it can be either based on the Entity Object
or plain SQL query.
All the view objects ends with the VO
Example: EmployeeVO

When we create the View Object (VO) one subclass will generate with setters and getters method.

We have four types of View Objects and they are:

1) Manual VO

2) Automatic VO

3) Validation VO

4) Property VO

Manual VO:  If we are writing our own SQL query then it will be called as Manual VO.

Automatic VO:  Automatic VO is when we select an Entity Object automatically it will select the Query.

Difference between Manual and Automatic VO is:

If we want to perform DML operations then we can go for VO that should be based on Entity Object.
We go for Manual VO if we are using simple SELECT statement.
NOTE: Note that when we create VO (View Object) all the table columns will be converted into attributes,
hence here we call columns as attributes.

Validation VO:Validating the data in the Data Base, example using WHERE condition in the SELECT statement.

Property VO:Attributes / columns without Data Base columns comes under property VO. These attributes
are also called as Transient attributes.

Example: Suppose there is a table which holds student marks so therefore it contains 6 columns to
hold six subject marks for each student. There is no total column in the table to store the total
marks of the student separately. Now in the output for display purpose we are taking TOTAL attribute,
hence which is not from Data Base table and this TOTAL attribute is called Transient attribute.

View Links:

Relationship between two View Objects having one common column in both the VO’s is called View Link. All the View Link objects end with the VL

Example: DeptEmpVL

Note that if we want to display Master Detail data then we go for View Links, where as if we want
to perform DML operations on Master Detail data we go for Entity Association.

The below figure shows that how View Objects and View Links are interacting with Data Base,
VO interacts with Data Base Directly or VO interacts with Data Base through the EO.

Application Module

It is very important component in the Model.
Every Oracle Application Framework (OAF) page should be attached to some Application Module.
It is the interface between the Client transactions and Data Base transactions.
All the application module objects end with AM.
Example: employeeAM

Whenever we create AM one subclass will generate.

Application Module is of two types and they are:

I. Root Application Module.

II. Nested Application Module.

If we are attaching AM to the Main Region of the page then it is called Root Application Module
and if we are attaching to the child regions (or) nested regions then it is called Nested Application Module.


The below figure shows what is the main region and what are the child regions in OAF page.

The View Objects containing in the Main Application Module can be used anywhere in the child regions
or Nested Application Module.

If the View Objects are attached to the Nested Application Module then those view objects are applicable only
to that particular nested region.

About View

View is the actual output OAF page what an end user can able to see.
In Oracle Apps Framework View is implemented using UIX technology, whereas UIX means User Interface XML.
Whenever we run the page in JDeveloper then automatically UIX will generate web.xml file.
The power of UIX is that allows metadata to be translated to an HTML page for a web browser or mobile device browsers.
The generated web.xml file will be converted into HTML format of OAF page.
Since web.xml file here will work as a cache memory.
Whenever we want to move the web.xml file into the server side then MDS repository is used to move the web.xml file into the server.
MDS stands for Meta Data Service and in the application top we will be having MDS folder.
When we deploy all the OAF page destination paths, regions then the files will be stored into the MDS tables.
The MDS table are like:
JDR_Paths:Stores the path of the documents, OA Framework pages and their parent child relationship.

JDR_Components:Stores components on documents and OA Framework pages.

JDR_Attributes:Stores attributes of components on documents and OA Framework pages.

JDR_ATTRIBUTES_TRANS:Stores translated attribute values of document components or OA framework pages.

JDR_DOCUMENT_ID_S: This is a sequence generator table.

MDS can be managed using standard database procedures and tools.

About Controller

Controller will take care of the web browser activities.
The controller manages the flow between pages.
Controller responds to the user actions and directs application flow.
The controller will request from HTTP get and HTTP post.
All the controllers end with the CO.
When we create controller on subclass will generate.

Controllers have three methods:

Process Request (HTTP get).
Process Form Request (HTTP post).
Process Form Data.

HTTP get:This is used while loading the page.

HTTP post: After loading the page if we want changes.

Process Request: This method will handle HTTP get, for example while loading the page displaying the default items.

Process Form Request: This method will handle HTTP post. After loading the page if we want to
perform any actions then we go for process
form request. For example, after clicking button going to another page.

Process Form Data: This page is invoked upon a browser ‘post’. During this phase the framework will
automatically applies changes back to the underlying view objects. Rarely custom code is required in
this phase. If exceptions are thrown during this phase the phase is skipped and the page redisplays
with the error message.

There are two parameters in the controller:

1) OAPageContext

2) OAWebBean

OAPageContext:

To get and set values of the fields using the OAPageContext.getparatmeter and
OAPageContext.putparameter.
To call one page to another page OAPageContext.setforwardURL.
To redirect the current page itself use OAPageContext.forwardImmediatelyToCurrentPage (or)
OAPageContext.sendRedirect and many more.

OAWebBean:

Each and every field we have properties and the properties define the behavior of item.
OAWebBean represents the Hierarchy/Structure of the components in the page.
WebBean represents the properties of item.
As we discussed what Model, View, and Controller is, look at the below figure which shows that
how they generally interact with each other or how the data flow between them is.

BC4J File Structure

BC4J stands for Business Component for Java, the following figure shows the file structure of
Business Component for Java where xxname stands for any user defined name and PO is the Application
Short name of Purchasing, Vision Operations (USA), and you can use other also, depending upon the requirement.
In place of XXAAM we generally use client name.

In the below figure we listed
• BC4J of AM and VO
• BC4J of EO
• BC4J of LOV
• BC4J of poplist
• BC4J of Controller
• BC4J of Page

Identifying JDdeveloper Version

Let us see how to identify the JDeveloper for the Oracle Apps Instance Version.


Step 1: If we observe we will find an option called “About this Page” in OAF Page.
Click on the link About this Page. The same process is shown in the below figure: