Search Results ece_output_pk

Overview

ECE_OUTPUT is a table in the EC (e-Commerce Gateway) product schema of Oracle E-Business Suite, valid in both 12.1.1 and 12.2.2. The ETRM documentation describes it as containing "the contents of the interface file to be created by the e-Commerce Gateway extract program." In practical terms, ECE_OUTPUT is a staging repository for the flat-file payloads that the e-Commerce Gateway generates when extracting transactional data — for example, outbound purchase orders, invoices, acknowledgements, or advance ship notices — destined for a trading partner or external system. Each row holds a segment of the outgoing interface file, tied to a specific extraction run.

The physical schema is owned by EC and consists of 12 documented columns. The primary key is ECE_OUTPUT_PK, defined on the composite of RUN_ID and LINE_ID, and a unique index ECE_OUTPUT_U1 mirrors the same column pair as the business-key candidate. The heuristic Data Vault classification mined from the foreign-key structure is standalone, meaning the table has no confirmed FK relationships to other objects in the mined metadata. As a modeling suggestion, this positions ECE_OUTPUT as an independent staging entity rather than a traditional hub, link, or satellite; the composite (RUN_ID, LINE_ID) behaves like a natural business key for a file-content staging construct.

Key Information Stored

The most important columns are:

• RUN_ID — Identifier for a specific extract program run; part of the composite primary key and unique index.
• LINE_ID — Sequence or line number within a run; the second component of the composite primary key and unique index.
• TEXT — The actual content of the interface file line. This is the payload column holding the segment or record text written to the output file.
• CREATION_DATE / CREATED_BY — Standard audit columns recording when and by whom the row was inserted.
• LAST_UPDATE_DATE / LAST_UPDATED_BY / LAST_UPDATE_LOGIN — Standard audit columns capturing the most recent modification and the login context.
• REQUEST_ID — Concurrent request identifier, linking the row to the specific concurrent program execution.
• PROGRAM_APPLICATION_ID / PROGRAM_ID — Identifiers for the application and concurrent program that produced the output.
• PROGRAM_UPDATE_DATE — Timestamp associated with the program's update of the row.

The surrogate/composite primary key (RUN_ID, LINE_ID) is distinct from the unique index ECE_OUTPUT_U1, which enforces the same business-key uniqueness on the same two columns. The remaining columns are descriptive and audit-oriented, supporting traceability back to the concurrent request that generated the file content.

Common Use Cases and Queries

Typical uses include reconstructing or auditing an outbound interface file, debugging extract runs, and confirming what content the e-Commerce Gateway produced for a given request. A representative query retrieves all lines for a run in sequence:

• SELECT line_id, text FROM ece_output WHERE run_id = :run_id ORDER BY line_id;
• Locate output by concurrent request: SELECT run_id, line_id, text FROM ece_output WHERE request_id = :request_id ORDER BY run_id, line_id;
• Identify recent runs: SELECT run_id, MIN(creation_date), COUNT(*) FROM ece_output GROUP BY run_id ORDER BY 2 DESC;

Reporting often joins REQUEST_ID back to concurrent request history (FND_CONCURRENT_REQUESTS) to present who ran the extract, when, and for what program. Because the table stores verbatim file text, it is also used to reconcile archived interface files against their source data.

Related Objects

The mined metadata classifies ECE_OUTPUT as standalone with no documented foreign keys, so associations are logical rather than enforced. Significant related objects include:

• ECE_OUTPUT_PK / ECE_OUTPUT_U1 — the primary key constraint and unique index on (RUN_ID, LINE_ID).
• FND_CONCURRENT_REQUESTS — associated via REQUEST_ID to identify the concurrent request that generated the output.
• FND_CONCURRENT_PROGRAMS — associated via PROGRAM_ID and PROGRAM_APPLICATION_ID to identify the extract program.
• Other EC e-Commerce Gateway staging tables — such as inbound/outbound interface and transaction tables that feed the extract program, connected through the run and request context rather than declared FKs.

Because ECE_OUTPUT is a standalone staging object, integrators should treat RUN_ID and REQUEST_ID as the practical join keys when correlating output content with the programs and requests that produced it.