Odoo Shopware 6 Connector: Asynchrone Synchronisation für komplexe E-Commerce-Systeme
Die Frage bei einer Odoo-Shopware-Integration ist nicht, ob die Systeme Daten austauschen können. Die Frage ist, wie eng sie dabei gekoppelt werden. Eine synchrone Verbindung macht die Verfügbarkeit des Checkouts von der Antwortzeit des ERP abhängig. Eine asynchrone entkoppelt beide voneinander.
Diese Entscheidung fällt einmal, zu Projektbeginn, und bestimmt danach das Betriebsverhalten des gesamten Systems. Dieser Beitrag beschreibt die asynchrone Variante als Referenzarchitektur: Ereignisfluss, Idempotenz, Fehlerbehandlung, Projektstruktur, Testing und Deployment.
Warum synchrone Schnittstellen problematisch sind
Eine direkte, blockierende Abfrage des ERP-Systems bei jeder Kundenaktion – etwa eine Live-Bestandsprüfung beim Checkout – koppelt die Verfügbarkeit des Shops an die Verfügbarkeit und Antwortzeit eines zweiten Systems. Steigt die Antwortzeit des ERP auch nur kurzzeitig an, verlängert sich die Ladezeit im Checkout unmittelbar mit. Fällt das ERP-System temporär aus, steht im schlechtesten Fall der gesamte Checkout still.
Ein weiteres Risiko synchroner Architekturen: Partial Updates. Schlägt eine mehrstufige Operation in der Mitte fehl, können Teile des Datensatzes bereits geschrieben, andere nicht mehr verarbeitet worden sein – ein inkonsistenter Zwischenzustand, der ohne saubere Fehlerbehandlung unbemerkt bleiben kann.
Diese Risiken sind nicht theoretisch: Jeder JSON-2-Aufruf gegen Odoo läuft in einer eigenen SQL-Transaktion und wird bei Erfolg committed, bei Fehler verworfen – mehrere Aufrufe werden dabei jedoch nicht automatisch zu einer gemeinsamen Transaktion verkettet. Ein Connector, der mehrere zusammenhängende Odoo-Aufrufe ausführt, muss diese Eigenschaft aktiv berücksichtigen, statt fälschlich von einer impliziten Gesamttransaktion auszugehen.
Event-Driven Architecture
Die belastbare Alternative ist eine ereignisbasierte, asynchrone Architektur. Geht eine Bestellung ein, schreibt das Shopware-Frontend diese lediglich in Millisekunden in eine Message Queue und schließt den Checkout für den Kunden sofort erfolgreich ab. Ein Connector arbeitet als Consumer die Queue im Hintergrund ab und überträgt die Aufträge über die JSON-2 API an Odoo. Schlägt die Übertragung fehl, verbleibt die Nachricht in der Queue und wird per Exponential Backoff später erneut verarbeitet.
Der grundlegende Datenfluss der Referenzarchitektur:
Shopware 6 → RabbitMQ Message Queue → Connector (Consumer) → Odoo 19 (JSON-2 API) → PostgreSQLDiese Entkopplung – im zugrunde liegenden Architekturkonzept als „Loose Coupling“ bezeichnet – bedeutet konkret: Odoo und Shopware wissen so wenig wie möglich voneinander und kommunizieren ausschließlich über eine standardisierte Middleware. Fällt eines der beiden Systeme kurzzeitig aus, kann das jeweils andere seinen Betrieb für die entkoppelten Prozesse fortsetzen; ausstehende Nachrichten werden gepuffert und später verarbeitet.
RabbitMQ und Symfony Messenger
In der beschriebenen Referenzimplementierung übernimmt eine RabbitMQ Message Queue diese Vermittlerrolle, angebunden über etablierte Muster: Publisher Confirm (Bestätigung, dass eine Nachricht sicher in der Queue angekommen ist), Retry-Schleifen, Dead Letter Exchange und Idempotent Consumer. Der vollständige Nachrichtenfluss folgt dem Muster Publisher → Exchange → Queue → Consumer → Retry Queue → Dead Letter Queue.
Wird der Connector direkt im Shopware-Frontend integriert, folgt er der etablierten Symfony-Architektur mit Symfony Messenger als Anbindung an die Message Queue – inklusive dedizierter Verzeichnisse für Client, DTOs, Mapper, Message-Handler, Services, Repositories und Exceptions.
Wichtig zur Einordnung: RabbitMQ ist die in dieser Referenzarchitektur verwendete, konkrete Message-Queue-Lösung – die Rolle „Message Queue“ ist damit nicht zwangsläufig an dieses eine Produkt gebunden. Für die Architekturentscheidung zählt das Muster (asynchrone Entkopplung über eine Queue), nicht die spezifische Produktwahl.
Idempotency und Datenkonsistenz
Ein Connector, der Nachrichten mehrfach verarbeiten kann – etwa nach einem Netzwerkfehler und erneutem Zustellversuch –, muss idempotent arbeiten: Die konkrete Nachricht kann wiederholt verarbeitet werden, ohne dass dadurch Dubletten oder inkonsistente Zustände entstehen. Odoo löst das über externe IDs in Verbindung mit der load()-Methode, die bei bereits vorhandener ID aktualisiert statt neu anlegt.
Für nicht-idempotente Schreiboperationen gilt eine zusätzliche Regel: Vor einem automatischen Retry muss geprüft werden, ob der ursprüngliche Request das Zielsystem bereits erfolgreich verändert hat – ein reines „nochmal senden“ ohne diese Prüfung kann sonst zu doppelten Bestellungen oder falschen Bestandsbuchungen führen.
Als Business Keys zwischen den Systemen dienen unveränderliche fachliche Identifikatoren wie die Shopware-UUID oder die Artikelnummer (SKU) – niemals technische Surrogate Keys wie interne Datenbank-IDs. Die Logik dazu erklären wir in Datenmapping bei der ERP-Migration.
Bestände, Bestellungen und Preise
Typische Synchronisationsbereiche einer laufenden Odoo-Shopware-Integration:
- Bestände: Änderungen im ERP fließen ereignisbasiert an das Frontend zurück, statt dass Shopware wiederholt aktiv nachfragt.
- Preise: inklusive kundenindividueller B2B-Preise und Staffelrabatte, gepflegt als Preislisten im ERP.
- Bestellungen: asynchron vom Frontend an das ERP übergeben, mit Retry bei temporären Fehlern.
- Auftragsstatus: Rückmeldung von Liefer- und Rechnungsstatus an das Frontend für Kundenkommunikation und Retourenprozesse.
Diese Aufzählung beschreibt typische Integrationsbereiche – der konkrete Funktionsumfang eines Projekts hängt immer von den tatsächlich benötigten Geschäftsprozessen ab, nicht von einer pauschalen Liste.
Fehlertoleranz und Monitoring
Für produktionsreife Connectoren gelten feste Grundregeln: keine stillen Fehler (Silent Errors), keine unterdrückten Exceptions, vollständiges Logging jedes Vorfalls, eine automatische Retry-Strategie und das Verschieben nicht verarbeitbarer Nachrichten in eine Dead Letter Queue statt eines stillen Datenverlusts.
Strukturiertes Logging umfasst dabei mindestens: Timestamp, Correlation-ID, die betroffene Entität, die relevante Business-Key-Referenz, HTTP-Status, Laufzeit und den aktuellen Retry-Zähler. Alle externen API-Aufrufe verwenden definierte Timeouts sowie Exponential Backoff mit Jitter; HTTP 429 sowie die Serverfehler 500, 502, 503 und 504 gelten grundsätzlich als Kandidaten für einen automatischen Retry – vorausgesetzt, die wiederholte Operation ist nachweislich idempotent.
Im laufenden Betrieb überwacht ein Observability-Setup (etwa Grafana, Prometheus, Loki) technische Metriken wie CPU- und Datenbankauslastung sowie den Füllstand der Message Queue, ergänzt um fachliche Kennzahlen wie die Anzahl der Bestellungen pro Stunde. Fällt die API-Erreichbarkeit ab, löst das System automatisch einen Alarm aus – statt dass ein Ausfall erst durch Kundenbeschwerden auffällt.
Referenzarchitektur im Überblick
Die vollständige Architektur eines produktionsreifen Connectors:
Shopware 6
│
Event / Order / Stock Change
│
▼
RabbitMQ Message Queue
│
▼
Connector (Consumer)
│
Odoo 19 JSON-2 API
│
▼
PostgreSQL (ERP-Datenbank)Diese Struktur ist bewusst modular: Jede Komponente (Producer, Queue, Consumer, API-Client) lässt sich unabhängig testen, überwachen und bei Bedarf austauschen, ohne die übrigen Komponenten zu berühren. Konfigurationswerte wie API-Keys, URLs, Timeouts und Zugangsdaten werden dabei niemals im Quellcode versioniert, sondern ausschließlich über Environment Variables oder ein Secret-Management-System bereitgestellt.
Projektstruktur: Python oder Symfony
Für performante ETL- und Connector-Prozesse empfiehlt sich eine modulare Projektstruktur, unabhängig von der gewählten Sprache. In Python-basierten Migrationswerkzeugen hat sich eine Aufteilung in eigene Module für Konfiguration, Authentifizierung, API-Client, Retry-Logik, Datenmapping sowie separate Module je Entität (Produkte, Kunden, Bestände, Bestellungen) bewährt, ergänzt um ein dediziertes Logging-Modul und eine eigene Test-Suite.
Wird der Connector stattdessen direkt im Shopware-Frontend integriert, folgt er der etablierten Symfony-Architektur: ein eigener Odoo-Namespace mit getrennten Verzeichnissen für den API-Client, Data Transfer Objects (DTOs), Mapper-Klassen, Messenger-Nachrichten und deren Handler, Services, Repositories, Exceptions und CLI-Commands. Diese Trennung erlaubt es, einzelne Bausteine – etwa den reinen API-Client – unabhängig zu testen und bei Bedarf auch außerhalb des Connectors wiederzuverwenden.
Testing: Die empfohlene Testpyramide
Ein produktionsreifer Connector durchläuft vor jedem Release eine feste Testpyramide: Unit Tests → Integration Tests → API Tests → Load Tests → Smoke Tests → Go-Live Tests. Unit Tests prüfen einzelne Funktionen isoliert, Integrationstests das Zusammenspiel mehrerer Komponenten, API-Tests die tatsächliche Kommunikation mit Odoo, Shopware und PlentyONE, Lasttests das Verhalten unter realistischem Bestellvolumen, Smoke-Tests die grundlegende Funktionsfähigkeit nach einem Deployment, und Go-Live-Tests die vollständige End-to-End-Funktionalität unmittelbar vor der produktiven Freigabe. Jede dieser Stufen deckt unterschiedliche Fehlerklassen ab – wird eine übersprungen, verschiebt sich die Fehlerentdeckung tendenziell in Richtung Livebetrieb.
Deployment und CI/CD-Pipeline
Die Referenzarchitektur setzt auf isolierte, versionierte und unveränderliche (immutable) Container für den Connector selbst. Eine automatisierte CI/CD-Pipeline sichert Code-Qualität und Stabilität über eine feste Abfolge von Stationen: Linting, statische Codeanalyse, Unit-Tests, Integrationstests, Docker-Build, Deployment auf eine Staging-Umgebung und erst danach das Deployment in die Produktivumgebung. Ein fehlschlagender Schritt an jeder dieser Stationen stoppt die Pipeline automatisch, statt fehlerhaften Code ungeprüft weiterzureichen.
Coding Standards
Professionelle Entwicklung verlangt Konsequenz über das gesamte Projekt hinweg: Für Python-Komponenten gelten PEP 8, statisches Typing sowie automatisierte Tools wie Ruff und Black zur Formatierung. Für PHP-Komponenten im Shopware-Frontend greifen PSR-12, PHPStan, Rector und der CS Fixer. SQL-Skripte für Validierung und Reporting nutzen explizite Spaltenangaben statt Wildcard-Selects, EXPLAIN ANALYZE zur Performanceprüfung, saubere Transaktionsgrenzen und optimierte Indizes. Für jede Referenzimplementierung werden zudem eine eindeutige Versionsnummer sowie die exakt getesteten Odoo-, Shopware- und Python-/PHP-Versionen dokumentiert, damit Implementierung und Referenzdokumentation langfristig konsistent bleiben.
Der Connector ist die dauerhafte Verbindung nach abgeschlossener Migration. Den Weg dorthin – von der Systemanalyse bis zum Cut-over – beschreibt unser Überblick zur Migration von PlentyONE zu Odoo.
Performante Odoo-Shopware-Integration anfragen
Eine belastbare, asynchrone Integrationsarchitektur zwischen Ihrem bestehenden Shopware-6-Frontend und Odoo 19 lässt sich nicht von der Stange kaufen – sie muss zu Ihren tatsächlichen Datenflüssen, Lastprofilen und Geschäftsprozessen passen. Genau das erarbeiten wir im Rahmen unseres kostenlosen, unverbindlichen E-Commerce Audits. Für eine erste Einschätzung Ihrer Systemlandschaft sprechen Sie uns direkt an.
Lassen Sie Ihre Integrationsarchitektur technisch bewerten – kostenfrei und unverbindlich.
Jetzt Integrationsaudit anfordern
„Wir befürchten, dass eine neue Schnittstelle unseren Checkout instabiler macht statt stabiler.“ Genau das Gegenteil ist das Ziel dieser Architektur: Die konsequente Entkopplung über eine Queue macht den Checkout unabhängiger vom ERP-System – nicht abhängiger.
„Unser Entwicklerteam kennt sich mit RabbitMQ oder Symfony Messenger nicht aus.“ Das ist kein Hindernis für den Projektstart. Wir übernehmen die Architektur und Implementierung vollständig inhouse und übergeben ein dokumentiertes, wartbares System – inklusive Monitoring, das auch ohne tiefes Messaging-Fachwissen verständlich bleibt.
„Wie stellen wir sicher, dass die Integration auch nach dem Projekt zuverlässig läuft?“ Durch das beschriebene Observability-Setup mit automatischer Alarmierung sowie eine klare Dokumentation der Architektur, die auch Ihr internes Team oder ein Nachfolgepartner nachvollziehen kann.
✔ kostenlos ✔ unverbindlich ✔ asynchrone Architektur statt blockierender Schnittstellen ✔ Antwort innerhalb von 24 Stunden
Häufig gestellte Fragen zum Odoo-Shopware-Connector
Ist RabbitMQ für jede Odoo-Shopware-Integration zwingend erforderlich?
Nein. RabbitMQ ist die in unserer Referenzarchitektur verwendete, konkrete Message-Queue-Lösung. Entscheidend für die Architektur ist das zugrunde liegende Muster einer asynchronen, ereignisbasierten Entkopplung – welches konkrete Produkt diese Rolle übernimmt, richtet sich nach Ihrer bestehenden Infrastruktur und Ihren Präferenzen.
Was passiert bei einem Ausfall der Message Queue selbst?
Eine produktionsreife Queue-Architektur läuft redundant und wird über dasselbe Observability-Setup überwacht wie die übrigen Systemkomponenten. Ein kurzzeitiger Ausfall würde durch automatische Alarmierung sofort erkannt, bevor er sich auf den Checkout auswirkt.
Können wir eine bestehende synchrone Integration schrittweise auf diese Architektur umstellen?
Ja. Die Umstellung lässt sich in der Regel entitätsweise vornehmen – etwa zunächst für Bestellungen, danach für Bestände und Preise – statt die gesamte Integration in einem einzigen, risikoreichen Schritt auszutauschen.
Christopher Einenkel
Christopher Einenkel ist der strategische Kopf der HQ GmbH für hochentwickelte Systemintegrationen und komplexe API-Architekturen. Immer wenn Datensynchronisationen an harte Grenzen stoßen oder anspruchsvolle Enterprise-Systeme wie Salesforce an Shopify angebunden werden müssen, konzipiert er maßgeschneiderte, hochperformante Schnittstellen-Logiken.
Sein Track Record umfasst die Eigenentwicklung proprietärer Enterprise-Lösungen, darunter automatisierte KI-Übersetzungstools für Artikelstammdaten, lückenlose B2B-Einkaufssysteme sowie automatisierte Marktbewertungs- und Wettbewerbsüberwachungen. Darüber hinaus steuert er für unsere Großkunden die technische Implementierung und API-Vernetzung digitaler Software-Callcenter-Anlagen in bestehende CRM- und ERP-Landschaften.
