Search Results get_app_info

Overview

FND_INSTALLATION is a low-level Oracle E-Business Suite PL/SQL package owned by the APPS schema that exposes installation and product-registration metadata to calling code. Its principal purpose is to resolve the status, industry classification, and Oracle schema associated with an Oracle EBS application (product) as recorded in the Applications Object Library and product installation tables. Because Oracle EBS modules are registered as applications (for example, GL, AP, AR, INV) with associated base product installation records, utilities frequently need to determine whether a given product is installed, which Oracle schema owns it, and what industry vertical it belongs to. FND_INSTALLATION centralizes that lookup so that dependent code does not have to query FND_APPLICATION, FND_ORACLE_USERID, and FND_PRODUCT_INSTALLATIONS directly.

The package is classified as OTHER in the ETRM registry, meaning it is an internal support API rather than a documented public business API. Its source header (AFINSTLS.pls 120.2) and the presence of compiler pragma RESTRICT_REFERENCES declarations indicate it is intended for efficient, read-consistent use inside PL/SQL, not as a transactional business interface. The package is referenced by 575 other packages, which confirms its role as pervasive infrastructure in the EBS technology stack across both 12.1.1 and 12.2.2 releases.

Key Procedures and Functions

• GET — Returns application installation information based on an application identifier and a dependent application identifier, returning status and industry as output parameters. The comment block documents that the appl_id argument is no longer meaningful and that resolution is driven by dep_appl_id and the current schema, so the same arguments may yield different results depending on which schema the caller is connected to.
• GET_APP_INFO — Returns installation information keyed by application short name, returning status, industry, and the owning Oracle schema as outputs. As with GET, results are schema-dependent because resolution incorporates the currently connected schema; the same short name may resolve differently from different schemas.
• GET_APP_INFO_OTHER — Provides deterministic, schema-independent resolution. It accepts a target_schema argument and ignores the current schema, so repeated calls with identical arguments return identical results regardless of the caller's connection.

All three functions are declared with PRAGMA RESTRICT_REFERENCES (WNDS, WNPS), signaling that they perform no database writes and read no package state, which allows the PL/SQL optimizer to treat them as pure reads within SQL and PL/SQL contexts.

Tables Accessed

The package reads three documented tables through APPS synonyms. FND_APPLICATION supplies the registered application metadata, including application short name and base product information, and is central to short-name-based resolution. FND_PRODUCT_INSTALLATIONS provides the installation status and industry classification for each registered product, which is what the status and industry output parameters derive from. FND_ORACLE_USERID maps applications to their owning Oracle database schemas, supplying the oracle_schema output used by GET_APP_INFO and GET_APP_INFO_OTHER. All access is read-only, consistent with the WNDS restriction.

Usage Notes

FND_INSTALLATION is typically invoked from other EBS PL/SQL packages, concurrent program logic, and custom extensions that must confirm whether a product is installed before executing dependent logic, or that must locate the schema that owns a given application. Because GET and GET_APP_INFO are schema-sensitive, custom code that runs from a fixed schema — such as APPS — should prefer GET_APP_INFO_OTHER when repeatable results are required across environments or session contexts. The package is not a user-facing API and is not exposed through standard EBS forms; it is a foundational utility invoked by the hundreds of dependent packages that depend on accurate application-registration metadata. Developers should treat the documented signatures as stable and avoid assumptions about the deprecated appl_id argument in GET.