Search Results retry_status

Overview

APPS.ECX_OUT_PROCESS_VL is a reporting view in the Oracle E-Business Suite E-Commerce Gateway (ECX) module that consolidates outbound transaction processing status across the entire message lifecycle. It joins the primary outbound log with downstream external delivery logs and retry records, exposing a single row per outbound document exchange along with human-readable error text. In EBS 12.1.1 and 12.2.2 this view serves as the principal diagnostic surface for outbound EDI and XML gateway traffic, allowing support and integration teams to trace a document from initial generation through external transport and any retry attempts without manually reconciling the ECX_OUTBOUND_LOGS, ECX_EXTERNAL_LOGS, and ECX_EXTERNAL_RETRY tables.

The view is defined as a UNION of two branches. The first returns rows where the outbound message has an associated retry record and external log; the second returns rows where those downstream records are absent, substituting NULLs through outer joins. This construction guarantees that an outbound document is never hidden simply because it never reached the external delivery stage.

Underlying Base Objects

Per the documented ETRM metadata for 12.2.2, the view is owned by APPS and is defined over the following base objects:

• ECX_OUTBOUND_LOGS — the driver table, supplying trigger, document, transaction, party, status, and timestamp information.
• ECX_EXTERNAL_LOGS — external delivery outcomes, joined on OUT_MSGID.
• ECX_EXTERNAL_RETRY — retry attempts, joined on MSGID and related to external logs via RETRY_MSGID.
• ECX_DOCLOGS — protocol address and protocol type, joined on MSGID.
• ECX_ERROR_MSGS — error message source tables (three aliases, ERR1/ERR2/ERR3), joined by ERROR_ID with the outer-join (+) operator so missing error definitions do not suppress the row.
• ECX_TP_HEADERS — documented as referenced, supporting trading partner context.
• ECX_DEBUG — the package supplying the GETMESSAGE function; it is not a table but is listed among referenced objects.

The view thus acts as a denormalized layer over the ECX logging subsystem rather than a stored table of its own.

Key Columns

The most consequential columns are the three resolved error descriptions produced by ECX_DEBUG.GETMESSAGE(message, message_parameters). Each call takes the error message text and the stored MESSAGE_PARAMETERS bind values and returns a substituted, readable string — one for the outbound log, one for the external log, and one for the retry record. The remainder of the projection includes TRIGGER_ID, DOCUMENT_NUMBER, TRANSACTION_TYPE, TRANSACTION_SUBTYPE, PARTY_TYPE, PARTY_ID, and PARTY_SITE_ID for document identification; STATUS appearing three times (outbound, external, retry); TIME_STAMP appearing three times for the corresponding stages; LOGFILE; OUT_MSGID; RETRY_MSGID; and PROTOCOL_TYPE with PROTOCOL_ADDRESS from ECX_DOCLOGS. In the second UNION branch, retry-specific columns are emitted as NULL and RETRY_MSGID is cast as HEXTORAW(NULL).

Common Use Cases and Queries

Typical usage centers on identifying failed or stalled outbound documents and reading the decoded error text. Because MESSAGE_PARAMETERS is passed directly into GETMESSAGE, users searching for that term are generally looking to obtain rendered messages rather than raw parameter strings.

• Monitoring failures: SELECT document_number, status, transaction_type FROM apps.ecx_out_process_vl WHERE status = 'ERROR';
• Reading decoded errors: SELECT document_number, ecx_debug.getmessage(err1.message, err1.message_parameters) FROM apps.ecx_out_process_vl; — note that GETMESSAGE is already applied within the view, so callers select the resulting column directly.
• Retry analysis: filtering on RETRY_MSGID IS NOT NULL isolates messages that required at least one retry.
• Trading partner tracing: joining PARTY_ID and PARTY_SITE_ID back to ECX_TP_HEADERS to reconcile partner-level delivery statistics.

Because the second UNION branch supplies NULL retry columns, queries must account for absent retry data rather than assuming a one-to-one relationship between outbound and retry rows.