Explore the flow
One order. Four stages.
Select a stage to follow the exchange between systems and the movement of a load.
1 / 4 · WMS
Order
The WMS specifies what needs to happen: which load to move and its requested destination.
Illustrative logical flow. Interfaces and responsibilities are defined for each project.
Separate policy from transport
A WCS can separate task intake, flow decisions, persistence, equipment adaptation and supervision. These are logical responsibilities, not a requirement for five services. More processes improve isolation but introduce messaging and distributed failures. Choose deployment boundaries for the workload and operational team.
Adapters translate tasks and resources into equipment-specific contracts. Keeping tag addresses and codes outside the flow core reduces change impact, but does not remove physical or semantic differences between machines.
Persist important decisions
Record a recoverable task before considering it accepted. Updating state and publishing an event independently creates a loss window. One design option records state and publication intent in the same transaction, then publishes asynchronously with duplicate-tolerant consumers.
This requires queue retention and publisher recovery. Delivery guarantees do not resolve physical uncertainty: a command may execute while its acknowledgement is lost. The equipment contract must support identification or reconciliation.
Observability and command authority
Relate logs to task, load, resource and message. Clock synchronization helps investigation, but causal order should also use explicit sequences: timestamps can disagree. Monitor queue age and communication quality, not only CPU.
Only an authorized instance may command a resource. Leadership transfer must invalidate the previous authority at the actual command boundary. A healthy dashboard does not prove correct failover.
Worked failure window
A task is persisted and the process fails before sending. Recovery finds the pending intent. If failure happened after sending, recovery checks equipment state before repeating. Without enough protocol evidence, those cases can look identical in storage.
Inject failures at each boundary. Record expected sequence, observed physical outcome and final task state. This evidence is more useful than an unsupported claim that the architecture is resilient.
Authority matrix: decision ownership and evidence
Start integration with an authority matrix. For each decision, name the component allowed to change it, the required evidence and behavior when information is unavailable. This is a reference division: a separate MFC may own WCS flow functions, provided there are no competing owners.
| Decision | Reference authority | Evidence and boundary |
|---|---|---|
| Business destination and priority | WMS / agreed orchestration | Valid demand and constraints; no permission to override an interlock. |
| Admission and capacity reservation | WCS/MFC flow coordination | Occupancy plus approaching reservations; one slot cannot be promised twice. |
| Local movement | Equipment controller | Handshake, mode and interlocks; safety remains in the machine architecture. |
| Logistics completion | WCS reports; WMS records the business effect | Load identity and delivery at the agreed point, not merely a sent command. |
| Discrepancy correction | Authorized operational procedure | Operator, reason and evidence; retain the original task and events. |
State machine and execution invariants
States represent knowledge, not just the last received message. In this example ACCEPTED requires durable recording, EXECUTING requires equipment evidence and COMPLETED requires agreed delivery. RECONCILING preserves uncertainty when the outcome cannot be established.
Test these invariants: a load identity cannot have incompatible concurrent executions; two tasks cannot consume one reservation; an old event cannot regress a completed state; a retry preserves operation identity. A new business intention requires a new task or authorized version under the contract.
| State | Entry condition | Next decision |
|---|---|---|
| ACCEPTED | Validated and persisted task | Wait for capacity or reject an incompatible change. |
| RESERVED | Resource and destination reserved | Publish command with stable identity. |
| EXECUTING | Equipment acknowledges execution | Await outcome; cancellation may require compensation. |
| COMPLETED | Delivery evidenced and recorded | Publish pending confirmation; do not repeat movement. |
| RECONCILING | Timeout or conflicting observations | Query state and location; never assume completion. |
Nominal sequence and persistence boundaries
This illustrative logical flow is not a product endpoint or protocol specification. Arrows represent causal relationships, not network topology. Task state and the intent to publish the next event can be recorded in one local transaction. Transmission follows, with recovery of pending publication intents.
WMS → WCS
Send T42 / C18 / destination S3 with task version.
WCS → persistence
Validate and record before returning business acceptance.
WCS → capacity coordination
Reserve S3 using occupancy and approaching loads.
WCS → adapter → equipment
Send a stable command identity and record acknowledged outcome.
Equipment → WCS
Report progress and delivery evidence for C18.
WCS → persistence → WMS
Record completion and notification intent; resend notification if needed.
A lost acknowledgement creates communication uncertainty, not proof of failed movement. Recovering a message and repeating a physical action are different operations.
Four failure windows to exercise
Persistence and messaging do not create a single transaction with the physical world. Test boundaries where software and equipment may disagree. Resume commands only when authority and state are coherent.
| Injected failure | Expected behavior | Acceptance evidence |
|---|---|---|
| After persistence, before send | Recover pending intent without creating another task | One T42, one logical command and preserved history. |
| After execution, before acknowledgement | Query sequence and position; reconcile ambiguity | No second movement caused by timeout. |
| After completion, before WMS notification | Replay the event with the same identity | One business effect even if the event arrives twice. |
| Leader communication loss | Invalidate old authority before resuming | The previous instance cannot command the resource. |
Size queues without moving the bottleneck
A queue absorbs temporary rate differences but needs retention limits and admission control. In an illustrative budget, arrivals are 120 tasks/min while execution sustains 100 tasks/min for ten minutes: backlog grows by 200 tasks. If arrivals then fall to 80/min, net draining capacity is 20/min, requiring ten more minutes under these assumptions.
This calculation ignores mix variation, blocking and ineligible tasks. Use it as an initial consistency check, not a throughput guarantee. Measure oldest-task age, waiting-time percentiles, physical occupancy and reservations. More software consumers do not automatically increase mechanical capacity.
Acceptance should specify workload profile, duration, expected outages and maximum backlog recovery time. Record which functions can continue when WMS, database or an adapter is unavailable. Availability then becomes a verifiable flow property.
Reference: Microsoft — Queue-Based Load Leveling.
Project verification criteria
- Map transaction boundaries and failure windows.
- Verify event replay without duplicate movement.
- Prove single command authority for each resource.
Examples describe engineering decisions and test scenarios. Implemented interfaces, limits and features are defined by each project’s scope.