Нужно обработать список небольшими порциями и получить общий результат после последней порции. Настроим Loop Over Items в n8n на семи вымышленных заказах: три записи, ещё три и последняя одна. Покажем, куда подключать loop и done и почему без обратного соединения останется только первый пакет.
Результат инструкции
Соберём ручную схему из шести узлов. Split Orders разделит массив на семь items, Batch Orders выдаст пакеты, Processed добавит номер и размер пакета. All Done получит все семь обработанных заказов с loop_completed = true. Исходные order_id и amount сохранятся.
Ничего не отправляем клиентам и не меняем в CRM. В примере нет API, AI-модели и платных вызовов. Статус processed_in_demo означает выполнение нашего учебного Edit Fields, а не подтверждение оплаты или успешной внешней отправки.
Что понадобится
- Отдельный пустой workflow в n8n. Проверено на 2.42.4: Loop Over Items 3, Edit Fields 3.4.
- JSON схемы из шага 2. В нём нет credentials, секретов или действующих внешних триггеров.
- Доступ к ручному запуску. Не импортируйте пример поверх рабочего workflow.
Установить n8n локально через Docker
Шаг 1. Создайте новый workflow
Откройте Overview → Create workflow. Не выбирайте существующую автоматизацию. Запуск будет по кнопке Execute workflow через Manual Trigger; Publish нажимать не нужно.
Шаг 2. Импортируйте шесть узлов
Скачать n8n-loop-batches-demo.json
Скопируйте весь JSON файла, щёлкните свободное место холста и нажмите Ctrl+V. Альтернатива - More actions → Import from File. Должны появиться имя ezgpt-loop-batches-demo и узлы Manual Trigger, Test Orders, Split Orders, Batch Orders, Processed и All Done. Импортируйте только один раз.
Нажмите Zoom to Fit после загрузки узлов. Если двойной щелчок по подписи только приближает холст, откройте сам квадрат узла с иконкой. В нашей проверке параметры открывались двойным щелчком по квадрату.
Шаг 3. Проверьте исходные семь заказов
Откройте Test Orders: Edit Fields, Mode = JSON Output, Include Other Input Fields выключен. В JSON стоит:
Показать код (32 строк)
{
"orders": [
{
"order_id": "O1",
"amount": 100
},
{
"order_id": "O2",
"amount": 200
},
{
"order_id": "O3",
"amount": 300
},
{
"order_id": "O4",
"amount": 400
},
{
"order_id": "O5",
"amount": 500
},
{
"order_id": "O6",
"amount": 600
},
{
"order_id": "O7",
"amount": 700
}
]
}Нажмите Execute step. На выходе один item с массивом orders из семи объектов, не семь отдельных items. ID O1–O7 и суммы 100–700 придуманы для проверки порядка. Никаких реальных персональных данных в наборе нет.
Шаг 4. Разделите массив через Split Out
Откройте Split Orders. Fields To Split Out = orders, Include = No Other Fields. Destination Field Name не задавайте. Нажмите Execute step: OUTPUT должен показывать семь items, у каждого order_id и amount находятся на верхнем уровне.
Если передать в цикл один item с вложенным массивом, Batch Size будет считать items, а не объекты внутри orders. Сначала убедитесь, что Split Orders действительно вернул семь отдельных записей.
Разобрать JSON-массив через Split Out
Шаг 5. Задайте размер пакета
Откройте Batch Orders: это Loop Over Items, в экспортированном JSON тип называется splitInBatches. Batch Size оставьте в Fixed и поставьте 3. В Options переключатель Reset должен быть выключен.
Наш набор конечный: семь уже загруженных записей. Для него не нужно переинициализировать вход на каждом обороте. Не включайте Reset ради исправления отсутствующего соединения. Пагинация с неизвестным числом страниц и условием остановки в этот пример не входит.
Шаг 6. Проверьте путь loop и возврат
Из выхода loop у Batch Orders должна идти линия к входу Processed. Из выхода Processed - линия обратно к входу Batch Orders. Выход done ведёт отдельно к All Done. Схема соединений:
Manual Trigger → Test Orders → Split Orders → Batch Orders
Batch Orders [loop] → Processed → Batch Orders [input]
Batch Orders [done] → All DoneСверяйте подписи loop и done, а не только положение разъёмов. Processed работает внутри цикла. All Done работает после его завершения. Не подключайте All Done к loop: тогда это уже не итоговый этап после всех пакетов.
Шаг 7. Добавьте метки обработки и пакета
Откройте Processed: Edit Fields, Mode = Manual Mapping. Include Other Input Fields включён, Input Fields to Include = All. Первое поле processing_status имеет тип String и Fixed = processed_in_demo. Оно лишь отмечает прохождение нашего узла.
Поле batch_number имеет тип Number. Значение в Expression:
{{ $runIndex + 1 }}$runIndex здесь относится к выполнению Processed и начинается с нуля. Прибавляем один для удобной подписи: первый, второй и третий пакет. Это не ID заказа и не номер запуска всего workflow.
Поле items_in_batch тоже Number. Значение в Expression:
{{ $input.all().length }}Оно считает входные items текущего выполнения Processed. В первых двух пакетах будет 3, в последнем 1. Имена полей оставляйте в Fixed, режим Expression нужен их значениям. В файле для импорта перед {{ есть знак =; вручную не добавляйте второй знак к уже импортированному выражению.
Шаг 8. Настройте общий выход All Done
Откройте All Done: Edit Fields, Mode = Manual Mapping. Поле loop_completed имеет тип Boolean и значение Fixed = true, не строку "true". Include Other Input Fields включён, Input Fields to Include = All.
Метка добавляется каждому item, полученному через done. Она не создаёт сводный отчёт и не проверяет внешний сервис. Для упражнения важнее другое: All Done должен выполниться один раз и выдать семь items, а не один item на каждую итерацию.
Шаг 9. Выполните всю цепочку
Закройте настройки крестиком и нажмите Execute workflow на холсте. Откройте All Done → OUTPUT → JSON. Должно быть семь записей. Полный проверенный результат:
Показать код (58 строк)
[
{
"order_id": "O1",
"amount": 100,
"processing_status": "processed_in_demo",
"batch_number": 1,
"items_in_batch": 3,
"loop_completed": true
},
{
"order_id": "O2",
"amount": 200,
"processing_status": "processed_in_demo",
"batch_number": 1,
"items_in_batch": 3,
"loop_completed": true
},
{
"order_id": "O3",
"amount": 300,
"processing_status": "processed_in_demo",
"batch_number": 1,
"items_in_batch": 3,
"loop_completed": true
},
{
"order_id": "O4",
"amount": 400,
"processing_status": "processed_in_demo",
"batch_number": 2,
"items_in_batch": 3,
"loop_completed": true
},
{
"order_id": "O5",
"amount": 500,
"processing_status": "processed_in_demo",
"batch_number": 2,
"items_in_batch": 3,
"loop_completed": true
},
{
"order_id": "O6",
"amount": 600,
"processing_status": "processed_in_demo",
"batch_number": 2,
"items_in_batch": 3,
"loop_completed": true
},
{
"order_id": "O7",
"amount": 700,
"processing_status": "processed_in_demo",
"batch_number": 3,
"items_in_batch": 1,
"loop_completed": true
}
]У O1–O3 batch_number = 1 и items_in_batch = 3. У O4–O6 номер 2 и размер 3. У O7 номер 3 и размер 1. У каждого processing_status = processed_in_demo и loop_completed = true. Проверьте все ID и суммы, не только первую строку.
На холсте Processed выполнился три раза, Batch Orders - четыре: последний вызов выдал общий результат через done. Поэтому четыре выполнения самого Batch Orders не означают четыре обработанных пакета.
Шаг 10. Посмотрите разные выполнения узла
Откройте Batch Orders. В OUTPUT есть выбор Run и вкладки Done Branch / Loop Branch. В нашем исходном запуске последняя запись Run показывала 4 of 4 и Done Branch с семью items. Это общий результат после обратного прохода последнего пакета.
Откройте Processed и просмотрите его выполнения: сначала O1/O2/O3, затем O4/O5/O6, затем O7. Только последний пакет содержит одну запись. Если интерфейс показывает одну запись или один выбранный Run, это ещё не означает, что весь workflow обработал только один заказ.
Шаг 11. Проверьте другой размер и неполный пакет
В Batch Orders измените Batch Size на 1, выйдите из поля и выполните всю цепочку заново. All Done снова получит семь заказов, но batch_number будет от 1 до 7 и items_in_batch = 1 у всех. Не запускайте только Execute step у циклического узла ради проверки всей схемы.
Верните Batch Size = 3. В Test Orders временно оставьте пять записей:
{
"orders": [
{
"order_id": "O1",
"amount": 100
},
{
"order_id": "O2",
"amount": 200
},
{
"order_id": "O3",
"amount": 300
},
{
"order_id": "O4",
"amount": 400
},
{
"order_id": "O5",
"amount": 500
}
]
}Полный запуск должен дать пакеты 3 и 2, All Done - пять заказов O1–O5. Остаток не отбрасывается. Если поставить Batch Size = 10 для исходных семи записей, получится один пакет из семи, а не десять записей: узел не дополняет данные. Эти варианты проверены тестами. Верните исходный JSON шага 3 и размер 3.
Шаг 12. Проверьте пустой список и обратное соединение
Для пустого набора временно замените JSON в Test Orders на:
{ "orders": [] }Выполните всю цепочку: после Split Orders нет items, Processed и All Done не должны выполниться. В этом примере пустота не создаёт отдельное уведомление или отчёт. Не включайте Always Output Data, если не хотите искусственно создавать item.
Верните семь заказов. Для проверки неполной схемы временно уберите только линию Processed → Batch Orders: выберите именно эту линию и удалите соединение, не узел. После полного запуска Processed обработает O1–O3, а All Done не запустится. Проверенный результат такого варианта: три обработанные записи и ноль итоговых.
Восстановите линию от выхода Processed к входу Batch Orders. Последний полный запуск должен снова дать семь записей в All Done, номера пакетов 1/2/3 и размеры 3/3/1. Оставьте workflow ручным и неопубликованным. Зелёное сообщение об успешном выполнении без этой сверки не доказывает, что обработаны все записи.
Если результат отличается
| Симптом | Что проверить | Исправление |
|---|---|---|
| Обработаны только O1–O3 | Возврат Processed → Batch Orders | Восстановить соединение |
| Цикл получил один item | Массив внутри orders | Сначала выполнить Split Out |
| All Done работает на каждом пакете | Подключён к loop | Подключить к done |
| Пропали ID и суммы | Processed / All Done | Include Other Input Fields → All |
| Виден только последний пакет | Выбранный Run в OUTPUT | Просмотреть все выполнения |
| Пустой набор без All Done | Нет входных items | Нормально для этой схемы |
Что учитывать перед подключением API
Размер пакета не является паузой в секундах. Эта схема не ограничивает число запросов в минуту, не повторяет 429 и не гарантирует отсутствие параллельных вызовов внутри обработчика. Для настоящего API отдельно определите лимиты, задержки, обработку ошибок и правила повторного выполнения. Не заменяйте Processed сразу узлом оплаты или массовой рассылки.
Получить JSON через HTTP Request
Проверьте, сколько items возвращает будущий обработчик: фильтрация или увеличение числа записей могут изменить итог done. Наш Edit Fields сохраняет число items. Для простой подготовки полей на всех записях цикл обычно не требуется: в этой инструкции он нужен именно для управляемого деления на пакеты.
Что проверено редакцией
10 октября 2026 года схема выполнена на n8n 2.42.4. Семь CLI-сценариев: пакеты 3/3/1, повторный запуск того же workflow, размер 1, размер 10, пять записей при размере 3, пустой массив, отсутствующий возврат. Все проверки размеров, ID, сумм, меток и итогового количества прошли. В новом workflow редактора nOM17TDmcS1vAg3L выполнены исходный набор, размер 1 и восстановление размера 3; скопированные OUTPUT All Done совпали с CLI. Старые 11 workflows не изменены, новая схема не опубликована, учебный контейнер возвращён в остановленное состояние. Cloud, реальные API, ожидание, 429, Reset, фильтрация внутри цикла, большие наборы и мобильная вёрстка не тестировались. Обложка - редакционная иллюстрация.
Частые вопросы
Зачем Loop Over Items, если узлы уже обрабатывают несколько items?
Для этой задачи он задаёт размер порций и отдельный этап после завершения. Если нужен только Edit Fields для всего списка, цикл может быть лишним. Наш пример специально показывает пакеты 3/3/1.
Чем отличаются выходы loop и done?
В учебной схеме loop передаёт очередной пакет в Processed, откуда есть возврат. done ведёт в All Done после обработки списка и передаёт общий результат из семи items.
Почему обработался только первый пакет?
Проверьте обратную линию Processed → Batch Orders. Без неё наш тест обработал только O1–O3, а All Done не выполнился. При этом сообщение об успешном выполнении не является проверкой полноты.
Ограничивает ли Batch Size частоту запросов API?
Сам по себе нет. Это размер порции items, не задержка и не лимит запросов за минуту. В примере нет внешних вызовов, Wait и обработки 429; их нужно настраивать отдельно.
Что произойдёт с последним неполным пакетом?
Он обработается в фактическом размере. Для семи записей при размере 3 получили 3/3/1, для пяти - 3/2. При размере 10 семь записей прошли одним пакетом.
