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

Статья
12/09/2023

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

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

политики повтора;

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

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

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

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

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

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

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

Откройте рабочий процесс приложения логики в конструкторе на портале Azure.
В зависимости от того, работаете ли вы над рабочим процессом "Потребление" или "Стандартный", откройте Параметры соответственно триггера или действия.
- Потребление: в фигуре действия откройте меню с многоточием (...) и выберите Параметры.
- Стандартный: в конструкторе выберите действие. В области сведений выберите Параметры.
Если действие или триггер поддерживает политику повтора, в разделе Политика повтора выберите нужный тип политики.

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

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

В определении триггера или действия добавьте 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`	<retry-policy-type>	Строка	Необходимый тип политики повтора: `default`, `none`, `fixed` или `exponential`
`count`	<retry-attempts>	Целое	Для типов политик `fixed` и `exponential` — число повторов, равное значению от 1 до 90. Дополнительные сведения см. в Фиксированном интервале и Экспоненциальном интервале.
`interval`	<retry-interval>	Строка	Для типов политик `fixed` и `exponential` — значение интервала повтора в формате ISO 8601. Для `exponential` политики можно также указать необязательный максимальный и минимальный интервалы. Дополнительные сведения см. в Фиксированном интервале и Экспоненциальном интервале. Потребление: от 5 секунд (`PT5S`) до 1 дня (`P1D`). Стандарт: для рабочих процессов с отслеживанием состояния от 5 секунд (`PT5S`) до 1 дня (`P1D`). Для рабочих процессов без отслеживания состояния — от 1 секунды`PT1S` до 1 минуты (`PT1M`).

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

Свойство	Значение	Тип	Описание
`maximumInterval`	<maximum-interval>	Строка	Для политики `exponential` — максимальный интервал для случайно выбранного интервала в формате ISO 8601. Значение по умолчанию — 1 день (`P1D`). Дополнительные сведения см. в Экспоненциальном интервале.
`minimumInterval`	<minimum-interval>	Строка	Для политики `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 час	Чтобы изменить ограничение по умолчанию в рабочем процессе приложения логики потребления, используйте параметр политики повтора. Сведения о том, как изменить Рабочий процесс приложения логики см. в статье Изменение параметров узла и приложения для приложений логики в одноклиентской службе Azure Logic Apps.
Минимальная задержка	По умолчанию: 5 с	По умолчанию: 5 с	Чтобы изменить ограничение по умолчанию в рабочем процессе приложения логики потребления, используйте параметр политики повтора. Сведения о том, как изменить Рабочий процесс приложения логики см. в статье Изменение параметров узла и приложения для приложений логики в одноклиентской службе Azure Logic Apps.

Имя.

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

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

Примечания.

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

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

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

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

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

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

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

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

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

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

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

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

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

Концептуальная схема с примерами, которые демонстрируют оценку состояний выполнения.

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

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

Примечание.

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

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

Стандартные
Потребление

Откройте рабочий процесс приложения логики в конструкторе на портале Azure.
В конструкторе выберите фигуру действия. В области сведений выберите Выполнить после.

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

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

В следующем примере выбрано состояние завершение сбоем.
Чтобы указать, что текущее действие выполняется при условии, что действие-предшественник помечено как Сбой, Пропущено, или Истекло время ожидания, выберите другие состояния.
Чтобы требовать выполнения нескольких действий-предшественников, каждый из которых имеет собственные состояния "выполнить после", разверните список Выбора действий. Выберите нужные действия предшественника и укажите необходимые состояния "выполнить после".
Когда будете готовы, нажмите кнопку Готово.

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

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

В представлении кода в определении 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 (Успешно). Если состояние последнего действия в области — Сбой или Прервано, для состояния области устанавливается значение Сбой.

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

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

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

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

Примечание.

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

Чтобы получить контекст о действиях, которые завершились сбоем в области, можно использовать выражение @result() с именем области и параметром "выполнить после". Чтобы отфильтровать возвращенный массив по действиям, имеющим состояние Сбой, можно добавить действие Фильтровать массив. Чтобы выполнить действие для возвращенного действия, завершившегося сбоем, возьмите возвращенный отфильтрованный массив и используйте цикл 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.

Следующие шаги

Примеры использования Logic Apps и распространенные сценарии

Поделиться через