Direct answer: A DWS should send the WMS enough information to identify the measured object, interpret its dimensions and weight, judge whether the result is usable, and process the message safely. At minimum, that means an item or handling-unit ID; length, width, height and weight; explicit units; a capture timestamp and station ID; a result or quality status; and a message or measurement ID for acknowledgement and duplicate control. The exact payload must match the receiving workflow and unit-of-measure level.
Start with the business object
Before naming API fields, decide what the WMS believes is being measured: an each, pack, case, parcel, license plate or pallet. Oracle WMS documents separate unit, pack and case dimensions. A valid number can still corrupt master data when written to the wrong unit-of-measure level.
Recommended data groups
| Group | Typical fields | Purpose |
|---|---|---|
| Identity | item, barcode, parcel/LPN, message ID | Bind readings to the correct object |
| Measurements | length, width, height, weight, optional volume | Carry physical data |
| Units | dimension, weight and volume UOM | Prevent interpretation errors |
| Context | timestamp, station, capture mode | Support traceability |
| Quality | accepted, no-read, incomplete, remeasure | Keep partial data from appearing valid |
| Control | correlation, version, acknowledgement | Support retry and reconciliation |
Units cannot be an afterthought
Oracle's WMS input-interface documentation includes separate weight, volume and dimension UOM codes and describes conversion into units tracked by the WMS. Transmit units explicitly and agree which system converts them.
Master data and shipment observations differ
Item-master enrichment needs a SKU, precise packaging level and governance for replacing an existing value. Outbound verification may be tied to a parcel or license plate and retained as transaction evidence. One endpoint must not blur permanent attributes with a one-time shipment observation.
Define acceptance behavior
An acknowledgement can mean a message was received, an object was found, or values passed business validation. Define which response proves acceptance, which errors are safe to retry, how duplicates behave, whether later observations supersede earlier ones, and where rejected data and physical parcels go.
Illustrative field structure—not a CONLIDA API
| Object | Example fields |
|---|---|
| Control | measurement_id, object_type, object_id |
| Dimensions | length, width, height, dimension_uom |
| Weight | weight_value, weight_uom |
| Context | captured_at, station_id, result |
Actual names, allowed values, authentication and transport must come from the approved project interface.
CONLIDA engineering note: an acknowledgement needs one agreed meaning
Teams often use the word acknowledged for different states: transport received, object found, or business validation passed. The interface workshop should name these states separately so retries and physical exception handling do not depend on an ambiguous success response.
Integration workshop questions
- Which system creates the object ID?
- At what UOM level are values stored?
- Who owns conversion, rounding and orientation?
- Can a measurement update master data automatically?
- What makes a message unique?
- What happens while the WMS is unavailable?
- Who resolves a rejection while the parcel keeps moving?
Connecting a CONLIDA DWS
A relevant CONLIDA DWS configuration can capture physical data, but the project must define the approved interface. CONLIDA and the integrator should agree identity, payload, trigger, acknowledgement and exception ownership before commissioning.
Explore DWS integration options.
