Search Results wf_item_activity_status




Overview

The APPS.WF_ITEM_ACTIVITY_STATUS package body is a core component of the Oracle Workflow engine, delivered as part of the Oracle E-Business Suite technology stack in releases 12.1.1 and 12.2.2. Its primary business function is to maintain and expose the runtime state of individual activities within a running workflow process instance. Every time the Workflow Engine executes an activity node, the corresponding status record must be created, updated, queried, or deleted. This package provides the encapsulated logic that performs those operations against the Workflow item activity status tables, shielding callers from the underlying persistence details.

The package is owned by the APPS schema and is classified as OTHER in the ETRM API classification scheme. It is a heavily depended-upon utility: the ETRM dependency listing shows that it is referenced by approximately twenty-nine other database objects, and its own body depends on WF_CORE, WF_ENGINE, WF_ENGINE_UTIL, WF_ACTIVITY, WF_PROCESS_ACTIVITY, WF_QUEUE, and WFA_SEC. This position within the dependency graph confirms that it is an internal engine service rather than an end-user-facing API.

Key Procedures and Functions

The ETRM metadata documents thirteen procedures and functions within this package body. Their documented purposes are described below; parameter signatures are deliberately omitted as they are internal engine contracts.

  • CLEARCACHE — Clears cached status information held in the package's PL/SQL memory, forcing subsequent calls to re-read from the database.
  • UPDATE_NOTIFICATION — Synchronizes notification-related state with the activity status record, typically after a notification activity is sent or responded to.
  • ROOT_STATUS — Returns or derives the status of the root activity of a workflow process, providing a roll-up view of the top-level process state.
  • LASTRESULT — Retrieves the most recent result code produced by an activity, used by the engine to determine downstream transition routing.
  • STATUS — Returns the current status of a specified activity within a specified item, the most commonly queried function in the package.
  • RESULT — Returns the result value associated with an activity occurrence, distinguishing between status and outcome.
  • DUE_DATE — Returns the due date assigned to an activity, supporting timeouts and deadline monitoring.
  • NOTIFICATION_STATUS — Returns the notification-specific status for notification activities, separate from the generic activity status.
  • ERROR_INFO — Retrieves error details recorded against an activity that ended in error.
  • SET_ERROR — Records error information against an activity status row when execution fails.
  • DELETE_STATUS — Removes activity status records, used during process cleanup or rollback.
  • CREATE_STATUS — Inserts a new activity status row when an activity instance is entered.
  • AUDIT — Writes audit information for activity status changes, supporting the Workflow administrative audit trail.

Tables Accessed

The package operates against three documented base tables through APPS synonyms.

  • WF_ITEMS — The master table of workflow item instances. Status functions verify item existence and join activity status rows to their parent item.
  • WF_ITEM_ACTIVITY_STATUSES — The primary operational table. CREATE_STATUS inserts here, SET_ERROR and UPDATE_NOTIFICATION update here, DELETE_STATUS removes rows, and the query functions (STATUS, RESULT, LASTRESULT, DUE_DATE, NOTIFICATION_STATUS, ERROR_INFO) read from it.
  • WF_ITEM_ACTIVITY_STATUSES_H — The history table for the statuses table. The AUDIT routine and engine-driven history maintenance write to this table so that prior activity states remain queryable.

Usage Notes

This package is not intended for direct invocation by end users or general customizations. It is invoked internally by the Workflow Engine, by other Workflow packages such as WF_ENGINE and WF_ENGINE_UTIL, and by Workflow-enabled Oracle EBS application modules that need to interrogate activity state. Typical indirect invocation paths include the Workflow Monitor responsibility, notification processing, background engines processing deferred activities, and concurrent programs that advance or purge workflow items. Developers writing custom Workflow code should prefer the documented public APIs in WF_ENGINE and related packages; calling WF_ITEM_ACTIVITY_STATUS directly risks bypassing engine-level controls. Because the package caches state, any custom routine that manipulates the underlying status tables outside this package may require CLEARCACHE to be called to avoid stale reads.