Если из большого списка в отчёт нужны только три крупнейших заказа, сначала нужно задать порядок, а затем ограничить результат. Limit в n8n оставляет заданное количество items с начала или конца списка. Соберём топ-3 и проверим, что это действительно крупнейшие заказы, а не первые три из случайной выгрузки.
Результат инструкции
Workflow ezGPT - Top Orders получает пять вымышленных заказов. Sort ставит их по сумме от большей к меньшей, а Limit оставляет первые три: O1, O2 и O3. Сумма выбранных заказов — 420000 копеек, или 4200 рублей. Сводка покажет: на входе 5, выбрано 3, исключено из результата 2.
Остальные заказы не удаляются из исходной системы. Мы лишь не передаём их дальше по этой цепочке. Никакие письма, оплаты или записи в CRM не выполняются: action_performed false. AI-модель здесь не нужна, используем Sort и Limit.
Что понадобится
- Работающий n8n и права создать отдельный workflow. Пример проверен на n8n 2.42.4, узлы Sort и Limit версии 1.
- Вымышленные данные и ручной запуск. API-ключи, платная модель и внешняя база не нужны.
- Отдельная учебная схема без подключения платежей, CRM и рассылки.
Установить локальный n8n через Docker
Шаг 1. Импортируйте готовый workflow
Скачать n8n-limit-top-orders.json
Создайте новый workflow. В меню редактора выберите Import from File и загрузите JSON. Если браузер показывает текст, сначала сохраните файл через «Сохранить как». После импорта должны появиться шесть узлов:
Manual Trigger → Sample Orders → Validate Orders → Sort Orders → Limit Orders → Top SummaryТри узла Sample Orders, Validate Orders и Top Summary — Code. Sort Orders — Sort, Limit Orders — Limit. При ручной сборке задайте именно эти имена: сводка обращается к Validate Orders по имени. Импорт не содержит чужого ID workflow и credentials, остаётся неопубликованным.
Шаг 2. Подготовьте пять отдельных заказов
Откройте Sample Orders. Mode: Run Once for All Items, Language: JavaScript. Замените стандартный пример этим кодом:
Показать код (34 строк)
const orders = [
{
"order_id": "O3",
"order_rank": 3,
"client": "Гамма",
"amount_minor": 120000
},
{
"order_id": "O1",
"order_rank": 1,
"client": "Альфа",
"amount_minor": 150000
},
{
"order_id": "O5",
"order_rank": 5,
"client": "Эпсилон",
"amount_minor": 50000
},
{
"order_id": "O4",
"order_rank": 4,
"client": "Дельта",
"amount_minor": 0
},
{
"order_id": "O2",
"order_rank": 2,
"client": "Бета",
"amount_minor": 150000
}
];
if (!orders.length) throw new Error('orders_empty');
return orders.map(json => ({ json }));| Поле | Тип | Правило примера |
|---|---|---|
| order_id | String | Непустой уникальный ID |
| order_rank | Number | Уникальное целое число от 1 |
| client | String | Непустое имя клиента |
| amount_minor | Number | Целые копейки от 0 |
После ручного запуска триггера выполните Sample Orders либо весь workflow. Output источника должен содержать пять отдельных items в порядке O3, O1, O5, O4, O2. Наиболее крупный O2 намеренно стоит последним: это позволит заметить ошибку, если ограничить список до сортировки.
order_rank задаёт порядок при равных суммах. Это отдельный учебный ключ, не оценка клиента и не положение строки после сортировки. Суммы записаны числами без кавычек, в копейках.
Шаг 3. Проверьте данные до отбора
Откройте Validate Orders. Mode: Run Once for All Items, Language: JavaScript. Вставьте код:
const items = $input.all();
const ids = new Set();
const ranks = new Set();
for (const { json: row } of items) {
if (typeof row.order_id !== 'string' || !row.order_id.trim() || ids.has(row.order_id)) {
throw new Error('order_id_missing_or_duplicate');
}
if (!Number.isSafeInteger(row.order_rank) || row.order_rank < 1 || ranks.has(row.order_rank)) {
throw new Error('order_rank_invalid_or_duplicate');
}
if (!Number.isSafeInteger(row.amount_minor) || row.amount_minor < 0) {
throw new Error('amount_minor_invalid');
}
if (typeof row.client !== 'string' || !row.client.trim()) {
throw new Error('client_required');
}
ids.add(row.order_id);
ranks.add(row.order_rank);
}
return items;В Settings оставьте On Error: Stop Workflow и Execute Once выключенным. Проверка не меняет поля, но останавливает схему при повторных ID, неверном ранге или сумме. null и строка «120000» не считаются корректными числовыми копейками.
Проверяются все пять входных записей, не только будущий топ-3. Limit после этой проверки не позволяет просто спрятать ошибочную запись в хвосте. Если в рабочем процессе ошибки нужно разбирать отдельно, настройте явную ветку проверки, а не пропускайте их молча.
Шаг 4. Задайте порядок до Limit
Откройте Sort Orders. Type: Simple. В Fields To Sort By первое поле amount_minor, Order Descending; второе поле order_rank, Order Ascending. Имена полей вводятся обычным текстом в Fixed, не выражениями и не конкретными значениями одного заказа.
1. amount_minor — Descending
2. order_rank — AscendingНа выходе Sort должен быть порядок O1, O2, O3, O5, O4. Для равных сумм O1 идёт раньше O2 по рангу. Сначала получаем полный упорядоченный набор, затем ограничиваем количество.
Подробно о двух ключах сортировки в n8n
Шаг 5. Оставьте первые три записи
Откройте Limit Orders. Max Items: 3. Keep: First Items. Это обычное фиксированное положительное целое число; поле интерфейса имеет минимальное значение 1.
First Items берёт начало текущего списка. После нашей сортировки это O1, O2 и O3. Сам Limit не сравнивает суммы и не знает, что значит «крупный заказ». У него нет отдельного условия по сумме.
В Settings оставьте Always Output Data и Execute Once выключенными, On Error: Stop Workflow. В этом примере не создаём служебную пустую запись и не ограничиваем вход первой записью.
Шаг 6. Добавьте сводку выбранного набора
Откройте Top Summary. Mode: Run Once for All Items, Language: JavaScript. Вставьте код целиком:
const source = $('Validate Orders').all();
const selected = $input.all().map(item => item.json);
let total = 0;
for (const row of selected) {
total += row.amount_minor;
if (!Number.isSafeInteger(total)) throw new Error('selected_total_out_of_range');
}
return [{ json: {
input_count: source.length,
selected_count: selected.length,
excluded_count: source.length - selected.length,
selected_ids: selected.map(row => row.order_id),
amounts_minor: selected.map(row => row.amount_minor),
selected_amount_minor: total,
selected_amount_rub: total / 100,
action_performed: false,
} }];input_count берётся из Validate Orders, то есть до ограничения. selected_count считает выход Limit. selected_amount_minor — сумма только выбранных заказов, не всей исходной выгрузки. selected_ids и amounts_minor соответствуют друг другу по позиции.
В коде есть проверка переполнения суммы. Учебные счётчики рассчитаны на один набор за запуск, без циклов, нескольких входов и повторных запусков узлов внутри execution.
Шаг 7. Запустите цепочку и сверьте топ-3
Нажмите Execute Workflow. В Sort Orders должно быть пять items, в Limit Orders — три. Проверьте полный список после Sort и границу отбора:
| Позиция / ID | Сумма в копейках | Результат Limit |
|---|---|---|
| 1 / O1 | 150000 | Выбран |
| 2 / O2 | 150000 | Выбран |
| 3 / O3 | 120000 | Выбран |
| 4 / O5 | 50000 | Не передаётся дальше |
| 5 / O4 | 0 | Не передаётся дальше |
В Top Summary ожидается:
{
"input_count": 5,
"selected_count": 3,
"excluded_count": 2,
"selected_ids": [
"O1",
"O2",
"O3"
],
"amounts_minor": [
150000,
150000,
120000
],
"selected_amount_minor": 420000,
"selected_amount_rub": 4200,
"action_performed": false
}Сверьте client, order_rank и amount_minor выбранных items с исходными данными. Limit сохраняет значения и порядок выбранной части, а не создаёт новые заказы.
Шаг 8. Проверьте другой размер результата
Поставьте Max Items: 1 и выполните всю цепочку: останется O1, selected_count 1 и сумма 150000 копеек. Поставьте 2: останутся O1 и O2, сумма 300000.
Теперь поставьте 10. На входе только пять заказов, поэтому результатом будут все пять в отсортированном порядке, selected_count 5, excluded_count 0, сумма 470000 копеек. Limit задаёт верхнюю границу, не дополняет результат до нужного числа. Верните Max Items: 3.
Шаг 9. Сравните First Items и Last Items
На исходном наборе оставьте Max Items: 3, но переключите Keep на Last Items. После запуска получите O3, O5, O4 и сумму 170000 копеек. Это хвост отсортированного списка, не три крупнейших заказа.
Last Items не переворачивает выбранную часть: порядок остаётся O3, затем O5, затем O4. При Max Items: 1 останется O4 с нулевой суммой. Если нужно показать самый маленький заказ первым, отдельно задайте подходящую сортировку. Верните First Items и Max Items: 3.
Шаг 10. Проверьте короткий и пустой вход
В Sample Orders временно оставьте только первые два объекта O3 и O1, сохранив остальные строки кода. Запустите всю цепочку с Max Items 3: результат O1, O3, input_count 2, selected_count 2, excluded_count 0 и сумма 270000 копеек. Пустого третьего заказа не появится.
Теперь временно задайте const orders = []; и оставьте проверку длины в источнике. Ожидается orders_empty; Sort, Limit и сводка не должны успешно выполнить отбор. Это выбранная политика нашего примера, не встроенное сообщение Limit.
В рабочем отчёте пустая выгрузка может быть допустима: для неё заранее нужен явный no_data до разворачивания массива. Ошибку загрузки нельзя выдавать за отсутствие заказов. Восстановите все пять исходных объектов.
Шаг 11. Проверьте порядок узлов и равные суммы
Для контрольного теста временно соедините узлы так: Validate Orders → Limit Orders → Sort Orders → Top Summary. Max Items 3, Keep First Items. После запуска выбранными окажутся O1, O3, O5, сумма 320000 копеек. Крупный O2 потеряется, потому что стоял пятым в исходном наборе и был отрезан до сортировки.
Верните Validate Orders → Sort Orders → Limit Orders → Top Summary. Повторный запуск должен вернуть O1, O2, O3 и 420000 копеек. Проверять только количество 3 недостаточно: неверный набор тоже может содержать три записи.
Чтобы проверить границу равных сумм, временно поставьте O3 и O5 amount_minor 150000. Четыре заказа теперь имеют одинаковую сумму, но Limit всё равно выберет ровно три: O1, O2, O3 по рангу. O5 не попадёт в результат. Если бизнес-правило требует включить всех с суммой на границе топа, одного Limit недостаточно. Верните суммы O3 120000 и O5 50000.
Шаг 12. Восстановите настройки и проверьте ошибки
В Sample Orders верните пять исходных записей. У O3 временно замените сумму на строку «120000», заключив её в кавычки: запуск должен остановиться в Validate Orders с amount_minor_invalid, без успешной сводки. Верните число без кавычек.
Повторный ID, null или дробная сумма тоже не должны давать корректный топ. Не включайте Continue On Error для обхода проверки. На рабочем входе нужны согласованные правила исправления данных.
Финальные настройки: Sort по amount_minor Descending, затем order_rank Ascending; Limit после Sort, Max Items 3, Keep First Items. Снимите pin data, если закрепляли данные, сохраните workflow и выполните его заново. Ожидается 5 входных записей, 3 выбранные, ID O1/O2/O3, 420000 копеек и action_performed false. Публикация ручной схемы не требуется.
Если результат отличается
| Симптом | Причина | Что проверить |
|---|---|---|
| Три записи, но пропал крупный заказ | Ограничение выполнено раньше Sort | Sort перед Limit |
| Попали небольшие суммы | Выбран хвост или Ascending | Keep First Items и сумма Descending |
| Выбрано меньше Max Items | Вход короче заданного лимита | Количество items до Limit |
| Сумма кажется заниженной | Посчитан только выбранный набор | selected_amount_minor, не общий итог |
| amount_minor_invalid | Тип или значение суммы неверны | Число, целые копейки, не null |
Что Limit не ограничивает
В нашей цепочке источник и проверка получают пять записей, Sort сортирует все пять, а Limit сокращает только выход. Он не отменяет уже выполненные запросы, не уменьшает прочитанную выгрузку и не является защитой от большого ответа API. Для этого нужны параметры источника, серверная пагинация и отдельные ограничения размера данных.
Limit не задаёт скорость запросов, не делает паузы и не разбивает список на пакеты. Для обработки пакетами нужен Loop Over Items. Если Limit выполняется отдельно для каждой страницы API или каждого пакета, получится отдельный топ в каждой порции, а не общий топ всего набора.
Получить все нужные страницы API
Обрабатывать записи пакетами через Loop Over Items
В этой инструкции ни один заказ не оплачивается и не удаляется. Перед внешним действием отдельно проверяются права, дубли и подтверждение. Попадание в топ по сумме само по себе не разрешает выполнить действие.
Что проверено редакцией
14 октября 2026 года схема проверена на n8n 2.42.4 в отдельном локальном Docker-экземпляре через штатные ручные запуски API. Двадцать два теста: основной топ-3; First Items с лимитами 1, 2, 5 и 10; Last Items с лимитами 1, 2 и 3; две записи; одна запись; обратный входной список; Limit перед Sort; Sort Ascending; равные суммы на границе отбора; пустой вход; строковая и null-сумма; повтор ID; неверный ранг; переполнение выбранной суммы; отсутствие суммы; дробные копейки. Сверены точные выбранные ID, неизменные поля, порядок, число записей до и после ограничения, суммы и action_performed false. При ошибках успешной сводки нет. Редакторские клики, Cloud, большие данные, реальные API, пагинация и циклы в этой схеме не тестировались. Официальные настройки и реализация Limit версии 1 сверены с документацией и кодом штатного узла. Учебный контейнер остановлен; чужие workflows не менялись. Обложка — редакционная AI-иллюстрация.
Частые вопросы
Limit выбирает самые большие суммы?
Нет. Он берёт начало или конец уже полученного списка. Для топа по сумме в нашей схеме сначала выполняется Sort Descending, затем Limit First Items.
Почему осталось только два заказа при Max Items 3?
На входе может быть только две записи. Max Items — верхняя граница; Limit не добавляет недостающие items и не создаёт пустой третий заказ.
Last Items разворачивает порядок?
Нет. Он сохраняет конец списка в его текущем порядке. После нашей сортировки с лимитом 3 это O3, O5, O4, а не обратная последовательность.
Limit уменьшает число запросов к API?
Не уменьшает запросы, которые уже выполнены до него. Здесь все пять заказов получены, проверены и отсортированы заранее. Ограничение загрузки и скорость запросов настраиваются отдельно.
Можно ли включить все заказы с одинаковой суммой на границе топа?
Для такого правила нужен отдельный отбор по пороговому значению. Limit оставляет не больше Max Items: в нашем тесте из четырёх равных сумм выбраны только три записи по второму ключу сортировки.
