Oracle Applications Manager (OAM) allows administrators to manage Oracle E-Business Suite systems from an HTML console. Utilities available from OAM include Oracle Workflow Manager, Patch Wizard, and Concurrent Processing monitoring tools.
With Oracle Applications Manager, system administrators can view information on general system activity including the statuses of the database, concurrent managers and other services, concurrent requests, and Oracle Workflow processes. OAM provides a summary of configuration changes, infrastructure usage, performance, required
maintenance activities, potential security issues, status of business flows, and diagnostic test results. In addition, they can manage downtime and patching. System administrators can also start or stop services, and submit concurrent requests.
Using Oracle Workflow Manager, administrators can control Workflow system services, such background engines, the Notification Mailer, agent listeners, queue propagation, and purging obsolete Workflow data. OAM utilities are generally available from two main screens: the Applications Dashboard and Site Map
Oracle Applications Manager uses with Oracle Application Object Library’s function security model. You can create custom responsibilities and menus to control access to specific OAM features. These features can thus be directly available from the E-Business Suite Home Page.
Oracle Applications has the capability to restrict access to a responsibility based upon the Web server from which the user logs in. This capability is provided by tagging Web servers with a “server trust level.”
The server trust level indicates the level of trust associated with the Web server.
Currently, three trust levels are supported: 1) administrative, 2) normal, and 3) external.
Web servers marked as “administrative” are typically those used exclusively by system administrators. These servers are considered secure and may contain highly sensitive  information. Servers marked as “normal” are those used by employees within a company’s firewall. Users logging in from normal servers have access to only a limited
set of responsibilities. Lastly, servers marked as “external” are those used by customers or employees outside of a company’s firewall. These servers have access to an even smaller set of responsibilities.
Setting the Server Trust Level for a Server
To assign a trust level to a Web server, set the Node Trust Level profile option. The Node Trust Level profile option uses the Server profile hierarchy type, meaning that the value of the profile depends on the particular middle-tier server accessing the profile.
This profile option can be set to either 1, 2, or 3, with the following meanings.
• 1 – Administrative
• 2 – Normal
• 3 – External
To avoid having to set the Node Trust Level profile option for every Web server, you may wish to set it to a default level of trust at the site level, such as level 1. If no value is set for the Node Trust Level profile option for a Web server, the Web server is assumed to have a trust level of 1 (Administrative).
Restricting Access to a Responsibility
To restrict access to a responsibility, set the security-based Responsibility Trust Level (internal name APPL_SERVER_TRUST_LEVEL) profile option value for that responsibility to be the number 1, 2, or 3. Setting this profile value ensures that only Web servers with the same or greater privileged trust level may access that responsibility.
Like the Node Trust Level profile option, the default value for the Responsibility Trust Level is 1.
When fetching the list of valid responsibilities for a user, Oracle Applications checks to find only responsibilities with a Responsibility Trust Level value greater than or equal to the Web server’s Node Trust Level. In this way, a responsibility with Responsibility Trust Level set to 1 would only be available if the Web server has the Node Trust Level set to 1 as well. A responsibility with Responsibility Trust Level set to 2 would only be available if the Web server has Node Trust Level set to either 1 or 2.
Configuring the Login Page for Oracle Applications
Oracle Applications uses a configurable login page, which can be tailored to suit the needs of different organizations
Users log in to Oracle Applications using a client web browser. From the Oracle Applications Login page, users access the E-Business Suite Home Page, which provides a single point of access to HTML-based applications, forms-based applications, and Business Intelligence applications. Users access the Oracle Applications Login page from the following URL: http://<server:port>/OA_HTML/AppsLogin
For example, http://r121.oracleerpappsguide.com:8000/OA_HTML/AppsLogin
From this URL, you will be redirected to the central login page, “AppsLocalLogin.jsp”.
The following features are displayed in the default login page: Username field,  Password field, Login button, and the Language Picker (if more than one language is installed).
The following user interface features can be turned on or off through the Local Login Mask profile option:
 Hints for username/password
* Register URL – this link allows the user to perform self-service registration in User
Management
 * Forgot Password URL – allows the user to have a password reset
 Language Picker
 Corporate Policy message
* Oracle User Management must be installed for “Register URL” and “Forgot Password URL” to be enabled.
The ICX login page (http://server:port/OA_HTML/US/ICXINDEX.htm) redirects the user to the central login page, “AppsLocalLogin.jsp”. If, in a previous release, you customized the ICX login page previously with a custom logo, you should make a copy of the new ICX login page and replace the existing image with your custom image in the copied file. The location for the company logo is $OA_MEDIA/FNDSSOCORP.gif.
Ensure that the image is appropriately size. Also, you should change the text of the message ‘FND_ORACLE_LOGO’ in Message Dictionary to the appropriate text. The following login URL is supported, but no new features are being added to it: http://server:port/OA_HTML/jtflogin.jsp
If the Oracle Applications instance is Single Sign-On enabled, the servlet directs the user to the Single Sign-On login page.
AdminAppServer Utility
Because Release 12 is deployed in a multi-tier configuration, the security model includes authentication of application servers to the database servers they access. When this layer of security is activated, the application server passes server IDs (similar to passwords) to the database server. If the database server recognizes the server ID, it grants access to the database. The server IDs are created using a Java script called AdminAppServer.
The application server security system is by default not activated; if it you must activate it after installation, if required. The application servers are not assigned server IDs and the database servers do not check for server IDs.


Forms-based
users are involved in the transactional operations of an organization. These users are usually full-time users and require a robust interface with maximum features.
The desktop tier is only responsible for displaying forms. To forms-based users, the forms are displayed using java. Therefore, the desktop tier needs java virtual machine (JVM) and java archive (JAR) files to operate in the forms-based architectural mode.
JVM is installed either as a plug-in in Netscape Navigator or an ActiveX control in mocrosoft IE. Oracle 11i provides JInitiator as a JVM that can be downloaded and installed. You perform the installation procedure only once. JInitiator is considered an add-on to the browser.

Self-service users are infrequent users of oracle. They require a sinmple and quick interface. Typically, most users in an instance are self-service users
Business Intelligence (BI) users are mainly senior executives, who require a simple interface to reveal critical business information. Application designed for BI users provide a browser to eliminate the need for these users to learn a new system
Mobile Users are users whose jobs prevent them from using network-connected computers. By using a mobile interface, they can send or receive information at convenient locations. Usually, sales and inventory personnel belong to this class of users.

To self-service, business intelligence, and mobile users, forms are displayed using HTML or JavaScript. The browser is inherently capablle of handling HTML and javascript. As a result, additional downloads are not required.

An Oracle Applications Release 12 system utilizes components from many Oracle products. These product files are stored below a number of key top-level directories on the database and application server machines.
Note: No Applications files are installed on desktop client machines, although JAR files and their supporting utilities are downloaded as required.
Depending on how you chose to install Applications, these product directories may be located on a single machine (the simplest case) or on multiple machines (the most common type of deployment). Operating system environment settings indicate the location of the various files in the file systems of the database and application server machines. This chapter discusses the association between these environment settings and the corresponding files and directories.

  1. The db/apps_st/data (DATA_TOP) directory is located on the database node machine, and contains the system tablespaces, redo log files, data tablespaces, index tablespaces, and database files
  2. The db/tech_st/10.2.0 directory is located on the database node machine, and contains the ORACLE_HOME for the Oracle10g database
  3. The apps/apps_st/appl (APPL_TOP) directory contains the product directories and files for Oracle Applications
  4. The apps/apps_st/comn or (COMMON_TOP or COMN_TOP) directory contains directories and files used across products
  5. The apps/tech_st/10.1.2 directory contains the ORACLE_HOME used for the Applications technology stack tools components
  6. The apps/tech_st/10.1.3 directory contains the ORACLE_HOME used for the Applications technology stack Java components