Search Results queued_on




Overview
Explore in AI Chat

Overview

APPS.XDP_ADAPTER_JOB_QUEUE_V is a reporting and integration view in the Oracle E-Business Suite, owned by the APPS schema. It exposes the most recent entry for each logical job tracking key held in the underlying XDP_ADAPTER_JOB_QUEUE table. The view belongs to the Oracle E-Business Suite Technology Stack's data adapter and integration infrastructure, which supports the queuing, routing, and status tracking of integration messages exchanged between EBS and external or downstream systems.

Its purpose is to collapse the historical queue records into a single current row per job, eliminating the need for callers to write their own correlated subquery logic. By filtering on the maximum value of the QUEUED_ON timestamp for a given combination of ORDER_ID, FE_ID, and WORKITEM_INSTANCE_ID, the view returns only the latest status snapshot for each work item. This makes it well suited to dashboards, interface status pages, and outbound extracts where duplicate or superseded queue entries would otherwise distort results. The view does not itself perform any processing; it is strictly a read-only projection over the queue table.

Underlying Base Objects

The ETRM metadata documents a single referenced base object: the synonym XDP_ADAPTER_JOB_QUEUE. All columns visible in the view are drawn from this source, aliased internally as AJQ1 in the outer query and AJQ2 in the correlated subquery. No joins to other tables, lookup views, or custom objects are present in the definition.

The relationship between view and base object is one-to-(at most) one per tracking key. For every distinct combination of ORDER_ID, FE_ID, and WORKITEM_INSTANCE_ID occurring in the queue, the view returns the row whose QUEUED_ON value equals the maximum for that combination. Records sharing a tracking key but carrying an earlier QUEUED_ON timestamp are excluded. This "latest row wins" pattern is the defining characteristic of the view and explains why it is favored for status determination over the base synonym directly.

Key Columns

  • JOB_ID — Identifier for the adapter job record. Serves as the primary row discriminator in the underlying queue table.
  • FE_ID — Front-end or functional entity identifier. Part of the composite grouping key that distinguishes one tracked work stream from another.
  • ORDER_ID — Identifier of the order or business transaction to which the queued adapter job relates. Also part of the grouping key.
  • WORKITEM_INSTANCE_ID — Identifier for a specific work item instance. Completes the three-part grouping key used in the correlated MAX subquery.
  • FA_INSTANCE_ID — Instance identifier for the associated adapter or processing agent instance handling the job.
  • QUEUED_ON — Timestamp indicating when the record was placed on the adapter job queue. This is the column referenced in the query filter and the one that determines which row is returned as the latest.

Common Use Cases and Queries

The view is typically queried to obtain the current queue state for a business order or to monitor the freshness of queued adapter jobs. Because the correlated subquery already enforces recency, callers can query the view directly without additional aggregation.

Retrieving the latest queue entry for a specific order:

  • SELECT job_id, fe_id, order_id, workitem_instance_id, fa_instance_id, queued_on FROM apps.xdp_adapter_job_queue_v WHERE order_id = :order_id;

Identifying jobs queued within a recent window:

  • SELECT order_id, workitem_instance_id, queued_on FROM apps.xdp_adapter_job_queue_v WHERE queued_on >= SYSDATE - 1 ORDER BY queued_on DESC;

Summarizing current queue depth by front-end entity:

  • SELECT fe_id, COUNT(*) queued_jobs, MAX(queued_on) last_queued FROM apps.xdp_adapter_job_queue_v GROUP BY fe_id;

Because the filter on QUEUED_ON is applied through a correlated subquery, performance depends heavily on an index over the grouping columns and timestamp in the base queue table. When writing diagnostic or monitoring queries, restricting on ORDER_ID, FE_ID, or QUEUED_ON allows the optimizer to drive from the base table and evaluate the subquery efficiently. The view should be treated as read-only, and any reconciliation between multiple queue entries for the same tracking key should rely on comparing QUEUED_ON values rather than on JOB_ID ordering, since JOB_ID sequence does not guarantee chronological insertion.