Search Results g_product_code

Overview

ASN_DEBUG is a PL/SQL debugging and instrumentation utility package in the APPS schema, catalogued under the OTHER API classification. Its business function is not transactional but diagnostic: it provides a centralized mechanism by which Oracle E-Business Suite application code — particularly the Advanced Shipment Notice (ASN) and receiving integration stack — can emit trace, log, and stack information during execution. The package wraps common diagnostics infrastructure (FND_LOG, FND_FILE) and exposes a small, consistent API that other packages call to record debug output. Its presence in a 12.1.1 or 12.2.2 installation indicates that receiving-related code paths are instrumented for troubleshooting, which is significant because ASN and receiving interface errors are among the most common integration failures in EBS and are otherwise difficult to trace.

Key Procedures and Functions

The documented interface consists of ten procedures and functions, reflecting a layered logging design:

• NAME — likely a constant or accessor identifying the package for logging output.
• GET_DEBUGGING_ENABLED / IS_DEBUG_ON — determine whether debugging is currently active for the session or module, allowing calling code to avoid the overhead of building debug messages when tracing is off.
• SET_MODULE_NAME — establishes the logical module or context label used to tag subsequent debug output.
• GET_CALLING_MODULE — returns the module context in effect, supporting nested or delegated logging.
• START_PROCEDURE / STOP_PROCEDURE — bracket the entry and exit points of a traced procedure, enabling call-flow reconstruction.
• DEBUG_MSG / DEBUG_MSG_EX — emit a debug message, with the extended variant presumably supporting additional parameters such as severity, module, or structured detail.
• PRINT_STACK — outputs the current call stack, typically used when an error is trapped and the execution path must be captured.

No specific parameter lists are documented in the available metadata, and none are assumed here. The pattern is a conventional instrumentation API: gate on the debug flag, announce entry, log messages, print the stack on failure, and announce exit.

Tables Accessed

Two objects are documented as referenced through APPS synonyms:

• RCV_TRANSACTIONS_INTERFACE — the receiving transactions open interface table. Its reference indicates that ASN_DEBUG participates in the receiving interface processing path, most likely for diagnostic queries against in-flight interface records when reporting errors or tracing receiving/ASN transactions.
• DBMS_UTILITY — the standard Oracle PL/SQL utility package, commonly used for FORMAT_ERROR_STACK, FORMAT_ERROR_BACKTRACE, and call stack retrieval, which directly supports the PRINT_STACK procedure.

Additional dependencies include FND_FILE (concurrent program output/ log files), FND_LOG (the EBS logging framework), FND_PROFILE (profile option retrieval, very likely the profile option controlling whether debugging is enabled), and INV_TRX_UTIL_PUB, suggesting debug paths extend into inventory transaction utilities.

Usage Notes

ASN_DEBUG is not normally invoked directly by end users or by forms. It is a server-side utility called by other PL/SQL packages and concurrent programs. ETRM records that it is referenced by 56 other database objects while itself being referenced by no database object — an unusual direction that reflects its role as a low-level leaf library: many callers depend on it, but it depends on no higher-level EBS business API, keeping it safe to call from anywhere. Typical invocation occurs inside receiving and ASN concurrent programs and interface processing routines, and in custom code that reuses the same instrumentation pattern. Because it depends on FND_PROFILE and FND_LOG, effective output is normally governed by profile-option settings and is directed either to the concurrent request log, the EBS log tables, or both. Developers troubleshooting ASN or receiving interface failures in 12.1.1 or 12.2.2 should check whether debugging is enabled before assuming the package will produce trace output, since the gateway functions exist specifically to suppress that output by default.