Flowpaja
Was Sie benötigen
- Ein Make.com-Szenario mit mindestens einem Modul, das fehlschlagen kann, etwa HTTP – Make a request oder Google Sheets
- Zugriff auf die Szenario-Einstellungen und den History-Tab
- Einen Ort für Benachrichtigungen, zum Beispiel Gmail oder Slack
Schritt für Schritt: Error-Handler-Route hinzufügen und Handler wählen
1. Wissen, was ohne Handler passiert
Ohne Handler hängt das Ergebnis von der Einstellung Store incomplete executions ab. Ist sie aus, wendet Make Rollback an: Der Lauf stoppt mit Fehlerstatus, und nach standardmäßig 3 Fehlern in Folge (Einstellung Number of consecutive errors) schaltet Make das Szenario ab. Ein Szenario mit sofortigem Trigger wird schon nach dem ersten Fehler abgeschaltet. Ist die Einstellung an, speichert Make den fehlgeschlagenen Lauf als Incomplete Execution, und der Lauf endet stattdessen mit einer Warnung. Module, die Transaktionen unterstützen, erkennbar am ACID-Tag, etwa Data-Store- oder MySQL-Module, machen ihre Änderungen rückgängig. Module wie Gmail, Google Sheets oder HTTP tun das nicht: Was sie bereits getan haben, bleibt getan.
2. Eine Error-Handler-Route hinzufügen
Klicken Sie mit der rechten Maustaste auf das Modul, das fehlschlagen kann, und wählen Sie Add error handler. Es entsteht eine Route, die vom Modul abzweigt. Alles, was Sie darauf platzieren, läuft nur, wenn dieses Modul einen Fehler meldet. Die Route muss nicht mit einem Error Handler enden: Schlägt auf ihr nichts fehl, überspringt Make den Fehler, eine Route nur mit einem Benachrichtigungsmodul verhält sich also wie Skip. An der ersten Verbindung der Route können Sie einen Filter setzen, damit unterschiedliche Fehler zu unterschiedlichen Handlern gelangen.
3. Den Error Handler am Ende der Route wählen
Was jeder einzelne tut, in einfachen Worten:
Skip (früher Ignore) entfernt das fehlgeschlagene Bundle aus dem Ablauf und macht mit dem nächsten weiter. Der Lauf endet mit Erfolgsstatus, nichts wird gespeichert. Nutzen Sie es, wenn der Verlust eines einzelnen Elements akzeptabel ist, etwa eine fehlerhafte Zeile in einem Stapel, die Sie anderswo protokollieren.
Resume ersetzt die Ausgabe des fehlgeschlagenen Moduls durch Werte, die Sie vorgeben, und das Szenario läuft nach diesem Modul weiter, als wäre es erfolgreich gewesen. Nutzen Sie es, wenn ein sinnvoller Standardwert existiert, etwa „unknown“ bei einer Suche ohne Treffer. Vorsicht: Diese Ersatzwerte fließen in alles ein, was danach kommt.
Retry (früher Break) entfernt das fehlgeschlagene Bundle aus dem Ablauf und speichert es mit den restlichen Schritten als Incomplete Execution, damit es später wiederholt werden kann, automatisch oder von Hand. Ist Automatically complete execution eingeschaltet, legen Sie Anzahl der Versuche und Abstand dazwischen fest. Die übrigen Bundles laufen weiter, und der Lauf endet mit einer Warnung. Nutzen Sie es, wenn die Daten wichtig sind und der Fehler wahrscheinlich vorübergehend ist, etwa ein Rate Limit oder ein Ausfall. Retry setzt voraus, dass Store incomplete executions in den Szenario-Einstellungen aktiviert ist; bis dahin markiert Make den Handler als fehlerhaft.
Rollback beendet den Lauf, markiert ihn als Fehler und macht Änderungen in Modulen rückgängig, die Transaktionen unterstützen. Er zählt zum Limit für aufeinanderfolgende Fehler. Nutzen Sie es nur, wenn Sie in etwas Transaktionales schreiben, etwa eine Datenbank, bei der ein halbes Update schlimmer wäre als keines.
Commit beendet den Lauf und übernimmt die bis dahin von transaktionalen Modulen vorgenommenen Änderungen. Die restlichen Module werden nicht verarbeitet, und der Lauf endet mit einer Warnung. Es ist das Gegenstück zu Rollback und wird bei Szenarien rund um Google Sheets und Gmail selten gebraucht.
4. Ein praktisches Beispiel mit HTTP – Make a request bauen
Angenommen, das Szenario liest Zeilen aus Google Sheets und sendet jede an eine API.
- Stellen Sie im HTTP-Modul Evaluate all states as errors (except for 2xx and 3xx) auf Yes. So heißt die Option in der Make-Dokumentation für die HTTP-Module (legacy); die neuere HTTP-App kann sie anders benennen. Sonst kann eine 429- oder 500-Antwort als Erfolg durchgehen. Mit dieser Einstellung steht der Antworttext eines fehlgeschlagenen Aufrufs auf der Fehlerroute meist nicht zur Verfügung.
- Fügen Sie dem HTTP-Modul eine Error-Handler-Route hinzu.
- Setzen Sie an der ersten Verbindung der Route einen Filter für Rate Limits und Serverfehler, zum Beispiel Statuscode 429 oder 500 und höher. Die genauen Feldnamen sehen Sie in der Fehlerausgabe eines fehlgeschlagenen Run once.
- Fügen Sie auf dieser Route den Error Handler Retry mit 3 Versuchen und einem Abstand von 10 Minuten hinzu. Das Bundle wird gespeichert und erneut versucht.
- Fügen Sie eine zweite Route für Clientfehler hinzu (ein 400 oder 404 wegen einer fehlerhaften Zeile). Senden Sie eine E-Mail oder Slack-Nachricht mit den Details der Zeile und dem Fehlertext, den Sie im Mapping-Panel aus der Fehlerausgabe des fehlgeschlagenen Moduls zuordnen, und beenden Sie mit Skip, damit eine fehlerhafte Zeile die übrigen nicht aufhält.
5. Ein Google-Sheets-Beispiel zum Protokollieren hinzufügen
Fügen Sie auf der Skip-Route vor dem Error Handler Google Sheets – Add a Row hinzu, in ein Blatt namens „Errors“, mit der Zeit {{now}}, dem Szenarionamen, dem betroffenen Datensatz und der Fehlermeldung. Ein Protokollblatt macht unsichtbare Fehler am nächsten Morgen lesbar.
6. Den Zusammenhang mit Incomplete Executions verstehen
Speichert Retry ein Bundle, erscheint es im Tab Incomplete executions des Szenarios. Dort können Sie es öffnen, den Fehler ansehen, die Ursache beheben und es wiederholen oder löschen. Sind automatische Wiederholungen eingestellt, versucht Make es von selbst erneut. Ist Process data in order aktiviert, verschiebt Make neue Läufe, bis die Incomplete Executions erledigt sind, schauen Sie also regelmäßig in den Tab. Tritt der Fehler im ersten Modul auf, speichert Make keine Incomplete Execution, außer dieses Modul hat einen Retry-Handler. Der Speicher für Incomplete Executions ist nicht unbegrenzt; prüfen Sie die aktuellen Limits Ihres Tarifs.
7. Den Handler absichtlich testen
Brechen Sie etwas gezielt: ein falscher API-Schlüssel oder eine ungültige URL, einmal ausführen und beobachten, welche Route läuft. Ein Handler, den Sie nie ausgelöst haben, ist ein Handler, von dem Sie nicht wissen, ob er funktioniert.
Häufige Fehler und Lösungen
Retry (Break) bringt nichts. Store incomplete executions ist in den Szenario-Einstellungen aus, also gibt es keinen Ort für das Bundle. Schalten Sie es ein und testen Sie erneut.
Fehler verschwinden spurlos. Skip (Ignore) wurde ohne Protokoll oder Benachrichtigung eingesetzt. Fügen Sie vor dem Error Handler immer eine Protokollzeile oder eine Benachrichtigung hinzu.
Nach einem Fehler tauchen falsche Daten weiter unten auf. Resume hat einen Platzhalterwert geliefert, und spätere Module haben ihn für echt gehalten. Verwenden Sie Resume nur mit unbedenklichen Werten, oder lassen Sie den leeren Wert in einen Filter laufen, der ihn stoppt.
Rollback hat die E-Mail oder die Tabellenzeile „nicht rückgängig gemacht“. Rollback macht nur transaktionale Module rückgängig. Gmail, Google Sheets und einfache HTTP-Aufrufe sind nicht abgedeckt. Wenn Teilarbeit vermieden werden muss, ordnen Sie die Module so an, dass der nicht umkehrbare Schritt zuletzt kommt.
Der Handler läuft bei HTTP 4xx oder 5xx nie. Das HTTP-Modul behandelt diese Antworten als erfolgreich. Aktivieren Sie die Option, die alle Nicht-Erfolgszustände als Fehler auswertet.
Wiederholungen erzeugen Dubletten. Retry führt die gespeicherte Ausführung erneut aus, und war der erste Versuch auf der Gegenseite teilweise erfolgreich, entsteht eine zweite Kopie. Senden Sie, wo die API es unterstützt, einen Idempotency-Key, oder prüfen Sie zuerst, ob der Datensatz schon existiert.