Search Results ece_error

Overview

ECE_ERROR is a table in the EC (e-Commerce Gateway) schema of Oracle E-Business Suite, present in both release 12.1.1 and 12.2.2. Per the ETRM documentation, it "contains the Oracle EDI Gateway processing error messages used by Development for debugging purposes." This statement of purpose is significant: ECE_ERROR is not a functional or user-facing repository of business data. It is a diagnostic table populated by the e-Commerce Gateway concurrent programs and internal processing routines to capture error text generated during EDI inbound and outbound processing. It is principally consumed by Oracle Development and, in practice, by support analysts tracing why a specific gateway run failed.

The heuristic Data Vault classification mined from the foreign-key structure is standalone. In Data Vault modeling terms this is best read as a suggestion that the table behaves as an isolated, non-conformed record set rather than as a hub, link, or satellite participating in a shared integration bus. Modeling it as a raw diagnostic log, keyed on its own composite identifier, is consistent with that classification.

Key Information Stored

The documented physical schema under ETRM 12.2.2 lists twelve columns on the EC owner. The most important are:

• TEXT — the error message payload, the substantive content of the row.
• RUN_ID — identifies the gateway processing run to which the error belongs.
• LINE_ID — identifies the individual line or record within the run that raised the error.
• REQUEST_ID — the concurrent request identifier, permitting correlation to the concurrent manager submission that produced the message.
• PROGRAM_APPLICATION_ID and PROGRAM_ID — the application and concurrent program that generated the error, disambiguating errors raised by different gateway programs.
• PROGRAM_UPDATE_DATE — the date the originating program last updated its context.
• CREATION_DATE, CREATED_BY — standard WHO audit columns recording row creation.
• LAST_UPDATE_DATE, LAST_UPDATED_BY, LAST_UPDATE_LOGIN — standard WHO audit columns recording the most recent modification.

The primary key is the composite ECE_ERROR_PK (RUN_ID, LINE_ID). RUN_ID and LINE_ID together therefore constitute the surrogate identifier of record; because both columns are drawn from gateway processing semantics rather than from a single generated sequence, they equally serve as the natural business-key pair. No separate unique index beyond this constraint is documented.

Common Use Cases and Queries

The dominant use case is post-mortem diagnosis of a failed or partially failed e-Commerce Gateway run. A typical pattern retrieves all messages for a single run:

SELECT run_id, line_id, text
FROM   ec.ece_error
WHERE  run_id = :p_run_id
ORDER BY line_id;

Because REQUEST_ID is retained, errors can also be located from the concurrent request side, which is useful when the gateway program is submitted through the standard request submission flow and the run identifier is not immediately known. Reporting use cases are limited: the table is diagnostic in nature and is not a source for business reporting. Administrators may nonetheless aggregate counts by PROGRAM_ID to identify which gateway programs fail most frequently, and periodic purging of aged rows is a common housekeeping task, since the table grows with processing volume.

Related Objects

Given its standalone Data Vault classification, ECE_ERROR has no documented foreign-key relationships to other EC tables. The most meaningful associations are through its identifying and contextual columns rather than enforced constraints:

• FND_CONCURRENT_REQUESTS — joined via REQUEST_ID to tie an error message to its concurrent request.
• FND_CONCURRENT_PROGRAMS — joined via PROGRAM_APPLICATION_ID and PROGRAM_ID to resolve the generating program.
• FND_APPLICATION — resolves PROGRAM_APPLICATION_ID to an application name.
• Gateway interface and transaction tables within the EC schema — correlated by RUN_ID, since the same run identifier is carried across the interface tables populated and validated during processing.
• FND_USER — resolves CREATED_BY and LAST_UPDATED_BY to the acting user.

Because these joins are conventional rather than declarative, consumers should validate cardinality and nullability before relying on them in production reporting.