Skip to content

Architecture and integrations

RDS integration with SAP ERP: orders, callbacks and statuses

Define an RDS–SAP interface contract: identifiers, a sample JSON request, confirmations, polling and retry handling.

This guide covers data exchange between a supervisory system and RDS. First establish whether the project uses SAP Warehouse Robotics or a bespoke ERP interface. The architecture guide explains that distinction and the adapter’s role.

The sample messages illustrate integration design. They are not an SAP API specification or confirmation that every RDS release supports the same functions.

Define the contract before configuring an endpoint

Agree the order owner, correlation identifier, source and destination, carrier identifier, priority and completion condition. Define permitted state transitions and location mapping.

An HTTP API with JSON is one possible communication method. A Warehouse Robotics integration also needs to implement its contract through the adapter described by SAP. A custom RDS endpoint is not automatically a ready-made SAP connector.

Confirm the system version, HTTPS configuration, authentication, permissions, timeouts and retry rules. A port number alone does not establish that a connection is encrypted.

Submit an order and map its data

The SEER manufacturer catalogue describes Wind Task, interface configuration and scripting. A particular installation still needs to connect the received data to the intended process, validate parameters and define error responses.

The following JSON retains the earlier article’s example. Field names belong to an illustrative contract rather than an SAP standard:

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

For this format, specify how the process obtains the pick-up location, identifies the carrier and interprets content. Agree Content-Type: application/json for a JSON request. Valid syntax alone does not mean a business task has been accepted.

Public Interface and Interface Configuration are names used in the RDS configuration description. Verify the actual endpoint, Wind Task mapping and response handling against the documentation and configuration of the installed release.

Callbacks and retries

Distinguish acceptance, transport start, pick-up, drop-off, completion, failure and cancellation. Agree which events the supervisory system requires and which event permits the warehouse movement to be confirmed.

The RDS description refers to Event Configuration and Callback After Completion Of Action with HttpPostTemplate. Treat these as mechanism names to verify for the chosen release. Regardless of implementation, a callback should identify the order, state, event time and error.

The receiver must recognise duplicates. After losing a response, the sender should reconcile state and follow an agreed retry rule without automatically starting a second transport. Retain communication history and operator decisions.

Status queries and version-dependent examples

Polling can help reconcile state after a disconnection, check station occupancy and inspect task history. Reading “location free” does not reserve it: the situation can change before the mission starts.

The following identifiers from the earlier material are retained as examples requiring verification, not ready-to-run instructions. An RDS release for which all of them form the applicable contract has not been established:

  • ports 8080 and 8090;
  • /handle/register/<interface_name> and /handle/register/interfaceTask;
  • /api/work-sites/sites;
  • /api/stat/taskList and /api/stat/agvTaskSuccessList;
  • the receiveThirdOrder(orderParam: string) method.

Before use, confirm availability, HTTP method, request and response schemas, authentication and permissions. The official SEER help centre points to RDS documentation; detailed manuals may require an account. Do not expose ports solely on the basis of an article example.

Plant automation and signal responsibilities

OPC UA, MQTT and Modbus TCP can form part of an architecture connecting controllers, doors, lifts or telemetry. Availability of a specific protocol and connector depends on the product, licence and configuration. It does not replace the ERP order and confirmation contract.

Ordinary process messages must not be treated as a safety channel. Safety functions and their validation require a separate design. Connecting PLC signals with the SAP layer through an integration solution should be defined as its own scope.

Acceptance and ongoing maintenance

Test a valid task, an invalid carrier, an occupied destination, timeout, duplicate message, restart and cancellation during a mission. Check that the SAP state matches physical execution and that recovery does not duplicate a goods movement.

Assign owners for the adapter, RDS configuration and SAP data, with error monitoring and a version-update procedure. Those maintenance responsibilities remain after the first successful transport.

The result should be an agreed and tested path from order to confirmation. Discuss your architecture with us, starting with system versions, the process description and example orders.

← Back to publications