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

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

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

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

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

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

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

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

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

Политика повтора	Описание
По умолч.	Для большинства операций политика повтора По умолчанию — это политика с экспоненциальным интервалом, которая осуществляет до четырех повторных попыток с экспоненциально растущими интервалами. Интервалы увеличиваются с шагом в 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 час	Чтобы изменить ограничение по умолчанию в рабочем процессе приложения логики потребления, используйте параметр политики повтора. Сведения о том, как изменить Рабочий процесс приложения логики см. в статье Изменение параметров узла и приложения для приложений логики в одноклиентской службе Azure Logic Apps.
Минимальная задержка	По умолчанию: 5 с	По умолчанию: 5 с	Чтобы изменить ограничение по умолчанию в рабочем процессе приложения логики потребления, используйте параметр политики повтора. Сведения о том, как изменить Рабочий процесс приложения логики см. в статье Изменение параметров узла и приложения для приложений логики в одноклиентской службе Azure Logic Apps.

Имя.

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

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

Примечания.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Несмотря на то, что перехват сбоев в области очень эффективен, вам также может понадобиться контекст, чтобы понять, какие действия завершились сбоем, и узнать возвращенные ошибки и коды состояния. 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.

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

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

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

Last updated on 2025-07-08