Loop Over Items Node
Der Loop Over Items Node (in älteren n8n-Versionen „Split In Batches” genannt) teilt Items in kleinere Gruppen auf. Ein typischer Batch-Workflow:batchSize: 10 werden aus 30 Input-Items drei Batches zu je 10 Items:
Loop Over Items Konfiguration
Batch-Größe bestimmen
Die optimale Batch-Größe hängt von den API-Rate-Limits (z.B. 100 Requests/Minute), der maximalen Batch-Größe der API (z.B. 50 Items), der Verarbeitungszeit pro Batch und den Memory-Limits ab.
Beginnen Sie mit Batch-Größe 10-20 und passen Sie basierend auf Performance und Rate Limits an.
Batch-API-Calls
Batch POST Request
Senden Sie mehrere Items in einem Request.$input.all() liefert alle Items des aktuellen Node-Inputs; Items eines bestimmten vorherigen Nodes erreichen Sie mit $('Node Name').all().
Batch GET Request
Mehrere IDs in einem Request — die URL wird damit z.B. zuhttps://api.example.com/items?ids=1,2,3,4,5:
Batch GET
Code-Node für Batch-Verarbeitung
Für komplexe Batch-Logik nutzen Sie den Code-Node:Rate Limit Management
Batching reduziert die Request-Zahl direkt: Erlaubt eine API 100 Requests pro Minute und Ihr Workflow verarbeitet 1000 Items, brauchen Sie ohne Batching 1000 Requests (10 Minuten) — mit Batches à 10 Items nur 100 Requests (1 Minute). Automate hat keinen dedizierten Rate-Limit-Node. Das etablierte Muster für kontrollierte Request-Raten kombiniert den Loop Over Items Node mit einem Wait-Node in der Schleife:- Der Loop Over Items Node gibt pro Durchlauf einen Batch aus
- Der Wait-Node pausiert nach jedem Batch für eine feste Zeit
- Die Rückverbindung zum Loop Over Items Node startet den nächsten Batch
batchSize: 10 und eine Wait-Dauer von 6 Sekunden — so bleiben Sie bei maximal 100 Requests pro Minute.
Parallele Batch-Verarbeitung
Sie können Batches auf mehrere Branches verteilen und die Ergebnisse anschließend zusammenführen:Code-Node für Parallelität
Batch-Fehlerbehandlung
Partielle Fehler
Wenn einzelne Items in einem Batch fehlschlagen, trennen Sie erfolgreiche und fehlerhafte Items und behandeln letztere separat (Error Trigger):Fehlerbehandlung
Retry-Logik für Batches
Fehlgeschlagene Batches versuchen Sie erneut (Process Batch → Error Trigger → Retry Logic → Process Batch):
Retry mit Exponential Backoff
Praxisbeispiel: E-Mail-Versand in Batches
100 E-Mails sollen versendet werden. Der Loop Over Items Node (batchSize: 20) erzeugt fünf Batches zu je 20 E-Mails; jeder Batch geht als ein Request an die E-Mail-API, ein Merge führt die Ergebnisse für das Success/Error-Tracking zusammen:
HTTP Request an E-Mail-API
Best Practices
- Batch-Größe optimieren: an API-Limits, Verarbeitungszeit, Memory-Verfügbarkeit und Rate Limits ausrichten.
- Fehlerbehandlung: partielle Fehler behandeln, Retry-Logik für fehlgeschlagene Batches, Fehler-Logging.
- Rate Limits respektieren: mit Loop Over Items + Wait-Node drosseln, Backoff implementieren, Request-Rate überwachen.
- Monitoring: Batch-Größe, Verarbeitungszeit und Fehlerrate im Blick behalten.
- Memory-Management: keine zu großen Batches, Ergebnisse früh ausgeben, unnötige Daten entfernen.
- Testing: mit verschiedenen Batch-Größen, Edge Cases (leere und sehr große Batches) und Fehler-Szenarien testen.
Checkliste
- Batch-Größe ist optimiert für API-Limits
- Rate Limits werden eingehalten
- Fehlerbehandlung ist implementiert
- Retry-Logik für fehlgeschlagene Batches
- Memory-Verbrauch ist akzeptabel
- Performance wird überwacht
- Edge Cases wurden getestet
Nächste Schritte
Retry Logic
Retry-Logik für fehlgeschlagene Batches implementieren.
Performance
Batch-Verarbeitung für bessere Performance optimieren.
Item Management
Items effektiv verwalten.
Testing
Batch-Workflows gründlich testen.
