2. OA Framework Architecture

OA Framework is based on MVC (Model-View-Controller) architecture. However to reduce the complexity, each layer is futher sub divided into multiple layers.

Below figure shows sub division of these 3 layers:

View (Pages in OAF)

==========================
While developing pages in OAF, these are stored in XML format (due to declarative nature of development method). However to access an OAF page from front end, these page definitions must be loaded in Oracle database i.e. MDS.

Metadata Service (MDS) is a repository used for rendering of an OAF page. It is implemented as a group of database tables that stores the structure and properties of the page components. The tables that belong to the MDS repository begin with JDR% : JDR_PATHS, JDR_ COMPONENTS, JDR_ATTRIBUTES_TRANS, and JDR_ATTRIBUTES. (For standard pages delivered by Oracle, page definition XML files are stored in $<PRODUCT>_TOP/mds directory. However these are only for reference purpose and are not used at runtime).

A page consists of regions and items. At runtime, both regions and items are instantiated as JavaBeans within the application server.
As page definition is stored in the database tables, OA Framework caches the page structure into the memory cache on middle-tier. When any given page or region is accessed for the very first time, its definition gets loaded in the MDS cache. Subsequently, each successive access to that page happens from the memory, hence reducing the performance overhead of querying the page definitions from database tables.

Controller in OAF
==========================
A controller in OA Framework is a Java class that is attached to a region. Its function is to handle user actions.
Controllers in OA Framework are based on the OAController interface, which defines three methods that can be implemented in the controllers that implement the OA Framework controller:

processRequest() method:
PR method is called by OAF just before a region gets displayed.
One page can have multiple regions, and each region may have a controller attached to it. If a page has multiple regions and controllers, controller against the outermost region will be the first to be called.

processFormData() method:

When a user submits the page, the PFD method in the controller class is invoked. The purpose of this method is to transfer the values from the fields on the screen into the cache.

processFormRequest() method:

Finally if everything is fine till this point, then PFR method of the controller class is called. Usually we issue a commit via processFormRequest() after all the validations. If there are multiple controller classes at different levels, then processFormRequest() against each of the controllers is called for each nested region within that page.

Also, instances of OAPageContext class and OAWebBean class are also passed as parameter to all these 3 methods. OAPageContext is used to get parameter values from the page and OAWebBean can be used to get handle of any of the bean within the page.

Model (BC4J)

==========================
Model part in OAF is implemented using "Business Components for Java - BC4J". BC4J is collection of application module (AM), view object (VO) and entity object (EO).

Application Module (AM):

An AM is container for server side objects, which are view objects, entity objects, view links, and entity associations.

Every OAF page accessed through Oracle apps must have an Application Module attached to its top-level region which is root AM. This top-level region is of the pageLayout region type and serves as a container for other regions and page components. The Root AM holds a BC4J transaction object that helps in JDBC operations. AMs can also be attached at lower-level regions within the

page. In such cases, AMs become nested AMs. The nested AMs reference the Root AM’s transaction object.

View Object (VO):

The purpose of a VO is to query data from database. A view object can either be a SQL Statement or it can be based on entity objects. If a region is read only, then its view object can be based directly on a SQL Statement. However, if the region allows a user to make changes to the data, then its VO should be based on entity objects. For example, view objects used by LOVs are not based on entity objects.

Entity Object (EO):

Entity objects are responsible for doing inserts, updates, and deletes to database tables. Each instance of an entity object represents a single row in the database table.

However, inserts, updates, and deletes can be done from anywhere. This is possible because any layer can request a JDBC connection via the AM. But this is not a recommended approach.

==========================

For better understanding, lets take an example of a page where user first queries the data, then modify the records and finally save/submit the changes.

Querying the data
VO based on an EO, which is based on a database table. The query is executed on that table. Data returned from SQL query is stored in entity object cache.

Modifying the data
The data changes only happen in the browser. The fields on the screen may be mapped to view object attributes, but the view object or the entity object is not affected until the page gets submitted to the server.

Submitting the form

• Fields in the screen are mapped to VO attributes. At this stage, PFD method of the controller is called. It transfers the values from the screen fields to the VO cache. As VO is based on EO, changes are further transferred into the EO cache.
• At the time when the cache is populated, the setAttribute method is called for each column. Within the setAttribute method, VO then calls the corresponding set(Attribute Name) method in the underlying EO. This executes the column-level validation in the entity object. Once all the attribute values have been set, OAF calls the validateRow() method for each VO row the user modified. This executes any row-level view object validation. Finally, within the validateRow() method, the view object calls validateEntity() for validating data in underlying entity objects.
• Once the cache has been populated and validated by PFD, the processFormRequest() method gets called. Inside this method, we can issue a commit or rollback through the AM. When a commit takes place, the data changes are transferred from the cache to the database table.