An interface failure isn't the scary part. The scary part is three systems each saying it's not theirs

Our in-house WMS’s external interface spec went from version 1.0 to version 1.27: 28 versions in just over a year, covering 52 interfaces.

Writing the interfaces isn’t the hard part. The most frequent and most draining problem is sync failure: one record gets stuck, two or three systems have to be checked together, the business waits on the side, and it takes a long time to resolve. With multi-system integration, this is the biggest problem.

This post covers three things: who the WMS integrates with and how data moves; why failures are so hard to trace; and why the business always ends up as the safety net.

1. Who the WMS integrates with, and how the interfaces move data

In an automated factory, the WMS deals with at least these kinds of systems:

• SAP, the enterprise planning and finance system: material master sync, business postings of all kinds, reversals
• MES, the system that runs production: production issue orders, receipt confirmation callbacks, line-side returns, stock queries
• QMS, the quality system: moving incoming pallets between the buffer area and the inspection area
• SRM, the supplier collaboration system: replenishment demand for suppliers, feedback on received and returned quantities
• LES and equipment systems: transport orders, AGV status callbacks, empty-pallet calls and returns to storage

All interfaces go through one interface platform. Data moves in two ways:

• Real time: most interfaces, one record at a time, such as outbound requests and transport orders. Business postings are partly real time and partly summarized daily
• Scheduled batch: replenishment demand to SRM is pushed once every morning. Replenishment is a daily plan anyway; it doesn’t need to go one record at a time

The material master uses both: changes are pushed in real time, and every night the day’s changes are pushed again on a schedule, so nothing slips through.

2. The most common WMS interface problem: sync failures that take several teams to trace

Sync failure is the most frequent problem. What makes it hard isn’t the failure itself; it’s that one record often passes through several systems.

Take an AGV transport order: the WMS sends it, and the LES relays it to the equipment system; the AGV’s in-transit and delivered statuses come back to the WMS through the LES again. If any link gets stuck, all the WMS sees is “status didn’t come back.” Finding where it’s stuck takes the WMS, LES and equipment teams digging through logs together. Each side checks its own first, and each says its side is fine.

The interfaces keep changing, too. Of the 28 versions of the spec, several changed fields. One side changes, the other doesn’t keep up, and failures follow.

Besides sync failures, three other problems are common:

• Master data out of sync: upstream creates a new part, the WMS doesn’t have it yet, so documents can’t come in
• Upstream and downstream not going live together: one end has switched to a new system, the other is still on the old one, and the interface no longer matches on both ends
• Upstream reversals: SAP reverses a posting, and on the WMS side someone has to reverse it by hand

3. When an interface fails, why the business always ends up as the safety net

We have interface monitoring logs, and failures are retried automatically. But retries only fix the “network hiccup” kind of failure. If the data itself is wrong, say missing master data or mismatched status, every retry fails.

So in the end, it’s usually the business that first notices the numbers don’t match, goes back to IT, and IT then pulls several systems together to investigate.

To trace faster, we rely on three things:

• One order number all the way through: every document carries an external order number, and the same number can’t be pushed twice. Every system recognizes it, so one number ties the trail together. When a document needs to change or be cancelled, no new document is sent; it carries the same number and states whether this push overwrites or cancels
• For each interface, write down who checks first when it fails: add an owner column to the interface list, so the three sides don’t wait on each other
• A daily list of orders whose retries failed: go find them, don’t wait for the business to report

---

Orders whose interfaces failed: do you publish that list every day, or wait for the business to report?