Fehlerbehandlung in Make: Szenarien, die nicht still sterben
Ein Automatisierungsszenario ohne Fehlerpfad meldet sich nicht, wenn es abbricht. Es hört einfach auf zu wirken — und niemand merkt es, bis jemand nach einem Ergebnis sucht, das nie entstanden ist.
Automatisierungen fallen selten mit einem Knall aus. Sie hören auf zu wirken. Der Newsletter wird nicht mehr verschickt, der Beitrag nicht mehr veröffentlicht, der Datensatz nicht mehr übertragen — und weil kein Fehler sichtbar wird, fällt es erst auf, wenn jemand ein Ergebnis sucht, das nie entstanden ist.
Wir betreiben ein Make-Szenario, das Beiträge über acht Kanäle veröffentlicht. Was wir daran gelernt haben, steht hier — nicht als Werkzeugvorstellung, sondern als Betriebsfrage.
Was ohne Fehlerpfad passiert
Bricht ein Modul in Make ab, endet der Durchlauf. Je nach Einstellung des Szenarios landet er als unvollständige Ausführung in einer Warteliste oder er verschwindet. Beides ist stiller, als es klingt:
- Die Warteliste sieht niemand, solange niemand sie öffnet.
- Nach wiederholten Fehlern deaktiviert Make das Szenario selbstständig. Die Benachrichtigung darüber geht an die Adresse des Kontos — nicht zwangsläufig an die Person, die für den Prozess verantwortlich ist.
- Ein fachlich falsches Ergebnis ist überhaupt kein Fehler. Wenn ein Modul einen leeren Wert liefert und das nächste damit weiterarbeitet, läuft der Durchlauf sauber durch und erzeugt Unsinn.
Der dritte Punkt ist der gefährlichste. Fehlerbehandlung ist deshalb mehr als das Abfangen von Ausnahmen — sie umfasst die Frage, ob das Ergebnis plausibel ist.
Die Wege, die Make anbietet
An jedes Modul lässt sich ein Fehlerpfad hängen. Fünf Wege stehen zur Wahl, und die Auswahl ist keine Geschmacksfrage:
| Weg | Was er tut | Wann er passt |
|---|---|---|
| Resume | Ersatzwert einsetzen, weiterlaufen | Das Modul liefert eine Ergänzung, die fehlen darf |
| Ignore | Diesen Datensatz überspringen | Bei Massenverarbeitung, wenn Einzelfehler tolerierbar sind |
| Break | Durchlauf anhalten, für Wiederholung vormerken | Vorübergehende Störungen: Zeitüberschreitung, Ratenbegrenzung |
| Commit | Beenden, bisherige Schreibvorgänge behalten | Wenn Teilergebnisse gültig sind |
| Rollback | Beenden, Schreibvorgänge zurücknehmen | Wenn ein halber Datensatz schlimmer ist als keiner |
Die wichtigste Unterscheidung ist vorübergehend gegen dauerhaft. Eine Zeitüberschreitung verschwindet beim nächsten Versuch — dafür ist ein Wiederholungspfad richtig. Eine fehlende Berechtigung verschwindet nie. Sie zu wiederholen erzeugt nur mehr Fehlversuche und verdeckt die Ursache.
Unser Fall dazu: Eine Veröffentlichungsschnittstelle antwortete mit einem Berechtigungsfehler, nachdem eine Verbindung serverseitig ihre Gültigkeit verloren hatte. Ein Wiederholungspfad hätte den Durchlauf beliebig oft scheitern lassen. Richtig war: anhalten, melden, benennen, welche Verbindung betroffen ist. Der Fehler war in Minuten behoben — weil klar war, was zu tun ist, nicht weil das System es selbst gelöst hätte.
Jeder Fehlerpfad endet in einer Meldung
Ein Fehlerpfad, der still ins Leere führt, ist kein Fortschritt gegenüber keinem Fehlerpfad. Jeder unserer Pfade endet in einer Nachricht in den Kanal, in dem die Zuständigen ohnehin arbeiten.
Eine brauchbare Meldung beantwortet vier Fragen:
- Welches Szenario und welcher Schritt?
- Welcher Datensatz — eine fachliche Kennung, nicht die interne ID
- Was ist passiert — die Fehlerklasse, nicht nur „Fehler"
- Was ist zu tun — wiederholen, Verbindung erneuern, Daten korrigieren
Punkt 4 unterscheidet eine nützliche von einer lästigen Meldung. Eine Meldung, die niemand einordnen kann, wird nach zwei Wochen ignoriert — und dann ist sie schlimmer als keine, weil sie ein falsches Sicherheitsgefühl erzeugt.
Warteschlange statt paralleler Durchläufe
Sobald mehrere Durchläufe dieselbe Ressource anfassen, reicht Fehlerbehandlung allein nicht. Zwei gleichzeitig startende Durchläufe überholen sich, und die Reihenfolge, in der Dinge passieren, wird zufällig.
Wir lösen das mit einem Data Store als Warteschlange: Aufträge werden eingereiht, ein Worker nimmt sie in der Reihenfolge ihres Eingangs ab. Drei getrennte Worker für drei Veröffentlichungsstufen, jeder mit eigenem Fehlerpfad. Ein hängender Auftrag blockiert damit nicht die anderen Stufen, und die Reihenfolge innerhalb einer Stufe bleibt erhalten.
Der Aufwand dafür ist überschaubar; der Ertrag ist, dass Fehler reproduzierbar werden. Ein Fehler, der nur bei bestimmter zeitlicher Überlappung auftritt, kostet mehr Stunden als die Warteschlange je gekostet hat.
Was wir vor der Übergabe prüfen
Ein Szenario gilt uns erst dann als betriebsbereit, wenn diese Punkte nachweisbar erfüllt sind:
| Prüfung | Nachweis |
|---|---|
| Jedes Modul mit Außenanbindung hat einen Fehlerpfad | im Szenario sichtbar |
| Jeder Fehlerpfad endet in einer Meldung | Testauslösung durchgeführt |
| Der Fehlerpfad wurde einmal echt durchlaufen | Meldung liegt vor |
| Warteschlange bei gemeinsamen Ressourcen | Data Store vorhanden |
| Plausibilitätsprüfung des Ergebnisses | Bedingung im Szenario |
| Betriebsdokumentation | wer ist zuständig, was tun bei Meldung |
Die dritte Zeile ist die, die am häufigsten fehlt. Ein Fehlerpfad, der nie gelaufen ist, ist eine Vermutung. Wir lösen ihn deshalb absichtlich aus — falsche Zugangsdaten, unerreichbare Adresse — und sehen nach, ob die Meldung ankommt und ob sie verständlich ist.
Was Automatisierung nicht ersetzt
Ein automatisiertes Szenario braucht jemanden, der die Meldungen liest. Wir übernehmen den Betrieb einer Automatisierung nur, wenn wir Zugang zu ihren Fehlerpfaden haben — ein Szenario, dessen Fehler wir nicht sehen, können wir nicht verantworten.
Das ist keine formale Einschränkung, sondern die Lehre aus dem Betrieb: Der Aufwand liegt nicht im Bauen. Er liegt darin, dass jemand hinsieht, wenn etwas nicht funktioniert.
Dasselbe Muster gilt außerhalb von Make. Ein Übersetzungslauf, der Fehler verschluckt, verbraucht Budget ohne Ergebnis — wie das im Shopware-Kontext aussieht, steht in Produktdaten übersetzen, ohne Daten zu verlieren. Und eine Erweiterung, die nach einem Update still nichts mehr tut, ist derselbe Fehlertyp in einem anderen System: wenn der Shopware-Kern eine Plugin-Route verdrängt.
Wenn Sie damit anfangen
Der schnellste Gewinn ist nicht ein neues Szenario, sondern eine Bestandsaufnahme der vorhandenen: Welche laufen? Welche haben einen Fehlerpfad? Wer bekommt die Meldung? Bei den meisten Beständen, die wir gesehen haben, ist die Antwort auf die letzten beiden Fragen „keiner".
Was wir im Bereich Automatisierung anbieten, ordnet Content & Social Media ein; die technische Anbindung an Shops und Systeme gehört zu App- und Plugin-Entwicklung.
Häufige Fragen
- Was passiert in Make ohne Error-Handler?
- Der Durchlauf bricht ab. Je nach Einstellung landet er als unvollständige Ausführung in einer Warteliste oder verschwindet ganz. In beiden Fällen bekommt niemand eine Nachricht — der Abbruch ist nur im Verlauf sichtbar, wenn jemand hinsieht.
- Welcher Error-Handler ist der richtige?
- Das hängt davon ab, ob der Fehler vorübergehend ist. Bei Zeitüberschreitungen und Ratenbegrenzungen ist ein Wiederholungspfad richtig, bei fehlenden Berechtigungen nicht — dort hilft nur melden und anhalten.
- Brauche ich eine Warteschlange?
- Sobald mehrere Durchläufe dieselbe Ressource anfassen, ja. Ohne Warteschlange überholen sich Durchläufe und erzeugen Reihenfolgefehler, die schwer zu reproduzieren sind.
- Reicht die eingebaute Benachrichtigung von Make?
- Als Grundabsicherung ja, als Betriebslösung nein. Sie meldet, dass ein Szenario deaktiviert wurde — nicht, dass ein einzelner Durchlauf fachlich das Falsche getan hat.