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)


A unique name for the function.

User Function Name

This name appears on the forms and web. This must be unique as well.


Any Description. It’s a free text

Properties Tab



The type of the function, we will discuss more about this later in this chapter

Maintenance Mode Support

This attribute determines if the menu is supported, when the application runs in the Maintenance mode. Unless it is very useful or a System Administrator types function, we should use the option ‘NONE’.

Context Dependency

Specifies whether the function depends on any context or not. If it does, then a user must have the context set in order to use this menu.

Form Tab


Form / Application

If it‘s a form function, we must add the form and the application name here.


The parameters to the Form function must be passed here.

Parameters should be separated by space.

Web HTML tab



This is for OAF pages type function. This can either be a static page or a Procedure. For Mobile applications, we can use a java class name to call the function.

Web Host Tab


Host Name

This is used in OAF pages. The URL is entered here.

Agent Name

The web agent determines the database to be used while calling the function.


The icon to be used in the function.


This is used only when the function uses Oracle workflow. If it is checked, then the system allows the notification recipients to respond back using email.

Encrypted Parameters

This functionality makes sure that the user cannot tamper the browser web access to use functionalities, other than going through the defined process. This flag makes the web addresses encrypted, so altering it, does not help.

Creating a Menu

  • ResponsibilitySystem Administrator
  • Navigation: Application -> Menu


 (Figure 2.2 – Defining Menus)


Name of the Menu; user does not see this menu name.

View Tree

Shows the menu in a tree structure, only after it is defined.

User Menu Name

The user name of the menu.

Menu Type

Choose one of these, based on requirement:

Standard: If the menu is going to be used in navigation forms.

Tab: If the menu will be used in SSHR as tabs.

Security: If the menu is going to be used for data security and to aggregate functions, This menu will not be available in Navigator Forms.


Any Description. It’s a free text.


This is a number that will be used by the system to sort the menu. So one menu / function with higher sequence appears after the ones in Lower sequence. It is better to use a sequence of 10, 20, 30... rather 1, 2, 3... Because it helps us to insert any new menu, in between two, if needed; without renumbering the existing sequence.


The Prompt that will appear on the navigator / web. It is always helpful to use prompt names with unique first letter, so that that alphabet can be used as a hot key for Key Board Shortcut.


This lists other menus, so that we can create a menu inside a menu. If user chooses this submenu, it opens the tree for the selected menu, for more options.


Attach the form function here. The one that will be called if the menu sequence is selected.


Any Description. It’s a free text. This text appears at the top of the navigation window.


This enables the user to use the menu. If this is not checked the menu is not available for use, unless some extra set of data security is applied.

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)


Name of the request group.


The application that owns the request group.


The request code identifies the request group uniquely.


Description of the request.


Choose the type as one of these:

Program: Include a concurrent Program.

Set: Include a request set.

Application: Include all the requests owned by the application.

Stage Function: Include a Staging / Loader function.


Name of the object, based on the type. For an example, If the selected type is program, include the program name.

Request Application

The application to which the object belongs to; auto populated.

Request Description

The Description of the object; auto populated.

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)


Name of the Responsibility


Name of the Application that will own the responsibility.


This is like an identifier. This is unique per application.


Any Description. It’s a free text.

Effective Dates

The dates within which the Responsibility will be available.

Available From

The type of navigator. A responsibility can be available through one type of navigator only. Use Mobile, if we are using Mobile apps with .mobi sites, and Oracle Applications for all others.

Data Group

Oracle Apps framework does not support data groups anymore. Leave blank, or use Standard.


The Menu attached to the responsibility.

Request Group

The request group attached to the responsibility.

Menu Exclusions

This is again for backward compatibility. This used to be used to exclude specific functions or menu from a responsibility. However the current day approach is to create a new menu if needed, rather excluding from here. Add the type menu / function and add the name of the object.

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)

User Name

The user name. Should be unique.


Should be within 5 to 30 characters long; and must have a number. Password cannot have username in it, and must not have repeating characters.

All Characters allowed; however it is better to use alphanumeric passwords, as they are more secure.

This is the initial password. Once entered, system prompts us to enter the password again for verification.

Once user logs in with the new password, he is asked to change the password right there with his initial log in.


Any Description. It’s a free text.


This is updated by the system, based on its validation. If the status is not active, the user can not log in. The three consecutive failed attempts, invalid passwords at the Definition etc make the status Invalid.

Person/ Customer/ Supplier

The Person/ Customer / Supplier, who uses this user. It’s optional. The list of values is populated from PER_ALL_PEOPLE_F.


The email id of the user.


The Fax Number of the user.

Password Expiration

Days: The maximum number of days within which the password must change.

Like, with in every 50 days, the user must change his/her password.


Accesses: The maximum possible logons to the application between the password changes.

Like, with in every 50 log on, the user must change his/her password.

Effective Dates

The start and end date of the user’s validity.


Select the responsibilities we want this user to have, enter a security group if any, and the dates as well.

Indirect Responsibilities

A user may inherit an indirect responsibility through membership of a group to which the responsibility has been assigned.

Securing Attributes

In few cases, we would like the user to see only filtered data. The filtration can be done here. Like, If we attach Earliest date as ’01-JAN-2010’; then the user once logs in will see the rows with data no earlier than that date. For this we will choose the attribute as “Earliest Date” and Value as ’01-JAN-2010’.

This filtration only applies to HTML based pages, not to forms.


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)


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

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)


  • 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)



The name of the Request set

Set Code

The request set code. This identifies the request set uniquely


The application that owns this request set


The description, free text


User who owns the request set

Active Dates

The request set is valid and can be used with in the given dates

Print Together

In case there are more than one requests that have print options enabled to print the output, checking this box ensures the system will wait until the last request is completed before starting to print

Allow Incompatibility

In some cases we might not want two different programs to be run together. For an example we do not want Program A to run when Program B is in running state. Then we can make Program A incompatible for Program B.

However the rules of incompatibility apply to single concurrent requests only.

Check this box, in case you want the incompatibility rules to be applied on related Request sets as well.

Define Stages



The serial number / stage number of the Program. The program with lowest serial number will be executed first


The name of the single concurrent request

Requests button

This window should show the related single concurrent request that is attached to the selected stage

Link Stages



The serial number of the program


Name of the single concurrent request


This should list the program to be invoked in case the current request completes successfully.


Similarly, what should be invoked if the current request completes with warning


The program which will be invoked in case the current one errors

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)


  •  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:


Normal, Scheduled, Waiting, Stand By


Normal, Terminating, Paused, Resuming


Normal, Cancelled, Terminated, Error, Warning


No Manager, Disabled, On Hold

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

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.