OAF Page Processing Part #1 - Key Terms

There are lot of terms that you'll encounter while learning about the OAF Page Processing, Request Handling etc. 

Following are some key terms that should help one understand OAF and Web development in quick time:

PAGE:

• A hierarchy of regions that is accessible using a URL. Pages generally represent a cohesive unit of functionality that may stand on its own, or work in concert with other pages.

REGION:

• Rectangular area that determines layout and UI component presentation in the user interface. Regions are containers which can contain both regions and items. Common region examples include tables, flow layouts, headers and so on.

PAGE LAYOUT REGION:

• A region that is a high-level layout element that is a template for the entire page. It supports several navigation and content areas for the creation of pages.

RENDER:

• To furnish; to contribute, to make available, to interpret, represent 
• When web beans are "rendered," UIX includes them in the web bean hierarchy. Furthermore, HTML is generated for the component and sent to the browser.

ORACLE E-BUSINESS SUITE USER SESSION

• A mechanism for keeping track of key Oracle E-Business Suite context information for a login.
• When the user logs in to an OA Framework application, the OA Framework creates an AOL/J oracle.apps.fnd.comon.WebAppsContext object and a browser session-based cookie that together keep track of key Oracle E-Business Suite context information like the current responsibility, organization id and various user attributes (user name, user id, employee id and so on). The Oracle E-Business Suite user session is associated with a servlet session, however, it has its own life cycle and time-out characteristics. 

CONTROLLER:

• In the context of a Model-View-Controller application (MVC), the controller responds to user actions and directs application flow.
• In an OA Framework application, this term is often used to specifically refer to the Java UI Controller associated with one or more regions in a page.

 PAGE CONTEXT:

• Each time a request is received for a page, OA Framework creates an OAPageContext that persists until a new page finishes processing. 
• This object contains parameters from the requesting page
• It also contains form fields if the request is a POST
• The OAPageContext object provides:
• Access to the server Application Module Class
• Methods to perform JSP forwards and client redirects\
• Access to session level Application context for
• User name
• Id
• Current responsibility and so on

WEBBEAN HIERARCHY:

• At page development time, we specify the bean hierarchy. Structure window shows the bean hierarchy at development time.
• The sequence in which region and items appear in structure window determines their position in web bean hierarchy.
• OA Framework reads the page's declarative metadata definition to create the web bean hierarchy.
• At page rendering time, the UIX framework processes the web bean hierarchy to generate the page HTML
  

PASSIVATION:

• The process of saving client state to a secondary medium (in the case of the OA Framework, database tables).
  

ACTIVATION:

• The process of restoring client state from a secondary medium (in the case of the OA Framework, database tables).

Passivation and activation are two phases of a resource management technique that reduces the number of bean instances needed to service all clients.

SERIALIZABLE:

• Process of saving an object's state to a sequence of bytes, as well as the process of rebuilding those bytes into a live object at some future time

Serialization is one way to save data, Passivation is a more generic concept.

PAGE BOUNDARY:

• The boundary between the completion of page processing for one page, and the start of page processing for another. When OAPageBean finishes processing a page.

REQUEST BOUNDARY:

• Once a response is returned, it is the end of the request processing or the boundary between one request/response pair and the next.

A page boundary is equal to request boundary except for JSP forward case where a single request can span multiple pages. 

Request parameters exists throughout the life span of a request, which can span across multiple page boundaries. Request parameters will be hanging around in case of JSP Forward.

JBO:

• Java Business Object
• BC4J was originally named JBO.

JRAD:

• Java Rapid Application Development
• Originally UI Level was called JRAD.

Multple Transactions in One OAF Page

Date: 20-May-2010  (I am little late for posting this article)

Background:

One very respected gentleman (who's blog we all would have visited while working on OAF.. keep guessing !!) asked a question in interview to a dear friend of mine.

How can we have two regions in a page in such a way that if you commit data in one region it shouldn't commit the data in other regions of the page?

In other words the requirement is to have two transactions in one OAF page.

First Reaction:

Shock!!

Root Application Module provides transaction context.

We can have only one Root Application Module in a page, then how can we have two transactions?

Why we need it?

I don't think we need it at all.

We can handle scenarios like this using combinations of Read-Only and Updatable VOs.

My strict recommendation is you try this only at home and never at work. You'll not be always available for your code's maintenance.

An observation that led to answer:

Application Behavior:

After some brainstorming, I remembered an observation while navigating between pages with retainAM=Y and with different Root AM, state of the page is getting retained.

Learning:

Somewhere system was retaining both Root AMs.

Two Root AMs means two transactions.

Test Case Tried:

On a relatively free day at work. I discussed this testcase with my colleague, one of the better technical resources I have ever worked with.

Tried passing AM object of one page to next page using Request and Session scope. Tried out things with both AMs in second page. 

It worked like magic.

Snippet:
------------

Page 1: Empty Page

Controller 1:

pageContext.putSessionValueDirect("xxfirstAM", pageContext.getApplicationModule(webBean));

//You can try passing it in Request also.

//We'll get this value in second CO and update data in VO's in this AM, call APIs by getting OADBTransaction

pageContext.forwardImmediately(<url of second page>);

Page 2: Transaction Page

Controller 2:

OAApplicationModule secondPageAM = pageContext.getRootApplicationModule();

OAApplicationModule firstPageAM =             (OAApplicationModule)pageContext.getSessionValueDirect("xxfirstAM");

// This way we'll be having two AMs in our Controller.

// Both these AMs will have their own transactions.

// Changes commited from one of them will not commit changes in other.