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

You can think of Oracle Applications as having two sides: a front end that
users see and work with, and a 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.

TCS Confidential
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.

Responsibility
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.

2
TCS Confidential
Defining a Responsibility
When you define a responsibility, you assign to it some or all of the
components described below:

Data Group A Data Group defines the mapping between Oracle

(Required) Application products and ORACLE IDs. A Data Group
determines which Oracle database accounts a
responsibility’s forms, concurrent programs, and
reports connect to.

Request Security A request security group defines the concurrent

Group (optional) programs, including requests and request sets, that
may be run by an application user under a particular
responsibility.

Menu A menu is a hierarchical arrangement of application

(Required) functions (forms) 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.

Function and Menu A responsibility may optionally have function and

Exclusions (optional) menu exclusion rules associated with it to restrict the
application functionality enabled for that responsibility.

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.

3
TCS Confidential
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.

Form (Form Function)

A form function (form) invokes an Oracle Forms form. Form functions have
the unique property that you may navigate to them using the Navigate window.

4
TCS Confidential
Subfunction (Non–Form Function)

A non–form function (subfunction) is a securable subset of a form’s

functionality: in other words, a function executed from within a form. A developer
can write a form to test the availability of a particularsubfunction, and then take
some action based on whether the subfunction is available in the current
responsibility.

Subfunctions are frequently associated with buttons or other graphical

elements on forms. For example, when a subfunction is enabled, the
corresponding button is enabled.

However, a subfunction may be tested and executed at any time during a

form’s operation, and it need not have an explicit user interface impact. For
example, if a subfunction corresponds to a form procedure not associated with a
graphical element, its availability is not obvious to the form’s user.

Menu
A menu is a hierarchical arrangement of functions and menus of functions.
Each responsibility has a menu assigned to it.

Menu Entry

A menu entry is a menu component that identifies a function or a menu of

functions. In some cases, both a function and a menu of functions correspond to
the same menu entry. For example, both a form and its menu of subfunctions can
occupy the same menu entry.

5
TCS Confidential
 6
TCS Confidential
Request Groups and Request Sets

Reports and concurrent programs can be assembled into request groups

and request sets.

• A request group is a collection of reports or concurrent programs. A System

Administrator defines report groups in order to control user access to reports
and concurrent programs. Only a System Administrator can create a request
group.

• Request sets define run and print options, and possibly, parameter values,
for a collection of reports or concurrent program. End users and System
Administrators can define request sets. A System Administrator has request
set privileges beyond those of an end user.

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 on the next page illustrates the
relationship between a request security group, application user, and a
responsibility.

7
TCS Confidential
Data Group
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
unique 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.

8
TCS Confidential
Purpose of the Data Group

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
unique Oracle username.

User Profiles
A user profile is a set of changeable options that affect the way your
application looks and behaves. As System Administrator, you control how Oracle
Applications operate by setting user profile options to the values you want. You
can set user profile options at four different levels: site, application, responsibility,
and user.

9
TCS Confidential
Setting User Profile Options

As System Administrator, you use the System Profile Values window to set
profile options for your user community. If you change a user profile option value,
your change takes effect as soon as your users log on again or change
responsibilities.

When you set a user profile, you provide Oracle Applications with standard
information (such as printer) that describes a user, responsibility, application, or
site. You can set values for user profile options at each profile level.

Site Option settings pertain to all users at an installation site.

Application Option settings pertain to all users of any responsibility

associated with the application.

Responsibility Option settings pertain to all users currently signed on under

the responsibility.

User Option settings pertain to an individual user, identified by

their application username.

The values you set at each level provide run–time values for each user’s
profile options. An option’s run–time value becomes the highest–level setting for
that option.

Using Profile Options as a Parameter or Segment Default Value

Profile option settings may be used as a default value for a concurrent

program’s parameter or flexfield’s segment. Table below lists the forms you may
use to enter a profile option whose setting serves as a default value.

To use a profile option’s setting as a default value, navigate to the form’s

Default Type field and select Profile. Then, enter the profile option’s internal
name in the Default Value field.

10
TCS Confidential
Concurrent Programs and Requests
A concurrent program is an executable file that runs simultaneously with
other concurrent programs and with online operations, fully utilizing your
hardware capacity. Typically, a concurrent program is a long–running, data–
intensive task, such as posting a journal or
generating a report.

Standard Request Submission and Request Groups

Standard Request Submission is an Oracle Applications feature that

allows you to select and run all your reports and other concurrent programs from
a single, standard form. The standard submission form is called Submit
Requests, although it can be customized to display a different title.

• The reports and concurrent programs that may be selected from the Submit
Requests form belong to a request security group, which is a request group
assigned to a responsibility.

• The reports and concurrent programs that may be selected from a

customized Submit Requests form belong to a request group that uses a
code.

In summary, request groups can be used to control access to reports and

concurrent programs in two ways; according to a user’s responsibility, or
according to a customized standard submission (Run Requests) form.

11
TCS Confidential
Request Sets as concurrent programs

When you define a request set, you create a concurrent program that runs
the reports in your request set according to the instructions you entered. All
concurrent programs that run request sets are titled Request Set <name of
request set>. In the Concurrent Programs form, if you query a request set
concurrent program on the basis of the program’s name, you must enter in the
Name field the words:

• ”Request Set” before the name of a concurrent program

• ”Request Set %” to perform a query on all request set programs

A request set concurrent program creates a log file documenting the

execution of the request set. Each report or concurrent program within a request
set also creates its own log file. When you run a request set, you submit a
request to run the concurrent program that defines the request set. The request
set concurrent program then submits a request for each program within the set. A
request to run the request set concurrent program is a Parent request, while the
requests to run individual programs within the set are Child requests.

Some Important notes on the privileges regarding Request Set

Request set editing and report viewing privileges are different for reports
that belong to a user’s request security group than they are for reports that are
not in the user’s request security group.

When you, as System Administrator, add a request set to a request

security group that contains individual reports that are not in the request security
group, end users who do not own the request set:

• cannot edit the request set if it is owned by someone else, or if it has no

owner (i.e., they can only edit their own request sets).
• cannot view online reports in a request set if those reports are not included in
their request security group.
• cannot run an individual report by itself, but can only run the entire request
set.
• cannot cancel pending requests for the individual reports in the set if those
reports are not included in their request security group.

When you, as System Administrator, add a request set to a request

security group that contains individual reports that are not in the request security
group, an end user who is the owner of the request set:

• can add any other reports in their request security group to the request set.

12
TCS Confidential
• can delete any report from the request set, regardless of whether that report
is in their request security group.
• can update print options or parameters for an individual report in the request
set, if the report is in their request security group.
• cannot view online reports in a request set if those reports are not included in
their request security group.
• cannot run an individual report by itself, but can only run the entire request
set.
• cannot cancel pending requests for the individual reports in the set if those
reports are not included in their request security group.

System Administrator Benefits from Private Request Sets

Private request sets offer three main benefits to System Administrators:

1. Private request sets offer a means of controlling access to concurrent

programs on a
user–by–user basis. By defining a request set, assigning it an owner, and
then not assigning the request set to any request security group, the reports
and programs in the request set are only available to the owner.

2. By leaving the Owner field blank, System Adminstrators can create request
sets whose individual programs and parameters cannot be edited or updated
by end users. Only a System Administrator can edit a request set that has no
owner.

3. System Administrators can provide members of a responsibility access to

reports and programs outside their request security group. By defining a
request set that contains reports or programs not in a request security group,
and assigning that request set to the request security group, users can be
granted run, but not edit or online viewing, privileges for selected reports or
programs.

Sharing Parameters in a Request Set

Parameters, also referred to as arguments, are values that define aspects

of a program’s execution.

You can share a parameter and its entered value among some or all of the
reports (or concurrent programs) in your request set. You identify a parameter as
shared by giving it a label. Then, for each concurrent program in your request
set, you can assign the same label to a parameter for that program. Among the
programs in your request set, the parameters for each program share or accept a
common value. The first time you enter a value for any of the shared parameters,

13
TCS Confidential
that value becomes the shared parameters value. This is useful, because you
only have to enter a value once, rather than for each program in the request set.

Defining a Request Group

When defining a request group, you can include:

• all the reports and concurrent programs owned by an application

• individual reports and concurrent programs
• request sets, which are collections of reports and concurrent programs that
may be selected from an application user’s request security groups

A request group is used by Oracle Applications at two different levels

Responsibility level

When a request group is assigned to a responsibility, it is referred to as a

request security group, and it defines the reports, request sets, and concurrent
programs that a user, operating under that responsibility, can select from the
Submit Requests Window.

Form level

When a request group is assigned a code, that code can be passed as a

parameter to the Submit Requests Window. The code helps define the function
that calls the Submit Requests Window. The list of values for that unique Submit
Requests Window lists the reports, request sets, and concurrent programs in the
request group.

Incompatible and Run Alone Programs

When a concurrent program is incompatible with another program, the two

programs cannot access or update the same data simultaneously. When you
define a concurrent program, you can list those programs you want it to be
incompatible with. You can also list the program as incompatible with itself, which
means that two instances of the program cannot run simultaneously. You can
also make a program incompatible with all other concurrent programs by defining
the program to be run–alone. You define a concurrent program to be run–alone
or to be incompatible with specific concurrent programs by editing the concurrent
program’s definition using the Concurrent Programs window. An applications
database account in which a concurrent program accesses or updates data and
where program incompatibility and run–alone program definitions are enforced is
referred to as a logical database.

14
TCS Confidential
Enforcing Incompatibility Rules

Concurrent managers read requests to start concurrent programs running.

The Internal Concurrent Manager checks concurrent program definitions for
incompatibility rules. If a program is identified as Run Alone, then the Internal
Concurrent Manager prevents the concurrent managers from starting other
programs in the same logical database. When a program lists other programs as
being incompatible with it, the Internal Concurrent Manager prevents the program
from starting until any incompatible programs have completed running. The
following below illustrates the role of the Internal Concurrent Manager when
enforcing program incompatibility rules.

15
TCS Confidential
Using Data Groups for cross–application reporting

Use data groups to allow users to run reports belonging to an application

other than the application associated with the user’s responsibility. For example,
you can let a user of an Oracle General Ledger responsibility run an Oracle
Payables report in the Oracle Payables Oracle username.
Note: Since you are using the Run Requests form in the General Ledger Oracle username, that
username must have SELECT privileges on any Oracle Payables validation tables needed to
validate report parameters

Using Data Groups with multiple Sets of Books

Use data groups to support multiple installations of an Oracle Applications

product (for example, Oracle Payables) that supports multiple sets of books,
where a different application is associated with each set of books.For example,
with two installations of Oracle Payables supporting two Sets of Books, use data
groups to indicate which Oracle Payables Oracle username to access from a
certain General Ledger responsibility. Define a data group for each application
installation (set of books). Define a responsibility for each application installation
(set of books), and assign the appropriate data group to each responsibility.

Using Data Groups to include custom applications

Use data groups to include custom applications you develop using

Oracle’s Application Object Library. To integrate a custom application with Oracle
Applications, you must register the application using the Applications window.

Concurrent Program Parameters

Parameters, also referred to as arguments, are assigned to standard

submission concurrent programs. To define a program as standard submission,
set the value of the Standard Submission field in the Concurrent Programs form
to Yes. Attention: All the mechanisms for parameter defaulting (including
references to values of other parameters, user profiles, etc.) are evaluated only
at submission time. There are two aspects to a parameter associated with a
concurrent program: its value set and its behavior. The valid values the
parameter can accept. The set of valid values is referred to as a value set. How
the parameter behaves within an application. For example, whether:
– an entry value for the parameter is required in
order for the program to work
– the parameter is displayed to the end user
– a default value is automatically provided for the
parameter

16
TCS Confidential
If you wish to define or modify a value set, you must first carefully plan your value
set’s purpose and implementation.

Using the Concurrent Programs form, you can see a concurrent program’s
parameters by choosing Parameters. Each parameter has a value set that
defines what values are permissible for the parameter. To see the name of a
parameter’s value set, look at the Value Set field in the Argument Details block.

17
TCS Confidential