Search Results xnp_trace




Overview

XNP_TRACE is a diagnostic utility package owned by the APPS schema in Oracle E-Business Suite, available in both 12.1.1 and 12.2.2. It belongs to the XNP application module, which supports Oracle's Supply Chain and order-promising infrastructure, including the document and debug frameworks used by advanced pricing, order capture, and related functional flows. As its name implies, XNP_TRACE provides a lightweight tracing and debugging mechanism that developers and support engineers can call from PL/SQL or concurrent processes to record runtime diagnostic information without deploying a full logging framework.

The package is classified under the ETRM taxonomy as "OTHER," reflecting its role as an internal technical utility rather than a business-facing API. It is not exposed to end users through standard Oracle EBS menus, and it does not implement any business transaction logic. Instead, it complements the XNP_DEBUG and XNP_DEBUG_S tables, which store debug configuration and trace output, providing a controlled, switchable diagnostic channel across XNP-driven code paths.

Key Procedures and Functions

ETRM documents one public program unit within XNP_TRACE:

  • LOG — The primary logging entry point. Callers invoke LOG to write a trace or debug message into the XNP debug store. Typical usage passes a message string and may include contextual identifiers such as a module name, severity, or session reference, depending on the caller's needs. The procedure encapsulates the mechanics of checking whether tracing is enabled for the current context before persisting the message, so callers do not need to query XNP_DEBUG directly.

No other documented procedures or functions are listed in the 12.2.2 ETRM metadata. Undocumented internal helpers may exist in the package body, but they are not part of the supported interface and should not be relied upon by customizations.

Tables Accessed

The package references two tables through APPS synonyms:

  • XNP_DEBUG — the debug configuration and trace registry table. LOG reads this table to determine whether tracing is currently active for the calling context (for example, by user, module, or debug flag) before writing output.
  • XNP_DEBUG_S — the debug sequence or supporting table associated with XNP_DEBUG. It provides the key generation or supplementary attributes required to persist trace rows consistently.

Together these tables form the persistence layer for XNP diagnostic records. Because they reside in the APPS schema and are accessed via synonyms, they are subject to standard EBS grants and are not intended for direct end-user querying outside controlled support scenarios.

Usage Notes

XNP_TRACE is typically invoked from within other XNP packages and from custom PL/SQL that needs to emit diagnostic output into the XNP debug framework. The dependency listing confirms that XNP_DOCUMENTS references XNP_TRACE, indicating that document-processing routines use the package to record trace information during execution. The package also appears as a self-reference, which is normal for packages that call their own internal subprograms and for the wrapper recorded in the data dictionary.

In practice, developers enable tracing by configuring the relevant XNP_DEBUG entries, then call XNP_TRACE.LOG at key points in their code. Support engineers review the resulting rows in the debug tables to reconstruct execution flow, diagnose pricing or ordering errors, or verify that configuration is applied as expected. Because XNP_TRACE is an internal utility, Oracle does not guarantee its signature across releases; custom code that calls LOG should be validated after patching or upgrading between 12.1.1 and 12.2.2.