Middleware schafft eine steuerbare Schicht zwischen ERP und wechselnden Kanälen
Direkte Punkt-zu-Punkt-Verbindungen funktionieren bei wenigen Systemen, werden mit jedem weiteren Kanal jedoch schwerer zu überblicken. Regeln für Preise, Attribute, Bestand und Status werden mehrfach implementiert und unterscheiden sich schrittweise. Eine Middleware bündelt gemeinsame Logik, übersetzt in kanalspezifische Formate und macht den Datenfluss an einer Stelle beobachtbar.
Dafür benötigt sie ein eindeutiges internes Datenmodell. Produkt, Angebot, Bestand, Auftrag, Lieferung und Retoure werden unabhängig vom jeweiligen Kanal beschrieben. Adapter übernehmen die Übersetzung zu Amazon, Shop oder Logistikpartner. Das reduziert Wiederholung, bedeutet aber nicht, dass alle Plattformen gleich sind: Pflichtfelder, Kategorien, Status und Fristen bleiben pro Verbindung konfiguriert und getestet.
Im Betrieb zählt die Fähigkeit, Fehler sicher einzugrenzen. Jede Nachricht braucht eine Referenz, einen Status und nachvollziehbare Transformationen. Wiederholungen dürfen keine doppelten Aufträge erzeugen, und kritische Bestands- oder Auftragsfehler müssen priorisiert alarmieren. So wird Middleware von einem unsichtbaren Datenrohr zu einem aktiv steuerbaren Bestandteil des Commerce-Betriebs.
Middleware belastbar gestalten
- Kanonisches Modell für zentrale Datenobjekte
- Versionierte Regeln je Connector
- Nachvollziehbare Logs und sichere Wiederholungen
- Prioritäten und Verantwortliche für Störungen
Zuerst die Datenhoheit klären
Für jedes Datenobjekt braucht es ein führendes System. Das ERP kann etwa Bestand und Auftragsstatus führen, ein PIM die Produktinformationen und der Shop Inhalte für die Präsentation ergänzen. Ohne diese Entscheidung entstehen Rückschleifen und widersprüchliche Werte.
Produkt- und Angebotsdaten
Marktplätze erwarten unterschiedliche Kategorien, Attribute, Pflichtfelder und Bildvorgaben. Die Middleware ordnet interne Daten den Kanalformaten zu und kann kanalspezifische Regeln anwenden.
- SKU, EAN und Variantenbeziehungen
- Titel, Beschreibungen, Bilder und Attribute
- Kategorien und Pflichtmerkmale
- Kanalpreise, Aktionen und Lieferinformationen
Bestände und Verfügbarkeit
Bestand muss nicht nur schnell, sondern auch fachlich korrekt übertragen werden. Reservierungen, Sicherheitsbestände, mehrere Lager und noch nicht gebuchte Aufträge beeinflussen die verkaufbare Menge. Klare Regeln reduzieren Überverkäufe.
Aufträge, Versand und Retouren
Eingehende Bestellungen müssen Kunden-, Steuer-, Zahlungs- und Positionsdaten vollständig enthalten. Nach der Bearbeitung fließen Versanddienstleister, Trackingnummer und Status zurück. Storno- und Retourenprozesse benötigen eigene Zustände und Verantwortlichkeiten.
Logistik und EDI mitdenken
Neben Marktplätzen können Speditionen, Fulfillment-Partner und EDI-Netzwerke Teil des Datenflusses sein. Versandaufträge, Lieferavise, Statusmeldungen und Geschäftsdokumente werden nach Partneranforderung transformiert. Beispiele für EDI-Partner sind Transus und Procuros.
Monitoring ist Teil der Schnittstelle
Eine Integration ist erst betrieblich, wenn Fehler sichtbar und wiederholbar bearbeitet werden können. Dazu gehören Protokolle, Warnungen, Wiederholungslogik, Verantwortliche und Kennzahlen zu Laufzeiten oder fehlgeschlagenen Datensätzen.
Das kanonische Datenmodell der Middleware
Bei vielen Kanälen ist es ineffizient, jedes Systempaar individuell zu verbinden. Ein kanonisches Modell beschreibt intern Produkt, Angebot, Bestand, Auftrag, Lieferung und Retoure. Jeder Adapter übersetzt zwischen diesem Modell und der jeweiligen Plattform.
Gemeinsame Regeln werden einmal umgesetzt, kanalspezifische Anforderungen bleiben isoliert. Das reduziert Abhängigkeiten und erleichtert einen neuen Connector, verlangt aber saubere Versionierung und eindeutige Felddefinitionen.
Betriebskonzept und Service-Level
Für jede Datenart werden erwartete Frequenz, zulässige Verzögerung und Fehlerpriorität festgelegt. Ein ausgefallener Bildexport hat eine andere Dringlichkeit als ein fehlender Auftrag oder falscher Bestand.
Dashboards, Alarmierung, Wiederholungen und manuelle Korrekturwege gehören in den Leistungsumfang. Außerdem muss klar sein, wer bei einem Fehler im ERP, in der Middleware, beim Provider oder am Marktplatz die Analyse übernimmt.
- fachliche und technische Health Checks
- Korrelation pro Auftrag und Nachricht
- Prioritäten und Reaktionszeiten
- Retry- und Dead-Letter-Prozess
- regelmäßiger Mengen- und Bestandsabgleich
Zum Abschluss
Häufige Fragen zum Thema
Wie schnell müssen Bestände synchronisiert werden?+
Das hängt von Abverkauf, Bestandspuffer, Kanalvorgaben und technischer Schnittstelle ab. Für knappe oder stark nachgefragte Artikel sind kurze Intervalle und klare Reservierungsregeln besonders wichtig.
Braucht jeder Marktplatz eine eigene Schnittstelle?+
Jeder Kanal hat eigene Datenmodelle und Prozesse. Eine Middleware kann gemeinsame Kernlogik bündeln, benötigt aber pro Verbindung ein spezifisches Mapping und Regelwerk.
Was passiert bei einem Schnittstellenfehler?+
Fehler sollten protokolliert, kategorisiert und sichtbar gemacht werden. Kritische Fälle brauchen Benachrichtigung, Wiederholungslogik und einen klaren manuellen Bearbeitungsweg.