Search Results dbms_output




Overview
Explore in AI Chat

Overview

The APPS.FND_AUDIT_REPORT package is an Oracle E-Business Suite utility that belongs to the Application Object Library (FND) auditing infrastructure. Its business function is to validate the configuration of audit schemas — the shadow tables, columns, and supporting metadata that Oracle EBS generates when auditing is enabled on application tables. When a customer enables auditing for a table through the AuditTrail setup forms, the system creates an associated audit schema, audit group, and shadow object. Over time these structures can drift out of sync with the live dictionary, producing silent loss of audit history or runtime errors during audited DML. FND_AUDIT_REPORT exists to detect and report exactly these inconsistencies by comparing the shadow objects registered in EBS audit metadata against the actual database catalog.

The header line $Header: AFATRPTS.pls 120.2 2005/10/25 ... noship $ indicates the package is a long-standing, non-shipped utility module that has been stable across releases and is present in 12.1.1 as well as 12.2.2. It is not an API in the sense of a supported business interface — its ETRM classification is OTHER, meaning it is a reporting/diagnostic helper rather than a transactional interface.

Key Procedures and Functions

ETRM documents two procedures in the package specification:

  • PRINT_OUTPUT — A shared logging helper. It writes a supplied data string either to the concurrent manager log file or to DBMS_OUTPUT, depending on a LOG flag ('Y' for concurrent manager log, 'N' for DBMS_OUTPUT). It accepts default values so callers may omit the log target and data. This procedure provides the consistent, tagged output format used by the validation report and is reused internally whenever the package emits diagnostic text.
  • AUDIT_GROUP_VALIDATION — The functional heart of the package. It is implemented as a PL/SQL stored procedure concurrent program that produces an exception report for audit schema validation. Invoked with a group name, it examines the audit definitions belonging to that audit group and reports any discrepancies between the registered audit metadata and the physical database objects. It follows the standard concurrent program signature convention with ERRBUF and RETCODE output parameters, plus optional GROUP_NAME, PROGNM, and LOG inputs. If GROUP_NAME is omitted, the procedure operates without restricting to a single group.

Tables Accessed

The package reads a broad set of FND and dictionary views through APPS synonyms:

  • FND_AUDIT_GROUPS, FND_AUDIT_SCHEMAS, FND_AUDIT_TABLES, FND_AUDIT_COLUMNS — the EBS audit metadata repository. These define which groups, schemas, tables, and columns are configured for auditing and form the baseline against which validation is performed.
  • FND_APPLICATION and FND_ORACLE_USERID — resolve application short names, Oracle schema names, and credentials referenced by the audit definitions.
  • FND_TABLES — the registered table inventory used to confirm that an audited table still exists in the FND table registry and matches its shadow object.
  • ALL_TAB_COLUMNS, DBA_TAB_COLUMNS, DBA_OBJECTS — the data dictionary views used to verify that the physical shadow table, columns, and objects actually exist and are valid.
  • USER_SYNONYMS and DUAL — used for synonym resolution and for seeding/single-row evaluation within the reporting logic.

Usage Notes

FND_AUDIT_REPORT is normally consumed indirectly. AUDIT_GROUP_VALIDATION is registered as a concurrent program so that administrators can submit an Audit Group Validation request from the standard Submit Requests form (or via the concurrent manager) to obtain an exception report of audit schema problems. Custom diagnostic scripts and DBA tooling may also invoke AUDIT_GROUP_VALIDATION directly from SQL*Plus or a PL/SQL wrapper, in which case the LOG parameter should be set to 'N' so results are emitted through DBMS_OUTPUT; PRINT_OUTPUT is available as a supporting utility for such custom callers. Because the package appears throughout both 12.1.1 and 12.2.2, the same invocation strategy applies to both releases. No other shipped packages depend on it (ETRM lists zero referencing packages), so it can be treated as a leaf diagnostic utility safe to call from ad hoc validation procedures.