Search Results get_user_name

Overview

FND_USER_AP_PKG is a small utility package body owned by the APPS schema in Oracle E-Business Suite, documented across releases 12.1.1 and 12.2.2. Its principal business function is to resolve an Oracle EBS internal user identifier (USER_ID) into the corresponding application user name stored in the FND_USER table. This is a recurring requirement throughout the E-Business Suite, where transactional and audit tables frequently store numeric user identifiers rather than the descriptive user name that end users and reports recognize. The package therefore provides a lightweight, centralized lookup service that avoids duplicating simple SELECT statements against FND_USER in multiple callers.

The package is classified as OTHER in the ETRM metadata, indicating that it is not part of a formally published public API family and is not subject to the same compatibility guarantees. Its header comment ($Header: fnduserb.pls 115.0 99/07/17 07:47:22 porting ship $) indicates an early FND release lineage carried forward into the current technology stack. The package contains no global state, no initialization section, and no package-level variables; its sole purpose is encapsulated in a single function.

Key Procedures and Functions

The documented interface consists of one function, GET_USER_NAME. It accepts a user identifier and returns the corresponding user name as a VARCHAR2 value. When the supplied identifier does not match any row in FND_USER, the function returns an empty string rather than NULL, because the local return variable is initialized to an empty string at declaration.

• GET_USER_NAME — Returns the USER_NAME stored in FND_USER for a given USER_ID. The implementation opens an explicit cursor selecting USER_NAME from FND_USER WHERE USER_ID equals the supplied value, fetches a single row into a local variable, closes the cursor, and returns the value. The lookup is a single-row primary key style access against FND_USER.

No other procedures or functions are documented in the package body. Practitioners should note that the function performs a fetch without validating cursor status; callers are responsible for interpreting the empty string result as a not-found condition.

Tables Accessed

The package references a single table through an APPS synonym: FND_USER. This is the core EBS applications user repository, containing one row per application user and holding attributes such as USER_NAME, USER_ID, encrypted password information, and account status. FND_USER_AP_PKG performs read-only access; it issues no INSERT, UPDATE, or DELETE statements and therefore never modifies user definitions. The dependency on FND_USER alone means the package has no dependencies on transactional application schemas, which keeps it inexpensive and broadly callable.

Usage Notes

The package is typically invoked from PL/SQL-based extensions, forms-level logic, and concurrent program code that need to display or log a user name adjacent to a stored user identifier. Because FND_USER_AP_PKG is referenced by twelve other packages within the E-Business Suite, it functions as a shared internal dependency rather than an end-user-facing API, and changes to it can propagate to those dependent callers. Performance characteristics are those of a single indexed lookup on FND_USER; the function is not result-cached and opens a cursor on each invocation, so it is best suited to low-frequency calls rather than row-by-row use inside large loops.

Developers writing custom code should prefer this package, or the equivalent FND_USER lookup, over hard-coded SQL to preserve a single point of maintenance. Oracle recommends against direct modification of seeded FND packages; any extension should be implemented in custom code that calls the function. As with all APPS-owned objects, grants and synonyms must be validated in each environment, and behavior should be verified after patching or upgrade between 12.1.1 and 12.2.2, since the object is not covered by Oracle's public API compatibility policy.