SSHR and User Access

User Access Overview

SSHR uses the same security mechanisms as Oracle HRMS applications. By defining user profiles, security profiles, responsibilities, and menu structures, you can control who uses SSHR, which information they can access, and how they access it.

See: Security Overview, Oracle HRMS Configuring, Reporting, and System Administration Guide

This documentation identifies the key concepts relating to SSHR user access and security and to provide information on how to apply these concepts to address the needs of your enterprise.

Managing User Access in SSHR

The following section answers common questions on SSHR and user access and gives an overview of the functionality.

How can the HR Department control the self-service activities available to each user?

The security controls - responsibilities, menus, and security profiles - used in standard Oracle applications also apply to self-service users. The seeded SSHR menus (Employee Self Service, Manager Self Service, and Contingent Worker Self Service) are collections of functions intended for distinct audiences. The employee functions are constrained to operate only on the current self-service user's record; the manager functions allow the user to select an person from a list of available employees and workers and carry out the required function. The seeded SSHR responsibilities corresponding to each of these menus are useful for exploring the functionality delivered with the product, although they are not intended for production use. Instead, customers can configure their own variations of these menus and responsibilities, combined with appropriate security profiles, to restrict different groups of users to specific functions and employee groups. The Personalization Framework and Workflow Builder tools offer considerable flexibility in controlling the user's access to specific functions and require that users' transactions are approved before they are committed to the database. You can also control the user's access by configuring the base products. For example, Benefits eligibility profiles and enrollment requirements can determine which benefits an employee can select from within the Benefits Enrollment function.

How do I control access to employee information?

In addition to controlling which self-service functions a user can access, you can also control which employee records a user can access. Employees can only access their own personal information. Manager and HR professionals can access the personal information for selected employees. This access is controlled by security profiles which restrict different groups of users to accessing specific employee groups. When a manager selects a function from the self-service menu, the list of subordinate employees and workers is displayed in a hierarchy. If appropriate, you can permit managers to search for employees and workers in other business groups or organizations and if required, you can restrict this access to view-only and prevent managers from performing any transactions on employees outside of their business group.

But what happens if an employee wishes to release their personal information to a third party?

In certain situations, for example, after an applying for a different position, an employee may wish to release their personal information to a third party, for example, a new manager. In this case, the employee can use the Release Employee Information function to enable the new manager to access the employee's personal information.

How are users created for SSHR?

You can follow the standard Oracle procedures to create users and enable self-service by adding the self-service responsibilities to the user. Alternatively, you can use a batch process to create multiple users at one time. The batch processes are particularly useful if you need to create large numbers of accounts after initial installation, or for the new hire process.

SSHR and User Access

User Access and Security in Oracle SSHR

The following description gives an overview of the standard security mechanisms used in Oracle HRMS and discusses how they relate to Oracle SSHR.

Responsibilities

A responsibility combines low-level elements of user access configuration to control which functions the user can access (User Access to Functions) and on whom they can perform these actions (see User Access to People).

You define SSHR responsibilities in the same way as you define responsibilities for Oracle HRMS applications.

Note: When you define your responsibilities, make sure they are available from Oracle Self-Service Web Applications.

See: Responsibilities, Oracle HRMS Configuring, Reporting, and System Administration Guide

As an administrator, you can view a list of all owned responsibilities using the Responsibility Ownership functionality in SSHR. This functionality enables you to display a list of people with access to each of your owned responsibilities and revoke access to the responsibilities if appropriate.

See: Responsibility Ownership

User Access to People

The primary users of SSHR can be divided into two main groups: managers and employees (non-managers).

Employees (non-managers)

Employees and workers can only access their own employee records.

Managers

Managers can process the records for other employees and workers after selecting them from the Enter Process page. In the Enter Process page the manager can switch between View as:

Note: If the profile option HR:Expand Role of Contingent Worker is set to Yes, contingent workers will be able to manage other employees.

Person Search

The Enter Process page enables managers to perform a basic search for any employee within the underlying security profile. Alternatively managers can access the Advanced Search page to apply more detailed search criteria.

The manager can process employees and workers in the resulting list directly or add them to My List for future reference.

Note: You can extend the security profile for managers by enabling the Release Employee Information function.

See:Release Employee Information

Some functions enable managers and HR Professionals to search for ex-employees and terminated employees.

See:

This extended search functionality is controlled by a function parameter.

See: Menu Function Parameter Descriptions

Configuration Options

You can control user access to the People Search functions by excluding certain functions if required, for example, you can hide the Person Search function so that managers can only process the records for the employees and workers displayed in their hierarchy.

See: Defining User Access and Menus

You can also control how managers search for employees and workers by assigning profile options. For example, you can apply the HR: Cross Business Group profile option to enable managers to search across business groups. If you then set the HR: Restrict Transactions Across Legislations in SSHR profile to Yes, the names of the employees and workers in other legislations will be disabled.

Security Profiles

SSHR uses security profiles to control a user's access to person records. For example, a security profile can give a manager access to the records for all the employees and workers in the department.

See: Security Profiles, Oracle HRMS Configuring, Reporting, and System Administration Guide

Employees (non-managers) and contingent workers

You can use the default View All security profile for the corresponding business group for the employee (non-manager) responsibilities because the employee functions restrict the user to accessing only their own record.

Managers

If you allow your managers to access the Search functions, you must create suitable security profiles. For most SSHR managers, the most appropriate security profile is a profile based on a supervisor hierarchy. This type of security profile dynamically generates a list of available employees and workers based on either the supervisor hierarchy or the supervisor assignment hierarchy (starting with the current user). The advantage of using a profile of this type is that you can set up a single security profile and use it for multiple users. To activate supervisor security, select either the Restrict by Supervisor (person-based) option or the Restrict by Supervisor (assignment-based) option in the Security Profile window. In this case, the manager can see the records for the persons with at least one assignment for which they are the supervisor and the manager can also see the direct reports for this person.

See: Security Profiles by Supervisor Hierarchy, Oracle HRMS Configuring, Reporting, and System Administration Guide

You can choose to build your supervisor hierarchy based on individual assignments. This means that your SSHR manager can only view and update a person's record if the manager is the supervisor for the specific assignment.

See: Assignment-Level Security, Oracle HRMS Configuring, Reporting, and System Administration in Oracle HRMS

Multiple Assignments

If you wish to enable your managers to view and update multiple assignments for employees and workers, you can use the HR:Enable Multiple Assignments in SSHR system profile to allow this.

Note: If you are using assignment-based security, you must enable this profile option.

If the profile is set to No, managers can only view and update primary assignments. If the profile is set to Yes, managers can view and update only the assignments that are reporting to them through the security hierarchy.

Note: In the Security Profile window, on the User-Based Security tab, select the Primary Assignments Only check box to restrict managers to viewing and updating primary assignment information only.

See: Defining a Security Profile, Oracle HRMS Configuring, Reporting, and System Administration Guide

Alternatively, you can choose to disable the Search functions for an SSHR manager responsibility. In this case, you can assign the View All security profile to the users.

Release Information

You can supplement the list of people who appear in a security profile by enabling the Release Information function. With this function, users can allow other users (who are outside of the security profile) to access their records. Similarly, managers can use the Release Information to allow a second manager (who is outside of the security profile) to access the records for one of their employees.

To illustrate a typical use of this function, imagine that an employee wants to transfer to another organization. The new manager may need to review the employee's absence history before the transfer can take place. However, this manager may be outside the employee's current business group and would therefore, be restricted by HRMS security access. The manager cannot access the employee's data from a Person Search because of the defined security profiles. With the Release Information function, the employee granting access can search for the manager's name across all organizations and business groups and grant access to that person. This enables the manager to view the employee's absence history. However, you must ensure that the manager has a responsibility that satisfies the following conditions:

If you want managers in your enterprise to have the same privileges for granted employees as for other employees who work for them, you can simply enable the "Allow Granted Access" option on the security profile they use with their main Manager Self Service responsibility. Alternatively, you may choose to limit managers' capabilities with respect to granted employees. For example, you may restrict managers to selected views and not allow them to use functions such as Termination. To do this, disable the "Allow Granted Access" check box for the main security profile and enable the check box for a separate security profile with a reduced set of functions.

See: Release Information

User Access to Functions

You control user access to specific functions using function security. Functions are attached to menus which are then attached to responsibilities.

Navigation paths

The traditional navigation path for SSHR users is to select a function, for example, Personal Information or Change Manager, directly from a user menu. From SSHR 4.2, SSHR supports this approach but also introduces a new navigation path which uses the Actions pages.

Accessing functions from the Actions pages:

Instead of selecting a specific function from the menu, the user selects either the Personal Actions function (for employees and workers) or the Manager Actions function (for managers). SSHR displays a context-sensitive list of available functions.

Personal Actions

The Actions page displays a list of available functions for the employee or worker. To generate this context-sensitive list, SSHR takes the submenu defined in the HR: Personal Actions Menu profile option and excludes any legislation-specific functions that do match the legislation code of the user's business group.

Manager Actions

The manager is first presented with the Enter Process page from which they can select an employee assignment. They will then proceed to the Actions page which displays a list of functions available for the selected employee or worker. SSHR derives the list of functions by taking the submenu defined in the HR: Manager Actions Menu profile option and excluding any legislation-specific functions that do not match the legislation code of the selected person's business group.

Note: If the manager first selected their own record, the submenu is derived using the HR: Personal Actions Menu profile option.

Accessing functions directly from a menu:

Managers

When a user selects a manager function directly from the menu, they are first presented with the Enter Process page. From this page, they can select an employee for processing. The user is then taken, via the Effective Date page, to the corresponding web page for the function.

Note: Data security starts after the user has selected a person. If the function is specific to a legislation other than the legislation to which the selected person belongs, an error message is displayed.

Other Employees

When a user selects an employee function directly from the menu they are taken, via the Effective Date page if appropriate, to the corresponding web page for the function.

Note: Data security is checked after the user has selected a function. If the function is specific to a legislation other than the legislation to which the user belongs, an error message is displayed.

Access to Workflow Transactions

Workflow administrators can monitor all workflow transactions across the business areas in an enterprise. Now, depending on your business requirements, you can restrict a workflow administrator's access to specific workflow transactions using the HR Self Service Selected Person ID Instance Set. This object instance set uses security profiles to identify the data that workflow administrators can access. For example, you can use this feature to restrict an administrator's access to workflow transactions in a specific organization hierarchy or a business group. Similarly, you can restrict a human resources manager to view only HR transactions and a payroll executive to view only payroll transactions.

See: Restricting Access to Workflow Transactions

Legislation-specific Functions

Most SSHR functions are global and can be used on employees in any legislation. However, some functions are legislation-specific and must be restricted to employees in the corresponding legislation.

SSHR uses FND Data Security to enforce this restriction. A data security object has been defined on the combination of person and legislation and data security menus have been created for predefined functions. There is one data security menu for global functions and one for each legislation code. The predefined functions are associated with either the global data security menu or with one or more of the country-specific data security menus as appropriate.

Data security grants have been predefined associating each data security menu with the appropriate legislation code (or with all legislation codes in the case of the global menu). The effect of each grant is to enable the functions attached to the corresponding data security menu for people in business groups having the corresponding legislation code.

For example, a function on the global data security menu may be used with any employee but a function that is only on the US data security menu may be used only with employees in a US business group.

In addition to the data security menus that are available for predefined functions, there is a similar set of data security menus to which you can attach your custom functions. The data security grants are already in place.

See: Data Security Menus

Users and Responsibilities

You define SSHR users in the same way as you define users for Oracle HRMS applications.

See: Users Window, Oracle E-Business Suite System Administrator's Guide - Security

However, the Person field of the Users window is particularly important for SSHR as it acts as the link between the professional forms interface and SSHR. It ensures that the user name is linked to the correct person records. For example, if you were to create a user and assign an SSHR responsibility to this user, the correct employee records would only be displayed in SSHR if the user's name is entered in the Person field.

See: Responsibilities, Oracle HRMS Configuring, Reporting, and System Administration Guide

New User Registration

The New User Registration functions enable new users to register their own details and create their own users for SSHR. You can also add a user hook which generates the user name when the user clicks a button on the web page.

You can enable the New User Registration functions for both employees and non-employees. The non-employee registration form is usually used in conjunction with Advanced Benefits.

See: New User Registration

User Profiles

You apply user profiles to control how the SSHR application runs. You can set profile options at site level, application level, responsibility level, and user level. The individual profile options are specified in the sections on each module.

See: User Profiles, Oracle HRMS Configuring, Reporting, and System Administration

User Access to Functions

Manager and Employee Functions

You can control which functions employees, workers, and managers can access by adding or removing functions from the user menus. For example, you could restrict employee access to the Termination function by only including it in the Manager menu.

See: Defining User Access and Menus

Access Roles for Self-Service Actions

Access roles specify permission to view or update routed transactions, such as self-service actions. You manage access roles for self-service actions in the Maintain Roles window.

SSHR provides two predefined types that you can use to create access roles that govern update permissions in self-service actions:

By default, all users can update an action. If you define a role using the SSHR Update Allowed type and assign it to a user, everyone else can no longer update. If you define and assign a role using the SSHR Update Not Allowed type, everyone else can update.

You do not use both types in the same implementation. Your decision to use one type or the other depends on whether the majority of users require update privileges. If they do, use the Update Not Allowed type to remove edit privileges from the remaining users. If the majority do not require permission to update, use the Update Allowed type to grant edit permission to those who do. If your organization has 40,000 people, of whom only 80 require update privileges for self-service actions, it makes more sense to grant privileges to 80 people than to deny them to 39,920.

Note: Position control and budgeting features also use role types to set up roles for routing and approvals. Do not use the predefined role types of Line Manager, HR Manager, or Budget Manager with self-service actions.

See: Defining Workflow Roles for Transactions, Oracle HRMS Enterprise and Workforce Management Guide

Self-Service Menus and User Access

SSHR uses four types of menu: top-level menus, submenus, hidden submenus, and data security menus. The following section looks at each of these menus in detail.

The predefined menus are overwritten whenever an SSHR patch is applied so any changes you have made to the menus are lost. For this reason, you should create at least one top-level menu for employees and at least one for managers.

Note: You can avoid having to configure several similar menus by adding all employee and manager functions to each of your menus and then defining menu exclusions against the responsibility to exclude specific functions from groups of users.

See: Defining Menus for SSHR

Types of Menus

Top-level Menus

The top-level menus define the choices that the user sees on their menu when they log in to SSHR. For example, the top-level menu for the Employee Self-Service responsibility is the Employee Self Service menu.

See: Defining User Access and Menus

Submenus

Submenus group together functions in a logical group on the top-level menu, for example, the Professional Details functions are grouped together in the Manager Professional Details submenu. The predefined submenus for SSHR include:

Hidden Submenus

By attaching a submenu to the top-level menu without defining a prompt, you can assign functions to the responsibility but hide them from the user. This means that the user cannot select these functions directly. The following hidden submenus are predefined for SSHR:

SSHR uses these submenus to determine the availability of functions in other places. For example, the Manager Enter Process submenu controls the tabbed regions appearing on the Manager Enter Process page. The Manager Actions menu controls which functions are available on the Actions page for a manager to perform on other employees. The Personal Actions menu controls which functions are available to a user on the Personal Actions page. This menu also controls which functions are available from the Actions page when the manager selects their own record.

Data Security Menus

SSHR uses the data security menus to determine which functions are global and which are for specific legislations.

The data security menus for SSHR are:

Menus for Employees (Non-Managers)

If you create a new employee menu and want to use the Personal Actions functionality, you need to add the following submenu to your new menu:

If you intend that contingent workers use your new employee menu, add the Contingent Worker Personal Actions Menu (or your configured copy) instead of the Personal Actions Menu.

You must also add the following functions to your new menu:

You must also make sure that, for any responsibilities that use your new employee menu, the values for the following profile options match the names of the personal actions submenus you selected above.

Menus for Managers

If you create a new Manager menu and want to use the Manager Actions functions, you need to add the following submenus to your new menu:

If you intend that contingent workers use your new manager menu, add the Contingent Worker Personal Actions Menu (or your configured copy) instead of the Personal Actions Menu.

You must also add the following functions to your new menu:

You must also make sure that, for any responsibilities that use the new manager menu, the values for the following profile options match the names of the manager actions and personal actions submenus you selected above.

Predefined Self-Service Responsibilities and User Menus

SSHR modules are accessible from predefined responsibilities, each with a corresponding top level menu.

In this version of SSHR, the predefined responsibilities are:

The predefined US Federal responsibilities are:

The predefined responsibilities for the HR Foundation application are:

The additional responsibilities provided by OSSWA (Oracle Self-Service Web Applications are:

Note: These responsibilities are provided as a starting point only. You should create your own responsibilities and menus using the predefined SSHR responsibilities and menus as examples. Otherwise, your changes may be lost during an upgrade.

See: User Access and Security

User Menus

SSHR includes several predefined top-level menus:

US Federal SSHR includes predefined top-level menus:

The Employee Self Service menu contains the functions that employees can perform on their own records, for example, the Personal Details function. The Manager Self-Service menu contains the same functions as the employee menu plus additional functions that the manager can carry out for the employees for whom they are responsible.

The HR Professional menu is available for HR professionals who wish to view summarized information on employees.

You can also use the following menu for administration purposes:

See: Self-Service Menus

Navigation Options for Functions

Both employees and managers can access functions in one of two ways. They can either use the above menus and select the function using the corresponding menu option or they can display the Actions page through the Manager Actions or Personal Actions menus and select the required function from the list of available actions.

Legislation-specific Menus

SSHR provides legislation-specific menus to give users access to the functions that are specific to a country.

See: Self-Service Menus

Responsibility Ownership

The Responsibility Ownership function enables you (as an administrator or implementor) to view a list of owned responsibilities. You can expand the list of responsibilities to display the menus and functions attached to each responsibility. From the list of responsibilities, you can see the number of people with access to each responsibility both within the organization (in other words, within your HR security access environment) and outside of the organization (outside of your HR security access environment). By clicking on the number of people, you can display the user ID and other information for each user with access to the responsibility and if required, you can revoke access directly in the self-service page. If you choose to revoke access to a responsibility, the affected user receives notification of the change.

Additional Information: When the application generates the notification, it also triggers a business event. You can subscribe to this business event and call Application Programmatic Interfaces (APIs) to end date the responsibility access.

See: Event Subscriptions, Oracle Workflow Developer's Guide

You can use the Responsibility Ownership functionality as an extra security measure to review and restrict the number of people outside of your organization with access to particular responsibilities. You can also monitor the number of people with access to each responsibility for auditing purposes.

Menu and Function Names

You access this module can be accessed from the following menus and functions:

User Menu Name Function Name
Responsibility Ownership Responsibility Ownership

Workflow

The workflow details for this module are listed below:

Workflow Process Display Name:

Not applicable

Configurable Workflow Attributes:

Not applicable

Configurable Profile Options

Not applicable

Additional Configuration Steps

  1. Before you can use the Responsibility Ownership function, you must create data security grants to link responsibilities to your users.

    See: Creating Data Grants for Responsibility Ownership

    See: Create Data Grant (Oracle E-Business Suite System Administrator's Guide - Security)

  2. You should create code to subscribe to the following business event:

    • oracle.apps.per.selfservice.respowner.revoke_access

    This code should trigger the fnd_user_resp_groups_api.update_assignment API to end date the responsibility assignment.

    See: Sample Code for Subscribing to Business Event (Responsibility Ownership)

Sample Code for Subscribing to Business Event - Responsibility Ownership

If you are using the Responsibility Ownership function, you should write a PL/SQL code to subscribe to the following business event:

Important: The code should call the following Application Programmatic Interface (API) which end-dates the responsibility assignment:

Sample code is provided below. You can use this as a basis for your own code.

Creating a Sequence (CUST_RESP_OWNER_ARCHIVE_SEQ)

CREATE SEQUENCE CUST_RESP_OWNER_ARCHIVE_SEQ
    MINVALUE 1
    MAXVALUE 999999999999999999999999999
    START WITH 1
    INCREMENT BY 1
    CACHE 20;

Creating a Table (CUST_RESP_OWNER_ARCHIVE)

create table CUST_RESP_OWNER_ARCHIVE
(REVOKE_ID varchar2(25),
USER_ID NUMBER(10),
RESPONSIBILITY_ID NUMBER(10),
REVOKE_JUSTIFICATION varchar2(250),
REVOKE_DATE Date,
REVOKED_BY NUMBER(10),
STATUS varchar2(250));

Creating a Package Header

CREATE OR REPLACE  PACKAGE cust_resp_owner_bevent AUTHID CURRENT_USER AS
FUNCTION revoke_access_wfevent_subscrb
( p_subscription_guid in raw,
p_event in out NOCOPY wf_event_t)
RETURN VARCHAR2;
END cust_resp_owner_bevent;
/

Creating Package Body

CREATE OR REPLACE  PACKAGE BODY cust_resp_owner_bevent AS
PROCEDURE archive_data
(p_user_id IN NUMBER,
p_user_name IN VARCHAR2,
p_resp_id IN NUMBER,
p_resp_appl_id IN NUMBER,
p_security_group_id IN NUMBER,
p_justification IN VARCHAR2,
p_status IN VARCHAR2) IS
l_login_person_id number;
BEGIN
l_login_person_id := fnd_global.user_id;
INSERT INTO CUST_RESP_OWNER_ARCHIVE
(REVOKE_ID,
USER_ID,
RESPONSIBILITY_ID,
REVOKE_JUSTIFICATION,
REVOKE_DATE,
REVOKED_BY,
STATUS)
VALUES
(CUST_RESP_OWNER_ARCHIVE_SEQ.nextval,
p_user_id,
p_resp_id,
p_justification,
sysdate,
l_login_person_id,
p_status);
EXCEPTION
WHEN OTHERS THEN
NULL;
END archive_data;
PROCEDURE remove_resp
(p_user_id IN NUMBER,
p_resp_id IN NUMBER,
p_resp_appl_id IN NUMBER,
p_security_group_id IN NUMBER,
p_error OUT VARCHAR2,
p_justification IN VARCHAR2) IS
cursor csr_user_name(v_user_id in number) is
select user_name
from fnd_user
where user_id = v_user_id;
cursor csr_user_resp_groups is
select description
from fnd_user_resp_groups
where user_id = p_user_id
and responsibility_id = p_resp_id;
l_user_name fnd_user.user_name%type;
l_owner_name fnd_user.user_name%type;
l_description varchar(2000);
l_login_person_id number;
BEGIN
l_login_person_id := fnd_global.user_id;
OPEN csr_user_name(p_user_id);
FETCH csr_user_name into l_user_name;
CLOSE csr_user_name;
OPEN csr_user_name(l_login_person_id);
FETCH csr_user_name into l_owner_name;
CLOSE csr_user_name;
OPEN csr_user_resp_groups;
FETCH csr_user_resp_groups into l_description;
CLOSE csr_user_resp_groups;
BEGIN
Fnd_User_Resp_Groups_Api.update_assignment(
USER_ID => p_user_id,
RESPONSIBILITY_ID => p_resp_id,
RESPONSIBILITY_APPLICATION_ID => p_resp_appl_id,
SECURITY_GROUP_ID => p_security_group_id,
START_DATE => SYSDATE - 2,
END_DATE => SYSDATE - 1,
DESCRIPTION =>
substr('RO:'||l_owner_name||':'||l_description,1,240)
);
p_error := 'Status SUCCESSFUL!';
EXCEPTION
WHEN OTHERS THEN
p_error := SQLERRM;
END;
--Helpdesk.remove_resp
-- (p_username => l_user_name,
-- resp_code => to_char(p_resp_id),
-- p_error => p_error,
-- p_description =>
--substr('RO:'||l_owner_name||':'||l_description,1,240));
archive_data(
P_USER_ID => p_user_id,
P_USER_NAME => l_user_name,
P_RESP_ID => p_resp_id,
P_RESP_APPL_ID => p_resp_appl_id,
P_SECURITY_GROUP_ID => p_security_group_id,
p_justification => p_justification,
p_status => p_error
);
EXCEPTION
WHEN OTHERS THEN
NULL;
END remove_resp;
FUNCTION revoke_access_wfevent_subscrb
( p_subscription_guid in raw,
p_event in out NOCOPY wf_event_t)
RETURN VARCHAR2
IS
I number := 0;
usrIdCnt number := 0;
l_error varchar2(2000) := null;
BEGIN
usrIdCnt := to_number(p_event.GetValueForParameter('USER_COUNT'));
FOR I IN 1 .. usrIdCnt LOOP
remove_resp
(p_user_id =>
to_number(p_event.GetValueForParameter('USER_ID'||to_char(I)))
,p_resp_id => to_number(p_event.GetValueForParameter('RESP_ID'))
,p_resp_appl_id =>
to_number(p_event.GetValueForParameter('RESP_APPL_ID'))
,p_security_group_id => to_number(p_event.GetValueForParameter
('SECURITY_GROUP_ID'))
,p_error => l_error
,p_justification => p_event.GetValueForParameter('MESSAGE'));
END LOOP;
COMMIT;
RETURN 'SUCCESS';
EXCEPTION
WHEN OTHERS THEN
WF_CORE.CONTEXT('PER_RESPOWNER_UTIL_SS',
'revoke_access_wfevent_subscrb', p_event.getEventName(),
p_subscription_guid);
WF_EVENT.setErrorInfo(p_event, l_error);
RETURN 'ERROR';
END revoke_access_wfevent_subscrb;
END cust_resp_owner_bevent;
/

For more information on using PL/SQL, see: Overview of Using PL/SQL in Applications, Oracle E-Business Suite Developer's Guide

Subscribing to the Business Event

Use the Workflow Administrator Web Applications responsibility and Events page to enable the business event: oracle.apps.per.selfservice.respowner.revoke_access. The revoke access feature of the Responsibility Ownership functionality works only if you subscribe to the business event

Follow these steps to subscribe to the business event:

Enabling the Business Event

  1. Log on to the Workflow Administrator Web Applications responsibility.

  2. Click Business Events. The Events page appears.

  3. In the Events page, search for the business event: oracle.apps.per.selfservice.respowner.revoke_access.

  4. Click Update.

  5. In the Update Event page, select the Enabled status and click Apply.

Creating Subscription for the Business Event

  1. In the Events page, search for the business event: oracle.apps.per.selfservice.respowner.revoke_access.

  2. Click Subscription. The Subscriptions: Event: oracle.apps.per.selfservice.respowner.revoke_access page appears.

  3. Click Create Subscription. The Create Event Subscription page appears.

  4. Select the instance name.

  5. Select the event filter: oracle.apps.per.selfservice.respowner.revoke_access

  6. Enter 10 in the Phase field.

  7. Select Enabled as the Status.

  8. Select Message as the Rule Data.

  9. Select custom as the Action Type.

  10. Click Next.

  11. In the PL/SQL Rule Function, enter the PL/SQL rule function in the following format: <package_name>.<function_name>

    for example, cust_resp_owner_bevent.revoke_access_wfevent_subscrb

  12. Enter the Owner Name: SSHR.

  13. Enter the Owner Tag: PER.

  14. Click Apply.

Creating Data Grants for Responsibility Ownership

Data grants enable you to control access to data in the data security system. When you create a data grant, you grant access to a database object to a user. In the case of the Responsibility Ownership function, you use data grants to grant responsibility ownership to a user. The following graphic illustrates the concept of data grants:

Data Grants for Responsibility Ownership:

the picture is described in the document text

The data grant links the user (grantee) to a specific data set instance (row in the data object). In addition, you link a function set to the user which enables the user to access particular functionality (in this case, the Responsibility Ownership functionality).

For information on using data grants for other purposes, see: Overview of Data Security (Oracle E-Business Suite System Administrator's Guide - Security).

To create a data grant for the Responsibility Ownership

  1. First identify which users should be granted ownership of responsibilities. These users would have an administrative role, for example, an HR Manager, Finance Manager, or System Administrator.

  2. Use the Functional Administrator responsibility to create grants.

    1. Select the Grants tab.

    2. From the Grants page, click Create Grant to initiate the creation process and define the data grant.

    3. In the Name field, enter a descriptive name for the grant, for example, <responsibility name>-Ownership. You can also enter a description.

    4. Specify the effective date for the grant.

      Navigate to the Security Context region to define the context for applying the grant.

    5. In the Grantee Type field, select Specific User.

    6. In the Grantee field, enter the user ID of the person who you are designating as the owner of the responsibility.

      Navigate to the Data Security region.

    7. In the Object field, enter the following delivered object:

      • FND_USER_RESP_GROUPS

        Note: Oracle provides this object for use with the Responsibility Ownership functionality.

    8. For the purpose of the Responsibility Ownership function, you must create a data set that grants access to a specific instance in the object table. Select this option (Instance) and continue to the next page to enter the instance information.

    9. The data set instance comprises three segments of information. Enter the information, leaving the remaining fields blank:

      Primary Key Example
      Responsibility ID 50101
      Application ID 800
      Security Group ID 0

      Note: To determine the information for the data set, query the user in the Users window and select Help > Diagnostics > Examine from the Responsibilities block. Query the following fields in the Examine Field and Variable Values window:

      • RESPONSIBILITY_ID

      • RESPONSIBILITY_APPLICATION_ID

      • SECURITY_GROUP_ID

    10. In the Set field, enter the delivered set PRIMARY_OWNER.

      Note: Oracle provides this function set for use with the Responsibility Ownership functionality.

      In this case, a function set is a data security menu containing the Responsibility Ownership function.

    11. Click Finish to complete the data grant creation process. The desginated owners can now log on to SSHR and use the Responsibility Ownership function to administer and control access to their responsibilities.

      See: Responsibility Ownership

    You should repeat steps 1 through 11 for each responsibility that you want to review and maintain.

Restricting Access to Workflow Transactions

You can restrict a workflow administrator's access to specific workflow transactions, depending on your business requirements. To restrict access to workflow transactions, you create a grant for the Workflow Item Attribute Values object using the Functional Developer responsibility.

Prerequisites

Before you define restrictions to access workflow transactions, ensure that you:

  1. Set up users and responsibilities to use Oracle SSHR.

  2. Assign the Workflow Administrator responsibility to users to monitor workflow transactions.

  3. Set up security profiles to give access to restricted set of information.

  4. Set the HR: Security Profile option at the responsibility level for the Workflow Administrator responsibility.

To restrict access to workflow transactions

  1. Log on to the Functional Developer responsibility.

  2. Search for the predefined Workflow Item Attribute Values (WF_ITEM_ATTRIBUTE_VALUES) object.

  3. Click the Update icon to navigate to the Update Object page.

  4. Click Create Grant on the Grants tab to initiate the creation process and to define the grant.

  5. On the Define Grant page, enter the following details:

    • In the Name field, enter a descriptive name for the grant.

    • Specify the effective date for the grant. Navigate to the Security Context region to define the context to apply the grant.

    • In the Grantee Type field, you can select a single user, a role, or global (all users and roles).

    • In the Responsibility field, specify a Workflow Administrator responsibility to apply the grant to that responsibility.

    • In the Object field, select the delivered object Workflow Item Attribute Values

      Note: Oracle provides the Workflow Item Attribute Values object to restrict access to workflow transactions.

  6. On the Grant: Select Object Data Context page, select the HR Self-Service Selected Person ID Instance Set (HRSS_WF_ATTR_PERSONID_INSTSET) to create a data set that grants access to a specific instance in the object table.

  7. On the Grant: Define Object Parameters and Select Set page:

    1. Review the definition of the grant.

    2. In the Set field, enter the delivered Business workflow item attribute permission set (WF_ADMIN_ITEM_ATTR_PSET) to define the grantee's access.

  8. Click Finish to complete the grant creation process. The designated workflow administrators can administer only the workflow transactions that they can access.

You must repeat these steps for each workflow administrator responsibility that you want to review and maintain.

Note: If users in your enterprise perform multiple roles such as a workflow administrator and a HR manager, then ensure that the users have the appropriate workflow responsibility to view their workflow transactions. For example, as a workflow administrator, the user must be able to view HR transactions.

SSHR User Accounts

Batch Creation of User Accounts

Every Oracle HRMS user needs to be registered with a user name, password and responsibility. The creation or deletion of these user accounts can often be time consuming, particularly if you are restricting a user's access with a responsibility associated with a security profile and a menu.

A set of concurrent programs have been created for Oracle HRMS applications to automate the creation and management of large groups of user accounts. These programs are particularly useful if you have to create a large number of user accounts at initial installation, for managing new hire user accounts, or for managing accounts for terminated employees.

Note: The creation of users with effective dates in the future is not supported.

The concurrent programs are:

Before you can use the concurrent programs however, you must write custom logic to reflect your enterprise's unique business rules. A user hook in the hr_user_acct_api is provided for you to do this.

You can find sample user hook code in the following package:

Features of the Create Batch Users Process

The Create Batch Users process only creates new responsibilities or profile option values for the new responsibility you create in the batch. This is for Oracle HRMS Applications only. The batch process does not create security profiles either. However, if you create a security profile, in Oracle HRMS, you can assign the security profile to a new responsibility that is created for a user in the batch process. The batch process does not create security attributes for a responsibility or a user.

A naming convention you might use is email ID with a responsibility name. For example, email ID JSMITH associated with the Manager Self Service responsibility could be JSMITH_MSS. If you have set up security profiles for managers in Oracle HRMS you can associate the security profile name to a user, a responsibility and a security profile. For example, the SEC_PF security profile could be JSMITH_MSS_SEC_PF.

You can create a template responsibility for the batch process. If you create a template responsibility, or use the predefined Manager Self Service responsibility, you can code a new responsibility created by the user hook to inherit the template responsibilities attributes. You can then overwrite the template responsibilities attributes, by setting values in the communication area, hr_user_acct_utility, of the API.

Creating User Accounts

Creating Batch User Accounts with Concurrent Programs

To create batches of users you must first write user hooks with your own custom logic.

See: Writing User Hooks to Create Batch User Accounts.

When you have created user hooks, you can run a set of concurrent programs to manage the batch creation of users on an ongoing basis.

You run the concurrent programs from the Submit Requests window.

To create batch user accounts with concurrent programs

  1. Run the User Account Employee Extract Process

    This program extracts employee records and creates a batch file of user accounts to be created or deactivated.

  2. Run Data Pump Engine

    This program uses the batch from the employee extract process and calls the HR API to create or deactivate user accounts.

  3. Submit Data Pump Batch Exceptions Report

    This program reports errors in the Data Pump Engine.

User Account Employee Extract Process

This extract process produces output records which are used by the Data Pump Engine. The Data Pump Engine calls the hr_user_acct_api to create or deactivate user accounts.

The batch name is written to the HR_PUMP_BATCH_HEADERS table. The extracted employee records are written to the HR_PUMP_BATCH_LINES table. The batch line table has defined generic attributes but for each API, the Data Pump generates a view on the HR_PUMP_BATCH_LINES table to reflect the parameters of the API.

The specific views tailored for the hr_user_acct_api are:

Note: You must use a meaningful batch name. For example, run type and date range or another parameter. The batch name is the only way you can identify which batch to select in the Employee Data Pump process and the Data Pump Batch Exceptions Report processes.

To run the user account employee extract process

  1. Access the User Account Employee Extract Process concurrent program.

  2. Enter a batch name to identify the batch.

  3. Enter the following date input parameters:

    • Start Date

      defaults to SYSDATE. This parameter sets the start date from which the records are extracted

    • End Date

      defaults to SYSDATE. This parameter is used in conjunction with the start date parameter to set a date range for the extraction of the records

  4. Enter the following organization input parameters:

    • Organization

      this parameter comprises a list of all the business group organizations that the responsibility is associated with. If you select an organization from the list of values, the program only extracts records from the selected organization.

    Note: If you enter values in the Organization parameter, they are superseded by any values you enter in the Organization Hierarchy, Organization Hierarchy Version, and Parent Organization parameters. These parameters always take precedence and replace the values entered in the organization parameter and work together as a set.

    • Organization Hierarchy

      organization hierarchy name for the responsibility's business group. This parameter contains an list of all the organizations hierarchies in the business group.

    • Organization Hierarchy Version

      organization hierarchy version for the responsibility's business group. This parameter contains an list of the organization hierarchy versions selected in the organization hierarchy parameter.

    • Parent Organization

      parent organization within the hierarchy. Selecting the parent organization will extract records from this organization and any organizations below the parent organization.

  5. Enter the Run Type input parameters by selecting a processing option from the list of values. The processing options are:

    • Create User Account for New Hires

      selects all employees hired between the start date and end date within the organization or organization hierarchy. This run type is used on an ongoing basis.

    • Create User Accounts for All Employees

      selects all employees as of the end date, within the organization or organization hierarchy. The start date parameter will be ignored and employees terminated before the end date will not be selected either. This run type is used on the initial implementation and is usually used once.

    • Inactivate User Account for Terminated Employees selects all employees terminated between the start date and end date parameter within the organization or organization hierarchy. Once selected, the user account for the terminated employee or worker is end dated. This run type is used on an ongoing basis to end date accounts for terminated employees and workers within the date range.

    • Create and Inactivate User Accounts runs two queries. The first query selects all employees and workers hired between the start date and end date within the organization or organization hierarchy. The second query selects all employees and workers terminated between the start date and end date within the organization or organization hierarchy. This run type is used on an ongoing basis.

    Note: Each employee or worker extracted from the database is recorded in the hr_pump_batch_line table. The hrdpv_create_user_acct view has been defined to map create user accounts to the hr_pump_batch_line table. The hrdpv_update_user_acct view has been defined to map inactivate user accounts to the hr_pump_batch_line table. You can access these views because the API column name is used to identify the record rather than the generic names used in the hr_pump_batch_lines table.

Data Pump Engine

The Data Pump Engine will call the hr_user_acct_api to perform data validation and loading operations. The employee data is recorded in the hr_pump_batch_lines table.

Note: You must run the User Account Employee Extract Process before you run the Data Pump Engine process. The Data Pump Engine depends on the batch id the User Account Employee Extract process creates.

To run the Data Pump Engine concurrent program:

  1. Access the Data Pump Engine concurrent program.

  2. Enter the following parameters:

    • Batch Name

      you must enter the same batch name as you did in the Employee Extract Process. The Batch Name is the only information you have to identify which batch to run

    • Validation Mode

      you can set two values, YES or NO. A YES value enables you to review errors in the batch, or related records in a batch, and change them before any are committed to the database.

      A NO value will commit the data to the database if there are no errors. If there are errors the data will not be committed to the database and you can fix the errors and rerun the batch.

      DataPump will set the Line Status to one of the following values:

      • E - Error

      • C - Completed

      • U - Unprocessed

      • V - Valid

    See: Oracle HRMS Data Pump, Oracle HRMS Implementation Guide

Employee Data Pump Exceptions Report

Each person record is recorded in an individual batch line. The data pump exceptions report will show whether the error is from the batch header or batch line. You can identify which person record is in error from the person id in the exception report.

Note: You must run the User Account Employee Extract Process before you run the Data Pump Engine and Data Pump Batch Exception Report processes. The Data Pump Engine and Data Pump Batch Exception Report processes depend on the batch id the User Account Employee Extract process creates.

To run the Data Pump Batch Exceptions report:

  1. Access the Data Pump Process Exceptions Report concurrent program.

    Note: You can run the Data Pump Engine and Data Pump Batch Exception Report processes in sequence. See: Overview of Concurrent Processes, Oracle E-Business Suite System Administrator's Guide - Security

    See: Oracle HRMS Data Pump, Oracle HRMS Implementation Guide

Writing User Hooks for the Batch Creation of User Accounts

Before you write your user hook, you must review your user population and create a standard user name format, responsibility, and security profile for your enterprise. When you have defined a standard and created any security profiles or security groups you need, you can begin to write your user hook.

You can create a template responsibility for the batch process. If you create a template responsibility or use the predefined Manager Self-Service responsibility, you can code a new responsibility created by the user hook to inherit the template responsibilities attributes. You can then overwrite the template responsibility's attributes by setting values in the communication area of the API, hr_user_acct_utility.

You can find sample user hook code in the following package:

To set up the prerequisites for writing user hooks

  1. Create a security profile in Oracle HRMS and, using your naming standard, associate the security profile and responsibility to a new user in your user hook code.

  2. Implement security groups to manage security profiles with the Enable Security Groups profile option. By implementing security groups, you can associate more than one security profile to a single responsibility.

    Note: Before you write user hooks, run the Security List Maintenance concurrent process. This ensures that the security profiles work.

    Note: If you plan to use security groups in a responsibility defined for use in Oracle Self-Service Web Applications, or plan to create a new responsibility for use in Oracle Self-Service Web Applications, set the Enable Security Groups profile option at the application level: Oracle Self Service Web Applications.

  3. Set up a guest user account in Oracle Applications by setting the GUEST USER PASSWORD profile option. This must be in the format <username/password>. You can obtain and verify the guest user account with your Database Administrator.

  4. Use the Define System Profile Option Value in System Administrator responsibility to set a security profile at Site or Application level. This is necessary because security profile option values can be set at Responsibility or User level with the batch process.

    Note: The sample user hook is called hrhksmpl.pkb and each code block is documented. You can also find a copy of the sample in the following directory $PER_TOP/patch/115/sql.

    See: API User Hooks, Oracle HRMS Implementation Guide

    See: Sample Code, Oracle HRMS Implementation Guide

Tables Updated in the Batch Process

The batch process inserts records into the following FND tables:

The batch process automates the functionality of the Define User Form and inserts records into the following FND tables:

Note: Security attributes for a user cannot be created in the batch process

The batch process automates the functionality of the Define Responsibility Form and inserts records into the following FND tables:

Note: Security attributes for a responsibility cannot be created in the batch process

The batch process automates the functionality of the Profile Option Value Form and inserts records into the following FND table:

To write batch user hooks with your own custom business logic

  1. To create batches of users you need to write PL/SQL programs in the user hooks of the following API:

    • hr_user_acct_api

    This API contains two procedures:

    • hr_user_acct_api.create_user_acct

      used to create a new user

    • hr_user_acct_api.update_user_acct

      used to inactivate user accounts, for example on termination of an employee or worker

To set up the Create User API procedure

  1. Write a PL/SQL program to communicate to the API the user name, password, responsibility, and profile to use when it creates a new user account for the employee or worker in the process.

    There are two user hook points in the create user procedure:

    • hr_user_acct_bk1.create_user_acct_b

      before-process hook point

    • hr_user_acct_bk1.create_user_acct_a

      after-process hook point

    Use the before-process hook for the PL/SQL program. The program enters these values into the global variables or record structures in hr_user_acct_utility.

    Note: You can supply passwords for the new user account or leave the API to generate a random string. The string will be in an 8 character alphanumeric format.

  2. Write a PL/SQL program for the after-process hook if you leave the API to generate a password. The program must save the password of the new user account to a file that can be accessed by a system administrator. This is necessary because the password created by the API is encrypted when it is saved to the FND_USER table in the database. You must capture the password before it is encrypted so that you can notify employees of their initial password.

    Note: If you supply a password, you may not need to write a user hook for this after-process hook point.

To set up the Update User API procedure

The update user API procedure is used to inactivate employees. The API end dates the employees record in the FND_USER and FND_USER_RESP_GROUPS tables and is not meant for general purpose update.

There are two user hook points in the update user procedure:

To carry out the remaining steps

  1. Compile the custom package you have created after you have written your user hooks.

  2. Register and link your custom package procedures to the appropriate API user hooks when you have compiled the package.

    See: API User Hooks, Oracle HRMS Implementation Guide

    A sample script to register and link your custom package and procedures is provided below.

    Sample code

    DECLARE

 ln_api_hook_call_id NUMBER;

 ln_object_version_number NUMBER;

 ln_api_hook_id NUMBER;

 

  BEGIN

 

 -- get api_hook_id for the seeded before process user hook package procedure

 SELECT ahk.api_hook_id

 INTO  ln_api_hook_id

 FROM  hr_api_hooks ahk

   ,hr_api_modules ahm

 WHERE ahm.module_name = 'CREATE_USER_ACCT'

 AND ahm.api_module_type = 'BP'

 AND ahk.hook_package = 'HR_USER_ACCT_BK1'

 AND ahk.hook_procedure = 'CREATE_USER_ACCT_B'

 AND ahk.api_hook_type = 'BP'

 AND ahk.api_module_id = ahm.api_module_id;

 

 -- insert a row into HR_API_HOOK_CALLS for before process user hook custom package procedure

 

 hr_api_hook_call_api.create_api_hook_call(

  p_effective_date => to_date('02/02/2000', 'DD/MM/YYYY'),

  p_api_hook_id   => ln_api_hook_id,

  p_api_hook_call_type => 'PP',

  p_sequence   => 1,

  p_enabled_flag  => 'Y',

  p_call_package  => 'MY_USER_ACCT', -- your custom package name

  p_call_procedure => 'CREATE_USER_ACCT_B', -- your custom package procedure name

  p_api_hook_call_id  => ln_api_hook_call_id,

  p_object_version_number => ln_object_version_number

 );

 

 

 -- get api_hook_id for the seeded after process user hook package procedure

 SELECT ahk.api_hook_id

 INTO  ln_api_hook_id

 FROM  hr_api_hooks ahk

   ,hr_api_modules ahm

 WHERE ahm.module_name = 'CREATE_USER_ACCT'

 AND ahm.api_module_type = 'BP'

 AND ahk.hook_package = 'HR_USER_ACCT_BK1'

 AND ahk.hook_procedure = 'CREATE_USER_ACCT_A'

 AND ahk.api_hook_type = 'AP'

 AND ahk.api_module_id = ahm.api_module_id;

 

 

 -- insert a row in HR_API_HOOK_CALLS for after process user hook custom package procedure

 hr_api_hook_call_api.create_api_hook_call(

  p_effective_date => to_date('02/02/2000', 'DD/MM/YYYY'),

  p_api_hook_id   => ln_api_hook_id,

  p_api_hook_call_type => 'PP',

  p_sequence   => 1,

  p_enabled_flag  => 'Y',

  p_call_package  => 'MY_USER_ACCT',

  p_call_procedure => 'CREATE_USER_ACCT_A',

  p_api_hook_call_id  => ln_api_hook_call_id,

  p_object_version_number => ln_object_version_number

 );

 

  EXCEPTION

 when others then

  dbms_output.put_line('Error in seeding user hook procedures: ' || sqlerrm);

  END;

 

  /

  commit;

  exit;

    Execute User Hook Pre-Processor

    When you have registered and linked your custom package procedure to the API you should execute the user hook pre-processor program. Run the hrahkone.sql found in $PER_TOP/patch/115/sql directory to do this. However, you'll need to know the internal api_module_id for the HR_USER_ACCT_API before running the script. To find the internal api_module_id you should run the script below:

      SELECT api_module_id

  ,api_module_type

  ,module_name

 FROM  hr_api_modules 

 WHERE module_package = 'HR_USER_ACCT_API';

    You should see results similar to those below:

     API_MODULE_ID API_MODULE_TYPE     MODULE_NAME

 --------------------------------------------------------

      383 BP                       CREATE_USER_ACCT

      384 BP                       UPDATE_USER_ACCT

    Note: Your api_module_id will be different from the one above.

    Use your own API module id when executing hrahkone.sql. If you have a customer package for UPDATE_USER_ACCT hook point, you will need to run hrahkone.sql twice. Once for the api_module_id for CREATE_USER_ACCT hook call and second for the UPDATE_USER_ACCT hook call.

  3. Enter any new message text for the messages that you issue in your custom package when you have run the pre-processor program. Use an Application Developer responsibility in Oracle Applications to create your message text.

  4. Ensure you have set the application level correctly if you use security groups to manage security profiles. For example, in SSHR you must set the application level to Oracle Self Service Web Applications. Set the security profile option to the application level if you need to associate the responsibility with another HRMS application.

    This updates the following tables: per_sec_ profile_ assignments, and fnd_user_resp_groups

  5. Make sure that the Enable Security Groups profile option is Yes.

  6. Set the Data Pump error parameters. These parameter control aspects of the Data Pump Engine process.

    See: Oracle HRMS Data Pump, Oracle HRMS Implementation Guide.

    Note: You must set the MAX_ERRORS_ALLOWED parameter to see all the errors logged during the run. This parameter controls how many errors are issued before the engine stops processing. The default value for the parameter is 20 or the chunk size. If you do not set this parameter value, the engine will stop processing after 20 errors.

  7. Test the custom packages by running the following programs:. To test, run the User Account Employee Extract concurrent program to create batches of extracted employees. Run the Data Pump Engine concurrent program to process your batch, and run the Data Pump Batch Exceptions

    • User Account Employee Extract concurrent program - to create batches of extracted employees

    • Data Pump Engine concurrent program - to process your batch

    • Data Pump Batch Exceptions concurrent program - to report any errors.

    If necessary, you can rerun the batch after fixing any errors.

    Note: You can use the Pipemon utility to help you debug your code.

    See: Creating Batches of Users with Concurrent Programs