You can restrict users' access to submit and view concurrent requests.

Controlling Access to Concurrent Programs with Request Security Groups

A request security group is a collection of reports or concurrent programs. A System Administrator defines request security groups in order to control user access to reports and concurrent programs. Only a System Administrator can create a request security group.

• The reports and concurrent programs that may be selected by a user in Standard Request Submission belong to a request security group, which is a request group assigned to a responsibility.

  Attention: The use of request security groups is for backward compatibility only.

• The reports and concurrent programs that may be selected from a customized SRS form or window belong to a request security group that uses a code.

  See: Customizing the Submit Request Window using Codes.

Controlling Access to Concurrent Programs using Role-Based Access Control (RBAC)

RBAC allows administrators to have more granular control in securing data related on concurrent programs and requests.

Submitting Requests

Administrators can assign individual programs/sets, all programs/sets in a request group, programs/sets belonging to one or more applications, and so on, either to the user directly or to a role that can then be assigned to one or more users. For more information on RBAC, see: Overview of Access Control with Oracle User Management.

If applications are included in the request groups, all programs/requests sets that are created in these applications will also be automatically included. Please note that request submission applies to both programs and request sets.

The following types of "instance sets" can be used for assignment (but administrators can create new instance sets based on their needs):

• All programs in a particular request security group

• All request sets in a particular request security group

To enable this functionality, the following are seeded:

• Permission "Submit Request"

• Permission "View Request"

• Permission Set "Request Operations" containing the permissions "Submit Request" and "View Request"

• Object "Concurrent Programs"

• Object Instance Set "Programs that can be accessed"

• Object Instance Set "Request sets that can be accessed"

To grant access to a request security group to a role, follow these steps:

1. Define your role (User Management responsibility).

2. Define your request security group (System Administrator responsibility).

3. Define your grant (Functional Administrator responsibility).

   1. Enter a Name and Description (optional) for the grant.

   2. Enter the Security Context for the grant.

   3. Under Data Security, choose "Concurrent Programs" or "Request Sets" as the object. Click Next.

   4. For the Object Data Context, select "Instance Set" for the Data Context Type. Choose either "Programs that can be accessed" or Request Sets that can be accessed" as appropriate. Click Next.

   5. Review the Instance Set information. Under Instance Set Details, enter the request group and its application. Specifically, enter the request group name as Parameter 1 and the application short name as Parameter 2.

   6. Choose "Request Operations" as the permission set under "Set". Click Next.

   7. Review the grant information and save your work.

Note that there are two seeded grants for all users to account for request group assignments that already exist for legacy responsibilities. These are:

• Programs - Grant Defaults

• Request Sets - Grant Defaults

Viewing Requests

You can control users' access to viewing requests with RBAC.

Seeded "instance sets" allow administrators to grant:

• All requests submitted by a user

• All requests submitted by a user for a given application

• All requests belonging to a program submitted by a user

• All requests belonging to a request set submitted by a user (irrespective of the constituent programs' owning application)

to another user (or a group of users - via a role).

System administrators can create new "instance sets" based on their needs. They can grant access to requests (of a particular program/set) submitted by all users to a specific set of users. For example, say a given application's administrators group want to track all requests of a particular type or program submitted by business users. Then the following approach, to grant specific programs' requests to a group of users, can be used:

1. Create an instance set that selects all the requests belonging to the particular program irrespective of which user submitted it.

   For example,

   &TABLE_ALIAS.request_id in
       ( select cr.request_id
         from fnd_concurrent_requests cr, fnd_concurrent_programs cp
         where cr.concurrent_program_id = cp.concurrent_program_id
         and cr.program_application_id = cp.application_id
         and cp.concurrent_program_name = &GRANT_ALIAS.PARAMETER1)

   If you want to grant access to a set of programs instead of a single program, '&GRANT_ALIAS.PARAMETER1' can be replaced with a subquery that returns all the programs in a particular request group.

2. Create a grant to grant this instance set to (an existing) role, for example, "<Application> Administrator" role, and assign the program name to grant. Use the "Concurrent Requests" data object in creating this grant.

3. Ensure that the role is assigned to all users that should have access to these requests.

Limiting Active Requests by a User

As System Administrator you can limit the number of requests that may be active (status of Running) for an individual user. This ensures that a user cannot monopolize the request queue. For example, if a user with an Active Request Limit of 5 submits 20 requests, only 5 requests will be run at the same time. The remaining requests will be run when the number of active requests for the user drops below 5. Use the Profile Options window to set the Concurrent: Active Request Limit profile. To set a global limit for all users, set this option at the site level. You can then modify limits for individual users by setting this profile option at the User level.