Results for “nls_patch”

AI-generated from documented ETRM metadata — verify critical details on the linked pages.

Overview

FND_UMS_ANALYSIS_ENGINE is an internal Oracle E-Business Suite package body owned by APPS that implements the analysis engine for the Oracle Unified Metadata System (UMS), the framework that tracks Oracle patch and bugfix metadata across releases. In EBS 12.1.1 and 12.2.2, the package evaluates the set of applied patches and bugfixes recorded in the FND_UMS_* tables, reconciles dependency and prerequisite relationships between them, and produces the reports used by patching utilities and support diagnostics. Its header revision ($Header: AFUMSAEB.pls 120.1) confirms it is an internal, non-shipped component maintained by Oracle development rather than a public API.

The package defines a substantial set of constants that characterize its problem domain: engine modes (MODE_NOT_CALLED), bugfix release statuses (IN_PROGRESS, RELEASED, RELEASED_HIGH_PRIORITY, SUPERSEDED, OBSOLETED), patch types (US_UMS, US_NON_UMS, NLS_PATCH, NLS_BUGFIX), replacement types (ORIGINAL_REPLACEMENT, FIRST_NON_OBSOLETE_REPLACEMENT, LAST_NON_OBSOLETE_REPLACEMENT), and application statuses (NOT_APPLIED and implicitly-applied states). These constants show that the engine's business purpose is to determine, for any bugfix, whether it and all its prerequisites have effectively been applied, and to resolve obsolete or superseded bugfixes to their valid replacements.

Key Procedures and Functions

ETRM documents four callable units in this package:

• ANALYZE_DEPENDENCIES — the core engine entry point. It evaluates bugfix relationships and prerequisites recorded in the UMS metadata to determine application and dependency status across the installed patch set.
• GET_PREREQ_LIST — returns the prerequisite list associated with a bugfix, supporting the dependency resolution performed by the engine and by replacement-bugfix processing.
• GET_REPORT_COUNT — returns the number of rows the engine would produce for a given report, allowing callers to size output or detect empty result sets before retrieval.
• GET_REPORT — materializes the analysis output, typically the listing of bugfixes with their resolved statuses, relationships, and any anomalies detected during analysis.

Parameter lists for these units are not part of the documented metadata and are intentionally not reproduced here. Additional private helpers (such as the replacement-bugfix GUID resolution logic referenced in the source comments) support the public units above.

Tables Accessed

The package operates against the following objects, accessed through APPS synonyms:

• FND_UMS_BUGFIXES — the primary store of bugfix records, including release status, patch type, language, and application status flags evaluated by ANALYZE_DEPENDENCIES.
• FND_UMS_BUGFIX_RELATIONSHIPS — the prerequisite and replacement linkage between bugfixes, the basis for dependency and replacement-type resolution.
• AD_APPL_TOPS — used to resolve APPL_TOP context; the source notes that the constant GLOBAL_APPL_TOP_ID (value -1) should eventually be replaced by AD_PATCH.GLOBAL_APPL_TOP_ID.
• DBMS_UTILITY and PLITBLM — Oracle-supplied utilities used for such tasks as parsing the NEWLINE character and dynamic SQL or string/table manipulation within the engine.

The package is read-oriented; it reports on metadata maintained by other UMS components rather than authoring bugfix records itself.

Usage Notes

FND_UMS_ANALYSIS_ENGINE is not a supported public API and is referenced by no other documented packages in ETRM. It is invoked internally during patch application and validation workflows, where the engine mode variable governs whether analysis has been initiated. Custom code should not call it directly; any extension that needs UMS status information should use supported patching or AD utilities. In 12.1.1 and 12.2.2 the metadata tables have the same structure, so behavioral differences are limited. When diagnosing bugfix dependency or prerequisite errors, DBAs and support engineers typically review the reports produced by GET_REPORT, using GET_REPORT_COUNT to confirm expected volumes first.