Workflows, Nodes und Executions verstehen

Workflows, Nodes und Executions verstehen

0:00 Im ersten Modul haben wir entschieden, was überhaupt automatisiert gehört. Jetzt sehen wir uns an, womit man das tut. Dieses Modul ist der Rundgang durch das Werkzeug — aber einer mit einer bestimmten Brille auf. Es geht nicht darum, wo welcher Knopf sitzt; das findet man beim Klicken heraus. Es geht um drei Unterscheidungen, an denen später die wirklich ärgerlichen Fehler hängen: welche Rolle ein Baustein im Ablauf spielt, was der Unterschied zwischen einem Testlauf und einem echten Lauf ist, und woran man erkennt, dass ein Ergebnis auf dem Bildschirm gar nicht mehr aktuell ist.

Workflows, Nodes und Executions verstehen

0:32 Wir bleiben am ersten Tag und werden konkret. Zuerst die Bausteine und die Fläche, auf der sie liegen. Dann die vielleicht wichtigste Unterscheidung überhaupt: gespeichert ist nicht veröffentlicht. Danach geht es um reproduzierbare Tests — also darum, wie Sie denselben Fall zweimal auslösen, ohne jedes Mal ein fremdes System anzurufen.

0:52 Und zum Schluss um Ordnung, denn der zwanzigste Workflow entscheidet über die Wartbarkeit, nicht der erste.

Oberfläche, Canvas und Node-Typen

0:59 Fangen wir mit dem an, was Sie den ganzen Tag vor Augen haben werden: der Arbeitsfläche und den Bausteinen darauf. Es sind wenige Rollen, aber sie verwechselt man leicht — und wer sie verwechselt, sucht Fehler später an der falschen Stelle. Nodes sind die einzelnen Bestandteile, aus denen ein Workflow entsteht. Sie legen fest, wann er läuft, sie holen, senden und verarbeiten Daten, sie bilden Ablauflogik ab und verbinden externe Dienste.

1:24 Die Canvas ist die Fläche, auf der Sie das anordnen. Der Vergleich, der hier trägt, ist eine Werkbank: Auf ihr liegen Werkzeuge nebeneinander, aber die Reihenfolge, in der Sie sie benutzen, steht nicht auf der Werkbank — sie steht in Ihrem Kopf. In n8n steht sie in den Verbindungen. Deshalb sagt die Anordnung auf dem Bildschirm allein noch nicht, was wann geschieht.

1:46 Diese vier Rollen sollten Sie auseinanderhalten können, und zwar aus einem sehr praktischen Grund. Ein Trigger bestimmt, wann der Workflow überhaupt anfängt — ohne ihn passiert im Betrieb gar nichts. Action-Nodes tun die eigentliche Arbeit an den Daten. Core-Nodes kümmern sich um den Ablauf: verzweigen, warten, zusammenführen.

2:05 Und Cluster-Nodes sind der Sonderfall, der die meisten Missverständnisse erzeugt: Sie bestehen aus einem Root-Node und Sub-Nodes, die daran hängen. Die Schichtung im Bild ist absichtlich keine Kette — denn genau als Kette liest man sie zuerst, und genau das ist falsch. Bleiben wir kurz bei den Cluster-Nodes, denn sie begegnen uns ab Tag vier ständig.

2:27 Ein Cluster-Node ist ein Verbund: ein Root-Node, der die eigentliche Funktion trägt, und ein oder mehrere Sub-Nodes, die ihn erweitern. Denken Sie an eine Bohrmaschine mit Aufsätzen. Der Aufsatz ist kein eigener Arbeitsschritt — niemand bohrt erst und setzt dann den Aufsatz ein. Er gehört zur Maschine. Genauso ist ein Modell oder ein Speicher, der an einem KI-Baustein hängt, kein Schritt im Ablauf, sondern Zubehör dieses Bausteins.

2:52 Wer das als Reihenfolge liest, wundert sich später über die Ausführungsreihenfolge. Vier Folgerungen, die im Alltag sofort greifen. Erstens: Jeder produktive Workflow braucht mindestens einen Trigger, sonst startet er nie — das klingt banal, ist aber der häufigste Grund dafür, dass ein fertiger Workflow im Betrieb schweigt.

3:12 Zweitens: Der Manual Trigger ist der einzige, der keine produktive Ausführung auslöst; er ist ein Entwicklungswerkzeug. Drittens: Sub-Nodes sind kein Schritt im Ablauf. Und viertens, die Konsequenz aus allem: Wer Cluster-Nodes als Kette liest, sucht den Fehler an der falschen Stelle — und findet ihn dort naturgemäß nicht.

3:33 Der erste Punkt ist der Klassiker der ersten Woche: Der Workflow wird mit dem Manual Trigger gebaut, funktioniert wunderbar, und dann wartet man vergeblich auf den produktiven Lauf. Der zweite ist der Denkfehler von eben. Der dritte ist eine Frage der Disziplin: Die Canvas wächst nach rechts, bis niemand mehr den Anfang sieht — dagegen helfen Gruppen und Notizen, dazu kommen wir im vierten Kapitel.

3:55 Und der vierte ist tückisch, weil er lautlos ist: Verbindungen werden gezogen, ohne zu prüfen, welcher Ausgang eines Nodes gemeint war. Bei einem If-Node sind das zwei sehr verschiedene Wege.

Ausführungen, Versionen und URLs

4:07 Jetzt kommt die Unterscheidung, die ich für die wichtigste dieses Moduls halte: Was Sie im Editor sehen, und was im Betrieb tatsächlich läuft, sind zwei verschiedene Dinge. Wer das verinnerlicht hat, spart sich eine ganze Klasse von Überraschungen. n8n speichert Ihre Änderungen automatisch, üblicherweise binnen ein bis fünf Sekunden, und legt dabei jeweils eine neue Version an.

4:29 Aber — und das ist der Punkt — alle Änderungen bleiben Entwurf, bis Sie den Workflow veröffentlichen. Produktive Läufe nutzen immer die veröffentlichte Version, nie Ihren letzten Stand. Das ist wie bei einer Zeitung: Sie können am Text arbeiten, so lange Sie wollen; gelesen wird die Ausgabe, die gedruckt wurde. Übrigens hieß das früher Aktivieren und Deaktivieren — mit n8n 2 heißt es Veröffentlichen. Der neue Name trifft es besser.

4:55 Hinter diesen drei Zeilen steckt eine Logik, die Sie sich merken sollten: Je weiter unten, desto ernster. Die manuelle Ausführung ist zum Bauen da — Sie sehen die Daten fließen. Die partielle Ausführung ist der Feinschliff: Sie führt einen einzelnen Baustein aus und alles, was davor nötig ist, um ihn mit Daten zu versorgen.

5:15 Das spart enorm Zeit, wenn Sie an Schritt sieben arbeiten. Und die produktive Ausführung ist der Ernstfall. Zwei Konsequenzen daraus: Sie ignoriert angeheftete Testdaten — dazu gleich mehr —, und sie zählt bei bezahlten Plänen gegen Ihr Kontingent. Veröffentlichen ist kein Speichern mit Nachdruck, sondern ein Schalter, der mehrere Dinge gleichzeitig umlegt.

5:36 Webhook- und Formular-Trigger wechseln auf ihre Produktions-URL — merken Sie sich das, es ist die Ursache für einen sehr häufigen Fehler. Zeitpläne laufen ab jetzt zu den festgelegten Zeiten. Und Ereignisse verbundener Anwendungen lösen den Workflow aus. Eine Feinheit am Rande, die gern verwirrt: Wenn Sie nur die Workflow-Einstellungen ändern, veröffentlicht n8n die Version von selbst neu.

5:59 Sie müssen also nicht rätseln, warum der Publish-Knopf plötzlich nichts tut. Vier Schritte, die zur Gewohnheit werden sollten. Bauen und manuell ausführen — das ist die Werkstatt. Dann veröffentlichen, und dabei Name und Beschreibung vergeben; die Voreinstellung ist eine Zeichenkette ohne Bedeutung, ein sprechender Name kostet zehn Sekunden und rettet später eine Fehlersuche.

6:22 Dann die produktiven Läufe im Reiter Executions beobachten — nicht im Editor, dort erscheinen sie nämlich nicht. Und bei Bedarf eine frühere Version wiederherstellen oder unveröffentlichen. Ein Hinweis zu benannten Versionen: Die setzen einen bezahlten Plan voraus, werden dafür aber nie automatisch aufgeräumt. Der erste Punkt ist der angekündigte Klassiker: Die Test-URL des Webhooks landet in der fremden Anwendung statt der Produktions-URL.

6:48 Die Gegenseite meldet Erfolg, und trotzdem passiert nichts — weil die Test-URL nur lauscht, wenn Sie gerade im Editor auf den Knopf gedrückt haben. Der zweite: Nach der Änderung wird nicht veröffentlicht, und produktiv läuft weiter die alte Version. Der dritte überrascht Teams: Nur eine Person kann einen Workflow gleichzeitig bearbeiten; die anderen sehen ihn schreibgeschützt.

7:10 Und der vierte: Unveröffentlichen ist kein Löschen — der Workflow bleibt, er ruht nur.

Reproduzierbare Tests und Execution History

7:16 Kommen wir zu einer Fähigkeit, die man unterschätzt, bis man sie einmal benutzt hat: denselben Fall beliebig oft auszulösen, ohne jedes Mal ein fremdes System anzurufen. Und zur Gegenfrage — woran erkennen Sie eigentlich, dass das Ergebnis auf dem Bildschirm noch stimmt? Datenanheftung friert die Ausgabe eines Bausteins während der Entwicklung ein.

7:36 Bei späteren Läufen führt n8n diesen Baustein nicht mehr aus, sondern setzt die eingefrorenen Daten ein und folgt der übrigen Logik ganz normal weiter. Stellen Sie sich ein Standbild in einem Film vor: Die Handlung läuft weiter, nur diese eine Einstellung bleibt stehen. Das Entscheidende steht im letzten Satz der Definition: Produktive Ausführungen ignorieren angeheftete Daten grundsätzlich.

7:58 Sie können also nichts vergessen, was Ihnen im Betrieb Testdaten unterschiebt — eine Entwarnung, die man kennen sollte. Vier gute Gründe, und der zweite ist der stärkste. Erstens: Der externe Dienst wird nicht bei jedem Versuch erneut aufgerufen — das schont fremde Ratenbegrenzungen und Ihre Nerven. Zweitens: Ein Fehlerfall lässt sich beliebig oft in derselben Form wiederholen. Ein Fehler, den Sie nicht wiederholen können, ist ein Fehler, den Sie nicht verstanden haben.

8:26 Drittens sind die Daten bearbeitbar — Grenzfälle entstehen also am Schreibtisch, nicht im Betrieb. Und viertens wird damit die ganze Verzweigung dahinter prüfbar, ohne dass draußen irgendetwas passiert. Jetzt zur Gegenfrage. Ein Dirty Node ist ein Baustein, der früher erfolgreich lief, dessen Ausgabe n8n aber inzwischen für veraltet hält.

8:46 Auf der Canvas erkennen Sie ihn an einem andersfarbigen Rand und einem gelben Dreieck statt des grünen Hakens. Das ist eine kleine, unauffällige Anzeige mit großer Wirkung: Sie sagt Ihnen, dass die Zahlen, die Sie gerade betrachten, aus einer anderen Welt stammen als der Stand Ihres Workflows. Wer darüber hinwegliest, optimiert eine halbe Stunde lang gegen ein Ergebnis, das es so gar nicht mehr gibt.

9:09 Das Prinzip hinter dieser Tabelle ist einfacher, als die Aufzählung vermuten lässt: Veraltet wird immer das, was von der Änderung abwärts betroffen sein könnte. Ändern Sie einen Parameter, gilt dieser Baustein selbst als veraltet. Fügen Sie einen Node ein oder löschen ihn, trifft es den ersten Baustein danach. Ziehen Sie eine Verbindung, trifft es deren Ziel. Und lösen oder ändern Sie eine Anheftung, trifft es den betroffenen beziehungsweise den folgenden Baustein.

9:36 Eine Besonderheit gilt in Schleifen: Dort gilt zusätzlich der erste Baustein der Schleife als veraltet, weil sich die Runde als Ganzes ändert. Der erste Punkt ist die Kehrseite des Anheftens: Die Daten bleiben stehen und täuschen einen funktionierenden Abruf vor. Sie glauben, die Anbindung läuft — in Wirklichkeit lesen Sie ein Standbild von vorgestern. Der zweite ist der gelbe Hinweis, über den man hinwegliest.

10:00 Der dritte betrifft partielle Ausführungen: Sie scheitern, wenn kein Trigger angeschlossen ist, denn auch eine Teilausführung will wissen, wann der Workflow gedacht ist zu starten. Und der vierte ärgert später: Execution-Daten werden erwartet, aber die Einstellung verwirft sie. Dann gibt es im Fehlerfall nichts anzusehen.

Ordnung im wachsenden Bestand

10:19 Zum Abschluss dieses Moduls ein Kapitel, das langweilig klingt und sich später auszahlt. Ordnung ist in Automatisierungsprojekten kein Selbstzweck: Sie entscheidet darüber, ob jemand anders den Workflow in zwei Jahren noch anfassen kann. Workflow-Einstellungen gelten je Workflow und regeln erstaunlich viel: Ausführungsreihenfolge, Fehler-Workflow, Zeitzone, Zeitüberschreitung und die Frage, welche Ausführungsdaten gespeichert oder geschwärzt werden.

10:46 Einen Wert sollten Sie sich besonders merken: Ohne gesetzte Zeitzone fällt n8n auf New York zurück. Das ist keine Schikane, sondern eine schlichte Voreinstellung — sie sorgt aber dafür, dass ein Lauf, den Sie für zwei Uhr nachts geplant haben, am Nachmittag startet. Und niemand sucht den Fehler zuerst in der Zeitzone. Vier Einstellungen, bei denen es sich lohnt, einmal bewusst hinzusehen.

11:09 Die Ausführungsreihenfolge v1 arbeitet Zweige nacheinander ab, von oben nach unten — die Lage auf der Fläche bestimmt also tatsächlich die Reihenfolge. Die Zeitzone haben wir gerade besprochen. Der Timeout bricht hängende Läufe ab, statt sie ewig stehen zu lassen; ohne ihn belegt ein wartender Lauf eine Ressource auf unbestimmte Zeit.

11:28 Und das Speichern des Ausführungsfortschritts erlaubt es, nach einem Fehler dort weiterzumachen, wo es hakte — das kostet allerdings Laufzeit und will abgewogen sein. Vier Mittel, die alle nichts kosten. Sticky Notes tragen Markdown und erklären einen Abschnitt genau dort, wo er liegt — nutzen Sie sie für das Warum, nicht für das Was.

11:48 Canvas Groups fassen zusammengehörige Bausteine zu einer benannten Einheit zusammen und lassen sich einklappen; auf einer großen Fläche ist das der Unterschied zwischen Übersicht und Suchbild. Tags und Ordner machen den Bestand durchsuchbar, bevor er unübersichtlich wird — und der richtige Zeitpunkt dafür ist vor dem zwanzigsten Workflow, nicht danach.

12:07 Projekte schließlich trennen nach Verantwortung; die sehen wir uns an Tag drei genauer an. Der erste Punkt ist erstaunlich langlebig: Namen wie Workflow 7 überleben Jahre und sagen nie, was der Workflow tut. Der zweite ist die Zeitzone, die ungesetzt bleibt — das kostet irgendwann eine nächtliche Fehlersuche. Der dritte ist eine Frage der Haltung: Sticky Notes, die beschreiben, was ohnehin dasteht, sind verschwendete Fläche; wertvoll wird die Notiz, wenn sie festhält, warum etwas so gebaut ist.

12:36 Und der vierte: Ordner und Projekte werden eingeführt, wenn schon hundert Workflows liegen — dann ist das Aufräumen ein Projekt für sich.

Übung

12:45 Jetzt bauen Sie zum ersten Mal selbst. Bewusst klein gehalten — geübt wird nicht die fachliche Tiefe, sondern der Weg vom Entwurf in den Betrieb. Genau der Weg, den wir gerade auseinandergenommen haben. Bei Kesselwerk meldet jemand über das Webformular eine Störung. Diese Meldung soll aufgenommen, um die Kundendaten aus Kundenkreis ergänzt und als Einsatz in Einsatzplan angelegt werden. Drei Schritte, mehr nicht.

13:09 Dass das inhaltlich überschaubar ist, ist Absicht: Sie sollen sich auf das konzentrieren, was zwischen Editor und Betrieb liegt. Erfahrungsgemäß ist genau das der Teil, der im Selbststudium untergeht — weil man ihn im Editor nicht sieht. Das Lernziel lautet: einen Workflow so testen, dass der produktive Lauf dasselbe tut wie der Test.

13:30 Das klingt selbstverständlich und ist es nicht — zwischen beiden liegen angeheftete Daten, zwei URLs und eine veröffentlichte Version. Erfolgreich sind Sie, wenn der Workflow veröffentlicht ist, ein produktiver Lauf in den Executions sichtbar ist und Sie nachweisen können, dass die angehefteten Testdaten ihn nicht beeinflusst haben.

13:48 Wer früh fertig ist, ändert einen Parameter und beobachtet, welche Bausteine dadurch als veraltet markiert werden — das ist die beste Art, die Tabelle von eben zu verstehen. Fünfzig Minuten, fünf Schritte. Bauen Sie zuerst Trigger, Anreicherung und Anlage als drei Bausteine auf. Heften Sie dann die Ausgabe der Anreicherung an und prüfen Sie die Verzweigungen dahinter — so sehen Sie, was bei unvollständigen Kundendaten passiert, ohne dass Sie solche Daten brauchen.

14:15 Setzen Sie Zeitzone und Fehler-Workflow in den Einstellungen; den Fehler-Workflow bauen wir an Tag drei richtig, hinterlegen ihn aber schon jetzt. Dann veröffentlichen und über die Produktions-URL einen echten Lauf auslösen. Und zuletzt: den Lauf in den Executions öffnen und mit dem Testlauf vergleichen. Vier Fallen bei genau dieser Übung.

14:36 Erstens: Getestet wird mit angehefteten Daten, veröffentlicht wird ohne einen echten Lauf — dann wissen Sie am Ende nicht, ob es produktiv funktioniert. Zweitens: Die Test-URL bleibt im Formular hinterlegt, und produktiv passiert nichts; das ist derselbe Stolperstein wie vorhin, nur diesmal in Ihrem eigenen Aufbau. Drittens: Veröffentlichen, ohne einen Fehler-Workflow zu hinterlegen — dann scheitert der Lauf stumm.

15:01 Und viertens: Die Executions werden gar nicht geöffnet, weil der Editor grün meldet. Der Editor kennt den produktiven Lauf aber nicht.