Basic Configuration Tasks

Oracle E-Business Suite Setup Steps

Proper setup is required before a number of Oracle E-Business Suite features will operate correctly. The following steps are carried out automatically during or after installation:

  1. Run Rapid Install

  2. Test Web listener virtual directories

  3. Test Oracle HTTP Server configuration

  4. Create DBC files

  5. Test Java Servlet setup

  6. Set Web Server profile options

The above is not an inclusive list of the installation and post-installation tasks that may be needed on a particular system.

Rapid Install is the installation program. Refer to Oracle E-Business Suite Installation Guide: Using Rapid Install for detailed information on running Rapid Install.

Configuring the Login Page for Oracle E-Business Suite

Oracle E-Business Suite uses a configurable login page, which can be tailored to suit the needs of different organizations.

Oracle E-Business Suite Login page

Users log in to Oracle E-Business Suite using a client web browser. From the Oracle E-Business Suite Login page, users access the Oracle 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 E-Business Suite Login page from the following URL:

http://<server:port>/OA_HTML/AppsLogin

For example,

http://oraapps1.oracle.com:8000/OA_HTML/AppsLogin

From this URL, you will be redirected to the central login page, "AppsLocalLogin.jsp".

Central Login Page

the picture is described in the document text

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:

* 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 E-Business Suite instance is Single Sign-On enabled, the servlet directs the user to the Single Sign-On login page.

Passwords

Note that in previous releases of Oracle E-Business Suite, user passwords were treated as case insensitive. Now, Oracle E-Business Suite user passwords can optionally be treated as case sensitive, depending on the mode you choose. Case-sensitivity in passwords is controlled by the profile option Password Case Option.

Language

The current browser language, if it exists in the applications database also, is used for the login page. The user can choose a different language on the login page (if the Language Picker is enabled) and refresh the page to have it appear in that language.

If the current browser language does not exist in the Oracle E-Business Suite installation, the language set in the site-level setting of the ICX_LANGUAGE profile option is used to render the login page.

A user can override the value of the ICX_LANGUAGE profile option for a given session only.

Oracle Applications Manager

Oracle Applications Manager uses this central login page as well to authenticate users.

Customizing the Oracle E-Business Suite Login page

Customized Login Page

the picture is described in the document text

User interface features can be turned on or off using the profile option Local Login Mask (FND_SSO_LOCAL_LOGIN_MASK):

For the Login page to show one of more of these optional attributes, just add the numeric values of all desired attributes and set the value of the profile option to that value.

For example to show the Password Hint and the Forgot Password URL only, set the Local Login Mask profile option to 10 (02+08). To show just the Language Picker, set the value to 32, which is also the default value for the profile option.

The values for the Username Hint, Password Hint, Forgot Password URL text, Register URL text, and the Corporate Policy Message, as well as the Copyright text, are stored in Message Dictionary. You can update these messages using the Messages form or HTML page.

The table below lists the message names and their default values.

Login Page Message Names and Default Values
Message Name Default value
FND_SSO_HINT_USERNAME (example: michael.james.smith)
FND_SSO_HINT_PASSWORD (example: 4u99v23)
FND_SSO_FORGOT_PASSWORD Forgot your password?
FND_SSO_REGISTER_HERE Register here
FND_SSO_SARBANES_OXLEY_TEXT Corporate Policy Message
FND_SSO_COPYRIGHT_TEXT Copyright (c) 2006, Oracle. All rights reserved.

Personalizing the Oracle E-Business Suite Home Page

The Oracle E-Business Home Page can be personalized to display the Worklist and to display the Applications Navigator in "Tree" or "Flat" mode. By default, the Applications Navigator is shown in Flat mode.

Refer to the Oracle Application Framework Personalization Guide for more information on personalizing Oracle Application Framework pages. Ensure that you have the relevant profile options set appropriately.

Follow these steps to use the Tree mode:

  1. Log in to Oracle E-Business Suite with the system administrator responsibility.

  2. From the Oracle E-Business Suite Home page, select Personalize Page.

  3. Select Apply in the "Choose Personalization Context" page.

  4. Under "Personalization Structure", expand the following nodes: 'Table Layout: (topTableLayoutContainer)' > 'Row Layout: (tableLayoutRow)' > 'Cell Format: (worklistResponsibilityLeftCell)' > 'Table Layout: Home Contenttable'.

  5. Under the node 'Table Layout: Home Contenttable' > Row Layout: (responsibilityRow), click the Personalize icon.

  6. Change the value for the 'Rendered' property for the column 'Function: Applications Home Page' to 'false'. Select Apply.

  7. Click on the Personalize icon for 'Table Layout: Home Contenttable' > 'Row Layout: (appsNavTreeRow)'.

  8. Change the value for the 'Rendered' property for the column 'Function: Applications Home Page' to 'true'. Select Apply.

  9. Select Return to Application.

Administering Oracle HTTP Server

Oracle HTTP Server Powered by Apache provides the communication services within Oracle Application Server. This facilitates deployment of HTML-based applications within a multi-tiered computing environment.

Oracle HTTP Server

All incoming client requests to Oracle Internet Application Server (AS) are handled by the Communication Services component of AS. The Oracle HTTP Server, powered by Apache Web Server technology accepts and processes these requests. The Apache technology adopted by Oracle HTTP Server provides an extremely stable, scalable, and extensible platform on which to deploy web-based applications. The modular design of the Apache server allows for extension of the capabilities of the Oracle HTTP Server. In addition to the standard Apache modules (often referred to as modules, or simply mods), a number of Oracle specific modules are provided along with an extension to the functionality of several standard modules.

These modules include:

Oracle E-Business Suite Installation Guide: Using Rapid Install should be consulted for additional information on directory structures and file locations referred to in this guide.

Apache Configuration Files

Apache is configured through directives contained in one or more configuration files. The directives necessary for operating Apache within the Oracle environment will be entered into the configuration files during the install process. It should not be necessary to modify these files unless the system is being re-configured.

Warning: An invalid directive entered into a configuration file will prevent Apache from starting. An incorrect definition provided to a directive may cause Apache to behave in an unintended fashion.

Location

The Apache configuration files are installed as part of the Oracle E-Business Suite Rapid Install process. On UNIX, for example, the files will be placed in $INST_TOP/ora/10.1.3/Apache/Apache/conf.

Secure Sockets Layer Configuration

Secure Sockets Layer (SSL) allows the Apache listener to encrypt HTML pages and transmit them on the network using the HTTPS protocol for secure transmissions.

SSL uses an encrypting method called public key cryptography, where the server provides the client with a public key for encrypting information. The server's private key is required to decrypt this information. The client uses the public key to encrypt and send information to the server, including its own key which identifies it to the server.

In order for the Oracle HTTP Server, powered by Apache, to function in secure mode it is also necessary to utilize certificates which validate the server's identity. These certificates are used to ensure that the owner of a public key is who they say they are. Typically you will want to use a private key with an officially signed certificate, validated by a Certificate Authority (CA). The CA validates the company details, sets expiration dates on the certificates and may place policies on what information is contained within the certificate. A number of CAs exist, and include such authorities as Verisign, RSA, and GTE CyberTrust.

To obtain a CA approved certificate it is necessary to generate a certificate request, which includes details of the organization applying as well as the public key to be distributed, this is then sent to the CA, validated and returned. Authorities may also require proof of ownership of the company applying for the certificate, as well as proof of ownership of the domain name specified in the certificate request.

It is possible to generate a self-signed certificate that can be used to test SSL operation. Most browsers are configured to accept certificates from a number of recognized authorities. Receiving a certificate from an organization other than one of these will generate a warning, and the user will be prompted to accept or reject this certificate. A self-signed certificate will generate this warning.

Creating a self-signed certificate

The SSL module provides two utilities - Oracle Wallet Manager, and the Oracle Wallet Manager Command Line Interface (orapki) - that can be used to create a self-signed certificate for testing purposes.

Warning: Self-signed certificates are inherently insecure, and should not be used in a environment where security is required.

In order to generate a self-signed certificate, perform the steps below using the Oracle Wallet Manager Command Line Interface:

Temporary SSL Environment Setup

Follow these steps for the temporary SSL environment setup.

  1. Source your environment

    1. Log on to the application (middle) tier, as the OS user who owns the application tier files.

    2. Source your <APPL_TOP>/<SID_hostname>.env file to set your APPL_TOP variables.

    3. Navigate to the $INST_TOP/ora/10.1.3 and source the <SID_hostname>.env file to set your 10.1.3 ORACLE_HOME variables. When working with wallets and certificates, you must use the 10.1.3 executables.

  2. Create a Wallet

    1. Verify the location of the Web SSL directory:

      grep s_web_ssl_directory $CONTEXT_FILE

    2. Navigate to this directory, which will have Apache and opmn subdirectories

    3. Change to the Apache subdirectory

    4. Backup any existing wallets (demo certificates are included in Release 12)

    5. Create your new wallet:

      orapki wallet create -wallet . -auto_login -pwd <password>

      "-wallet ." (note the ".") tells orapki that you want to create the wallet in the current directory. You can also specify the full path to any directory where you wish to create a wallet.

      " -auto_login" tells orapki that you want to create cwallet.sso which is an obfuscated copy of ewallet.p12. With auto login enabled, processes submitted by the OS user who created the wallet will not need to supply the password to access the wallet.

    6. You should now see two wallet files in your directory: cwallet.sso and ewallet.p12.

  3. Add your self-signed certificate to the wallet.

    1. Enter the following command all on one line, substituting the appropriate parameters for your instance:

      orapki wallet add -wallet . -dn "CN=server.us.oracle.com,OU=Unit,O=Org,L=Orlando,ST=Florida,C=US" -keysize 1024 -self_signed -validity 3650 -pwd welcome1

    2. Your wallet is now ready for use in environments where security is not required (as mentioned in the warning note above, self-certification is by definition not secure).

Configure Apache for SSL Connections using AutoConfig

Ensure that the following parameters are correctly set in your Oracle E-Business Suite applications context file:

Variable Non-SSL Value SSL Value
s_url_protocol http https
s_local_url_protocol http https
s_webentryurlprotocol http https
s_active_webport Same as s_webport Same as s_webssl_port
s_help_web_agent URL constructed with http protocol and s_webport URL constructed with http protocol and s_webport (same as non-SSL)
s_login_page URL constructed with http protocol and s_webport URL constructed with https protocol and s_webssl_port

Run AutoConfig, either through the Oracle Applications Manager interface, or by using the adautocfg.sh script in the application tier $ADMIN_SCRIPTS_HOME directory.

Note: For more details, see My Oracle Support Knowledge Document 387859.1, Using AutoConfig to Manage System Configurations with Oracle E-Business Suite Release 12.

Test Startup of Apache and Oracle E-Business Suite Sign-On

Restart the application tier Apache services using the adapcctl.sh script in the $ADMIN_SCRIPTS_HOME directory. Ensure that Apache can startup successfully, and that you successfully get an SSL connection to the default Apache banner screen using https:/<host.domain>:<SSL_port>, where <host.domain> is the fully qualified name of the machine running Apache, and <SSL_port> is the SSL port number defined in ssl.conf.

Once you have signed on to Oracle E-Business Suite, select a responsibility and process that will launch a Forms-based application. For example, System Administrator responsibility and the Define User process.

Note: For further details of using SSL, see My Oracle Support Knowledge Document 376700.1, Enabling SSL with Oracle Application Server 10g and E-Business Suite Release 12, and Knowledge Document 376694.1, Using the Oracle Wallet Manager Command Line Interface with Oracle E-Business Suite Release 12.

AdminAppServer Utility

Important: The following details are provided for reference only. You should not need to carry out manual maintenance on dbc files, as they are managed by AutoConfig, which runs AdminAppServer automatically. See "Using AutoConfig to Manage System Configurations with Oracle E-Business Suite Release 12", Knowledge Document 387859.1, on My Oracle Support.

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.

Using the AdminAppServer Utility

The Java script AdminAppServer is used to create .dbc files and to enable or disable application server security.

Prior to running AdminAppServer you must ensure that:

For UNIX platforms, the script is run as:

java oracle.apps.fnd.security.AdminAppServer [parameters]

For Windows platforms, the script is run as:

jre -classpath %CLASSPATH% \ 
        oracle.apps.fnd.security.AdminAppServer [parameters]

The first parameter must be the connection string followed by the command string, for example:

apps/apps@dbname ADD

The following commands are supported:

Additional parameters depend on the operation. These include:

Administering .dbc Files

The .dbc file is contained on the web/applications server and holds information used by the database for authentication. The web/application server passes the information from the .dbc file, as well as login information, to the database server to authenticate the user. The authentication process is handled by the standard applications security feature.

The .dbc files required by the application server security system are not part of the delivered product and must be created after installation.

The Java utility AdminAppServer is used to create the .dbc files.

Prior to running AdminAppServer you must ensure that:

Creating a .dbc file

Use the AdminAppServer utility to create a .dbc file for the application server to access the database server. In addition to creating the .dbc file this utility registers the application server with the database for the Applications Server Security feature.

To access additional database servers from the same application server, you must rerun the AdminAppServer utility for each additional database. You must run the AdminAppServer utility each time you create a .dbc file, and each .dbc file only allows access to one database.

To create a .dbc file for an application server:

  1. You must set the username/password value for the GUEST_USER_PWD parameter. Create a valid username ("guest" for example) in Oracle E-Business Suite. Then use the username/password combination as the value for GUEST_USER_PWD. The syntax is illustrated in the following example:

    GUEST_USER_PWD=guest/guest

    Oracle recommends that you do not assign any responsibilities for this user.

  2. From the command line, enter the appropriate command for your platform:

    For UNIX platforms:

    java oracle.apps.fnd.security.AdminAppServer apps/apps@dbname \
        ADD DB_HOST=database_host_name DB_PORT=database_port \ 
        DB_NAME=database_sid \
        [env_name=env_value] SECURE_PATH=$FND_TOP/secure

    For Windows platforms:

    jre -classpath %CLASSPATH% \ 
        oracle.apps.fnd.security.AdminAppServer apps/apps@dbname \
        ADD DB_HOST=database_host_name DB_PORT=database_port \ 
        DB_NAME=database_sid \
        [env_name=env_value] SECURE_PATH=$FND_TOP/secure

GWYUID, FNDNAM, and GUEST_USER_PWD will be defaulted if not provided explicitly. dbc files should be located in $FND_TOP/secure, so SECURE_PATH should always be set to that, or this should be run directly out of of the $FND_TOP/secure area.

Updating a .dbc file (or Server ID)

When updating the .dbc file you can change as many parameters as you want, including the server ID, but you must enter at least one. Settings that you do not update retain their value.

To update a .dbc file or server ID:

Enter from the command line:

UNIX

java oracle.apps.fnd.security.AdminAppServer apps/apps@dbname \ UPDATE DBC=$FND_TOP/secure/file.dbc APPL_SERVER_ID \ [env_name=env_value]

Windows

jre -classpath %CLASSPATH% \ oracle.apps.fnd.security.AdminAppServer apps/apps@dbname \ UPDATE DBC=$FND_TOP/secure/file.dbc APPL_SERVER_ID \ [env_name=env_value]

If APPL_SERVER_ID is not passed, AdminAppServer will attempt to synchronize the current server ID value in the .dbc file and the database, generating a new one if neither contains a value at all. Passing in APPL_SERVER_ID by itself will force a brand new application server ID to be created always, overwriting any existing one.

Deleting a .dbc file

To delete a .dbc file, enter on the command line:

UNIX

java oracle.apps.fnd.security.AdminAppServer apps/apps@dbname \ DELETE DBC=$FND_TOP/secure/file.dbc

Windows

jre -classpath %CLASSPATH% \ oracle.apps.fnd.security.AdminAppServer apps/apps@dbname \ DELETE DBC=$FND_TOP/secure/file.dbc

This deletes the .dbc file and disallows access to the indicated database if Server Security is active.

Troubleshooting

The following are possible problems you may encounter and suggested solutions.

Administering Server Security

Oracle E-Business Suite is deployed in a multi-tier configuration with one database server and many possible middle-tier application servers. The application servers include Apache JSP/Servlet, Forms, Discoverer and also some client programs such as Application Desktop Integrator. Any program which makes a SQL*Net connection to the Oracle E-Business Suite database needs to be trusted at some level. Oracle E-Business Suite uses the Server Security feature to ensure that such SQL*Net connections are coming from trusted machines and/or trusted programs.

The Server Security feature of Oracle Application Object Library supports authentication of application server machines and code modules in order to access the database. When Server Security is activated, application servers are required to supply server IDs (like passwords) and/or code IDs to access a database server. Server IDs identify the machine from which the connection is originating. Code IDs identify the module and patch level from which the connection is originating. Code IDs are included in applications code by development. The database server can be set to allow access only from specific machines and/or by code at a desired patch level.

The application server security feature is not initially activated. You should activate it by using the commands described in this section.

Application Server Security can be in one of three states:

Server Security Status

You can check the Server Security status for a particular database using the STATUS command in the AdminAppServer utility, and providing the dbc file corresponding to that database. The STATUS command will display whether server security is turned on and whether the server ID in the dbc file is currently valid.

To check the Server Security status for a database:

On UNIX:

java oracle.apps.fnd.security.AdminAppServer apps/apps \
     STATUS DBC=<dbc file path>

On Windows:

jre –classpath %CLASSPATH% \
     oracle.apps.fnd.security.AdminAppServer apps/apps \
     STATUS DBC=<dbc file path>

Important: Check the Server Security status of your databases before you activate server security and ensure that all desired application servers have been registered.

Adding, Updating, or Deleting Server IDs

Application servers can be registered as trusted machines with a database server. This works by generating a large random ID number and storing that in both the application server and the database. When the application server attempts to connect to the database it will supply its server ID and the database will verify that it matches a trusted machine. The server ID is stored as a parameter in the DBC file for each application server. It can also be defined as an environment variable. The AdminAppServer utility is used to generate server IDs and then register them with a database server.

To add a server ID

Server ID values are generated by the AdminAppServer utility, and therefore cannot be supplied on the command line. They will be added to the database automatically when the AdminAppServer is used to create a dbc file.

On UNIX:

java oracle.apps.fnd.security.AdminAppServer apps/apps \
ADD [SECURE_PATH=$FND_TOP/secure] \
DB_HOST=<database host> \
DB_PORT=<database port> \
DB_NAME=<database sid>

On Windows:

jre –classpath %CLASSPATH \
oracle.apps.fnd.security.AdminAppServer apps/apps \
ADD [SECURE_PATH=$FND_TOP/secure] \
DB_HOST=<database host> \
DB_PORT=<database port> \
DB_NAME=<database sid>

To update a server ID

You can update an application server's server ID at any time. From the command line enter:

On UNIX:

java oracle.apps.fnd.security.AdminAppServer apps/apps \
UPDATE DBC= <dbc file path> APPL_SERVER_ID

On Windows:

jre –classpath %CLASSPATH% \
oracle.apps.fnd.security.AdminAppServer apps/apps \
UPDATE DBC=

By providing the APPL_SERVER_ID argument, you will force a new server ID to be generated and added to your DBC file. If the APPL_SERVER_ID argument is not provided, AdminAppServer will take care of syncing up the server ID's of your dbc file and your database automatically, if required.

To delete a server ID

Server IDs can be deleted. This must be done using the AdminAppServer utility as follows:

On UNIX:

java oracle.apps.fnd.security.AdminAppServer apps/apps \
DELETE DBC= <dbc file path> APPL_SERVER_ID

On Windows:

jre –classpath %CLASSPATH% \
oracle.apps.fnd.security.AdminAppServer apps/apps \
DELETE DBC=

Activating Server Security

You can turn the server security feature to OFF, ON, or SECURE mode using the AdminAppServer utility. When you turn off server security, you will not change or delete your server IDs. You can re-enable server security without having to recreate server IDs for existing registered application servers.

On UNIX:

To activate basic server security on UNIX, enter on the command line:

 java oracle.apps.fnd.security.AdminAppServer apps/apps \
    AUTHENTICATION ON DBC=<dbc file path>

To activate full server security (SECURE mode) on UNIX, enter:

 java oracle.apps.fnd.security.AdminAppServer apps/apps \
    AUTHENTICATION SECURE DBC=<dbc file path>

To deactivate server security on UNIX, enter:

 java oracle.apps.fnd.security.AdminAppServer apps/apps \
    AUTHENTICATION OFF DBC=<dbc file path>

On Windows:

jre -classpath %CLASSPATH% \ 
 oracle.apps.fnd.security.AdminAppServer apps/apps \
 AUTHENTICATION ON DBC=<dbc file path>

To activate full server security (SECURE mode), from the command line, enter:

jre -classpath %CLASSPATH% \ 
    oracle.apps.fnd.security.AdminAppServer apps/apps \
    AUTHENTICATION SECURE DBC=<dbc file path>

To deactivate server security, from the command line, enter:

 jre -classpath %CLASSPATH% \ 
    oracle.apps.fnd.security.AdminAppServer apps/apps \
    AUTHENTICATION OFF DBC=<dbc file path>

Restricting Access to Responsibilities Based on User's Web Server

Oracle E-Business Suite 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.

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 E-Business Suite 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.

Oracle Application Object Library AOL/J Setup Test Suite

The AOL/J Setup Test Suite consists of Java Server Pages (JSPs) and can be used to diagnose AOL/J setup issues. These JSPs exercise various features of AOL/J and provide feedback on the results. The test suite is accessed from the URL:

 http://<host_name>:<port_number>/OA_HTML/jsp/fnd/aoljtest.jsp

where host_name and port_number correspond to the host name and port number of your instance's Apache listener. The host name and port number values are normally found in the APPS_SERVLET_AGENT profile option.

When you access the test suite, you will be asked to provide login information for your instance:

The following is a list of functions and tests you can run with your instance.

An optional and recommended alternative to AOL/J is the Oracle Universal Connection Pool (UCP ) for JDBC.

Note: For further details, refer to My Oracle Support Knowledge Document 1077727.1, Using Universal Connection Pool (UCP) in Oracle E-Business Suite Release 12.1.3.

Using Oracle Application Framework

Oracle Application Framework is an Oracle E-Business Suite development and deployment platform. It is a 100% Java and XML, middle-tier application framework and services for the rapid development and deployment of HTML based applications.

For information on Oracle Application Framework, see My Oracle Support Knowledge Document 1087332.1, Oracle Application Framework Release Notes, Release 12.1.3.

The following user interface features are enabled by default but can be disabled via the profile options listed in the table below.

Note: See the Oracle E-Business Suite User's Guide for additional information on these features.

Feature Profile Option Profile Option Values Default Value on Site Level
Configurable Homepage FND: Disable Configurable Home Page True, False False
Slideout Menu for Navigator and Favorites FND: Disable Navigator and Favorites Rich Menu True, False False
Inline Attachments FND: Disable Inline Attachments True, False False
Look-ahead LOV FND: Disable Look Ahead LOV True, False False

Note: The profile Enable Configurable Homepage (FND_CONFIG_HOMEPAGE_ENABLED) is retained for backward compatibility with Release 12.1.2.

Note: To disable the feature, the profile values should be set as follows:

The profile FND Slideout Menu is retained for backward compatibility on Release 12.1.2.

Note: Inline Attachments can only be enabled if the accessibility mode is set to None using the profile option Self Service Accessibility Features. Inline Attachments are disabled if accessibility is set to "Screen Reader Optimized" mode or "Standard Accessibility" mode. See the Oracle E-Business Suite User's Guide for more information on accessibility.

AutoConfig and Oracle Applications Manager

Oracle Applications Manager (OAM) provides access to the AutoConfig configuration management tool via the AutoConfig tab in the Site Manager screen. Previous configuration settings can easily be compared with the current settings, allowing changed settings to be identified and rolled back as necessary. The configuration editor also helps you add custom variables to the context files, to allow AutoConfig and AutoPatch to preserve your system configuration customizations.

For more information on AutoConfig, see: "Using AutoConfig to Manage System Configurations with Oracle E-Business Suite Release 12", Knowledge Document 387859.1, on My Oracle Support.

For more information on Oracle Applications Manager, see: Introduction to Oracle Applications Manager.

From the Oracle Applications Manager Site Map, AutoConfig is on the Administration tab under the System Configuration heading. Click on the AutoConfig link to go to the tool's home page.

From the AutoConfig home page, you can view details of a context file by clicking Show. For example, you can see Version, Path, Creation Date. Last Updated By, Status (for example, Write succeeded), and Comments.

You can select a context file and choose Edit Parameters. This is the only supported way to modify parameters that AutoConfig maintains: if you edit any context files manually, they will be overwritten the next time AutoConfig is run.

Under Edit Parameters, choosing the Local tab will open a screen that shows environment-related details, including local host machine name, virtual hostname (used to connect), local domain name, and platform type.

You can select a context file and click on Show History, to see details of any previous configurations.

The Custom tab under Edit Parameters allows you to add a new context variable (not maintained by AutoConfig) to the context file. This is the only supported way to add customizations.

Related Topics

Configuration Overview