How do users interact with Oracle Applications – Part 2
Oracle Applications is installed on the servers of a company and every user from the CEO down to a factory staff is given a user name and password. They use their browsers to connect to the servers in their LAN and typically get a menu called responsibilities to choose from. Once they choose their responsibility, accordingly they get another menu of functions they can perform. For example if it is a Purchasing user, he may be able to create RFQs (Request for quotations), Purchase Requisitions, Purchase Orders, Receive material etc. Hence whatever that is happening at the factory ground needs to be entered in a particular form in APPS. If something is not right, APPS will not allow the process to flow further. Hence mistakes will be arrested at each step. Besides there are dozens of reports in a variety of formats for Business Intelligence and better understanding of what is actually happening for the decision makers.
So now, you understand how Oracle apps is used, but how is it structured?
The following image represents the directory structure of APPS.
The APPL_TOP directory contains all the oracle applications products (modules) folders including the au folder where all all your form binaries or *.fmb files are located.
Now let us look at the logical architecture of Oracle Applications.
Essentially, it is a three-tier architecture, with the end-user located at the Desktop Tier, and the application software(s) and Database installed on the server(s). For ease of maintenance you may find the same physical server hosting the Application and Database tiers.
Each user logs in to Oracle Applications through the E-Business Suite Home Page on a desktop client web browser. The user interface is provided in two ways, either through HTML for the newer HTML-based JSP applications, or through a Java applet in a Web browser for the traditional Forms-based interface.
The Home Page provides a single point of access to HTML-based applications, Forms-based applications, and Business Intelligence applications (like Oracle Discoverer).
The Forms client applet is packaged as a collection of Java Archive (JAR) files. The JAR files contain all Java classes required to run the presentation layer of Oracle Applications forms. The Forms client applet must run within a Java Virtual Machine (JVM) on the desktop client. The Oracle JInitiator component (which needs to be installed on the user machine) allows use of the Oracle JVM on web clients, instead of the browser’s own JVM.
The figure below demonstrates Java Servlet Access with JSP Pages
An HTML-based Applications module uses the following access path:
1. The user clicks the hyperlink of a function from a browser.
2. The browser makes a URL request to the Web listener.
3. The Web listener contacts the Servlet engine (JServ) where it runs a JSP.
4. The JSP obtains the content from the Applications tables and uses information from
the metadata dictionary to construct the HTML page.
5. The resulting HTML page is passed back to the browser, via the Web server.
The figure below explains very well how the forms interface works.
When a user initiates an action in the Forms client applet, such as entering data into a field or clicking a button, data is passed to the Forms server on the application tier. The user interface logic runs in the Forms server, and determines the appropriate user interface effect based on the user’s action. For example, a window may open, or another field value may be populated. If necessary, the database tier is contacted for any data not already cached on the application tier, or for data-intensive processing.
The Databse tier is the core Oracle RDBMS where all the tables, views, packages etc are stored. Different modules are organized into different schemas like PO, INV, GL schemas etc. However the APPS schema is granted all permissions on all oracle applications schemas. The APPS database user is the user user who performs all the database activities for the APPS database.