SAP Schnittstellen: OData, IDoc & Co im Unified Namespace

SAP ist in der produzierenden Industrie weit verbreitet. Damit Geschäftsprozesse und Shopfloor konsistent zusammenspielen, müssen OT-Daten zuverlässig in SAP integriert werden. Allerdings hat SAP mit der Abkündigung von SAP MII und Plant Connectivity (PCo) die direkte OT-Integration beendet. Zudem stoßen klassische Punkt-zu-Punkt-Architekturen von OT und IT an ihre Grenzen. Vor diesem Hintergrund etabliert sich der Unified Namespace (UNS) als zukunftsfähiger Integrationslayer: OT-Daten werden außerhalb von SAP ereignisbasiert, entkoppelt und kontextualisiert bereitgestellt. SAP konsumiert diese Informationen gezielt über APIs und Events. Der folgende Artikel vergleicht die für diese Architektur relevanten SAP Schnittstellen.

 

Überblick: SAP, S/4HANA und OT-relevante Subsysteme

SAP ist eine Plattform aus Kernsystem und angebundenen Fach- und Integrationskomponenten. Im industriellen Umfeld bildet SAP S/4HANA den digitalen Kern („Digital Core“) für transaktionale Geschäftsprozesse wie Planung, Logistik, Qualität und Instandhaltung. S/4HANA ist dabei die Weiterentwicklung des klassischen SAP ERP (ECC) und basiert vollständig auf der In-Memory-Datenbank SAP HANA. Insbesondere aufgrund dieser Datenbank bietet S/4HANA gegenüber R/3 und ECC Vorteile bei der parallelen Verarbeitung großer Datenmengen.

 

Übersicht OT-relevante SAP-Subsysteme

Folgende Übersicht zeigt die wichtigsten OT-relevanten SAP-Subsysteme.

SAP-Subsystem	Rolle im OT-Kontext	Status
SAP Digital Manufacturing (DM/DMC)	Cloud-MES für Auftragsausführung, Rückmeldungen, Shopfloor-Events	✅ Langfristig unterstützt
SAP Integration Suite (CPI)	Middleware für Mapping, Routing, API- und Event-Integration zwischen externen Systemen und SAP-Anwendungen	✅ Langfristig unterstützt
SAP Enterprise Asset Management (EAM)	Instandhaltung, Wartung, Meldungen, Aufträge, Messpunkte	✅ Langfristig unterstützt
SAP Quality Management (QM)	Qualitätsprüfungen, Prüflose, Qualitätsmeldungen, Freigabe- und Sperrentscheidungen	✅ Langfristig unterstützt
SAP Extended Warehouse Management (EWM)	Intralogistik, Lager- und Materialflusssteuerung (z. B. Bereitstellung, Nachschub, Routenzüge, FTS)	✅ Langfristig unterstützt
SAP ME	Klassisches On-Prem-MES	❌ Abgekündigt
SAP MII	Shopfloor-Integration & Reporting	❌ Abgekündigt
SAP Plant Connectivity (PCo)	OT-Gateway (OPC UA, SPS, Feldbusse)	❌ Abgekündigt

 

Wichtig für die SAP-OT-Integration

S/4HANA ist kein Echtzeit-System und nicht für die Verarbeitung hochfrequenter Zeitreihen aus dem Shopfloor ausgelegt. Die direkte Anbindung von Maschinen und Linien gehört daher nicht zum Aufgabenbereich des ERP-Kerns. Mit der Abkündigung von SAP MII und SAP Plant Connectivity (PCo) hat sich SAP zudem aus dem OT-Integrationsgeschäft zurückgezogen. In modernen Architekturen werden OT-Daten daher außerhalb von S/4HANA über einen Unified Namespace (UNS) erfasst und ereignisbasiert bereitgestellt. Lösungen wie i-flow bilden dabei das OT-nahe Rückgrat, das Maschinendaten strukturiert, entkoppelt und gezielt über APIs oder Events an SAP-Systeme übergibt.

 

Integration Suite als SAP Middleware

Die SAP Integration Suite (CPI) fungiert als zentrale Middleware zwischen SAP-Systemen, Cloud-Services und externen Anwendungen. Sie übernimmt Mapping, Routing und Orchestrierung von APIs und Events und entkoppelt SAP damit von technischen Details der angebundenen Systeme. Hierfür stellt CPI eine Vielzahl nativer Konnektoren (Adapter) bereit. Unter anderem für REST/OData, SOAP, MQTT, AMQP, JMS, SFTP/FTP, Datenbanken sowie für zahlreiche SAP- und Cloud-Services.

Im OT-Kontext dient CPI nicht der direkten Maschinenanbindung, sondern der Integration zwischen Unified Namespace (UNS), Event Brokern und SAP. Typische Szenarien sind die Transformation von OT-Events (z. B. MQTT) in SAP-konforme Aufrufe wie OData oder BAPIs sowie die Abbildung end-to-end Geschäftsprozesse über mehrere Systeme.

 

Übersicht SAP-Schnittstellen

SAP stellt eine Vielzahl technischer Schnittstellen bereit, um OT- und Shopfloor-Systeme mit ERP-, MES- und Cloud-Lösungen zu verbinden. Im Produktionsumfeld haben sich dabei die folgenden Integrationswege etabliert. Diese unterscheiden sich in ihrem Kopplungsgrad, ihrer Echtzeitfähigkeit und ihrer Eignung für Cloud- und Event-Architekturen.

 

1. SAP OData Services (REST APIs)

OData ist der strategische API-Standard von SAP, insbesondere auch in S/4HANA und Cloud-Szenarien. Über HTTP(S), JSON/XML und gängige Security-Mechanismen wie OAuth ermöglichen OData-APIs den direkten Zugriff auf SAP-Geschäftsobjekte.

• Typische OT-Use Cases: Synchrone Rückmeldungen von Fertigungsaufträgen, Materialbuchungen und Bestandsabfragen, Freigaben oder Statusänderungen direkt vom Shopfloor
• Architektur-Einordnung: OData eignet sich ideal für transaktionale Echtzeit-Integrationen mit moderner OT-naher Software (MES, IIoT-Plattformen, mobile Apps). Für Massendaten oder hochfrequente Sensordaten ist OData jedoch ungeeignet – hier sind asynchrone, eventbasierte SAP Schnittstellen die bessere Wahl.
• Notwendiges Know-how: REST/OData, OAuth/Identity, SAP-API-Modelle (Business Objects), Fehler-/Retry-Handling

 

2. SAP Digital Manufacturing (DMC) APIs

SAP Digital Manufacturing setzt konsequent auf cloud-native REST/APIs, Events und Webhooks zur Integration von Shopfloor-Daten.

• Typische OT-Use Cases: Auftrags- und Rückmeldedaten über APIs, Ereignisbasierte Benachrichtigungen bei Produktions- oder Qualitätsereignissen, Einbindung in UNS- und Broker-Architekturen
• Architektur-Einordnung: DMC-APIs sind hoch skalierbar und Cloud-ready, erfordern jedoch sauberes API-, Event- und Security-Design (OAuth, Topics, Governance). Sie markieren den Übergang von transaktionalen zu ereignisdominierten SAP Schnittstellen.
• Notwendiges Know-how: Cloud/API-Design, OAuth, Event-/Webhook-Design, Topic-/Governance-Konzepte

 

Abgrenzung SAP OData Services und DMC REST APIs

Aspekt	S/4HANA	SAP Digital Manufacturing (DMC)
API Standard	OData als Hauptstandard	REST Endpoints + (non-OData)
Fokus	ERP-Transaktionen & Geschäftsobjekte	Prozess-/MES-Daten & Produktionsereignisse
Echtzeitfähigkeit	synchron/transaktional	synchron & asynchron (Events/Webhooks)
Typische Nutzung	Produktionsaufträge, Status, Materialdaten	Shopfloor-Status, Qualitäts-/Produktionsereignisse
Integration mit UNS/Event Mesh	über APIs/Events möglich	nativ eventfreundlich

 

3. Direkter Datenbankzugriff auf SAP S/4HANA

SAP S/4HANA basiert auf einer In-Memory-Datenbank, die in On-Premise- und Private-Cloud-Editionen technisch auch einen direkten Zugriff externer Systeme über JDBC/ODBC ermöglicht. Dieser Zugriff eignet sich insbesondere für lesende Szenarien, etwa zur Auswertung oder zum Export von Produktions- und Bewegungsdaten.

• Typische OT-Use Cases: Lesender Zugriff auf Produktions-, Bewegungs- oder Statusdaten, Reporting- und Analysezwecke außerhalb des SAP-Systems
• Architektur-Einordnung: Direkter Datenbankzugriff ist kein klassischer SAP-Schnittstellenmechanismus, sondern ein technischer Zugriffspfad. Lesender Zugriff – idealerweise über freigegebene CDS Views – kann in ausgewählten Szenarien sinnvoll sein. Schreibende Zugriffe umgehen jedoch Geschäftslogik, Validierungen und Sicherheitsmechanismen und gelten als nicht upgrade- und betriebssicher. Für schreibende Operationen sollten daher ausschließlich SAP Schnittstellen wie OData-APIs, BAPIs oder ereignisbasierte Mechanismen verwendet werden.
• Notwendiges Know-how: SQL/HANA, Datenmodellkenntnis, CDS Views, Security/Read-Only-Governance

 

4. SAP IDoc (Intermediate Documents)

IDocs sind das klassische SAP-Format für strukturierte, asynchrone Nachrichtenübertragung. Sie werden intern als Datensätze verarbeitet und können über verschiedene Transportmechanismen (z. B. RFC, Middleware oder optional file-basiert) zwischen SAP und externen Systemen ausgetauscht werden.

• Typische OT-Use Cases: Anlage / ERP-Kopplungen (z. B. Auftragsrückmeldungen), Stammdatenverteilung (Materialstamm, Stücklisten, Arbeitspläne)
• Architektur-Einordnung: IDocs werden in der Praxis häufig file-basiert über zusätzliche Middleware wie FTP-Server oder EDI-Gateways transportiert. Diese mehrstufige Übertragung erhöht die Komplexität und Fehleranfälligkeit der Integration, insbesondere bei Netzwerkproblemen oder fehlender End-to-End-Transparenz. Gleichzeitig sind IDocs nicht echtzeitfähig. In Cloud-Architekturen in der S/4HANA Public Cloud werden sie daher zunehmend durch API-first-Ansätze ersetzt. Dennoch bleiben IDocs in etablierten Brownfield-Landschaften ein tragendes Element vieler SAP Schnittstellen.
• Notwendiges Know-how: IDoc-Typen/Mapping (z. B. MATMAS/LOIPRO), ALE/EDI-Grundlagen, Monitoring/Reprocessing

 

5. SAP RFC / BAPI 

RFC (Remote Function Calls) bzw. BAPI (Business Application Programming Interface) ermöglicht direkte, synchrone Funktionsaufrufe im SAP-Backend mit hoher Performance und vollständiger Transaktionssicherheit.

• Typische OT-Use Cases: Zeitkritische Buchungen aus MES oder Integrationsmiddleware, Rückmeldungen, Qualitäts- und Produktionsbuchungen, Bestehende Brownfield-Integrationen mit hoher Transaktionsdichte
• Architektur-Einordnung: RFC/BAPI ist technisch effizient, erfordert jedoch eine enge, proprietäre Kopplung. Zudem sind spezielle Konnektoren notwendig (von i-flow unterstützt). In Cloud- und UNS-Architekturen wird diese Form der SAP Schnittstellen zunehmend durch APIs und Events ergänzt oder abgelöst.
• Notwendiges Know-how sehr hoch: ABAP-/BAPI-Kenntnis, Funktionsbausteine, SAP-Daten-/Beleglogik, Berechtigungen, Fehler-/Lock-Handling

 

6. SAP Message Queues / Event Mesh

SAP Event Mesh ist der zentrale Baustein für ereignisgesteuerte SAP Schnittstellen. Als Cloud-Broker unterstützt er Publish/Subscribe-Modelle über Protokolle wie AMQP und MQTT.

• Typische OT-Use Cases: Verteilung von Business- und Shopfloor-Events in Near-Realtime, Integration in einen Unified Namespace (UNS)
• Architektur-Einordnung: SAP Event Mesh ermöglicht eine lose, ereignisbasierte Kopplung zwischen SAP-Systemen und externen Anwendungen. Externe Systeme können nach Authentifizierung Events aktiv in den Broker publizieren oder abonnieren, etwa über MQTT oder AMQP. Damit eignet sich Event Mesh nicht nur zur Verteilung von SAP-Business-Events, sondern auch zur Integration von OT-Events. Event Mesh ist optimal für skalierbare, asynchrone Kommunikation, jedoch nicht für synchrone, transaktionale Buchungen ausgelegt.
• Notwendiges Know-how sehr hoch: Event-driven Architektur, MQTT/AMQP, Topic-Design, Security (OAuth/TLS), Schema-/Event-Governance

 

SAP-Schnittstellen richtig einsetzen: Use-Case Überblick

Die folgende Übersicht ordnet die wichtigsten SAP-Schnittstellen typischen Integrationsszenarien zu und zeigt, welche Technologien sich für welche Datenflüsse, Kopplungsgrade und Architekturmuster eignen.

SAP-Schnittstelle	Kurzbeschreibung	Stärken & Einschränkungen	Typische Integrationsszenarien (Beispiele)
OData Services (REST APIs)	Standardisierte Web-APIs auf SAP-Geschäftsobjekten (HTTP(S), OAuth, JSON/XML)	Stärken: API-first, cloudfähig, gut für transaktionale Buchungen in S/4HANA. Einschränkungen: Ungeeignet für Massendaten und hochfrequente Signale; erfordert sauberes API- und Berechtigungsdesign.	Bewegungsdaten transaktional buchen (Auftragsbestätigungen, Materialbuchungen, Statuswechsel); Stammdaten on-demand abrufen (Materialstamm, Arbeitspläne).
SAP Digital Manufacturing (DM/DMC) APIs	Cloud-native REST APIs plus Events/Webhooks für Shopfloor- und MES-Prozesse	Stärken: Hoch skalierbar, event- und cloudfähig, gut geeignet für UNS- und Broker-Architekturen. Einschränkungen: Erfordert klares Event-, Topic- und Security-Governance; stärker prozess- als objektorientiert.	Cloud-MES-Integration (Aufträge, Rückmeldungen); Ereignisse bei Produktions- und Qualitätsereignissen; Kopplung an UNS über Event Broker.
Direkter DB-Zugriff (JDBC/ODBC, lesend)	Technischer Lesezugriff auf S/4HANA-Datenbank (On-Prem / Private Cloud), idealerweise über CDS Views	Stärken: Sehr effizient für Reporting und Datenexport (read-only). Einschränkungen: Kein offizieller Integrationsmechanismus; schreibende Zugriffe nicht upgrade- oder betriebssicher; deploymentabhängig.	Reporting und Analytics außerhalb von SAP; Datenexport für BI- oder Datamart-Lösungen (read-only).
IDoc (Intermediate Documents)	Klassische, asynchrone und strukturierte Nachrichtenübertragung (z. B. via RFC, Middleware, Datei)	Stärken: Robust, bewährt in Brownfield-Szenarien, gut für große Datenmengen und Stammdatenpakete. Einschränkungen: Nicht near-realtime; oft mehrstufig und komplex; in Cloud-Editionen teils nicht verfügbar.	Stammdatenverteilung (Materialstamm, Stücklisten, Arbeitspläne); ERP–MES-Kopplungen (z. B. LOIPRO, periodische Rückmeldungen).
RFC / BAPI	Direkte, synchrone Funktionsaufrufe im SAP-Backend mit hoher Transaktionssicherheit	Stärken: Sehr performant und transaktionssicher, geeignet für zeitnahe Buchungen in On-Prem-Szenarien. Einschränkungen: Proprietär, hoher Betriebsaufwand, wenig cloud-native, enge Kopplung.	Zeitkritische Produktions- und Qualitätsbuchungen; Bestehende MES–SAP-Integrationen mit hoher Transaktionsdichte (Brownfield).
SAP Event Mesh (Pub/Sub)	Cloud-Broker für ereignisbasierte Integration (MQTT/AMQP, Publish/Subscribe)	Stärken: Lose Kopplung, hohe Skalierbarkeit, ideal als Event- und UNS-Backbone. Einschränkungen: Nicht für synchrone Buchungen geeignet; benötigt sauberes Topic- und Event-Governance-Modell.	Verteilung von Events wie „OrderReleased“, „QualityResult“, „DowntimeDetected“ an mehrere Systeme; Weiterleitung ausgewählter OT-Events aus dem UNS in Cloud-SAP-Landschaften.

 

Von der Schnittstelle zur Architektur­entscheidung

Die vorgestellten SAP-Schnittstellen unterscheiden sich deutlich in Kopplungsgrad, Kommunikationsmodell und Cloud-Fähigkeit. Keine dieser Technologien ist jedoch per se „richtig“ oder „falsch“. In der Praxis werden mehrere Schnittstellen parallel eingesetzt – jeweils dort, wo sie fachlich und architektonisch sinnvoll sind. Entscheidend ist daher nicht die isolierte Betrachtung einzelner SAP-Technologien, sondern die Frage, welcher Typ von Datenfluss über welche Integrationsform geführt werden sollte. Genau diese Einordnung ist für eine stabile SAP-OT-Architektur – insbesondere im Kontext eines Unified Namespace – zentral.

Near-Realtime vs. Batch

Im SAP-Umfeld ist echte Echtzeit im Millisekundenbereich in der Regel nicht erforderlich. Entscheidend ist vielmehr die Abgrenzung zwischen Near-Realtime-Verarbeitung (Sekundenbereich) und Batch-orientierter Verarbeitung.

Für Near-Realtime-Szenarien eignen sich vor allem RFC/BAPI und OData-APIs, da Buchungen gezielt und unmittelbar im SAP-Backend ausgeführt werden können. Diese Schnittstellen sind transaktional ausgelegt und liefern sofort eine fachliche Rückmeldung – etwa für Statusänderungen, Rückmeldungen oder qualitätsrelevante Buchungen aus dem Shopfloor. Unterschiede im technischen Overhead sind dabei meist zweitrangig gegenüber Semantik, Konsistenz und Transaktionssicherheit. Event Mesh adressiert ebenfalls Near-Realtime, jedoch mit einem anderen Fokus: Ereignisse werden asynchron und entkoppelt verteilt, typischerweise innerhalb weniger Sekunden. Dadurch eignet sich dieser Ansatz besonders, um mehrere Systeme parallel zu informieren, ohne direkt im SAP zu buchen – ein zentrales Architekturprinzip von Unified-Namespace-basierten Integrationen.

IDocs hingegen sind klar batch-orientiert. Sie werden zeitversetzt verarbeitet (z. B. in Minuten- oder Stundenintervallen) und sind auf Robustheit und große Datenmengen ausgelegt, nicht jedoch auf zeitkritische Rückmeldungen.

Praxisregel: Sobald ein Ereignis zeitnah fachlich wirksam werden muss – etwa bei Störungen, Freigaben oder unmittelbaren Statusbuchungen – sind API- oder BAPI-basierte Integrationen die bessere Wahl.

 

Asynchron vs. synchron

Ein weiterer zentraler Unterschied zwischen SAP-Schnittstellen liegt im Kommunikationsmodell.

Synchrone Schnittstellen wie RFC/BAPI oder OData-APIs erwarten eine direkte Antwort vom SAP-System. Der aufrufende Prozess weiß sofort, ob eine Buchung erfolgreich war oder fehlgeschlagen ist. Das ist ideal für kritische Geschäftsprozesse, bei denen eine unmittelbare Rückmeldung erforderlich ist – etwa bei Auftragsrückmeldungen, Statusänderungen oder qualitätsrelevanten Buchungen.

Asynchrone Schnittstellen wie Event Mesh oder IDocs entkoppeln Sender und Empfänger zeitlich. Der Produzent eines Ereignisses muss nicht auf die Verarbeitung im SAP warten, sondern stellt die Information bereit, die SAP oder andere Systeme später konsumieren. Dieses Modell erhöht die Skalierbarkeit und Robustheit der Architektur erheblich, da Lastspitzen abgefedert und Systeme unabhängig voneinander weiterarbeiten können.

 

Stammdaten vs. Bewegungsdaten:

Ein weiteres zentrales Unterscheidungsmerkmal für die Wahl der passenden SAP-Schnittstelle ist der Datentyp. Stammdaten und Bewegungsdaten unterscheiden sich grundlegend in Änderungsfrequenz, Volumen und zeitlicher Kritikalität – und stellen entsprechend unterschiedliche Anforderungen an die Integration.

Stammdaten wie Materialstämme, Stücklisten oder Arbeitspläne ändern sich vergleichsweise selten. Sie lassen sich daher gut gebündelt und periodisch übertragen. In vielen bestehenden Architekturen kommen hierfür weiterhin IDoc-basierte Integrationen zum Einsatz, etwa für regelmäßige Synchronisationen zwischen ERP und MES (z. B. MATMAS, BOMMAT). Alternativ können Stammdaten auch on demand über OData-APIs bereitgestellt werden, etwa wenn ein Shopfloor-System oder eine Maschine gezielt Informationen zu einem Material oder Arbeitsplan abruft. Der Fokus liegt hier auf Konsistenz und Vollständigkeit, weniger auf zeitlicher Nähe.

Bewegungsdaten hingegen entstehen kontinuierlich im laufenden Produktionsprozess: Fertigungsaufträge, Mengenrückmeldungen, Qualitätsmessungen oder Zustandsänderungen. Sie sind häufig zeitkritisch, werden einzeln verarbeitet und haben direkten Einfluss auf operative Prozesse. Entsprechend eignen sich hier transaktionale Schnittstellen wie BAPI oder OData für gezielte Buchungen sowie ereignisgetriebene Ansätze zur Verteilung der Informationen.

 

On-Prem vs. Cloud-SAP

Neben Zeitverhalten, Kommunikationsmodell und Datentyp spielt auch das Deployment-Modell des SAP-Systems eine entscheidende Rolle bei der Wahl der passenden Schnittstelle. Ob SAP lokal betrieben wird oder als Cloud-Service läuft, beeinflusst direkt, welche Integrationsmechanismen technisch verfügbar und architektonisch sinnvoll sind.

In klassischen On-Prem-Landschaften – etwa SAP ECC oder S/4HANA On-Prem zusammen mit lokalem MES und Shopfloor-IT – wurden historisch vor allem RFC/BAPI und IDocs eingesetzt. Diese Schnittstellen integrieren sich eng in das SAP-Backend, bieten hohe Transaktionssicherheit und kommen ohne zusätzliche Cloud-Infrastruktur aus. Gerade in Brownfield-Umgebungen sind sie daher weiterhin weit verbreitet und funktional bewährt.

Mit dem Übergang zu cloud-basierten SAP-Systemen (z. B. S/4HANA Cloud oder SAP Digital Manufacturing) verschiebt sich der Integrationsfokus jedoch deutlich. In Cloud-Editionen sind Web-APIs (OData/REST) der primäre – und teilweise einzige – Integrationsweg. Klassische Mechanismen wie RFC oder IDocs stehen je nach Cloud-Variante nur eingeschränkt oder gar nicht mehr zur Verfügung (z. B. in der S/4HANA Public Cloud). Cloud-SAP erzwingt damit faktisch einen API-first-Ansatz.

 

Best Practices

Aus den beschriebenen Schnittstellen und Datenflüssen lassen sich einige Architekturprinzipien ableiten. Sie machen SAP-OT-Integrationen wartbar, sicher und skalierbar.

1. Entkopplung statt Punkt-zu-Punkt-Integration

Punkt-zu-Punkt-Verbindungen zwischen OT und IT skalieren schlecht: Jede zusätzliche Maschine oder Anwendung erhöht den Integrationsaufwand überproportional. Setzen Sie stattdessen auf Publish/Subscribe. Ein Messaging-Layer – im Werk oder in der Cloud – entkoppelt Produzenten und Konsumenten. Systeme publizieren Daten, ohne ihre Abnehmer zu kennen. Das erhöht Robustheit, vereinfacht Erweiterungen und verhindert Mehrfachbelastung von SAP. Event Mesh und Message-Broker sind typische Bausteine für dieses „Event Thinking“.

 

2. Unified Namespace als zentrales Rückgrat

Behandeln Sie den Unified Namespace als Zentrum der Integrationsarchitektur. OT-Systeme publizieren Zustände und Ereignisse in den UNS, statt Daten in Silos zu halten oder direkt nach SAP zu senden. SAP, MES, Analytics und Wartung konsumieren daraus rollenbasiert die relevanten Informationen. Eine saubere Topic-Struktur und Zugriffskontrolle halten den Namespace beherrschbar. So lassen sich neue Anwendungen später anbinden, ohne neue Punkt-zu-Punkt-Schnittstellen zu bauen. Weitere Informationen finden Sie hier.

 

3. Edge und Cloud bewusst kombinieren

Nicht alle Daten gehören in SAP oder in die Cloud. Verarbeiten Sie Rohdaten möglichst nah an der Quelle: filtern, verdichten, kontextualisieren – dann weiterleiten. Eine i-flow Edge kann hochfrequente Signale lokal analysieren und daraus Events oder KPIs ableiten. Diese Ergebnisse gehen über den UNS gezielt an SAP oder andere Cloud-Services. Das senkt Datenvolumen, entlastet Netzwerke und reduziert Cloud-Kosten.

 

4. Security und Governance von Anfang an mitdenken

OT-IT-Integration braucht ein klares Security- und Betriebsmodell: Outbound-only aus der OT, zertifikatsbasierte Verbindungen (z. B. MQTT/TLS, OAuth für APIs) und konsequente Segmentierung. Ergänzend gilt fachliche Governance: Definieren Sie, welche Daten mit welcher Qualität und Granularität nach SAP fließen, vergeben Sie Minimalrechte für technische User und etablieren Sie einen gemeinsamen Change-Prozess zwischen IT und OT. Weitere Informationen finden Sie hier.

Guideline für Cloud-SAP: Keine direkten Punkt-zu-Punkt-Verbindungen aus der Cloud in den Shopfloor. Stattdessen: OT → lokaler UNS (z. B. i-flow) → selektierte Events in SAP (z. B. via MQTT/AMQP).

 

5. Schrittweise modernisieren statt alles neu bauen

Lösen Sie IDoc- oder RFC-Integrationen nicht „auf einen Schlag“ auf. Bewährt hat sich eine inkrementelle Modernisierung: Legacy-Schnittstellen laufen weiter, während Event- und UNS-basierte Flüsse schrittweise dazukommen. So sinkt das Risiko, und das Zielbild (UNS-zentriert, cloudfähig) bleibt steuerbar. Definieren Sie dieses Zielbild klar und richten Sie neue Investitionen (Maschinen, Software) von Anfang an daran aus.

 

Use-Cases und i-flow Kundenbeispiele

Im Folgenden sind einige Kundenbeispiele beschrieben inkl. der Umsetzung mittels des i-flow Unified Namespace (UNS).

1. Produktionsaufträge & Rückmeldungen

Produktionsaufträge sind der zentrale Taktgeber zwischen ERP und Shopfloor und müssen konsistent, aktuell und entkoppelt an alle beteiligten Systeme verteilt werden.

1. SAP → i-flow (OData): i-flow synchronisiert Fertigungsaufträge periodisch aus SAP (z. B. entlang des Planungs- oder Schichtzyklus) und legt sie strukturiert im UNS ab.
2. Statusänderung → Event im UNS: Wird ein Auftrag in SAP freigegeben oder geändert, erzeugt i-flow ein fachliches Event im UNS (z. B. ProductionOrderReleased).
3. UNS → i-flow Edge → Anlage: Die i-flow Edge abonniert das Event, liest die zugehörigen Auftragsdaten aus dem UNS und überträgt sie OT-nah an Linie oder Steuerung.
4. Rückmeldung → UNS → SAP: Produktionsrückmeldungen werden von der Edge als Events publiziert; i-flow bucht fachlich relevante Rückmeldungen gezielt per OData/BAPI zurück nach SAP.

Worauf es ankommt: SAP bleibt transaktionales System, der i-flow UNS verteilt Ereignisse, Anlagen sind vollständig entkoppelt.

 

2. Maschinendaten & KPIs

Maschinendaten liefern die Grundlage für Transparenz, Leistungskennzahlen und Optimierung auf Basis von Zyklenzeiten, Stückzähler, Temperaturen, Zustände usw. Diese Daten erzeugen jedoch Volumen, das allein aus Kostengründen nicht ungefiltert in die Cloud gelangen sollte.

1. Maschine → i-flow Edge → UNS: Maschinen- und Prozessdaten werden kontinuierlich von der i-flow Edge erfasst und als Rohdaten oder Zustandsereignisse im UNS publiziert.
2. Verdichtung im Edge/UNS:i-flow Edge leiten aus Rohdaten aggregierte Werte, KPIs oder fachliche Events ab (z. B. ShiftOutputCalculated, DowntimeDetected).
3. UNS → SAP (OData/BAPI): Nur verdichtete Kennzahlen oder relevante Ereignisse werden transaktional in SAP gebucht.

Worauf es ankommt: Rohdaten verbleiben außerhalb von SAP; SAP konsumiert Ergebnisse (ERP eignet sich nicht als Zeitreihendatenbank). In Szenarien, in welchen Big Data Analysen erwünscht sind, können Maschinendaten direkt über MQTT an SAP Digital Manufacturing Insights geschickt werden.

 

3. Qualitätsdaten & Traceability

Qualitäts- und Rückverfolgbarkeitsdaten haben sicherheits- und compliance-kritische Bedeutung. Unternehmen erfassen mittels i-flow Qualitätsmessungen wie Maße oder Fehlercodes in SAP, protokollieren Prüfergebnisse revisionssicher und verfolgen Seriennummern lückenlos durch die gesamte Fertigungskette.

1. Prüfung → i-flow Edge → UNS: Qualitäts- und Traceability-Ereignisse (z. B. QualityCheckPassed, SerialAssigned) entstehen am Prüfstand oder an der Anlage und werden über die i-flow Edge im UNS publiziert.
2. Datenanreicherung in i-flow: i-flow verknüpft die prozess- und produktnahen OT-Daten (Messwerte, Station, Zeitpunkt) mit kontextuellen Informationen aus SAP, z. B. Fertigungsauftrag, Materialnummer, Serien- oder Chargennummer. So entsteht ein fachlich vollständiger Qualitätskontext, der eindeutig einem Produkt und Auftrag zugeordnet ist.
3. UNS → SAP QM (OData/BAPI): Auf Basis dieses angereicherten Kontexts schreibt i-flow konsistente Prüf- und Entscheidungsdaten transaktional z. B. via BAPI_QM_RESULT_RECORD in SAP QM (z. B. Prüflos, Ergebnis, Verwendungsentscheidung).

Worauf es ankommt: SAP QM erhält entscheidungsrelevante, kontextualisierte Qualitätsdaten; der UNS stellt die Entkopplung sicher, und i-flow übernimmt die Anreicherung von OT- mit SAP-Daten.

 

Wartungsdaten & Instandhaltung (SAP EAM)

Zustandsbasierte Wartung erfordert, dass Maschinensignale in konkrete Instandhaltungsprozesse übersetzt werden.

1. Zustandsdaten → i-flow Edge → UNS: Sensordaten werden kontinuierlich erfasst und im UNS gesammelt.
2. Bewertung auf der Edge: i-flow Edge erkennt Schwellwertverletzungen oder Anomalien und erzeugt Wartungsereignisse (z. B. ConditionThresholdExceeded).
3. UNS → SAP EAM (OData/BAPI): i-flow stößt auf Basis dieser Events gezielt SAP-EAM-Objekte an (Messbeleg, Meldung, Auftrag).

Worauf es ankommt: SAP reagiert auf bewertete Ereignisse, nicht auf Rohsensorik

 

Fazit

In der Produktion gibt es selten eine „one-size-fits-all“-Integration. Stattdessen entsteht eine belastbare Architektur durch eine bewusste Kombination von SAP Schnittstellen je Datenfluss: Stammdaten werden häufig paketiert und robust synchronisiert (z. B. IDoc oder API), Bewegungsdaten transaktionssicher verbucht (OData oder BAPI), und Ereignisse über Broker-Mechanismen verteilt (Event Mesh/UNS). In modernen UNS-Architekturen bedeutet das konkret: Events dienen als Integrationsrückgrat, während SAP über APIs/BAPIs gezielt nur die geschäftsrelevanten Zustandsänderungen übernimmt. Welche Variante passt, entscheidet sich entlang klarer Kriterien – Latenzbedarf, Datenvolumen, Kopplungsgrad und Betriebsmodell (Cloud/On-Prem).