Search Results ldap_attr




Overview
Explore in AI Chat

Overview

FND_LDAP_MAPPER is an Oracle E-Business Suite application-level PL/SQL package body owned by the APPS schema. Its purpose is to provide the mapping layer between EBS user and workflow entity data and an external directory server (LDAP or Oracle Internet Directory). The package translates EBS records into directory-compatible attribute structures and, conversely, translates inbound LDAP or OID messages and events into EBS workflow entity-change records. In this role it acts as the glue code for identity-management and single sign-on integration flows, sitting between the Oracle Workflow event infrastructure and the LDAP/OID plug-in layer. The object is documented as VALID and is classified with an API classification of OTHER, indicating that it is an internal integration utility rather than a published end-user API. It depends on a broad set of APPS utilities, including FND_OID_PLUG, FND_OID_UTIL, FND_WEB_SEC, FND_LOG, FND_PROFILE, and FND_USER, and it is not itself referenced by any other database object, confirming its position as a top-level integration component rather than a reusable library.

Key Procedures and Functions

The documented package exposes six procedures or functions. The ETRM metadata lists five with explicit names and reports six in total; the remaining routine is not separately enumerated in the supplied excerpt.

  • MAP_SSO_USER_PROFILES — Maps SSO-relevant user profile information, aligning EBS user profile values with the attributes expected by the directory/SSO layer.
  • MAP_ENTITY_CHANGES_REC — Processes a workflow entity-changes record, converting the change payload into the form required by the directory mapping. This routine is directly relevant to the WF_ENTITY_CHANGES_S search term, since the sequence-backed workflow entity change table supplies the record being mapped.
  • MAP_LDAP_ATTR_LIST — Translates a list of LDAP attributes (LDAP_ATTR_LIST) into an EBS-usable representation, supporting attribute-based reconciliation between the directory and EBS.
  • MAP_LDAP_MESSAGE — Maps an inbound LDAP message structure, translating directory-supplied data into workflow or EBS entities.
  • MAP_OID_EVENT — Maps an Oracle Internet Directory event, routing directory change notifications into the EBS change-tracking mechanism.

Tables Accessed

The package reads and writes via APPS synonyms. FND_USER supplies the EBS user identity and profile data being mapped. WF_ENTITY_CHANGES and WF_ENTITY_CHANGES_S (the sequence for entity-change records) form the workflow change-capture store that this package populates when directory-side changes must be reflected in EBS. WF_ATTRIBUTE_CACHE provides cached workflow attribute metadata used during mapping, and WF_EVENT_T carries the workflow event structure raised or consumed during event-driven flows. LDAP_ATTR and LDAP_ATTR_LIST hold directory attribute definitions and attribute collections, while LDAP_EVENT carries directory event payloads. WF_ENTITY_MGR and WF_OID support entity management and OID interaction respectively. DUAL, PLITBLM, and UTL_RAW are used for scalar evaluation, PL/SQL table handling, and raw-value conversion (for example, binary directory values).

Usage Notes

FND_LDAP_MAPPER is not a user-facing API and should not normally be called directly from forms or custom code. It is invoked internally by the EBS OID/LDAP integration and Workflow event subscriptions — for example, when an OID event is raised, or when an entity change recorded in WF_ENTITY_CHANGES must be propagated to the directory. Administrators and developers encountering it typically do so while troubleshooting SSO, user-provisioning, or directory-synchronization issues. FND_LOG references indicate that the package writes diagnostic information to the EBS logging framework, and FND_PROFILE is read for site-level configuration values. The package is documented as being referenced by three other packages, which are its normal entry points. Because it is marked VALID and is not referenced by any database object itself, it functions as a terminal integration component within the APPS schema.