Search Results ece_attachment_headers




Overview
Explore in AI Chat

Overview

ECE_ATTACHMENT_HEADERS is a transient staging table owned by the EC (e-Commerce Gateway) schema in Oracle E-Business Suite 12.1.1 and 12.2.2. It stores temporary header-level data that the e-Commerce Gateway uses to extract document attachments during outbound and inbound transaction processing. Because the e-Commerce Gateway operates on batched, run-based transactions, this table functions as an intermediate holding area: attachment metadata is written, associated with a specific extraction run and transaction record, and then consumed by the gateway's extraction logic. The table's 41 documented columns reflect a hybrid design that combines attachment identification, multi-part key values (PK1_VALUE through PK5_VALUE), and the standard EBS WHO columns used across nearly every transactional table.

From a heuristic Data Vault classification perspective, the mined FK structure suggests this object is best modeled as a standalone structure rather than a hub, link, or satellite. Although it carries a foreign key to FND_ATTACHED_DOCUMENTS and a unique business key, its temporary, run-scoped nature means it does not persist as durable reference data in the way a typical Hub (business key registry) or Satellite (descriptive history) would. Modelers building a warehouse layer should treat it as an operational staging artifact keyed by TRANSACTION_RECORD_ID.

Key Information Stored

The table's most operationally significant columns fall into four groups:

Common Use Cases and Queries

The primary use case is diagnosing attachment extraction failures in the e-Commerce Gateway. When an outbound document (such as an invoice or purchase order) fails to carry its PDF or text attachment, DBAs query this table by RUN_ID or TRANSACTION_RECORD_ID to confirm whether the attachment was staged. A representative query is:

  • SELECT RUN_ID, TRANSACTION_RECORD_ID, ATTACHED_DOCUMENT_ID, ENTITY_NAME, NAME, USAGE_TYPE FROM ECE_ATTACHMENT_HEADERS WHERE RUN_ID = :run_id ORDER BY ATT_SEQ_NUM;
  • Reconciling staged attachments against the source registry with ... JOIN FND_ATTACHED_DOCUMENTS fad ON fad.ATTACHED_DOCUMENT_ID = eah.ATTACHED_DOCUMENT_ID.
  • Reporting attachment volume per extraction run or per entity using GROUP BY RUN_ID or ENTITY_NAME.
  • Identifying stale or orphaned staging rows, since the table is temporary in nature and rows accumulate from historical runs that can be purged by age via CREATION_DATE.

Related Objects

  • FND_ATTACHED_DOCUMENTS — referenced by ECE_ATTACHMENT_HEADERS.ATTACHED_DOCUMENT_ID; the authoritative attachment registry.
  • FND_DOCUMENTS / FND_DOCUMENT_ENTITIES — the underlying document and entity definitions that FND_ATTACHED_DOCUMENTS resolves to.
  • FND_LOBS — stores the actual attachment binary content associated with the attached document.
  • ECE_ATTACHMENT_LINES — the line-level counterpart that typically pairs with this header table during extraction.
  • ECX_OUTBOUND_LOG / ECX_INBOUND_LOG — transaction logs whose run identifiers correlate with RUN_ID.
  • FND_CONCURRENT_REQUESTS — joins on REQUEST_ID to identify the concurrent program execution that staged each row.
  • ECX_TP_HEADERS and related EC transaction tables — provide the transactional context for PK1_VALUE through PK5_VALUE.

Together, these relationships make ECE_ATTACHMENT_HEADERS a diagnostic staging layer rather than a permanent data store, which governs how it should be queried, reported on, and purged.