Search Results hr_helpdesk_util_ss




Overview
Explore in AI Chat

Overview

HR_HELPDESK_UTIL_SS is a utility package body owned by the APPS schema in Oracle E-Business Suite, valid and deployed in both 12.1.1 and 12.2.2 environments. It belongs to the Oracle HR Helpdesk (also surfaced through the iSupport/TeleService family of self-service applications) and functions as a shared helper library rather than as a transaction-processing API. Its purpose is to resolve and validate the identity, assignment, and access context of a user interacting with HR Helpdesk self-service flows. Typical callers use it to translate an FND user or person into a PERSON_ID and ASSIGNMENT_ID, to determine whether the person and assignment are currently active, and to verify that a given function, responsibility, or security group is legitimately reachable by that user.

Consistent with its classification as OTHER (a non-public, non-API package), HR_HELPDESK_UTIL_SS is intended for internal consumption by Oracle-delivered forms, JSP/HTML self-service pages, and workflow or concurrent logic that underpins HR Helpdesk. ETRM records show it is referenced by no other database object, confirming its role as a leaf-level utility invoked directly by application code rather than by other PL/SQL packages.

Key Procedures and Functions

The documented package exposes nine procedures and functions. GET_PERSON_ID returns the PERSON_ID associated with the current user or session context. GET_ASSGN_ID returns the corresponding ASSIGNMENT_ID, allowing callers to bind downstream queries to a specific assignment rather than to the person alone. GET_PERSON_STATUS returns the current status of a person record, enabling self-service code to suppress or redirect actions for terminated or inactive individuals.

GET_ASSIGN_STATUS performs the equivalent check at the assignment level, returning whether the assignment is active, and GET_PERSON_TYPE_STATUS resolves status information keyed by person type, which supports filtering behavior for employee, applicant, or contingent worker categories. VALIDATE_FUNCTION checks whether a named function is valid and accessible, while GET_FUNCTION_TYPE returns the function type classification used to distinguish forms, JSP pages, and other function definitions. GET_RESP_NAME returns the name of a responsibility, and GET_SECGRP_KEY returns the security group key, both used when the Helpdesk must present or verify the user's responsibility and security group context.

No parameter lists are invented here; the names above reflect the documented signatures only in terms of purpose.

Tables Accessed

The package reads foundational Oracle Applications foundation and HR tables through APPS synonyms. FND_FORM_FUNCTIONS supplies function definitions consumed by VALIDATE_FUNCTION and GET_FUNCTION_TYPE. FND_MENU_ENTRIES, FND_RESPONSIBILITY, FND_SECURITY_GROUPS, and FND_USER_RESP_GROUPS provide the responsibility, menu, and security group hierarchy needed by GET_RESP_NAME and GET_SECGRP_KEY. FND_GLOBAL supplies session context such as the current user and responsibility.

On the HR side, PER_ALL_PEOPLE_F and PER_ALL_ASSIGNMENTS_F (with the base PER_PEOPLE_F and PER_ASSIGNMENTS_F referenced for dependency resolution) back GET_PERSON_ID, GET_ASSGN_ID, GET_PERSON_STATUS, GET_ASSIGN_STATUS, and GET_PERSON_TYPE_STATUS. The _F date-tracked views are used so that status resolution reflects the effective date of the query.

Usage Notes

HR_HELPDESK_UTIL_SS is typically invoked from Oracle Forms and OA Framework/self-service pages during HR Helpdesk session initialization, when the application must establish who the user is, which assignment is in context, and whether that user may access a requested function. Customizations and extensions that need the same context-resolution logic may call these routines directly, but because the package carries no public API designation and is not referenced by any other database object, Oracle does not guarantee signature stability across patches.

Callers should treat the package as read-only: it resolves and validates data and does not perform transactional DML. Because several routines depend on FND_GLOBAL session state, they must be invoked within an initialized EBS session (form, OAF page, or concurrent program) rather than from an unauthenticated database connection, or the returned identifiers and statuses will not reflect a valid user context.