Search Results wf_local_synch




Overview
Explore in AI Chat

Overview

WF_LOCAL_SYNCH is a PL/SQL package body owned by the APPS schema in Oracle E-Business Suite. Its purpose is to synchronize the Workflow local cache tables — principally WF_LOCAL_ROLES, WF_LOCAL_USER_ROLES, WF_ROLE_HIERARCHIES, and WF_USER_ROLE_ASSIGNMENTS — with the authoritative directory data held in WF_ROLES and WF_DIRECTORY_PARTITIONS. The local tables exist so that the Workflow engine and Notification Mailer can resolve role, user, and hierarchy membership without repeatedly traversing the full directory model. WF_LOCAL_SYNCH supplies the propagation, validation, and bulk-rebuild routines that keep those cached structures consistent when users, roles, or role assignments change.

In EBS 12.1.1 and 12.2.2, the dictionary object is reported as VALID. It is not referenced by any other database object, meaning it is not a utility called from within the Workflow engine's core code path, but rather an administration-side package invoked directly by maintenance processes and concurrent programs. In the documented 12.2.2 metadata it is classified as OTHER, and the ETRM repository lists 33 other packages that reference it, indicating that downstream Workflow administration components are its principal callers.

Key Procedures and Functions

The documented entry points fall into four functional groups:

  • Propagation: PROPAGATE_USER, PROPAGATE_ROLE, PROPAGATE_USER_ROLE, and PROPAGATEUSERROLE push changes for a single user, role, or user-role assignment into the local cache tables. PROPAGATEUSERROLE is the legacy (non-underscored) variant retained for backward compatibility.
  • Bulk synchronization: BULKSYNCHRONIZATION and BULKSYNCHRONIZATION_CONC perform a wholesale rebuild or refresh of the local tables. The _CONC form is the concurrent-program entry point, suitable for scheduled or transactional submission, while the non-suffixed form is the callable worker.
  • Validation: VALIDATEUSERROLES and VALIDATEUSERROLES_CONC verify that cached user-role assignments agree with the source data and report or repair discrepancies. As with bulk synchronization, the _CONC variant is designed for concurrent manager execution.
  • Cache management and DDL: CHECKCACHE and DELETECACHE inspect and clear cached synchronization state; CREATE_STAGE_INDEXES builds the temporary staging indexes used to accelerate bulk operations; and BULK_RESET_NTFPREF resets the name-to-function preference reference used during bulk processing.

No parameter signatures are documented in the source metadata, so callers should obtain exact argument lists from the package specification in the target environment.

Tables Accessed

WF_LOCAL_SYNCH reads and writes the cached Workflow directory tables WF_LOCAL_ROLES, WF_LOCAL_USER_ROLES, WF_ROLE_HIERARCHIES, and WF_USER_ROLE_ASSIGNMENTS. It reads source and configuration data from WF_ROLES, WF_DIRECTORY, WF_DIRECTORY_PARTITIONS, FND_USER, FND_LANGUAGES, and FND_LOOKUP_VALUES. It also queries WF_PARAMETER_LIST_T and WF_PARAMETER_T for Workflow parameterization and PLITBLM for PL/SQL table handling. The remaining dependencies reflect infrastructure rather than business data: FND_FILE, FND_GLOBAL, FND_LOG, FND_STATS, WFA_SEC, WF_CORE, WF_DDL, WF_ENGINE, WF_ENTITY_MGR, WF_EVENT, WF_LOG_PKG, WF_MAINTENANCE, WF_ROLE_HIERARCHY, DBMS_SQL, PLITBLM, and the DBA_INDEXES, DBA_IND_COLUMNS, DBA_IND_EXPRESSIONS, and DBA_IND_PARTITIONS views, which CREATE_STAGE_INDEXES uses to inspect and manage index definitions.

Usage Notes

Because the package is not invoked by any database object, it is driven externally — typically from Workflow administration concurrent programs such as "Synchronize WF_LOCAL_ROLES" and "Validate WF_LOCAL_ROLES," or from SQL*Plus scripts run during patching and post-installation steps. Bulk routines should be scheduled during off-peak windows, since rebuilding WF_LOCAL_ROLES and its dependents is I/O intensive. PROPAGATE_USER, PROPAGATE_ROLE, and PROPAGATE_USER_ROLE are appropriate for targeted, near-real-time maintenance after individual assignment changes. Custom code may call these procedures as published APIs, but should always reference the package specification for exact signatures and should not modify the local cache tables directly.