Search Results ecx_msg_logs_s

```html

Overview

The package body APPS.ECX_ERRORLOG is the central error-capture and diagnostic-logging facility for the Oracle E-Business Suite e-Commerce Gateway (ECX) module, which handles inbound and outbound EDI transactions and other external data exchanges. Its primary business function is to record, categorize, and persist error conditions, document payloads, message logs, and external-system communication events encountered while the gateway processes a transaction. Because ECX exchanges data with external trading partners asynchronously through a workflow-based engine, failed or partially completed transactions must be persisted with enough context to permit retry, resubmission, or operator diagnosis. ECX_ERRORLOG supplies that persistence layer.

The user search term ecx_error_no_s corresponds to the ECX_ERROR_NO_S sequence referenced by the package. This sequence is used to generate surrogate primary keys for error and message-log records, ensuring that concurrent gateway processes do not collide when writing log rows. The package depends on the same sequence as part of its logging and message-dispatch routines.

Key Procedures and Functions

The ETRM metadata documents thirteen procedures or functions within this package body:

• INBOUND_ENGINE — Coordinates error and log handling for inbound transactions processed by the ECX inbound engine.
• OUTBOUND_ENGINE — Coordinates error and log handling for outbound transactions generated by the ECX outbound engine.
• EXTERNAL_SYSTEM — Handles logging associated with communication to or from an external system, such as a partner's EDI translator or VAN.
• SEND_ERROR — Persists an error condition, including associated error message and error-number identification, for later retrieval.
• SEND_MSG_API — Dispatches or records a message through the message-log API path.
• INBOUND_TRIGGER — Captures errors and log context tied to inbound transaction triggers.
• OUTBOUND_TRIGGER — Captures errors and log context tied to outbound transaction triggers.
• LOG_DOCUMENT — Inserts a document log entry, recording the processed payload or document reference.
• UPDATE_LOG_DOCUMENT — Updates an existing document log entry, typically to set status or completion information.
• GETDOCLOGDETAILS — Returns document log detail for a given log record; used by reporting or inquiry.
• LOG_RESEND — Records a resend event when a transaction is retried or resubmitted.
• OUTBOUND_LOG — Writes an outbound processing log record.
• LOG_RECEIVEMESSAGE — Records an inbound message receipt event.

Parameter lists are intentionally not enumerated here; only the documented purpose of each routine is stated.

Tables Accessed

The package reads and writes the core ECX logging, transaction, and trading-partner tables through APPS synonyms. ECX_ERROR_MSGS and ECX_ERROR_NO_S store error text and generate error-number keys. ECX_DOCLOGS, ECX_MSG_LOGS (and ECX_MSG_LOGS_S), ECX_INBOUND_LOGS, ECX_OUTBOUND_LOGS, and ECX_EXTERNAL_LOGS hold the detailed log rows for each processing phase. ECX_EXTERNAL_RETRY supports retry bookkeeping, while ECX_TRANSACTIONS, ECX_TRIGGER_ID_S, and ECX_INLSTN_S link logs to the originating transaction and trigger identifiers. ECX_TP_HEADERS and ECX_TP_DETAILS provide trading-partner context so that an operator can trace which partner and transaction type were involved. The WF_EVENT_T type and underlying workflow packages (WF_CORE, WF_ENGINE, WF_EVENT, WF_LOG_PKG, WF_AGENT_T) are leveraged so that error logging can raise or interpret Workflow business events that the ECX engine relies on.

Usage Notes

ECX_ERRORLOG is invoked internally by the e-Commerce Gateway concurrent programs, the ECX inbound and outbound workflow processes, and the ECX transactional APIs. The public Oracle EBS forms that display ECX error and document logs (the Gateway transaction monitors and error inquiry forms) also read the records produced by this package. In addition, the package is referenced by fourteen other ECX packages and is not itself referenced outside the logging dependency chain, confirming its role as a shared utility. Custom code that catches ECX processing exceptions should call the appropriate SEND_ERROR or log routine rather than inserting directly into the underlying log tables, so that error numbering via ECX_ERROR_NO_S and any associated Workflow events remain consistent. Typical use is therefore operational rather than user-facing: it supports retry, resend, and diagnostic inquiry for failed or suspended EDI and external-system transactions in both 12.1.1 and 12.2.2.

```