AGVHub
What Does Connecting SAP to Your AGV System Actually Mean?
How SAP integrates with AGV fleet managers: data flows, integration patterns, cost expectations, and who does what in a typical project.
The Inevitable Question
You have decided to automate your material flow with AGVs. The business case is clear, the vehicle type is chosen, and then someone from IT asks the inevitable question: "How does this connect to SAP?"
It is a fair question, and one that often creates more confusion than it should. The short answer: SAP does not drive your AGVs. It tells them what needs to move. The fleet manager figures out how. Understanding this separation is the key to a smooth integration.
SAP Never Talks to the Vehicles
The most common misconception is that SAP somehow needs to communicate with each individual vehicle. It does not. AGV systems follow a layered architecture:
SAP sits at the top. It knows about production orders, warehouse movements, and material requirements. When a pallet needs to move from storage to a production line, SAP generates that demand.
The fleet manager sits in the middle. It receives transport requests, selects the best vehicle, plans routes, manages traffic, and reports back. Think of it as a taxi dispatcher: it takes the booking and assigns the right cab.
The vehicles execute. They navigate, pick up, transport, and deliver.
In some setups, an additional middleware layer or MES (Manufacturing Execution System) sits between SAP and the fleet manager, translating high-level production orders into concrete transport tasks.
This separation of concerns is important: SAP is the source of truth for the overall process. It decides what needs to move, from where to where, and in which order. The fleet manager is only responsible for what happens during the transport itself: which vehicle takes the job, in which sequence, along which route. Warehouse management stays in SAP, not in the AGV system.
What Data Actually Flows
The interface between SAP and the fleet manager is surprisingly simple. Two directions, well-defined content:
SAP sends down
- Transport orders: pick up at location A, deliver to location B
- Priority and time constraints (e.g., "needed by 14:00")
- Order modifications: cancel, change priority, redirect
- Material identifiers for traceability
Fleet manager sends back
- Order received and accepted
- Vehicle dispatched (pickup started)
- Delivery in progress
- Order completed (or: failed, with error code)
- System status and availability metrics
That is it. No vehicle telemetry, no battery levels, no navigation data. SAP does not need to know which specific vehicle handles a job, only that the job gets done. The fleet manager always reports back when a transport is completed (or failed), and may provide intermediate status updates along the way. SAP uses these confirmations to continue its own process, for example triggering the next production step or updating stock records.
The Fleet Manager API is the Starting Point
Every fleet manager vendor provides their own API for pushing transport orders into the system. This API is the integration point, not SAP itself. Some vendors offer well-documented REST interfaces, others work with MQTT messaging, and some use proprietary protocols or IDoc-based communication. A few vendors go further and provide pre-built SAP integration modules or certified connectors that reduce the development effort on the SAP side significantly. When evaluating AGV vendors, ask specifically about their SAP integration experience and whether they offer ready-made building blocks, it can save weeks of project time.
Two Common Integration Patterns
Direct API Connection
The fleet manager exposes a REST or MQTT interface. SAP connects to it, typically through custom ABAP development or IDoc configuration. Simple, low-latency, but requires SAP development skills on both sides.
Best for: single-site, single-fleet setups with straightforward transport logic.
Middleware / MES Layer
A middleware platform sits between SAP and the fleet manager. This could be a material flow controller, an MES, or an integration platform like MuleSoft. SAP sends production orders to the middleware, which breaks them into transport tasks and dispatches them to one or more fleet managers.
Best for: environments where AGVs are one part of a larger automated setup with conveyors, robots, or AS/RS systems.
What Drives Integration Cost
The cost of connecting SAP to your AGV fleet is hard to generalize because it depends heavily on your starting point. The main cost drivers are:
- SAP readiness: A well-maintained SAP landscape with clean master data and available sandbox environments is much cheaper to integrate than one with heavy customization, outdated basis versions, or restricted IT access.
- Complexity of order logic: a simple A-to-B transport is fast to integrate. Dynamic routing based on production schedules, priorities, and real-time buffer levels takes significantly longer.
- SAP customizing: custom transaction codes, workflows, and authorization concepts add effort. Every SAP landscape is different.
- Testing: integration testing with a live SAP system requires coordination, test data, and often a dedicated sandbox environment. This is frequently underestimated.
Who Does What
Three parties typically share the work:
| Party | Responsibility |
|---|---|
| AGV supplier | Fleet manager API, transport logic, status reporting |
| SAP consultant | ABAP development, IDoc configuration, SAP-side testing |
| Your internal IT | Network, firewalls, server infrastructure, SAP sandbox access |
Conclusion
SAP integration is not the monster it is sometimes made out to be. SAP connects to the fleet manager, never to individual vehicles. The data interface is simple: transport orders down, status messages up. Choose your integration pattern based on your existing IT landscape, not the AGV vendor's preference. Plan for proper integration testing with a SAP sandbox. Most importantly, define one owner for the interface specification early, this prevents finger-pointing between AGV supplier and SAP consultant later.