Search Results wf_log_pkg




Overview
Explore in AI Chat

Overview

APPS.WF_LOG_PKG is the Oracle Workflow logging package body that provides the runtime instrumentation layer used by the Workflow engine and its dependent components. Its principal business function is to write diagnostic and audit messages into the Oracle Workflow and FND logging infrastructure so that administrators and support engineers can trace the execution of workflow processes, notifications, and event activities. The package abstracts the mechanics of log severity, module naming, and message construction away from individual workflow programs, allowing a consistent logging format across the entire Oracle E-Business Suite Workflow stack.

Because it is a package body, WF_LOG_PKG owns no standalone API surface of its own; the specification (WF_LOG_PKG) defines what callers may invoke. In EBS 12.1.1 and 12.2.2 the body is marked VALID in the APPS schema and carries an API classification of OTHER, confirming that it is an internal support routine rather than a published integration API.

Key Procedures and Functions

The documented body exposes eight procedures and functions, all oriented toward log level control and message generation:

  • INIT — Initializes the logging context for a session or calling unit, establishing the baseline state used by subsequent logging calls.
  • SET_LEVEL — Sets the active logging severity threshold, determining which messages are recorded versus suppressed.
  • SET_NAME — Assigns the logical module or component name that will be stamped on generated log entries.
  • SET_TOKEN — Registers a substitution token or identifier used to correlate the log output with a specific process or activity instance.
  • STRING — Emits a plain string message at the currently configured logging level.
  • STRING2 — Emits a two-part string message, extending STRING for cases where a second value or label must be concatenated into the output.
  • MESSAGE — Emits a message derived from the FND message dictionary, allowing translatable and standardized text to be written to the log.
  • TEST — Evaluates whether logging is currently enabled at a given level, so callers can avoid the cost of building messages that would be discarded.

Tables Accessed

The ETRM documentation records direct references to DBMS_UTILITY and PLITBLM through APPS synonyms. DBMS_UTILITY supplies formatting and stack/error-context utilities used when constructing log output. PLITBLM is the PL/SQL internal table management package referenced by the compiled body; it is an implementation-level dependency rather than a business table.

Functionally, the package also interacts with FND_LOG and FND_LOG_REPOSITORY (referenced in the dependency listing) to persist and configure log records, and with FND_PROFILE to read the profile options that govern logging behavior. FND_MESSAGE supplies the message text used by the MESSAGE routine. No application data tables are read or written by this package — its scope is entirely diagnostic.

Usage Notes

WF_LOG_PKG is invoked internally by Oracle Workflow components rather than by end users. The dependency metadata records that it references FND_GLOBAL, FND_LOG, FND_LOG_REPOSITORY, FND_MESSAGE, FND_PROFILE, WF_CORE, and itself, and that it is referenced by 62 other packages within the APPS schema. This breadth of inbound dependency confirms its role as shared infrastructure: workflow notification mailers, event subscribers, background engine programs, and workflow-enabled forms all call into it to record activity.

Administrators indirectly control its output through the FND: Logging profile options and the Oracle Workflow logging configuration stored in the logging repository. When investigating a stalled or failing workflow, support staff typically enable logging at the appropriate level and then review the resulting entries, which WF_LOG_PKG has formatted and written. Custom code may call the specification routines directly for consistent formatting, but because the API is classified OTHER rather than as a public interface, such use should be treated cautiously and validated against each EBS point release. The package is not referenced by any database object outside the APPS package set.