Search Results log_variable




Overview
Explore in AI Chat

Overview

INL_LOGGING_PVT is a private PL/SQL utility package owned by the APPS schema in Oracle E-Business Suite, first shipped under the Oracle Inventory (INL) product family and carried forward across 12.1.1 and 12.2.2. It is not a business API in the transactional sense; it exists to provide a consistent, centralized instrumentation framework that other packages can call to record diagnostic trace information at runtime. By routing all diagnostic output through a single package, Oracle developers avoid embedding ad hoc message strings and commits throughout the code base, and DBAs gain a predictable place to look when tracing the execution of an instrumented program.

The package carries the header comment $Header: INLVLOGS.pls 120.4.12010000.1 2008/09/25 07:34:16 ...$, confirming it is a long-lived, stable component that was shipped well before the 12.2 release and has not undergone functional revision since. It is classified in ETRM as PVT (private), signalling that it is an internal implementation helper rather than a public application programming interface.

Key Procedures and Functions

The documented interface exposes ten procedures, organized around a small set of tracing idioms.

  • LOG_STATEMENT — writes a free-text debug message associated with a module and procedure context.
  • LOG_VARIABLE — the procedure directly relevant to the search term "log_variable". It records the name and current value of a variable at a defined point in processing, which is the primary mechanism for capturing runtime state during troubleshooting.
  • LOG_BEGINPROC / LOG_ENDPROC — bracket the entry to and exit from a procedure, producing paired trace markers that make call nesting and duration visible in the log.
  • LOG_APICALLIN — records an inbound call to an API, including the invoked API name and up to ten optional name/value pairs describing the input parameters. All parameter pairs default to NULL, so callers may supply only the arguments they consider material.
  • LOG_APICALLOUT — the outbound counterpart, capturing the API being called and the returned output parameters using the same optional name/value pairing convention.
  • LOG_EVENT — records a significant application event, allowing functional milestones to be interspersed with the finer-grained statement and variable traces.
  • LOG_EXCEPTION — records a handled exception and its context.
  • LOG_EXPECERROR — records an expected error condition, that is, a failure the calling code anticipates and handles deliberately.
  • LOG_UNEXPECERROR — records an unexpected error, typically an unhandled condition, so that it is captured distinctly from anticipated failures.

Tables Accessed

The ETRM metadata for this package does not enumerate any base tables referenced through APPS synonyms. The design of the package, however, implies a dependency on a logging repository into which the trace rows produced by the procedures are persisted, most likely accessed indirectly through APPS synonyms or a companion worker package. Because no tables are documented, integrators should treat the physical storage layer as an Oracle-internal detail rather than a supported extension point; querying or writing to any inferred log table directly is not a supported practice.

Usage Notes

INL_LOGGING_PVT is invoked from within other PL/SQL units, not directly from a form, concurrent program, or external client. This is corroborated by the metadata note that it is referenced by thirteen other packages, which constitute its real callers. Custom developers working on Oracle Inventory extensions may call the LOG_* procedures to produce trace output consistent with Oracle's own instrumentation, but because the package is classified PVT, its interface is not guaranteed to remain backward compatible across patches.

In practice, LOG_VARIABLE and LOG_STATEMENT are the most frequently invoked entry points during debugging, while LOG_BEGINPROC, LOG_ENDPROC, LOG_APICALLIN, LOG_APICALLOUT, and the exception-logging procedures form the standard wrapper pattern applied to instrumented API calls. The package should be treated as a diagnostic aid: enabling its output broadly can generate substantial data volume, so its use is normally scoped to targeted troubleshooting rather than left active in a production steady state.