Trigger, Webhooks und ereignisgesteuerte Prozesse

Trigger, Webhooks und ereignisgesteuerte Prozesse

0:00 Bis hierhin haben wir Workflows gebaut, die wir selbst gestartet haben. Jetzt kommt die Außenwelt ins Spiel. Ein Webhook ist nämlich nichts anderes als eine Tür in Ihr Netz, die Sie selbst einbauen — und wer eine Tür einbaut, baut auch das Schloss. Dieses Modul behandelt beides: wie Sie Ereignisse von außen entgegennehmen, und wie Sie verhindern, dass jeder, der die Adresse kennt, Ihre Prozesse auslösen kann.

0:23 Dazu kommt ein Baustein, der auf den ersten Blick merkwürdig wirkt und sich später als einer der wichtigsten entpuppt: der, mit dem ein Workflow tagelang wartet, ohne zu laufen.

Trigger, Webhooks und ereignisgesteuerte Prozesse

0:34 Das letzte Modul des ersten Tages. Wir gehen die Trigger-Arten durch und klären die Grundsatzfrage: nachfragen oder benachrichtigt werden? Dann sehen wir uns den Webhook-Baustein genau an — mit seinen zwei URLs, die schon manchen eine Nachmittagssuche gekostet haben. Danach Formulare, Dialoge und Wartezustände. Und zum Schluss die Absicherung, denn alles, was Sie hier öffnen, ist von außen erreichbar.

Trigger-Arten und Integrationsmuster

0:58 Jeder produktive Workflow beginnt mit einer Bedingung. Welche das ist, entscheidet mehr über Ihre Architektur, als man zunächst denkt — vor allem die Frage, ob Sie regelmäßig nachsehen oder sich melden lassen. Ein Trigger-Node ist ein besonderer Baustein: Er führt den Workflow aus, sobald bestimmte Bedingungen eintreten.

1:17 Jeder produktive Workflow braucht mindestens einen davon — ohne Trigger passiert im Betrieb schlicht nichts. Eine Ausnahme kennen Sie schon: Der Manual Trigger dient dem Entwickeln und löst keine produktive Ausführung aus. Wenn Sie so wollen, ist der Trigger die Türklingel Ihres Workflows. Und wie bei einer Türklingel gibt es verschiedene Bauarten: eine, die läutet, wenn jemand drückt, und eine, bei der Sie regelmäßig selbst nachsehen, ob jemand vor der Tür steht.

1:44 Sechs Trigger-Arten, und sie sortieren sich nach der Frage, wer aktiv wird. Der Manual Trigger wartet auf Sie im Editor. Der Schedule Trigger auf einen Zeitpunkt — achten Sie hier auf die Zeitzone, wir hatten das im letzten Modul. Der Webhook wartet auf einen HTTP-Aufruf von außen, der Form-Trigger auf ein abgeschicktes Formular, das n8n selbst bereitstellt.

2:05 Der App-Trigger lässt sich von einem verbundenen Dienst benachrichtigen. Und der Chat-Trigger wartet auf eine Nachricht im Dialog — der wird ab Tag vier wichtig, wenn KI ins Spiel kommt. Das ist die Grundsatzentscheidung dieses Kapitels, und sie hat zwei ehrliche Seiten. Beim Abrufen fragt n8n regelmäßig nach und findet meistens nichts Neues — das kostet Aufrufe und erzeugt eine Verzögerung, die so groß ist wie Ihr Abfrageabstand, nie kleiner.

2:33 Beim Ereignis meldet sich die Gegenseite, sobald etwas passiert: sofort und sparsam. Aber, und das ist der Haken: Ereignisse gehen verloren, wenn niemand zuhört. War Ihre Instanz gerade nicht erreichbar, ist die Meldung weg. Abrufen holt sie beim nächsten Durchgang nach. Es gibt hier also kein Besser, sondern eine Abwägung zwischen Schnelligkeit und Robustheit.

2:56 Der erste Punkt ist der Zeitzonen-Klassiker aus dem letzten Modul, diesmal in seiner teuersten Form: Der nächtliche Lauf startet am Nachmittag. Der zweite ist eine Frage des Maßes — minütlich abfragen, obwohl der Prozess täglich einmal läuft; das summiert sich bei bezahlten Plänen. Der dritte ist eine Sorgfaltsfrage: Der App-Trigger wird benutzt, ohne zu prüfen, welche Ereignisse er wirklich meldet — viele melden weniger, als man annimmt.

3:21 Und der vierte ist ein Diagnoseproblem: Der Workflow hat zwei Trigger, und im Fehlerfall weiß niemand, welcher den Lauf ausgelöst hat.

Webhooks im Detail

3:29 Jetzt zum Webhook-Baustein selbst. Er hat mehr Einstellungen, als man auf den ersten Blick vermutet, und zwei davon entscheiden darüber, ob Ihr Aufrufer zufrieden ist oder in einen Timeout läuft. Der Webhook-Node hat zwei URLs, und dieser Unterschied ist die häufigste Fehlerquelle beim Einbinden fremder Systeme. Die Test-URL registriert n8n nur dann, wenn Sie gerade auf Listen for Test Event oder Execute workflow gedrückt haben und der Workflow nicht veröffentlicht ist — und dann erscheinen die Daten im Editor.

3:59 Die Produktions-URL registriert n8n beim Veröffentlichen, und der Lauf erscheint ausschließlich in den Executions. Merken Sie sich: Die Test-URL lauscht nur, wenn Sie danebensitzen. Wer sie bei der Gegenseite hinterlegt, bekommt später ein stummes System und keinen Fehler. Vier Einstellungen, die Sie bewusst treffen sollten. Die HTTP-Methode — die Gegenseite gibt sie meist vor.

4:21 Der Pfad, wahlweise mit Routenparametern; die Voreinstellung ist eine zufällige Zeichenkette, was gegen Kollisionen hilft, aber unschön ist, wenn Sie eine feste Adresse brauchen. Der Antwort-Statuscode und die zurückgegebenen Daten. Und, am wichtigsten, der Respond-Modus: Er entscheidet, wann der Aufrufer seine Antwort bekommt.

4:41 Das klingt nach einem Detail und ist in Wirklichkeit eine Architekturentscheidung — darum hat es die nächste Folie verdient. Vier Modi, und die Logik dahinter ist die Frage: Soll der Aufrufer warten? Bei Immediately antwortet n8n sofort mit einem Statuscode und der Meldung, dass der Workflow gestartet ist — das ist der richtige Modus für alles, was danach länger dauert.

5:04 When Last Node Finishes lässt den Aufrufer warten, bis der ganze Workflow durch ist; bequem, aber gefährlich, sobald ein fremder Dienst langsam antwortet. Mit dem Respond-to-Webhook-Baustein legen Sie den Antwortzeitpunkt selbst fest — das ist der sauberste Weg. Und Streaming schickt fortlaufend, während gearbeitet wird; dafür braucht es allerdings mindestens einen Baustein, der das unterstützt.

5:27 Der erste Punkt ist eine Zahl, die Sie kennen sollten: Die maximale Nutzlast liegt bei 16 Megabyte. Größere Aufrufe scheitern, ohne dass Ihr Workflow etwas davon merkt — der Fehler entsteht davor. Der zweite ist der Antwortzeitpunkt von eben, in seiner unangenehmen Variante: Der Aufrufer wartet minutenlang und bricht ab.

5:47 Der dritte passiert beim Aufräumen: Der Pfad wird von Hand gesetzt und kollidiert mit einem anderen Webhook. Und der vierte betrifft Dateien — Binärdaten kommen an, aber es ist keine Binary Property konfiguriert, also landen sie nirgends.

Dialog, Formular und Wartezustände

6:02 Jetzt zu einer Fähigkeit, die Automatisierung erst wirklich brauchbar macht: Ein Workflow darf warten. Tagelang, wenn nötig — ohne dabei Ressourcen zu belegen. Das ist die technische Grundlage für alles, was später mit menschlichen Freigaben zu tun hat. Der Wait-Node hält die Ausführung an und lagert die Daten in die Datenbank aus. Ist die Fortsetzungsbedingung erfüllt, lädt n8n sie zurück und macht weiter.

6:27 Fortgesetzt wird nach einer Zeitspanne, zu einem Zeitpunkt, auf einen Webhook-Aufruf hin oder nach dem Absenden eines Formulars. Das Auslagern ist der Punkt, auf den es ankommt: Der wartende Workflow belegt keinen Prozess. Denken Sie an einen Vorgang, der in die Ablage wandert, bis die Rückmeldung kommt — er liegt im Schrank, nicht auf dem Schreibtisch.

6:47 Genau deshalb sind auch sehr lange Wartezeiten unproblematisch. Diese eine Zeile ist der Schlüssel zu jedem Freigabeprozess, den Sie bauen werden. Die Variable liefert eine Adresse, die es zum Zeitpunkt des Schreibens noch gar nicht gibt — n8n erzeugt sie erst zur Laufzeit, und zwar je Ausführung neu. Sie schreiben also die Vorschrift, nicht den Wert.

7:08 Praktisch heißt das: Sie können diese Adresse in eine E-Mail oder eine Chat-Nachricht einsetzen, und wer sie aufruft, setzt genau diesen einen Vorgang fort. Und wenn mehrere Wait-Nodes in einem Workflow stehen, werden sie nacheinander fortgesetzt. Merken Sie sich die Zeile — ab Tag vier brauchen wir sie wieder. Vier Anwendungsfälle, und sie sind unterschiedlicher, als sie aussehen.

7:31 Freigaben: Der Prozess ruht, bis ein Mensch den Link aufruft — das ist der wichtigste Fall und begleitet uns durch das ganze Seminar. Rückfragen: Eine fehlende Angabe kommt über ein Formular nach, statt den Vorgang scheitern zu lassen. Ratenbegrenzung: Zwischen zwei Aufrufen wird bewusst pausiert, weil die Gegenseite sonst dichtmacht. Und das Warten auf fremde Vorgänge: Sie halten an, bis die andere Seite meldet.

7:56 Was diese Fälle eint: In allen vieren wäre die Alternative, den Vorgang abzubrechen und später neu zu starten — mit allem, was dabei verloren geht. Der erste Punkt ist der wichtigste dieser Folie: Die Fortsetzungs-URL wird verschickt, aber niemand sichert sie ab. Wer diese Adresse kennt, kann den Vorgang fortsetzen — auch jemand, der die Mail weitergeleitet bekommen hat. Der Wait-Node bietet dafür Authentifizierung an; nutzen Sie sie.

8:22 Der zweite: Es gibt keine Zeitgrenze, und der Lauf wartet unbegrenzt auf eine Antwort, die nie kommt. Der dritte ist ein Rechenfehler: Wartezeiten in Schleifen vervielfachen sich mit der Zahl der Durchläufe. Und der vierte ist fachlich: Beim Fortsetzen fehlt der Kontext, weil zwischenzeitlich anderswo etwas geändert wurde.

Eingehende Aufrufe absichern

8:42 Kommen wir zum Schloss für die Tür. Wer die URL kennt, kann den Prozess auslösen — das ist die schlichte Ausgangslage. Was n8n Ihnen dafür anbietet, und was es ausdrücklich nicht anbietet, sehen wir uns jetzt an. Der Webhook-Node kann Aufrufe authentifizieren. Zur Wahl stehen Basic Auth, Header Auth, JWT Auth — oder eben keine.

9:03 Und jetzt der Satz, den Sie sich merken sollten, weil er in vielen Konzepten falsch steht: Eine eingebaute Signaturprüfung gibt es nicht. Viele fremde Dienste signieren ihre Aufrufe, damit der Empfänger die Echtheit prüfen kann. n8n nimmt Ihnen das nicht ab. Wenn Sie Signaturen prüfen wollen, bauen Sie das als eigenen Schritt in den Workflow ein. Das ist gut machbar — man muss nur wissen, dass es nicht von selbst passiert.

9:30 Fünf Schritte, die aufeinander aufbauen. Wählen Sie zuerst eine Authentifizierung und hinterlegen Sie die Zugangsdaten als Credential — nicht im Node. Setzen Sie dann, wenn die Gegenstelle bekannt ist, die IP-Allowlist; alles andere bekommt eine Fehlerantwort. Steuern Sie offensichtlich unpassende Aufrufe früh aus. Bilden Sie einen Idempotenzschlüssel aus dem Nutzinhalt, damit Doppelläufe nicht zu doppelten Vorgängen werden.

9:56 Und legen Sie Antwortzeiten und Fehlerfälle bewusst fest, statt sie entstehen zu lassen. Wichtig zur Einordnung: Die Ausdrucksprüfung greift erst nach IP-Prüfung und Authentifizierung — und gilt für Test- wie Produktions-URL. Diese Einstellung wird gern missverstanden, deshalb vier Punkte zur Klarheit. Der Ausdruck wird gegen den eingehenden Aufruf ausgewertet; Sie kommen dabei an Rumpf, Header, Pfadparameter und Query heran.

10:21 Passt er nicht, antwortet n8n mit einem Erfolgs-Statuscode und legt gar keine Ausführung an — der Aufrufer merkt also nichts, und Ihr Kontingent bleibt unberührt. Und jetzt der Punkt, auf den es ankommt: Schlägt die Auswertung selbst fehl, wird der Aufruf durchgelassen und eine Warnung geschrieben. Das ist bewusst so gebaut, damit ein kaputter Ausdruck nicht Ihren Prozess anhält. Es macht diese Einstellung aber zu einem Filter, nicht zu einer Sicherheitsmaßnahme.

10:49 Der erste Punkt ist die Konsequenz aus der letzten Folie, und er ist wichtig genug für die Wiederholung: Only Run If wird als Sicherheitsmaßnahme verstanden — im Fehlerfall lässt es aber durch. Der zweite: Dieselbe Meldung wird zweimal zugestellt und zweimal verarbeitet; fremde Systeme wiederholen Aufrufe häufiger, als man denkt.

11:07 Der dritte ist eine Frage der Betriebssicherheit: Die Ratenbegrenzung fehlt, und ein fehlerhafter Client löst tausend Läufe aus. Und der vierte ist heimtückisch: Der Statuscode meldet Erfolg, obwohl der Workflow die Daten verworfen hat. Dann glaubt die Gegenseite, alles sei gut.

Übung

11:24 Sie bauen jetzt den öffentlichen Störungsmelder von Kesselwerk. Damit steht zum ersten Mal etwas in diesem Seminar im offenen Netz — entsprechend gehört die Absicherung diesmal zur Aufgabe, nicht zur Kür. Kesselwerk stellt Kundinnen und Kunden einen Störungsmelder zur Verfügung. Eine Meldung kommt als HTTP-Aufruf herein, wird geprüft, quittiert und anschließend weiterverarbeitet.

11:47 Und dann der Satz, auf den es ankommt: Fehlerhafte Aufrufe sollen eine verständliche Antwort bekommen, statt still zu verschwinden. Das ist kein Komfort für den Aufrufer, sondern Selbstschutz. Ein System, das stillschweigend verwirft, produziert Anrufe wie „Ich habe das doch gemeldet" — und niemand kann prüfen, wer recht hat.

12:07 Das Lernziel lautet: eingehende Aufrufe so annehmen, dass Annahme, Prüfung und Verarbeitung getrennt bleiben. Diese Trennung ist das eigentliche Muster — annehmen und quittieren ist schnell, verarbeiten kann dauern. Erfolgreich sind Sie, wenn ein gültiger Aufruf quittiert und verarbeitet wird, ein ungültiger einen passenden Statuscode erhält und ein zweimal gesendeter Aufruf nur einen Vorgang erzeugt.

12:29 Dieser dritte Punkt ist der anspruchsvollste. Wer früh fertig ist, ergänzt eine Rückfrage per Wait-Node, die über die Fortsetzungs-URL beantwortet wird — damit haben Sie den Freigabeprozess im Kleinen schon gebaut. Eine Stunde, fünf Schritte. Legen Sie den Webhook mit eigenem Pfad und Header Auth an. Prüfen Sie den Nutzinhalt gegen die erwarteten Felder und steuern Sie früh aus — bevor irgendetwas geschrieben wird.

12:54 Antworten Sie dann bewusst über den Respond-Baustein, und zwar bevor Sie verarbeiten; das ist die Trennung aus dem Lernziel. Bilden Sie den Idempotenzschlüssel und erkennen Sie bereits verarbeitete Meldungen. Und rufen Sie zum Schluss Test- und Produktions-URL nacheinander auf und halten Sie die Unterschiede fest — wo die Daten jeweils auftauchen, ist die beste Übung zum Thema der zweiten Folie.

13:16 Vier Fallen. Erstens: Die Antwort geht erst nach der Verarbeitung heraus, und der Aufrufer läuft in einen Timeout — genau der Fehler, den Schritt drei verhindern soll. Zweitens: Der Idempotenzschlüssel wird aus dem Zeitstempel gebildet und ist deshalb nie zweimal gleich; er muss aus dem fachlichen Inhalt kommen. Drittens: Getestet wird nur der gültige Fall, weil der ungültige unbequem ist — dabei ist er die halbe Aufgabe.

13:42 Und viertens: Die Zugangsdaten stehen im Pfad statt im Header und landen damit in jedem Server-Log, das der Aufruf unterwegs passiert.