Обработка ошибок и исключений в рабочих процессах в Azure Logic Apps

Область применения: Azure Logic Apps (Потребление + Стандартный)

Способ, которым любая архитектура интеграции должным образом обрабатывает время простоя или проблемы, вызванные зависимыми системами, может создать проблему. Azure Logic Apps предоставляет эффективные возможности обработки ошибок и исключений, чтобы помочь вам создать надежную и устойчивую интеграцию, корректно обрабатывающую проблемы и сбои.

Политики повторных попыток

Для наиболее простой обработки исключений и ошибок можно использовать политику повторных попыток , если эта возможность существует в триггере или действии, например действие HTTP. Если исходный запрос триггера или действия превышает время ожидания или завершается сбоем, в результате чего возвращается код ответа 408, 429 или 5xx, политика повторных попыток предписывает триггеру или действию повторно отправить запрос в соответствии с параметрами политики.

Пределы политики повтора

Дополнительные сведения о политиках повтора, параметрах, ограничениях и пр. представлены в разделе об ограничениях политики повтора.

Типы политик повтора

Операции соединителя, поддерживающие политики повтора, используют политику По умолчанию, если только вы не выберете другую политику повтора.

Политика повтора	Описание
По умолчанию	Для большинства операций политика повтора По умолчанию — это политика с экспоненциальным интервалом, которая осуществляет до четырех повторных попыток с экспоненциально растущими интервалами. Интервалы увеличиваются с шагом в 7,5 секунд, но имеют границу от 5 до 45 секунд. Некоторые операции используют другую политику повтора По умолчанию, например политику фиксированного интервала. Дополнительные сведения см. в разделе о типе Политики повтора по умолчанию.
Не допускается	Не отправляйте запрос повторно. Дополнительные сведения см. в разделе Нет — политика повтора отсутствует.
Экспоненциальный интервал	Перед отправкой следующего запроса эта политика ожидает случайного интервала, выбранного из экспоненциально растущего диапазона. Дополнительные сведения см. в разделе о типе политики с экспоненциальным интервалом.
Фиксированный интервал	Эта политика ожидает определенный интервал времени перед отправкой следующего запроса. Дополнительные сведения см. в разделе о типе политики с фиксированным интервалом.

Измените тип политики повтора в конструкторе

Откройте ресурс приложения логики на портале Azure.
На боковой панели ресурсов выполните следующие действия, чтобы открыть конструктор рабочих процессов на основе приложения логики:
- Потребление: в разделе "Средства разработки" выберите конструктор, чтобы открыть рабочий процесс.
- Стандарт
  1. В разделе "Рабочие процессы" выберите "Рабочие процессы".
  2. На странице "Рабочие процессы" выберите рабочий процесс.
  3. В разделе "Сервис" выберите конструктор, чтобы открыть рабочий процесс.
В триггере или действии, в котором требуется изменить тип политики повторных попыток, выполните следующие действия, чтобы открыть параметры:
1. В конструкторе выберите операцию.
2. В области сведений об операции выберите "Параметры".
3. В разделе "Сеть" в разделе "Политика повторных попыток" выберите нужный тип политики.

Изменение типа политики повтора в редакторе представления кода

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

В определении триггера или действия добавьте retryPolicy объект JSON в объект триггера или действия inputs . Если объект retryPolicy не существует, используется политика повторения default.

"inputs": {
   <...>,
   "retryPolicy": {
      "type": "<retry-policy-type>",
      // The following properties apply to specific retry policies.
      "count": <retry-attempts>,
      "interval": "<retry-interval>",
      "maximumInterval": "<maximum-interval>",
      "minimumInterval": "<minimum-interval>"
   },
   <...>
},
"runAfter": {}

Обязательный

Свойство	Значение	Тип	Описание
`type`	< тип политики повторных попыток>	Строка	Необходимый тип политики повтора: `default`, `none`, `fixed` или `exponential`
`count`	< повторные попытки>	Целое	Для типов политик `fixed` и `exponential` — число повторов, равное значению от 1 до 90. Дополнительные сведения см. в Фиксированном интервале и Экспоненциальном интервале.
`interval`	< Интервал повтора>	Строка	Для типов политик `fixed` и `exponential` — значение интервала повтора в формате ISO 8601. Для `exponential` политики можно также указать необязательный максимальный и минимальный интервалы. Дополнительные сведения см. в Фиксированном интервале и Экспоненциальном интервале. Потребление: от 5 секунд (`PT5S`) до 1 дня (`P1D`). Стандарт: для рабочих процессов с отслеживанием состояния от 5 секунд (`PT5S`) до 1 дня (`P1D`). Для рабочих процессов без отслеживания состояния — от 1 секунды`PT1S` до 1 минуты (`PT1M`).

Необязательно

Свойство	Значение	Тип	Описание
`maximumInterval`	< максимальный интервал>	Строка	Для политики `exponential` — максимальный интервал для случайно выбранного интервала в формате ISO 8601. Значение по умолчанию — 1 день (`P1D`). Дополнительные сведения см. в Экспоненциальном интервале.
`minimumInterval`	< минимальный интервал>	Строка	Для политики `exponential` — минимальный интервал для случайно выбранного интервала в формате ISO 8601. Значение по умолчанию — 5 секунд (`PT5S`). Дополнительные сведения см. в Экспоненциальном интервале.

Политика повтора по умолчанию

Операции соединителя, поддерживающие политики повтора, используют политику По умолчанию, если только вы не выберете другую политику повтора. Для большинства операций политика повтора По умолчанию — это политика экспоненциального интервала, которая осуществляет до четырех повторных попыток с экспоненциально растущими интервалами. Интервалы увеличиваются с шагом в 7,5 секунд, но имеют границу от 5 до 45 секунд. Некоторые операции используют другую политику повтора По умолчанию, например политику фиксированного интервала.

В определении рабочего процесса определение триггера или действия явно не определяет политику по умолчанию, но в следующем примере показано, как работает политика повтора по умолчанию для действия HTTP:

"HTTP": {
   "type": "Http",
   "inputs": {
      "method": "GET",
      "uri": "http://myAPIendpoint/api/action",
      "retryPolicy" : {
         "type": "exponential",
         "interval": "PT7S",
         "count": 4,
         "minimumInterval": "PT5S",
         "maximumInterval": "PT1H"
      }
   },
   "runAfter": {}
}

Нет — политика повтора отсутствует

Чтобы указать, что действие или триггер не повторяет неудачные запросы, присвойте параметру <retry-policy-type> значение none.

Политика повтора с фиксированным интервалом

Чтобы указать, что действие или триггер ожидает указанный период перед отправкой следующего запроса, присвойте параметру <retry-policy-type> значение fixed.

Пример

Эта политика повтора пытается два раза получить последние новости после первого сбоя запроса с 30-секундной задержкой между попытками.

"Get_latest_news": {
   "type": "Http",
   "inputs": {
      "method": "GET",
      "uri": "https://mynews.example.com/latest",
      "retryPolicy": {
         "type": "fixed",
         "interval": "PT30S",
         "count": 2
      }
   }
}

Политика повтора с экспоненциальным интервалом

Политика повтора с экспоненциальным интервалом указывает, что триггер или действие ожидает случайный интервал перед отправкой следующего запроса. Случайный интервал выбирается из экспоненциально растущего диапазона. При необходимости можно переопределить минимальные и максимальные интервалы по умолчанию, указав собственные минимальные и максимальные интервалы в зависимости от того, используете ли вы рабочий процесс приложения логики "Потребление" или "Стандартный".

Имя.	Ограничение потребления	Стандартное ограничение	Примечания.
Максимальная задержка	По умолчанию: 1 день.	По умолчанию: 1 час	Чтобы изменить ограничение по умолчанию в рабочем процессе приложения логики потребления, используйте параметр политики повтора. Чтобы изменить ограничение по умолчанию в рабочем процессе приложения логики уровня Standard, см. статью Изменение параметров узла и приложения для приложений логики в одноклиентской службе Azure Logic Apps.
Минимальная задержка	По умолчанию: 5 с	По умолчанию: 5 с	Чтобы изменить ограничение по умолчанию в рабочем процессе приложения логики потребления, используйте параметр политики повтора. Чтобы изменить ограничение по умолчанию в рабочем процессе приложения логики уровня Standard, см. статью Изменение параметров узла и приложения для приложений логики в одноклиентской службе Azure Logic Apps.

Имя.

Ограничение потребления

Стандартное ограничение

Примечания.

Максимальная задержка

По умолчанию: 1 день.

По умолчанию: 1 час

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

Чтобы изменить ограничение по умолчанию в рабочем процессе приложения логики уровня Standard, см. статью Изменение параметров узла и приложения для приложений логики в одноклиентской службе Azure Logic Apps.

Минимальная задержка

По умолчанию: 5 с

Диапазон случайных переменных

Для политики повтора с экспоненциальным интервалом в следующей таблице показан общий алгоритм, который Azure Logic Apps использует для создания единой случайной переменной в указанном диапазоне для каждого повтора. Указанный диапазон может доходить до числа повторных попыток включительно.

Число повторных попыток	Минимальный интервал	Максимальный интервал
1	max(0, <минимальный интервал>)	min(интервал, <максимальный интервал>)
2	max(интервал, <минимальный интервал>)	min(2 * интервал, <максимальный интервал>)
3	max(2 * интервал, <минимальный интервал>)	min(4 * интервал, <максимальный интервал>)
4	max(4 * интервал, <минимальный интервал>)	min(8 * интервал, <максимальный интервал>)
....	....	....

Управление поведением "выполнить после"

При добавлении действий в конструктор рабочих процессов вы неявно объявляете последовательность для выполнения этих действий. После завершения выполнения действия оно помечается состоянием, например Успешно, Сбой, Пропущено, или Истекло время ожидания. Другими словами, действие предшественника должно завершиться с одним из разрешенных состояний прежде, чем начнется действие преемника.

По умолчанию действие, добавляемое в конструктор, выполняется только в том случае, если предыдущее действие завершается с состоянием "Успешно". Этот запуск после поведения точно указывает порядок выполнения для действий в рабочем процессе.

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

В базовом определении JSON действия параметр run after совпадает со свойством runAfter . Это свойство указывает одну или несколько операций предшественника, которые сначала должны завершиться определенными разрешенными статусами, прежде чем операция преемника может начаться. Свойство runAfter — это объект JSON, который обеспечивает гибкость, позволяя указать все действия предшественника, которые должны завершиться до выполнения действия преемника. Этот объект также определяет массив допустимых состояний.

Например, чтобы действие выполнялось после успешного выполнения действия A, а также после успешного выполнения действия B или сбоя при работе с определением JSON действия настройте следующее runAfter свойство:

{
   // Other parts in action definition
   "runAfter": {
      "Action A": ["Succeeded"],
      "Action B": ["Succeeded", "Failed"]
    }
}

Поведение "Выполнить после" для обработки ошибок

Когда действие вызывает необработанную ошибку или исключение, оно помечается как Сбой, а все последующие действия помечаются как Пропущено. Если такое поведение наблюдается для действия, у которого есть параллельные ветви, механизм Azure Logic Apps переходит к другим ветвям, чтобы определить их статусы завершения. Например, если ветвь оканчивается действием Пропущено, а состояние завершения этой ветви определяется состоянием предшественника пропущенного действия. После завершения выполнения рабочего процесса механизм определяет общий статус выполнения, оценивая статусы всех ветвей. Если какая-либо из веток заканчивается неудачей, весь запуск рабочего процесса помечается как Неудачно.

Чтобы действие по-прежнему могло выполняться независимо от статуса предыдущего действия, можно изменить параметр действия «Выполнить после» так, чтобы оно учитывало неуспешные статусы предыдущего действия. Таким образом, действие выполняется, когда состояние предшественника — Успешно, Сбой, Пропущено, Истекло время ожидания или все эти состояния.

Например, чтобы запустить действие Office 365 Outlook Отправить сообщение электронной почты после того, как предшествующее действие Excel Online Добавить строку в таблице будет помечено как Сбой, а не Успешно, измените поведение "выполнить после" с помощью конструктора или редактора представления кода.

Изменить поведение «выполнять после» в конструкторе

Откройте ресурс приложения логики на портале Azure.
На боковой панели ресурсов выполните следующие действия, чтобы открыть конструктор рабочих процессов на основе приложения логики:
- Потребление: в разделе "Средства разработки" выберите конструктор, чтобы открыть рабочий процесс.
- Стандарт
  1. На боковой панели ресурса в разделе "Рабочие процессы" выберите "Рабочие процессы".
  2. На странице "Рабочие процессы" выберите рабочий процесс.
  3. В разделе "Сервис" выберите конструктор, чтобы открыть рабочий процесс.
В триггере или действии, где вы хотите изменить поведение 'после выполнения', следуйте этим шагам, чтобы открыть параметры операции:
1. В конструкторе выберите операцию.
2. В области сведений об операции выберите "Параметры".
  
  В разделе "Запуск после" содержится список Выбрать действия, в котором показаны доступные операции предшественника для текущей выбранной операции, например:
3. В списке Выберите действия разверните текущую операцию предшественника, которая в этом примере является HTTP.
  
  По умолчанию для статуса "Запуск после" установлено значение "Успешно выполнено". Это значение означает, что операция предшественника должна успешно завершиться до выполнения текущего действия.
Чтобы изменить параметр «запуск после» для нужных вам статусов, выберите эти статусы.

В следующем примере выбирается Завершилось с ошибкой.
Чтобы указать, что текущая операция выполняется только в том случае, если действие предшественника завершается сбоем, пропущено или истекло время ожидания, выберите эти состояния, а затем очистите состояние по умолчанию, например:

Примечание.

Прежде чем очистить состояние по умолчанию, сначала выберите другое состояние. Необходимо всегда выбрать хотя бы один статус.
Чтобы необходимо было выполнение и завершение нескольких предшествующих операций, каждая из которых имеет собственные состояния последовательности, следуйте этим шагам:
1. Откройте список Select actions и выберите предшествующие операции, которые вы хотите.
2. Выберите состояния "Выполнить после" для каждой операции.
По завершении закройте область сведений об операции.

Изменение поведения "выполнить после" в редакторе представления кода

На боковой панели ресурса выполните следующие действия, чтобы открыть редактор представления кода на основе приложения логики:
- Потребление: в разделе "Средства разработки" выберите представление кода, чтобы открыть рабочий процесс в редакторе JSON.
- Стандарт
  1. В разделе "Рабочие процессы" выберите "Рабочие процессы".
  2. На странице "Рабочие процессы" выберите рабочий процесс.
  3. В разделе "Сервис" выберите представление кода, чтобы открыть рабочий процесс в редакторе JSON.

В определении JSON действия измените свойство runAfter, которое имеет следующий синтаксис:

"<action-name>": {
   "inputs": {
      "<action-specific-inputs>"
   },
   "runAfter": {
      "<preceding-action>": [
         "Succeeded"
      ]
   },
   "type": "<action-type>"
}

В этом примере измените свойство runAfter с Succeeded на Failed:

"Send_an_email_(V2)": {
   "inputs": {
      "body": {
         "Body": "<p>Failed to add row to table: @{body('Add_a_row_into_a_table')?['Terms']}</p>",
         "Subject": "Add row to table failed: @{body('Add_a_row_into_a_table')?['Terms']}",
         "To": "Sophia.Owen@fabrikam.com"
      },
      "host": {
         "connection": {
            "name": "@parameters('$connections')['office365']['connectionId']"
         }
      },
      "method": "post",
      "path": "/v2/Mail"
   },
   "runAfter": {
      "Add_a_row_into_a_table": [
         "Failed"
      ]
   },
   "type": "ApiConnection"
}

Чтобы указать, что действие выполняется при условии, что действие-предшественник помечено как Failed, Skipped или TimedOut, добавьте другие состояния:
```
"runAfter": {
   "Add_a_row_into_a_table": [
      "Failed", "Skipped", "TimedOut"
   ]
},
```

Оценка действий с областями действия и их результатов

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

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

По умолчанию, когда все действия области будут выполнены, для состояния области устанавливается значение Succeeded (Успешно). Если состояние последнего действия в области — Сбой или Прервано, для состояния области устанавливается значение Сбой.

Для перехвата исключений в области с состоянием Сбой и выполнения действий, которые обрабатывают эти ошибки, можно использовать параметр "выполнить после" для области с состоянием Сбой. Таким образом, если какие-либо действия в этой области завершаются сбоем и для этой области используется параметр "выполнить после", можно создать одно действие для перехвата сбоев.

Сведения об ограничениях для областей см. в статье Ограничения и конфигурация.

Настройте область с параметром "run after" для обработки исключений

На портале Azure откройте ресурс и рабочий процесс приложения логики в конструкторе.

Рабочий процесс должен иметь триггер, который запускает рабочий процесс.
В конструкторе выполните следующие универсальные действия, чтобы добавить действие Control с именем Scope в рабочий процесс.
В действии Scopeвыполните следующие общие действия, чтобы добавить действия для выполнения, например:

В следующем списке показано несколько примеров действий, которые можно включить в действие «Область»:
- Получение данных из API.
- Обработка данных.
- Сохраните данные в базе данных.
Теперь определите правила запуска после выполнения действий в области.
1. В конструкторе выберите название области . Когда откроется панель сведений об области, выберите Параметры.
2. Если в рабочем процессе есть несколько предыдущих действий, в списке "Выбор действий " выберите действие, после которого необходимо выполнить действия с областью действия.
3. Для выбранного действия выберите все статусы действия, при которых могут выполняться действия в заданной области.
  
  Другими словами, любой из выбранных статусов, полученный в результате выбранного действия, приводит к выполнению действий в этой области.
  
  В следующем примере действия с областью действия выполняются после завершения действия HTTP с любым из выбранных состояний:

Получите контекст и результаты для сбоев

Хотя перехват сбоев из области видимости полезен, вам может понадобиться дополнительный контекст, чтобы выяснить, какие именно действия завершились сбоем, а также какие ошибки или коды состояния были возвращены. result()Функция возвращает результаты из действий верхнего уровня в действии с заданной областью действия. Эта функция принимает имя области в качестве одного параметра и возвращает массив с результатами этих действий верхнего уровня. Объекты действия имеют те же атрибуты, что возвращает функция actions(), например время начала и окончания действия, его состояние, входные и выходные данные, а также идентификаторы корреляции.

Примечание.

Функция result() возвращает результаты только для действий верхнего уровня, а не для более глубоко вложенных действий, таких как действия switch или condition.

Чтобы получить сведения о действиях, которые завершились ошибкой в области действия, можно использовать выражение @result() с именем этой области действия и параметром "run after". Чтобы отфильтровать возвращенный массив по действиям, имеющим состояние Сбой, можно добавить действие Фильтровать массив. Чтобы выполнить действие для возвращенного действия, завершившегося сбоем, возьмите полученный отфильтрованный массив и используйте цикл For each.

Следующий пример JSON отправляет HTTP-запрос POST с телом ответа для любых действий, завершившихся с ошибкой, в рамках действия области с именем My_Scope. За примером следует подробное объяснение.

"Filter_array": {
   "type": "Query",
   "inputs": {
      "from": "@result('My_Scope')",
      "where": "@equals(item()['status'], 'Failed')"
   },
   "runAfter": {
      "My_Scope": [
         "Failed"
      ]
    }
},
"For_each": {
   "type": "foreach",
   "actions": {
      "Log_exception": {
         "type": "Http",
         "inputs": {
            "method": "POST",
            "body": "@item()['outputs']['body']",
            "headers": {
               "x-failed-action-name": "@item()['name']",
               "x-failed-tracking-id": "@item()['clientTrackingId']"
            },
            "uri": "http://requestb.in/"
         },
         "runAfter": {}
      }
   },
   "foreach": "@body('Filter_array')",
   "runAfter": {
      "Filter_array": [
         "Succeeded"
      ]
   }
}

Ниже описано, что происходит в этом примере:

Для получения результатов из всех действий в области My_Scope, действие Filter_array использует выражение фильтра: @result('My_Scope')
Условием для Фильтр массива является любой элемент @result(), у которого состояние равно Failed. Это условие фильтрует массив, который имеет все результаты действия от My_Scope до массива только с неудачными результатами.
Выполните действия цикла For_each на выходных данных фильтрованного массива. Этот шаг выполняет действие для каждого неудавшегося результата действия, который был ранее отфильтрован.

Если определенное действие в области завершилось сбоем, действия в цикле For_each выполняются лишь один раз. Несколько сбоев приводят к одному действию на каждый сбой.
Отправьте HTTP POST-запрос к телу ответа элемента For_each, которое является выражением @item()['outputs']['body'].

Формат элемента @result() совпадает с форматом @actions() и может быть проанализирован одинаково.
Включите два пользовательских заголовка с именем сбойного действия (@item()['name']) и идентификатором отслеживания клиента для сбойного запуска (@item()['clientTrackingId']).

Ниже приведен пример (для справочных целей) отдельного элемента @result() с отображением свойств name, body и clientTrackingId, проанализированных в примере выше. Вне действия For_each, @result() возвращает массив этих объектов.

{
   "name": "Example_Action_That_Failed",
   "inputs": {
      "uri": "https://myfailedaction.azurewebsites.net",
      "method": "POST"
   },
   "outputs": {
      "statusCode": 404,
      "headers": {
         "Date": "Thu, 11 Aug 2016 03:18:18 GMT",
         "Server": "Microsoft-IIS/8.0",
         "X-Powered-By": "ASP.NET",
         "Content-Length": "68",
         "Content-Type": "application/json"
      },
      "body": {
         "code": "ResourceNotFound",
         "message": "/docs/folder-name/resource-name does not exist"
      }
   },
   "startTime": "2016-08-11T03:18:19.7755341Z",
   "endTime": "2016-08-11T03:18:20.2598835Z",
   "trackingId": "bdd82e28-ba2c-4160-a700-e3a8f1a38e22",
   "clientTrackingId": "08587307213861835591296330354",
   "code": "NotFound",
   "status": "Failed"
}

Выражения, описанные в этой статье, можно использовать для выполнения различных шаблонов обработки исключений. Вы можете выбрать выполнение одного действия обработки исключений вне области действия, которое принимает весь отфильтрованный массив сбоев, и удалить действие For_each. Кроме того, можно включить другие полезные свойства из ответа \@result(), как описано выше.

настройка журналов Azure Monitor;

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

Например, Azure Monitor предоставляет упрощенный способ отправки всех событий рабочего процесса, включая все состояния выполнения и действия, в место назначения. Вы можете настроить оповещения для определенных метрик и пороговых значений в Azure Monitor. Вы также можете отправлять события рабочего процесса в рабочую область Log Analytics или учетную запись хранения Azure. Вы также можете передавать все события через Центры событий Azure в Azure Stream Analytics. В Stream Analytics можно писать запросы в реальном времени на основе любых аномалий, средних значений или сбоев из журналов диагностики. Stream Analytics можно использовать для отправки информации в другие источники данных, такие как очереди, разделы, SQL, Azure Cosmos DB или Power BI.

Дополнительные сведения см. в статье Настройка журналов Azure Monitor и сбор диагностических данных для Azure Logic Apps.

Примеры и сценарии Azure Logic Apps

Обратная связь

Были ли сведения на этой странице полезными?

Last updated on 2026-07-10