Search Results fnd_user_pkg_wrp

Overview

APPS.FND_USER_PKG_WRP is a wrapper package in the Oracle E-Business Suite Applications (APPS) schema that encapsulates a set of user-management operations exposed by the underlying FND_USER_PKG. Its header identifies it explicitly as an AOL (Application Object Library) internal utility, meaning it is intended for use by Oracle's own framework components rather than by external customizations. The wrapper provides a controlled, stable entry point for functions such as synchronizing a user record (user_synch), deriving person and party identifiers, validating user names, and performing LDAP-related user lifecycle operations. In the context of Oracle EBS 12.1.1 and 12.2.2, this package sits at the boundary between the base user repository (FND_USER and related tables) and the security infrastructure that governs authentication, password policy, and directory integration. The user query "user_synch" maps directly to the USER_SYNCH procedure, which is the wrapper around fnd_user_pkg.user_synch() and represents the primary mechanism for reconciling a user's identity and dependent data within the framework. The package carries the AUTHID CURRENT_USER declaration, ensuring it executes with the privileges of the invoking schema, a common convention for internal wrapper layers that call lower-level APIs.

Key Procedures and Functions

The package exposes ten documented procedures and functions, each delegating to a corresponding routine in FND_USER_PKG:

• USER_SYNCH — A procedure that synchronizes a user, accepting a user name as input. This is the routine associated with the "user_synch" search term and is used to align a user's record with the framework's expectations.
• DERIVE_PERSON_PARTY_ID — A function that returns a numeric identifier, deriving the person and party association for a user based on user name, customer ID, and employee ID, with an optional logging flag controlling exception logging.
• SET_OLD_USER_NAME — A function that records a prior user name, returning a numeric status, typically used during user name change operations.
• VALIDATE_USER_NAME — A procedure that validates a supplied user name, ensuring it conforms to the naming rules enforced by the framework.
• ISPASSWORDCHANGEABLE — A function returning a boolean that indicates whether the password of the specified user may be changed, reflecting password policy state.
• LDAP_WRAPPER_CREATE_USER — A procedure that creates a user in the LDAP directory context, accepting user name, an unencrypted password, start and end dates, description, e-mail address, and fax number.
• LDAP_WRAPPER_UPDATE_USER — A procedure that propagates user attribute changes to the LDAP directory.
• LDAP_WRAPPER_CHANGE_USER_NAME — A procedure that mirrors a user name change into the LDAP directory.
• FORMS_VALIDATE_PASSWORD — A routine supporting the Oracle Forms password validation path.
• FORMS_CHANGE_USER_PWD — A routine supporting password change from the Forms interface.

Tables Accessed

The ETRM metadata does not enumerate the underlying tables referenced through APPS synonyms, and no referenced-by relationships to other packages are documented. Functionally, the package operates against the core EBS user repository, principally FND_USER and its supporting password and organization-assignment structures, along with the person and party tables (such as HZ_PARTIES and PER_PERSONS) accessed through DERIVE_PERSON_PARTY_ID. LDAP-oriented routines interact with directory configuration rather than additional base tables.

Usage Notes

FND_USER_PKG_WRP is flagged "for AOL INTERNAL USE ONLY." It is not a supported public API for customer extension. It is typically invoked indirectly by EBS Forms-based user maintenance screens, by Oracle's LDAP synchronization and password-management flows, and by internal concurrent or background processes that reconcile user identities. In 12.1.1 and 12.2.2 the package remains an internal wrapper, and custom code should call the documented public APIs (such as FND_USER_PKG) rather than this wrapper directly, since signature and behavior changes are not governed by the same compatibility guarantees.