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.

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.