Search Results carousel_directive_queue_id




Overview

The WMS_CAROUSEL_DIRECTIVE_QUEUE table is a Warehouse Management (WMS) transaction staging object in Oracle E-Business Suite 12.1.1 and 12.2.2 that governs communication between the EBS WMS engine and automated carousel storage and retrieval equipment. In warehouse operations environments, carousels rotate to present bins to operators or automated pick/put devices. Each movement instruction sent to the hardware, along with the equipment's acknowledgement, passes through this table. The table therefore acts as an outbound directive queue and an inbound response log, tracking every command issued to a carousel device and the result returned by that device.

The ETRM metadata classifies this object heuristically as standalone from a Data Vault modeling perspective. That classification suggests the table functions as an independent hub carrying its own surrogate key, rather than as a satellite joined through an obvious foreign-key dependency. The surrogate primary key, CAROUSEL_DIRECTIVE_QUEUE_ID, is enforced by the constraint WMS_CAROUSEL_DIRECTIVE_Q_PK, and the same column appears in the unique index WMS_CAROUSEL_DIRECTIVE_Q_U1, making it the sole documented business-key candidate.

Key Information Stored

The table contains 39 documented columns spanning directive control, device addressing, retry management, and descriptive segments.

  • CAROUSEL_DIRECTIVE_QUEUE_ID — the surrogate primary key and the unique business-key candidate; uniquely identifies each queued directive record.
  • DIRECTIVE — the instruction payload issued to the carousel, such as a bin rotate, pick, or put command.
  • STATUS — the current lifecycle state of the directive (for example, queued, sent, acknowledged, or failed).
  • REQUEST_ID, REQUEST, RESPONSE — the outbound request text and the inbound device response, forming the round-trip message pair.
  • SEND_PIPE, RECEIVE_PIPE, PIPE_TIMEOUT — the IPC/named-pipe channels and timeout used to transmit the directive and receive its reply.
  • RESPONSE_TIMEOUT, ATTEMPTS, MAX_ATTEMPTS, LAST_ATTEMPT — retry and escalation controls governing when a directive is reissued or abandoned.
  • DEVICE_ID, DEVICE_TYPE_ID, ADDR — identify the target carousel device, its type, and its network address.
  • TASK_ID, PREV_ID, BUSINESS_EVENT_ID, SEQUENCE_ID — associate the directive with warehouse tasks, predecessor records, business events, and ordering.
  • TASK_COUNT, TASKS_LEFT, TASK_GROUP — support grouping and progress tracking of batched carousel work.
  • SUBNIVENTORY context and SEGMENT1–SEGMENT10 — descriptive flexfield and inventory context columns.
  • LAST_UPDATE_DATE, LAST_UPDATED_BY, CREATION_DATE, CREATED_BY, LAST_UPDATE_LOGIN — the standard EBS audit columns.

Common Use Cases and Queries

Warehouse supervisors and integration teams monitor the queue to confirm that directives were delivered and acknowledged. A typical operational query inspects outstanding or stalled directives:

  • Filtering by STATUS to identify directives that remain unacknowledged beyond a threshold.
  • Comparing ATTEMPTS against MAX_ATTEMPTS to isolate directives that exhausted their retries.
  • Joining on TASK_ID or BUSINESS_EVENT_ID to correlate a carousel message with the originating warehouse task.
  • Aggregating TASK_COUNT and TASKS_LEFT by DEVICE_ID to measure throughput per carousel.
  • Auditing REQUEST and RESPONSE pairs for protocol troubleshooting.

Sample pattern: SELECT CAROUSEL_DIRECTIVE_QUEUE_ID, DEVICE_ID, STATUS, ATTEMPTS FROM WMS.WMS_CAROUSEL_DIRECTIVE_QUEUE WHERE STATUS <> 'COMPLETE' AND ATTEMPTS >= MAX_ATTEMPTS;

Related Objects

Because the FK structure is documented as standalone, explicit joins are best derived from the columns present rather than enforced constraints:

  • WMS_TASKS / WMS_TASK_HEADERS — joined via TASK_ID to link directives to executable warehouse work.
  • WMS_DEVICES / device configuration tables — joined via DEVICE_ID and DEVICE_TYPE_ID.
  • WMS_BUSINESS_EVENTS — correlated through BUSINESS_EVENT_ID.
  • FND_CONCURRENT_REQUESTS — linked via REQUEST_ID for concurrent program lineage.
  • Independent self-referencePREV_ID chains a directive to its predecessor, supporting sequencing.
  • WMS device APIs / carousel device driver programs — consume and update these records as directives are transmitted and acknowledged.