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 WindowUse 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 Block1. 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 Expiration1. 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 DatesFrom/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 BlockResponsibility : 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 AttributesSecuring
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 ResponsibilityWhen 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 WindowUse
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 BlockAn 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 GroupName/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 GroupName/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 BlockDefine 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 SecurityOracle
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 NeedsOracle 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 FeaturesUser 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 BlockFunction : 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
FormForm /ApplicationIf 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 MenuMenus: Menus Window is used to d
efine 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 BlockSequence : 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.
