Search Results admin_object

Overview

BNE_ADMIN_ACTIONS is a configuration table owned by the BNE schema, the database account that supports Oracle Web Applications Desktop Integrator (Web ADI). Web ADI provides the framework through which users upload spreadsheet-based data into Oracle E-Business Suite and download report output back into Excel. Within that framework, BNE_ADMIN_ACTIONS stores the administration-level actions that can be applied to administrative objects. Each row represents a discrete administrative action associated with a specific administration group and administrative object, together with the value assigned to that action.

The table resides in both Oracle EBS 12.1.1 and 12.2.2. Its structure and purpose are unchanged between the two releases; the online patching architecture introduced in 12.2.2 does not alter the BNE data model for this object. The table is documented as VALID in the ETRM repository and consists of ten columns.

The metadata classifies BNE_ADMIN_ACTIONS as standalone with respect to foreign key structure, meaning no outgoing or incoming foreign keys were mined. As a modeling suggestion, the table behaves more like a satellite or reference table than a true hub or link: it holds descriptive attributes (the action and its value) keyed by a composite business identifier rather than by a generated surrogate. Analysts building a Data Vault representation should treat ADMIN_GROUP and ADMIN_OBJECT as the natural composite business key and ADMIN_ACTION, ADMIN_VALUE as descriptive payload.

Key Information Stored

The primary key is defined by the constraint BNE_ADMIN_ACTIONS_PK, which covers the composite of ADMIN_GROUP and ADMIN_OBJECT. A unique index, BNE_ADMIN_ACTIONS_U1, enforces the same pair (ADMIN_GROUP, ADMIN_OBJECT), confirming that the combination is the business-key candidate for the table. This is notable because there is no single-column surrogate key such as ADMIN_ACTION_ID; the composite is the sole identifier.

• ADMIN_GROUP — the administrative grouping to which the action belongs; part of both the primary key and the unique business key.
• ADMIN_OBJECT — the administrative object targeted by the action; the second component of the composite key.
• ADMIN_ACTION — the specific administrative action defined for the group and object pairing.
• ADMIN_VALUE — the value or setting associated with the administrative action.
• OBJECT_VERSION_NUMBER — the optimistic locking column used by the Oracle Application Framework to detect concurrent updates.
• CREATED_BY, CREATION_DATE — audit columns recording the user and timestamp of row insertion.
• LAST_UPDATED_BY, LAST_UPDATE_LOGIN, LAST_UPDATE_DATE — audit columns recording the most recent modification, including the login context of the updating session.

The four WHO columns (CREATED_BY, CREATION_DATE, LAST_UPDATED_BY, LAST_UPDATE_DATE) follow the standard Oracle EBS audit convention and are populated automatically by the framework rather than by application logic.

Common Use Cases and Queries

The most frequent access pattern is retrieval of all administrative actions defined for a given administration group. Because the table is small and highly static, queries are typically unfiltered or filtered on ADMIN_GROUP alone:

• SELECT admin_group, admin_object, admin_action, admin_value FROM bne.bne_admin_actions ORDER BY admin_group, admin_object;
• SELECT admin_action, admin_value FROM bne.bne_admin_actions WHERE admin_group = :p_group AND admin_object = :p_object;

Reporting use cases include auditing administrative configuration for Web ADI, documenting which actions are permitted for each administrative object, and validating that expected action-value pairs are present after an upgrade or patch. Because the composite key prevents duplicates, a lookup by ADMIN_GROUP and ADMIN_OBJECT returns exactly one row, making the table suitable for direct joins in BI Publisher or custom concurrent programs. Change tracking is supported by filtering on LAST_UPDATE_DATE for incremental extracts.

Related Objects

The ETRM metadata documents no foreign key relationships for this table, and the Data Vault heuristic classifies it as standalone. Consequently, related objects are identified by functional association within the BNE schema rather than by enforced referential constraints. The most significant dependencies and companions are:

• BNE_ADMIN_GROUPS (or equivalent BNE administration group definition) — supplies the ADMIN_GROUP values referenced logically by this table.
• BNE_ADMIN_OBJECTS — supplies the ADMIN_OBJECT values that the action definitions target.
• BNE_ADMIN_ACTIONS_PK — the primary key constraint enforcing uniqueness on ADMIN_GROUP and ADMIN_OBJECT.
• BNE_ADMIN_ACTIONS_U1 — the unique index on ADMIN_GROUP and ADMIN_OBJECT, serving as the business-key candidate.
• BNE interface and integrator tables — the broader set of BNE_* tables used by Web ADI for layout, parameter, and content management, which consume the same ADMIN_GROUP and ADMIN_OBJECT identifiers.

Because the table carries no enforced foreign keys, integrity between BNE_ADMIN_ACTIONS and its logical parents depends on application logic and seeded data rather than on database constraints. Administrators modifying this table directly should validate ADMIN_GROUP and ADMIN_OBJECT values against the corresponding master definitions to avoid orphaned administrative actions.