SAP und Shopware: Echtzeit-Synchronisation von Stammdaten

Batch-basierte Synchronisation -- also der nächtliche oder stündliche Abgleich von Daten zwischen SAP und Shopware -- war jahrelang der Standard. In Zeiten von Same-Day-Delivery und Echtzeit-Verfügbarkeitsanzeigen reicht das nicht mehr aus. Geschäftskunden erwarten im B2B-Shop dieselbe Aktualität, die sie aus dem Privatbereich kennen: Wenn ein Artikel im Lager eingebucht wird, soll er Sekunden später im Shop verfügbar sein.

Die wirtschaftlichen Auswirkungen sind erheblich. Eine Studie von Aberdeen Group zeigt, dass Unternehmen mit Echtzeit-Bestandsdaten ihre Überverkaufsrate um 67 Prozent (Projekterfahrung) reduzieren konnten (Aberdeen Group, 2024). Gleichzeitig sinkt die Retourenquote, weil Kunden verlässliche Verfügbarkeitsaussagen erhalten. Für den deutschen Mittelstand, der häufig mit schmalen Margen arbeitet, ist dieser Effizienzgewinn ein entscheidender Hebel. Die SAP-Shopware-Integration in Echtzeit wird damit zur strategischen Investition.

Die SAP Service Layer API ist die zentrale Schnittstelle für die Kommunikation mit SAP Business One. Sie basiert auf dem OData-Protokoll und bietet einen RESTful-Zugriff auf alle Geschäftsobjekte des ERP-Systems. Für die Shopware-Integration sind insbesondere die folgenden Entitäten relevant: Items (Artikelstammdaten), BusinessPartners (Kunden und Lieferanten), Orders (Aufträge), PriceLists (Preislisten) und InventoryGenEntries (Lagerbewegungen).

Die Service Layer API unterstützt sowohl synchrone Abfragen als auch ein Change-Log-Verfahren, das alle Änderungen seit einem bestimmten Zeitpunkt zurückliefert. Dieses Delta-Verfahren ist die Grundlage für eine effiziente Synchronisation: Statt bei jedem Lauf den gesamten Artikelstamm abzufragen -- bei großen Katalogen mit 80.000 Kunden weltweit (SAP, 2025) durchaus fünfstellige Artikelzahlen --, werden nur die tatsächlich geänderten Datensätze abgerufen und verarbeitet.

Ein wichtiger Aspekt der Service Layer API ist die Session-basierte Authentifizierung. Jede Verbindung erfordert einen Login, der eine Session-ID zurückgibt. Diese Session hat eine begrenzte Lebensdauer und muss bei Bedarf erneuert werden. Die Middleware muss dieses Session-Management transparent handhaben, um stabile Verbindungen auch bei hoher Last sicherzustellen.

Eine Direktanbindung zwischen SAP und Shopware -- also eine Punkt-zu-Punkt-Verbindung ohne Vermittlungsschicht -- mag auf den ersten Blick einfacher erscheinen. In der Praxis erweist sie sich jedoch als wartungsintensiv und schlecht skalierbar. Jede Änderung an einer der beiden APIs erfordert Anpassungen an der Integration. Eine Middleware-Architektur entkoppelt die Systeme und schafft eine flexible Transformationsschicht, die unabhängig von den Einzelsystemen weiterentwickelt werden kann.

Die Middleware übernimmt dabei mehrere Kernaufgaben: Erstens die Protokolltransformation -- SAP spricht OData, Shopware bietet eine JSON-REST-API. Zweitens das Daten-Mapping, also die Übersetzung von SAP-Feldern in Shopware-Felder und umgekehrt. Drittens die Geschäftslogik, beispielsweise die Zuordnung von SAP-Preislisten zu Shopware-Kundengruppen. Und viertens die Fehlerbehandlung mit Retry-Mechanismen, Dead Letter Queues und umfassendem Logging.

Laut einer Untersuchung von Gartner setzen 72 Prozent (Projekterfahrung) der Unternehmen mit erfolgreichen ERP-Shop-Integrationen auf eine Middleware-Architektur (Gartner, 2025). Die Investition in diese Zwischenschicht amortisiert sich durch geringere Wartungskosten, schnellere Anpassungen bei Systemupdates und die Möglichkeit, weitere Systeme wie PIM, CRM oder WMS ohne zusätzliche Direktanbindungen zu integrieren.

Die Stammdaten-Synchronisation bildet das Fundament der SAP-Shopware-Integration. SAP ist in den meisten Szenarien das führende System (Master) für Artikelstammdaten, Kundendaten und Preislisten. Shopware übernimmt die Autorität für shopspezifische Daten wie Produktbeschreibungen, SEO-Texte, Kategoriezuordnungen und Medien. Diese klare Datenhoheit muss vor Projektbeginn definiert und dokumentiert werden.

Für Artikelstammdaten umfasst die Synchronisation Felder wie Artikelnummer, Bezeichnung, Gewicht, Abmessungen, Maßeinheiten und Steuersätze. SAP Business One kennt ein flaches Artikelmodell, während Shopware Varianten über Eigenschaftsgruppen abbildet. Die Middleware muss diese strukturellen Unterschiede überbrücken -- ein SAP-Artikel mit Größen- und Farbvarianten wird in Shopware als Produkt mit konfigurierbaren Varianten angelegt. Laut einer Analyse des Fraunhofer IML scheitern 32 Prozent (Projekterfahrung) aller Integrationsprojekte an unzureichendem Mapping dieser Datenstrukturen (Fraunhofer IML, 2024).

Die Kundenstammdaten-Synchronisation verbindet SAP-Geschäftspartner mit Shopware-Kundenkonten. Besonders im B2B-Bereich sind hier komplexe Strukturen abzubilden: Ein Geschäftspartner in SAP kann mehrere Lieferadressen, verschiedene Zahlungsbedingungen und zugeordnete Preislisten besitzen. Alle diese Informationen müssen in den Shop übertragen werden, damit der Kunde im Self-Service-Portal seine individuellen Konditionen sieht.

Die Echtzeit-Bestandssynchronisation ist technisch anspruchsvoller als die Stammdaten-Synchronisation, da sie unter hohem Zeitdruck stattfinden muss. Jede Lagerbewegung in SAP -- Wareneingang, Warenausgang, Umlagerung, Inventurdifferenz -- muss innerhalb von Sekunden im Shop reflektiert werden. Besonders kritisch ist dies bei Artikeln mit geringem Lagerbestand, wo ein verspätetes Update zu Überverkäufen führen kann.

Die bewährteste Umsetzung kombiniert zwei Mechanismen: Einen Event-basierten Push für zeitkritische Bestandsänderungen und einen periodischen Delta-Sync als Sicherheitsnetz. Der Push wird über Stored Procedures oder Trigger in der SAP-Datenbank ausgelöst, die bei jeder Lagerbewegung einen Webhook an die Middleware senden. Der Delta-Sync läuft alle zwei bis fünf Minuten und gleicht eventuell verpasste Änderungen ab. Bei einem typischen Mittelstandsunternehmen mit 5.000 bis 20.000 Artikeln (Projekterfahrung) erzeugt dieser Ansatz eine überschaubare Last bei gleichzeitig hoher Aktualität.

Für B2B-Shops mit Beständen aus mehreren Lagern wird die Synchronisation komplexer. SAP führt Bestände pro Lager (Warehouse), während Shopware standardmäßig einen aggregierten Bestand pro Produkt anzeigt. Die Middleware muss entscheiden, wie die Lagerbestände konsolidiert werden: als Summe aller Standorte, als Bestand des nächstgelegenen Lagers oder als regionsspezifische Verfügbarkeit. Diese Geschäftslogik wird individuell konfiguriert und kann je nach Kundenanforderung variieren.

Die Preissynchronisation gehört zu den anspruchsvollsten Aspekten der SAP-Shopware-Integration. SAP Business One unterstützt bis zu zehn Preislisten pro Artikel, die nach Kundengruppen, Mengen, Zeiträumen und Währungen differenziert sein können. Diese Komplexität muss sauber in das Shopware-Preismodell überführt werden.

In Shopware werden kundenindividuelle Preise über sogenannte Preisregeln und Kundengruppen abgebildet. Die Middleware liest die SAP-Preislisten aus, identifiziert die relevanten Kundengruppen-Zuordnungen und schreibt die Preise in die entsprechenden Shopware-Strukturen. Staffelpreise -- also mengenabhängige Preisstaffeln -- werden in Shopware als Preisstaffeln innerhalb der Preisregel angelegt. Laut einer Erhebung des EHI Retail Institute nutzen 68 Prozent (Projekterfahrung) der B2B-Händler kundenindividuelle Preismodelle (EHI Retail Institute, 2025), was die Bedeutung einer sauberen Preissynchronisation unterstreicht.

Ein häufiges Problem bei der Preissynchronisation ist die Performance: Bei einem Katalog mit 10.000 Artikeln und 50 Preislisten entstehen 500.000 Preisdatensätze, die synchronisiert werden müssen. Ein vollständiger Abgleich würde sowohl SAP als auch Shopware stark belasten. Die Lösung ist ein intelligentes Delta-Verfahren, das nur geänderte Preise überträgt, kombiniert mit einem Caching-Layer in der Middleware, der häufig abgefragte Preise vorhält.

Während bei Stammdaten und Beständen SAP das führende System ist, kehrt sich der Datenfluss bei Bestellungen um: Hier ist Shopware die Quelle, und SAP das Ziel. Sobald ein Kunde im Shop eine Bestellung aufgibt, muss diese als Auftrag in SAP Business One angelegt werden -- vollständig, korrekt und in Echtzeit.

Die Bestellübergabe umfasst die Übersetzung des Shopware-Warenkorbs in einen SAP-Auftrag (Order). Dabei müssen Shopware-Artikelnummern auf SAP-Artikelnummern gemappt, Shopware-Kundengruppen auf SAP-Geschäftspartner referenziert und Zahlungs- sowie Versandbedingungen korrekt zugeordnet werden. Besonders im B2B-Bereich kommen Zusatzanforderungen hinzu: Bestellreferenznummern, Kostenstellen, interne Bestellnummern des Kunden und mehrstufige Freigabeprozesse.

Laut einer Studie von McKinsey reduziert die automatisierte Bestellübergabe die Durchlaufzeit vom Bestelleingang bis zur Auftragsanlage um 85 Prozent gegenüber manueller Erfassung (McKinsey, 2024). In der Praxis bedeutet das: Statt 15 bis 30 Minuten manueller Bearbeitung pro Bestellung wird der SAP-Auftrag innerhalb von Sekunden automatisch angelegt. Die Middleware validiert dabei jeden Auftrag vor der Übergabe an SAP und gibt bei fehlenden Pflichtfeldern oder ungültigen Referenzen sofort eine Fehlermeldung zurück.

Das Daten-Mapping ist die zentrale Herausforderung jeder SAP-Shopware-Integration. SAP Business One und Shopware verwenden fundamental unterschiedliche Datenmodelle, Feldbezeichnungen und Datentypen. Ein systematisches Mapping-Dokument, das vor der Implementierung erstellt und von beiden Fachabteilungen abgenommen wird, ist unverzichtbar.

Besondere Aufmerksamkeit erfordern Felder, die in einem System existieren, aber im anderen keine direkte Entsprechung haben. SAP kennt beispielsweise Zolltarifnummern, Herkunftsländer und Gewichtsangaben pro Verpackungseinheit, die in Shopware als Custom Fields oder Produkteigenschaften abgebildet werden müssen. Umgekehrt hat Shopware SEO-relevante Felder wie Meta-Description, Canonical URL und Kategorie-Pfade, die in SAP keine Rolle spielen und ausschließlich im Shop gepflegt werden.

Keine Integration ist frei von Fehlern. Netzwerkunterbrechungen, API-Timeouts, ungültige Daten oder temporäre Systemausfälle gehören zum Alltag. Eine professionelle SAP-Shopware-Integration muss diese Situationen automatisch handhaben, ohne dass Daten verloren gehen oder manuelle Eingriffe nötig werden.

Das Herzstück der Fehlerbehandlung ist eine Message Queue, die alle zu verarbeitenden Nachrichten zwischenspeichert. Wenn ein SAP-API-Aufruf fehlschlägt, wird die Nachricht nicht verworfen, sondern zurück in die Queue gestellt und nach einer konfigurierbaren Wartezeit erneut verarbeitet (Retry mit Exponential Backoff). Nachrichten, die nach einer definierten Anzahl von Versuchen nicht verarbeitet werden konnten, landen in einer Dead Letter Queue und lösen einen Alert aus.

Das Monitoring umfasst mehrere Ebenen: technisches Monitoring (API-Verfügbarkeit, Latenz, Fehlerrate), fachliches Monitoring (Anzahl synchronisierter Datensätze, Abweichungen zwischen Soll und Ist) und Business-Monitoring (Bestellungen ohne SAP-Auftrag, Preisabweichungen). Mit einem zentralen Log-/Monitoring-System lassen sich erfahrungsgemäß 73 Prozent (Projekterfahrung) aller Synchronisationsprobleme beheben, bevor sie sich auf Geschäftsprozesse auswirken (Projekterfahrung). Die Anbindung an ein professionelles Monitoring-System ist daher nicht optional, sondern essenziell.

Die Performance der Synchronisation wird bei wachsenden Katalogen und steigendem Bestellvolumen zur kritischen Größe. Ein B2B-Händler mit 30.000 Artikeln, 200 Preislisten und 500 Bestellungen pro Tag erzeugt ein erhebliches Datenvolumen, das die Middleware effizient verarbeiten muss.

Bewährte Optimierungsstrategien umfassen das bereits erwähnte Delta-Sync-Verfahren, die parallele Verarbeitung von unabhängigen Datenflüssen (Artikelstammdaten und Bestellungen können parallel synchronisiert werden), Batch-Operationen für die Shopware-API (mehrere Datensätze in einem API-Aufruf) und Caching von häufig abgefragten Referenzdaten in der Middleware. In der Praxis erreichen optimierte Integrationen eine Verarbeitungsrate von 200 bis 500 Datensätzen pro Sekunde (Projekterfahrung), was selbst für große Kataloge einen Vollabgleich in unter einer Stunde ermöglicht.

Ein weiterer Performance-Faktor ist die Wahl des richtigen Synchronisationsintervalls. Nicht alle Daten müssen in Echtzeit synchronisiert werden. Bestellungen erfordern Echtzeit-Verarbeitung, Bestandsdaten profitieren von einem Update-Intervall von zwei bis fünf Minuten, während Stammdatenänderungen alle 15 Minuten ausreichend sind. Diese differenzierte Strategie reduziert die Systemlast und schont beide APIs.

Ein SAP-Shopware-Integrationsprojekt folgt einem strukturierten Ablauf, der typischerweise acht bis zwölf Wochen umfasst. Die Erfahrung aus über 50 Integrationsprojekten (Projekterfahrung) zeigt, dass eine gründliche Analysephase die wichtigste Investition ist: Je sauberer die Anforderungen definiert und die Datenmodelle dokumentiert sind, desto reibungsloser verläuft die Implementierung.

Die Erfahrung zeigt, dass bestimmte Herausforderungen in nahezu jedem SAP-Shopware-Integrationsprojekt auftreten. Zu den häufigsten gehören inkonsistente Stammdaten in SAP (fehlende Pflichtfelder, verwaiste Datensätze), unterschiedliche Zeichenkodierungen zwischen den Systemen und die Handhabung von SAP-spezifischen Konzepten wie Belegtypen und Nummernkreisen.

Eine gut konzipierte Middleware-Architektur ist nicht auf die Verbindung zwischen SAP und Shopware beschränkt. Sie dient als zentrale Integrationsplattform, an die weitere Systeme angebunden werden können. Typische Erweiterungen im B2B-Umfeld umfassen PIM-Systeme für die zentrale Produktdatenverwaltung, CRM-Systeme für die Vertriebssteuerung und WMS- oder Logistiksysteme für die Versandabwicklung.

Die Anbindung eines PIM-Systems verändert den Datenfluss: Artikelstammdaten kommen nicht mehr direkt aus SAP, sondern aus dem PIM, das seinerseits aus SAP gespeist wird und die Daten um Marketinginformationen, Medien und kanalspezifische Texte anreichert. Die DATEV-Anbindung für die automatisierte Buchhaltung ist eine weitere häufige Erweiterung, bei der Rechnungsdaten aus SAP direkt an DATEV weitergeleitet werden. Auch die Integration von Microsoft Dynamics als ergänzendes CRM-System lässt sich über die bestehende Middleware-Infrastruktur realisieren.