Transport Overview

Transport Overview

The Transport Overview screen (/transport) is the live operations view of all device tasks managed by the flow-orchestrator — every conveyor/ASRS/AMR/AutoStore movement in one place, with all UUIDs resolved to human-readable codes.

Backed by GET /api/flow/device-tasks (flow-orchestrator, port 8085). RBAC: DEVICE_VIEW required.

Scope filter

The screen opens on "Open + finished today" — the operator's working set: everything still running plus anything that completed today. Switch from the Show dropdown:

Scope	Rows shown
Open + finished today (default)	Active tasks (REQUESTED / DISPATCHED) + anything that finished today
Open (active) only	Active tasks only
Completed	COMPLETED tasks
Failed	FAILED tasks
All recent	The full 500-task backend window

Scope is applied client-side against a single 500-task newest-first backend window. Changing the scope does not trigger a new backend request. The equipment-family filter and equipment picker apply server-side (they do trigger a reload).

Click-to-trace dialog

Click any row to open the detail + trace dialog for that transport.

Code-resolved fields

Field	Resolved from
HU	Payload huCode
Origin	useCatalog (location code) or listWorkplaces (GTP station code)
Destination	Same
Next hop	Same; falls back to destination for ASRS/AMR/AutoStore direct-delivery tasks
Equipment	Equipment catalog label
Actor	actor field on the task

Per-HU transport trace

When a task is linked to an induction queue entry — set by flow-orchestrator from the moment a tote is requested for a workplace — the dialog fetches the full material-flow timeline for that HU via GET /api/flow/hu-trace?huId= and renders each function point as a timestamped row:

Field	Description
point	Function point in the HU's journey (e.g. request, retrieve, induct, arrive, queue, done, conveyor, storage, slot)
event	Event that triggered the transition (e.g. REQUESTED, RETRIEVED, INDUCTED, SCANNED, ARRIVED, QUEUED, DONE, RETURNING, RETURN_ARRIVED, STORED)
decision	Human-readable note on the routing or lifecycle decision made at this point
fromPoint / toPoint	Origin and destination location or function point
ts	Timestamp of the trace row

This append-only hu_transport_trace table (V11 migration, ADR-0007 Phase 3c-1) records a row at every function point an HU passes — retrieved from slot, inducted, conveyor decision points, arrival, queued at the station, presented, done, returning to storage (CONVEY), arrived back at storage, stored back in the source slot — giving a complete material-flow audit trail per HU rather than the coarse per-device-task list. Tasks without an induction entry (e.g. standalone STORE tasks) fall back to showing only the clicked task.

Conveyor decision-point rows (Phase 3c-2): when the emulator recirculates a tote (OPENWCS_EMULATOR_RECIRC_EVERY=N), the CONVEY result payload includes an ordered decisions list (sorter RECIRCULATED/DIVERTED events). Flow writes one trace row per decision before the ARRIVED row, so the timeline explains why a tote arrived later than or out of order with others dispatched before it. The point column is sorter and the event column is RECIRCULATED or DIVERTED; the decision column carries a human-readable explanation (e.g. "missed divert (destination busy) — looping"). In normal operation (no recirculation) only the final DIVERTED row is written.

Live conveyor scan rows (ADR-0008 Phase 3d-1): when a CONVEY is dispatched as a live-walk leg (payload contains entryNode), RoutingService.decide() appends a SCANNED row to hu_transport_trace for each scan that belongs to the transport — one row per conveyor node the HU passes through, written in real time as the emulator/adapter walks the graph. Each row records: point = the scanned node code, event = SCANNED, decision = the routing outcome (e.g. "routed to MID via straight", "held: loop full", "No route plan: following divert default to SHIP", "destination reached"), toPoint = the next hop. This gives a node-by-node timeline of the HU's physical journey before the final ARRIVED row. Stray barcodes (no active induction entry) are answered by flow's routing engine but produce no trace row.

The raw payload and result JSON (if non-empty) are pretty-printed at the bottom of the dialog — useful for diagnosing FAILED tasks.

Close with ✕, the Close button, or Escape.

Dispatching a physical move (POST /api/flow/moves)

Other services (today: Slotting and Replenishment) turn a plan into a real physical relocation by posting a single request to flow:

POST /api/flow/moves
{ "warehouseId", "huId", "huCode", "fromLocationId", "toLocationId", "family", "reason" }

Flow dispatches a RELOCATE device task (AutoStore family → BIN_RELOCATE) to physically move the handling unit from fromLocationId to toLocationId. On completion it:

• books the HU's new location in inventory (PUT /api/inventory/handling-units/{id}/location), and
• fires the existing HandlingUnitMoved txlog audit (below).

Stock follows the HU, so no StockMoved is emitted for HU-bound moves — the stock rows ride the HU and are already located by the registry booking, which avoids a double-apply. (The dormant StockMoved / PutawayCompleted inventory projection is reserved for loose, non-HU stock and is now proven on that path — see Inbound and Inventory.)

The dispatched move is a single RELOCATE leg today; a full RETRIEVE → CONVEY → STORE chain is a documented follow-up (see Roadmap and Status).

Physical-move audit (HandlingUnitMoved)

The hu_transport_trace above is flow-local — flow's own working record of a journey. The durable, replayable system-of-record for physical moves lives in the shared transaction log (txlog). Whenever a device task that physically relocates a handling unit reaches a terminal state, flow-orchestrator appends a HandlingUnitMoved event:

Aspect	Value
Commands audited	STORE, RETRIEVE, RELOCATE and the AutoStore BIN_STORE / BIN_RETRIEVE / BIN_RELOCATE variants (CONVEY transport is not audited — it is not a stock-location change and is already on the trace)
Trigger	Once per task at its terminal transition (COMPLETED or FAILED), emitted from DeviceTaskService — the single chokepoint every device task passes through
Stream	hu-<huId>
Payload	warehouseId, huId, huCode, command, family, equipmentId, fromLocationId, toLocationId, status, detail, deviceTaskId (from/to derived from the command's own payload: STORE → destination, RETRIEVE → source, RELOCATE → both)
Delivery	Best-effort (HttpTxLogClient, 2 s timeouts): a txlog hiccup is logged at WARN and never fails the device-task callback

It is audit-only: HandlingUnitMoved is deliberately not consumed by the inventory stock projection (the HU's location stays maintained by the registry booking, PUT /api/inventory/handling-units/{id}/location), so there is no double-apply. This is the audit foundation that the now-built slotting move-dispatch (POST /api/flow/moves, above) rides on. Inventory's StockMoved / PutawayCompleted projection stays reserved for loose (non-HU) stock, where there is no HU to follow; it is now proven on that path. See Roadmap-and-Status.

Table columns

Column	Notes
Status	REQUESTED → DISPATCHED → COMPLETED / FAILED
Family	Equipment type: CONVEYOR · ASRS · AMR · AUTOSTORE
Command	e.g. CONVEY · STORE · RETRIEVE · TRANSPORT
HU	Resolved handling-unit code
Origin / Destination	Resolved location code or GTP station code
Next hop	Resolved; falls back to destination for direct deliveries
Equipment	Resolved label from the equipment catalog
Correlation	Short id; hover for the full id and explanation
Created	Timestamp

The search box matches id, status, family, command, HU code, resolved origin/destination, equipment label, and correlation id simultaneously. Auto-refresh runs every 4 s; toggle with the Auto-refresh switch in the header.

Related

Equipment Integration · Goods-to-Person Stations · Services