Search Results activate_trace




Overview
Explore in AI Chat

Overview

XLA_UTILITY_PKG is the centralized instrumentation and diagnostics utility for the Oracle Subledger Accounting (XLA) product family in Oracle E-Business Suite 12.1.1 and 12.2.2. As documented in its package header (xlacmutl.pkh), the package exists to provide a wrapper for "debugging/benchmark/testing facilities." It is not a business API in the accounting sense; no accounting event, journal entry, or application transaction is created or modified by calling it. Instead, it supplies a uniform mechanism through which Subledger Accounting code — and the many modules that call into it — can emit trace output, write to the concurrent manager log and output files, and collect timing and runtime statistics. In practice the package constitutes the observability layer of XLA, and the procedure name activate_trace reflects its most common entry point for diagnostic sessions.

Key Procedures and Functions

The 23 documented procedures divide into three functional groups that mirror the sections of the package specification.

  • Trace and debug control: ACTIVATE_TRACE, DEACTIVATE_TRACE, SET_TRACE_ON, SET_TRACE_OFF, ACTIVATE, DEACTIVATE, and SET_OPTION govern whether tracing is enabled, at what level, and the operational mode in which output is produced. TRACE emits a single message at a supplied level; PRINT_TRACE_INFO reports the current trace configuration. These procedures are the mechanism referenced by the activate_trace search and correspond to the init_trace/trace/trace_off coding standard shown in the header.
  • Output and logfile facilities: PRINT, PRINT_OUTPUTFILE, and PRINT_LOGFILE direct diagnostic text to the standard output stream, to the concurrent program output file, or to the logfile through FND_FILE, as described in the specification's "SRS Output and logfile facilities" section.
  • Statistics and session information: ACTIVATE_STAT, DEACTIVATE_STAT, SET_STAT_ON, SET_STAT_OFF, PRINT_STAT_INFO, and GET_STAT_INFO provide a parallel benchmarking facility that records elapsed timing and resource counters around a block of PL/SQL. GET_SESSION_INFO and GET_OPTION_VALUE return session and profile-option context used to decide whether a given trace level is active.

No parameter lists are documented; callers should rely on the published specification rather than assuming signatures.

Tables Accessed

As recorded in the ETRM metadata, XLA_UTILITY_PKG references no application tables directly. Its dependencies are all supplied packages and dynamic performance views, accessed through APPS synonyms: DBMS_PIPE (for transmitting messages to a waiting SRS process), DBMS_SESSION (session attributes such as client identifier and module), DBMS_UTILITY (timing and formatting helpers used by the statistics routines), HTP (HTML-formatted output), UTL_FILE (flat-file trace targets), and V$PARAMETER (database initialization parameters consulted for diagnostic context). Because it reads no XLA or other module table, the package can be invoked safely during any phase of processing without affecting transactional data.

Usage Notes

The package header documents three invocation patterns. From SQL*Plus or custom PL/SQL, a session begins with an initialization call, executes the source under investigation, issues trace calls at a specified level, and closes with a trace termination call. From SRS or Oracle Forms 4.5 and later, behavior is controlled by the profile options XLA_DEBUG_MODE (Yes/No), XLA_DEBUG_LEVEL (1 to 100), and XLA_DEBUG_TIMEOUT (in seconds), so that operators can enable diagnostics for a specific user or responsibility without code changes. Output destinations include standard output, a pipe to another concurrent process, the current FND file log, an HTML page, or a flat file.

Because XLA_UTILITY_PKG is referenced by 39 other packages, activating trace at a low level through activate_trace or profile options produces output from many layers of Subledger Accounting processing simultaneously. The documented XLA_DEBUG_LEVEL setting should therefore be raised incrementally. The timeout option exists to protect concurrent requests from runaway trace volume, and should be set whenever tracing is enabled in a production or performance-test environment.