Ablaufsteuerung und robuste Workflow-Architektur

Ablaufsteuerung und robuste Workflow-Architektur

0:00 Es gibt einen Moment in jedem n8n-Projekt, an dem die Zeichenfläche kippt. Bis dahin war sie übersichtlich, und plötzlich muss man scrollen, um den Anfang zu sehen. Das ist kein Schönheitsproblem: Eine Fläche, die niemand mehr überblickt, ist ein Monolith mit Symbolen — und Monolithen kann man nicht einzeln testen. Dieses Modul handelt von den Mitteln, mit denen man das verhindert: verzweigen, zusammenführen, zerlegen.

0:24 Und von den Mustern, die man braucht, wenn ein Vorgang über mehrere Schritte läuft und einer davon scheitert, nachdem der vorherige bereits gewirkt hat.

Ablaufsteuerung und robuste Workflow-Architektur

0:33 Wir bleiben am zweiten Tag und gehen von der Anbindung zur Architektur. Zuerst die Bausteine der Ablauflogik — verzweigen, filtern, zusammenführen, wiederholen. Dann die wichtigste Technik dieses Moduls: Sub-Workflows, also das Zerlegen einer großen Fläche in benannte Bausteine mit vereinbarter Schnittstelle. Danach die Muster für mehrstufige Prozesse. Und zum Schluss die Frage, wo eigentlich der Zustand eines Vorgangs liegt, wenn er länger dauert als ein Lauf.

Verzweigen, Zusammenführen und Schleifen

1:01 Fangen wir mit den Bausteinen an, aus denen jede Ablauflogik entsteht. Es sind wenige — und einer davon wird regelmäßig dort eingesetzt, wo er gar nicht gebraucht wird. Sechs Bausteine, und sie teilen sich in zwei Gruppen. Die ersten beiden verzweigen: If gibt Ihnen zwei Ausgänge nach einer Bedingung, Switch mehrere nach Regeln.

1:21 Filter sieht ähnlich aus, macht aber etwas anderes — er sortiert Items aus, ohne einen zweiten Weg zu eröffnen; wenn Sie den anderen Fall gar nicht brauchen, ist Filter die ehrlichere Wahl. Merge führt Zweige oder Datenquellen wieder zusammen. Compare Datasets gleicht zwei Bestände gegeneinander ab — sehr nützlich bei Synchronisationen.

1:41 Und Loop Over Items durchläuft Items portionsweise. Zu dem letzten gleich noch ein Wort, denn er wird am häufigsten missverstanden. Die Ausführungsreihenfolge v1 arbeitet Zweige nacheinander ab — ein Zweig wird vollständig fertig, bevor der nächste beginnt. Und jetzt kommt eine Eigenheit, die man kennen muss: n8n ordnet die Zweige nach ihrer Lage auf der Fläche, von oben nach unten, bei gleicher Höhe der linke zuerst.

2:07 Das heißt: Die Position Ihrer Bausteine hat eine Bedeutung. Wer zwei Zweige verschiebt, weil es hübscher aussieht, ändert damit unter Umständen die Reihenfolge. Das ist selten ein Problem — aber wenn doch, sucht man den Grund garantiert woanders. Hier steht der wichtigste Satz dieses Kapitels gleich am Anfang: Bausteine verarbeiten mehrere Items von sich aus — eine Schleife ist dafür unnötig.

2:31 Das ist der Fließband-Gedanke aus Modul drei. Wer aus anderen Sprachen kommt, baut reflexhaft eine Schleife, und die ist hier meistens überflüssig und immer langsamer. Loop Over Items lohnt sich, wenn die Gegenseite Portionen verlangt — etwa hundert Datensätze je Aufruf. Die Batch-Größe steuert dann die Last, nicht das Ergebnis.

2:50 Und noch ein Rechenhinweis: Wartezeiten innerhalb einer Schleife vervielfachen sich mit der Zahl der Durchläufe. Der erste Punkt ist der eben besprochene: Eine Schleife wird gebaut, wo der Baustein ohnehin über alle Items iteriert. Der zweite ist subtiler und rächt sich später: Zweige werden zusammengeführt, ohne zu klären, was bei ungleicher Anzahl gilt.

3:12 Kommen links drei und rechts fünf Items an — was ist dann das Ergebnis? Der Merge-Baustein hat dafür Modi, und die sollte man bewusst wählen. Der dritte ist die Positionsabhängigkeit von vorhin. Und der vierte: Stop and Error beendet den Lauf, aber niemand hat vorgesehen, was danach passieren soll. Dazu kommen wir morgen ausführlich.

Sub-Workflows und Verträge

3:33 Jetzt zur wichtigsten Technik dieses Moduls. Sub-Workflows sind der Ausweg aus der wachsenden Fläche — und mehr als das: Sie sind die Voraussetzung dafür, dass sich Teile eines Prozesses überhaupt einzeln testen lassen. Ein Sub-Workflow ist ein eigener Workflow, den ein anderer aufruft. Er beginnt mit einem besonderen Trigger, der im Editor auch „When Executed by Another Workflow" heißt — sagen Sie das Ihren Teilnehmenden, sonst sucht man ihn unter dem falschen Namen.

4:01 Der letzte Baustein des Sub-Workflows gibt die Daten an den Aufrufer zurück. Der Vergleich, der hier trägt: Das ist ein Funktionsaufruf. Sie übergeben Argumente, bekommen ein Ergebnis, und was dazwischen passiert, muss der Aufrufer nicht wissen. Genau diese Unwissenheit ist der Gewinn. Drei Modi, und die Wahl entscheidet über die Wartbarkeit.

4:22 Bei den ersten beiden beschreiben Sie, was hineinkommt — entweder als benannte Felder mit Datentyp oder als JSON-Beispiel, aus dem sich die Struktur ergibt. Der praktische Vorteil: Der aufrufende Baustein zieht diese Felder automatisch als Eingabemaske heran. Sie sehen also beim Aufruf, was erwartet wird. Der dritte Modus — Accept all data — nimmt alles an, und der Sub-Workflow muss selbst damit klarkommen. Er ist verführerisch, weil er sofort funktioniert.

4:49 Und er ist der Grund, warum viele Sub-Workflows nach einem Jahr niemand mehr anzufassen traut. Vier Argumente, und das erste ist ein hartes: Sub-Workflow-Ausführungen zählen nicht gegen Ihr monatliches Ausführungskontingent. Wer auf einem bezahlten Plan arbeitet, zerlegt also nicht nur aus Ordnungsliebe. Das zweite ist der fachliche Kern: Jeder Baustein lässt sich einzeln testen und einzeln ändern.

5:13 Das dritte betrifft Sicherheit — eine Einstellung begrenzt, wer den Sub-Workflow aufrufen darf. Und das vierte ist eine Alltagshilfe, die man erst schätzt, wenn man sie braucht: Aus dem Elternlauf führt ein Link direkt in den Kindlauf und wieder zurück. Bei der Fehlersuche ist das Gold wert. Fünf Schritte, und n8n nimmt Ihnen einen großen Teil ab. Wählen Sie zusammenhängende Bausteine aus — ohne Trigger, mit einem Eingang und einem Ausgang.

5:40 Lösen Sie sie über die Sub-Workflow-Konvertierung im Kontextmenü heraus; dabei zieht n8n Ausdrücke, die auf andere Bausteine zeigen, automatisch als Parameter nach. Das ist die Arbeit, die man sonst von Hand macht und dabei übersieht. Beschreiben Sie dann den Eingangsvertrag ausdrücklich, statt alles anzunehmen. Prüfen Sie den Baustein einzeln — mit gültigen und ungültigen Eingaben. Und führen Sie zum Schluss den Elternlauf aus und vergleichen Sie gegen vorher.

6:09 Der erste Punkt ist der aus der Tabelle: Accept all data wird gewählt, weil es schneller geht, und der Vertrag fehlt dauerhaft. Der zweite ist ein Betriebsdetail, das überrascht: Ein Fehler im Sub-Workflow verhindert, dass der Elternlauf ihn überhaupt startet — nicht erst mittendrin, sondern vorher. Der dritte ist eine schleichende Entwicklung: Der Sub-Workflow wird für jeden neuen Aufrufer erweitert und ist irgendwann selbst der Monolith.

6:33 Und der vierte ist die vergessene Einstellung: Niemand begrenzt, wer aufrufen darf — dann ist Ihr schreibender Baustein für jeden Workflow im Haus verfügbar.

Muster für mehrstufige Prozesse

6:42 Jetzt wird es interessant. Was passiert, wenn Schritt drei scheitert und Schritt eins schon gewirkt hat? Über Systemgrenzen hinweg gibt es kein Zurückrollen. Es gibt nur Muster — und die sollte man kennen, bevor man sie braucht. Ein Kompensationsschritt macht eine bereits ausgeführte Wirkung fachlich rückgängig, wenn ein späterer Schritt scheitert.

7:04 Das klingt nach einem Datenbank-Rollback, ist aber etwas völlig anderes. Bei einer Datenbank verschwindet die Änderung, als hätte es sie nie gegeben. Über Systemgrenzen hinweg geht das nicht: Die Bestellung wurde ausgelöst, die Mail ist raus. Sie können nur eine zweite, ausgleichende Aktion hinterherschicken — stornieren, korrigieren, widerrufen.

7:24 Denken Sie an eine Buchhaltung: Dort wird nichts radiert, dort wird gegengebucht. Genau dieses Denken brauchen Sie hier. Dieses Muster begegnet Ihnen überall dort, wo ein Vorgang in Teilaufgaben zerfällt, die unabhängig voneinander erledigt werden können. Ein Vorgang kommt an, wird auf Teilaufgaben verteilt, parallel abgearbeitet, und dann kommen die Ergebnisse wieder zusammen, bevor der Vorgang abschließt.

7:48 Der interessante Teil ist nicht das Auffächern, sondern das Zusammenführen: Dort müssen Sie entscheiden, was gilt, wenn eine Teilaufgabe scheitert. Warten Sie? Machen Sie mit dem Rest weiter? Brechen Sie ab? Diese Frage zu beantworten ist der eigentliche Architekturentwurf — das Auffächern ist danach Handwerk. Vier Eigenschaften, die man beim Entwurf festlegt und später nicht mehr nachrüsten kann.

8:12 Idempotenz: Derselbe Aufruf zweimal erzeugt nicht zwei Vorgänge — das haben wir gestern beim Webhook gestreift und es wird uns bis zum Abschlussprojekt begleiten. Korrelation: Jeder Teilschritt trägt die Kennung des Gesamtvorgangs; ohne sie können Sie im Fehlerfall nicht sagen, was zusammengehört. Zustand: Der erreichte Stand ist auch nach einem Neustart bekannt. Und Ausgleich: Für jede wirksame Aktion ist der Gegenschritt beschrieben.

8:37 Diese vier Wörter klingen abstrakt — am sechsten Tag werden Sie sie als Checkliste benutzen. Der erste Punkt ist eine Selbstüberlistung: Parallelität wird erhöht, bis die Gegenseite die Ratenbegrenzung zieht — dann ist man langsamer als vorher. Der zweite ist der schmerzhafteste bei der Fehlersuche: Die Korrelationskennung fehlt, und im Fehlerfall ist unklar, welche Teilschritte zu welchem Vorgang gehörten.

9:01 Der dritte ist eine Papierübung, die niemandem hilft: Der Ausgleichsschritt existiert nur in der Dokumentation, nicht im Workflow. Und der vierte kostet Zeit und Geld: Teilerfolge werden nicht festgehalten, also beginnt der Wiederanlauf wieder von vorn — mitsamt allem, was schon gewirkt hat.

Zustand ablegen

9:18 Zum Abschluss eine Frage, die überraschend oft falsch beantwortet wird: Wo liegt eigentlich der Zustand eines Vorgangs? Es gibt drei Orte, und nur einer davon ist für Fachdaten gedacht. Data Tables sind tabellarische Ablagen innerhalb der Projektgrenzen. Die Dokumentation nennt vier typische Zwecke: Daten über mehrere Workflows eines Projekts hinweg halten, Marker gegen Doppelläufe setzen, Nachschlagetabellen führen und Auswertungsdaten für KI-Workflows ablegen.

9:45 Achten Sie auf das, was dort nicht steht — von Stammdaten oder Fachdatenhaltung ist nirgends die Rede. Data Tables sind das Notizbuch neben dem Schreibtisch, nicht der Aktenschrank. Sie sind grandios für „Diese Meldung habe ich schon verarbeitet" und ungeeignet für „Hier stehen unsere Kunden". Drei Orte, drei Zwecke. Die Data Table für Marker, Nachschlagewerte und Stände innerhalb eines Projekts.

10:09 Workflow Static Data für einen kleinen technischen Merkposten eines einzelnen Workflows — etwa den Zeitstempel des letzten erfolgreichen Abrufs. Und die externe Datenbank für fachliche Daten mit eigenem Lebenszyklus. Die Faustregel, die ich Ihnen mitgeben möchte: Wenn jemand außerhalb von n8n diese Daten je brauchen könnte, gehören sie nicht in n8n.

10:29 Denn was in einer Data Table liegt, sieht nur, wer Zugriff auf das Projekt hat — und Auswertungen darüber schreibt niemand. Vier Grenzen, und die erste ist eine Zahl: Alle Data Tables einer Instanz teilen sich standardmäßig 200 Mebibyte. Ab achtzig Prozent warnt n8n, ab der Grenze schlagen Schreibzugriffe fehl — und zwar im laufenden Betrieb, nicht beim Anlegen.

10:52 Selbst gehostet lässt sich die Grenze per Umgebungsvariable ändern, in der Cloud nicht. Die zweite: Data Tables sind für leichte bis mittlere Datenmengen gedacht. Die dritte überrascht viele: Aus dem Code-Node gibt es keinen programmatischen Zugriff — das ist ausdrücklich nicht vorgesehen. Und die vierte ist eine Datenschutzfrage: Im Projekt sehen alle Mitglieder die Tabelle.

11:15 Der erste Punkt ist die Entwicklung, vor der ich eben gewarnt habe: Die Data Table wächst zur heimlichen Stammdatenhaltung, ohne dass jemand sie pflegt. Der zweite ist ein Betriebsproblem mit Ansage: Der Doppellauf-Marker wird geschrieben, aber nie wieder aufgeräumt — und irgendwann sind die zweihundert Mebibyte voll. Planen Sie das Aufräumen mit ein, wenn Sie den Marker einführen. Der dritte ist der Zugriff aus dem Code-Node, den es nicht gibt.

11:39 Und der vierte ist die Datenschutzfrage von eben: Personenbezogene Daten landen dort, ohne dass eine Löschfrist vereinbart wäre.

Übung

11:47 Jetzt zerlegen Sie den Workflow, den Sie gestern gebaut haben. Er ist inzwischen gewachsen — und damit ein realistischer Kandidat für genau die Operation, die wir besprochen haben. Der Kesselwerk-Workflow aus Modul zwei nimmt die Meldung an, reichert Kundendaten an, prüft Ersatzteile und legt den Einsatz an — alles auf einer Fläche.

12:07 Und jetzt kommt das Argument, das in echten Projekten den Ausschlag gibt: Drei dieser Schritte sind auch anderswo nützlich. Kundendaten anreichern brauchen Sie in jedem zweiten Prozess. Solange das im Störungs-Workflow eingebaut ist, bauen Sie es beim nächsten Mal erneut — und pflegen es danach an zwei Stellen. Das Lernziel: fachlich zusammenhängende Schritte so herauslösen, dass ihr Ein- und Ausgabeverhalten vereinbart ist.

12:32 Auf dem Wort fachlich liegt die Betonung — zerlegt wird nach Zuständigkeit, nicht nach Bildschirmbreite. Erfolgreich sind Sie, wenn drei Sub-Workflows mit ausdrücklich beschriebenem Eingangsvertrag einzeln laufen und der Hauptworkflow nachweislich dasselbe Ergebnis liefert wie vorher. Dieses Nachweislich ist der Kern der Übung: Eine Refaktorierung ohne Vergleichsstand ist eine Behauptung.

12:54 Wer früh fertig ist, begrenzt je Baustein über die Einstellungen, wer ihn aufrufen darf. Eine Stunde, und der erste Schritt ist der, den man überspringen will: Halten Sie das Ergebnis des bisherigen Laufs als Vergleichsstand fest. Ohne ihn können Sie am Ende nicht zeigen, dass nichts kaputtgegangen ist. Lösen Sie dann die drei Abschnitte einzeln über die Konvertierung heraus — einzeln, nicht alle auf einmal, damit Sie nach jedem Schritt prüfen können.

13:20 Beschreiben Sie je Baustein den Eingang über Felder oder JSON-Beispiel. Prüfen Sie jeden einzeln mit gültiger und fehlerhafter Eingabe. Und führen Sie zum Schluss den Hauptlauf aus und halten ihn gegen den Vergleichsstand. Vier Fallen. Erstens: Zerlegt wird nach Größe der Fläche, nicht nach fachlicher Zuständigkeit — dann entstehen Bausteine, die niemand benennen kann.

13:41 Zweitens: Der Vergleichsstand wird nicht festgehalten, und die Gleichheit bleibt eine Behauptung. Drittens: Die Bausteine übernehmen Accept all data und prüfen nichts — dann haben Sie den Monolithen nur verteilt, nicht zerlegt. Und viertens, ein feiner, aber wichtiger Punkt: Ein Baustein greift weiter auf Bausteine des Elternworkflows zu.

14:02 Dann ist er kein eigenständiger Baustein, sondern ein ausgelagertes Stück mit unsichtbarer Leine.