Middleware
Eine zentrale Schicht für gewachsene Systemlandschaften
Solange nur zwei Systeme miteinander reden, reicht eine Schnittstelle. Sobald aber Shop, Warenwirtschaft, PIM, Marktplatz, Payment und Versand alle voneinander abhängen, wird aus einzelnen Verbindungen schnell ein Geflecht: Jede Änderung an einem System zieht Anpassungen an allen anderen nach sich; ein Ausfall reißt im schlimmsten Fall die ganze Kette mit. Middleware setzt eine vermittelnde Schicht dazwischen: Jedes System spricht nur noch mit ihr, nicht mehr mit jedem anderen. Sie übersetzt Datenformate, steuert die Abläufe und entkoppelt die Systeme, sodass sich einzelne Teile ändern oder ausfallen können, ohne den Rest zu gefährden.
Womit wir dich unterstützen:
Zentrale Datendrehscheibe
Jedes System wird einmal angebunden, an die Middleware und nicht an jedes andere. Daten laufen über eine zentrale Stelle, statt über ein Geflecht aus Einzelverbindungen.
Daten übersetzen & zuordnen
Jedes System hat sein eigenes Datenformat. Die Middleware übersetzt dazwischen und ordnet die Felder sauber zu, damit überall dieselbe Information richtig ankommt.
Systeme entkoppeln
Kein System hängt mehr direkt am anderen. Ändert sich eines oder fällt aus, fängt die Middleware das ab. Der Rest läuft weiter, statt in einer Kettenreaktion mitzureißen.
Steuern & überwachen
Eine Stelle, an der die Abläufe gesteuert und beobachtet werden: Was läuft, was hakt, wo muss eingegriffen werden. Sichtbar an einem Ort statt verteilt über viele Systeme.
Wann Middleware sich lohnt
Nicht jedes Projekt braucht eine Middleware. Eine einzelne Anbindung kommt ohne sie aus. Sinnvoll wird sie, sobald sich diese Muster zeigen:
Viele Systeme, viele Verbindungen
Shop, Warenwirtschaft, PIM, CRM, Marktplätze, Payment: Je mehr zusammenkommt, desto unübersichtlicher wird ein Netz aus einzelnen Schnittstellen.
Ständige Änderungen
Ein neuer Kanal, ein neues System, eine neue Anforderung — und schon muss an vielen Stellen gleichzeitig angefasst werden. Eine zentrale Schicht macht das beherrschbar.
Daten driften auseinander
Dieselben Daten liegen in mehreren Systemen, aber nirgends gleich. Ohne eine vermittelnde Stelle gibt es keine verlässliche Quelle der Wahrheit.
Aus unserer täglichen Arbeit
Zentrale Middleware für die Onlineshops, Marktplätze und Filialen einer Unternehmensgruppe
Eine Unternehmensgruppe mit mehreren Gesellschaften betrieb je Gesellschaft einen eigenen Onlineshop, dazu mehrere Marktplätze und den stationären Handel. Warenwirtschaft und Produktdatenpflege lagen in eigenen Systemen. Jede Verbindung dazwischen war über die Jahre einzeln entstanden. Bei dieser Zahl an Systemen wächst der Aufwand nicht linear, sondern mit jeder neuen Strecke: Eine Änderung an der Preislogik musste an mehreren Stellen gleichzeitig nachgezogen werden und ein einzelnes langsames System konnte die ganze Kette ausbremsen.
Wir haben eine Middleware als zentrale Schicht entwickelt. Jedes Quellsystem übersetzt seine Daten einmal in ein einheitliches Modell, jedes Zielsystem bekommt daraus seine eigene Ausleitung. Der eigentliche Aufwand lag in der Klärung der Datenhoheiten: Preise und Bestände führt die Warenwirtschaft, Produktinhalte das Produktdatensystem, Bestellungen entstehen im jeweiligen Kanal. Dazu kamen Warteschlangen und Wiederholungen, damit ein nicht erreichbares System die übrigen nicht blockiert, sowie versionierte Zuordnungen, über die sich ein neuer Kanal ergänzen lässt, ohne bestehende Strecken anzufassen.
Heute kommt ein zusätzlicher Marktplatz oder eine weitere Gesellschaft dazu, ohne dass die vorhandenen Verbindungen berührt werden. Änderungen an einem System bleiben dort, wo sie entstehen.
Prozessautomatisierung für Onlineshop und Website mit n8n
Ein Kunde betrieb einen Onlineshop und daneben eine Website. Dazwischen lag eine Reihe täglicher Handgriffe: Bestelldaten wurden für die Buchhaltung aufbereitet, Formularanfragen von der Website per Mail verteilt, Bestände und Rückläufer manuell geprüft. Keine dieser Aufgaben rechtfertigte für sich eine Eigenentwicklung, in Summe kosteten sie jede Woche Stunden.
Statt eine eigene Schicht zu entwickeln, haben wir n8n eingesetzt und selbst gehostet. Ereignisse aus dem Shop und Einsendungen von der Website lösen darin Abläufe aus: Daten laufen aufbereitet in die Buchhaltung, Kontakte landen mit dem passenden Interesse in den Newsletter-Gruppen, das Team bekommt Benachrichtigungen dort, wo es ohnehin arbeitet. Wo die Standardbausteine nicht reichten, haben wir eigene Schritte ergänzt, etwa für die Umrechnung von Einheiten und für Prüfungen vor der Übergabe.
Die Abläufe sind im Editor sichtbar, kleinere Anpassungen nimmt das Team selbst vor. Betrieb und Überwachung liegen bei uns. Kommt eine neue Aufgabe dazu, entsteht ein weiterer Ablauf, kein neues Projekt.
Schlanke Middleware für eine Warenwirtschaft ohne offene Schnittstelle
Ein kleinerer Händler pflegte sein Sortiment in einer älteren Warenwirtschaft, die keine offene Schnittstelle mitbrachte. Der einzige Weg nach draußen war ein nächtlicher Datei-Export in einem eigenen Format. Entsprechend hinkten die Bestände im Onlineshop einen Tag hinterher, Preisänderungen wurden von Hand nachgezogen. Für eine Plattformlösung war der Fall zu speziell, für den Verzicht auf Automatisierung zu fehleranfällig.
Wir haben eine schlanke Middleware entwickelt, die den Export einliest, die Daten normalisiert und über die Shop-Schnittstelle einspielt. Die Arbeit steckte in den Eigenheiten des Formats: Staffelpreise, abweichende Mengeneinheiten und Artikel, die im Shop als Zubehör auftauchen, im System aber eigenständig geführt werden. Fehlerhafte Zeilen sortiert die Übertragung aus, statt den gesamten Durchlauf abzubrechen.
Der Abgleich läuft heute mehrmals täglich statt einmal nachts. Die Lösung ist bewusst klein gehalten, läuft auf der vorhandenen Infrastruktur mit und verursacht keine Kosten pro übertragenem Vorgang.
Häufige Fragen zu Middleware
Was ist der Unterschied zwischen einer Schnittstelle und einer Middleware?
Eine Schnittstelle verbindet zwei Systeme miteinander. Eine Middleware setzt eine eigene Schicht dazwischen, mit der alle Systeme sprechen. Bei zwei oder drei Verbindungen ist der Unterschied kaum spürbar. Sobald ein halbes Dutzend Systeme voneinander abhängen, entscheidet er darüber, ob eine Änderung an einer Stelle den Rest mitreißt.
Brauchen wir überhaupt eine Middleware?
Oft nicht. Für zwei Systeme mit überschaubarem Datenaustausch ist eine direkte Schnittstelle die einfachere und günstigere Lösung. Eine Middleware lohnt sich, wenn mehrere Systeme zusammenspielen, Daten aus verschiedenen Quellen zusammenlaufen oder ein Ausfall nicht die ganze Kette treffen darf. Nach einem Blick auf dein bestehendes und gewünschtes Setup wägen wir ab, ob eine vorhandene Lösung trägt oder eine Eigenentwicklung der bessere Weg ist.
Shopware bietet mit Nexus eine eigene Integrationsplattform. Ist das nicht dasselbe?
Nexus ist ein starkes Werkzeug, verfolgt aber einen anderen Ansatz: Es macht Shopware zur zentralen Steuerungsebene. Solange der Onlineshop das Zentrum ist, funktioniert das gut. Liegt die führende Datenhoheit dagegen im ERP oder laufen mehrere Kanäle zusammen, entsteht eine Abhängigkeit von einem System, das die Daten gar nicht führt. Wir prüfen beides und setzen Nexus ein, wo es passt.
Wir arbeiten mit Shopify Flow oder n8n. Könnt ihr damit umgehen?
Ja. Flow automatisiert Abläufe innerhalb von Shopify sehr gut, n8n ist für systemübergreifende Automatisierung eine ernstzunehmende Basis. Wir arbeiten mit beiden, wenn sie zum Fall passen und ergänzen eigene Logik dort, wo die Standardbausteine nicht reichen. Was wir nicht tun: eine Eigenentwicklung verkaufen, wenn ein vorhandenes Werkzeug den Job erledigt. Trägt kein Werkzeug, entwickeln wir die Middleware selbst.
Was kostet eine Middleware im laufenden Betrieb?
Das hängt vom gewählten Weg ab. Plattformwerkzeuge rechnen meist nach Ausführungen ab, eine eigenentwickelte Lösung verursacht Entwicklungsaufwand und danach im Wesentlichen Betriebskosten. Bei geringem Datenaufkommen ist die Abrechnung nach Verbrauch günstiger, bei hochfrequenten Abgleichen kippt das Verhältnis.
Macht uns eine Eigenentwicklung von euch abhängig?
Wir setzen auf verbreitete Technologien und dokumentierte, nachvollziehbare Strukturen, sodass auch andere Entwickler die Lösung übernehmen können. Exotische Konstruktionen, die nur wir pflegen können, vermeiden wir bewusst. Umgekehrt bindet auch eine fertige Plattform, nur eben an ihren Anbieter und dessen Preismodell.
Was passiert, wenn ein angebundenes System ausfällt?
Genau dafür gibt es die vermittelnde Schicht. Fällt ein System aus, laufen die Daten nicht ins Leere, sondern werden zwischengespeichert und nachgeliefert, sobald es wieder erreichbar ist. Fehlgeschlagene Übertragungen bleiben im Protokoll nachvollziehbar, statt unbemerkt durchzulaufen.
Lust, gemeinsam etwas zu entwickeln, das bleibt?
Projekt anfragen