Middleware zwischen Shop und ERP: Wann eine zusätzliche Schicht sinnvoll ist

Middleware ist eine zusätzliche Software zwischen Systemen. Sie kann Informationen entgegennehmen, umformen und an andere Anwendungen weitergeben. Zwischen Shop und ERP kann das hilfreich sein, wenn mehrere Datenquellen oder besondere Abläufe zusammenkommen. Die zusätzliche Schicht muss jedoch selbst zuverlässig betrieben werden. Sie ist deshalb eine Architekturentscheidung mit konkreten Aufgaben und Kosten.

Die tatsächliche Lücke beschreiben

Beginne mit einem Datenfluss, den die vorhandene Anbindung nicht ausreichend abdeckt. Welche Information fehlt, in welcher Richtung und zu welchem Zeitpunkt? Prüfe, ob die Lücke durch Konfiguration, eine dokumentierte Connector-Funktion oder eine Änderung des Prozesses geschlossen werden kann.

Ein möglicher Bedarf: Ein Auftrag soll vor der Übergabe mit Daten aus einem dritten System ergänzt werden. Ob Middleware dafür geeignet ist, hängt davon ab, ob alle benötigten Schnittstellen diese Informationen und Aktionen bereitstellen. Ein allgemeines Versprechen „per API geht alles“ ersetzt diese Prüfung nicht. Für Xentral ist die offizielle API-Dokumentation der technische Ausgangspunkt.

Für einen Xentral-Zugang musst du außerdem API-Token, Rechte und Laufzeit planen. Bevor du zusätzliche Logik entwickelst, lohnt sich die Prüfung, welche Aufgaben Xentral Flows und der Flow Editor im konkreten Setup übernehmen können.

Verantwortung für Daten eindeutig zuordnen

Lege für jede Datenart fest, welches System sie führt. Wenn Shop, ERP und Middleware dieselbe Information unabhängig verändern, können Aktualisierungen einander überschreiben. Eine klare Zuständigkeit reduziert solche Konflikte.

• Wo entsteht der ursprüngliche Datensatz?
• Welche Kennung verbindet ihn mit den anderen Systemen?
• Welche Felder darf die Middleware verändern?
• Wie wird eine spätere Korrektur weitergegeben?
• Was geschieht, wenn zwei Änderungen gleichzeitig eintreffen?

Dokumentiere auch, ob die Middleware Daten dauerhaft speichert oder nur weiterleitet. Davon hängen unter anderem Wiederanlauf, Fehlersuche und der Umgang mit gespeicherten Informationen ab.

Wiederholungen ohne doppelte Vorgänge

Eine Übertragung kann erfolgreich verarbeitet werden, obwohl die technische Antwort verloren geht. Wenn der Absender anschließend erneut sendet, darf daraus nicht unbeabsichtigt ein zweiter Auftrag entstehen. Dafür braucht die Integration eine eindeutige Vorgangskennung und einen geprüften Umgang mit Wiederholungen.

Der Fachbegriff dafür ist Idempotenz: Dieselbe fachliche Aktion führt bei kontrollierter Wiederholung nicht zu zusätzlichen unerwünschten Ergebnissen. Ob eine einzelne API-Funktion dieses Verhalten selbst unterstützt oder die Integrationslogik es sicherstellen muss, ist je Endpunkt zu prüfen.

Fehler sichtbar und bearbeitbar machen

Unterscheide vorübergehende technische Störungen von fachlich ungültigen Daten. Ein kurzzeitig nicht erreichbares System kann einen späteren Versuch rechtfertigen. Eine fehlende Artikelzuordnung benötigt dagegen eine Korrektur. Dauerndes Wiederholen löst diesen Fehler nicht.

Definiere, wo offene Vorgänge sichtbar werden, wer sie prüft und wie ein einzelner Fall erneut verarbeitet wird. Protokolle sollten die notwendigen technischen Referenzen enthalten, ohne unnötig Zugangsdaten oder sensible Inhalte offenzulegen. Ein grüner Gesamtstatus genügt nicht, wenn einzelne Bestellungen unbemerkt liegen bleiben.

Einrichtung und Betrieb gemeinsam kalkulieren

Zum Aufwand gehören neben der ersten Umsetzung auch Überwachung, Anpassungen an Schnittstellenänderungen und die Bearbeitung von Ausnahmen. Kläre, wer für welche Komponente zuständig ist. Bei mehreren Dienstleistern sollte ein Fehler nicht allein deshalb liegen bleiben, weil jeder nur seinen Abschnitt betrachtet.

Teste den normalen Ablauf, fehlende Daten, einen Ausfall und eine Wiederholung. Entscheide erst anhand dieser Ergebnisse, ob die zusätzliche Schicht den benötigten Nutzen bringt. Im Xentral-API-Leitfaden findest du den weiteren technischen Kontext. Für eine Integrationsprüfung helfen eine Systemskizze und Beispiele der konkreten Datenflüsse, die heute nicht funktionieren.

Passender Einblick aus einem Kundenprojekt

Die Fallstudie CAJU beschreibt die Konsolidierung einzelner Werkzeuge und die Automatisierung von Abläufen. Sie ist ein Beispiel für die Prüfung der gesamten Systemlandschaft; eine bestimmte Middleware-Lösung wird damit nicht belegt.

Quellen und fachlicher Stand

Herstellerdokumentation geprüft am 17. September 2026. Die Empfehlungen zur Projektorganisation sind redaktionelle Empfehlungen von CommerceOS.

• Xentral Developer: API-Dokumentation