Search Results gl_application_groups

Overview

FND_APPLICATION is the registration master table owned by APPLSYS in Oracle E-Business Suite 12.1.1 and 12.2.2. Every Oracle EBS product — Payables, Receivables, General Ledger, Order Management, and so on — is registered here as a row, and the table serves as the single authoritative source of application identity across the entire system. The APPLSYS.FND_APPLICATION table is maintained through the Oracle Application Object Library (FND) and is loaded or updated by AutoConfig and the AD (Applications DBA) utilities during installation, upgrade, and patching. Because virtually every functional and technical table in EBS carries an APPLICATION_ID or APPLICATION_SHORT_NAME discriminator, FND_APPLICATION functions as a system-wide reference hub.

From a Data Vault modeling perspective, the ETRM heuristic classification for this object is hub. This is a sound modeling suggestion: APPLICATION_ID is a stable, non-volatile business key, and the table's sole structural role is to anchor references from dependent tables. Surrounding descriptive attributes such as BASEPATH and PRODUCT_CODE could be modeled as satellite attributes in a Data Vault design, but within native EBS the table is a conventional master/reference table.

Key Information Stored

The documented physical schema contains 10 columns:

• APPLICATION_ID — the surrogate primary key (FND_APPLICATION_PK). It is the numeric identifier used as a foreign key from the vast majority of EBS tables.
• APPLICATION_SHORT_NAME — the business-key candidate enforced by unique index FND_APPLICATION_U3. Values are the familiar product short codes such as "SQLGL", "SQLAP", "AR", "FND", and "ONT".
• PRODUCT_CODE — the product code that maps to Oracle inventory and installation metadata; it commonly mirrors or closely tracks the short name.
• BASEPATH — the file system path, typically $APPL_TOP-relative, where the application's executable and library files reside.
• LAST_UPDATE_DATE, LAST_UPDATED_BY, CREATION_DATE, CREATED_BY, LAST_UPDATE_LOGIN — the standard FND audit columns applied to nearly every EBS table, used for change tracking and support diagnostics.
• ZD_EDITION_NAME — the editioning column introduced with Online Patching in 12.2. It participates in two unique indexes: FND_APPLICATION_U1 (APPLICATION_ID, ZD_EDITION_NAME) and FND_APPLICATION_U3 (APPLICATION_SHORT_NAME, ZD_EDITION_NAME). In 12.1.1 this column does not exist; the uniqueness is enforced on APPLICATION_ID and APPLICATION_SHORT_NAME alone.

The distinction between the surrogate key (APPLICATION_ID) and the business-key candidate (APPLICATION_SHORT_NAME) matters when writing joins: internal EBS code almost always joins on APPLICATION_ID, while interfaces and some legacy views reference APPLICATION_SHORT_NAME directly.

Common Use Cases and Queries

The most frequent use is resolving a numeric application identifier to a readable product name, or the reverse. A typical query lists all registered products:

• SELECT application_id, application_short_name, product_code FROM fnd_application ORDER BY application_short_name;
• Resolve an ID: SELECT application_short_name FROM fnd_application WHERE application_id = :app_id;
• Cross-reference a transaction's originating module: SELECT fa.application_short_name, oh.order_number FROM oe_order_headers_all oh, fnd_application fa WHERE oh.program_application_id = fa.application_id;

Reporting use cases include building module-level summaries (counts of orders, invoices, or journal entries by application), validating that a concurrent program or responsibility is attached to the expected product before migration, and auditing custom code that hard-codes APPLICATION_ID values. During 12.1.1-to-12.2.2 upgrades, queries against ZD_EDITION_NAME help confirm that editioning is correctly populated. The user search term "ieu_msg_messages" maps here because IEU_MSG_MESSAGES is one of the many tables carrying an APPLICATION_ID foreign key to FND_APPLICATION — the FK allows an interactive-messaging record to be tied back to the application that owns its definition.

Related Objects

The table is referenced by well over one hundred dependent objects. The most significant include:

• FND_APPLICATION_TL — the translated (language-specific) name and description, joined on APPLICATION_ID.
• FND_RESPONSIBILITY — responsibilities are scoped to an application via APPLICATION_ID.
• FND_CONCURRENT_PROGRAMS and FND_EXECUTABLES — concurrent programs and executables are owned by an application through APPLICATION_ID.
• FND_PROFILE_OPTIONS and FND_PROFILE_OPTION_VALUES — profile option definitions and values are application-scoped.
• FND_LOOKUP_TYPES and FND_TABLES / FND_VIEWS — lookup types and registered tables/views carry VIEW_APPLICATION_ID or APPLICATION_ID.
• IEU_MSG_MESSAGES — interactive-messaging definitions reference the owning application through APPLICATION_ID.
• FND_CONCURRENT_QUEUES, FND_REQUEST_GROUPS, FND_ID_FLEXS, and FND_DESCRIPTIVE_FLEXS — infrastructure objects all resolving back to FND_APPLICATION.
• FND_PRODUCT_INSTALLATIONS and FND_MODULE_INSTALLATIONS — provide the installation status and patch level corresponding to each registered application.

Related APIs are minimal because FND_APPLICATION is largely read-only reference data; changes are driven by AD utilities (adpatch, AutoConfig) and the installation process rather than by user-facing PL/SQL packages.