Search Results ece_attachment_headers_u1

Overview

EC.ECE_ATTACHMENT_HEADERS is an interface table in the Oracle E-Business Suite EC (E-Commerce Gateway / Extensible Common Architecture) schema that holds temporary header-level data used during the extraction of attachments from Oracle EBS. Its primary purpose is to stage the metadata that links a binary or textual attachment to its parent document — for example, a purchase order line, a trading partner document, or another EBS entity — prior to extraction or transmission. The table resides in the APPS_TS_INTERFACE tablespace, confirming its role as a persistent staging structure rather than a transactional master table. It is flagged as having FND Design Data, meaning it is registered with the Oracle Application Object Library and can be referenced through the standard EBS dictionary. Its documented status is VALID.

Based on the mined dependency structure, this table is classified heuristically as standalone within a Data Vault modeling perspective. This classification reflects the fact that the table carries only a single reference to an external object (FND_ATTACHED_DOCUMENTS via ATTACHED_DOCUMENT_ID) and does not itself act as a hub, link, or satellite of a larger integrated model. In practice, ECE_ATTACHMENT_HEADERS functions as a transient staging table whose lifecycle is tied to a specific extraction run, not to the permanent attachment record itself; the actual content body is persisted separately in ECE_ATTACHMENT_DETAILS.

Key Information Stored

The table contains 41 documented columns. Among the most operationally significant are:

• TRANSACTION_RECORD_ID — The column defined by the unique index ECE_ATTACHMENT_HEADERS_U1. It is the business-key candidate that distinguishes each header record for a given extraction transaction. Note that the documentation excerpt does not designate a separate surrogate primary key column; the unique index on TRANSACTION_RECORD_ID serves as the effective unique identifier.
• RUN_ID — Identifies the extraction run that produced the record and is indexed non-uniquely by ECE_ATTACHMENT_HEADERS_N1, enabling efficient retrieval of all headers created by a single run.
• DOCUMENT_ID — The identifier of the parent document to which the attachment belongs.
• ENTITY_NAME — The entity type (for example, purchase order or trading partner document) that owns the attachment.
• NAME — The attachment category name, which classifies the kind of attachment being extracted.
• PK1_VALUE through PK5_VALUE — A set of up to five positional primary-key values that, taken together, address the specific parent record (such as a purchase order line) within the source entity.
• ATT_SEQ_NUM — The attachment sequence number, used to order multiple attachments on the same parent document.
• DATATYPE_ID — Indicates the data type of the attachment body, informing downstream interpretation of the content stored in ECE_ATTACHMENT_DETAILS.
• DESCRIPTION, USAGE_TYPE, and LANGUAGE — Descriptive and contextual attributes of the attachment.
• ATTRIBUTE_CATEGORY and ATTRIBUTE1 through ATTRIBUTE15 — A standard EBS descriptive flexfield block allowing extension of the header record without schema change.
• ATTACHED_DOCUMENT_ID — A foreign key to FND_ATTACHED_DOCUMENTS that anchors the staged record to the underlying EBS attachment repository.

Standard EBS auditing and concurrent program columns (CREATION_DATE, CREATED_BY, LAST_UPDATE_DATE, LAST_UPDATED_BY, LAST_UPDATE_LOGIN, REQUEST_ID, PROGRAM_APPLICATION_ID, PROGRAM_ID, and PROGRAM_UPDATE_DATE) are also present and are populated by the producing concurrent request.

Common Use Cases and Queries

The most frequent access pattern is by RUN_ID, since an extraction process retrieves all attachment headers queued for a given run. A typical query joins the header table to its detail table to reconstruct the full attachment for transmission:

• Retrieving all headers for a specific extraction run:
  SELECT * FROM ec.ece_attachment_headers WHERE run_id = :p_run_id ORDER BY att_seq_num;
• Loading attachment bodies for a run by joining to the details table on the shared header identity (TRANSACTION_RECORD_ID or DOCUMENT_ID plus ATT_SEQ_NUM, per the implementation's join convention).
• Auditing which parent documents had attachments extracted during a batch by projecting ENTITY_NAME, DOCUMENT_ID, PK1_VALUE through PK5_VALUE, and NAME.
• Reconciliation against FND_ATTACHED_DOCUMENTS via ATTACHED_DOCUMENT_ID to confirm that every staged header corresponds to a still-valid source attachment.
• Operational troubleshooting of failed extractions by filtering on REQUEST_ID or PROGRAM_ID to isolate records produced by a specific concurrent program execution.

Because the table is an interface structure, it is typically purged after successful extraction; queries should therefore scope carefully by RUN_ID or REQUEST_ID rather than scanning the full table.

Related Objects

• EC.ECE_ATTACHMENT_DETAILS — The companion interface table holding the actual attachment body content, keyed to the header record.
• FND_ATTACHED_DOCUMENTS — The EBS attachment repository, referenced through ATTACHED_DOCUMENT_ID.
• EC.ECE_ATTACHMENT_HEADERS_U1 — The unique index on TRANSACTION_RECORD_ID.
• EC.ECE_ATTACHMENT_HEADERS_N1 — The non-unique index on RUN_ID supporting run-based retrieval.
• FND_DOCUMENTS / FND_DOCUMENT_ENTITIES — The underlying document and entity registry that the attachment header references through its NAME and ENTITY_NAME columns.
• EC.ECE_TP_HEADERS and related EC interface tables — Sibling interface tables populated by the same EC extraction programs.
• FND_ATTACHMENT_FUNCTIONS — The EBS API layer commonly used to read and write attachment records that ultimately source this staging table.