OAF Basics
Oracle Application Framework (OAF) is an architecture for creating web-based pages within the Oracle EBS platform.OAF follows MVC architecture. MVC stands for Module View Controller Architecture
Key JSP Application Components
A typical JSP application involves the following components: a browser for client access, a database for enterprise data, and a web application server (“middle tier”) where the application objects live.
-The browser communicates with the middle tier using HTTP (HyperText Transfer Protocol) which involves sending a request message to which the middle tier replies with a response message.
-A JSP is a file with some HTML and Java code that executes top to bottom. At runtime, it is compiled into a Java class which is actually a servlet.
-A servlet is a Java-based web application server extension program that implements a standard API.
-A servlet session is a mechanism for maintaining the state between HTTP requests during a period of continuous interaction between a browser and a web application. A session may be initiated at any time by the application and terminated by the application, by the user closing the browser, or by a period of user inactivity. A session usually corresponds to an application login/logout cycle
-A JavaBean (or “bean” for short) is simply a reusable component that implements specific design patterns to make it easy for programmers and development tools to discover the object’s properties and behavior.
-Any objects in the middle tier that communicate with the oracle database use a JDBC (Java Database Connectivity) driver.
What Happens at Runtime?
Step 1
When the user selects a link, a button, or an active image, the browser sends an HTTP request to the web application server for processing. For the purposes of this introduction, we will focus on the two primary HTTP request methods (POST and GET) that are relevant for an OA Framework application.
HTTP GET
Whenever the user clicks a link or an image with an associated URL (like http://www.rediff.in) the browser submits a GET request.
You can think of a GET as a postcard: both the address (URL) and any information the sender wants to convey (URL parameters) are written on the card itself (which is inherently space-constrained; how much can you write on a postcard?). This means that all the information for the communication is visible externally (and in an HTTP GET, all the data sent to the server is visible as parameters on the URL).
HTTP POST
Whenever the user clicks a button, image, or link that performs a form submit in an OA Framework application the browser submits a POST request to the server (technically, a form can be submitted with a GET, but for the purposes of working with the OA Framework, you can assume a form submission is a POST).
You can think of a POST as an envelope: the address (URL) is written on the outside, but the content within has the information the sender wants to convey. There’s no limit to the amount of information that can be stored inside the envelope. Furthermore, the submitted data is not visible on the URL — just as the contents of an envelope are not externally visible (although the metaphor isn’t absolutely accurate: a developer could also add some parameters to the URL when doing a form submit).
Step 2
The HTTP listener in the web application server routes the incoming request to the JSP.
Step 3
The JSP delegates to one or more JavaBeans which implement various behaviors including database interaction. Once they have completed their work, the JSP prepares the appropriate HTML content to send back to the browser in the response.
Step 4
The browser displays the HTML it received in the response.
What is a Cookie?
A “cookie” is a nugget of information that a web application can give to a browser with the understanding that the browser will send it back to the server with each request. In other words, it is a mechanism for holding on to some small amount of state between requests.
Cookies can be persistent or session-based:
-The browser saves a persistent cookie to a file on the user’s computer, and the information endures across browser sessions. Have you ever navigated to a website that greeted you by name before you logged in? If so, this was accomplished with a persistent cookie.
-Session-based cookies are held in the browser’s memory, and when the browser is closed, the cookie is destroyed.
More About Servlet Sessions
In the same way that AOL/J pools JDBC connections because they are a precious resource, the servlet engine pools request processing threads. The servlet engine allocates a thread to process each request it receives. When the request completes, the servlet engine returns the thread to its pool.
Servlet Session
A servlet session is a mechanism for maintaining the state between HTTP requests during a period of continuous interaction between a browser and a web application. A session may be initiated at any time by the application and terminated by the application, by the user closing the browser, or by a period of user inactivity. A session usually corresponds to an application login/logout cycle, but that is not strictly true in the case of OA Framework applications
Oracle Applications User Session
When the user logs in to an OA Framework application, the OA Framework creates an AOL/J oracle.apps.fnd.common.WebAppsContext object and a browser session-based cookie that together keeps track of key Oracle Applications context information like the current responsibility, organization id, and various user attributes (user name, user id, employee id, and so on).
-The cookie contains an encrypted key identifier for a session row stored in the Applications database (specifically, this is the servlet session ID which, in its decrypted form, serves as the primary key in the ICX_SESSIONS table)
-The WebAppsContext retrieves this key-value after each request and uses it to query the current session state
-The Oracle Applications user session is associated with a servlet session, however, it has its own life cycle and time-out characteristics
Generally, the Oracle Applications user session should have a longer life span than the servlet session (the servlet session should be time-out sooner).
-An Oracle Applications user session might be associated with multiple servlet sessions (if, for example, the servlet session times out while the user takes a phone call in the middle of creating an OA Framework expense report, and then resumes work before the Oracle Applications user session times out).
-A servlet session might be associated with multiple Oracle Applications user sessions (if, for example, a user logs out and then back in again without closing the browser window).
-If the Oracle Applications user session times out, as long as the user does not close the browser window (so the browser session-based cookie isn’t lost) and no one deletes the corresponding session row in the ICX_SESSIONS table, the user can resume her transaction at the point where she stopped working after being prompted to log back in.
If you need access to any of the information stored with the Oracle Applications user session, you can obtain it from OAPageContext (in your controller code) or OADBTransaction (in your model code).
Related Links
OA Framework Profiles
Profile options in Oracle Apps
How to change Corporate Branding Image for Oracle Applications