Fundamentals of System Administration

Fundamentals of System Administration

What Is System Administration?

A System Administrator is a person responsible for controlling access to Oracle Applications and assuring smooth ongoing operation. Each site where Oracle Applications is installed needs a system administrator to perform tasks such as:

- Managing and controlling security. Decide which users have access to each application, and within an application, which forms, functions, and reports a user can access.

- Setting up new users. Register new Oracle Applications users, and give them access to only those forms, functions, and reports they need to do their jobs.

- Auditing user activity. Monitor what users are doing and when they do it. Choose who to audit and what type of data to audit.

- Setting user profiles. A user profile is a set of changeable options that affects the way Oracle Applications look and behave. A System Administrator can set user profile values at the site, application, responsibility, and user levels.

- Managing concurrent processing. Concurrent Processing is an Oracle Applications facility that lets long-running, data-intensive tasks run simultaneously with online operations, taking full advantage of multitasking and parallel processing. A System Administrator can monitor and control concurrent processing using a few simple forms.

System vs. Database Administrator:

Front end that users see and work with, and

Back end where data manipulation is performed.

The natural division between user applications and the underlying database structures results in two separate job functions: system administrator, and database administrator.
An Oracle Applications System Administrator administers the user interface or applications side of Oracle Applications.
An Oracle Database Administrator (DBA) administers the data that users enter, update, and delete while using Oracle Applications.

Define Oracle Applications users, and assign one or more responsibilities to each user.

Defining Application Users You allow a new user to sign-on to Oracle Applications by defining an application user. An application user has a username and a password. You define an initial password, then the first time the application user signs on, they must enter a new (secret) password.
When you define an application user, you assign to the user one or more responsibilities. If you assign only one responsibility, the user, after signing on, immediately enters an application.
If you assign two or more responsibilities, the user, after signing on, sees a window listing available responsibilities.

Responsibilities define Application Privileges A responsibility is a level of authority in Oracle Applications that lets users access only those Oracle Applications functions and data appropriate to their roles in an organization. Each responsibility allows access to:
- A specific application or applications, such as Oracle General Ledger or Oracle Planning.
- A set of books, such as U.S. Operations or German Sales or an organization, such as New York Manufacturing or New York Distribution.
- A restricted list of windows that a user can navigate to; for example, a responsibility may allow certain Oracle Planning users to enter forecast items, but not enter master demand schedule items.
- A restricted list of functions a user can perform. For example, two responsibilities may have access to the same window, but one responsibility's window may have additional function buttons that the other responsibility's window does not have.
- Reports in a specific application; as system administrator, you can assign groups of reports to one or more responsibilities, so the responsibility a user choose determines the reports that can be submitted.

Each user has at least one or more responsibilities and several users can share the same responsibility. A system administrator can assign users any of the standard responsibilities provided with Oracle Applications, or create new custom responsibilities.


Users Window

Use this window to define an application user. An application user is an authorized user of Oracle Applications and/or Oracle Self-Service Applications who is uniquely identified by an application username. Once defined, a new application user can sign on to Oracle Applications and access data through Oracle Applications windows.

Users Block

1. User Name : An application user enters this username to sign on to Oracle Applications.
The username must not contain more than one word.
You should use only alphanumeric characters ('A' through 'Z', and '0' through '9') in the username. Please note that you must limit your username to the set of characters that your operating system supports for filenames.
* It is recommended that you define meaningful usernames, such as the employee's first initial followed by their last name. Or, for a group account, you can define the application username so as to indicate the purpose or nature of the group account.

2. Password: Enter the initial password of an application user. An application user enters this password along with her or his username to sign on to Oracle Applications.
A password must be at least five characters and can extend up to 100 characters.
You should use alphanumeric characters ('A' through 'Z', and '0' through '9') in a password. All other characters are invalid. This window does not display the password you enter. After you enter a password, you must re-enter it to ensure you did not make a typing error.
If the application user already exists and the two entries do not match, the original password is NOT changed, and you navigate automatically to the next field.
If you are defining a new application user and the two entries do not match, you are required to enter the password again. For a new user, you cannot navigate to the next field until the two entries match.
The first time an application user signs on, they must change his or her password. If a user forgets their password, you can reassign a new password in this field.
As System Administrator, you can set an initial password or change an existing password, but you cannot access the user's chosen password.

3. Person, Customer, and Supplier : Use these fields to enter the name of an employee (person), customer, or supplier contact. Enter the last name and first name, separated by a comma, of the employee, customer, or supplier who is using this application username and password. Use the List of Values to select a valid name.

4. E-Mail/Fax : Enter the E-mail address and/or fax number for this user.


Password Expiration

1. Days : Enter the maximum number of days between password changes. A pop-up window prompts an application user to change her or his password after the maximum number of days you specify has elapsed.

2. Accesses :Enter the maximum allowed number of sign-ons to Oracle Applications allowed between password changes. A pop-up window prompts an application user to change her or his password after the maximum number of accesses you specify has elapsed.
Suggestion: We recommend that you require application users to make frequent password changes. This reduces the likelihood of unauthorized access to Oracle Applications.

Effective Dates

From/To: The user cannot sign onto Oracle Applications before the start date and after the end date. The default for the start date is the current date. If you do not enter an end date, the username is valid indefinitely.
- You cannot delete an application user from Oracle Applications because this information helps to provide an audit trail. You can deactivate an Oracle Applications user at any time by setting the End Date to the current date.
- If you wish to reactivate a user, change the End Date to a date after the current date, or clear the End Date field.

Responsibilities Block

Responsibility : Select the name of a responsibility you wish to assign to this application user. A responsibility is uniquely identified by application name and responsibility name.

From/To : You cannot delete a responsibility because this information helps to provide an audit trail. You can deactivate a user's responsibility at any time by setting the End Date to the current date.

If you wish to reactivate the responsibility for the user, change the End Date to a date after the current date, or clear the End Date.

Securing Attributes

Securing attributes are used by Oracle Self-Service Web Applications to allow rows (records) of data to be visible to specified users or responsibilities based on the specific data (attribute values) contained in the row.

- You may assign one or more values for any of the securing attributes assigned to the user. If a securing attribute is assigned to both a responsibility and to a user, but the user does not have a value for that securing attribute, no information is returned for that attribute.

- For example, to allow a user in the ADMIN responsibility to see rows containing a CUSTOMER_ID value of 1000, assign the securing attribute of CUSTOMER_ID to the ADMIN responsibility. Then give the user a security attribute CUSTOMER_ID value of 1000.

- When the user logs into the Admin responsibility, the only customer data they have access to has a CUSTOMER_ID value of 1000.

Attribute : Select an attribute you want used to determine which records this user can access. You can select from any of the attributes assigned to the user's responsibility.
Value : Enter the value for the attribute you want used to determine which records this user can access.


Defining a Responsibility

When you define a responsibility, you assign to it some or all of the components described below:
1. Data Group (required): A Data Group defines the mapping between Oracle Applications products and ORACLE IDs. A Data Group determines which Oracle database accounts a responsibility's forms, concurrent programs, and reports connect to.

2. Request Security Group (optional): A request security group defines the concurrent programs, including requests and request sets, that may be run by an application user under a particular responsibility.

3. Menu (required): A menu is a hierarchical arrangement of application functions (forms) that displays in the Navigate window. Menus can also point to non-form functions (subfunctions) that do not display in the Navigate window, but that define the range of application functionality available for a responsibility. Each responsibility is associated with a menu.

4. Function and Menu Exclusions (optional):A responsibility may optionally have function and menu exclusion rules associated with it to restrict the application functionality enabled for that responsibility.

Additional Notes About Responsibilities

- Predefined Responsibilities: All Oracle Applications products are installed with predefined responsibilities. Consult the reference guide for your Oracle Applications product for the names of those predefined responsibilities.
Additionally, instances of the major components that help define a responsibility (data groups, request security groups, menus, and functions) are predefined for Oracle Applications.

-Responsibilities and Request Security Groups: When a request group is assigned to a responsibility, it becomes a request security group.
From a standard submission form, such as the Submit Requests form, users can run only the reports, concurrent programs, and request sets that are in their responsibility's request security group.

- If you do not include the Submit Requests form on the menu for a responsibility, then you do not need to assign a request security group to the responsibility.

- If a request security group is not assigned to a responsibility, then users working under that responsibility cannot run any reports, request sets, or other concurrent programs from a standard submission form.

- Responsibilities and Function Security: Oracle Applications GUI-based architecture aggregates several related business functions into a single form. Parts of an application's functionality may be identified as individual Oracle Applications functions, which can then be secured (i.e., included or excluded from a responsibility).


Responsibilities Window

Use this window to define a responsibility. Each application user is assigned at least one responsibility. A responsibility determines if the user accesses Oracle Applications or Oracle Self-Service Web Applications, which applications functions a user can use, which reports and concurrent programs the user can run, and which data those reports and concurrent programs can access.

[ Responsibilities cannot be deleted. To remove a responsibility from use, set the Effective Date's To field to a past date. You must restart Oracle Applications to see the effect of your change. ]

Prerequisites:
- Use the Data Groups window to list the ORACLE username your responsibility's concurrent programs reference on an application-by-application basis.
- Use the Request Groups window to define the Request Group you wish to make available with this responsibility.
- Use the Menus window to view the predefined Menu you could choose to assign to this responsibility.


Responsibilities Block

An application name and a responsibility name uniquely identify a responsibility.

1. Responsibility Name: If you have multiple responsibilities, a pop-up window includes this name after you sign on.

2. Application : This application name does not prevent the user of this responsibility from accessing other applications' forms and functions if you define the menu to access other applications.

3. Responsibility Key: This is a unique name for a responsibility that is used by loader programs. Loaders are concurrent programs used to "load" such information as messages, user profiles and user profile values into your Oracle Applications tables. To help ensure that your responsibility key is unique throughout your system, begin each Responsibility Key name with the application short name associated with this responsibility.

4. Menu : The menu whose name you enter must already be defined with Oracle Applications.

5. Web Host Name : If your Web Server resides on a different machine from your database, you must designate the host name (URL) here. Otherwise, the Web Host Name defaults to the current database host server.

6. Web Agent Name : Enter the PL/SQL Agent Name for the database used by this responsibility. If you do not specify an Agent Name, the responsibility defaults to the agent name current at log-on.

7. Available From: A responsibility may be associated with only one applications system. Select between Oracle Self-Service Web Applications or Oracle Applications.

8. Effective Dates:

From/To : Enter the start/end dates on which the responsibility becomes active/inactive. The default value for the start date is the current date, and if you do not enter an end date, the responsibility is valid indefinitely.

You cannot delete a responsibility because its information helps to provide an audit trail. You can deactivate a responsibility at any time by setting the end date to the current date. If you wish to reactivate the responsibility, change the end date to a date after the current date, or clear the end date.

9. Data Group

Name/Application : The data group defines the pairing of application and ORACLE username.
Select the application whose ORACLE username forms connect to when you choose this responsibility. The ORACLE username determines the database tables and table privileges accessible by your responsibility. Transaction managers can only process requests from responsibilities assigned the same data group as the transaction manager.

10. Request Group

Name/Application :
If you do not assign a request security group to this responsibility, a user with this responsibility cannot run requests, request sets, or concurrent programs from the Submit Requests window, except for request sets owned by the user. The user can access requests from a Submit Requests window you customize with a request group code through menu parameters.


Function and Menu Exclusions Block

Define function and menu exclusion rules to restrict the application functionality accessible to a responsibility.

1. Type : Select either Function or Menu as the type of exclusion rule to apply against this responsibility.
- When you exclude a function from a responsibility, all occurrences of that function throughout the responsibility's menu structure are excluded.
- When you exclude a menu, all of its menu entries, that is, all the functions and menus of functions that it selects, are excluded.

2. Name : Select the name of the function or menu you wish to exclude from this responsibility. The function or menu you specify must already be defined in Oracle Applications.

Self-Service Applications Security

Oracle Self-Service Web Applications uses columns, rows and values in database tables to define what information users can access. Table columns represent "attributes" that can be assigned to a responsibility as Securing Attributes or Excluded Attributes. These attributes are defined in the Web Application Dictionary.
Securing Attributes : Use the List of Values to select valid attributes. You may assign any number of securing attributes to the responsibility.
Excluded Attributes : Use the List of Values to select valid attributes. You can assign any number of Excluded Attributes to a responsibility.


Defining a Request Security Group

Using Request Security:

- You use request security to specify the reports, request sets, and concurrent programs that your users can run from a standard submission form, such as the Submit Requests form.
- To set up request security, you define a request group using the Request Groups form. Using the Responsibilities form, you assign the request group to a responsibility. The request group is then referred to as a request security group.
- You can define a request group to contain single requests, request sets, or all the requests and request sets in an application.
- If you choose to include all the requests and requests sets in an application, the user has automatic access to any new requests and request sets (without owners) in the future.
- A request security group can contain requests and request sets from different applications. If you want to define request security groups that own requests from different applications, please refer to the discussion on Data Groups.

Individual Requests and Request Sets:

Reports or concurrent programs that are not included in a request security group on an individual basis, but that do belong to a request set included in a request security group, have the following privileges:
- Users cannot use the Submit Requests form to run single requests and request sets that are not in their responsibility's request security group.
- Users can, however, run request sets that contain requests that are not in their request security group, if the request set is in their request security group.

If you assign a request set, but not the requests in the set, to a request security group, the user: - cannot edit request information in the request set definition
- cannot stop specific requests in the set from running
- can edit the request set by deleting requests from it or adding other requests to it, only if the user is the assigned owner of the request set

The Request Security Groups figure illustrates the relationship between a request security group, application user, and a responsibility.

Data Groups: A data group is a list of Oracle Applications and the Oracle username assigned to each application. Each application in a data group must have a Oracle username assigned to it. An application may be listed only once in a data group.
An Oracle username and password allow access to an application's tables in an Oracle database. Each Oracle username in a data group determines the database tables and table privileges accessible by the corresponding application or applications.

Data Group's Purpose: Each responsibility has a data group associated with it. A data group serves two purposes:
1. It identifies the Oracle username that forms connect to when you select the responsibility.
2. Concurrent managers use a data group to match the application that owns a report or concurrent program (submitted by a user of the responsibility) with a Oracle username.

Data Group's structure There are four points concerning the makeup of any Data Group.
1. Within each data group, an application can be listed only one time.
2. Within each data group, an Oracle username can be paired with more than one application.
3. Within each data group, the application Application Object Library is automatically included.
- Application Object Library's Oracle username cannot be updated or deleted.
- Application Object Library owns the database tables that oversee concurrent processing and the standard submission of reports by any Oracle Application.
4. Within each data group, a Tool Oracle username can be associated with each application-Oracle username pair. If that application-Oracle username pair is chosen as the one for forms to connect to when the responsibility is selected, then the Tool Oracle username is relevant, and appears by default.

* To prevent users of a responsibility from connecting to the database using a Tool Oracle username, you can backspace over (erase) the default entry. You cannot select a Tool Oracle username associated with another application in the data group.

The Tool Oracle username identifies the database tables and privileges a user of the responsibility has when connecting to the database using an Oracle Tool, for example, SQL*Plus.
- When users of the responsibility select Oracle Tools window to run a tool that requires a database connection, the Tool Oracle Username appears as the default tool access Oracle - Username.
- Users do not need to enter an Oracle password to use the Oracle Username.

* The Oracle Tools window may not be available on your desktop platform.

* If the Oracle Tool is query-only, for example, Oracle Browser, you may assign an unrestricted Tool Oracle Username. If the Oracle Tool allows write privileges, you should assign a Tool Oracle Username that is restricted (read-only).

* Modifying data or table structures using an Oracle Tool, for example, SQL*Plus or SQL*Forms, may damage your data's integrity and is not supported by Oracle.


Request Groups: A request security group is the collection of requests, request sets, and concurrent programs that a user, operating under a given responsibility, can select from the Submit Requests window.

System Administrators:

- Assign a request security group to a responsibility when defining that responsibility. A responsibility without a request security group cannot run any requests using the Submit Requests window.
- Can add any request set to a request security group. Adding a private request set to a request security group allows other users to run that request set using the Submit Requests window.

Users:
- Can create their own private request sets using the Request Sets window. In a private request set, users can include only the requests you assign to their request security group.
- Cannot update another user's private request set using the Request Sets window.
- Cannot delete a private request set if it is assigned to a request security group.

Request Security Groups : When a request group is assigned to a responsibility, the request group is referred to as a request security group. Any user signed on under a responsibility can run the reports and concurrent programs contained in their responsibility's request security group.
The Submit Requests standard submission form displays a list of all the reports and programs in the current responsibility's request security group.

Request Sets:

1. There are significant differences between end user and System Administrator privileges when defining or editing request sets.

2. End users own the request sets they create An end user can create a request set by selecting reports, other request sets, or concurrent programs that are part of the report security group assigned to his or her responsibility.

3. When an end user creates a request set, the user automatically becomes the "owner" of the request set. Ownership is identified by the person's application username.

4. End users use the Request Set form to create a new request set, or to query and update any request sets they own. End users can only edit request sets they own.

5. We sometimes refer to a request set that an end user owns as a private request set. Private request sets are not automatically added to a request security group. That is, other users cannot access your private request sets using the Submit Requests window unless the System Administrator assigns that request set to a request security group.

6. Request sets owned by an end user are always available to that user, regardless of what responsibility the user is operating under. However, a standard submission form customized to display only reports in a request group using a code does not display private request sets.

7. When a user signs on to Oracle Applications, the user can run requests, request sets, and concurrent programs included in:
- their responsibility's request security group
- any request sets they own.

End User Benefits from Private Request Sets: Private request sets offer two main benefits to end users:

1. The request sets that users own are always available to them, regardless of which responsibility they are working under.
2. Users can create as many request sets as they want without adding request set choices to the list of standard submission concurrent programs that other users must select from.


User Profiles

- A user profile is a collection of changeable options that affect the way your applications run. Oracle Applications establishes a value for each option in a user's profile when the user logs on or changes responsibility. Oracle Applications provides these options so that you can alter the behavior of your applications to suit your own preferences.

- Oracle Applications uses a set of user profile options that are common to all the application products. In addition, each application product has its own unique set of user profile options.

- User profile options can be set at one or more of four levels: Site, Application, Responsibility, and User. Your system administrator can set default option values at any of these levels.

Basic Business Needs

Oracle Applications user profiles help you satisfy the following business needs. You should be able to:
- Set options that affect your application's behavior to your preference
- Modify product-specific variables that affect the functionality of your application to suit your business environment

Major Features

User Profile Hierarchy Oracle Applications treats user profile levels as a hierarchy, where User is the highest level of the hierarchy, followed by Responsibility, Application, and at the lowest level, Site. Each user profile option ordinarily exists at each level. For example, Oracle Applications provides a Site-level Printer option, an Application-level Printer option, and so on. Oracle Applications enforces the level hierarchy to ensure that a higher-level option value overrides a lower-level value. For example, if your Site-level Printer value is "New York", but your User-level Printer value is "Boston", you can be assured that your reports print to the Boston printer.

User Profile Options: Changeable options that affect the way your applications run.

User Profile Levels: User profile options exist at four different levels: Site, Application, Responsibility, and User levels. Oracle Applications treats user profile levels as a hierarchy, where User is the highest level of the hierarchy, followed by Responsibility, Application, and at the lowest level, Site. Higher-level option values override lower-level option values.

1. Site Level Site is the lowest profile level. Site-level option values affect the way all applications run at a given installation site.

2. Application Level Application is the profile level immediately above Site. Application-level option values affect the way a given application runs.

3. Responsibility Level Responsibility is the profile level immediately above Application. Responsibility-level option values affect the way applications run for all users of a given responsibility.

4. User Level User is the highest profile level and is immediately above Responsibility. User-level option values affect the way applications run for a given application user.


Determining User Profile Option Values Your system administrator can set values for user profile options at each profile level. Typically, your system administrator sets Site-level option values after installing Oracle Applications at a site. These Site-level option values apply until you or your system administrator changes them.

Oracle Applications derives a run-time value for each user's profile option based on the value set at the highest hierarchy level. For example, suppose your system administrator initially set your Printer option only at the Site and Responsibility levels. When you sign on to Oracle Applications, the Printer option assumes the value set at the Responsibility level, since it is the highest-level setting for that option. If you are not satisfied with that setting, you can set your own preference at the User-level, since your User-level setting overrides the Responsibility-level setting.

[Some option values can only be changed by the system administrator. You can view the value of such a user profile option, but you cannot modify that value. For example, you can view the value of the user profile option Concurrent:Request Priority, which is set at the User-level, but only your system administrator can modify its value for you]

If the default value of a user profile option at any level is inappropriate, your system administrator can change it at any time. Any change your system administrator makes takes effect as soon as you log on again or change responsibilities.


Setting Your Personal User Profile You can change a user profile option value using the Profile Values window. Using this window, you can display all your options and review the values your system administrator has set for them. You can also change those options that are updatable if you like. Changes you make to a User-level profile option take effect when you either change responsibilities or close and re-login into the application. If changes are made in character mode you must follow the same steps to apply the changes to applications running in GUI mode. Changes you make to your User-level options are still in force when you log in again.
If you never set your own User-level option values, your user profile options assume the Site-, Application-, Responsibility-, or User-level values your system administrator has set for them.


Function: A function is a part of an application's functionality that is registered under a unique name for the purpose of assigning it to, or excluding it from, a responsibility.
There are two types of functions: form functions, and non-form functions.
For clarity, we refer to a form function as a form, and a non-form function as a subfunction, even though both are just instances of functions in the database.


Defining a function: Form Function Block

Function : Users do not see this unique function name. However, you may use this name when calling your function programmatically. You should follow the naming conventions for functions.

User Function Name: Enter a unique name that describes your function. You see this name when assigning functions to menus. This name appears in the Top Ten List of the Navigator window.

Type : Type is a free-form description of the function's use. A function's type is passed back when a developer tests the availability of a function. The developer can write code that takes an action based on the function's type.
By convention, Oracle Applications form functions are registered with a type of FORM. A few, specialized functions that determine common form behaviors are registered with a type of UTIL.
Even if you do not register a form function with a type of FORM, Oracle Applications treats it as a form if you specify a valid Form Name/Application

Form
Form /Application
If you are defining a form function, select the name and application of your form.

Parameters : Enter the parameters you wish to pass to your function. Separate parameters with a space.
- For a form function, if you specify the parameter QUERY_ONLY=YES, the form opens in query-only mode. Oracle Application Object Library removes this parameter from the list of form parameters before opening the form in query-only mode.
- You can also specify a differnt form name to use when searching for help for a form in the appropriate help file. The syntax to use is:
HELP_TARGET = "alternative_form_name"
Your form name overrides the name of the form.
- Some Oracle Applications forms are coded to accept particular form parameters. For example, the Run Requests form accepts a TITLE parameter you can use to change the Run Requests window title. The syntax you should use is:
TITLE="appl_short_name:message_name"
where appl_shortname:message_name is the name of a Message Dictionary message.

[Warning: In general, System Administrators should not modify parameters passed to functions that are predefined as part of the Oracle Applications products. The few cases where function parameters may be modified by a System Administrator are documented in the relevant technical reference manual or product update notes.]

Web Regions: The fields in the Web regions are only required if your function will be accessed from Oracle Self-Service Web Applications. You do not need to enter any of these fields for SmartClient and Web-deployed Applications functions.

Host Name : The URL (universal resource locator) or address required for your function consists of three sections: the Host Name, Agent Name, and the HTML Call. The Host name is the IP address or alias of the machine where the Webserver is running.

Agent Name : The second section of your functions URL is the Oracle Web Agent. The Oracle Web Agent determines which database is used when running your function. Defaults to the last agent used.

HTML Call : The last section of your functions URL is the HTML Call. The HTML Call is used to activate your function. The function may be either a static web page or a procedure.

Secured : Secured is only required when your function is accessed by Oracle Workflow. Checking Secured enables recipients of a workflow E-Mail notification to respond using E-Mail.

Encrypt Parameters : Checking Encrypt Parameters adds a layer of security to your function to ensure that a user cannot access your function by altering the URL in their browser window. You must define Encryption Parameters when you define your function to take advantage of this feature.

Defining a Menu

Menus: Menus Window is used to define a new menu or modify an existing menu.
- A menu is a hierarchical arrangement of functions and menus of functions. Each responsibility has a menu assigned to it.
- A "full access" responsibility with a menu that includes all the functions in an application is predefined for each Oracle Applications product. As a System Administrator, you can restrict the functionality a responsibility provides by defining rules to exclude specific functions or menus of functions. In fact, we recommend that you use exclusion rules to customize a responsibility in preference to constructing a new menu hierarchy for that responsibility.
- If you cannot create the responsibility you need by applying exclusion rules, you may build a custom menu for that responsibility using predefined forms (i.e., form functions) and their associated menus of subfunctions. However, we recommend that you do not disassociate a form from its developer-defined menus of subfunctions.

Prerequisites
- Register your application with Oracle Application Object Library using the Applications window.
- Define any menus that you intend to call from your menu. Define the lowest-level submenus first. A submenu must be defined before it can be called by another menu.

* By calling submenus from your menu, you can group related windows together under a single heading on your menu. You can reuse your menu on other menus.

Menus Block Menu entries detail the options available from your menu.
Menu : Choose a name that describes the purpose of the menu. Users do not see this menu name.
User Menu Name : You use the user menu name when a responsibility calls a menu or when one menu calls another.

Menu Entries Block

Sequence : Enter a sequence number to specify where a menu entry appears relative to other menu entries in a menu. The default value for this field is the next whole sequence number.
A menu entry with a lower sequence number appears before a menu entry with a higher sequence number.

Attention: If you change sequence numbers or frequently insert and delete menu entries, carefully check the default value. This value may be a duplicate sequence number or an out of sequence number.
Suggestion: You cannot replace a menu entry sequence number with another sequence number that already exists. If you want to add menu entries to a menu entry sequence that uses only integers, carefully renumber your menu entries to a sequence range well outside the sequence range you want, ensuring that you do not use existing sequence numbers
Once you save this work, you can go back and renumber each entry to have the final sequence number you want.

Navigator Prompt : Enter a user-friendly, intuitive prompt your menu displays for this menu entry. You see this menu prompt in the hierarchy list of the Navigator window.
Suggestion: Enter menu prompts that have unique first letters so that power users can type the first letter of the menu prompt to choose a menu entry.

Submenu : Call another menu and allow your user to select menu entries from that menu.

Function : Call a function you wish to include in the menu. A form function (form) appears in the Navigate window and allows access to that form. Other non-form functions (subfunctions) allow access to a particular subset of form functionality from this menu.

Description : Descriptions appear in a field at the top of the Navigate window when a menu entry is highlighted.