Search Results x_cost

Overview

APPS.WF_ACTIVITIES_PKG is the Oracle Workflow repository maintenance package for the WF_ACTIVITIES entity, which stores the definition of every individual activity (function, notification, event subscription, and so on) that belongs to a workflow item type. In Oracle EBS 12.1.1 and 12.2.2 the Workflow engine relies on this metadata at runtime to resolve an activity's function, result type, error process, message, and access roles. The package is a private, low-level Data Manipulation Language (DML) layer rather than a business-facing API: it is generated in the standard Oracle Forms pattern, exposing row-level INSERT, LOCK, UPDATE, DELETE, and translation procedures so that the Workflow Builder client and other internal Workflow utilities can persist activity definitions consistently. Because it is declared AUTHID CURRENT_USER (per the source header, version 115.15), privilege resolution follows the calling schema, and the package is intended to be invoked from within the APPS environment or by other APPS-owned code that has been granted execute.

Key Procedures and Functions

• INSERT_ROW — Inserts a new activity definition into the base table. It accepts the complete attribute set for an activity row, including item type, name, version, type, rerun behavior, role-expansion flag, protection and customization levels, effective begin and end dates, function and function type, result type, cost, read/write/execute role assignments, icon name, message, error process, display name, description, error item type, runnable flag, and the optional event filter and event type used for event subscriptions.
• LOCK_ROW — Performs the standard Forms-style optimistic locking check on an existing activity row, verifying that the persisted attribute values still match those held by the calling form or routine. A failure raises the standard lock exception, signalling that the record was modified by another session.
• UPDATE_ROW — Modifies an existing activity definition, including the X_COST attribute that carries the activity's costing value, along with the remaining descriptive and behavioural columns.
• DELETE_ROW — Removes an activity definition from the WF_ACTIVITIES entity. Deletion is normally restricted to activities with no runtime instances or dependent subscriptions.
• ADD_LANGUAGE — Inserts or maintains the translated (TL) row for an activity, populating the display name and description for a given language so that Workflow notifications and the Workflow Builder UI can present localized text.

Tables Accessed

The package operates exclusively against two documented tables, reached through APPS synonyms:

• WF_ACTIVITIES — the base table holding the non-translatable definition of each activity, including the X_COST value and all control attributes (roles, function, result type, error handling, runnable and event flags). All INSERT, LOCK, UPDATE, and DELETE operations target this table.
• WF_ACTIVITIES_TL — the translation table holding display name and description by language; ADD_LANGUAGE writes here, and the base row's language-independent columns remain in WF_ACTIVITIES.

Usage Notes

WF_ACTIVITIES_PKG is classified in the ETRM metadata as OTHER rather than as a published public API, and it is referenced by one other package within the Workflow schema. In practice it is invoked by the Oracle Workflow Builder client, by Workflow configuration and upgrade utilities, and occasionally by custom PL/SQL that must programmatically create or clone activity definitions during item type deployment. Because callers must supply every mandatory attribute and must satisfy the LOCK_ROW check before updating, direct use requires that the caller first query the row and pass current values. The presence of the X_COST parameter reflects the activity-level cost used by Workflow for accounting and performance reporting. Oracle recommends using the supported Workflow APIs (for example, WF_ITEM_TYPE or Workflow Builder) wherever possible, reserving direct calls to this package for controlled development, migration, or diagnostic scenarios. No formal commit is issued by these procedures; transaction control remains with the calling application.