RDS fleet management integration with SAP - how to connect AGV robots to an ERP system

Integrating a fleet of AGV and AMR mobile robots with an ERP system is not an optional add-on. It is one of the conditions for a successful deployment. If robots do not exchange data with the supervisory system, transport orders start to live outside the real process and teams fall back to manual confirmations, rewritten order numbers and time-consuming checks of what actually happened on the shop floor.

In practice, it is the ERP layer, most often SAP, that manages warehouse logic, production planning and goods movements. The RDS fleet management system is responsible for execution: assigning missions, controlling traffic logic, collecting statuses and reacting to exceptions. From a deployment perspective, the key goal is therefore not only to launch the fleet, but to connect both layers so process data and physical execution become one consistent flow.

What the RDS and SAP integration is based on

The most flexible and recommended way to exchange data between RDS and SAP is bidirectional communication through a RESTful HTTP API with JSON payloads. For the customer’s IT team this is a predictable, well-known and maintainable model that does not require unusual middleware just to keep the integration alive.

This approach supports communication in both directions:

• SAP sends transport orders to RDS,
• RDS reports execution, failures and status changes back,
• SAP can query the system on demand for current point status or execution history.

In practice, the integration is usually built around three core layers.

1. Sending transport orders from SAP to RDS

The first data flow direction is the transport order itself. SAP decides what has to be moved, when it has to be moved and between which points. RDS then distributes the task across available robots and launches the proper execution logic.

On the RDS side, the administrator prepares a so-called Public Interface for external systems. This is configured in the Interface Configuration area and allows a custom endpoint to be created with a drag-and-drop workflow so it can listen for requests sent from SAP.

SAP then performs an HTTP POST request to the RDS server. The default path has the following structure:

http://<RDS_IP_address>:8080/handle/register/<interface_name>

For example, the endpoint may be:

/handle/register/interfaceTask

The request header should include:

Content-Type: application/json

And the request body can contain a JSON object with business task parameters:

{
  "data": {
    "taskRecordId": "SAP_order_ID_12345",
    "targetSiteId": "Loc-05",
    "content": "Goods_X"
  }
}

Once the message is received, RDS automatically creates and launches a task instance for the robot inside the Wind Task engine. From that point on, the AGV fleet takes over responsibility for physical transport execution.

For more unusual scenarios, RDS also exposes dedicated scripting methods such as receiveThirdOrder(orderParam: string). These methods make it possible to handle custom mapping logic, unusual payload formats or additional business rules required by a specific customer environment.

2. Reporting task completion back to SAP with callbacks

Sending a task to the robot is only the start of the process. SAP must know whether a pallet has been picked up, whether it reached the destination point and whether the task finished successfully or failed. Without that feedback, warehouse and production data in ERP quickly drift away from operational reality.

RDS can report task execution back to SAP in two main ways.

The first is Event Configuration, where the system can be configured to react to specific conditions such as:

• task completion,
• action failure,
• workstation state change,
• other process-relevant events.

The second is to configure Callback After Completion Of Action in the Wind Task engine together with an HttpPostTemplate network request. In that model, every completed or failed robot action triggers an HTTP POST to an endpoint listening on the SAP side.

In more advanced projects, the same mechanism can be extended through JavaScript system scripts. This allows the ERP layer to receive not only the completion state of an entire mission, but also each relevant warehouse state update, process blockage or operational exception.

3. Querying RDS for statuses on demand

Not every integration scenario is purely event-driven. Sometimes SAP needs data immediately, for example before launching the next production batch, before allocating a drop-off point or while verifying process consistency.

For that purpose, RDS exposes port 8080, and in the secured variant 8090 for HTTPS, where an external system can query the RDS database through REST API endpoints.

Two areas are used most often.

Storage point status

If SAP wants to check whether a given station is free or occupied, it can send requests to:

/api/work-sites/sites

This is the basis for deciding whether another transport can be launched at all and to which target point the next order should be routed.

Task history

To analyze completed, canceled or stopped missions, SAP can use endpoints such as:

/api/stat/taskList
/api/stat/agvTaskSuccessList

This allows SAP to compare plan versus execution, validate how tasks were performed and create its own operational reporting around mission execution quality.

Alternative protocols: OPC UA, MQTT and Modbus TCP

REST API is a strong fit for the business layer, especially where orders, reports and statuses are concerned. In some projects, however, the integration must also exchange signals that are much closer to real-time automation, such as:

• gate and lift states,
• safety zone changes,
• control-system signals,
• individual bits and process flags from PLCs.

In such cases, especially when the project integrates not only with SAP ERP itself but also with layers such as SAP MII or plant automation systems, RDS offers support for:

• OPC UA as an industrial communication standard,
• MQTT as a lightweight publish-subscribe protocol for telemetry and events,
• Modbus TCP as a classic PLC integration mechanism.

These protocols do not replace REST API. They complement it in areas where HTTP is not the best tool for technical signal exchange.

What this gives the customer in practice

A well-designed RDS to SAP integration means that from the moment an order is created in ERP to the moment pallet receipt is confirmed at the destination point, the whole process can run without human intervention. Operators do not need to rewrite order numbers, warehouse teams do not need to click manual confirmations and shift managers see in SAP the same process state that the fleet operator sees in RDS.

For the customer’s IT team, this means predictable and well-documented interfaces without the need to maintain multiple custom connectors. For the operations team, it means data consistency and lower risk that warehouse status in SAP will diverge from what the robots are actually doing on site.

The main business value goes even further. Automation stops being a separate island and becomes part of the company’s core operational process. That is when an AGV fleet starts to improve throughput and process quality instead of simply executing isolated trips next to the supervisory system.

What should be agreed early in the integration project

From a project perspective, a few topics should be aligned as early as possible:

• which data fields are the order identifiers on the SAP side and on the RDS side,
• when a mission should be treated as completed,
• which exceptions should be returned to ERP and in what form,
• which layer owns business logic and which layer owns execution logic,
• whether REST is enough or a real-time signal layer is also required.

The earlier these points are agreed, the lower the risk during testing and commissioning.

Summary

Integrating the RDS fleet management system with SAP is not only a technical connection between two systems. It is a way to make transport orders, physical execution and business confirmations part of one consistent process from ERP down to the shop floor or warehouse operation.

If this model is designed correctly, the customer gets more than a working AGV fleet. They get a full mechanism in which SAP plans, RDS executes and operational data returns automatically to the supervisory layer.

If you want to discuss AGV fleet integration with your SAP environment, talk to the Inovatica AGV team. We can show how this works in projects where the deployment is already live.