Обработка ошибок и повторные попытки в Power Automate — как не допустить, чтобы работающий поток незаметно остановился

«Поток агрегации, который работал каждое утро, на самом деле стоял с прошлой недели». «Поток регистрации заказов дважды обработал одни и те же данные, и в реестре появились дубликаты». Мы регулярно слышим подобные жалобы от компаний, которые построили поток на Power Automate и начали его эксплуатировать. Построить было легко, а вот то, что поток остановился, никто не заметил, — типичная картина.

Пока речь идёт только о happy path, поток Power Automate способен работать часами без сбоев. Но подключённые сервисы временно падают, аутентификация истекает, а неожиданные данные рано или поздно обязательно появятся. Поток, не спроектированный на случай «что происходит при сбое», молча накапливает сбои и в худшем случае автоматически отключается через 14 дней¹. В этой статье разберём паттерны проектирования обработки ошибок, выдерживающие продакшен-эксплуатацию: от классификации сбоев потока и точной спецификации стандартного retry до паттерна Try-Catch-Finally на основе Scope, механизмов обнаружения сбоев, повторного выполнения и идемпотентности. Выбор в целом по Power Automate и обработка ошибок на стороне UI-автоматизации (потока рабочего стола) разобраны в статье «Автоматизация бизнес-процессов с Power Automate — выбор между облачным потоком и потоком рабочего стола, проектирование обработки ошибок», поэтому здесь мы сосредоточимся на глубоком разборе именно облачных потоков.

1. Сначала вывод

• Сбои стоит рассматривать в четырёх категориях: «временный сбой», «вызванный данными», «истечение прав/аутентификации» и «изменение спецификации». Стандартный retry решает проблему только в первом случае, для остальных трёх нужны механизмы обнаружения и исправления².
• Стандартная политика повтора срабатывает только при таймауте запроса или сбое с ответом 408, 429 либо 5xx. По умолчанию используется экспоненциальная задержка, а количество попыток зависит от уровня лицензии (профиля производительности) — до 2 или до 12 попыток³¹.
• Базовая форма обработки ошибок — это Try-Catch-Finally на основе Scope и настройки «Конфигурация условия выполнения» (run after). Условие выполнения выбирается из четырёх состояний: «Succeeded», «Failed», «Skipped», «TimedOut»³⁴.
• Обработав сбой в Catch, в конце обязательно фиксируйте выполнение как «Failed» действием Terminate. Если этого не сделать, история выполнения покажет успех, и сбой окажется скрыт⁴³.
• Стандартное письмо-уведомление о сбое ограничено «сбоями с известным способом исправления» и снабжено 28-дневным периодом охлаждения — механизм с слишком большим числом дыр, чтобы полностью на него полагаться. Считайте собственное уведомление из блока Catch обязательным⁵.
• История выполнения по умолчанию видна только за 28 дней. Поток, продолжающий давать сбои, автоматически отключается через 14 дней. Ситуация «заметил остановку только через месяц» вполне возможна по спецификации⁶¹.
• На случай повторного выполнения (переотправки) и дублирующихся запусков с самого начала закладывайте идемпотентный дизайн, безопасный при двойном выполнении (флаг обработки, upsert вместо создания, условия триггера)⁷⁸.

2. Как отказывает поток — четыре категории сбоев

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

Из них самая неприятная на практике категория — истечение прав или аутентификации, потому что отказывать начинают не только действия потока, но и сам триггер. В официальном руководстве по устранению неполадок в качестве типичного примера сбоя триггера с ошибкой класса 4xx приводится именно смена (истечение срока) пароля, использованного для подключения. Когда триггер отказывает, поток вообще не запускается, поэтому в истории выполнения не остаётся даже строки «Failed», и заметить проблему получается ещё позже⁹. Поскольку подключение привязано к конкретному создавшему его пользователю, увольнение или перевод сотрудника может обрушить сразу целую партию подключений. Организационные меры на этот случай подробно разобраны в статье «Меры против привязки Power Automate к одному человеку — владельцы, подключения, передача дел».

Ещё одна вещь, которую стоит знать: если сбои игнорировать, сам поток отключат. Поток, у которого триггер или действия продолжают отказывать, автоматически отключается через 14 дней; поток, который постоянно подвергается троттлингу, тоже отключается через 14 дней. Поток, не срабатывавший 90 дней, также может быть отключён (если только его владелец не обладает премиум-лицензией или лицензией на ёмкость)¹. Кроме того, из-за нарушения политики DLP или повторяющихся сбоев поток может оказаться в состоянии «приостановлен» (suspended)¹⁰. Некоторая доля случаев «работавший поток вдруг остановился» — это не сбой, а именно эта особенность в действии.

3. Разбираемся со стандартным retry

В каждое действие Power Automate (в основе которого лежит Azure Logic Apps) политика повтора встроена изначально. Зная эту спецификацию точно, вы сможете решить, стоит ли добавлять собственные настройки retry или сбой в принципе retry не решает.

Что и когда повторяется

Политика повтора срабатывает, когда запрос действия (или триггера) завершается таймаутом либо сбоем с ответом 408 (тайм-аут запроса), 429 (слишком много запросов = троттлинг) или 5xx (ошибка сервера)³. Политика по умолчанию — экспоненциальная задержка (повтор с экспоненциально увеличивающимся интервалом), а количество попыток и интервал по умолчанию в Power Automate зависят от профиля производительности потока (по сути — от уровня лицензии)¹.

Иначе говоря, даже при абсолютно одинаковом определении потока «выносливость к временным сбоям» различается в зависимости от лицензии владельца. Профиль влияет не только на количество повторов, но и на суточный лимит запросов, поэтому уровень лицензии стоит держать в уме как полноценный фактор проектирования; подробнее об этом — в статье «Лицензирование Power Automate и граница между стандартными и премиум-коннекторами».

Политику повтора можно изменить в настройках действия. Есть четыре типа: по умолчанию, отсутствует, фиксированный интервал, экспоненциальный интервал — количество попыток и интервал можно задать явно. Ограничения настройки: до 90 попыток, минимальный интервал 5 секунд, максимальная задержка 1 день³¹. Собственные рекомендации Microsoft по написанию кода советуют для восстановления после временного сбоя экспоненциальный интервал, а не фиксированный, — чтобы не долбить собеседника с коротким интервалом и не мешать его собственному восстановлению⁴.

Что решает retry, а что нет

Стоит помнить, что retry тоже расходует лимит запросов (Power Platform requests). Каждое выполнение действия засчитывается в лимит запросов независимо от успеха или неудачи, и то же самое касается запросов retry и пагинации¹. Настройка «увеличить число попыток» в ответ на 429 иногда лишь усугубляет троттлинг, поэтому прежде чем усиливать retry, стоит сначала подумать, нельзя ли сократить само количество вызовов.

4. Паттерн Try-Catch-Finally — Scope и конфигурация условия выполнения

Сбой, который retry не решает, нужно перехватывать и обрабатывать прямо внутри потока. В Power Automate нет синтаксиса try-catch как такового, но ту же структуру можно построить, комбинируя Scope (область) и «Конфигурацию условия выполнения» (run after). Это стандартный приём, который рекомендуют и собственные рекомендации Microsoft по написанию кода⁴.

Основой всего механизма служит именно конфигурация условия выполнения. По завершении каждое действие получает одно из состояний — успех (Succeeded), сбой (Failed), пропуск (Skipped) или таймаут (TimedOut), и следующее за ним действие по умолчанию выполняется только «если предыдущее действие завершилось успехом». Это условие можно менять для каждого действия отдельно, создавая ветку, которая выполняется «в случае сбоя» или «в случае таймаута»³.

Применив это к Scope, получаем Try-Catch-Finally. Scope сводит результаты всех вложенных действий в единое общее состояние, поэтому конструкция «если что-то внутри Try-области дало сбой, выполнить Catch-область» получается несравнимо проще в поддержке, чем настройка условий вокруг каждого отдельного действия³⁴.

flowchart TD
    Trigger[Триггер] --> Try[[Try-область<br/>здесь размещается основная обработка]]
    Try -- Успех --> Fin
    Try -- Сбой / Таймаут --> Catch[[Catch-область<br/>условие выполнения: сбой или таймаут]]
    Catch --> Extract[Функцией result + фильтрацией массива<br/>извлекаем неудачное действие и причину]
    Extract --> Notify[Уведомить ответственного через Teams / почту<br/>имя потока, неудачный шаг, детали ошибки, URL выполнения]
    Notify --> Fin[[Finally-область<br/>условие выполнения: успех, сбой, пропуск, таймаут - все четыре]]
    Fin --> Cleanup[Уборка: обновить столбец статуса в реестре]
    Cleanup --> Judge{Прошли через Catch?}
    Judge -- Да --> Term[Terminate<br/>статус: Failed, завершение выполнения]
    Judge -- Нет --> Done([Нормальное завершение])

Есть четыре ключевых момента в том, как это строить.

• Установите условие выполнения Catch-области на «в случае сбоя» и «в случае таймаута» одновременно. Уберите настройку по умолчанию «в случае успеха». Если выбрать только «сбой», таймаут ожидания согласования или отложенного действия проскользнёт незамеченным³.
• Извлеките содержимое сбоя внутри Catch. Функция result('ИмяTryОбласти') возвращает результаты (статус, входы/выходы, текст ошибки) действий, непосредственно вложенных в область, в виде массива, поэтому «фильтрацией массива» по статусам Failed или TimedOut можно поместить в уведомление имя неудачного действия и текст ошибки³⁴. Если фильтровать только по Failed, при попадании в Catch через таймаут результат извлечения окажется пустым, и из уведомления пропадёт как раз тот шаг, который важнее всего. Также стоит извлечь ID выполнения через функцию workflow() и собрать прямую ссылку на историю выполнения — это сильно упрощает расследование⁴.
• Установите условие выполнения Finally-области на все четыре состояния. Здесь размещается уборка, которую нужно провести обязательно вне зависимости от успеха или сбоя — удаление временных файлов, обновление столбца статуса в реестре и т. п.
• Неудачное выполнение в конце обязательно завершайте действием Terminate со статусом «Failed». Это самый легко забываемый момент. Если Catch завершается нормально, выполнение потока в целом заканчивается успехом последнего действия, и в истории выполнения это фиксируется как «Succeeded». То есть, если ограничиться только уведомлением, сбой становится невидимым в истории выполнения и выпадает из мониторинга и последующей статистики. Если же завершить выполнение через Terminate, задав статус Failed и сообщение об ошибке, в истории выполнения он тоже останется как сбой⁴³. Однако нельзя размещать Terminate прямо в конце Catch-области. Terminate немедленно завершает всё выполнение целиком в этот же момент, поэтому следующая за ним Finally-область не выполнится, и уборка, особенно нужная именно при ошибке, будет пропущена. Как показано на схеме, в Catch стоит только выставить флаг сбоя (переменную) и ограничиться уведомлением, затем после прохождения уборки в Finally проверить этот флаг и завершать выполнение через Terminate только в случае сбоя.

Отметим также, что конфигурация условия выполнения — это центральный строительный блок и для ветвления по таймауту в потоке согласования (напоминания, эскалация). Конкретная реализация разобрана в статье «Создание процесса согласования в Power Automate — перевод бумажных заявок и согласований по почте в электронный вид».

5. Механизмы обнаружения сбоя — уведомления и наглядность

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

Правильно понимаем стандартное письмо-уведомление о сбое

В Power Automate есть механизм отправки письма при сбое, но если полагаться на него, не зная спецификации, обнаружится масса дыр. Уведомлений два вида⁵.

• Оповещение о сбое на уровне выполнения: отправляется сразу после сбоя выполнения, но только если сбой признан «известным и имеющим способ исправления» — обрыв подключения, троттлинг, известная ошибка коннектора и т. п. При обычном сбое действия оно не отправляется. Получатели — владелец и совладельцы (пользователи, имеющие только право запуска, не включены), администраторам оно не приходит. Более того, после однократной отправки для того же потока действует 28-дневный период охлаждения, в течение которого дополнительные оповещения за новые сбои не приходят. Оповещения на уровне выполнения к тому же включены по умолчанию не для всех потоков — это нужно проверить в настройках потока⁵.
• Еженедельный дайджест сбоев: раз в неделю отправляется сводка сбоев по всем средам сразу. В неё попадают и обычные сбои, за которые оповещение на уровне выполнения не отправлялось⁵.

Кроме того, для определённых ошибок владельцу отправляется письмо с «подсказками по восстановлению» и шагами исправления (его тоже можно отключить для каждого потока отдельно)⁷. Подводя итог: стандартное уведомление — это механизм, который «позволяет заметить первый обрыв подключения, но легко пропускает сбои, вызванные бизнес-данными, и повторные сбои». Для важных потоков считайте собственное уведомление из блока Catch (глава 4) обязательным.

Проектирование уведомления из Catch — случай, когда сам поток уведомления даёт сбой

У собственного уведомления тоже есть свои моменты проектирования.

• Не адресуйте уведомление конкретному человеку. Если оно уходит лично ответственному, оно перестанет доходить хоть до кого-то в его отсутствие или после увольнения. Официальная документация тоже рекомендует отправлять его в общий почтовый ящик или канал Teams¹⁰.
• Разделяйте маршрут уведомления и основной обработки. Типичная авария — «подключение Outlook оборвалось, поток дал сбой, а уведомление о сбое тоже не может отправиться, потому что использует то же подключение Outlook». При сбое, вызванном истечением аутентификации, действие уведомления, использующее то же подключение, отказывает одновременно с основным. Если для уведомления использовать другой коннектор и другое подключение, чем для основной обработки (например, публикацию в Teams), или вынести его в отдельный маленький специализированный поток уведомлений, вызываемый отдельно, риск совместного отказа снижается. Тем не менее «уведомление об уведомлении» до бесконечности не построить, поэтому в качестве последнего рубежа стоит держать регулярную проверку, описанную далее.
• Вкладывайте в уведомление всю информацию, нужную для расследования. Имя потока, имя неудачного действия, сообщение об ошибке, прямую ссылку на историю выполнения. Без этого уведомление сообщает лишь «что-то пошло не так» и не более того, и его легко проигнорировать⁴.

Наглядность и регулярные проверки

• Проверка потока (Flow checker): перед сохранением обнаруживает ошибки и предупреждения в определении потока. Заведите привычку запускать её один раз после того, как поток построен¹¹.
• Регулярная проверка истории выполнения: история выполнения потока по умолчанию отображается только за 28 дней⁶. Для потока, включённого в решение (solution), метаданные истории выполнения можно сохранять в Dataverse, но и там срок хранения по умолчанию — 28 дней, а его продление — настройка на стороне администратора¹². Для боевых потоков рекомендуется примерно раз в неделю проверять не только сбои, но и «выполнения в состоянии отмены» (которые иногда вызваны настройкой параллелизма) и «резкое падение числа выполнений» (признак того, что триггер перестал срабатывать)¹⁰.
• Централизованный мониторинг администратора: чтобы видеть абсолютно все сбои, включая те, за которые не отправляется оповещение на уровне выполнения, самый полный вариант — функция Monitor (мониторинг) в Центре администрирования Power Platform. Она позволяет проверять число сбоев и детали ошибок в разрезе потока или среды⁵.

Для планового потока нужен ещё и мониторинг того, сработал ли он вообще. Проектирование планового выполнения, включающего определение рабочего дня и обработку конца месяца, разобрано в статье «Проектирование регулярных потоков в Power Automate — практика обработки конца месяца, проверки рабочих дней и напоминаний».

6. Повторное выполнение и идемпотентность — делаем «не ломается даже при двойном запуске»

Реакция на сбой не заканчивается его обнаружением. Нужны сразу оба элемента: операция «переделать неудавшееся» и дизайн, при котором «переделка ничего не ломает».

Спецификация повторной отправки (resubmit)

Неудачное выполнение можно переделать из истории выполнения через повторную отправку (Resubmit). Это операция повторного выполнения с теми же данными триггера: для временного сбоя (500/502 и т. п.) достаточно просто переотправить как есть, а если причина — недочёт в определении потока, сначала исправьте и сохраните поток, и тогда повторная отправка выполнится уже по исправленному определению⁷. Из списка истории выполнения можно переотправить одновременно до 20 выполнений — это пригождается для восстановления после массового сбоя. Для потока с ручным запуском (мгновенный триггер) свои собственные выполнения можно переотправлять всегда, а для повторной отправки выполнений, запущенных другими пользователями, администратору нужно разрешить это через настройку клиента (tenant)¹³.

Важно понимать: повторная отправка запускает поток заново, с самого начала. Если переотправить выполнение, которое отказало на 8-м шаге из 10, шаги с 1-го по 7-й, уже успешно завершившиеся, тоже выполнятся снова. Именно отсюда берутся аварии вроде «письмо уже было отправлено, а его отправили ещё раз» или «в реестре появилась та же строка дважды».

Идемпотентность — дизайн, безопасный при двойном выполнении

Поэтому с самого начала закладывайте дизайн, при котором результат выполнения с одним и тем же вводом остаётся одинаковым сколько ни запускай (идемпотентный). Это самая суть проектирования ошибок — он защищает не только от повторной отправки, но и от дублирующихся срабатываний триггера и параллельных выполнений.

• Ведите флаг обработки. Дайте реестру (например, списку SharePoint) столбец «Статус» (Не обработано / В обработке / Обработано); в начале потока проверяйте статус — если уже обработано, завершайте выполнение прямо там, а по завершении обработки обновляйте статус. Так повторная отправка не приведёт к двойной обработке. Однако флаг работает, только если продумана ещё и очерёдность обновления. Для внешних побочных эффектов вроде отправки письма или регистрации в базовой системе сначала обновите статус на «В обработке», затем выполните действие, и только по завершении переводите в «Обработано». Выполнение, отказавшее после побочного эффекта, но до обновления флага, останется в состоянии «В обработке» — а это состояние, когда неизвестно, прошёл ли побочный эффект на самом деле. Механическая переотправка такой строки может привести к двойной отправке, поэтому строки со статусом «В обработке» исключайте из автоматического повторного выполнения и переводите их в «Обработано» или «Не обработано» вручную, только сверив с фактическим результатом отправки или регистрации. Безопасно переотправлять без раздумий можно только строки, застрявшие на «Не обработано».
• Используйте не безусловное «создание», а «обновить, если есть, создать, если нет» (upsert). Ищите существующую строку по уникальному ключу (номер заказа, ID заявки и т. п.) и ветвитесь: обновление при совпадении, создание при отсутствии. Безусловное «Создание элемента» при каждом повторном выполнении накапливает дублирующиеся строки. Иными словами, данные без уникального ключа сделать идемпотентными нельзя, поэтому определение ключевого столбца должно закладываться уже на этапе проектирования реестра.
• Останавливайте ненужные срабатывания условиями триггера. Многократные срабатывания, например когда поток с триггером «при создании или изменении элемента» перезапускает сам себя из-за собственной обратной записи, нужно останавливать не последующим условным ветвлением, а именно условиями триггера (trigger conditions). Для события, не удовлетворяющего условию триггера, выполнение вообще не возникает, поэтому не расходуется ни счётчик выполнений, ни лимит запросов⁸.

Есть один нюанс. Подход «сначала проверить, потом записать» — как флаг обработки, так и upsert — эффективен против последовательной переделки вроде повторной отправки, но сам по себе не является атомарной защитой. Если два дублирующихся события триггера срабатывают почти одновременно, может возникнуть гонка, при которой оба выполнения читают «Не обработано» и оба начинают обработку. Чтобы надёжно предотвратить дублирование в потоке, где возможны параллельные запуски, либо сериализуйте выполнение управлением параллелизмом, установив степень параллелизма в 1 (см. следующий раздел), либо дополнительно используйте механизм на стороне хранилища, способный принудительно применять ограничение уникальности ключа (например, уникальное ограничение базы данных), чтобы дублирующееся создание проваливалось уже на этапе записи.

Компромисс между управлением параллелизмом (concurrency control) и порядком

Наряду с двойным выполнением проблемой становится и пара «параллелизм» и «порядок». По умолчанию, если одновременно возникает множество событий, удовлетворяющих условию триггера, поток запускается параллельно в любом количестве экземпляров¹. Когда несколько выполнений одновременно читают и пишут одну и ту же строку реестра, может возникнуть несогласованность из-за чтения устаревшего значения и его перезаписи (dirty read)¹⁴.

Включив управление параллелизмом (Concurrency Control) в настройках триггера, можно задать число параллельных выполнений (степень параллелизма) от 1 до 100. При степени параллелизма 1 выполнение происходит только одно за раз, что приближает обработку к строгому порядку¹¹⁴. Однако у этого переключателя есть серьёзные оговорки.

• После включения отменить нельзя. Единственный способ вернуться к «выключено» — удалить триггер и создать заново¹. Поскольку управление параллелизмом необратимо, рекомендуется применять его только к потокам с небольшим числом действий (при необходимости вынося логику в дочерний поток)¹⁴.
• Возникает риск потери событий. При включённом управлении параллелизмом число выполнений, которые могут стоять в очереди ожидания, ограничено значением «10 + степень параллелизма»; триггер, поступивший, пока этот лимит превышен, будет повторён на стороне коннектора, но при длительном превышении лимита он может так и не дойти до выполнения. Официальная документация прямо указывает, что для потока, которому важно гарантированно довести до выполнения каждый триггер, управление параллелизмом стоит оставить выключенным¹. Если история выполнения переполнена состояниями отмены, причиной может быть именно эта настройка¹⁰.

Иначе говоря, «соблюдение порядка» и «отсутствие потерь» — это компромисс. Сериализация со степенью параллелизма 1 эффективна для процессов с небольшим потоком событий, где важен порядок (например, присвоение порядковых номеров в реестре), но её не стоит бездумно применять к обработке, куда в пиковые моменты приходит масса событий. Если строго нужны и порядок, и полнота одновременно, вы вступаете в область, которую, как сказано в главе 8, стоит проектировать за пределами Power Automate.

7. Контрольный список перед выводом в продакшен

Перед выводом нового потока в продакшен проверьте как минимум следующее.

Двенадцать пунктов могут показаться избыточными, но больше половины из них нужно продумать лишь один раз, в самом начале. И наоборот: «доделать задним числом» для потока, который пропустил этот список и сразу пошёл в продакшен, обычно так и не происходит — сказывается ещё и страх трогать то, что уже работает, — и дело обычно доходит до аварии.

8. Насколько далеко доверять Power Automate

Если довести обработку ошибок до предела, становятся видны требования, выходящие за пределы возможностей Power Automate. Вот примерные ориентиры для проведения границы.

На уровне ощущения граница проходит примерно так: пока процедуру восстановления после сбоя можно объяснить словами — это территория Power Automate, а как только объяснить без схемы уже не получается — это область разработки. В особенности работа, требующая компенсирующей транзакции (в системе компании A запись уже прошла, в системе компании B — сбой, отменять ли A?), сложнее, чем кажется по внешнему виду потока, и Terminate с уведомлением её не покрывают. Выбор с учётом Планировщика заданий и PowerShell разобран в статье «Выбор между Power Automate и PowerShell/Планировщиком заданий».

9. Итоги

«Работавший поток вдруг остановился» — почти никогда не невезение, а проблема проектирования. Поток рано или поздно обязательно даст сбой. Из четырёх категорий сбоев retry берёт на себя заботу только о временных сбоях; сбои, вызванные данными, истечением аутентификации и изменением спецификации, можно уловить только многоуровневым механизмом: перехват через Try-Catch, фиксация через Terminate, собственное уведомление и еженедельная проверка истории выполнения. Стандартное письмо-уведомление о сбое — ограниченный механизм с условиями и 28-дневным периодом охлаждения, и эксплуатация, полагающаяся только на него, гарантированно даст утечку.

И главная опора подготовки к сбою — не уведомление, а идемпотентность. Придав дизайну форму «не ломается даже при двойном выполнении» с помощью флага обработки и upsert, можно перестать бояться и повторной отправки, и дублирования триггера, а восстановление сведётся к «выбрать неудачное и переотправить». И наоборот: работу, требующую компенсирующей транзакции или строгой гарантии порядка, не стоит насильно втискивать в Power Automate — решение вынести её в область разработки в долгосрочной перспективе обходится дешевле. Именно в день, когда поток впервые заработал, стоит один раз пройтись по этому чек-листу.

Похожие статьи

• Автоматизация бизнес-процессов с Power Automate — выбор между облачным потоком и потоком рабочего стола, проектирование обработки ошибок
• Проектирование регулярных потоков в Power Automate — практика обработки конца месяца, проверки рабочих дней и напоминаний
• Создание процесса согласования в Power Automate — перевод бумажных заявок и согласований по почте в электронный вид
• Меры против привязки Power Automate к одному человеку — владельцы, подключения, передача дел
• Выбор между Power Automate и PowerShell/Планировщиком заданий

Смежные области консультирования

KomuraSoft LLC (合同会社小村ソフト) занимается ревью обработки ошибок и эксплуатационного проектирования потоков Power Automate, а также системной реализацией требований к гарантии порядка и транзакциям, которые в поток уже не укладываются.

• Техническая консультация и ревью проекта
• Разработка приложений для Windows
• Связаться с нами

Справочные ссылки

Похожие статьи

Недавние статьи с теми же тегами помогут подробнее изучить близкие темы.

Связанные темы

Эти страницы показывают тему статьи в более широком контексте услуг и решений.

Частые вопросы

Вопросы, которые часто возникают при консультациях по теме статьи.

Если поток Power Automate завершается сбоем, придёт ли автоматическое письмо с уведомлением?

Придёт лишь в ограниченном числе случаев. Оповещение о сбое на уровне выполнения отправляется владельцу и совладельцам только тогда, когда сбой признан «известным и имеющим способ исправления» — например, обрыв подключения или троттлинг, — но не при обычном сбое действия. Более того, после однократной отправки для того же потока действует 28-дневный период охлаждения, в течение которого дополнительные оповещения не приходят. Оповещения на уровне выполнения к тому же включены по умолчанию не для всех потоков. Чтобы гарантированно замечать сбои, рекомендуем встроить собственное уведомление в Teams или по почте прямо из блока Catch.

Сколько раз и с каким интервалом выполняется стандартный retry в Power Automate?

Если запрос действия завершается таймаутом или сбоем с ответом 408, 429 или в диапазоне 5xx, по умолчанию срабатывает автоматический повтор с экспоненциально увеличивающимся интервалом. Количество попыток зависит от профиля производительности потока (по сути — от уровня лицензии): для низкого профиля, например с лицензией Microsoft 365, — до 2 повторов, а для среднего и высокого профиля, например Power Automate Premium или лицензии Process, — до 12 повторов. В настройках действия политику повтора можно изменить на «нет / фиксированный интервал / экспоненциальный интервал», задав количество попыток вплоть до 90. Ошибки, вызванные данными или настройками, вроде 400 или 404, повторам не подлежат.

Как повторно запустить (переотправить) неудачное выполнение потока?

Откройте неудачное выполнение из истории выполнения и выберите «Повторная отправка» (Resubmit) — поток заново выполнится с теми же данными триггера. Если причиной был недочёт в определении потока, исправьте поток, сохраните и только потом переотправьте — тогда выполнение пройдёт уже по исправленному определению. Из списка истории выполнения можно переотправить одновременно до 20 выполнений. Важный нюанс: переотправка запускает поток заново с самого начала, поэтому в выполнении, которое частично успело завершиться успешно, уже выполненные шаги запустятся повторно. Нужен идемпотентный дизайн (флаг обработки, запись с приоритетом обновления, а не создания), при котором результат не портится даже при двойном выполнении.

Может ли поток отключиться незаметно для меня?

Да. Поток, у которого триггер или действия продолжают завершаться ошибкой, автоматически отключается через 14 дней. Поток, постоянно попадающий под троттлинг (превышение лимитов), тоже отключается через 14 дней. Кроме того, поток, ни разу не сработавший за 90 дней, тоже может быть отключён, если у его владельца нет премиум-лицензии или лицензии на ёмкость. Поскольку игнорирование сбоев напрямую ведёт к отключению потока, важно встроить в эксплуатацию механизм обнаружения сбоев и регулярную проверку истории выполнения (по умолчанию 28 дней).

Об авторе

Страница с профилем автора статьи.

Го Комура

Представитель KomuraSoft LLC

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