Search Results dscfg_api_pkg

Overview

The APPS.FND_OAM_DSCFG_OBJECTS_PKG package is a component of the Oracle E-Business Suite Diagnostics and Configuration framework, commonly associated with the Oracle Application Manager (OAM) infrastructure. It manages configuration objects — discrete records that represent mappable and comparable entities within a configuration snapshot or configuration instance. These objects serve as the fundamental building blocks used by the diagnostics subsystem to capture, store, compare, and migrate configuration data across EBS environments.

The package is defined with AUTHID CURRENT_USER, meaning that it executes with the privileges of the invoking user rather than the package owner, allowing the calling context to control access to underlying objects. Its role is tightly coupled to the broader configuration-instance lifecycle: objects can only be created once a configuration instance has been created or selected. The header identifies object types as being stored externally in DSCFG_API_PKG, which acts as the registry of valid object type constants referenced throughout the framework. This design cleanly separates the object-management operations from the type and API definitions.

Key Procedures and Functions

The documented public interface exposes four procedures and functions:

• ADD_OBJECT — Creates a new configuration object record. It draws the configuration instance identifier from the INSTANCES_PKG, which forces a call to create or use a configuration instance, and attempts to derive the import procedure identifier from IMPORT_PROCS_PKG. The procedure is explicitly not autonomous, so callers can package properties, mapped keys, and related entities within a single commit. It accepts parameters governing the object type (corresponding to an API_PKG.G_OTYPE_* constant), an optional parent object identifier (used to link argument objects to their parent DML-operation object), optional source type and source ID values, an error flag, and a message field, and it returns the newly created object ID. It raises NO_DATA_FOUND if the configuration instance has not been initialized.
• GET_OBJECTS_FOR_TYPE — Retrieves configuration objects filtered by object type, supporting the enumeration and comparison logic required by the configuration subsystem.
• DELETE_OBJECT — Removes a configuration object and its dependent records, supporting cleanup and snapshot maintenance.

Tables Accessed

The package references the following objects through APPS synonyms:

• FND_OAM_DSCFG_OBJECTS — The primary transactional table storing configuration object records, including parent-child relationships, source references, and error or message state.
• FND_OAM_DSCFG_OBJECTS_S — The corresponding sequence (or supporting seed/sequence object) used to generate unique object identifiers returned by ADD_OBJECT.
• DBMS_SQL — The Oracle-supplied dynamic SQL package, invoked for dynamic query execution, typically to accommodate the variable structure of configuration properties across object types.

In addition, the package logically depends on INSTANCES_PKG and IMPORT_PROCS_PKG for instance and import-procedure resolution, and on DSCFG_API_PKG for the object type constants that drive its behavior.

Usage Notes

FND_OAM_DSCFG_OBJECTS_PKG is an internal, non-UI-facing package invoked programmatically rather than directly by end users. It is referenced by two other packages within the framework, one of which is the configuration API layer that exposes the higher-level API surface (dscfg_api_pkg) referenced in user searches. Typical invocation paths include:

• Concurrent programs and diagnostics routines that build or refresh a configuration instance, where ADD_OBJECT is called after the instance is initialized.
• Import and comparison utilities that enumerate objects by type via GET_OBJECTS_FOR_TYPE to detect differences between source and target systems.
• Housekeeping logic that calls DELETE_OBJECT to purge stale or superseded configuration data.

Because the package is not autonomous, callers must manage commits deliberately, grouping related writes into a single transaction. Direct custom invocation is discouraged; developers should prefer the documented configuration API layer, which encapsulates the required ordering invariants — notably the precondition that a configuration instance exist before any object is added.