Expressions, JavaScript und Python

Expressions, JavaScript und Python

0:00 Es gibt in Low-Code-Projekten eine merkwürdige Scham vor Code. Als sei es ein Eingeständnis des Scheiterns, wenn man etwas nicht zusammenklicken kann. In n8n ist das ausdrücklich nicht so: Die Dokumentation sieht Expressions und den Code-Node als Ergänzung zur Modellierung vor, nicht als Notausgang. Code ist die Stelle, an der man aufhört, eine Oberfläche zu überreden.

0:21 Die Kunst besteht darin, zu wissen, wann dieser Punkt erreicht ist — und wann man ihn nur herbeiredet, weil Tippen schneller geht als Suchen.

Expressions, JavaScript und Python

0:30 Das letzte Modul des zweiten Tages. Zuerst die Frage, welches der vier verfügbaren Werkzeuge wann das richtige ist. Dann der Code-Node selbst, mit einer Neuerung, die Sie unbedingt kennen müssen, wenn Sie Python einsetzen wollen — dort hat sich mit n8n 2 Grundlegendes geändert. Danach die Aufgaben, für die sich Code wirklich lohnt: Validieren und Mappen. Und zum Schluss die Sicherheitsfrage, denn fremder Code läuft auf Ihrer Maschine.

Wann Node, wann Expression, wann Code

0:56 Fangen wir mit der Entscheidung an. Vier Wege stehen zur Auswahl, und jeweils einer davon ist der kürzeste — die Kunst ist, ihn zu erkennen, bevor man den längeren gegangen ist. n8n sieht Expressions und den Code-Node ausdrücklich als Ergänzung zur Low-Code-Modellierung vor. Die Arbeitsteilung dahinter ist klar: Expressions setzen einen einzelnen Parameterwert, Transformations-Bausteine erledigen die häufigen Operationen, und der Code-Node übernimmt, was darüber hinausgeht.

1:25 Ich vergleiche das gern mit einer Küche. Für Zwiebeln nehmen Sie das Messer, das dafür gemacht ist. Für die Sahne den Schneebesen. Und wenn es wirklich etwas Besonderes wird, arbeiten Sie von Hand. Nur: Niemand schneidet Zwiebeln von Hand, bloß weil er es kann. Vier Wege, und die Tabelle hat eine Spalte, auf die Sie achten sollten: die Verfügbarkeit. Die ersten drei stehen Ihnen überall zur Verfügung, in der Cloud wie selbst gehostet.

1:52 Der AI Transform Node, der aus einer Beschreibung Code erzeugt, ist ausdrücklich nur in der Cloud verfügbar. Wenn Ihr Haus selbst hostet, planen Sie ihn also gar nicht erst ein. Die Fußzeile wiederholt die Empfehlung der Dokumentation, und sie hat einen sehr praktischen Kern: Expressions zeigen den berechneten Wert sofort in der Vorschau.

2:11 Sie sehen beim Schreiben, ob es stimmt — bei Code sehen Sie das erst beim Ausführen. Vier Grenzen, und die erste ist eine technische, die überrascht: Der Code-Node hat keinen Zugriff auf das Dateisystem und kann keine HTTP-Aufrufe machen. Dafür gibt es eigene Bausteine, und das ist bewusst so. Die zweite ist eine Teamfrage — was als Code entsteht, prüft kein Reviewer auf der Fläche mit; es verschwindet in einem Kästchen.

2:37 Die dritte ist eine Erfahrungsregel: Fünfzig Zeilen im Baustein sind leichter geschrieben als später wiedergefunden. Und die vierte ist eine Architekturaussage: Wiederverwendbar wird Logik als Sub-Workflow, nicht als kopierter Code-Block. Kopierter Code ist derselbe Fehler wie überall. Der erste Punkt ist der ehrlichste dieser Folie: Der Code-Node ersetzt einen Standard-Baustein, weil Schreiben schneller ging als Suchen.

3:02 Das ist menschlich und trotzdem falsch — der Standard-Baustein ist in einem Jahr noch verständlich. Der zweite ist die Gegenrichtung: Logik wird in Expressions gepresst, bis niemand sie mehr lesen kann; ab drei verschachtelten Bedingungen gehört sie in Code. Der dritte ist der Cloud-Hinweis von eben. Und der vierte ist ein Architekturproblem mit Ansage: Für jeden Sonderfall entsteht ein weiterer Code-Node ohne gemeinsame Basis.

JavaScript und Python im Code Node

3:27 Jetzt in den Code-Node selbst. Zwei Modi, zwei Sprachen — und eine Änderung mit n8n 2, die jeden betrifft, der bisher Python eingesetzt hat. Der Code-Node kennt zwei Modi, und die Wahl entscheidet über die Denkweise. Run Once for All Items führt Ihren Code einmal aus, unabhängig von der Zahl der Eingabe-Items — Sie bekommen alle Items als Liste und arbeiten damit. Das ist die Voreinstellung.

3:52 Run Once for Each Item führt ihn für jedes Item erneut aus; Sie denken dann in einem einzelnen Datensatz. Beides hat seine Berechtigung: Wer gruppiert oder aggregiert, braucht alle auf einmal. Wer ein Feld je Datensatz ergänzt, hat es mit dem zweiten Modus leichter. Der häufigste Fehler ist, den falschen Modus mit der Logik des anderen zu füllen.

4:13 Sie sehen hier beide Modi nebeneinander, und mir geht es nur um den Unterschied im Denken. Oben arbeiten Sie mit der Gesamtmenge: Sie holen sich alle Items, filtern und geben die gefilterte Liste zurück. Unten arbeiten Sie mit einem einzelnen Datensatz: Sie setzen ein Feld und geben dieses eine Item zurück. Kein Wort über Klammern und Semikola — wichtig ist das Muster.

4:35 Und ein praktischer Hinweis, der viel Ärger spart: Wenn der json-Schlüssel oder die Array-Klammer fehlt, ergänzt der Code-Node beides von selbst. Das ist einer der wenigen Orte in n8n, an denen Ihnen die Struktur aus Modul drei nachgesehen wird. Und jetzt die Änderung, die ich angekündigt habe. Python über Pyodide ist eine Altlast und wird von n8n 2 nicht mehr unterstützt.

4:58 An seine Stelle tritt natives Python über Task Runner — seit Version 1.111.0 verfügbar und mit n8n 2 stabil. Das ist ausdrücklich eine Breaking Change: Bestehende Skripte müssen angepasst werden. Wenn Sie also Bestand haben, der Python nutzt, ist das kein Detail am Rande, sondern ein Migrationsthema. Was genau sich ändert, steht auf der nächsten Folie — und das sind keine Kleinigkeiten.

5:24 Fünf Unterschiede, und drei davon brechen bestehenden Code. Der Zugriff auf Felder funktioniert nur noch mit Klammerschreibweise — der Punkt, den Pyodide erlaubte, ist weg. An eingebauten Variablen gibt es nur noch zwei, alles andere entfällt. In der Cloud können Sie überhaupt keine Bibliotheken importieren, auch keine aus der Standardbibliothek — das ist die härteste Einschränkung und überrascht jeden.

5:48 Selbst gehostet geht nur, was das Runner-Image mitbringt und ausdrücklich freigibt. Und unsichere eingebaute Funktionen sind standardmäßig gesperrt. Mein Rat: Wenn Sie in der Cloud arbeiten und Bibliotheken brauchen, nehmen Sie JavaScript. Der erste Punkt ist der Migrationsfall: Ein Pyodide-Skript wird übernommen und scheitert an der Punktschreibweise. Immerhin scheitert es sichtbar — das ist besser als still.

6:12 Der zweite ist der Cloud-Fall: Ein Python-Import wird eingeplant, der dort grundsätzlich nicht geht; das merkt man am besten vor der Architekturentscheidung. Der dritte ist der Modus-Fehler von vorhin. Und der vierte betrifft JavaScript: Externe npm-Module werden vorausgesetzt, aber in der Cloud stehen nur zwei zur Verfügung — crypto und moment.

6:32 Selbst gehostet lässt sich das freischalten, in der Cloud nicht.

Validieren, Mappen und Fehler behandeln

6:37 Kommen wir zu den Aufgaben, für die sich Code wirklich lohnt. Und die wichtigste davon ist nicht das Umbauen von Daten, sondern etwas anderes: Der Code-Node ist die richtige Stelle, um Nein zu sagen. Vier Aufgaben. Erstens: eingehende Daten gegen ein erwartetes Schema prüfen, bevor sie weiterlaufen. Das ist der wertvollste Einsatz überhaupt, weil er verhindert, dass Unsinn durch fünf Bausteine wandert, bevor er auffällt.

7:02 Zweitens: verschachtelte Strukturen in die flache Form des Zielsystems überführen — das klassische Mapping. Drittens: mehrere Items zu einem Vorgang bündeln oder einen Vorgang aufteilen, wenn die Standardbausteine nicht ganz passen. Und viertens: fachliche Regeln abbilden, die keine Standardoperation kennt. Alle vier haben gemeinsam, dass sie sich gut beschreiben lassen — und was sich beschreiben lässt, lässt sich auch testen.

7:29 Dieses Beispiel ist bewusst schlicht, weil es um eine Haltung geht. Sie prüfen am Eingang, ob die Pflichtfelder da sind, und wenn nicht, werfen Sie eine Ausnahme mit einer verständlichen Meldung. Kein stilles Überspringen, kein leeres Array, keine Ersatzwerte. Der Grund steht in der Fußzeile: Eine geworfene Meldung landet im Fehlerzweig und in den Ausführungsdaten — eine still verworfene landet nirgends.

7:52 Das ist der Unterschied zwischen einem Vorgang, den jemand nacharbeiten kann, und einem, der einfach verschwunden ist. Wir kommen morgen ausführlich darauf zurück; hier ist es eine Vorwegnahme. Erinnern Sie sich an den Faden aus Modul drei? Hier müssen Sie ihn selbst knüpfen. Stimmt die Zahl der Ein- und Ausgabe-Items nicht überein, muss Ihr Code die Verkettung setzen — sonst schlägt ein späterer Zugriff auf das zugehörige Item fehl.

8:18 Bei völlig neu erzeugten Items ohne Bezug geht es gar nicht automatisch. Das klingt nach einer lästigen Pflicht, ist aber nur konsequent: Wenn Sie aus drei Datensätzen fünf machen, kann n8n nicht wissen, welcher woher stammt. Deshalb der Satz am Ende: Die Verkettung ist Teil des Vertrags, nicht ein Detail der Umsetzung. Der erste Punkt ist der gefährlichste im ganzen Modul: Der Code fängt jeden Fehler und gibt ein leeres Array zurück — der Lauf bleibt grün, und niemand erfährt je davon.

8:47 Das ist das genaue Gegenteil von Folie sechzehn. Der zweite ist ein Testproblem: Es wird auf ein Feld zugegriffen, das nur in den Testdaten vorkommt. Der dritte ist eine Frage der Reihenfolge — die Prüfung steht hinter der Verarbeitung statt davor. Und der vierte ist eine liebe Gewohnheit mit Grenzen: console.log ersetzt die Fehlerbehandlung. Eine Ausgabe in der Konsole hilft Ihnen beim Entwickeln und niemandem im Betrieb.

Sicherheit der Code-Ausführung

9:13 Zum Abschluss die unbequeme Seite. Ein Code-Node ist eine Stelle, an der fremder Code auf Ihrer Maschine läuft — und wer den Workflow ändern darf, ändert damit diesen Code. Task Runner führen Code in einem eigenen Prozess aus, getrennt vom n8n-Hauptprozess. Natives Python läuft darüber, und die Laufzeitumgebung sperrt unsichere eingebaute Funktionen standardmäßig.

9:35 Das ist eine spürbare Verbesserung gegenüber früher: Ein Fehler oder ein Angriff im Code trifft dann nicht direkt den Prozess, der Ihre ganze Instanz trägt. Denken Sie an eine Werkstatt mit Brandschutztür — nicht jeder Funke ist damit ausgeschlossen, aber er bleibt im Raum. Mit n8n 2 sind Task Runner übrigens standardmäßig eingeschaltet; wer selbst hostet, sollte ihre Härtung trotzdem bewusst ansehen.

10:00 Vier Punkte, und der dritte ist der, den man selten ausspricht. Externe Module bringen fremden Code samt dessen Abhängigkeiten mit — das ist das Lieferketten-Thema, das uns am fünften Tag beschäftigt. Ein Code-Node kann Daten an beliebige Stellen weitergeben, die er kennt. Und dann: Wer den Workflow ändern darf, ändert damit auch ausgeführten Code.

10:21 Das heißt, Ihre Rechtevergabe für Workflows ist zugleich eine Rechtevergabe für Codeausführung — daran denkt beim Einrichten selten jemand. Und viertens: KI-erzeugter Code sieht plausibel aus. Plausibel ist keine Prüfung. Fünf Maßnahmen. Geben Sie externe Module nur frei, wenn ein Anwendungsfall sie wirklich braucht — und beachten Sie: Die Freigabe gilt instanzweit, nicht je Workflow.

10:46 Setzen Sie Task Runner ein und übernehmen Sie deren Härtung. Sehen Sie für Code dieselbe Review-Pflicht vor wie für Anwendungscode; er ist ja auch welcher. Kommentieren Sie jeden Code-Node — wozu er da ist und was er an der Eingabe erwartet. Und lesen und testen Sie KI-erzeugten Code, bevor Sie ihn übernehmen. Die Fußzeile fasst es zusammen: Wer Code nicht prüfen will, sollte ihn auch nicht zulassen.

11:11 Der erste Punkt ist die instanzweite Freigabe von eben: Externe Module werden freigeschaltet, weil ein Workflow eines braucht — und stehen danach allen offen. Der zweite ist alltäglich: Code aus einer Vorlage wird übernommen, ohne ihn zu lesen. Der dritte ist ein Wartungsproblem, das erst nach Jahren zuschlägt: Der Baustein trägt keinen Kommentar, und der Autor ist nicht mehr im Haus.

11:32 Und der vierte ist die klassische Verschiebung: Die Härtung der Task Runner wird auf später verschoben — und später kommt bekanntlich nach dem Vorfall.

Übung

11:41 Zum Abschluss des zweiten Tages eine Übung, die eine Frage beantwortet, über die man sonst nur streitet: Ist die visuelle oder die Code-Variante besser? Sie bauen beide und entscheiden begründet. Die Anlagendaten von Kesselwerk kommen verschachtelt an: je Kunde eine Liste von Anlagen, je Anlage eine Liste von Messwerten.

12:01 Gebraucht wird eine flache Liste je Anlage mit dem jüngsten Messwert und einem Kennzeichen für überfällige Wartung. Das ist eine typische Aufgabe — nicht trivial, aber auch nicht exotisch. Genau in diesem Bereich liegt die interessante Frage, denn ganz einfache Fälle löst man visuell und ganz komplexe im Code. Die Entscheidung fällt in der Mitte.

12:22 Das Lernziel: begründet entscheiden, wann eine Transformation als Baustein-Kette und wann als Code besser aufgehoben ist. Erfolgreich sind Sie, wenn beide Varianten für dieselbe Eingabe dasselbe Ergebnis liefern und die Wahl zwischen ihnen mit Lesbarkeit, Testbarkeit und Verhalten bei fehlenden Feldern begründet ist. Diese drei Kriterien sind Absicht — nach Zeilenzahl zu entscheiden wäre zu einfach.

12:44 Wer früh fertig ist, ergänzt in der Code-Variante die Verkettung der Items und prüft den Zugriff aus einem späteren Baustein. Dann sehen Sie, was auf Folie siebzehn gemeint war. Eine Stunde, und der erste Schritt ist der, den man gern überspringt: Schreiben Sie die erwartete Ausgabe als Beispiel auf, bevor Sie bauen. Sonst entsteht sie nachträglich aus dem, was herausgekommen ist — und dann prüfen Sie nichts mehr. Bauen Sie dann Variante A aus Split Out, Sort und Aggregate zusammen.

13:13 Schreiben Sie Variante B im Code-Node, mit Prüfung am Eingang. Führen Sie beide mit denselben Daten aus und vergleichen Sie. Und entfernen Sie zum Schluss ein Pflichtfeld und beobachten Sie, welche Variante das meldet. Erfahrungsgemäß ist das der Moment, in dem die Entscheidung fällt. Vier Fallen. Erstens: Verglichen wird die Ausgabe, aber nicht das Verhalten im Fehlerfall — dabei ist genau das der interessante Unterschied.

13:39 Zweitens: Die Code-Variante gewinnt, weil sie kürzer aussieht, nicht weil sie klarer ist; Kürze ist kein Kriterium. Drittens: Die erwartete Ausgabe entsteht erst nachträglich aus dem Ergebnis — der übersprungene erste Schritt. Und viertens: Der Modus des Code-Nodes passt nicht zur geschriebenen Logik. Das ist der Klassiker aus dem zweiten Kapitel, und er fällt hier besonders auf, weil die visuelle Variante danebensteht und es richtig macht.