Лимиты Apply to each и постраничная разбивка в Power Automate: порог в 100 000

Когда поток в Power Automate внезапно завершается с непонятной ошибкой, как только список SharePoint, таблица Dataverse или диапазон Excel превышают определённый размер, почти всегда причина кроется в одном из встроенных ограничений циклов и постраничной разбивки. Самым известным из них является лимит в 100 000 для циклов Apply to each и постраничных элементов. В повседневной работе оно долго остаётся незаметным, потому что большинство списков намного меньше, а затем поражает именно те процессы, которые важнее всего: массовые импорты, закрытие годового периода или миграцию больших объёмов данных.

Эта статья объясняет, какие именно лимиты действуют для циклов и постраничной разбивки в Power Automate, как включить постраничную разбивку для действия и с помощью каких приёмов можно надёжно обрабатывать даже очень большие объёмы данных, не упираясь в лимит 100 000 итераций. Все сведения взяты из официальной документации Microsoft.

Какие лимиты действуют для циклов и постраничной разбивки?

Microsoft документирует соответствующие значения в обзоре Лимиты для автоматизированных, запланированных и мгновенных потоков. Самые важные цифры для одного запуска потока:

• Apply to each: 5000 элементов в профиле производительности «Низкий», 100 000 элементов для всех остальных профилей. Это максимальное количество элементов массива, которое может обработать цикл Apply to each.
• Постраничные элементы: также 5000 для «Низкого», 100 000 для всех остальных профилей. Чтобы обработать больше элементов, необходимо запускать несколько выполнений потока для своих данных.
• Split On: 5000 для «Низкого» без параллелизма триггера, 100 000 для всех остальных без параллелизма триггера, но только 100, как только параллелизм триггера включён.
• Итерации Until: по умолчанию 60, максимум 5000.
• Apply to each (параллелизм): значение по умолчанию для одновременно выполняемых итераций равно 1, но его можно увеличить до значения от 1 до 50.

Какой профиль производительности действует для твоего потока, зависит от лицензии его владельца. «Низкий» затрагивает, среди прочего, бесплатные планы, планы Microsoft 365, план Power Apps 1 и пробные лицензии, тогда как премиум-лицензии, лицензии на процессы и полётные лицензии попадают в профили «Средний» или «Высокий» и поэтому могут использовать полный лимит 100 000.

Ошибка WorkflowRunActionRepetitionQuotaExceeded

Когда цикл Apply to each достигает максимального числа итераций, поток завершается с ошибкой `WorkflowRunActionRepetitionQuotaExceeded`. Согласно справочнику кодов ошибок облачного потока наиболее частые причины таковы:

• действие Get items или List rows, которое возвращает все записи вместо того, чтобы быть отфильтрованным заранее
• вложенные циклы Apply to each, число итераций которых перемножается, например 100 умножить на 100 равно 10 000 проходов
• очень большой список SharePoint или таблица Dataverse, которые полностью загружаются в цикл без фильтра

В качестве решения Microsoft рекомендует ограничивать данные уже в исходном действии с помощью OData-фильтров, таких как `$filter` и `$top`, вместо фильтрации только внутри цикла, распределять большие наборы данных по нескольким выполнениям потока с помощью токенов постраничной разбивки или диапазонов дат, а для чистых преобразований или фильтраций использовать действия Select или Filter array вместо полного цикла Apply to each.

Включение постраничной разбивки для действия

Для многих действий с данными, например List rows в Dataverse, постраничную разбивку можно настроить прямо в параметрах действия. Документация по спискам строк в потоках описывает этот путь в новом конструкторе так:

1. Выбери соответствующую карточку действия, например List rows.

2. Открой в левой области вкладку Параметры, а затем Сеть.

3. Переведи переключатель Разбиение на страницы в положение Вкл.

4. Введи в поле Пороговое значение максимальное желаемое количество строк. Наибольшее настраиваемое пороговое значение составляет 100 000.

Внутри Power Automate округляет это значение до целых кратных размера страницы по умолчанию. Если, например, ввести 7000, а размер страницы составляет 5000, фактически будет возвращено 10 000 строк. Без включённой постраничной разбивки автоматически действует стандартный лимит в 5000 строк, и ответ больше не содержит параметр `@odata.nextLink`, как только пороговое значение превышено.

Особый случай SharePoint: Get items и порог в 5000

Для действия SharePoint Get items стандартный лимит составляет и вовсе всего 100 элементов, но его можно увеличить до 5000 с помощью расширенных параметров и параметра Top Count, прежде чем список упрётся в собственный порог представления SharePoint. Если объединить запрос с фильтром и список с более чем 5000 записей, может случиться так, что результаты вообще не вернутся, хотя подходящие записи существуют. И здесь включение постраничной разбивки в параметрах действия с достаточно высоким пороговым значением помогает, потому что Power Automate тогда извлекает данные пакетами согласно Top Count, вместо того чтобы проверять только первые 5000 неотфильтрованных строк.

Лимит всплеска действий: 100 000 действий за 5 минут

Помимо самого числа итераций, существует ещё один, часто упускаемый из виду тормоз: лимит всплеска действий. Согласно рекомендациям по пониманию лимитов платформы текущий верхний предел составляет 100 000 действий на поток в пределах скользящего окна в пять минут. Каждое действие внутри цикла Apply to each учитывается отдельно, поэтому цикл с несколькими действиями за проход достигает этого лимита значительно быстрее, чем можно предположить, судя только по числу итераций. Microsoft рекомендует в таком случае распределять нагрузку между несколькими потоками, например с помощью дочерних потоков (Child Flows) или условий триггера, которые заранее предотвращают ненужные запуски.

Чистая обработка больших объёмов данных: практические рекомендации

Для процессов, которые предположительно приблизятся к лимиту 100 000, на практике оправдал себя чёткий подход:

• Фильтровать рано, а не поздно: Ограничивай записи уже в исходном действии с помощью `$filter`, `$top` или запроса с фильтром SharePoint, вместо того чтобы загружать весь список в цикл и проверять его только там.
• Избегать вложенности: При наличии нескольких вложенных друг в друга циклов Apply to each проверь, не перемножаются ли внешнее и внутреннее число итераций, и заранее выстрой, где возможно, обработку с помощью Select или Filter array.
• Распределять по нескольким запускам: Используй токены пропуска, диапазоны дат или запланированный триггер, чтобы планомерно распределить очень большой объём данных по нескольким выполнениям потока, вместо того чтобы обрабатывать всё за один запуск.
• Целенаправленно использовать параллелизм: Если увеличить параллелизм цикла Apply to each до значения больше 1, несколько итераций выполняются одновременно, что экономит время выполнения, но повышает нагрузку на подключённые системы, и поэтому подходит не для каждого коннектора.
• Следить за лимитами: Регулярно проверяй через Аналитику на странице сведений о потоке фактическое число действий, вместо того чтобы реагировать только после ошибки.

Такой подход позволяет тебе сохранять контроль над своим потоком данных, вместо того чтобы быть застигнутым врасплох внезапным сбоем именно в том процессе, который и так заслуживает наибольшего внимания.

Кому стоит оптимизировать такие массовые процессы?

Отдельный цифровой сотрудник в Power Automate обычно упирается в лимит 100 000 только тогда, когда компания действительно растёт, например при миграции большой устаревшей базы данных, при ежегодной отчётности по всем клиентским записям или при подключении ERP-системы с несколькими десятками тысяч позиций. Для таких случаев чистая архитектура из отфильтрованных исходных запросов, разумно рассчитанной постраничной разбивки и, при необходимости, нескольких последовательных выполнений потока окупается с самого начала гораздо больше, чем последующее латание отдельных ошибок. Тот, кто хочет с самого начала построить свои процессы Power Automate для больших объёмов данных надёжно, найдёт поддержку в консультациях NordFlux по Power Automate.

Часто задаваемые вопросы

Что произойдёт, если потоку нужно обработать более 100 000 элементов?

Power Automate обрабатывает не более 100 000 элементов за один запуск потока в одном цикле Apply to each или в одном постраничном действии. Для больших объёмов данных Microsoft рекомендует запускать несколько выполнений потока для этих данных, например с помощью токена пропуска, фильтра по дате или запланированного триггера, который разбивает обработку на несколько частей.

Действует ли лимит 100 000 одинаково для каждой лицензии?

Нет. Лимит в 100 000 действует для профилей производительности «Средний» и «Высокий», к которым относятся, среди прочего, премиум-лицензии и лицензии на процессы. В профиле производительности «Низкий», который действует для бесплатных планов, планов Microsoft 365 и пробных лицензий, тот же лимит составляет уже 5000 элементов.

Чем лимит Apply to each отличается от лимита Split On?

Лимит Apply to each относится к циклу, который проходит по массиву в рамках одного запуска потока. Лимит Split On, напротив, касается триггеров, которые поставляют массив и разбивают его напрямую на несколько отдельных экземпляров рабочего процесса с помощью свойства SplitOn, вместо использования цикла foreach. Если для такого триггера дополнительно включён параллелизм триггера, лимит Split On снижается до 100 элементов.

Как понять, что поток упирается в лимит 100 000?

Поток завершается с ошибкой `WorkflowRunActionRepetitionQuotaExceeded`, как только цикл Apply to each превышает максимальное число итераций. В истории выполнения потока эту ошибку можно проследить напрямую до затронутого действия цикла, а через Аналитику на странице сведений о потоке ты дополнительно видишь, сколько действий в общей сложности потребил запуск.

Могу ли я установить порог постраничной разбивки выше 100 000?

Нет. Согласно документации Microsoft, максимальное настраиваемое пороговое значение для постраничной разбивки составляет 100 000, независимо от того, какое значение ты вводишь в поле параметров. Поскольку внутренне значение округляется до целых размеров страниц, фактически возвращённое число может быть немного больше введённого значения, но никогда не превышает верхний предел в 100 000.

Источники: Microsoft Learn — лимиты для автоматизированных, запланированных и мгновенных потоков, Microsoft Learn — понимание лимитов платформы и предотвращение ограничения скорости, Microsoft Learn — использование списков строк в потоках