Ignition SCADA mit SAP verbinden: Wege, Schnittstellen, Stolpersteine

Ignition bindet Steuerungen und Datenquellen über OPC UA, SQL-Datenbanken, REST und MQTT an, einiges davon erst mit Zusatzmodulen. SAP bietet die Schnittstellen RFC, BAPI und IDoc an. Von Ignition dorthin gibt es drei Wege, die sich nicht ausschließen.

Weg 1: Eigenbau im Gateway. Ignition lässt sich per Skript erweitern: Es kann Webdienste aufrufen und mit einem Zusatzmodul eigene HTTP-Endpunkte bereitstellen. Die Skriptsprache ist Python, in Ignition als Jython auf der Java-Plattform umgesetzt; Skripte können deshalb die Java-Standardbibliothek nutzen. Java-Bibliotheken außerhalb der Standardbibliothek, auch die von SAP, lassen sich nur mit Eingriffen ins Gateway einbinden, über ein eigenes Modul oder die Gateway-Konfiguration. Der Code muss dann im Projekt gepflegt werden.

Weg 2: ein Zusatzmodul in Ignition. Module von Drittanbietern bringen den SAP-Zugang über RFC und BAPI direkt ins Gateway. Sie passen, wenn Ignition das einzige System ist, das mit SAP Daten austauscht.

Weg 3: eine eigene Integrationsschicht zwischen Ignition und SAP, etwa eine Middleware, die mit SAP über RFC und IDoc verbunden ist und mit Ignition über SQL, OPC UA oder REST. Ignition braucht dann keine eigene SAP-Schnittstelle. Was eine solche Schicht grundsätzlich leistet, beschreibt Was ist Middleware? Die Integrationsschicht kann SAP-Daten in einen Unified Namespace veröffentlichen, aus dem Ignition liest, oder sie direkt über SQL, OPC UA, REST oder Sparkplug an Ignition übergeben, je nachdem, was zu Projekt und vorhandener Systemlandschaft passt. Sie ist sinnvoll, wenn mehrere Systeme an SAP hängen oder die Kopplung ohne Programmierung im Gateway gepflegt werden soll.

Für die Wahl des Wegs zählt, wer die Schnittstelle später betreut und ob sie eine von vielen ist oder die einzige. Ebenso zählt, an wie vielen Stellen die Verbindung zu SAP liegt. Jede dieser Stellen muss eingerichtet, überwacht und bei Änderungen auf SAP-Seite angepasst werden. Bei mehreren Gateways lässt sich die Verbindung an einer zentralen Stelle bündeln, etwa in einer Integrationsschicht, die dann als eigenes System betrieben wird. Dazu kommen zwei technische Fragen. Schickt SAP bereits IDocs an andere Systeme, muss die Empfangsseite IDoc samt Statussätzen verarbeiten; läuft alles über RFC und BAPI, genügt ein RFC-fähiger Weg. Und: Stößt SAP die Übertragung an, braucht es einen Trigger, den SAP aufruft; holt Ignition die Daten ab, genügt ein Client.

Ein IDoc ist das asynchrone Austauschformat von SAP. Der Sender übergibt einen Beleg, der Empfänger puffert ihn und arbeitet ihn der Reihe nach ab. IDocs eignen sich deshalb vor allem für Stammdaten und Buchungsdatensätze, während ein RFC-Aufruf synchron ist und dort passt, wo eine Antwort sofort gebraucht wird. Mehr dazu auf SAP-Schnittstellen: RFC, BAPI und IDoc.

Im Gateway selbst lässt sich ein IDoc nur mit eigenem Code entgegennehmen: über einen HTTP-Endpunkt, an den SAP das IDoc schickt, oder über die Java-Bibliothek von SAP mit ihrer IDoc-Erweiterung. Einfacher wird es, wenn das IDoc in einer Datenbank ankommt, aus der Ignition ohnehin liest.

Diesen Weg beschreibt das OPC-Router-Handbuch. Zu SAP verbindet sich der OPC Router über das SAP-Plug-in, ausschließlich per RFC, auch für IDoc und BAPI, wahlweise über das klassische RFC-Protokoll oder NetWeaver RFC. Unterstützt werden unter anderem NetWeaver, ECC 6 und R/3 ab Release 4.0B; im Docker-Betrieb steht nur das NetWeaver-Protokoll zur Verfügung. Die SAP-Bibliotheken liefert SAP selbst, dafür braucht der Betreiber einen SAP-Account. Die klassische RFC-Bibliothek librfc32 wird von SAP seit dem 31. März 2016 nicht mehr unterstützt. Neben IDoc gibt es Transferobjekte für BAPI und RFC-Funktionsbausteine, beide mit dem Ergebnis als JSON, und einen RFC-Trigger, über den SAP den OPC Router aufruft.

Das IDoc-Transferobjekt versendet IDocs an SAP, mit Auswahl von IDoc-Typ, Erweiterung und Datensegmenten; nicht versendbare IDocs landen in einer IDoc-Queue. Der IDoc-Trigger empfängt IDocs aus SAP: Eingestellt werden Programm-ID und Gateway-Service, die Programm-ID muss zeichengenau zur RFC-Destination in SM59 passen. Als zweiter Empfangsweg steht ein eigener HTTP- oder HTTPS-Endpunkt zur Verfügung; einstellbar sind Port, Basic Authentication und SSL-Zertifikat. Das empfangene IDoc lässt sich als JSON-Dokument weitergeben und von dort in die Datenbank schreiben, aus der Ignition liest.

Zu Ignition nutzt der OPC Router Schnittstellen, die Ignition selbst dokumentiert. Er schreibt in Tabellen in SQL Server, PostgreSQL oder MySQL, die Ignition über JDBC liest. Als OPC UA Server kann er Ignition Werte anbieten, die aus SAP stammen statt aus einer Steuerung. Über Sparkplug tritt er als Edge-Node oder als Application auf, und REST-Endpunkte kann er aufrufen und bereitstellen, auch über den Import einer OpenAPI-Beschreibung. Über MQTT kann er SAP-Daten auch in einen Unified Namespace veröffentlichen, aus dem Ignition liest.

Ein Flow kann so einen Auftrag per RFC aus SAP lesen und in eine SQL-Tabelle schreiben, die ein Ignition-Bild anzeigt. Ein zweiter Flow holt die Rückmeldung aus dieser Tabelle und schickt sie als IDoc an SAP.

Der OPC Router kann als Redundanzpaar laufen. Die zweite Instanz baut ihre Verbindungen schon im Bereitschaftsbetrieb auf und kann übernehmen, wenn die erste ausfällt. Für SAP empfiehlt das Handbuch je Instanz eine eigene Programm-ID für RFC- und IDoc-Trigger und einen Test des Umschaltens mit den tatsächlich verwendeten SAP-Triggern.

Laut Handbuch wird der auslösende Aufruf aus SAP sofort quittiert, bevor der Flow läuft. Der OPC Router legt das IDoc in eine Warteschlange und entnimmt es im Abfragezyklus. Über diesen Aufruf geht kein Ergebnis zurück. Ist in der Registerkarte „Erweitert“ die IDoc-Quittierung eingeschaltet, meldet der OPC Router den Verarbeitungsstatus über eine eigene RFC-Verbindung als Statussatz zurück. Welcher Status bei Erfolg und bei Fehler gesetzt wird, ist einstellbar, zum Beispiel 12 („Dispatch OK“) und 11 („Error during dispatch“). Ob ein IDoc angekommen und weitergegeben ist, zeigt in SAP deshalb der Statussatz, nicht der Aufruf. Welche Berechtigungen der SAP-Benutzer des OPC Router braucht, listet das Handbuch, etwa S_RFC für den Verbindungsaufbau.

Die internationalen Anwendungsfälle auf opc-router.de (Stand der Seite: Juli 2026) beschreiben einen Fall aus Italien: Bei einem Hersteller von Polyethylenrohren verbindet der OPC Router SAP S/4HANA mit einem MES auf Ignition. Die Kopplung nutzt SAP IDoc, SAP RFC und MS SQL Server. Konfiguriert sind mehrere Transaktionen: die Übermittlung der Artikelstammdaten mit allen Merkmalen, der Eingang von Rohmaterial und die Produktionsaufträge. In der Gegenrichtung meldet das MES den Fortschritt an SAP zurück, je Auftrag mit produzierten Stückzahlen, Kilogramm Ausschuss und Materialverbrauch.

Der Fall zeigt eine Arbeitsteilung: Ignition trägt das MES, der OPC Router die SAP-Seite.

An dieser Grenze treffen ein asynchrones Belegformat, Werte aus der Steuerung und zwei unabhängig gewachsene Datenmodelle aufeinander. Die Fehlerbilder, die daraus folgen, hängen von der Bauart der Kopplung ab, gleich welches SCADA darunter liegt. Keines davon lässt sich allein durch Software lösen.

Angenommen heißt nicht verbucht

In SAP ist ein IDoc als übergeben vermerkt, der Auftrag erscheint aber nicht im MES. Oder umgekehrt: Die Rückmeldung ist abgeschickt, die Buchung fehlt.

Ursache: IDoc ist asynchron. Die Übergabe ist ein eigener Schritt, die Verarbeitung ein zweiter, und dazwischen kann ein Beleg an einer fehlenden Partnervereinbarung, einem unbekannten Material oder einer gesperrten Charge scheitern. Die erste Quittung bestätigt nur, dass der Beleg übergeben wurde.

Erkennbar an: IDocs mit Fehlerstatus in SAP, die niemand abarbeitet, und Aufträgen, die im MES fehlen, ohne dass eine Schnittstelle einen Fehler meldet.

Was beim Betrieb liegt: Die Partnervereinbarung in WE20, der Port in WE21 und die RFC-Destination in SM59 müssen stehen, und jemand muss die Fehler-IDocs in SAP regelmäßig abarbeiten. Dafür braucht es eine feste Zuständigkeit im SAP-Team.

Im OPC Router: Für IDocs, die SAP an den OPC Router schickt, gilt: Ist die IDoc-Quittierung eingeschaltet, schreibt er nach dem Transfer den eingestellten Status für Erfolg beziehungsweise Fehler als Statussatz zurück. Für IDocs, die er selbst an SAP sendet, lässt sich mit dem IDoc-Status-Transferobjekt anhand der IDoc-Nummer abfragen, ob sie verarbeitet wurden, samt Meldungstexten. Damit wird die zweite Quittung abfragbar.

Mengenrückmeldungen kommen unvollständig oder doppelt an

Die Rückmeldung an SAP enthält die Stückzahl, aber noch den Ausschuss des vorigen Auftrags. Oder derselbe Auftrag wird zweimal zurückgemeldet.

Ursache: Eine Rückmeldung besteht aus mehreren Werten, die in der Steuerung nacheinander geschrieben werden. Ein Lesezugriff während des Schreibens erwischt einen gemischten Stand, und eine wertgesteuerte Abfrage kann eine Änderung doppelt oder gar nicht erfassen.

Erkennbar an: Buchungen, deren Summen nicht zu den Zählerständen der Anlage passen.

Was beim Betrieb liegt: Die Steuerung schreibt zuerst alle zusammengehörenden Werte und erhöht danach einen Zähler. Diese Reihenfolge gehört ins SPS-Programm; keine Middleware holt sie nach.

Im OPC Router: Liest der OPC Router den Zähler selbst über OPC, aus der Steuerung oder über einen OPC-UA-Server, reagiert der Message-Trigger auf die Zähleränderung, übernimmt den Datensatz als Ganzes und schreibt eine Antwort auf einen Antwort-Datenpunkt. Das Handbuch nennt als Beispiel ausdrücklich die „Rückmeldung von Mengen an ERP oder MES“. Bleibt die Antwort aus, kann die Steuerung daran erkennen, dass sie wiederholen muss. Schreibt Ignition die Rückmeldung als eine Zeile in eine Tabelle, übernimmt der Transferstatus-Trigger sie erst, wenn ihre Markierungsspalte auf „Nicht transferiert“ steht. Die Zeile muss deshalb vollständig sein, bevor ihre Markierungsspalte diesen Wert erhält.

SAP ist im Wartungsfenster, die Anlage läuft weiter

Am Sonntagmorgen ist SAP für zwei Stunden nicht erreichbar. Die Produktion läuft, und danach fehlen diese zwei Stunden an Rückmeldungen.

Ursache: Eine Kopplung ohne Zwischenspeicher überträgt in dem Moment, in dem sie ausgelöst wird. Ist das Ziel nicht erreichbar, hat der Datensatz keinen Ort, an dem er warten kann.

Erkennbar an: Die Lücke hat scharfe Ränder und deckt sich mit einem Ereignis im ERP, nicht in der Anlage.

Was beim Betrieb liegt: Pro Datenfluss entscheiden, ob Nachliefern sinnvoll ist. Für eine Auftragsrückmeldung ja, für einen Momentanwert nein. Und jeder Datensatz braucht einen eigenen Zeitstempel, weil nachgelieferte Werte nicht zwingend in ihrer ursprünglichen Reihenfolge ankommen.

Im OPC Router: Holt der OPC Router die Rückmeldungen aus einer Tabelle, markiert der Transferstatus-Trigger jeden Datensatz nach dem Transfer als übertragen oder fehlgeschlagen. Optional wiederholt er fehlgeschlagene Transfers nach einer einstellbaren Wartezeit; der Datensatz bleibt in der Tabelle stehen. Die Wiederholung endet nach der eingestellten Zahl von Versuchen; Wartezeit und Zahl der Versuche werden so eingestellt, dass sie zusammen länger reichen als ein Wartungsfenster. IDocs, die sich nicht versenden lassen, gehen in eine IDoc-Queue.

Stammdaten passen nicht zusammen

Die Materialnummer im MES hat sechs Stellen, in SAP zehn mit führenden Nullen. Der Ausschuss wird in Kilogramm gemeldet, SAP erwartet eine andere Einheit.

Ursache: MES beziehungsweise SCADA und ERP haben ihre Datenmodelle unabhängig voneinander bekommen. Keines der beiden ist falsch; sie beschreiben dieselben Dinge mit verschiedenen Schlüsseln und Einheiten.

Erkennbar an: IDocs, die mit einem Fehler zum Material oder zur Mengeneinheit hängen bleiben, obwohl das Material in beiden Systemen existiert.

Was beim Betrieb liegt: Festlegen, welches System für welche Stammdaten führt, und die Zuordnung von Schlüsseln und Einheiten einmal fachlich beschreiben. Das ist Arbeit zwischen Produktion und SAP-Team.

Im OPC Router: Die Zuordnung wird im Flow grafisch konfiguriert. Welche Datensegmente eines IDocs übertragen werden, ist wählbar; leere numerische Felder (NUMC) kann das IDoc-Transferobjekt automatisch mit Nullen füllen.

Ignition bringt eigene Treiber und einen OPC-UA-Client mit; für die Maschinendaten braucht es keine zweite Schicht. Eine Integrationsschicht ergänzt das, wenn dieselben Daten zugleich in andere Systeme fließen sollen, etwa in einen Historian, eine Cloud-Plattform oder ein zweites MES. Tauscht SAP nur mit Ignition Daten aus, entfällt dieses Argument. Liest die Integrationsschicht selbst Maschinendaten, kann der OPC Router das als OPC-Client über OPC UA und OPC Classic (DA); über seinen OPC UA Server stellt er selbst eine Schnittstelle bereit, auch mit NodeSets aus Companion Specifications.

Eine mögliche Arbeitsteilung: Visualisierung und MES-Funktionen bleiben auf der Plattform, die die Bediener kennen, die Kopplung zu SAP und anderen IT-Systemen liegt bei einer eigenen Integrationsschicht. Wie sich SCADA und MES dabei voneinander abgrenzen, beschreiben Was ist SCADA? und Was ist ein MES? Wo beide in der Schichtung stehen, zeigt Was ist ISA-95?

Stand: 22. September 2026. Aussagen über Ignition beruhen vor allem auf der Dokumentation von Inductive Automation zu Gateway, OPC-Servern von Drittanbietern, JDBC-Treibern, WebDev, Skripten und Store and Forward, abgerufen am 21. und 22. September 2026; Aussagen über den OPC Router auf dem OPC-Router-Handbuch, vor allem auf den Kapiteln zum SAP-Plug-in, zum Message-Trigger, zu den Datenbank-Triggern und zur Redundanz.