Skip Headers

Oracle E-Business Suite Maintenance Guide
Release 12.2
Part Number E22954-15
Go to Table of Contents
Contents
Go to previous page
Previous
Go to next page
Next

Basic DBA Tasks

Overview of Oracle E-Business Suite DBA Duties

Oracle E-Business Suite database administration (DBA) combines the efforts of an Oracle E-Business Suite System Administrator and an ORACLE database administrator.

ORACLE Schemas

Upon installation of Oracle E-Business Suite, a number of schemas (sometimes called ORACLE schemas) are present in the database. You do not need to create these schemas; however, you should change the default passwords. For information on changing passwords, see: Oracle E-Business Suite Password Management.

These schemas come from different sources and can by described as being of the following types:

  1. Schemas that exist in every Oracle database (whether used by Oracle E-Business Suite or not) [for example, SYS, SYSTEM].

  2. A small set of schemas used by shared components of Oracle E-Business Suite (for example, APPLSYSPUB, APPLSYS, APPS).

  3. A large set of schemas provided by the individual products of Oracle E-Business Suite (for example, ABM, AHL,..., ZSA, ZX).

  4. A set of schemas that belong to optional database features or third party products these fall into three subtypes:

    1. Used by and patched with Oracle E-Business Suite (for example, CTXSYS).

    2. Used by Oracle E-Business Suite but patched only with the RDBMS (for example, MDSYS, ORDSYS).

    3. Not used by Oracle E-Business Suite (for example, SCOTT).

At no time do any of the schemas provided with Oracle E-Business Suite relate to a particular Oracle E-Business Suite user.

All types of schemas are used during runtime operations of Oracle E-Business Suite and the schemas of type 2, 3 & 4.1 are accessed during initial installation and patching.

For schema passwords, Oracle E-Business Suite concerns itself with mainly three passwords for its schemas:

  1. A password for APPLSYSPUB (also known as the GATEWAY user). The default password is 'PUB'.

  2. A password shared between APPLSYS, APPS, and APPS_NE. The default password is 'APPS'.

  3. A password for all of the product-specific base schemas (type 3). The default password for these schemas is same as the schema name.

Important: You should change these passwords upon installation.

Note that the Oracle database schemas and passwords connect to the ORACLE database, while application usernames and passwords access Oracle E-Business Suite.

Registering an ORACLE Schema

The installation process automatically registers Oracle E-Business Suite ORACLE schemas.

You must register an ORACLE schema with Oracle E-Business Suite if you create a custom application using Oracle Application Object Library. See: My Oracle Support Knowledge Document 1577707.1, "Creating a Custom Application in Oracle E-Business Suite Release 12.2."

Reregistering ORACLE schemas

You should also reregister ORACLE schemas associated with custom applications built using Oracle Application Object Library each time you upgrade Oracle Application Object Library.

Initialization Code

You can add in custom initialization SQL code to be executed when a database session starts up or when it is re-initialized. You specify this code using a profile option.

The code is executed by FND_GLOBAL.INITIALIZE and APPS_INITIALIZE immediately after initializing global variables, profiles, and the contents of client_info on session startup.

Profile Option Initialization SQL Statement - Custom

Using the profile option Initialization SQL Statement - Custom, you can add site-specific initialization code, such as optimizer settings. This profile value must be a valid SQL statement, or a PL/SQL block for more than one statement, that is to be executed once at the startup of every database session.

This profile option can be set at any level by the System Administrator, and is reserved for use by customers.

Profile Option Initialization SQL Statement - Oracle

This profile option is used by Oracle E-Business Suite. This profile option and its value settings are delivered as seed data, and must not be modified.

Resource Consumer Groups in Oracle E-Business Suite

The Database Resource Manager introduced in Oracle8i is used to allocate and manage resources among database users and applications.

Resource consumer groups and resource plans provide a method for specifying how to partition processing resources among different users. A resource consumer group defines a set of users who have similar resource usage requirements. An overall resource plan specifies how resources are distributed among the different resource consumer groups.

Oracle E-Business Suite allows the system administrator to assign individual Oracle E-Business Suite users to resource consumer groups. In addition, concurrent programs and concurrent managers can be assigned to resource consumer groups.

Note: These resource consumer groups apply to CPU resources only.

For additional information, see the Oracle database documentation.

Assigning Resource Consumer Groups

The system administrator can assign a user to a resource consumer group by setting the value of the user profile option FND:Resource Consumer Group for that particular user. The user can see this profile option but cannot update it.

The system administrator can assign a concurrent program to a resource consumer group in the Parameters window of the Define Concurrent Program form. See: Concurrent Programs Parameters Window, Oracle E-Business Suite Setup Guide.

The system administrator can assign a concurrent manager to a resource consumer group in the Define Concurrent Manager form. See: Concurrent Managers Window, Oracle E-Business Suite Setup Guide.

Hierarchy of Resource Consumer Group Assignments

Conflicts can arise between the resource consumer groups associated with a single session. For example, a concurrent manager assigned to one resource consumer group may run a concurrent program assigned to another. A similar situation arises when a user performs a transaction managed by a transaction manager that has a different resource consumer group than the user. To resolve such conflicts, Oracle E-Business Suite uses a hierarchy.

In the case of a concurrent program, the system first checks to see if the program has an assigned resource consumer group and if so, uses that. If not, the system checks the concurrent manager running the program and uses its resource consumer group. If the concurrent manager is not assigned to a resource consumer group the system uses the default group "Default_Consumer_Group".

In the case of a transaction manager running a transaction program, the system once again checks the resource consumer group assigned to the program, if any, and if there is none, checks the transaction manager. If the transaction manager has no assigned resource consumer group the system then checks the profile option value for the user whose session began the transaction. If there is no resource consumer group defined the system uses the default resource consumer group.

For a user running a form, the system first checks the profile option value for that user and uses that if it is defined. Otherwise the system uses the default resource consumer group.

Oracle E-Business Suite Password Management

Oracle E-Business Suite provides two command line utilities, FNDCPASS and AFPASSWD, for setting Oracle E-Business Suite schema passwords. These utilities change the password registered in Oracle E-Business Suite tables and the schema password in the database. The utilities can also be used to change user passwords.

Several important considerations apply:

Oracle E-Business Suite releases that use an Oracle 11g database can optionally employ case-sensitive database passwords, allowing mixed case to be used. For further details on utilizing this feature, refer to My Oracle Support Knowledge Document 1581584.1, Enabling the Oracle Database 11g Case-Sensitive Password Feature for Oracle E-Business Suite Release 12.1.1.

In Oracle E-Business Suite Release 12.2.3 and higher, you can also use the AFPASSWD utility to migrate Oracle E-Business Suite user passwords to a non-reversible hash password scheme.

FNDCPASS Utility

Important: Although still supported, FNDCPASS is a legacy tool. Oracle recommends all customers to make the transition to its successor, AFPASSWD, as soon as they can.

The FNDCPASS utility can be used to change various types of passwords.

Note: You should always run AutoConfig after changing any system (type 2) password.

To change the APPS, APPLSYS, and APPS_NE (type 2) schema password:

Use this command to change passwords for schemas that are used by shared components of Oracle E-Business Suite.

FNDCPASS <logon> 0 Y <SYSTEM username>/<SYSTEM password>  SYSTEM \ 
	<username> <new_password> 

Use the above command with the following arguments. When specifying the SYSTEM token, FNDCPASS expects the next arguments to be the APPLSYS username and the new password.

Variable Description
logon The Oracle username.

Note: You can provide just the Oracle username, and FNDCPASS will prompt you for the password. Alternatively you can provide the <username>/<password> pair.

system/password The username and password for the SYSTEM DBA account.
username The APPLSYS username. For example, 'applsys'.
new_password The new password.

This command does the following:

  1. Verifies the current APPLSYS password.

  2. Re-registers password in Oracle E-Business Suite.

  3. Changes the APPLSYS, APPS_NE, and all APPS passwords (for multi-APPS schema installations) to the same password.

  4. ALTER USER is executed to change the ORACLE password for the above ORACLE users.

For example, the following command changes the APPLSYS password to 'WELCOME'.

FNDCPASS <APPS username> 0 Y <SYSTEM username>/<SYSTEM password> SYSTEM APPLSYS WELCOME

After changing the APPLSYS password, you must also perform the steps listed in Important Additional Instructions to Update WLS Datasource

To change an Oracle E-Business Suite schema password (type 3) (other than APPS/APPLSYS/APPS_NE):

Use this command to change the password of a schema provided by an individual product in Oracle E-Business Suite.

FNDCPASS <logon> 0 Y <SYSTEM username>/<SYSTEM password> ORACLE \ 
	<username> <new_password> 

Use the above command with the following arguments. When specifying the ORACLE token, FNDCPASS expects the next arguments to be an ORACLE username and the new password.

Variable Description
logon The Oracle username.

Note: You can provide just the Oracle username, and the system will prompt you for the password. Alternatively you can provide the <username>/<password> pair.

<SYSTEM username>/<SYSTEM password> The username and password for the SYSTEM DBA account.
username The Oracle username. For example, 'GL'.
new_password The new password.

For example, the following command changes the GL user password to 'GL1'.

FNDCPASS <APPS username> 0 Y <SYSTEM username>/<SYSTEM password> ORACLE GL GL1

Note: The system prompts the user for the APPS password in the above example.

To change all ORACLE (type 3) schema passwords:

Use this command to change the passwords of all schemas provided by Oracle Application products that are registered as base product schemas in the FND_ORACLE_USERID table.

FNDCPASS <logon> 0 Y <SYSTEM username>/<SYSTEM password> ALLORACLE \ 
 <new_password> 

Use the above command with the following arguments. When specifying the ALLORACLE token, FNDCPASS expects the next argument to be the new password.

Variable Description
logon The Oracle username.

Note: You can provide just the Oracle username, and the system will prompt you for the password. Alternatively you can provide the <username>/<password> pair.

<SYSTEM username>/<SYSTEM password> The username and password for the SYSTEM DBA account.
new_password The new password.

For example, the following command changes all ORACLE schema passwords to "WELCOME":

FNDCPASS <APPS username> 0 Y <SYSTEM username>/<SYSTEM password> ALLORACLE WELCOME

Note: The system prompts the user for the APPS password in the above example.

To change an Oracle E-Business Suite user's password:

You can use this command to change an individual Oracle E-Business Suite user's password.

FNDCPASS <logon> 0 Y <SYSTEM username>/<SYSTEM password> USER \ 
	<username> <new_password> 

Use the above command with the following arguments. When specifying the USER token, FNDCPASS expects the next arguments to be an Oracle E-Business Suite username and the new password.

Variable Description
logon The Oracle username.

Note: You can provide just the Oracle username, and the system will prompt you for the password. Alternatively you can provide the <username>/<password> pair.

<SYSTEM username>/<SYSTEM password> The username and password for the System DBA account.
username The Oracle E-Business Suite username. For example, 'VISION'.
new_password The new password.

For example, if you were changing the password for the user VISION to 'WELCOME', you would use the following command:

FNDCPASS <APPS username> 0 Y <SYSTEM username>/<SYSTEM password> USER VISION WELCOME

Note: The system prompts the user for the APPS password in the above example.

FNDCPASS prompting for password if not provided

FNDCPASS prompts the user for the APPS user password if it is not given on the command line.

Here is an example in which the APPS password provided on the command line:

FNDCPASS APPS/APPS 0 Y <SYSTEM username>/<SYSTEM password> USER operations welcome

You can choose not to give the APPS password in the same command, as in the following example.

FNDCPASS APPS 0 Y <SYSTEM username>/<SYSTEM password> USER operations welcome 
ORACLE Password: 

Here the APPS password is not provided on the command line, but instead you are prompted for it.

FNDCPASS Example

The following is an example of using the FNDCPASS utility to change the password, where <username> is the Oracle schema name.

FNDCPASS <APPS username>/<APPS password> 0 Y \
<SYSTEM username>/<SYSTEM password> \
ORACLE <username> <new_password> 

Changing the APPLSYS, APPS, and APPS_NE passwords is a special case. Here, all application tier services must first be shut down using the command $INST_TOP/admin/scripts/adstpall.sh. In the command, ORACLE must be replaced with SYSTEM: SYSTEM mode changes the APPS and APPS_NE passwords as well as the APPLSYS password, and thereby keeps them all synchronized.

Note: FNDCPASS requires the next argument after SYSTEM to be the APPLSYS username.

FNDCPASS <APPS username>/<APPS password> 0 Y \
<SYSTEM username>/<SYSTEM password> \
SYSTEM APPLSYS <new_password>

You will then need to run AutoConfig (adautocfg.sh) using <new_password> as the APPS password, and finally restart application tier services using the command $INST_TOP/admin/scripts/adstrtal.sh.

Tip: For assistance in resolving any issues, refer to My Oracle Support Knowledge Document 1306938.1, FNDCPASS Troubleshooting Guide For Login and Changing Applications Passwords .

AFPASSWD Utility

AFPASSWD is an enhanced version of FNDCPASS, and includes the following features:

FNDCPASS will continue to be shipped with Oracle E-Business Suite for use in changing passwords, and customers can switch to the AFPASSWD utility for this purpose at their discretion. However, note that as of Release 12.2.3, the USERMIGRATE mode of FNDCPASS described in My Oracle Support Document 457166.1, FNDCPASS Utility New Feature: Enhance Security With Non-Reversible Hash Password is deprecated. You should now use AFPASSWD to migrate to a password hashing scheme.

Note: You should always run AutoConfig after changing any system (type 2) password.

AFPASSWD Usage

The AFPASSWD command is used with the relevant command line options to perform the desired action.

AFPASSWD [-c <APPSUSER>[@<TWO_TASK>]] -f <FNDUSER>

AFPASSWD [-c <APPSUSER>[@<TWO_TASK>]] -o <DBUSER>

AFPASSWD [-c <APPSUSER>[@<TWO_TASK>]] -a

AFPASSWD [-c <APPSUSER>[@<TWO_TASK>]] -l <ORACLEUSER> {TRUE|FALSE}

AFPASSWD [-c <APPSUSER>[@<TWO_TASK>]] -L {TRUE|FALSE}

AFPASSWD [-c <APPSUSER>[@<TWO_TASK>]] -s <APPLSYS>

AFPASSWD [-c <APPSUSER>[@<TWO_TASK>]] -h

These options have the following functions:

Important Additional Instructions to Update WLS Datasource

Whenever you use FNDCPASS or AFPASSWD in SYSTEM mode to change the APPS or APPLSYS schema passwords, you must also perform the actions listed below.

Note: Using SYSTEM mode with either APPLSYS or APPS will simultaneously update both the APPLSYS and APPS schemas: the respective passwords are kept in sync by both FNDCPASS and AFPASSWD.

Important: These steps must be carried out on the run file system.

  1. Shut down the application tier services using the $INST_TOP/admin/scripts/adstpall.sh script.

  2. Change the APPLSYS password, as described for the utility you are using.

  3. Start AdminServer using the $INST_TOP/admin/scripts/adadminsrvctl.sh script. Do not start any other application tier services.

  4. Change the "apps" password in WLS Datasource as follows:

    1. Log in to WLS Administration Console.

    2. Click Lock & Edit in Change Center.

    3. In the Domain Structure tree, expand Services, then select Data Sources.

    4. On the "Summary of JDBC Data Sources" page, select EBSDataSource.

    5. On the "Settings for EBSDataSource" page, select the Connection Pool tab.

    6. Enter the new password in the "Password" field.

    7. Enter the new password in the "Confirm Password" field.

    8. Click Save.

    9. Click Activate Changes in Change Center.

    Note: Where an Oracle E-Business Suite instance is integrated with Edge Applications such as Oracle AccessGate or E-Kanban, in addition to EBSDataSource the WLS domain will also have a datasource with the name OAEADataSource. In such a case, the password for both datasources should be modified.

  5. Start all the application tier services using the $INST_TOP/admin/scripts/adstrtal.sh script.

  6. Verify the WLS Datasource changes as follows:

    1. Log in to WLS Administration Console.

    2. In the Domain Structure tree, expand Services, then select Data Sources.

    3. On the "Summary of JDBC Data Sources" page, select EBSDataSource.

    4. On the "Settings for EBSDataSource" page, select Monitoring > Testing.

    5. Select "oacore_server1".

    6. Click Test DataSource

    7. Look for the message "Test of EBSDataSource on server oacore_server1 was successful".

Important: Steps 4, 5 and 6 are only applicable when changing the APPLSYS password. They are not applicable when changing passwords for product schemas or the SYSTEM schema.

In the next prepare phase after the password change, adop will invoke EBS Domain Configuration to ensure that the WLS datasource on the patch file system will be synchronized with the new APPS password.

Using AFPASSWD to Migrate to a Password Hashing Scheme

You can optionally use AFPASSWD to migrate Oracle E-Business Suite user passwords to a password hashing scheme. The migration converts the passwords for local Oracle E-Business Suite users (that is, users stored in the FND_USER table) from their current encryption to a non-reversible password hashing scheme, thus making the passwords non-recoverable. This feature provides additional protections against brute forcing of hashes in case the password hashes in the database are compromised. You can select SHA2 algorithms (SHA256, SHA384, and SHA512) defined by NIST FIPS 180-4 which are combined internally with the use of the PBKDF2 derivation function as defined by NIST 800-132 to make calculating the hashes computationally more difficult.

Note: The option to migrate to the SHA hash mode is deprecated in Release 12.2.3 and higher. You should now migrate only to SHA256, SHA384, or SHA512. However, if you previously migrated to the SHA hash mode, you can use AFPASSWD to perform another migration to one of the advanced hash modes.

Migration to a password hashing scheme is a one-way operation that cannot be undone without a system restore from backup. This migration is optional and is not implemented unless you manually execute it to take advantage of this feature. Oracle recommends that you do implement an advanced password hashing scheme to enhance Oracle E-Business Suite user password security.

Using an advanced hash algorithm adds a small delay to the login process for users due to the additional computation. Oracle recommends that you use advanced password hashing with the strongest SHA2 algorithm that provides acceptable login performance.

Note: The AFPASSWD migration option does not affect existing password schemes for the following types of users:

Before migrating, back up your Oracle E-Business Suite instance so that you can restore it from the backup if necessary.

Also, before migrating, verify that you have upgraded all desktop clients to a version supported with Release 12.2 to ensure that these clients can continue to connect to your Oracle E-Business Suite instance. These clients include the following:

Note: If you plan to export Oracle E-Business Suite users for bulk loading into Oracle Internet Directory, you should perform the export and bulk load before you migrate Oracle E-Business Suite user passwords to a password hashing scheme. After you implement password hashing, the AppsUserExport utility can no longer include the passwords when exporting Oracle E-Business Suite user information. See: Migrating Data between Oracle E-Business Suite and Oracle Internet Directory, Oracle E-Business Suite Security Guide.

To migrate Oracle E-Business Suite user passwords to a password hashing scheme, specify the AFPASSWD command with the following options.

AFPASSWD [-c <APPSUSER>[@<TWO_TASK>]] -m <HASH_MODE> {FULL|BACKGROUND|PARTIAL}

The AFPASSWD log file is written to the directory where AFPASSWD was executed. You should review this log file to verify the status of the migration.

Note: After you have migrated to a password hashing scheme, you may encounter an issue when using the expdp database export utility in which the FND_USER_PREFERENCES table is not properly exported. As a workaround to resolve this issue, you can re-export and re-import the FND_USER_PREFERENCES table separately using the exp and imp utilities, after initially running expdp and impdp.

  1. Immediately after running expdp and impdp, use the exp utility to export the FND_USER_PREFERENCES table from the source database with the following command:

    exp TABLES=(<APPLSYS SCHEMA NAME>.FND_USER_PREFERENCES) COMPRESS=Y DIRECT=Y

    For example:

    exp TABLES=(APPLSYS.FND_USER_PREFERENCES) COMPRESS=Y DIRECT=Y

    When prompted, enter the user to run the utility, such as SYSTEM, and the password for that user.

  2. Then import this data into the target database using the following command:

    imp FILE=expdat.dmp LOG=imptab.log TABLES=FND_USER_PREFERENCES FROMUSER=<APPLSYS SCHEMA NAME> IGNORE=Y
    

    For example:

    imp FILE=expdat.dmp LOG=imptab.log TABLES=FND_USER_PREFERENCES FROMUSER=APPLSYS IGNORE=Y

    When prompted, enter the user to run the utility, such as SYSTEM, and the password for that user.

Using Case-Sensitive Database Passwords

To help meet increasing and often mandatory requirements for complex passwords, Oracle E-Business Suite now supports the use of Oracle Database 11g case-sensitive passwords. This is in contrast to the traditional Oracle Application Library behavior of storing and validating all database passwords as uppercase, regardless of the case in which they are entered.

Case-sensitive database passwords can be employed with any Oracle E-Business release that uses an Oracle 11g database. Using mixed case enables more secure application schema passwords to be specified.

Overview

There are two possible situations:

Case sensitivity disabled (default) - For new database accounts or changed database passwords, Oracle automatically records the case in which the password was originally specified and stores it as a hash value in the data dictionary table that holds user information. However, new or changed database account passwords will continue to be case-insensitive unless and until the mixed-case feature is explicitly enabled.

Case sensitivity enabled - After the feature is enabled, database passwords created or changed since the upgrade to Oracle 11g will need to be entered in the case specified originally. Only database passwords that remain unchanged in the Oracle 11g database will continue to be case-insensitive. The database stores a case-sensitive version of the password created or changed in Oracle 11g, whether the mixed-case feature is enabled or not. The case-sensitive version of the password is therefore ready for immediate use as soon as the feature is enabled.

The case sensitivity capability for Oracle E-Business Suite database passwords is analogous to the way the SIGNON_PASSWORD_CASE profile is used to determine how new or changed Oracle E-Business Suite user passwords will be stored.

Enabling Case-Sensitive Database Passwords

Case sensitivity is controlled by the setting of the Oracle 11g database initialization parameter SEC_CASE_SENSITIVE_LOGON. The default for Oracle E-Business Suite databases is FALSE, which means that new, existing (pre-11g), and changed database passwords will all remain case-insensitive.

The case sensitivity feature is enabled as follows:

  1. Set the Oracle 11g Database initialization parameter SEC_CASE_SENSITIVE_LOGON to TRUE.

    Note: The default for Oracle E-Business Suite databases is FALSE, which means that new, existing (pre-11g), and changed database passwords will remain case-insensitive.

  2. Shut down and restart the database. New and changed database passwords will now be case-sensitive, with the case of the password being preserved as it was entered.

    Bear in mind the following important points:

  3. After password case sensitivity has been enabled, a DBA should immediately change the passwords of administrative accounts such as SYS and SYSTEM, and may also wish to employ a password management policy (profile) to ensure system administrators change the Oracle E-Business Suite database passwords within a reasonable time.

If for some reason password case sensitivity needs to be disabled once again, this can be done by setting SEC_CASE_SENSITIVE_LOGON = FALSE and shutting down and restarting the database.

Warning: In such a case, all Oracle E-Business Suite database passwords (stored in the FND_ORACLE_USERID table) must be reset, or database authentication will fail. Disabling password case sensitivity is therefore not recommended.

Additional Considerations for Oracle E-Business Suite DBAs

Be aware of the following points:

ORACLE Users Window

An ORACLE username grants access privileges to the ORACLE database.

This section is provided for reference use only. Beginning with Release 12.2, the ORACLE Users window should not be used. For information on creating custom applications and related ORACLE users, see: AD Splicer, Oracle E-Business Suite Setup Guide and My Oracle Support Knowledge Document 1577707.1, "Creating a Custom Application in Oracle E-Business Suite Release 12.2." For information on changing passwords for ORACLE users, see: Oracle E-Business Suite Password Management.

The installation process always registers your ORACLE username, and additional ORACLE usernames are needed only for custom applications using Oracle Application Object Library. See My Oracle Support Knowledge Document 1577707.1, "Creating a Custom Application in Oracle E-Business Suite Release 12.2," for more information.

Before an ORACLE username is registered, the ORACLE username should be created (this function is usually performed by a database administrator). The ORACLE username must include the create session privilege.

If you register an ORACLE username as a “restricted" ORACLE username, you submit a concurrent request to set up read-only privileges to the Oracle Application Object Library tables. An “enabled" ORACLE username has all privileges to those tables. A “disabled" ORACLE username has no privileges to those tables.

If you do not register and enable your ORACLE username or if you disable a registered ORACLE username, your user cannot use Oracle Application Object Library features such as menus and flexfields.

You should not change the registration of any ORACLE usernames that the installation process registers, other than changing the passwords.

If you are registering a change to an existing ORACLE password, make the password change in the database immediately AFTER you register the password change in Oracle E-Business Suite. Until you register the password changes in Oracle E-Business Suite and implement them in the database, responsibilities using this ORACLE username cannot connect to the database.

Your password must follow the guidelines for creating passwords discussed in the Oracle database documentation. Remember that if you use non-character values in your password, you may need to use quotation marks around your password when changing it in the database.

Note: Use a password management utility described in Oracle E-Business Suite Password Management to change the password, not the ORACLE Users window.

Warning: If you are changing the password to the applsys ORACLE username, which contains the Oracle Application Object Library tables, you must not change the passwords to any other ORACLE usernames at the same time.

As soon as you change and save the password, you should immediately log out of the Oracle E-Business Suite, make the applsys password change in the database, and then sign on again before you do anything else. You should also ensure that no other users are logged on to the Oracle E-Business Suite while you are changing the applsys password.

Important: For passwords for the APPS accounts, the applsys password must be identical to the password for the APPS accounts (APPS, APPS2, APPS3). The uniform passwords enable the different sets of books to operate correctly.

ORACLE Users Block

This block contains the following:

Password

The password of your ORACLE username.

Until you register the password changes in Oracle E-Business Suite and implement them in the database, responsibilities using this ORACLE username cannot connect to the database.

Privilege

The type of privilege to the Oracle Application Object Library database tables for this ORACLE username. The Oracle Application Object Library tables contain information for Oracle Application Object Library features such as menus, help text, and flexfields. If you do not have access to these tables, you cannot use these features.

The default value for this field is Enabled.

Two additional privilege types appear, associated with ORACLE usernames configured at installation. However, these privilege types cannot be selected from your list of values.

Install Group

The value of the installation group associated with your ORACLE username. Install group numbers should be consecutive whole numbers, where 1 represents the first set of books (or first set of product installations), 2 is the second set of books, 3 is the third set of books, and so on. Install group number 0 represents products that need only single installations.

Important: Since the installation process does not affect ORACLE usernames (also known as "schemas") for custom applications, this value is for your reference only and is currently not used.

Applications Window

Information provided here is for reference only. Beginning with Release 12.2, you must register a custom application using adsplice. See: AD Splicer, Oracle E-Business Suite Setup Guide and My Oracle Support Knowledge Document 1577707.1, "Creating a Custom Application in Oracle E-Business Suite Release 12.2."

Oracle Application Object Library uses information supplied when a an application is registered to identify application objects such as responsibilities and forms as belonging to your application. This identification with your custom application allows Oracle E-Business Suite to preserve your application objects and customizations during upgrades. The application basepath tells Oracle Application Object Library where to find the files associated with your custom application.

You can use your custom application to name your custom menus, concurrent programs, custom responsibilities, and many other custom components. For some objects, the application part of the name only ensures uniqueness across Oracle E-Business Suite. For other components, the application you choose has an effect on the functionality of your custom object.

Applications Block

When you register a custom application, you provide the information Oracle uses to identify it whenever you reference it. Although the application short name of an application can be changed, doing so may cause a change in the application code where the application short name is hardcoded.

Important: You should not change the name of any application that you did not develop, as you cannot be sure of the consequences. You should never change the name of any Oracle E-Business Suite application, because these applications may contain hardcoded references to the application name.

Application

This user-friendly name appears in lists seen by application users.

Short Name

Oracle E-Business Suite uses the application short name as an internal key; for example, when identifying forms, menus, concurrent programs and other application components. The short name is stored in hidden fields while the name displays for users.

Your short name should not include spaces. You use an application short name when you request a concurrent process from a form, and when you invoke a subroutine from a menu.

Tip: Although your short name can be up to 50 characters, we recommend that you use only four or five characters for ease in maintaining your application and in calling routines that use your short name. To reduce the risk that your custom application short name could conflict with a future Oracle E-Business Suite short name, we recommend that your custom application short name begins with "XX".

Basepath

The name of an environment variable that represents the top directory of your application's directory tree. Oracle E-Business Suite searches specific directories beneath the basepath for your application's files and scripts.

In general, your application's basepath should be unique so that separate applications do not write to the same directories.

However, custom applications that will be used only for naming custom responsibilities, menus and other data components may be defined. In this case, you can use the basepath of the Oracle application that uses the same forms as your application. For example, if you are defining a Custom_GL application, you could use the GL_TOP basepath for your custom application. In this case, however, you should not create custom components in the directory structure, such as custom forms and reports, because they will be difficult to isolate for maintenance and upgrading.

See: Oracle E-Business Suite Concepts

Network Test Window

the picture is described in the document text

You can use the Network Test form to monitor the latency and bandwidth of the network for forms applications, or to help create a baseline for use in comparing response times from within the application. This information enables you to make comparisons between locations, or at different times of day at the same location. The form shows the time taken to perform one or more Oracle Forms round trips, and the throughput used.

The latency shown on the form represents a combination of the round trip time needed to traverse the physical network (including any devices), and the Forms overhead to process a packet. The network test form is designed to more closely measure the network latency and bandwidth of an actual forms user. Note that the results are not expected to match the times returned by ping, traceroute, or other diagnostic network commands.

To test the network latency, a short sequence of packets is sent from the client application to the application server, then on to the database server, and back to the client. You need to specify the number of sequences (iterations) you want to send, and the number of times you want to send each set of iterations (trials). The default setting is 5 trials of 100 iterations each. The average latency is the total time for all round trips in a trial, divided by the number of iterations.

The bandwidth test (or more accurately, throughput test), examines the data transfer rate, and shows how many bytes per second your network transferred between the client, application server and database server.

Running a Test

Click the Run Test button to perform the test.

You can provide notes to indicate the conditions for each test you run.

Evaluating the Test Results

If one test result varies significantly from the other trials, discard that information.

Use the Clear Old Test Data button to purge previous test results from your database.

The results of both the latency and throughput tests are displayed in the Results block.

For comparison, the sample data fields show the results of tests completed at Oracle Headquarters in Redwood Shores, California.

Administering Folders

the picture is described in the document text

Administer folders by assigning default folder definitions either to a specific user or to a responsibility. Manage folder definitions by assigning them to new owners, determining which folder definitions should be public (accessible by anyone), and setting the AutoQuery behavior of the folders.

You can do different tasks depending on how you search for folders or folder assignments in the Find Default Folders window.

You can assign a default folder to a user or responsibility in "restricted mode" such that all folder functionality is disabled at runtime for the user. In this way you can, for example, prevent users from seeing specific fields, or control which records they can query. This behavior is controlled by the Behavior Mode poplist value, set when the folder is assigned.

You must have default folders before you perform these steps.

To Assign a Folder to a Responsibility:

Follow these steps to assign a folder to a responsibility:

  1. Navigate to the Find Default Folders window. Use "Default folder assignments by responsibility" to view the responsibilities for which to assign default folders.

  2. You can assign default folders for each responsibility. When users of this responsibility navigate to this folder block, they see the default folder you specify, unless it is overridden by a user-level default.

    From the Folder field, enter the name of the default folder. The name of the folder set to which the folder belongs is filled in automatically.

    If you do not know the name of the folder, enter the folder set first, then view the folders that belong to that set.

    After you save a default folder definition for a folder set, that folder set no longer appears in the list of values.

Folder Set: Every folder set is associated with a particular folder block, and a user or responsibility can have one default folder within each folder set. The folder set name generally describes the records shown in the block; some blocks may have multiple sets of folders associated with them.

To Assign a Folder to a User:

Follow these steps to assign a folder to a user:

  1. Navigate to the Find Default Folders window. Use "Default folder assignments by user" to view a list of eligible users.

  2. You can assign default folders for each responsibility. When users navigate to this folder block, they see the default folder you specify.

    From the Folder field, enter the name of the default folder. The name of the folder set to which the folder belongs is filled in automatically.

    If you do not know the name of the folder, enter the folder set first, then view the folders that belong to that set.

    After you save a default folder definition for a folder set, that folder set no longer appears in the list of values.

Folder Set: Every folder set is associated with a particular folder block, and a user or responsibility can have one default folder within each folder set. The folder set name generally describes the records shown in the block; some blocks may have multiple sets of folders associated with them.

Source Type: Either User or Responsibility. Records entered in this window use the source type of User. If one of the current user's responsibilities has default folders defined, the default folders are listed with a source type of Responsibility.

User defaults override Responsibility defaults. You cannot delete Responsibility default folders in this window.

Responsibility: The responsibility which uses this default folder definition.

To Assign Ownership of a Folder:

Follow these steps to assign ownership of a folder:

  1. Navigate to the Find Default Folders window. Use "Folders" to view general information about folders.

  2. Select the folder(s) that requires a change of ownership.

  3. Choose "Change Owner" and enter the new owner for the selected folders, or change the value in the Owner field to change the owner of a single folder.

Folder Set: Every folder set is associated with a particular folder block, and a user or responsibility can have one default folder within each folder set. The folder set name generally describes the records shown in the block; some blocks may have multiple sets of folders associated with them.

Public: Whether this folder definition is public; whether users besides the owner can use it. Use this field to determine whether to make folder definitions generally available.

Anyone's Default: Whether this folder definition is used as a default by a user or a responsibility. If it is a default definition, use Default Assignments to view the users and responsibilities for which it is the default folder definition.

Default Assignments: The users and responsibilities that use this folder definition as a default.

To Delete a Folder Definition

Follow these steps to delete a folder definition:

  1. Navigate to the Find Default Folders window. Use "Folders" to view general information about folders.

  2. If you queried up multiple folders, select the folder(s) to delete.

  3. Delete the folder. Deleting folders deletes the folder definition along with any user and responsibility default assignments for the folder.

To Create and Assign a Folder in "Restricted Mode"

Use the steps below to create and assign a folder in a "restricted mode". When user opens a folder in restricted mode, all folder functionality is disabled.

  1. Run the folder form and navigate to the folder block.

    Hide or show fields as you wish. Take care in choosing the appropriate fields, as the fields that are hidden will not be accessible for users or responsibilities of this folder block after it is assigned to them as a default folder in restricted mode.

  2. Save the folder.

  3. Assign the folder as a default folder to a responsibility or user.

  4. Set the value of the new Behavior Mode poplist to "Restrict fields and folder functions".

    A default folder can have one of the following values for Behavior Mode:

Runtime Scenarios with Restricted Mode

Here are two scenarios with restricted mode:

End user runs folder form with restrictions

When the user opens the restricted default folder form, all folder functions are disabled. For example, the user cannot open any other folders, or move or resize fields.

Within a folder block, once a restricted default folder loads, all folder functionality will become disabled even if that block supports other folder objects.

System Administrator wants to change the default restricted folder

Once a default folder is assigned with the Behavior Mode "Restrict fields and folder functions" to any user or responsibility, it no longer appears in the list of available folders for opening by any user (even though this folder is defined as "Public").

To change this default folder, you should first assign the default folder to yourself. Then run the folder form and navigate to the folder block so that the default folder will load. You can then make modifications and save the folder. Even though the Behavior Mode is restricted, the folder functions can still be performed since you have become the owner of the folder.