Search Results wf_cache




Overview
Explore in AI Chat

Overview

WF_CACHE is an internal Oracle Workflow runtime package that resides in the APPS schema and provides in-memory caching services for the Workflow Engine. Its purpose is to reduce the volume of repeated queries against the Workflow configuration tables during the execution of workflow processes. Rather than reading activity definitions, item type attributes, and process metadata directly from the database on every navigation step, calling code (principally WF_ENGINE) retrieves this configuration data through the WF_CACHE layer, which retains it in PL/SQL session memory for the duration of a transaction or session.

Because the package body is documented as VALID and classified as OTHER in the ETRM repository, it is not a public integration API. It is a support component that underpins the performance of the Workflow Engine. The presence of transaction control entry points (BEGINTRANSACTION, ENDTRANSACTION) and a cache invalidation entry point (CLEAR, RESET) confirms that the package is designed to coordinate cached state with transactional boundaries so that workflow runs observe consistent definitions. The package references WF_ENGINE, WF_RESOURCES, DBMS_UTILITY, PLITBLM, and STANDARD, which is consistent with a low-level utility that is invoked by the engine and that uses NLS and resource-table lookups for localization and diagnostic information.

Key Procedures and Functions

The documented program units (20 total) fall into several functional groups:

  • CACHEMANAGER — The orchestrating routine that governs cache population, lookup, and refresh behavior for a given cache category.
  • CLEAR / RESET — Invalidation routines that empty cached entries, either wholesale or for a specific cache key, forcing subsequent reads to return to the base tables.
  • SETHASHRANGE / HASHKEY — Support routines that establish and compute the hash key or hash range used to index and locate cached entries efficiently in memory.
  • GETACTIVITY / GETACTIVITYATTR / GETACTIVITYATTRVALUE — Retrieve a workflow activity definition, its attribute definitions, and individual activity attribute values.
  • GETACTIVITYTRANSITIONS — Returns the transitions defined out of a given activity, which the engine requires when advancing a process.
  • GETPROCESSACTIVITY / GETPROCESSACTIVITYINFO / GETPROCESSSTARTACTIVITIES — Return process-level activity metadata, including the activities that can start a process.
  • GETITEMTYPE / GETITEMATTRIBUTE / GETITEMATTRVALUE — Return item type definitions and their attribute definitions and values.
  • GETNLSPARAMETER — Resolves NLS-dependent settings used when rendering or interpreting cached definitions.
  • BEGINTRANSACTION / ENDTRANSACTION — Delimit the transactional scope over which cached data remains valid and are used to synchronize cache state with engine transactions.
  • VARCHAR2 — A declared type or helper that supports cache value handling.
  • METAREFRESHED — Tracks or signals whether cached metadata has been refreshed relative to the underlying definitions.

No parameter lists are published for these units in the ETRM metadata; callers should treat them as engine-internal.

Tables Accessed

The documented dependencies are WF_RESOURCES, DBMS_UTILITY, and PLITBLM. WF_RESOURCES is the Workflow resource table that stores translatable message and lookup text; WF_CACHE reads it to resolve language-dependent resource strings associated with activities, item types, and NLS parameters. DBMS_UTILITY and PLITBLM are supplied PL/SQL and kernel packages rather than application tables, and are used for utility and low-level operations that support cache mechanics. Notably, the metadata does not list the principal Workflow definition tables (WF_ITEM_TYPES, WF_ACTIVITIES, WF_ACTIVITY_ATTRS, WF_TRANSITIONS) as direct dependencies, which suggests that WF_CACHE obtains definition data indirectly through WF_ENGINE, its documented referencer. This reinforces the package's role as a caching facade rather than a direct SQL accessor.

Usage Notes

WF_CACHE is invoked implicitly by the Oracle Workflow Engine whenever a workflow process is executed, not by end users directly. It is not referenced by any database object according to the dependency listing, but it is referenced by eight other packages and depends on WF_ENGINE, indicating it sits inside the engine's call graph. Typical invocation paths include Workflow background engine processing, item type and process definition execution from the Workflow Builder and administrator forms, and the notification and event subsystems that drive workflow progression.

Custom code should not call WF_CACHE routines directly. Applications that need to force workflow definitions to be reread after a definition change should use the supported Workflow configuration and "refresh" mechanisms or restart the Workflow Engine, which causes the cache to be cleared and repopulated. In Oracle EBS 12.1.1 and 12.2.2, the package is compiled into the APPS schema; its PL/SQL session-scoped caches mean that stale definitions can persist in long-lived sessions until invalidated, so administrators should be aware of cache clearing and engine restart implications following Workflow definition changes.