OBI ↔ Shopware Connector

Ausgangslage: Zwei Systeme, kein gemeinsamer Takt

OBI betreibt seinen Online-Marktplatz auf Basis der Mirakl-Plattform (MMP). Händler, die dort verkaufen, müssen ihren kompletten Katalog samt Preisen und Beständen einspielen und eingehende Bestellungen zurück in das eigene System holen. Ohne Automatisierung bedeutet das doppelte Pflege in zwei getrennten Welten — mit allen Folgen: veraltete Preise, überverkaufte Artikel und Bestellungen, die im Marktplatz-Backend hängenbleiben.

Für einen Shopware-6-Händler sollte genau dieser Aufwand verschwinden. Ziel war ein Connector, der Shopware als führendes System behandelt (Single Source of Truth), alle relevanten Änderungen automatisch nach OBI/Mirakl spiegelt und Bestellungen sowie Retouren in Gegenrichtung zuverlässig zurückspielt — nachvollziehbar, überwachbar und ohne manuelles Zutun im Tagesgeschäft.

Architektur: ein dünnes Plugin, ein robuster Connector

Die Lösung ist bewusst zweigeteilt. In Shopware läuft nur ein schlankes Plugin, das auf Entity-Events (Produkt, Preis, Bestand) lauscht und diese — entprellt, um Event-Stürme abzufangen — an den Connector meldet. Die eigentliche Logik liegt im Python-Connector: Mapping, Warteschlangen, Wiederholungen und die gesamte Mirakl-Kommunikation.

Dieses Modell hält Shopware frei von Marktplatz-Spezifika und macht den Connector unabhängig testbar und deploybar. Der Datenfluss ist klar gerichtet: Shopware pusht Katalog, Preis und Bestand nach OBI, während OBI-Webhooks Bestellungen und Statusereignisse zurück in Richtung Shopware auslösen.

Bidirektionaler Sync in der Praxis

Produktexporte folgen dem zweistufigen Mirakl-Ablauf: Zuerst wird das Produkt per CSV-Import angelegt (P41), nach erfolgreichem Import folgt das Angebot mit Preis und Bestand (OF24). Preis- und Bestandsänderungen laufen anschließend schlank nur noch über OF24. In Gegenrichtung holt der Connector Bestellungen (OR11) inklusive SKU-Lookup in den Shopware-Kontext und meldet Versand samt Tracking (OR23/OR24) sowie Rechnungen zurück.

Jeder Vorgang wird als Job protokolliert. Ein Dashboard zeigt Job-Status, Erfolgsquote und Aktivität, ein detailliertes Fehlerlog macht jede fehlgeschlagene Übertragung mit Ursache sichtbar. Für Sonderfälle stehen manuelle Aktionen bereit — einzelne Artikel, ganze Kategorien oder ein kompletter Bestell-Abgleich lassen sich jederzeit anstoßen.

• product.export / price.export / inventory.export: Shopware → OBI
• order.import: OBI → Shopware inkl. SKU-Lookup in den Shopware-Kontext
• fulfillment.export & invoice.export: Versand, Tracking & Rechnung zurück an OBI
• reconcile.*: geplanter Abgleich über Celery Beat

Go-Live mit Sicherheitsnetz

Ein Marktplatz-Anschluss scheitert selten an einem einzelnen Feature, sondern an Kleinigkeiten kurz vor dem Start: ein fehlendes Webhook-Secret, unvollständige Mappings, ein nicht laufender Worker. Deshalb bündelt ein Go-Live-Panel alle Bereitschaftsprüfungen an einer Stelle — von der Erreichbarkeit beider Systeme über gesetzte Secrets bis zu Anzahl und Vollständigkeit der Kategorie-, Marken- und Attribut-Mappings.

Über den Kategorie-Sync lassen sich komplette Shopware-Kategorien gezielt zu OBI/Mirakl exportieren; der Kategoriebaum ist direkt im Dashboard navigierbar. So wird der Rollout planbar und wiederholbar statt zum Blindflug.

Technik-Highlights & Ergebnis

Der Connector ist als eigenständiger FastAPI-Dienst mit Celery-Workern, Postgres und Redis aufgebaut und vollständig über eine OpenAPI-Spezifikation dokumentiert. Eingehende Shopware-Events und OBI-Webhooks sind sauber getrennte Endpunkte; eine HMAC-Signatur sichert die eingehenden Webhooks ab.

Im Betrieb erreichte die Integration über 1.700 ausgeführte Sync-Jobs bei 216 gepflegten Mappings eine Erfolgsquote von 90,7 %. Ein integriertes Betriebshandbuch dokumentiert Architektur, Konfiguration und Go-Live direkt im Dashboard — der Händler pflegt seinen Katalog weiterhin nur in Shopware, der Marktplatz bleibt automatisch synchron.