Search Results is_initialized

Overview

FND_OAM_DSCFG_PROCS_PKG is an Oracle E-Business Suite package owned by the APPS schema that supports the Applications Diagnostics (OAM) configuration framework. Its name derives from "DSCFG" (Diagnostics Configuration) and "PROCS" (Procedures), indicating that it manages the metadata and runtime state associated with the diagnostic procedures registered in the EBS environment. The package acts as a paired controller: it provides a stateful accessor layer over the currently executing diagnostic procedure, and it supplies the standard row-level DML operations for maintaining the underlying FND_OAM_DSCFG_PROCS configuration table.

In the context of Oracle EBS 12.1.1 and 12.2.2, this package belongs to the internal diagnostics infrastructure rather than to a business-facing module. It is not a "noship" package in the sense of being unused; the header comment, dated 2005, is carried forward from earlier releases, and the package remains documented in ETRM 12.2.2 with an API classification of OTHER. It is referenced by three other packages, confirming that it is part of an interdependent runtime chain used during diagnostics execution and configuration maintenance.

Key Procedures and Functions

The package exposes thirteen documented routines, divisible into three functional groups. The first group is the runtime state accessor set, which reads the package's internal state during procedure execution:

• IS_INITIALIZED — Boolean accessor returning TRUE when the internal package state has been initialized. Used defensively before other accessors are called.
• GET_CURRENT_ID — Returns the proc_id of the in-progress procedure. Only valid after GET_NEXT_PROC or SET_CURRENT_PROC has been called.
• GET_CURRENT_TYPE — Returns the proc_type of the in-progress procedure, drawn from the procedure type constants defined in DS_API_PKG. This is the routine most directly associated with the search term "get_current_type."
• GET_CURRENT_ERROR_IS_FATAL — Returns the error_is_fatal_flag associated with the current procedure, indicating whether a failure aborts the diagnostic run.
• GET_CURRENT_LOCATION — Returns the location attribute of the currently executing procedure.
• GET_CURRENT_EXECUTABLE — Returns the executable attribute of the currently executing procedure.

The second group governs the transition between procedures in a diagnostic run:

• GET_NEXT_PROC — Advances the package state to the next procedure to be executed, populating the accessor values.
• SET_CURRENT_PROC — Explicitly sets the current procedure in the package state, allowing a caller to override sequential advancement.

The third group provides conventional table maintenance against FND_OAM_DSCFG_PROCS: LOAD_ROW, INSERT_ROW, LOCK_ROW, UPDATE_ROW, and DELETE_ROW. These follow the standard EBS generated-handler pattern for loading a row into a record, inserting, pessimistic locking, updating, and deleting a configuration record.

Tables Accessed

The package operates against a single documented base table, FND_OAM_DSCFG_PROCS, accessed through an APPS synonym. This table stores the registered diagnostic procedures and their configuration attributes, including proc_id, proc_type, location, executable, and error_is_fatal_flag — the same attributes surfaced by the accessor functions. The DML routines (INSERT_ROW, UPDATE_ROW, DELETE_ROW, LOCK_ROW, LOAD_ROW) maintain these rows, while the accessor functions expose the attributes of the row currently in progress.

Usage Notes

FND_OAM_DSCFG_PROCS_PKG is typically invoked from within the diagnostics execution framework rather than directly by end users. The accessor functions depend on package state and will raise NO_DATA_FOUND if called before GET_NEXT_PROC, SET_CURRENT_PROC, or another initialization path has established the current procedure context. Custom code should therefore check IS_INITIALIZED before invoking GET_CURRENT_ID, GET_CURRENT_TYPE, GET_CURRENT_ERROR_IS_FATAL, GET_CURRENT_LOCATION, or GET_CURRENT_EXECUTABLE. The row-handling routines are the appropriate entry points for maintaining diagnostic procedure configuration and should be used in preference to direct DML so that LOCK_ROW semantics and validation are honored. Because the package is referenced by three other packages, modifications to its behavior can propagate through the diagnostics stack in both 12.1.1 and 12.2.2.