Results for “bne_objects”

AI-generated from documented ETRM metadata — verify critical details on the linked pages.

Overview

BNE_OBJECTS is the foundational repository table for the BNE schema (Web Applications Desktop Integrator, commonly known as Oracle Web ADI) within Oracle E-Business Suite 12.1.1 and 12.2.2. The table resides in the BNE schema and holds the base registration record for every object managed by the Web ADI framework, including integrators, layouts, and related desktop integration metadata. Each object is scoped to a specific Oracle application, allowing the same object code to exist independently across multiple products.

Heuristic data vault modeling classifies BNE_OBJECTS as standalone, with no mined foreign key dependencies pointing into or out of the table. From a dimensional modeling perspective, the composite key of APPLICATION_ID and OBJECT_CODE behaves as the natural business key of a hub, with the remaining descriptive and audit columns functioning as satellite attributes. The absence of FK relationships reinforces its role as a self-contained reference entity rather than a transactional or junction table.

Key Information Stored

The documented physical schema comprises twelve columns, of which the following are the most significant:

• APPLICATION_ID — Identifies the Oracle application (product) that owns the object; part of the composite primary key.
• OBJECT_CODE — The internal code uniquely identifying the object within the application; the second component of the primary key.
• OBJECT_TYPE — Classifies the object (for example, integrator or layout), driving how Web ADI processes it.
• OBJECT_DATA — Stores the object's functional definition or configuration payload.
• OBJECT_VERSION_NUMBER — Supports optimistic locking and version tracking for concurrent updates.
• ORACLE_CHARSET and TEXT_CHARSET — Define the character set characteristics used when the object's data is rendered or exchanged.
• CREATED_BY, CREATION_DATE, LAST_UPDATED_BY, LAST_UPDATE_LOGIN, LAST_UPDATE_DATE — The standard EBS WHO columns capturing audit and last-touch information.

The surrogate primary key is BNE_OBJECTS_PK (APPLICATION_ID, OBJECT_CODE). The unique index BNE_OBJECTS_UK1 mirrors the same column pair, confirming APPLICATION_ID and OBJECT_CODE as the business-key candidates. Note that the composite key also serves as the primary key, so no separate single-column surrogate exists.

Common Use Cases and Queries

Typical usage centers on diagnosing and reporting Web ADI integrator and layout registrations. Common scenarios include verifying that an integrator exists for a given application, auditing custom objects created during implementation, and reconciling version or audit history for compliance reporting.

• Locate a specific integrator: SELECT object_code, object_type FROM bne.bne_objects WHERE application_id = :app_id AND object_code = :code;
• Enumerate all objects for a product: SELECT object_code, object_type, creation_date FROM bne.bne_objects WHERE application_id = :app_id ORDER BY object_code;
• Audit recently modified objects: SELECT object_code, last_updated_by, last_update_date FROM bne.bne_objects WHERE last_update_date > SYSDATE - 30;
• Identify custom integrators by joining to FND_APPLICATION to resolve application names.

Because OBJECT_DATA may contain large definitions, reporting queries should avoid selecting it unless required, favoring selective column projections for performance.

Related Objects

Although the metadata records BNE_OBJECTS as a standalone entity with no mined foreign keys, its practical role in Web ADI links it to the following commonly referenced objects:

• BNE_INTEGRATORS — Defines integrator metadata; joined via APPLICATION_ID and OBJECT_CODE.
• BNE_LAYOUTS — Stores layout definitions tied to integrators via APPLICATION_ID and OBJECT_CODE.
• BNE_CONTENTS — Holds content or parameter definitions associated with an object.
• FND_APPLICATION — Resolves APPLICATION_ID to an application short name and description.
• BNE_PARAMETERS — Captures parameter metadata linked to objects by APPLICATION_ID and OBJECT_CODE.

JOIN conditions should consistently use the composite pair APPLICATION_ID and OBJECT_CODE, since these constitute the primary key and the documented unique business key.