SYSTEM

ADMINISTRATION
INTRODUCTION
Every system has administrators, the professional / team of professionals
that manage the system, users and ensure the apposite functionality of
the application. Oracle E-Biz is no different. We will not discuss the core
System administration tasks as part of this section, because it is a role by
itself, and a completely different archetype with respect to the job
responsibilities. However we are going to look at the different concepts
and screens those as useful from a Techno-functional point of view.

CHAPTER OVERVIEW
This chapter talks about:
 Users, Roles and Responsibilities
 Concepts of Functions, Menus and Request Groups
 Concurrent programs and their usages

LEARNING OUTCOMES
After going through this Chapter, you should be able to:
 Understand difference between user and roles
 Understand the concept of responsibility
 Usage of menu and functions
 Define concurrent programs and attach them to Request Groups
 Run concurrent programs

THE DICTIONARY

Users
A user, as the name suggests in an entity that logs in to the system, and
uses the system resources for their requirement. So who are the users?
 The HR person, the person who manages employee data and other HR
related processes.
 The employees working in the firm, as they will log in for their daily needs,
like seeing their pay slips, updating their information in system, Choosing
their benefit enrollments, entering time onto the system and entering
appraisals are to name a few examples.
 The External Vendors, like trainers, recruiting agencies etc, who use our
system to put data and access the same.

These examples are just based on HR systems. If we look at other modules

as well, there will be a hundred different types of users, like the
Procurement team users, the financial users etc.

Role
Continuing with the set of users that we have discussed above, every user
is entitled to a distinct group of tasks, he does. For an example, a HR user
manages the HR related data of employees of an Organization. To be little
specific, a Payroll user, who is a type of HR user, manages the Payroll data,
a talent development user in HR, creates and manages the training classes
 and administers the enrolments. So every type of user has certain tasks to
do, in the application. That set of tasks is known as a role. Hence a role is a
set of tasks combined together that is assigned to one or more than one
user(s).

Responsibility
A responsibility controls the accesses and the transactional/ reporting
authority to a user. To be specific, a responsibility defines the set of
screens that a user with that particular responsibility can go to, the reports
he can run, the approvals he can make etc. For an example, if we create a
responsibility called Payroll User, we can club the functionalities, reports
and the tasks it can access. Then once a user is attached to that particular
responsibility he will be able to access and use those functionalities.
However another user with some other responsibility will not be able to
use the functionalities that are not attached to his responsibility.

Talking about functionalities, what are the different types of functionalities

that are offered by oracle application? The functionality count is
enormous, but if we are looking at the types, those will be:
 A screen, either a Form or a web page that allows us to navigate through
the data, and process certain tasks. These are called Functions.
 A Report / Concurrent process.

So every function opens up a Form / webpage that can be used to perform

a certain task / view some data. We will learn about the Reports in detail,
later in this book.

Menu
Let’s make sure we understand the different bits we learnt so far. There
are Functions that will let a user do a certain task. And there are
responsibilities that control the access of tasks/ functions. Now, let’s see
how, do we control the access to the tasks?

Here comes the Concept of Menus. A menu is a combination of functions.

Once a menu is defined, we attach that to the Responsibility. The
Responsibility is then attached to the users. As the user logs in, he will see
only those functions that are attached to the menu, and eventually to the
responsibility on which he is attached to.

Concurrent Requests
Let’s imagine a case where a user wants a report of all the employees who
have joined in the month of January last year, he might have to run some
program to query the database and generate the output for you. The
developer can create the program using a programming language,
however in order to make it available to the user, we must have an
interface where he goes and enters the required parameters and runs the
program. That interface is known as a concurrent request.

In a live instance of Oracle E-Biz, a lot of records get created, updated and
logged every second. Which means the system is busy all the time. To
reduce the load, Concurrent requests are run in a dedicated server which
runs parallel to the live database server, without disrupting the heavy load
on the database server. The concurrent requests also give a mechanism to
schedule the programs at a given intervals, which helps in checking /
reporting things or cleaning up garbage data periodically.

Request Set
Request set as the name suggests is a group of concurrent requests
clubbed together that can be run one after another. For an example, if a
user wants to run a program, load the output on to a remote server using
Unix Script and once both the programs complete successfully, he wants
another program to send the logs to the user’s email address. So this
needs three different concurrent requests, one to run the program, one to
load the output and the last one to mail it to the user.

If the user wants he can run it one after another, however he can also
create a request set where he defines the stages to be the three different
programs and then when he runs the request set, the system will execute
one after another in order in which they are staged.

Request Group
The concept of request group is exactly similar to that of Menus. Where
Menu is a combination of Functions, and Request group is a combination
of Requests/ Request sets. Like menus, request groups are attached to the
responsibility that limits the access to the various requests available for
the user.

Profile Option
As we know, Oracle E-Biz is highly scalable, in order to support a wide
variety of businesses. With each implementation, there will be some
preferences that are needed to be set, so that the system will translate the
business need from the preference. Those preferences are known as
Profile options. They can be set by the System administrator, and the
application refers to the preference values to take decisions.

Let’s take an example, in a firm, how do they want the person names to be
displayed in the forms and web? The application would like to know this in
order to show the name in that manner. We can just set the profile option
“HR:Display Person Name” as “Full name”; that tells the system to show the
name as full name. Similarly, if we wish to count the Unpaid Absences of
Employees then set the “BEN: Count Unpaid Absence” as Yes.
 CONFIGURATION
CONFIGURATION
One must follow some set of steps, in order to create a component /
object in application. Those steps are known as the Configuration steps. In
this section, we will discuss about the Configuration steps required for
creating System Administration Components.

Creating a Function
 Responsibility: System Administrator
 Navigation: Application -> Function

(Figure 2.1 – Defining Functions)

Creating a Menu
 Responsibility: System Administrator
 Navigation: Application -> Menu

(Figure 2.2 – Defining Menus)

Creating a Request Group

A request group, as explained earlier, is a group of requests combined
together. We attach the group to the responsibilities. Once attached a user
can execute only those requests that are part of the request group
attached to the responsibility in which the user has logged in. See Figure
2.3 – Defining Request Sets.
 Responsibility: System Administrator
 Navigation: Security -> Responsibility -> Request
 (Figure 2.3 – Defining Request Groups)

Creating a Responsibility
Now it’s time for a new responsibility. See Figure 2.4 – Defining
Responsibilities.
 Responsibility: System Administrator
 Navigation: Security -> Responsibility -> Define
 (Figure 2.4 – Defining Responsibilities)

Creating a User
To create a user, we need to login to Oracle applications, and we must
have the System Administrator Responsibility to do so. We should contact
the system administrators / Installation analysts to get one user created
first, so that we can log in and create other users.
 Responsibility: System Administrator
 Navigation: Security -> User -> Define
 (Figure 2.5 – Defining Users)

Monitoring a User
There will be instances in which we will need to monitor a specific set of
users, and see the current activities. To do so, one can use the monitor
user functionality given to the System administrator. See Figure 2.6 –
Monitoring Users.
 Responsibility: System Administrator
 Navigation: Security -> User -> Monitor
 (Figure 2.6 – Monitoring Users)

Steps:
 Query for the user, and it will list the current usage of the application of
the user.
 The Responsibility and form section tells us about the application and the
forms being used.
 The Time tells the length of the time, the user had been in that form /
responsibility
 The Oracle Process textbox tells us the Process id, of the Oracle process
being executed by the user.

There will be instances in which we will need to monitor a specific set of

users, and see the current activities. To do so, one can use the monitor
user functionality given to the System administrator. See Figure 1.17 –
Monitoring Users.

back to top

Administrating Profile Options

As discussed earlier, Profile options are the preferences that the system
uses to make decisions. So these options direct the way our application
behaves. Oracle E-Biz lists a set of Profile options that we need to define
for each module to work in a certain way.

There are six different levels at which we can attach Profile Options.
1. Site
2. Application
3. Responsibility
4. Server
5. Organization
6. User

The hierarchy follows the same order. Like the Responsibility level
overrides the option value given in the site level, and the Organization level
overrides the option value at the Responsibility level. The user level, being
the lowest overrides them all.

(Figure 2.7 – Profile Options)

Let’s see how to find and update a profile option. See Figure 1.8 – Finding
Profile Options.
 Responsibility: System Administrator
 Navigation: Profile -> System
 (Figure 2.8 – Finding Profile Options)
Steps:
 Check the level at which we want to see the Option value.
 Unless the level is Site, enter the name of the Object. Like if application is
checked, enter the name of the application.
 If we wish to see the values of Options with blank values in the particular
level, check the “Profile with No values” flag.
 Select the name of the profile, and press find.
 Once the option value is open, we can go and update the option values if
needed.
 We can also set few profile options in Functional Administrator
responsibility (Functional Administrator -> Core Services -> Profiles).

Creating Request Sets

A request set is a set of concurrent requests pooled together to run one
after another. Let’s discuss about the steps involved in creating a request
set.
 Responsibility: System Administrator
 Navigation: Concurrent -> Set

(Figure 2.9 – Defining Request Sets)

Steps:

CONCURRENT REQUESTS
The concurrent requests are the requests that can run in the system
without impacting the ongoing transactions. To elaborate, if a system is
live, then a lot of users might be using it at one point of time, and in that
period if we wish to run a report or run a process, then we can do it with
Concurrent requests without impacting the performance of the system.
Again, we can submit the request and keep on working on the regular
application tasks. The request will automatically get completed, and we
could check the results anytime later.

We can either submit a concurrent request or a set of requests combined

together, known as the request sets. Let’s see how.

Submitting a New Request

 A request set is a set of concurrent requests pooled together to run one
after another. Let’s discuss about the steps involved in creating a request
set.
 Navigation: View (menu) -> Request (menu)

(Figure 2.10 – Submitting New Requests)

Steps:
 It opens up the Find Request screen. See Figure 2.10 – Submitting New
Requests.
 Enter Submit a request to create a new Request
 The system asks, if we wish to submit a single request or a request set.
Choose single request
 It opens up the submit request screen
 (Figure 2.11 – Submit Requests)
 From the List of Values choose the name of the request, and press tab. See
Figure 2.11 – Submit Requests.
 It should open up all the mandatory and optional Parameters that are
needed for the request to run.
 The language of the output can be changed by clicking on the language
settings.
 The request can be scheduled for a later point in time. To do so, go to the
Schedule button, and select the schedule; else choose as soon as possible
 If we wish to print or email or fax the output, put the required information
in the Delivery options button
 Press Submit. Once submitted, the system assigns a REQUEST_ID for the
request and the Requests window opens.
 (Figure 2.12 – View Request Status)
 The requests window shows all request submitted by us / our group based
on the settings. See Figure 2.12 – View Request Status.
 There are four different phases of a request
 Pending: The request is either waiting to be picked up based on priority /
waiting for another request to be processed/ scheduled for later.
 Running: The request is running.
 Completed: The Request is complete.
 Inactive: The Request is not prioritized yet; waiting for the Concurrent
manager
 Based on the phases, there are different statuses that a request can have:
 For Child requests, the parent of the request shows the request that in
turn created this child request.
 The Hold Request Button pauses the processing of the request and
changes the Phase to Inactive – On Hold.
 Cancel request, cancels the reques
 View Details button shows the submitted parameters with all the
preferences on output and language as read only.
 Diagnostics button opens up a new window detailing the status of the
request.
 View output button opens up a new window with the Output in it.
 View Log shows the log file generated by the Process
 Only the Parent requests have the log and the output; that to only after
the request is completed
 While browsing through the log and output, we can either use the page
numbers to navigate or simply go to Tools menu -> Copy File to copy the
entire output/ log to an Internet Explorer or a Text file.

back to top

Finding a Request
Once the request is submitted, the request status and the output can be
checked anytime. Let’s see how to find a request. See Figure 2.13 – Find
Requests.

Navigation: View (menu) -> Request (menu)

 (Figure 2.13 – Find Requests)
 Once the Find request window is open, we have the following Options.
 Search all our completed requests by using ‘My Completed Requests’
 Search all our running requests by using ‘My Requests in Progress’
 Search all our request irrespective of any criteria by using ‘All my Requests’
 Search requests by
 Request Id
 Concurrent Program name
 Submitted / completed date
 Current status or phase
 Request submitted by
 Enter the number of days we want to look for. It queries back till that many
number of days and shows the requests.
 Press Find to find the requests based on the criteria added.
 Submitting a Request Set

(Figure 2.14 – Submitting Request Sets)

 Once we click on ‘Submit New Request’, we can choose Request Set this
time, rather selecting the Single request.
 This opens up a new screen for request sets. See Figure 2.14 – Submitting
Request Sets.
 Enter the name of the request set and press tab
 Then it will list the Programs listed under the request set.
 Start entering the Parameters for the program.
 If we wish to print or fax or mail the output, update the Delivery Options.
 Update the schedule in needed.
 Press submit
 Once submitted the find request window opens with the submitted
requests in there.
 SUMMARY
SUMMARY
In this chapter, we learnt about the Basics of system administrations. We
discussed various aspects of users, roles and responsibilities. We learnt
about Forms, functions, menus and profile options. Later, we discussed
the different steps to set up all the objects related to System
Administration. We learnt about Concurrent Programs, and the set up
steps to define one. We found out the steps to submit and access a
request. We also discussed about the request sets and the usage.