Shopware 6 Flow Builder: Warum Debugging zur echten Herausforderung wird

Der Shopware 6 Flow Builder ist eines der mächtigsten Werkzeuge im Shopware-Ökosystem. Mit ihm lassen sich Geschäftsprozesse automatisieren – ganz ohne Programmierkenntnisse, rein visuell per Drag-and-Drop. Bestellbestätigungen versenden, Zahlungsstatus ändern, Kunden taggen, Webhooks auslösen: All das funktioniert über Trigger, Conditions und Actions. In einer Zeit, in der laut McKinsey über 92 Prozent der Unternehmen ihre Investitionen in Automatisierung in den nächsten drei Jahren steigern wollen, ist der Flow Builder genau das richtige Werkzeug zur richtigen Zeit.

Bis etwas schiefgeht. Und niemand es merkt.

Das größte Problem: Stille Fehler

Wer den Flow Builder produktiv einsetzt, kennt das Szenario. Ein Flow ist konfiguriert, der Trigger feuert – aber die erwartete Aktion bleibt aus. Keine Fehlermeldung im Admin. Kein Eintrag im Log. Keine Warnung, kein Hinweis, nichts. Der Flow scheitert stillschweigend, und der Shopbetreiber erfährt davon erst, wenn sich ein Kunde meldet – weil die Bestellbestätigung nie ankam, die Rechnung nicht generiert wurde oder der Versandstatus sich nicht geändert hat.

Das ist kein Randphänomen. Ein Blick ins Shopware Community Forum zeigt dutzende Threads von Händlern mit exakt diesem Problem. Die Beiträge tragen Titel wie „Flow Builder verschickt keinerlei Mails", „Rechnungen automatisch erstellen klappt nicht" oder „Flow Builder funktioniert nicht mehr nach Update". Das Muster ist immer dasselbe: Etwas funktioniert nicht, aber es gibt keinen erkennbaren Grund dafür.

Selbst Shopware erkennt das Problem an

Besonders aufschlussreich ist ein internes Architektur-Dokument von Shopware, ein sogenannter Architecture Decision Record (ADR). Darin beschreibt das Shopware-Team einen konkreten Fall: Ein Händler hatte sich gemeldet, weil sein Shop keine E-Mails mehr versendete. Die Fehlersuche stellte sich als deutlich schwieriger heraus als erwartet. Shopware formuliert darin die klare Erkenntnis, dass der Flow Builder Händler befähigen soll, zuverlässige Workflows zu bauen – und nicht, ihre Zeit mit der Suche nach Fehlerursachen zu verschwenden.

Als Reaktion arbeitet Shopware an einem Flow Builder Preview, der bei der Erstellung neuer Flows helfen soll. Doch wie Shopware im selben Dokument einräumt, adressiert das nur die halbe Wahrheit. Die Preview hilft beim Bauen – aber nicht beim Überwachen laufender Flows. Was passiert, wenn ein Flow in der Produktion fehlschlägt? Welche Condition hat nicht gegriffen? Welche Action hat eine Exception geworfen? Diese Fragen bleiben im Standard unbeantwortet.

Warum der Flow Builder so schweigsam ist

Die Ursache liegt in der technischen Architektur. Der Flow Builder basiert auf dem Symfony EventDispatcher. Wenn ein Trigger-Event feuert, übergibt der FlowDispatcher die Daten an den FlowExecutor. Dieser prüft Conditions und führt Actions aus. Das Problem: Wenn eine Action intern eine Exception wirft, wird diese in vielen Fällen gefangen und geschluckt. Der Flow bricht ab, aber weder der Admin noch die Logdateien erfahren davon.

Im Produktivmodus, in dem nahezu alle Live-Shops betrieben werden, protokolliert Shopware nur schwerwiegende Fehler in der Datei unter /var/log/. Flow-Builder-Fehler fallen oft nicht in diese Kategorie. Der Entwicklermodus wiederum ist für den Dauerbetrieb ungeeignet – er legt sensible Daten offen, erhöht den Ressourcenverbrauch erheblich und kann laut Shopware-Dokumentation dazu führen, dass im Frontend anstelle der Shopseite eine technische Fehlermeldung erscheint.

Shopbetreiber stehen also vor einer Zwickmühle: Entweder sie betreiben ihren Shop sicher, aber blind. Oder sie schalten den Debug-Modus ein und riskieren Performance-Probleme und Datenschutzverstöße.

Die realen Kosten fehlender Transparenz

Die Auswirkungen stiller Flow-Fehler gehen weit über ein technisches Ärgernis hinaus. Eine nicht versendete Bestellbestätigung ist ein Vertrauensbruch gegenüber dem Kunden. Eine fehlende Zahlungserinnerung bedeutet verzögerter Cashflow. Ein nicht ausgelöster Webhook an das ERP-System kann zu Bestandsdifferenzen führen, die sich über Tage aufstauen.

Shopify formuliert es in einem aktuellen Artikel über Workflow-Automatisierung treffend: Ohne Dashboards und Fehler-Alerts können sich stille Fehler wochenlang unbemerkt aufstauen. Wer zehn, zwanzig oder mehr Flows im Einsatz hat – bei mittelgroßen Shops durchaus realistisch – verliert schnell den Überblick. Ein einziger fehlkonfigurierter Flow kann im schlimmsten Fall hunderte Bestellungen betreffen, bevor der Fehler auffällt.

Laut einer Forrester-Studie nutzen 82 Prozent der Unternehmen noch immer papierbasierte oder manuelle Prozesse mit Excel. Wer den Schritt zur Automatisierung gewagt hat, erwartet zu Recht, dass diese Automatisierung auch zuverlässig läuft – und nicht im Stillen versagt.

Was Shopbetreiber heute tun müssen

Die gängige Methode, einen fehlerhaften Flow zu debuggen, sieht heute so aus:

1. Entwicklermodus aktivieren 2. Den Fehler reproduzieren 3. Logdateien unter /var/log/ manuell durchsuchen 4. Alle Drittanbieter-Plugins deaktivieren 5. Plugins einzeln wieder aktivieren, bis der Fehler auftritt 6. Den Symfony Profiler konsultieren 7. Entwicklermodus wieder deaktivieren

Das ist ein Prozess, der Stunden dauern kann, tiefes technisches Verständnis voraussetzt und für die meisten Shopbetreiber ohne Entwickler-Hintergrund schlicht nicht machbar ist. Selbst erfahrene Agenturen berichten, dass die Fehlersuche im Flow Builder unverhältnismäßig viel Zeit frisst – weil es an einer zentralen Stelle fehlt, die zeigt, was tatsächlich passiert ist.

Was fehlt: Ein Logging- und Debugging-Werkzeug

Was der Flow Builder bräuchte, liegt auf der Hand: Eine Protokollierung jeder Flow-Ausführung – welcher Trigger hat gefeuert, welche Conditions wurden geprüft, welche Actions wurden ausgeführt, und vor allem: was ist fehlgeschlagen und warum. Eine zentrale Übersicht im Admin, die auf einen Blick zeigt, ob die Automatisierung des Shops gesund läuft oder ob es stille Fehler gibt.

Genau an dieser Stelle setzen wir mit DvShopwareFlowLogger an. Das Plugin befindet sich aktuell in der Entwicklung und wird als Erweiterung für den Shopware 6 Flow Builder konzipiert. Ziel ist es, die beschriebene Transparenzlücke zu schließen und Shopbetreibern ein Werkzeug an die Hand zu geben, das Flow-Ausführungen nachvollziehbar macht – ohne den Entwicklermodus aktivieren zu müssen, ohne Logdateien manuell zu durchsuchen, ohne Blindflug.

Details zu Funktionsumfang und Verfügbarkeit werden wir in den kommenden Wochen auf plugin-marktplatz.de veröffentlichen.

Fazit

Der Shopware 6 Flow Builder ist ein hervorragendes Automatisierungswerkzeug. Doch Automatisierung ohne Monitoring ist wie ein Motor ohne Ölstandsanzeige – er läuft, bis er nicht mehr läuft. Die fehlende Transparenz bei der Flow-Ausführung ist einer der größten Pain Points im Shopware-Ökosystem und betrifft Shopbetreiber, Agenturen und Entwickler gleichermaßen. Wer seine Flows produktiv einsetzt, braucht ein Werkzeug, das zeigt, was unter der Haube passiert. Nicht erst, wenn der Kunde sich beschwert.