Search Results cn_debug




Overview
Explore in AI Chat

Overview

CN_DEBUG is a utility package body owned by the APPS schema in Oracle E-Business Suite Release 12.1.1 and 12.2.2. It is classified under the ETRM (E-Business Suite Technical Reference Manual) as an OTHER API, indicating that it is not a public business API but rather an internal diagnostic and instrumentation utility. The package provides a centralized debugging and message-routing mechanism used by the Oracle Property Manager and related component applications falling under the "CN" namespace.

Its core purpose is to allow PL/SQL code to emit trace and diagnostic messages at runtime without requiring direct writes to application tables or log files. Instead, CN_DEBUG routes messages through a database pipe infrastructure, which decouples the producing code from the consuming diagnostic session. This design supports coordinated, real-time debugging of concurrent programs, forms-based transactions, and background processes across a multi-tier EBS deployment.

Key Procedures and Functions

The ETRM metadata documents four procedures and functions within this package:

  • SET_DEBUG_LEVEL — Establishes the verbosity threshold for subsequent debug output. Higher or lower levels determine which messages are passed to PRINT_MSG and which are suppressed, allowing developers to control trace granularity without code changes.
  • PRINT_MSG — The primary output routine. It accepts a message and emits it through the configured pipe when the current debug level permits, providing the actual trace/logging behavior invoked throughout calling code.
  • SET_PIPENAME — Configures the name of the database pipe used for message delivery. This allows multiple concurrent diagnostic sessions to be isolated from one another by assigning distinct pipe names.
  • INIT_PIPE — Initializes the pipe infrastructure for a session, preparing the mechanism that PRINT_MSG later uses. It typically precedes any debug output within a diagnostic run.

No parameter signatures are asserted here; the procedures are described strictly by their documented purpose.

Tables Accessed

The documented metadata lists no tables referenced through APPS synonyms. This absence is consistent with the package's role as an in-memory diagnostic utility: rather than persisting to application tables, CN_DEBUG communicates via Oracle's DBMS_PIPE facility and depends only on the SYS STANDARD package and its own specification. Persistent logging, where required, is handled by the caller or an external consumer that reads the pipe.

Usage Notes

CN_DEBUG is a foundational dependency, referenced by sixteen other packages within the APPS schema. Typical invocation follows a predictable lifecycle: calling code invokes SET_PIPENAME and INIT_PIPE to prepare a channel, sets the desired threshold with SET_DEBUG_LEVEL, and then calls PRINT_MSG at strategic points. A separate diagnostic session reads from the pipe to observe the trace in real time.

Because it is not referenced by any database object and is not a business API, CN_DEBUG is never exposed directly to end users or Oracle Forms responsibility menus. It is invoked exclusively from within PL/SQL — most commonly during development, unit testing, and production troubleshooting of Property Manager concurrent programs and related transactions. DBAs and technical consultants use it to obtain runtime visibility into package execution without modifying application code or enabling database-wide SQL trace. Its lightweight, non-persistent nature makes it safe to leave installed in production, as output occurs only when a debug level and pipe consumer are explicitly configured.