Why the Gap Exists and Why It Matters
ERP and WMS systems are designed around order lifecycle management: creating orders, releasing them to fulfillment, tracking shipment confirmation, and closing financials. The polling intervals that drive these systems — typically 15–60 seconds for internal state updates, often 5–15 minutes for inter-system syncs — were sized for the cadence of order management workflows, not for real-time sortation monitoring.
WES systems operate on an entirely different cadence. A sort event — parcel inducted, barcode scanned, sort assignment made, divert activated, chute assignment confirmed — happens in under 2 seconds from induction to divert. At 15,000 PPH, a WES is generating roughly 250 sort events per minute. Those events are time-stamped to the millisecond in WES logs. A WMS polling the sort completion status every 30 seconds is aggregating across 125 sort events per poll — it gets a batch summary, not a real-time stream.
The 30-second gap referenced in the title is a conservative estimate. In many production deployments, the actual lag between a sort event completing at the WES level and that event being visible in WMS or ERP reporting is 2–5 minutes, depending on how the integration was architected and what polling intervals were configured. For a sort floor running against tight carrier windows, 2–5 minutes of data lag is operationally significant — a developing chute problem or induction shortfall is invisible to WMS-side reporting until it's already past the point of easy correction.
Polling vs. Event-Driven Integration Architecture
There are two fundamentally different ways to move sortation data from WES to WMS. Most existing integrations use polling; event-driven architecture is the more appropriate approach for real-time sortation monitoring.
Polling architecture. The WMS (or an integration middleware layer) queries the WES for updated sort data at a fixed interval. The WES returns whatever sort events have accumulated since the last query. This is easy to implement and is the default integration pattern for most WMS vendor connectors because it doesn't require real-time coordination between the two systems. The latency is inherent to the polling interval — and that interval is rarely configured as aggressively as the sort floor needs because frequent polling at 1–5 second intervals creates load on both systems.
Event-driven architecture. The WES publishes sort events to a message queue or event stream as they happen. The WMS (or analytics layer) subscribes to that stream and processes events in near-real-time. Protocols designed for this pattern in industrial environments include OPC UA (the IEC 62541 standard for industrial device interoperability, used by Honeywell Momentum WES, Dematic iQ, and many Siemens TIA / Rockwell Studio 5000 / Beckhoff TwinCAT PLC environments) and MQTT (the lightweight publish-subscribe protocol common in IoT and high-throughput telemetry applications).
An OPC UA subscription on a WES sort event node can deliver sort event data to a subscribing analytics client with sub-second latency. An MQTT broker publishing sort events from a Dematic iQ WES can handle 10,000+ events per minute without queue buildup. Both approaches eliminate the 30-second lag inherent in polling — they replace it with near-real-time event delivery that matches the actual cadence of sortation operations.
SAP EWM and Manhattan Active WMS Integration Patterns
SAP EWM and Manhattan Active WMS are the two most common WMS platforms in mid-size to large FC environments. Their integration patterns with sortation control systems have well-established conventions — and well-understood limitations.
SAP EWM. SAP EWM's native sortation integration uses RFC (Remote Function Calls) for order-level data exchange: order release to the sort system, sort confirmation back to EWM. The RFC integration is reliable for order lifecycle management but is fundamentally a batch-style exchange — each RFC call moves an order-level record, not a continuous sort event stream. Building real-time sortation monitoring on top of SAP EWM typically requires a side-channel integration: an analytics connector that reads WES telemetry via OPC UA or MQTT independently of the SAP RFC exchange, then correlates WES sort events with SAP order records using shared tracking IDs. The SAP integration handles order state; the side-channel handles sort floor telemetry.
Manhattan Active WMS. Manhattan Active's REST API provides a more flexible integration surface than SAP RFC for real-time event exchange. The Manhattan event streaming capability (available in Manhattan Active versions supporting event-driven order management) can push shipment and sort status events to subscribing systems with sub-minute latency. For sortation analytics purposes, the more useful integration point is often the inbound: Manhattan Active's wave release and order assignment logic needs to inform the WES of sort assignments in real time, and the WES sort completion events need to confirm back to Manhattan in near-real-time. Configuring this as a bidirectional event stream (rather than polling from the sort floor analytics layer) reduces the data gap significantly without requiring architectural changes to the Manhattan deployment.
Data Latency Causes in ERP-to-WES Pipelines
Understanding where latency accumulates in an ERP-to-WES data pipeline is necessary for deciding where to intervene. Latency has four common sources:
- Integration middleware polling interval. If an ETL tool or integration platform (MuleSoft, Dell Boomi, or custom middleware) sits between the WES and the WMS, its polling interval adds to the base WES data lag. An integration middleware configured for 5-minute polling on sort event data effectively limits real-time visibility to 5-minute granularity regardless of how fast the WES generates events.
- WES event log structure. Some WES platforms log sort events to a relational database table rather than a real-time event bus. Reading from that table requires polling rather than subscription, and the table may be indexed for WES operational use rather than optimized for high-frequency external reads. This is a WES configuration issue that varies significantly between platforms and installation versions.
- Network segmentation between OT and IT zones. Sort floor equipment lives in the OT network zone. WMS and ERP systems live in the IT zone. Data crossing the OT/IT boundary often goes through a firewall or DMZ with latency-adding inspection rules. The actual data transfer from WES to WMS may add 200–800ms of network latency per event crossing that boundary — negligible for individual events but significant when combined with polling-based aggregation over high event volumes.
- WMS processing queue depth. During high-volume sort waves, the WMS may be processing a large queue of inbound sort confirmations from the WES. If the WMS processes that queue sequentially, events at the end of the queue experience a processing lag relative to their actual sort time — even if the WES published them promptly.
Building Real-Time Sortation Dashboards From Existing Data
The gap between what WMS/ERP reporting shows and what the sort floor is actually doing isn't primarily a data availability problem — it's a data plumbing problem. The sort event data exists in WES logs. The order assignment data exists in WMS records. The problem is getting those two data streams joined and visualized at sortation-relevant latency levels without requiring a major infrastructure replacement.
A sortation analytics layer that subscribes to WES sort events via OPC UA or MQTT, joins them against WMS order records via REST API, and computes per-lane PPH, chute fill rates, and wave completion percentages at a 90-second refresh interval can close most of the practical data gap without replacing either the WES or the WMS. The integration reads from existing systems rather than replacing them. The operational layer — the dashboard, the alerts, the carrier window countdowns — sits on top of the two source systems as a read-only analytics consumer.
This is the architecture choice that makes a 6-week integration timeline realistic for a mid-size FC. A 6-week timeline is not plausible for replacing a WES or rebuilding a WMS integration. It is plausible for connecting an analytics layer to existing WES telemetry streams and WMS APIs, configuring the join logic against the facility's specific sort data schema, and deploying a dashboard to floor operations. The data gap closes because the plumbing is corrected — not because the underlying systems are replaced.