Search Results update_shadow




Overview
Explore in AI Chat

Overview

ZPB_PERSONAL_AW is an Oracle E-Business Suite PL/SQL package owned by APPS that governs the creation, maintenance, and deletion of the personal Analytic Workspace (AW) assigned to each user of Oracle Daily Business Intelligence / Enterprise Planning and Budgeting (EPB) analytical functionality. Within the 12.1.1 and 12.2.2 code lines, the package acts as the driver layer between the shared, centrally maintained OLAP AW and the per-user AW that each end user actually queries. It also performs the associated metadata and relational-view provisioning required so that the OLAP measures become addressable from standard SQL.

The package is classified as OTHER in the ETRM 12.1.1 metadata, and the header comment records the source revision as zpbpersonalaw.pls 120.0.12010.4 dated 2006/08/03. Its documented interface exposes 16 procedures and functions, several of which are referenced by four other packages in the application, confirming it as a shared utility for the ZPB (Enterprise Planning and Budgeting) schema rather than a leaf-level form handler.

Key Procedures and Functions

  • AW_CREATE — Driver program that creates the user's personal AW from the shared AW, identified by user ID and business area ID.
  • AW_DELETE — Permanently and irreversibly deletes the user's personal AW, removing the AW and the SQL views defined against it.
  • AW_UPDATE — Updates the user's personal AW from the shared AW and returns a flag indicating whether the underlying structures changed enough to require a new Metadata Map.
  • DATA_VIEWS_CREATE — Creates the SQL views associated with the instance's measures, keyed by user, instance, type, and optional template.
  • MEASURES_DELETE and MEASURES_SHARED_UPDATE — Maintain measure definitions and propagate shared-measure changes.
  • MEASURES_APPROVER_UPDATE — Updates approver assignments for measures.
  • METADATA_CREATE and METADATA_UPDATE — Build and refresh the Metadata Map used to translate OLAP structures into EBS queryable artifacts.
  • SECURITY_UPDATE — Maintains the security model governing which users can see which analytical data; this is the procedure typically targeted when a "security_update" search is performed.
  • IMPORT and UPDATE_SHADOW — Support loading of analytical content and shadow-table synchronization.
  • STARTUP — Initialises package-level state.
  • VIEWS_UPDATE — Refreshes the generated SQL views.
  • PERSONAL_AW_RW_SCAN and PERSONAL_AW_SESS_CLOSE — Scan for and close stale sessions holding personal AW read/write locks.

Tables Accessed

The package works against a defined set of APPS-synonymed objects. ZPB_BUSINESS_AREAS, ZPB_ANALYSIS_CYCLES, ZPB_ACCOUNT_STATES, ZPB_DC_OBJECTS, ZPB_MEASURES, and ZPB_USERS hold the ZPB configuration and user registration data that determine what the personal AW must contain. FND_APPLICATION and FND_RESPONSIBILITY supply application and responsibility context for security and responsibility-scoped access. The package also calls DBMS_AW and DBMS_LOCK, and reads the dynamic performance views V$AW_OLAP, V$LOCK, and V$SESSION (plus DUAL) to inspect OLAP objects, detect lock contention, and identify active sessions. The V$ references underpin PERSONAL_AW_RW_SCAN and PERSONAL_AW_SESS_CLOSE.

Usage Notes

ZPB_PERSONAL_AW is normally invoked indirectly. Analytical UI pages within Oracle EBS trigger personal AW creation or refresh on first access, causing AW_CREATE or AW_UPDATE to run. Administrative and concurrent programs handle bulk maintenance, view regeneration (VIEWS_UPDATE), metadata rebuilding, and stale-session cleanup. The SECURITY_UPDATE entry point is the relevant procedure when analytical security definitions change and must be reapplied to the personal AW and its metadata. Because AW_DELETE is documented as irreversible, custom code should invoke it only with confirmed authority. Implementers extending ZPB functionality should call these documented entry points rather than manipulating the underlying ZPB_* tables or OLAP objects directly, since view and metadata consistency depends on the package performing both operations together. Direct invocation requires the APPS schema and appropriate privileges on DBMS_AW and the V$ views.