WCS integration with Manhattan: tasks, events and reconciliation

Before the API: agree functional ownership

Record the Manhattan product, version, extensions, authentication, traffic limits and available environments. For each flow, identify the task-creation trigger, destination owner and physical completion point. WMS, WES, WCS and local control do not necessarily map to separate servers.

The interface document should cover nominal execution, cancellation, priority changes, partial outcomes and recovery. Assign owners at both ends and define contract-change validation. A connected interface can still carry the wrong interpretation of a load identifier or destination.

Illustrative contract: a message is not a task

The following JSON is a teaching example. It is neither an official Manhattan API nor a published ABNET WCS message format. Map its concepts to the interface actually available in the project.

messageId identifies a logical message delivery, taskId the physical operation and taskVersion an authorized update. correlationId connects the chain of commands and events. Deduplication keys need appropriate scope, such as producer and facility, to avoid collisions between senders.

{
  "schemaVersion": "example-1",
  "messageId": "MSG-0091",
  "taskId": "T42",
  "taskVersion": 1,
  "correlationId": "FLOW-018",
  "loadId": "C18",
  "source": "IN-01",
  "destination": "S3",
  "intent": "MOVE"
}

Three different acknowledgements in one flow

Transport receipt, business acceptance and physical completion must be distinguishable in logs and interfaces. Transport acknowledgement may precede destination validation. An accepted task may wait for capacity without any communication fault.

1. 1

   Manhattan → WCS

   Request T42 with load, destination and version.

2. 2

   Channel → producer

   Acknowledge protocol receipt without implying execution.

3. 3

   WCS → Manhattan

   Accept after validation and recording, or reject with a reason.

4. 4

   WCS ↔ equipment

   Reserve, send command and track the load.

5. 5

   WCS → Manhattan

   Publish evidenced delivery with a stable event identity.

6. 6

   Manhattan → integration

   Confirm processing or support outcome reconciliation.

If the final response is lost, replaying the event must not repeat the inventory transaction. Deduplication retention must cover the agreed replay window.

Ordering, timeouts and operational exceptions

Order dependent operations, such as updates to the same task. Avoid a global queue where independent tasks can run concurrently. A future version arriving before its predecessor needs an agreed wait, state query or diagnosable rejection. Timestamps alone do not establish causal order.

For transient failures, bound attempts and use progressive spacing with variation to avoid synchronized retry storms. Content rejection needs correction, not endless retries. Exception queues need ownership, context and audited replay. Correcting payload under the same identity may be treated as a duplicate; define how corrected versions obtain valid identities.

Minimum integration acceptance matrix

Tests must prove business and execution integrity, not just connectivity. Use identifiable tasks, known initial state and correlated records from both systems. Workload and recovery limits should come from agreed operational requirements.

After each scenario, reconcile accepted tasks, physically delivered loads and WMS-recorded outcomes. Every difference needs an explained rejection, cancellation or open exception. A dashboard without alarms does not replace reconciliation.