Search Results bne_admin_actions_u1

Overview

BNE.BNE_ADMIN_ACTIONS is a configuration and runtime control table in the Oracle E-Business Suite (EBS) 12.1.1 and 12.2.2 environments, owned by the BNE (Common Applications Technology / Oracle Application Object Library helper) schema. As documented in the ETRM metadata, the table stores JVM-specific actions requested by an administrator. These actions can be propagated across Java Virtual Machines through this table, allowing the middle-tier application servers to coordinate runtime behavior and administrative state across a distributed deployment. The object holds a VALID status and is physically stored in the APPS_TS_TX_DATA tablespace with a PCT Free of 10.

From a Data Vault modeling perspective, the heuristic classification mined from the foreign key structure is standalone. This suggests the table is best modeled as a hub-like reference of administrative settings, rather than as a link or satellite, because it neither references nor is referenced by other database objects through formal foreign keys. The primary key, BNE_ADMIN_ACTIONS_PK, is defined on the composite of ADMIN_GROUP and ADMIN_OBJECT.

Key Information Stored

The table comprises 10 documented columns. The most important of these define the identity and payload of each administrative setting:

• ADMIN_GROUP (VARCHAR2, 30, mandatory) — Groups related settings and can be used to create levels of settings; part of the primary key.
• ADMIN_OBJECT (VARCHAR2, 30, mandatory) — The name of the setting; part of the primary key.
• ADMIN_ACTION (VARCHAR2, 30) — Describes the action associated with the setting.
• ADMIN_VALUE (VARCHAR2, 2000) — The value of the setting. This column is documented as deprecated in favour of SETTING_VALUE_CLOB, so queries should account for its legacy status.
• OBJECT_VERSION_NUMBER (NUMBER, 15) — Standard object version number used for optimistic locking and concurrency control.

The remaining columns are the standard "Who" audit columns: CREATED_BY, CREATION_DATE, LAST_UPDATED_BY, LAST_UPDATE_LOGIN, and LAST_UPDATE_DATE. The surrogate primary key is the composite of ADMIN_GROUP and ADMIN_OBJECT (BNE_ADMIN_ACTIONS_PK). The unique index BNE_ADMIN_ACTIONS_U1, stored in the APPS_TS_TX_IDX tablespace, is defined over the same two columns (ADMIN_GROUP, ADMIN_OBJECT), making them the business-key candidate that enforces uniqueness of each administrative setting.

Common Use Cases and Queries

A primary use case is retrieving the current administrative actions and their values for a given group, so that JVM runtime behavior can be inspected or audited. A representative query selects settings by group:

• SELECT admin_group, admin_object, admin_action, admin_value FROM bne.bne_admin_actions WHERE admin_group = :group;
• SELECT admin_group, admin_object, admin_action FROM bne.bne_admin_actions WHERE admin_object = :object;

Because BNE_ADMIN_ACTIONS_U1 enforces uniqueness on ADMIN_GROUP and ADMIN_OBJECT, reporting queries can safely use that pair to identify a single row. Change-tracking reports commonly use LAST_UPDATED_BY and LAST_UPDATE_DATE to determine which administrator last modified a setting, and to correlate changes across JVMs during troubleshooting. Given the deprecation of ADMIN_VALUE, comparative queries should verify whether newer CLOB-based values are being used instead.

Related Objects

The ETRM metadata records that BNE.BNE_ADMIN_ACTIONS does not reference any database object, consistent with its standalone Data Vault classification. It is referenced by the APPS synonym BNE_ADMIN_ACTIONS, which exposes the table to application code and concurrent programs running under the APPS schema. The standard Who columns relate conceptually to FND_USER.USER_ID (CREATED_BY, LAST_UPDATED_BY) and FND_LOGINS.LOGIN_ID (LAST_UPDATE_LOGIN), though these are documented as logical rather than enforced foreign keys. Administrators and developers typically join this table to FND_USER to resolve the identity of the last modifier and to trace propagation activity across middle-tier JVMs.