Search Results pa_product_install_utils




Overview
Explore in AI Chat

Overview

PA_PRODUCT_INSTALL_UTILS is a licensing-verification utility package owned by the APPS schema in Oracle E-Business Suite. Its purpose is to determine whether a specific Oracle EBS object — a form function, an OA Framework/AK region, or a generic product object — is licensed for use by the current installation. Projects (PA) and other product modules use this package as a central gatekeeper before rendering functionality or executing logic that depends on separately licensed options.

The package is declared AUTHID CURRENT_USER, meaning its SQL executes with the privileges of the calling user rather than the definer. The header bears the version string $Header: PAPIUTLS.pls 120.1 2005/08/19 16:40:45 mwasowic noship $, indicating the codebase is stable and unchanged since the 11i era, yet it remains shipped and functional in 12.1.1 and 12.2.2. The ETRM classification for the package is OTHER, and it is referenced by four other APPS packages, confirming it is a shared infrastructure utility rather than an end-user-facing API.

Key Procedures and Functions

  • check_function_licensed (function) — Returns a single-character indicator of eligibility: Y when the current installation is licensed to use the named function, and N when it is not. It accepts the function name as its input parameter and is the most commonly called entry point in this package.
  • check_function_licensed (procedure) — A procedural overload of the same logic that returns results through standard EBS error-handling OUT parameters: a return code, a return status, and the standard message count and message data fields. This form integrates with the FND message stack so callers can surface a localized error to the user.
  • check_object_licensed (function) — A generalized version of the licensing check that accepts both an object type and an object code, returning Y or N. It allows callers to test licensing for categories of objects beyond functions.
  • validate_object (procedure) — Performs validation of an object identified by type and code, reporting the outcome through the standard OUT parameters (return code, return status, message count, message data).
  • check_region_licensed (procedure) — Determines whether the installation is licensed to use a specified AK region, using the same four OUT parameter error-reporting convention.

All OUT parameters in these signatures are declared NOCOPY for performance, consistent with the File.Sql.39 / Bug 4440895 standard applied across the EBS codebase.

Tables Accessed

  • FND_FORM_FUNCTIONS — The Oracle Application Object Library table that defines form functions. It is queried to resolve the function name supplied to check_function_licensed and to derive the licensing attributes associated with that function.
  • AK_REGIONS — The AK (Application Kit) region repository. It is read by check_region_licensed to identify the region being tested and to evaluate its licensing designation.
  • PA_PRODUCT_FUNCTIONS — The Projects product function mapping table. It supplies the product-to-function associations that determine which Projects functionality is licensed, tying the generic licensing logic to the PA product family.

All three tables are accessed through APPS synonyms, so the package depends on the standard APPS synonym layer rather than direct schema-qualified references.

Usage Notes

PA_PRODUCT_INSTALL_UTILS is an internal infrastructure package, not a published public API. It is typically invoked from Forms-based code, OA Framework regions, and other PL/SQL packages (four documented dependent packages) immediately before displaying licensed functionality, so that unlicensed features can be hidden or blocked gracefully. Customizations that extend Projects functionality should call check_function_licensed rather than querying FND_FORM_FUNCTIONS directly, ensuring consistent behavior across releases and patch levels. Because the package uses AUTHID CURRENT_USER, callers must have appropriate grants on the underlying tables. The metadata excerpt does not document all six underlying routines in full, so developers should treat the four public routines above as the supported surface and avoid depending on undocumented internals.