Search Results queue_content

Overview

OKC_QUE_ERROR_CNT_V is a reporting and diagnostic view owned by the APPS schema in Oracle E-Business Suite, registered under the OKC – Contracts Core product family. Its documented status is VALID, and it is exposed as a read-only query surface over the Advanced Queue error repository used by Contracts Core. The view presents the set of failed or problematic Advanced Queuing (AQ) messages together with their queue name, message identifier, retry count, and the serialized queue payload. Within the EBS integration landscape, this view serves as the primary means by which DBAs, support analysts, and integration developers inspect the state of the Contracts Core outbound/inbound message queues without querying the underlying error table directly. The object is consistent across the 12.1.1 and 12.2.2 release lines; the ETRM 12.2.2 metadata records APPS as owner and OKC_AQERRORS as the single referenced base object.

Underlying Base Objects

The ETRM metadata documents exactly one referenced base object: the synonym OKC_AQERRORS. The view text confirms this dependency directly, selecting every column it exposes from OKC_AQERRORS:

• OKC_AQERRORS — the synonym resolving to the Contracts Core AQ error table. It retains failed or unprocessed queue messages for the Contracts (OKC) module.

Because the definition is a straightforward projection with column aliasing and no joins, filters, or aggregation, the view imposes no additional performance cost beyond the scan of OKC_AQERRORS. Its value is presentational: it renames cryptic storage columns into business-friendly labels. Referential transparency to the synonym means any purging or archival strategy applied to OKC_AQERRORS is immediately reflected in the view.

Key Columns

The documented column list and their underlying expressions are:

• ID — aliases the ID column of OKC_AQERRORS; uniquely identifies the error record.
• SOURCE_NAME — passes through SOURCE_NAME, indicating the originating process or component that enqueued or dequeued the message.
• BEGIN_DATE — aliases the DATETIME column; the timestamp associated with the error occurrence.
• QUEUE_NAME — aliases Q_NAME; the Advanced Queue in which the failure occurred.
• MESSAGE_ID — aliases MSGID; the AQ message identifier, usable for correlation against AQ$ dictionary views.
• RETRY_COUNT — the number of delivery or processing retries already attempted for the message.
• QUEUE_CONTENT — aliases QUEUE_CONTENTS; this is the payload column and the direct match for the search term "queue_content". It holds the serialized message body, typically an XML or delimited payload, and is the column analysts inspect to determine why a message failed.

Common Use Cases and Queries

The most frequent scenario is triage of stuck Contracts Core messages. The view answers "what is failing on the queue, and what does the payload look like?" A representative query lists the newest failures:

• SELECT id, source_name, begin_date, queue_name, message_id, retry_count FROM okc_que_error_cnt_v ORDER BY begin_date DESC;
• SELECT queue_name, retry_count, queue_content FROM okc_que_error_cnt_v WHERE queue_name = :queue AND retry_count > 0;
• SELECT message_id, begin_date, queue_content FROM okc_que_error_cnt_v WHERE source_name = :source;

Typical consumers include concurrent-program monitoring, integration error dashboards, and support scripts that extract QUEUE_CONTENT for replay or root-cause analysis. Because the view exposes the raw payload without truncation, results should be limited or filtered before display in reporting tools. For 12.1.1 and 12.2.2 alike, no differences are documented, so the same SQL is portable across both releases.