Search Results dom_file_ext




Overview
Explore in AI Chat

Overview

DOM_FILE_EXT is a table within the DOM (Document Management and Collaboration) product module of Oracle E-Business Suite, owned by the DOM schema. As documented in ETRM metadata for release 12.2.2, its stated purpose is to store the status of webservices documents. The table exposes a minimal three-column structure designed to associate a document version with a repository and to record a processing or lifecycle status value. Its definition in the DOM schema is marked VALID, indicating that the object is compiled and available for use within the E-Business Suite data dictionary.

From a Data Vault modeling perspective, the heuristic classification mined from the foreign key structure is standalone. This suggests the table is not a conventional hub or link in a Data Vault sense; rather, it behaves more like a satellite or status-tracking structure attached to a version record. Analysts designing integration or reporting layers may treat DOM_FILE_EXT as an auxiliary status satellite keyed to VEA_VERSIONS, rather than as a first-class business entity.

Key Information Stored

The documented physical schema for release 12.2.2 contains three columns, summarized below:

  • VERSION_ID — The foreign key column referencing VEA_VERSIONS.VERSION_ID. This identifies the document version whose webservice document status is being tracked. It is the principal join key to the parent version record.
  • REPOSITORY_ID — Identifies the repository against which the webservice document status applies. This column participates in the unique business key.
  • STATUS — Holds the status value of the webservices document, which is the primary informational payload of the table.

The unique index DOM_FILE_EXT_U1 is defined on the column pair (VERSION_ID, REPOSITORY_ID). This composite uniqueness constraint is the documented business-key candidate: for any given version and repository combination, at most one status row exists. No separate surrogate primary key column is documented in the ETRM metadata beyond the columns listed; the unique index effectively serves as the identifying key. Because the table is compact and purpose-built, its design reflects a narrow, transactional status-recording role rather than a broad attribute-rich entity.

Common Use Cases and Queries

Typical uses center on determining whether a document version has completed webservice processing in a given repository, and on joining this status to the parent version and document metadata. A representative query retrieves status alongside version information:

  • SELECT fe.VERSION_ID, fe.REPOSITORY_ID, fe.STATUS FROM DOM.DOM_FILE_EXT fe WHERE fe.VERSION_ID = :version_id;
  • Joining to the parent to enrich reporting: SELECT v.VERSION_ID, fe.REPOSITORY_ID, fe.STATUS FROM DOM.DOM_FILE_EXT fe, DOM.VEA_VERSIONS v WHERE fe.VERSION_ID = v.VERSION_ID;
  • Counting statuses per repository for operational dashboards: SELECT REPOSITORY_ID, STATUS, COUNT(*) FROM DOM.DOM_FILE_EXT GROUP BY REPOSITORY_ID, STATUS;

These patterns support troubleshooting failed or incomplete webservice document loads, monitoring repository-level document ingestion health, and reconciling status against version lifecycle records.

Related Objects

The most significant related object is the parent version entity referenced by the documented foreign key:

  • VEA_VERSIONS — Referenced via DOM_FILE_EXT.VERSION_ID → VEA_VERSIONS.VERSION_ID. This is the primary parent table for version-level document data.
  • DOM_FILE_EXT_U1 — The unique index enforcing the (VERSION_ID, REPOSITORY_ID) business key.

Beyond these documented relationships, DOM module objects such as repository definitions and document metadata tables in the VEA and DOM schemas are commonly associated in the same functional area. Because the ETRM metadata classifies the table as standalone with a single documented foreign key, additional dependencies should be confirmed against the DOM schema before use in cross-module reporting.