Magento SAP Schnittstelle für IT-Verantwortliche

Wer SAP im Unternehmen einsetzt und einen Magento-Onlineshop anbinden möchte, steht schnell vor einer Reihe grundlegender Fragen. Welche Daten benötigt Magento aus SAP? Welche Informationen fließen zurück? Welches System ist führend? Wie werden Preise, Bestände, Kunden und Bestellungen behandelt? Und was passiert, wenn eines der Systeme vorübergehend nicht erreichbar ist?

Eine Magento-SAP-Schnittstelle besteht in der Praxis meist aus mehreren Datenflüssen und Prozessen. Produktdaten können aus SAP zum Shop übertragen werden, Bestellungen gehen in die andere Richtung. Preise, Bestände, Kundeninformationen, Lieferstatus und Rechnungsinformationen können zusätzliche Schnittstellen benötigen.

Für IT-Verantwortliche ist daher zunächst wichtig, Magento fachlich und technisch in die vorhandene SAP-Systemlandschaft einzuordnen.

Was ist Magento aus Sicht eines SAP-Verantwortlichen?

Magento 2 ist eine E-Commerce-Plattform. In diesem Beitrag liegt der Schwerpunkt auf Magento Open Source.

Magento kann (aber muss) nicht verwalten unter anderem:

• Produkte und Produktvarianten
• Kategorien
• Preise und Preisregeln
• Kundenkonten
• Warenkörbe
• Bestellungen
• Rechnungen innerhalb des Shopprozesses
• Gutschriften
• Lieferungen
• Lager- und Bestandsinformationen
• Websites, Stores und Store Views (Sprachen aber auch "Mulitstore")

Dazu bietet Magento umfangreiche Web-APIs. Über REST können externe Systeme beispielsweise Produkt-, Kunden-, Preis-, Bestands- und Bestelldaten lesen oder bearbeiten.

Auch individuelle Magento-Erweiterungen können zusätzliche API-Funktionen bereitstellen, wenn die vorhandenen Schnittstellen einen speziellen Geschäftsprozess nicht vollständig abdecken.

Die Magento API ist sehr mächtig. Es ist z.B. möglich einen kompletten Auftragsprozess über REST mit Quote(Warenkorb), Bestellung, Rechnung und Lieferung per Rest-API zu steuern bzw. anzulegen. Bedeutet jeder einzelne Schritt kann über Rest-API in Magento mit Daten befüllt werden und/oder der Status geändert werden.

Für ein SAP-Team bedeutet das zunächst: Magento ist mehr als eine Oberfläche für SAP-Daten. Innerhalb des Shops existieren eigene Geschäftsobjekte und Prozesse, die beim Schnittstellenkonzept berücksichtigt werden müssen.

Sie müssen keine Magento-Fachleute werden, aber es ist deutlich mehr (möglich) als nur z.B. Bestände aktualisieren. Ein enger Austausch insbesondere zu Beginn ist unserer Erfahrung hilfreich und nötig.

Welches SAP-System soll mit Magento verbunden werden?

Die Bezeichnung „Magento SAP Schnittstelle“ beschreibt noch keine konkrete technische Lösung. Bereits auf SAP-Seite können sehr unterschiedliche Voraussetzungen bestehen. Relevant sind beispielsweise:

• SAP S/4HANA
• ältere SAP-ECC-Installationen
• SAP S/4HANA Cloud
• SAP Business One
• vorhandene Middleware
• SAP Integration Suite
• bestehende IDoc-Prozesse
• OData-Schnittstellen
• SOAP-Webservices
• unternehmensspezifische Eigenentwicklungen

Wir sind keine SAP-Experten sondern kennen uns "nur" mit der Magento Rest-API sehr gut aus. Daher hier nur allgemeine Informationen bzw. klären Sie diese mit Ihrem SAP-Betreuuer im Detail.

Bei SAP S/4HANA stehen scheinbar beispielsweise APIs für Produktstammdaten zur Verfügung. Die aktuelle Product API unterstützt CRUD-Operationen über OData V4. SAP stellt zudem APIs für Business-Partner-Daten bereit. Vor der Architekturentscheidung sollten daher mindestens SAP-Version, Betriebsmodell, vorhandene Integrationsplattform und bereits genutzte Schnittstellen bekannt sein.

Eine bestehende und bewährte Integrationsarchitektur sollte in die Planung einbezogen werden. Wenn im Unternehmen bereits zahlreiche Systeme über eine zentrale Middleware mit SAP kommunizieren, spricht vieles dafür, auch Magento in dieses Konzept einzuordnen.

Wir selbst (KonVis) sind darauf angewiesen, dass auf Kundenseite jemand ist, der ein tiefes Verständnis des eingesetzten SAP hat. Die Kommunikation der Systeme läuft zu 100% losgelöst von den Systemen rein über Rest-API. Jedoch sind auf beiden Seiten tiefe Verständnis der Prozess und Daten nötig, sodass die Systeme überhaupt zusammenspielen können.

Welche Daten werden typischerweise zwischen SAP und Magento ausgetauscht?

Eine SAP-Anbindung sollte in einzelne Datenobjekte zerlegt werden. Die Umsetzung selbst sollte idealerweise in Stufen erfolgen.

Eine typische Zuordnung könnte folgendermaßen aussehen:

Daten	Typische Richtung	Beispiel
Artikelnummer	SAP → Magento	SAP-Materialnummer wird Magento-SKU
Produktstammdaten	SAP → Magento	Maße, Gewicht, Status
Produkttexte	SAP/PIM → Magento	Name, Kurz- und Langbeschreibung
Preise	SAP → Magento	Basispreise, Kundenpreise
Bestände	SAP → Magento	verfügbare Mengen
Kunden	Magento ↔ SAP	Kundenkonto und Business Partner
Bestellung	Magento → SAP	Auftrag aus dem Onlineshop
SAP-Auftragsnummer	SAP → Magento	Referenz für weitere Prozesse
Auftragsstatus	SAP → Magento	Bearbeitung, Versand
Lieferung	SAP → Magento	Tracking und Lieferinformationen
Rechnung	SAP → Magento	falls Rechnungen aus SAP bereitgestellt werden
Retoure/Gutschrift	abhängig vom Prozess	Rückgabe und finanzielle Korrektur

Die tatsächliche Lösung kann erheblich davon abweichen.

Ein Unternehmen verwaltet möglicherweise Produkttexte vollständig in Magento. Ein anderes setzt ein PIM ein. Manche Shops übernehmen nur Bestände und Basispreise aus SAP. Im B2B-Bereich können zusätzlich individuelle Kundenpreise, Kundensortimente oder besondere Verkaufseinheiten hinzukommen.

Es ist auch problemlos möglich es stückweise auszubauen. Die Produkttexte und insbesondere Kategorie-Zuordnung wird z.B. zunächst in Magento verwaltet. Wenn wichtigere Dinge die Bestandsupdates fehlerfrei funktionieren und produktiv sind, wird als nächster Schritt z.B. Produkttexte per Schnittstelle gepflegt.

Deshalb sollte das Schnittstellenprojekt mit einer Liste der benötigten Datenobjekte beginnen. Es muss schlicht klar sein auf was man fokussiert, wie man was evtl. (händisch) weiter pflegt und ob/wo evtl. z.B. "Excel-Imports" oder ähnliches (für die ersten Stufen ausreichend sind).

Welches System soll für welche Daten führend sein?

Datenhoheit gehört zu den wichtigsten Entscheidungen einer Magento-SAP-Anbindung. Die Frage welches System führend ist, kommt fast immer. Diese lässt sich aber nicht beantworten, da es üblicherweise erst auf Level des jeweiligen Datenobjektes definiert wird. In den seltensten Fällen ist ein System komplett führend bei allen Daten.

Für jedes Datenobjekt sollte festgelegt werden:

• Wo entsteht die Information
• Wo wird sie gepflegt ?
• Welches System darf sie ändern?
• Welche anderen Systeme erhalten lediglich eine Kopie?
• Was geschieht bei widersprüchlichen Daten?

Das Ganze wird dann üblicherweise noch erweitert um die zeitliche Dimension:

Aktuell, Übergangsweise, Zukünftig oder auch "langfristige Ziel"

Ein mögliches Konzept könnte so aussehen:

Datenobjekt	Führendes System
Artikelnummer	SAP (Ausbaustufe 1)
Basispreis	SAP (Ausbaustufe 1)
physischer Lagerbestand	SAP (Ausbaustufe 1)
Webshop-Produktbeschreibung	Magento oder PIM (Ausbaustufe 2)
SEO-Daten	Magento (Ausbaustufe 2)
Kategoriezuordnung	Magento oder PIM (Ausbaustufe 3)
Bestellung im Shop	Magento (Ausbaustufe 1)
interner Auftrag	SAP (Ausbaustufe 4)
Versandstatus	SAP oder Logistiksystem (Ausbaustufe 2)
Kundenlogin	Magento (Ausbaustufe 1)
Business Partner	SAP (Ausbaustufe 5)

Das ist nur ein Beispiel. Die passende Verteilung hängt von der vorhandenen Systemlandschaft ab. Dazu wo welche Daten anfallen und wir kritisch Prozesse sind. Idealerweise startet man mit Dingen die einfach umzusetzen sind, aber idealerweise bereits große Auswirkungen haben.

Sobald die initiale API steht und funktioniert, ist es deutlich einfacher basierend darauf sich an die "harten Nüsse" ranzuwagen. Wer z.B. direkt mit "Erstellung von Bestellungen in Magento aus SAP herraus" startet, wird ein äußerst frustrierende Projekt haben mit X Dingen die nicht funktionieren, geklärt werden müssen usw.

Unklare Datenhoheit führt häufig zu schwer nachvollziehbaren Fehlern. Wird etwa ein Produkttext in Magento geändert und anschließend erneut aus SAP importiert, kann die Änderung überschrieben werden. Dies wird üblicherweise durch so eine Betrachtung direkt gelöst-

Für kritische Daten sollte daher bis auf Feldebene geklärt werden, welches System die maßgebliche Quelle ist. Dazu zählt z.B. die E-Mail oder auch Kundennummer.

Welche Magento-Begriffe sollte ein SAP-Team kennen?

Einige Magento-Konzepte lassen sich nur eingeschränkt auf bekannte SAP-Begriffe übertragen.

SKU (Artikelnummer)

Die SKU ist die zentrale Artikelkennung eines Magento-Produkts.

In vielen Integrationen wird die SAP-Materialnummer als Magento-SKU verwendet. Das ist praktisch, wenn beide Systeme eine identische und dauerhaft stabile Kennung verwenden können.

Simple Product (Standard Produkt)

Ein Simple Product ist ein einzelnes kaufbares Produkt.

Bei Varianten kann beispielsweise jede Größe oder Farbe ein eigenes Simple Product mit eigener SKU darstellen.

Configurable Product (komplexere Produkt)

Ein Configurable Product fasst Varianten für die Darstellung im Shop zusammen.

Ein Hemd könnte im Frontend als ein Produkt erscheinen, während Größen und Farben technisch mehrere Simple Products darstellen.

Diese Struktur ist für das Mapping von SAP-Materialien besonders wichtig.Es gibt jedoch auch Varianten wie Bundle Produkt. Hier ist wichtig sich (wenn relevant) damit zu beschäftigen. Magento kann schlicht mehr als nur "Simple Product"

Attribute (Produkt-Eigenschaften)

Magento verwendet Attribute für Produkteigenschaften wie Farbe, Material, Hersteller oder technische Werte.

Attribute können außerdem für Filter, Varianten und die Darstellung verwendet werden. Die Attribute können unterschiedliche Typen sein wie z.B. ja/nein, Mehrfachauswahl, Textfelder aber auch Bilder, Zahlen und mehr. Das ist für das Mapping entsprechend relevant

Website, Store und Store View

Magento kann mehrere Websites, Stores und Store Views innerhalb einer Installation verwalten.

Diese Struktur ist beispielsweise relevant für:

• mehrere Länder
• unterschiedliche Marken
• verschiedene Sortimente
• unterschiedliche Sprachen
• getrennte B2B- und B2C-Bereiche

Eine direkte Entsprechung zu Verkaufsorganisation, Vertriebsweg oder Sparte in SAP sollte nicht vorausgesetzt werden. Die Zuordnung muss fachlich geplant werden.

Quote (Warenkorb inkl. Inhalt)

Der Quote bildet den Warenkorb beziehungsweise Teile des Checkout-Prozesses ab.

Order (platzierte Bestellung)

Nach Abschluss des Bestellvorgangs entsteht eine Magento Order. Das ist schlicht die platzierte Bestellung. Diese ist die Basis um daraus eine Rechnung, Lieferschein aber auch Gutschrift zu generieren. Alle diese Dokumente sind in Magento untereinander verbunden und separat. Sie hängen nicht(!) von Produkten usw. ab. Alle Daten sind bereits in den Objekten enthalten und Änderung am Produkt ändert (logischerweis) z.B. nicht die Rechnung, Lieferschein, Bestellung usw.

Aus der Bestellung können weitere Magento-Objekte wie Invoice, Shipment und Credit Memo relevant werden. Adobe beschreibt diesen Lebenszyklus auch in der REST-Dokumentation. Das hängt jedoch stark davon ab ob/was im Shop überhaupt verwendet wird. Gutschrift und Lieferschein sind z.B. eher selten.

Source und Stock (Lager und Lagerbestand)

Magento Inventory Management unterscheidet unter anderem zwischen Sources und Stocks.

Eine Source kann einen physischen Lagerort repräsentieren, beispielsweise ein Lager, Ladengeschäft, Distributionszentrum oder einen Dropshipper. Ein Stock verbindet Sources mit Verkaufskanälen und dient der Ermittlung verkaufbarer Mengen.

Diese Magento-Struktur sollte beim Mapping von SAP-Werken, Lagerorten und Beständen berücksichtigt werden.

Wie kommen Magento-Bestellungen nach SAP?

Die Übertragung einer Bestellung gehört zu den häufigsten SAP-Integrationsprozessen.

Ein vereinfachter Ablauf kann so aussehen:

1. Der Kunde schließt seine Bestellung in Magento ab.
2. Magento legt die Order an.
3. Die Schnittstelle (von SAP Seite) erkennt eine neue übertragungsfähige Bestellung.
4. Die benötigten Daten werden validiert und in das SAP-Format überführt.
5. SAP verarbeitet die Daten.
6. SAP bestätigt die erfolgreiche Übernahme.
7. Die SAP-Auftragsnummer wird gespeichert.
8. Weitere Statusinformationen können später an Magento zurückgegeben werden.

Dabei sollten unter anderem folgende Informationen berücksichtigt werden:

• Magento-Bestellnummer
• Kundennummer oder Business Partner (z.B. als neue Kundeneigenschaft in Magento)
• Rechnungsadresse
• Lieferadresse
• Positionen (Produkte)
• SKU beziehungsweise Materialnummer
• Menge
• Preis
• Rabatte
• Steuern
• Versandkosten
• Zahlungsart
• Versandart
• Währung
• Kundenreferenzen (Nicht Magento Standard, aber als neue Eigenschaft der Bestellung in Magento denkbar)
• individuelle Zusatzfelder (üblicherweise Attribute von Produkten, die in die Bestellung übergeben werden z.B. Größen, Gebinde, Zollnummer...)

Für eine belastbare Integration reicht der erfolgreiche Standardfall nicht aus.

Besonders wichtig sind die Fehlerfälle und Sonderfälle.

Was passiert, wenn SAP eine Bestellung nicht übernehmen kann?

Ein typischer Fehlerfall könnte folgendermaßen aussehen:

Der Kunde bestellt erfolgreich um 10:03 Uhr. Magento nimmt die Bestellung an. SAP ist jedoch während der Übertragung um 10:04 Uhr nicht erreichbar.

Die Bestellung darf dadurch nicht verloren gehen.

Ein geeignetes Schnittstellenkonzept muss daher definieren:

• wie fehlgeschlagene Übertragungen erkannt werden
• welches System überhaupt die Daten abholt oder sendet?
• wie oft ein erneuter Versuch erfolgt
• welche Fehler automatisch erneut verarbeitet werden dürfen
• welche Fehler einen manuellen Eingriff benötigen
• wie Doppelübertragungen verhindert werden
• wo Übertragungsstatus gespeichert werden
• wer bei länger anhaltenden Problemen informiert wird

Ähnlich problematisch ist ein Timeout.

Magento sendet eine Bestellung. SAP verarbeitet sie erfolgreich. Die Antwort erreicht Magento aufgrund eines Netzwerkfehlers jedoch nicht.

Wird die Bestellung anschließend ungeprüft erneut übertragen, kann in SAP ein zweiter Auftrag entstehen.

Solche Fälle zeigen, warum Prozesssicherheit, eindeutige Referenzen, Idempotenz und nachvollziehbares Logging früh berücksichtigt werden sollten.

KonVis hat bereits Magento-SAP-Schnittstellen umgesetzt, bei denen unter anderem Error-Handling, Sicherstellung der Übertragung, Cron-Jobs und die Verarbeitung größerer Datenmengen Bestandteil der Lösung waren.

Zentrale Punkt ist schlicht, dass mit Warteschlangen und Statusänderungen gearbeitet werden muss. Es darf z.B. niemals eine SAP Bestellung vom Shop an SAP geschickt werden und wenn es fehlschlägt, dann ist das eben so. Besser sind dort immer Cron Job basierte Verfahren bzw. SAP holt z.B. alle 5 Minuten schlicht die Bestellungen im Shop ab.

Wie werden SAP-Preise in Magento abgebildet?

Preise können zu einem der komplexesten Bereiche einer B2B-Schnittstelle werden. Ein einfaches Modell überträgt einen Basispreis pro Artikel.In der Praxis können weitere Anforderungen hinzukommen:

• Staffelpreise
• Kundengruppenpreise
• individuelle Kundenpreise
• unterschiedliche Preislisten
• Vertragskonditionen
• Sonderpreise
• zeitlich begrenzte Preise
• unterschiedliche Währungen
• Netto- und Bruttopreise
• Mindestmengen
• Verpackungseinheiten

Magento bietet über seine REST-API unter anderem Funktionen für Basis-, Sonder- und Staffelpreise. Tier Prices können beispielsweise nach Kundengruppe, Website und Menge definiert werden.

Damit ist jedoch noch nicht entschieden, wie eine vorhandene SAP-Konditionslogik integriert werden sollte.

Grundsätzlich können beispielsweise unterschiedliche Modelle untersucht werden.

Preise werden nach Magento übertragen

SAP oder eine Middleware berechnet die benötigten Preise und überträgt diese regelmäßig an Magento. Vorteile können kurze Antwortzeiten im Shop und eine geringere Abhängigkeit von SAP während eines Seitenaufrufs sein. Bei sehr vielen kundenindividuellen Preisen kann jedoch eine große Datenmenge entstehen.

Preise werden bei Bedarf ermittelt

Magento fragt den benötigten Preis während eines definierten Prozesses bei SAP oder einem zwischengeschalteten Dienst ab. Damit können sehr aktuelle Preise möglich sein. Gleichzeitig steigen die Anforderungen an Antwortzeit, Verfügbarkeit und Caching. Dazu muss Magento so angepasst werden, dass gewartet wird, bis die Preise abgerufen werden.

Dies ist üblicherweise ausdrücklich NICHT nötig.

Ein hybrides Modell wird verwendet

Standardpreise befinden sich in Magento. Besondere Konditionen werden nur für bestimmte Kunden oder Situationen extern ermittelt. Welches Modell geeignet ist, hängt stark von Preislogik, Kundenzahl, Artikelzahl, Aktualitätsanforderungen und vorhandener SAP-Architektur ab.

Auch hier wird es schnell (unnötig) aufwendig. Idealerweise gibt es maximal Preisgruppen oder feste Rabatte. z.B. Kundengruppe A, B, C und jede der Kundengruppen steht für z.b. -5% -10% und -20% vom Basispreis oder ähnliches.

Welcher Lagerbestand soll im Magento-Shop angezeigt werden?

„Lagerbestand übertragen“ klingt zunächst eindeutig.

Fachlich können jedoch verschiedene Mengen gemeint sein:

• physischer Bestand
• frei verfügbarer Bestand
• bereits reservierte Menge
• Sicherheitsbestand
• zukünftiger Bestand
• verkaufbare Menge
• Bestand eines bestimmten Lagers
• Gesamtbestand mehrerer Lager

Magento Inventory Management unterstützt mehrere Sources. Adobe nennt ausdrücklich ERP-Systeme als mögliche externe Quelle für die Aktualisierung von Source Items.

Eine Source kann beispielsweise ein bestimmtes Lager repräsentieren. Mehrere Sources können einem Stock zugeordnet werden. Magento verwendet diese Zuordnung für die verkaufbare Menge eines Verkaufskanals.

Vor der technischen Umsetzung sollte deshalb zunächst die fachliche Frage beantwortet werden:

Welche SAP-Menge darf der Magento-Shop tatsächlich verkaufen?

Das ist besonders relevant, wenn mehrere Lagerorte, Reservierungen, Sicherheitsbestände oder unterschiedliche Liefergebiete existieren.

Wie werden Kunden und SAP Business Partner verbunden?

Auch Kundenstammdaten benötigen ein klares Konzept.

Magento kann Kundenkonten selbst verwalten. SAP S/4HANA arbeitet mit Business Partnern. SAP stellt dafür APIs zur Verfügung, über die Business-Partner-Stammdaten gelesen oder angelegt werden können.

Zu klären sind beispielsweise:

• Darf sich ein neuer Kunde direkt im Shop registrieren?
• Wann wird daraus ein Business Partner in SAP?
• Muss SAP den Kunden zuerst freigeben?
• Welche SAP-Nummer wird in Magento gespeichert?
• Wie werden bestehende SAP-Kunden einem Magento-Konto zugeordnet?
• Welches System führt Rechnungs- und Lieferadressen?
• Was passiert bei einer Adressänderung?
• Wie werden Ansprechpartner eines Firmenkunden behandelt?
• Wie werden mehrere Einkäufer eines Unternehmens abgebildet?

Gerade im B2B-E-Commerce kann die Beziehung zwischen Magento-Konto und SAP-Kundenstruktur deutlich komplexer werden als bei einem klassischen B2C-Shop.

Eine einfache Lösung ist z.B. das B2B Kunden schlicht manuell freigegeben werden müssen im Magento Shop. Die reguläre Funktion im Shop sich einen Account anlegen zu können (wie im B2C üblich) wird so angepasst, dass Unternehmen zwar ihren Account anlegen, der aber zunächst vom Shopbetreiber freigegeben werden muss.

Direktverbindung oder Middleware?

Magento muss technisch nicht zwingend unmittelbar mit SAP kommunizieren bzw. dies ist sogar unüblich unserer Erfahrung nach.

Drei grundsätzliche Architekturen sind denkbar.

Magento kommuniziert direkt mit SAP

Das kann bei überschaubaren Integrationen sinnvoll sein, wenn passende Schnittstellen vorhanden sind und nur wenige Systeme beteiligt sind. Mit zunehmender Zahl der Datenflüsse wächst jedoch die Kopplung zwischen beiden Systemen.

Eine vorhandene Middleware vermittelt

Viele Unternehmen haben bereits eine zentrale Integrationsplattform.

Dann kann Magento beispielsweise mit der Middleware kommunizieren. Diese übernimmt Routing, Transformation und Kommunikation mit SAP.

Das kann insbesondere sinnvoll sein, wenn dort bereits Monitoring, Mapping und zentrale Integrationsregeln vorhanden sind.

SAP Integration Suite wird eingesetzt

SAP Integration Suite kann ebenfalls als Integrationsschicht eingesetzt werden.

SAP dokumentiert unter anderem Unterstützung für REST-, SOAP- und OData-basierte API-Artefakte. Zusätzlich sind verschiedene Adapter verfügbar, darunter auch IDoc-Adapter.

Welche Variante geeignet ist, lässt sich ohne Kenntnis der vorhandenen SAP-Landschaft nicht pauschal beantworten.

Müssen alle Daten in Echtzeit übertragen werden?

Ganz klar Nein.

Für jeden Datenstrom sollte separat entschieden werden, wie aktuell die Informationen sein müssen. z.B. Produktbilder gibt es selten Gründe,dass diese in Echtzeit getauscht werden. Diese werden in ersten Integrationsstufen üblicherweise sogar manuell aktualisiert.

Beispielsweise:

Daten	Denkbare Aktualisierung
Bestellung	unmittelbar oder sehr kurzfristig (alle 5 Min per Cronjob)
Bestand	wenige Minuten
Preis	Minuten bis Stunden, abhängig vom Modell
Produktstammdaten	mehrmals täglich
Produkttexte	täglich
Tracking	ereignisbasiert oder regelmäßig
SAP-Auftragsstatus	regelmäßig oder ereignisbasiert

Diese Werte sind Beispiele und keine allgemeine Empfehlung. Bei Shops wo sich der Bestand z.B. selten ändert und es große Sicherheitsbestände gibt usw. kann es womöglich auch täglich oder wöchentlich erfolgen.

Magento unterstützt neben synchronen REST-Aufrufen auch asynchrone Web-Endpunkte und Bulk-Verarbeitung. Bei Bulk-Aufrufen werden mehrere Operationen in einzelne Nachrichten aufgeteilt und über eine Message Queue verarbeitet.

Das kann beispielsweise bei großen Produkt- oder Preisimporten interessant sein.

Hohe Aktualität sollte nur dort gefordert werden, wo sie fachlich einen Nutzen hat. Echtzeit erhöht häufig die Anforderungen an Verfügbarkeit, Performance und Fehlerbehandlung.

Wie sollte die Fehlerbehandlung geplant werden?

Eine produktive Schnittstelle benötigt mehr als Datentransport.

Zu einem Betriebskonzept gehören typischerweise:

• eindeutige Übertragungsstatus
• Logging (üblicherweise technische Logging, aber denkbar auch sichtbar für kunden)
• Fehlerklassifizierung (z.B. "Kundennummer fehlt bei Kunden")
• automatische Wiederholungsversuche
• manuelles Reprocessing (evtl. sogar per Adminbereich durch Kunden selbst)
• Monitoring
• Benachrichtigungen (bei Fehlern)
• Schutz vor Doppelübertragungen
• Nachvollziehbarkeit der übertragenen Daten
• Umgang mit Wartungsfenstern
• Verfahren für größere Störungen

Hilfreich ist die Unterscheidung zwischen technischen und fachlichen Fehlern.

Ein Netzwerk-Timeout kann eventuell automatisch erneut versucht werden. Das sollte das Konzept schlicht "aussitzen" und z.b. alle X Minuten neu versuchen bis es schlicht wieder funktioniert.

Eine unbekannte SAP-Materialnummer benötigt wahrscheinlich eine fachliche Prüfung. Das kann womöglich das Update von Preisen/Bestand "crashen" bzw. geht dann schlicht nicht. Wenn z.B. vorab nicht das Produkt korrekt angelegt wurde, kann der Preis/Bestand nicht aktualisiert werden. Hier ist wichtig deutlich und verständlich Fehlermeldungen idealerweise automatisch zu generieren. Dann kann der Shopbetreiber selbst (ohne Magento Support) den Fehler idealerweise bereits lösen.

Ein ungültiges Datenformat deutet möglicherweise auf ein Mapping-Problem hin. Das passiert üblicherweise nur bei Anpassungen an der API oder ähnliches. Aber auch hier sollte es Fehlermails und zumindest ein Eintrag in einem Fehlerlog geben.

Diese Unterscheidung verhindert, dass jeder Fehler denselben Prozess auslöst. Wichtig ist, dass Fehler überhaupt abgefangen werden und entsprechend "geworfen" werden, sodass diese auch wirklich sichtbar sind und jemand darauf reagiert.

Welche Datenmengen muss die Schnittstelle bewältigen?

Die Anzahl der Produkte allein sagt wenig über die tatsächliche Last aus.

Relevant können sein:

• Anzahl Produkte
• Anzahl Varianten
• Anzahl Lagerorte
• Preisdatensätze je Produkt
• kundenindividuelle Preise
• Anzahl Kunden
• Bestellungen pro Stunde
• Bestellpositionen
• tägliche Änderungen
• saisonale Spitzen
• Initialimport beim Projektstart

Ein Shop mit 30.000 Produkten und einem Preis pro Produkt kann technisch einfacher sein als ein B2B-Shop mit 5.000 Produkten und mehreren Millionen Kombinationen aus Kunde, Produkt und Preis.

Lastspitzen sollten ebenfalls betrachtet werden. Wenn z.B. durch dusselige Prozesse jeden Tag all 5.000 Produkte ein oder mehrfach per API angefasst werden (obwohl nicht mussten), kann dies auch das Hosting stark belasten.

Wenn SAP beispielsweise nachts sehr große Datenpakete sendet, muss Magento diese verarbeiten können, ohne den laufenden Shop unnötig zu belasten.

Wie sollte eine Magento-SAP-Schnittstelle getestet werden?

Tests sollten reale Geschäftsprozesse abbilden. Dazu gehören insbesondere auch die Sonderfälle, da dies die Fälle sind, die üblicherweise eine Schnittstelle "lahmlegen" bzw. schief laufen.

Ein einfacher Test mit einem Produkt und einer Bestellung reicht für eine produktive Integration kaum aus.

Sinnvolle Testszenarien können beispielsweise sein:

• einfacher Auftrag
• Gastbestellung
• bestehender SAP-Kunde
• neuer Kunde
• abweichende Lieferadresse
• mehrere Positionen
• Rabatt
• Staffelpreis
• individuelle Preisvereinbarung
• nicht verfügbarer Artikel
• Teillieferung
• Storno
• Retoure
• SAP zeitweise nicht erreichbar
• Timeout während einer erfolgreichen Übertragung
• fehlerhafte Stammdaten
• doppelte Nachricht
• große Datenmenge

Zusätzlich sollten Grenzfälle bewusst erzeugt werden. Hier ist das Wissen auf SAP Seite um die Bestellungen usw. extrem wichtig. Es muss schlicht bewusst/bekannt sein was für Sonderfälle/Grenzfälle es gibt.

Gerade dort zeigen sich häufig Probleme, die bei einem Test des idealen Standardprozesses unentdeckt bleiben.

Selbst bei noch so guten Testläufen, ist es üblicherweise immer der Fall, dass 1-2 Sonderfälle dennoch nicht bedacht werden. Daher ist es wichtig die Schnittstelle stufenweise auszurollen, einige Wochen/Monate testen und dann die nächste Ausbaustufe zu verwenden. So bleiben auch die (übersehenen) Sonderfälle überschaubar und gut lösbar.

Welche Verantwortlichkeiten sollten vor dem Projekt geklärt werden?

Eine Magento-SAP-Integration betrifft meist mehrere Verantwortungsbereiche.

Benötigt werden häufig Ansprechpartner für:

• SAP Betreuer in der Firma sowie evtl. Externe Partner
• Magento Betreuer/Agentur sowie Zuständige in Firma
• Infrastruktur/Netzwerk im SAP Umfeld und Mailserver
• Middleware auf SAP Seite
• Vertrieb bzw. E-Commerce zuständige Person
• Logistik falls Lieferinfos relevant sind
• Buchhaltung
• Datenschutz und IT-Sicherheit

Besonders wichtig ist eine klare Grenze zwischen den Verantwortungsbereichen. Wenn eine Bestellung nicht in SAP angekommen ist, sollte möglichst schnell feststellbar sein. Hier im Fall, dass Magento etwas schickt:

1. Hat Magento die Nachricht erzeugt?
2. Hat Magento sie (wirklich) versendet (oder z.B. interne Fehler)?
3. Hat eine Middleware sie angenommen (sprich taucht Sie in den Logs auf) ?
4. Wurde sie transformiert (innerhalb der Middleware)?
5. Hat SAP sie erhalten?
6. Hat SAP sie fachlich akzeptiert?
7. Wurde eine Antwort zurückgesendet?

Hier gibt es verschiedenste Stelle wo eine Schnittstelle-Nachricht schief laufen kann. Im Laufe der Integration erkennt man üblicherweise die häufigsten Kandidaten. Es muss aber eben schlicht auch möglich sein, bei exotischeren Fällen die Ursache systematisch und zeitnah einzugrenzen. Die Ursache beheben und bei Bedarf die Nachricht neu zu verschicken.

Welche Fragen sollten vor einer Aufwandsschätzung beantwortet werden?

Vor einer belastbaren Aufwandsschätzung sollten mindestens folgende Informationen gesammelt werden:

• Magento-Version
• eingesetztes SAP-System und Version (Für Update Aufwand auf SAP-Seite evtl. relevant)
• vorhandene Middleware (Updatestand bzw. braucht es Update?)
• verfügbare SAP-Schnittstellen (z.B. Rest-API)
• zu übertragende Datenobjekte
• Datenrichtung pro Objekt
• führendes System jeweils
• vorhandene Felddefinitionen
• Produkt- und Variantenstruktur (wenn relevant für Ausbaustufe)
• Preislogik (wenn relevant für Ausbaustufe)
• Bestandslogik (wenn relevant für Ausbaustufe)
• Kundenstruktur (wenn relevant für Ausbaustufe)
• Bestellprozess
• Sonderfälle
• gewünschte Aktualität
• erwartete Datenmengen
• Anforderungen an Logging und Monitoring
• Testsysteme
• Verantwortlichkeiten

Je früher reale Beispieldaten zur Verfügung stehen, desto besser lassen sich Mapping und Sonderfälle beurteilen.

Wir haben hat diese Fragen auch in einem separaten Beitrag zur Aufwandsschätzung von Magento-ERP-Schnittstellen zusammengefasst.

Welche typischen Fehler sollten Unternehmen vermeiden?

Aus Integrationsprojekten lassen sich einige wiederkehrende Risiken ableiten.

Zu früh über das Übertragungsformat sprechen

Die Frage „REST, SOAP oder IDoc?“ ist wichtig. Zuerst müssen jedoch Geschäftsprozess und Datenhoheit klar sein. Ein technisch sauber übertragenes falsches Datenmodell bleibt fachlich falsch.

Nur den Standardfall spezifizieren

Eine Bestellung mit einem Artikel lässt sich meist schnell übertragen. Die eigentliche Komplexität entsteht durch Teillieferungen, Stornos, Preisabweichungen, Adressen, Rabatte, Kundenzuordnungen und Sonderfällen.

Alle Daten bidirektional synchronisieren

Jede zusätzliche Schreibrichtung erzeugt weitere Konfliktmöglichkeiten. Für jedes Objekt sollte deshalb geprüft werden, ob ein Rückkanal fachlich wirklich benötigt wird.

SAP-Bestand direkt als Shopbestand interpretieren

Die physische Menge ist nicht automatisch die Menge, die im Shop verkauft werden soll. Reservierungen, Sicherheitsbestände und mehrere Lagerorte müssen gegebenenfalls berücksichtigt werden.

Fehlerbehandlung erst nach dem Go-Live ergänzen

Fehler treten in produktiven Integrationen auf. Entscheidend ist, ob sie erkannt, eingeordnet und kontrolliert korrigiert werden können. Idealerweise ist bereits während der Integration und Testen soviel Monitoring und Logging im Einsatz, dass NICHT händisch jedes Mal in den Magento Logs und ähnlichen umständlich die Informationen gesucht werden müssen.

Wie haben dazu zum Beispiel dieses Magento REST-API Logging Erweiterung umgesetzt

Wie kann ein sinnvolles Vorgehen aussehen?

Für umfangreichere Projekte bietet sich ein schrittweises Vorgehen an.

1. Architektur wählen

Kann die Middlewear z.B. REST-API? Welche Authentifierung wie z.B. "Bearer Token"? Wenn dies möglich ist, ist dieser Punkt soweit "durch". Ja man muss sich die Details später anschauen, aber es sollte mit 99,99% Wahrscheinlichkeit funktionieren.

2. Prozesse aufnehmen

Zuerst werden die relevanten Geschäftsprozesse beschrieben.

Beispielsweise:

Kunde bestellt → Magento erzeugt Bestellung → Auftrag wird in SAP angelegt → Lieferung erfolgt → Tracking geht an Magento zurück.

3. Datenobjekte definieren

Anschließend wird festgelegt, welche Informationen für jeden Prozess benötigt werden.

4. Datenhoheit festlegen

Für jedes Objekt und bei Bedarf jedes einzelne Feld wird das führende System bestimmt.

5. Mapping erstellen

SAP-Felder und Magento-Felder werden einander zugeordnet.

Unterschiedliche Datenmodelle und Wertelisten werden dokumentiert.

6. Fehlerfälle definieren

Für relevante Störungen werden erwartete Reaktionen festgelegt.

7. Schnittstelle entwickeln

Magento kann dafür vorhandene REST-Funktionen verwenden oder bei Bedarf durch eigene Module und API-Endpunkte erweitert werden.

8. Mit realistischen Daten testen

Tests sollten neben Standardfällen auch Sonderfälle, Ausfälle und größere Datenmengen umfassen.

9. Monitoring und Betrieb vorbereiten

Vor dem Go-Live muss feststehen, wie Fehler erkannt und bearbeitet werden.

Fazit

Eine Magento-SAP-Schnittstelle sollte als Verbindung mehrerer Geschäftsprozesse betrachtet werden.

Für SAP-erfahrene IT-Verantwortliche sind vor allem sechs Fragen entscheidend:

1. Welche Daten benötigt Magento?
2. Welche Daten müssen zurück zu SAP?
3. Welches System führt welche Information?
4. Welches System sendet bzw. ruft in welchem Fall Daten ab?
5. Wie werden Magento- und SAP-Datenmodelle zugeordnet?
6. Wie werden Fehler und Ausfälle behandelt?
7. Welche Integrationsarchitektur passt zur bestehenden SAP-Landschaft?
8. Wo müssen Dinge in Magento erweitert/angepasst werden?

Magento stellt für viele typische E-Commerce-Objekte bereits REST-Schnittstellen bereit. SAP bietet je nach System ebenfalls unterschiedliche Integrationsmöglichkeiten. Die eigentliche Projektarbeit liegt häufig in der fachlichen Zuordnung, im Mapping, in Sonderfällen sowie in einer zuverlässigen Verarbeitung.

Je klarer diese Punkte vor Beginn der Entwicklung beschrieben sind, desto besser lassen sich Umfang, Architektur und Aufwand einer Magento-SAP-Anbindung einschätzen.

Wie beschrieben ist das stufenweise vorgehen sehr wichtig. Eine Schnittstelle bei der in der ersten Stufe Kundendaten, Produktdaten, Bestanddaten und noch mehr übertragen werden soll, wird mit hoher Wahrscheinlichkeit scheitern oder schlicht absurd aufwändig und länger dauern. Besser ist es so klein wie möglich zu starten, Sonderfälle abfangen/lösen und dann stückweise auszubauen.

Für eine individuelle Beratung und Einschätzung sprechen Sie uns gerne an

zu unseren Kontaktdaten

Magento-SAP-Schnittstelle planen oder erweitern

KonVis entwickelt seit vielen Jahren individuelle Magento-Schnittstellen und hat bereits verschiedene Anbindungen zwischen Magento und SAP umgesetzt.

Dazu gehörten unter anderem der Export von Bestellungen und Kundendaten sowie komplexere SAP-Integrationen mit umfangreichem Error-Handling, Verarbeitung größerer Datenmengen und Maßnahmen zur Sicherstellung der Übertragung.

Wenn Sie eine bestehende SAP-Landschaft mit Magento verbinden möchten, kann zunächst gemeinsam geprüft werden, welche Datenflüsse benötigt werden, welche Magento-Funktionen bereits vorhanden sind und an welchen Stellen individuelle Erweiterungen erforderlich sind.

Ausführliche Informationen zu Magento Schnittstelle Programmierung

Ausführliche Informationen zu den Kosten einer Magento Schnittstelle für ERP System

Quellen

Adobe Developer Documentation, Order processing tutorial, abgerufen am 31.08.2026
Adobe Order Processing REST API

Adobe Developer Documentation, Inventory Management, abgerufen am 31.08.2026
Adobe Inventory Management REST API

Adobe Developer Documentation, Manage prices for multiple products, abgerufen am 31.08.2026
Adobe Catalog Pricing REST API

Adobe Developer Documentation, Bulk endpoints, abgerufen am 31.08.2026
Adobe Bulk API

KonVis, Magento API und Schnittstellen Programmierung
Magento Schnittstellen Programmierung bei KonVis

KonVis, Was kostet eine Magento-ERP-Schnittstelle?
Zwölf Fragen vor der Aufwandsschätzung