Search Results wf_ldap




Overview
Explore in AI Chat

Overview

WF_LDAP is an Oracle E-Business Suite PL/SQL package owned by the APPS schema and classified under the ETRM as OTHER. Its name and dependencies indicate that it is the Oracle Workflow component responsible for integrating E-Business Suite user and role data with an external Lightweight Directory Access Protocol (LDAP) directory service, such as Oracle Internet Directory. The package acts as the bridge between Workflow's internal directory tables and the enterprise directory, allowing EBS to treat an external LDAP server as the authoritative source for users, roles, and related attributes.

In the 12.1.1 and 12.2.2 releases this integration underpins features that rely on a centralized identity store, including Oracle User Management, Workflow notifications, role-based approvals, and the Oracle Internet Directory/OID synchronization capabilities used by Fusion Middleware-based components. WF_LDAP abstracts the low-level LDAP protocol calls so that the rest of Oracle Workflow can query and reconcile directory entries without embedding protocol handling in higher-level business logic.

Key Procedures and Functions

Per the documented package metadata (ETRM 12.2.2), the source stub declares the package specification with AUTHID CURRENT_USER but exposes zero documented procedures or functions. The ETRM extract shows only the package declaration and the terminating end WF_LDAP; line, and records no API-level entries in the documented procedure/function list.

Because no public programs are catalogued, the package's implementation is treated as internal plumbing. This typically means the callable routines are either declared in the body only (not the specification), invoked through dynamic or internal mechanisms, or called by other Workflow and directory-synchronization programs rather than directly by customers. The ETRM lists no procedures that developers or administrators should call directly, so no parameter lists or signatures are asserted here.

Practically, this package provides the internal interface through which Workflow issues LDAP searches, binds, and attribute lookups against the directory. All such functionality is undocumented from an ETRM standpoint and should be regarded as private.

Tables Accessed

The ETRM documents the following referenced objects via APPS synonyms:

  • WF_ATTRIBUTE_CACHE — a Workflow caching table used to hold directory-derived attributes for users and roles, avoiding repeated round trips to the LDAP server during notification and role-resolution processing.
  • DBMS_JOB — the legacy Oracle job scheduler. WF_LDAP references DBMS_JOB, indicating that directory synchronization, refresh, or cleanup operations may be submitted and run as scheduled background jobs rather than synchronously.
  • DBMS_LDAP — the Oracle-supplied PL/SQL LDAP API. This is the core dependency confirming that WF_LDAP performs native LDAP operations (connect, bind, search, compare, unbind) against the external directory.
  • PLITBLM — a PL/SQL internal table helper package, used to hold and manipulate in-memory collections (for example, result sets returned from LDAP searches) during processing.

Together these references confirm a background, cached, job-driven synchronization mechanism between Workflow and the enterprise directory.

Usage Notes

WF_LDAP is not intended for direct invocation by developers. It is invoked indirectly by Oracle Workflow and Oracle User Management components whenever the system resolves users, roles, or approval routing against an LDAP-backed directory. Administrators encounter its effects through directory synchronization and user/role provisioning features rather than by calling its programs.

Because it declares AUTHID CURRENT_USER, execution privileges follow the calling schema, so any dependent job or concurrent program must be granted appropriate access to the LDAP directory tables and to DBMS_LDAP. The presence of DBMS_JOB references suggests that directory refresh activity runs as scheduled jobs and should be monitored through the standard concurrent manager and job queue views.

Custom code should avoid calling this package directly. Because the ETRM documents no supported API surface and no public procedures, the package is best treated as an internal Workflow implementation detail subject to change between 12.1.1 and 12.2.2. Development efforts requiring directory integration should use formally documented Workflow and User Management APIs instead.