Search Results processing_logfile




Overview
Explore in AI Chat

Overview

APPS.ECX_IN_PROCESS_VL is a public Oracle E-Business Suite view owned by the APPS schema and registered under the FND Design Data reference ECX.ECX_IN_PROCESS_VL. It is classified as a view whose status is VALID and whose view type is a public view intended to be useful for custom reporting and other data requirements. Functionally, the object presents the status of inbound messages flowing through the ECX (e-Commerce Gateway / XML Gateway) processing infrastructure. In Oracle EBS 12.1.1 and 12.2.2, this view is a reporting facade over the inbound message processing and logging tables that the ECX message-processing engine populates as transactions are received, validated, transformed, and dispatched.

The primary purpose of the view is to expose the processing state of inbound documents — the trigger, the document identifier, transaction classification, trading partner context, current processing status, diagnostic messages, and the timestamp at which processing occurred. This makes it a convenient single source for monitoring inbound interface health without joining multiple ECX control and log tables manually. The view does not store data itself; it is a read-only projection over its base objects, and its definition is maintained as part of the ECX design data shipped with the applications schema.

Underlying Base Objects

Documented dependency information indicates that APPS.ECX_IN_PROCESS_VL is defined over the following base objects:

  • ECX_DEBUG (PACKAGE) — the debug/logging utility used by ECX processing to record diagnostic output.
  • ECX_DOCLOGS (SYNONYM) — document-level logging records produced during inbound processing.
  • ECX_ERROR_MSGS (SYNONYM) — error message definitions referenced for processing status text.
  • ECX_EXT_PROCESSES (SYNONYM) — definitions of external processing steps applied to messages.
  • ECX_INBOUND_LOGS (SYNONYM) — the inbound message log, the principal source of processing status. Because it maps to ECX_INBOUND_LOGS, the view is closely aligned with the inbound message lifecycle.
  • ECX_STANDARDS (SYNONYM) — the EDI/XML standard definitions used to classify transactions.
  • ECX_TP_DETAILS (SYNONYM) — trading partner detail records supplying party and party site context.
  • ECX_TP_HEADERS (SYNONYM) — trading partner header records supplying party type and identifier data.

In the dependency map, APPS.ECX_IN_PROCESS_VL is itself referenced by APPS.ECX_IN_PROCESS_V, indicating that this visible-layer (VL) object feeds a sibling view used for user-facing presentation. The view therefore sits in the middle of an ECX inbound-processing reporting chain, reading from the log, partner, standard, and error objects and supporting higher-level status views.

Key Columns

The view exposes fourteen columns that together describe an inbound processing event:

  • TRIGGER_ID (NUMBER, 15) — the triggering identifier for the processing run.
  • DOCUMENT_ID (VARCHAR2, 256) — the document identifier of the inbound message.
  • TRANSACTION_TYPE (VARCHAR2, 100) — the internal transaction type.
  • TRANSACTION_SUBTYPE (VARCHAR2, 100) — the internal transaction subtype.
  • PARTY_ID (NUMBER) and PARTY_SITE_ID (NUMBER) — the trading partner and partner site identifiers.
  • PARTY_TYPE (VARCHAR2, 30) — the classification of the trading partner.
  • INTERNAL_CONTROL_NUMBER (NUMBER) — the internal message control number.
  • PROCESSING_STATUS (VARCHAR2, 256) — the current state of inbound processing.
  • PROCESSING_MESSAGE (VARCHAR2, 4000) — free-text processing message, typically an error or diagnostic description.
  • PROCESSING_TIMESTAMP (DATE) — the date and time at which processing was recorded. This is the column most directly relevant to the user search term.
  • PROCESSING_LOGFILE (VARCHAR2, 256) — reference to the associated processing logfile.
  • OUT_MSGID (RAW, 16) and MSGID (RAW, 16) — message identifiers used to correlate inbound and outbound messages.

Common Use Cases and Queries

Because the view is documented as suitable for custom reporting, it is commonly queried to monitor inbound interface activity, identify failed or stalled messages, and trace processing timeframes using PROCESSING_TIMESTAMP. A typical query retrieves recent processing activity:

  • SELECT TRIGGER_ID, DOCUMENT_ID, TRANSACTION_TYPE, PROCESSING_STATUS, PROCESSING_TIMESTAMP FROM APPS.ECX_IN_PROCESS_VL ORDER BY PROCESSING_TIMESTAMP DESC;
  • Filtering by status: SELECT DOCUMENT_ID, PROCESSING_MESSAGE, PROCESSING_TIMESTAMP FROM APPS.ECX_IN_PROCESS_VL WHERE PROCESSING_STATUS = :status;
  • Tracing a specific document: SELECT * FROM APPS.ECX_IN_PROCESS_VL WHERE DOCUMENT_ID = :document_id;
  • Auditing by time window: SELECT DOCUMENT_ID, PROCESSING_STATUS, PROCESSING_TIMESTAMP FROM APPS.ECX_IN_PROCESS_VL WHERE PROCESSING_TIMESTAMP >= :from_date AND PROCESSING_TIMESTAMP < :to_date;

These queries allow interface administrators to track inbound message throughput, isolate errors by reading PROCESSING_MESSAGE, and correlate activity with trading partners via PARTY_ID and PARTY_SITE_ID.