Search Results wms_device_request

Overview

The APPS.WMS_DEVICE_INTEGRATION_PUB package body provides the public integration layer between Oracle Warehouse Management (WMS) and third-party material handling and automated data collection devices. It exists to abstract the mechanics of dispatching requests to physical device hardware—such as label printers, scanners, conveyor controllers, and pick-to-light systems—away from the core WMS transaction engine. Rather than embedding device-specific protocol logic within WMS, Oracle exposes this package as an extension point: third-party device vendors are expected to wrap or extend the published procedures to implement the actual communication logic required for their equipment.

Requests destined for devices are staged in a temporary table, WMS_DEVICE_REQUEST, and the primary driver of activity in this package is the processing and dispatching of that staged data. The package therefore functions as a device communication façade, decoupling WMS transaction processing from the asynchronous, often failure-prone nature of hardware integration, and providing a controlled mechanism for status feedback and resubmission.

Key Procedures and Functions

The package exposes three documented procedures:

• SYNC_DEVICE_REQUEST — Initiates a request to a WMS device. This is the principal entry point for synchronously dispatching a staged device request identified by a request ID and a target device ID. It accepts a resubmit flag that distinguishes a request invoked in conjunction with transaction processing from one invoked specifically to resubmit a previously failed or pending request to the device. It returns a status code (Success or Error), an associated status message, and a separate device-level status string.
• UPDATE_REQUEST — Updates the status of a device request from a transaction cycle separate from the one in which the request was originally initiated. This supports asynchronous operation, allowing a device response or downstream process running in a different session or transaction context to record the outcome of the request. Parameters include the request ID, the device ID (used where request data was directed to multiple devices), and the resulting status code and message.
• SYNC_DEVICE — Provides device-level synchronization functionality, complementing the request-level procedures above by managing interaction with the device itself rather than an individual request.

In the shipped Oracle implementation, SYNC_DEVICE_REQUEST is delivered as a stub that returns success status codes, consistent with its documented role as a vendor extension point rather than a fully implemented integration.

Tables Accessed

The package operates against WMS_DEVICE_REQUEST, the temporary staging table that serves as the primary source of input to the integration logic, holding the requests awaiting dispatch to devices. It also references WMS_DEVICE_REQUESTS_HIST (via an APPS synonym), the historical table used to persist the lifecycle and outcome of device requests, providing the audit trail that UPDATE_REQUEST maintains when recording asynchronous status changes.

Usage Notes

This package is typically invoked from WMS transaction processing flows—such as picking, put-away, and task execution—whenever a transaction requires interaction with a physical device, and from resubmission logic that retries failed device requests. Because the procedures are published (PUB classification) under the APPS schema, they serve as the supported interface for vendor extensions and custom code implementing device-specific communication.

Implementers extending this package must preserve the documented procedure signatures and the success/error status contract, since the package is referenced by four other packages within the WMS application. Direct modification of the seeded stub is discouraged; vendors are expected to provide their own implementing logic in accordance with Oracle's extension conventions. The asynchronous design of UPDATE_REQUEST means that request outcomes may be recorded in a transaction context independent of the initiating WMS transaction, so callers should not assume immediate synchronous completion of device interactions.