Split In Batches (Der Portionierer)

Stell dir vor, du musst 1000 Briefe verschicken, aber der Briefkasten nimmt immer nur 10 auf einmal an. Du teilst den Stapel in kleine Päckchen (Batches) auf. Der Split In Batches Node macht genau das: Er nimmt eine riesige Liste von Daten und gibt sie häppchenweise weiter.

:level0

Lernbruecke: Split In Batches ist wie Portionieren beim Kochen. Statt 1000 Kontakte auf einmal zu bearbeiten, nimmst du 50, wartest auf das Ergebnis und machst dann weiter.

Lernbruecke für Anfänger

Wenn du bei Split In Batches (Der Portionierer) ganz neu startest, denke zuerst nicht an Fachwörter, sondern an die Alltagssituation: Grosse Listen kontrolliert verarbeiten. Der Begriff beschreibt einen klaren Baustein im größeren Ablauf. Frage dich immer: Was ist der Eingang, was passiert in der Mitte, und woran erkenne ich am Ende, dass es funktioniert hat?

Ein guter Einstieg ist, den Begriff in einem Satz zu erklären, danach ein reales Beispiel zu nennen und erst dann die Technikdetails zu lernen. So entsteht kein reines Auswendiglernen, sondern ein mentales Modell.

Das ist essenziell für Loops (Schleifen) in n8n. Ohne diesen Node würde n8n versuchen, alle 1000 Daten gleichzeitig an die nächste API zu senden. Die API würde sagen: "Stop! Zu viel auf einmal!" (Rate Limit). Mit SplitInBatches sagst du: "Nimm immer 10 Stück, verarbeite sie, warte kurz, dann die nächsten 10."

:level1

Praxisbeispiel: Eine API erlaubt nur 100 Requests pro Minute. Du teilst die Liste in kleine Batches, fuegst bei Bedarf Wartezeit ein und speicherst Zwischenergebnisse, damit ein Fehler nicht die ganze Arbeit zerstoert.

So baust du einen Loop:

Split In Batches Node: Batch Size = 10.
Verarbeitung: (z.B. HTTP Request).
Verbindung zurück: Vom Ende der Verarbeitung zurück zum Input des SplitInBatches Node. Der Node erkennt automatisch, ob noch Daten übrig sind.

Wenn ja: Loop-Ausgang.
Wenn nein: Done-Ausgang.

:level2

Technisch reduziert Batching Speicherlast, API-Rate-Limit-Probleme und Wiederholungsaufwand. Entscheidend ist, ob der Workflow nach einem Fehler weiss, welcher Batch zuletzt erfolgreich war.

Technische Einordnung im System

Technisch ist Split In Batches (Der Portionierer) nicht isoliert. Es wirkt mit Nachbarbegriffen zusammen, hat Voraussetzungen und erzeugt Folgen. Für ein robustes Verständnis prüfst du drei Fragen: Welche Daten oder Bedingungen braucht dieser Schritt? Welche Ausgabe oder Wirkung entsteht? Was passiert bei falschen, fehlenden oder zu großen Eingaben?

Diese Sicht ist wichtig, weil echte Systeme selten am Hauptpfad scheitern. Sie scheitern an Randfällen, Berechtigungen, Zeitpunkten, Formaten, Reihenfolgen oder stillen Annahmen.

Context & State

Innerhalb des Loops ändert sich der Kontext ($json). Wenn du auf Daten zugreifen willst, die außerhalb des Loops (vor dem Split) liegen, musst du explizit referenzieren: $('.NodeName').first().json.field oder über Variablen. Der SplitInBatches Node selbst hält den State: noItemsLeft (Boolean) und context.currentRunIndex.

Memory Management (RAM)

Bei sehr großen Datensätzen (100k Zeilen) ist dieser Node überlebenswichtig. Aber Vorsicht: n8n hält standardmäßig alle Execution Data im RAM, bis der ganze Workflow fertig ist. Bei extremen Mengen muss man die Option "Return All" im Loop deaktivieren oder Sub-Workflows nutzen, die jeweils nur einen Batch verarbeiten und sich dann beenden, um den Speicher freizugeben.

Reset

Du kannst den Loop zurücksetzen (Reset), wenn du verschachtelte Loops (Loop im Loop) baust. Das ist komplex und erfordert sorgfältige Planung der Datenstruktur.