Results for “fnd_adpatch”

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

Overview

FND_ADPATCH is a low-level Oracle E-Business Suite utility package that supports the Applications DBA (AD) patch driver infrastructure. It is owned by APPS and is classified under the generic OTHER API category, meaning Oracle does not publish it as a supported public interface for customer extension. Its single documented entry point, Post_Patch, is a post-processing routine executed by the AutoPatch session after a patch has been applied. In the context of Oracle EBS 12.1.1 and 12.2.2, the package bridges the AD patching utilities and the concurrent manager metadata stored in the FND tables, ensuring that menu, responsibility, and concurrent program definitions are correctly reconciled once patch files have been copied and database objects recompiled.

The name and the internal comment header (indicating an AutoPatch session ID) confirm that the function is intended to be called once per patching session, with the session identifier passed in and a textual status returned to the caller.

Key Procedures and Functions

The only documented routine in this package is POST_PATCH. It is a function that accepts an AutoPatch session identifier and returns a Boolean-style VARCHAR2 result of TRUE or FALSE, consistent with many legacy FND utility functions. It also returns, through an output parameter, a human-readable message such as "Executed Successfully" or an error description. Its purpose is to perform the post-application processing associated with a completed patch run: refreshing the security and concurrent program metadata that the patch may have changed, and reporting back to the AutoPatch driver whether this phase completed successfully.

No other procedures or functions are documented in the ETRM metadata. The header also declares AUTHID CURRENT_USER, so the routine executes with the privileges of the calling session rather than the definer, allowing the invoking patch driver to operate under the appropriate AD or APPS credentials.

Tables Accessed

The documented table references, reached through APPS synonyms, are FND_APPLICATION, FND_CONCURRENT_PROGRAMS, FND_CONCURRENT_REQUESTS, FND_RESPONSIBILITY, and FND_USER. Together these tables define the application registrations, concurrent program definitions and their request history, responsibility assignments, and user accounts. Post_Patch reads and updates these tables to reconcile metadata after a patch: validating that newly installed or altered concurrent programs are registered correctly, that responsibilities and users remain valid, and that the application definitions that own these objects are consistent. This reconciliation prevents invalid request submissions and menu security failures immediately following a patch.

Usage Notes

FND_ADPATCH is not intended for direct invocation by end users or from application forms. It is called programmatically by the AutoPatch driver and related AD utilities at the conclusion of a patch application, and it is referenced by one other package within the APPS schema. Custom code should not invoke Post_Patch directly, because it depends on a valid AutoPatch session and current patch context. The safest and supported practice is to allow AutoPatch to call the routine automatically. In 12.2.2 online patching environments, the equivalent reconciliation occurs within the patching cycle, and administrators should rely on the standard adop and AutoPatch phases rather than calling this package manually. Troubleshooting should focus on reviewing AutoPatch logs, not on re-invoking this internal API.