SAP Daten integrieren mit klarer Architektur

Ein Außendienst sieht einen anderen Auftragsstatus als der Innendienst. Ein Kundenportal meldet verfügbare Ware, obwohl sie bereits reserviert ist. Und eine Freigabe bleibt liegen, weil Daten zwischen SAP, CRM und einer individuell entwickelten Anwendung nur einmal pro Nacht abgeglichen werden. Wer SAP Daten integrieren möchte, löst deshalb nicht nur eine technische Schnittstellenaufgabe. Es geht darum, Geschäftsprozesse verlässlich über Systemgrenzen hinweg abzubilden.

Gerade bei wachsenden Organisationen ist SAP häufig das führende System für zentrale Geschäftsobjekte: Kunden, Materialien, Aufträge, Preise, Bestände, Rechnungen oder Kostenstellen. Gleichzeitig entstehen digitale Produkte und Fachanwendungen außerhalb von SAP - etwa Kundenportale, B2B-Shops, mobile Apps, Planungswerkzeuge oder KI-gestützte Assistenzsysteme. Der Nutzen entsteht erst, wenn diese Systeme die richtigen Daten zur richtigen Zeit erhalten und Änderungen kontrolliert zurückspielen können.

SAP Daten integrieren beginnt mit dem Geschäftsprozess

Die entscheidende Frage lautet nicht: Welche Schnittstelle ist verfügbar? Sie lautet: Welcher Prozess soll für welche Rolle schneller, sicherer oder automatisiert funktionieren? Ein Ersatzteilportal benötigt beispielsweise nicht das gesamte SAP-Datenmodell. Es braucht verlässliche Verfügbarkeiten, kundenspezifische Preise, Auftragsstatus und eine Möglichkeit, Bestellungen eindeutig anzulegen. Ein Dispositionscockpit benötigt dagegen aktuelle Bedarfe, Bestände und Liefertermine, aber keine vollständigen Rechnungsdaten.

Diese fachliche Abgrenzung reduziert Komplexität. Sie verhindert, dass eine neue Anwendung direkt an Tabellen, Transaktionen oder interne Logik gekoppelt wird, die sich bei einem Release ändern kann. Gleichzeitig schafft sie eine klare Antwort auf die Frage nach der Datenhoheit: Welches System darf Daten lesen, welches darf sie ändern und welches führt bei Konflikten?

In vielen Vorhaben bleibt SAP für kaufmännische und operative Kernprozesse führend. Das angeschlossene System ergänzt die Benutzerführung, bündelt Informationen oder automatisiert Teilschritte. Es sollte nicht unbemerkt eigene Wahrheiten für Bestände, Preise oder Auftragsdaten erzeugen. Dieser Grundsatz ist besonders relevant, wenn mehrere Vertriebskanäle, Gesellschaften oder Lager angebunden werden.

Die passende Integrationsarchitektur wählen

SAP bietet je nach eingesetztem System und Prozess unterschiedliche Integrationswege. In SAP S/4HANA stehen häufig APIs auf Basis von OData oder REST zur Verfügung. Auch SOAP-Webservices, IDocs, RFC-Verbindungen, Dateischnittstellen oder Ereignisse können sinnvoll sein. Keines dieser Verfahren ist pauschal das richtige. Entscheidend sind Aktualität, Datenvolumen, Fehlertoleranz, Sicherheitsanforderungen und die erwartete Weiterentwicklung.

Synchron oder ereignisbasiert?

Eine synchrone API-Anfrage passt, wenn eine Anwendung eine direkte Antwort benötigt. Wird im Kundenportal eine Bestellung ausgelöst, muss das Portal beispielsweise erkennen, ob der Auftrag angenommen wurde und welche Belegnummer entstanden ist. Der Nachteil: Die Verfügbarkeit und Antwortzeit von SAP beeinflussen unmittelbar das Nutzererlebnis.

Ereignisbasierte Integration entkoppelt Systeme stärker. Ändert sich ein Lieferstatus oder wird ein Auftrag freigegeben, kann SAP ein Ereignis auslösen. Eine Integrationsschicht verteilt die Information an Portal, App, Data Platform oder Benachrichtigungsservice. Das erhöht die Widerstandsfähigkeit und eignet sich für Prozesse, bei denen wenige Sekunden Verzögerung akzeptabel sind. Dafür braucht es ein sauberes Konzept für doppelte Nachrichten, Reihenfolgen und Wiederholungen.

Für große Datenmengen oder seltene Abgleiche kann ein geplanter Batch-Export die wirtschaftlichere Wahl sein. Stammdaten, historische Belege oder Reporting-Daten müssen nicht immer in Echtzeit fließen. Echtzeit dort einzusetzen, wo ein nächtlicher oder stündlicher Abgleich genügt, erzeugt Kosten und Betriebsrisiken ohne geschäftlichen Mehrwert.

Eine Integrationsschicht schützt beide Seiten

Direkte Punkt-zu-Punkt-Verbindungen wirken anfangs schnell umgesetzt. Mit jeder weiteren Anwendung steigt jedoch die Zahl der Abhängigkeiten. Änderungen am SAP-System, am Datenmodell oder an Berechtigungen werden dann teuer, weil mehrere Anbindungen gleichzeitig betroffen sind.

Eine dedizierte Integrationsschicht - etwa als Backend-Service oder API-Gateway - übersetzt fachliche Anforderungen in stabile Endpunkte für angebundene Anwendungen. Sie kann SAP-spezifische Felder und Protokolle kapseln, Antworten vereinheitlichen, Zugriffe prüfen und Fehler zentral behandeln. Für ein Portal kann daraus etwa ein verständlicher Endpunkt für „Bestellung anlegen“ werden, obwohl im Hintergrund mehrere SAP-Aufrufe, Validierungen und Freigabelogiken zusammenspielen.

Das bedeutet nicht, dass jede Integration eine große Plattform benötigt. Bei einer klar abgegrenzten Anwendung mit wenigen Datenobjekten kann ein schlanker Service ausreichend sein. Sobald mehrere Kanäle, Partner oder Fachsysteme beteiligt sind, zahlt sich eine bewusst geplante Entkopplung meist aus.

Datenqualität und Verantwortlichkeiten früh klären

Technisch erfolgreiche Übertragungen garantieren noch keinen funktionierenden Prozess. Häufig liegen die eigentlichen Probleme in uneinheitlichen Kundenkennungen, fehlenden Pflichtfeldern, abweichenden Mengeneinheiten oder nicht gepflegten Stammdaten. Eine Schnittstelle überträgt diese Probleme lediglich schneller.

Vor der Umsetzung sollten Teams für jedes relevante Objekt festlegen, welche Felder übertragen werden, welche fachlichen Regeln gelten und wie Fehler bearbeitet werden. Dazu gehören eindeutige Schlüssel, Wertebereiche, Zustände und die Behandlung von Löschungen. Bei Kunden- oder Ansprechpartnerdaten muss außerdem feststehen, welche Daten tatsächlich erforderlich sind und wie lange sie außerhalb von SAP vorgehalten werden dürfen.

Besonders kritisch sind Schreibzugriffe. Darf ein Portal einen Auftrag direkt anlegen? Werden Änderungen zunächst als Entwurf gespeichert und erst nach Prüfung übertragen? Was passiert, wenn ein Nutzer auf „Absenden“ klickt, die Verbindung abbricht und die Anfrage erneut gesendet wird? Idempotente Schnittstellen, eindeutige Korrelations-IDs und nachvollziehbare Statusmeldungen verhindern doppelte Belege und langwierige Klärungsfälle.

Sicherheit und Betrieb sind Teil der Integration

SAP-Integration wird produktionskritisch, sobald Anwendungen operative Prozesse auslösen. Daher gehören Berechtigungskonzepte, Verschlüsselung, Protokollierung und Monitoring von Beginn an zur Architektur. Ein technischer Nutzer sollte nur die Rechte erhalten, die für seinen konkreten Prozess nötig sind. Zugangsdaten dürfen nicht im Quellcode oder in Konfigurationsdateien liegen, die unkontrolliert verteilt werden.

Ebenso wichtig ist die Beobachtbarkeit im Betrieb. Fachbereiche benötigen nicht nur eine technische Fehlermeldung, sondern Klarheit darüber, welcher Auftrag, welche Kundennummer oder welches Ereignis betroffen ist. Gute Integrationen erfassen daher strukturierte Logs, fachliche Statuswerte und Metriken zu Laufzeiten, Fehlerquoten und Warteschlangen. Alarmierungen müssen zwischen einem kurzzeitigen Ausfall und einem echten Geschäftsrisiko unterscheiden.

Auch das Deployment verdient Aufmerksamkeit. Werden SAP und die angebundene Anwendung unabhängig veröffentlicht, müssen Schnittstellen versioniert werden. Eine API sollte nicht brechen, nur weil ein optionales Feld ergänzt oder eine interne Zuordnung angepasst wurde. Testsysteme mit realitätsnahen, datenschutzgerecht aufbereiteten Daten helfen, kritische Fälle vor dem Go-live zu erkennen.

So wird aus einer Schnittstelle ein belastbares Vorhaben

Ein tragfähiges Integrationsprojekt startet mit einem gemeinsamen Blick auf Prozesse, Daten und Verantwortlichkeiten. Im ersten Schritt werden die konkreten Anwendungsfälle priorisiert: Welche Daten und Funktionen schaffen den größten Nutzen, welche Abhängigkeiten bestehen und welche Risiken sind akzeptabel? Daraus entsteht ein fachlicher Schnittstellenvertrag, nicht nur eine Liste technischer Felder.

Danach folgt ein technischer Architekturentscheid. Dabei werden SAP-Version, vorhandene APIs, Authentifizierung, Netzwerkgrenzen, Cloud-Umgebung und Betriebsmodell berücksichtigt. Erst dann lohnt sich die detaillierte Umsetzung. Ein sinnvoller erster Release konzentriert sich auf einen klar messbaren Prozess, etwa Auftragserfassung oder Statusauskunft. Er liefert früh Erkenntnisse über Datenqualität, Lastverhalten und Akzeptanz.

Für langfristige Vorhaben ist eine gemeinsame Betriebsverantwortung entscheidend. Fachliche Änderungen, SAP-Releases, neue Vertriebskanäle und wachsende Datenmengen verändern die Anforderungen kontinuierlich. Ein Technologiepartner wie entrecode kann dabei nicht nur die Anwendung entwickeln, sondern Architektur, Betrieb und Weiterentwicklung als zusammenhängende Aufgabe begleiten.

Typische Fehler vermeiden

Der häufigste Fehler ist, SAP als reine Datenbank zu behandeln. Direkte Tabellenzugriffe mögen kurzfristig funktionieren, umgehen aber häufig Geschäftslogik, Berechtigungen und Upgrade-Sicherheit. Stabiler sind freigegebene Schnittstellen und klar dokumentierte Services.

Problematisch ist auch die Annahme, dass jede Information sofort verfügbar sein muss. Echtzeit sollte dort eingesetzt werden, wo sie Entscheidungen oder Transaktionen tatsächlich verbessert. Für Reporting, Analysen oder große Stammdatenmengen ist ein zeitversetzter Abgleich oft günstiger und zuverlässiger.

Schließlich scheitern Integrationen oft an unklaren Ausnahmefällen. Ein Happy Path reicht nicht aus. Stornierungen, Teilmengen, gesperrte Kunden, Preisänderungen, fehlende Berechtigungen und temporär nicht erreichbare Systeme gehören von Anfang an in Tests und Prozessdesign.

Die beste SAP-Integration ist nicht die mit den meisten Schnittstellen. Sie ist diejenige, die einen geschäftskritischen Ablauf nachvollziehbar beschleunigt, Verantwortlichkeiten klar hält und auch nach dem nächsten Release beherrschbar bleibt.