Search Results fnd_enabled_plsql

Overview

FND_ENABLED_PLSQL is a control table in the Oracle E-Business Suite Application Object Library (FND) product, owned by the APPLSYS schema. Its documented purpose is to maintain the list of PL/SQL packages and procedures that are accessible by the web server. In EBS 12.1.1 and 12.2.2 the middle tier invokes server-side PL/SQL through the Oracle Applications Framework and related servlet infrastructure; FND_ENABLED_PLSQL acts as an allow-list that the web server consults to determine whether a given PL/SQL program unit may be executed on behalf of a browser request. The table therefore plays a security and configuration role rather than a transactional one, and administrators interact with it primarily during patching, upgrades, and troubleshooting of web-tier PL/SQL invocation failures.

Under the heuristic Data Vault classification mined from the foreign-key structure, this object is identified as standalone. That classification suggests it is neither a hub nor a link between other business entities, and functions more like a reference or control satellite: a small, self-contained set of rows keyed only by the type and name of the PL/SQL unit. No dependent foreign-key relationships to other EBS tables were documented, which is consistent with its role as a lookup-style configuration table rather than a transactional entity.

Key Information Stored

The table is documented with 9 physical columns in the ETRM 12.2.2 schema definition. The most important of these are the two columns that constitute the primary key, FND_ENABLED_PLSQL_PK, and the matching unique index FND_ENABLED_PLSQL_U1 — both defined on the column pair (PLSQL_TYPE, PLSQL_NAME). These two columns are the business-key candidates: PLSQL_TYPE distinguishes the category of the program unit (for example, whether the entry denotes a package or a procedure), while PLSQL_NAME holds the actual PL/SQL package or procedure identifier. Together they uniquely identify each enabled program unit, and because the primary key is composite and natural, there is no separate surrogate identifier column in the documented schema.

The remaining documented columns support the enable/disable decision and the standard EBS audit trail. ENABLED is the operative flag that determines whether the named PL/SQL unit is permitted to be invoked by the web server. EXTERNAL is a flag indicating whether the entry is externally sourced or externally accessible. The audit columns — LAST_UPDATE_DATE, LAST_UPDATED_BY, CREATION_DATE, CREATED_BY, and LAST_UPDATE_LOGIN — follow the standard FND who-column convention and record who created or last modified each row, when the change occurred, and the login context of the change. These audit columns are populated automatically by the EBS framework and are commonly used in change-tracking and diagnostic queries.

Common Use Cases and Queries

Typical operational scenarios include verifying that a specific package is enabled before invoking it from a web-based page, reconciling the contents of the table against the actual PL/SQL objects in the APPLSYS schema, and auditing recent changes made by administrators or patch drivers. A frequent query checks the enabled state of a named unit:

• SELECT PLSQL_TYPE, PLSQL_NAME, ENABLED, EXTERNAL FROM APPLSYS.FND_ENABLED_PLSQL WHERE PLSQL_NAME = :name AND ENABLED = 'Y';
• Listing all enabled entries by type: SELECT PLSQL_TYPE, COUNT(*) FROM APPLSYS.FND_ENABLED_PLSQL WHERE ENABLED = 'Y' GROUP BY PLSQL_TYPE;
• Change auditing: SELECT PLSQL_TYPE, PLSQL_NAME, LAST_UPDATED_BY, LAST_UPDATE_DATE FROM APPLSYS.FND_ENABLED_PLSQL WHERE LAST_UPDATE_DATE > SYSDATE - 30 ORDER BY LAST_UPDATE_DATE DESC;

These patterns are useful during post-patch validation, when confirming that newly deployed PL/SQL units were correctly registered as enabled, and when investigating "procedure not enabled" or permission errors surfaced by the middle tier. Because the table is small and its access path is driven by the primary key, index lookups on (PLSQL_TYPE, PLSQL_NAME) are efficient and reporting queries rarely require joins.

Related Objects

The ETRM metadata documents FND_ENABLED_PLSQL as having no foreign-key relationships and a standalone Data Vault classification, so there are no documented parent or child tables joined by FK columns such as PLSQL_TYPE or PLSQL_NAME. Related objects are therefore inferred from function rather than from constrained relationships, and the following are the most significant for operational purposes:

• FND_ENABLED_PLSQL_PK — the composite primary key constraint over (PLSQL_TYPE, PLSQL_NAME).
• FND_ENABLED_PLSQL_U1 — the unique index enforcing the same business key, used for fast lookups.
• The APPLSYS schema's stored PL/SQL program units (packages and procedures) — the objects whose names appear in PLSQL_NAME and whose runtime availability is gated by the ENABLED flag.
• The EBS web-tier components of FND that consult this allow-list when serving browser requests, including the Oracle Applications Framework (OA Framework / FND) runtime.
• The standard FND audit and user tables referenced conceptually through CREATED_BY and LAST_UPDATED_BY, which store the user identifiers recorded in the audit columns.

Because no FK evidence was supplied, these dependencies should be treated as functional rather than referential. Any extension or reporting object built against this table should key on (PLSQL_TYPE, PLSQL_NAME) and treat the enablement flag and audit columns as the primary attributes of interest.