Вызов внешних конечных точек HTTP или HTTPS из рабочих процессов в Azure Logic Apps

Статья
04/08/2024

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

В некоторых сценариях может потребоваться создать рабочий процесс приложения логики, который отправляет исходящие запросы конечным точкам в других службах или системах по протоколу HTTP или HTTPS. Например, предположим, что вы хотите отслеживать конечную точку службы для веб-сайта, проверка эту конечную точку в определенном расписании. Когда определенное событие происходит в этой конечной точке, например на веб-сайте, это событие активирует рабочий процесс и запускает действия в этом рабочем процессе.

Примечание.

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

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

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

Необходимые компоненты

Учетная запись и подписка Azure. Если у вас еще нет подписки Azure, зарегистрируйтесь для получения бесплатной учетной записи Azure.
URL-адрес конечной точки назначения, которую требуется вызвать
Рабочий процесс приложения логики, из которого требуется вызвать конечную точку назначения. Чтобы начать с триггера HTTP, вам потребуется пустой рабочий процесс. Чтобы использовать действие HTTP, запустите рабочий процесс с любым нужным триггером. В этом примере на первом шаге используется триггер HTTP.

технический справочник по Подключение or

Технические сведения о параметрах триггера и действия см. в следующих разделах:

Добавление триггера HTTP

Этот встроенный триггер выполняет HTTP-вызов по указанному URL-адресу для конечной точки и возвращает ответ.

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

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

В этом примере триггер переименовывается в триггер HTTP — URL-адрес конечной точки вызова, чтобы триггер получил более описательное имя. Кроме того, в примере позже добавляется действие HTTP, а имена операций в рабочем процессе должны быть уникальными.
Укажите значения параметров триггера HTTP, которые необходимо включить в вызов конечной точки назначения. Настройте повторение для того, как часто триггер проверка конечной точке назначения.

Если выбран тип проверки подлинности, отличный от Нет, параметры проверки подлинности будут отличаться в зависимости от выбора. Дополнительные сведения о типах проверки подлинности, доступных для HTTP, см. в следующих разделах:
- Добавление проверки подлинности в исходящие вызовы
- Аутентификация для доступа к ресурсам на основе управляемых удостоверений
Чтобы добавить другие доступные параметры, откройте список дополнительных параметров и выберите нужные параметры.
Добавьте любые другие действия, которые необходимо выполнить при срабатывании триггера.
Закончив работу, сохраните свой рабочий процесс. На панели инструментов конструктора выберите Сохранить.

Добавление действия HTTP

Это встроенное действие выполняет HTTP-вызов по указанному URL-адресу для конечной точки и возвращает ответ.

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

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

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

В этом примере действие переименовывается в действие HTTP — URL-адрес конечной точки вызова, чтобы шаг получил более описательное имя. Кроме того, имена операций в рабочем процессе должны быть уникальными.
Укажите значения параметров действия HTTP, которые необходимо включить в вызов конечной точки назначения.

Если выбран тип проверки подлинности, отличный от Нет, параметры проверки подлинности будут отличаться в зависимости от выбора. Для получения дополнительной информации о типах аутентификации, доступных для HTTP, ознакомьтесь со следующими статьями:
- Добавление проверки подлинности в исходящие вызовы
- Аутентификация для доступа к ресурсам на основе управляемых удостоверений
Чтобы добавить другие доступные параметры, откройте список дополнительных параметров и выберите нужные параметры.
Закончив работу, сохраните свой рабочий процесс. На панели инструментов конструктора выберите Сохранить.

Выходные данные триггеров и действий

Дополнительные сведения о выходных данных триггера ИЛИ действия HTTP, которые возвращают следующие сведения:

Свойство	Type	Описание
`headers`	Объект JSON	Заголовки из запроса
`body`	Объект JSON	Объект с содержимым текста из запроса
`status code`	Целое	Код состояния из запроса

Код состояния	Description
200	OK
202	Accepted
400	Недопустимый запрос
401	Не авторизовано
403	Запрещено
404	Не найдено
500	Внутренняя ошибка сервера. Произошла неизвестная ошибка.

Безопасность URL-адресов для исходящих вызовов

Сведения о шифровании, безопасности и авторизации исходящих вызовов из рабочего процесса, таких как TLS, ранее известный как Secure Sockets Layer (SSL), самозаверяющий сертификат или проверка подлинности Microsoft Entra ID Open Authentication (Microsoft Entra ID OAuth), см. в статье "Безопасный доступ и данные - Доступ для исходящих вызовов к другим службам и системам".

Проверка подлинности для однотенантной среды

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

TLS/SSL-сертификат: добавьте параметр WEBSITE_LOAD_ROOT_CERTIFICATESприложения и задайте значение отпечатка сертификата TLS/SSL.
Сертификат клиента или открытый идентификатор Microsoft Entra ID (Microsoft Entra ID OAuth) с типом учетных данных "Сертификат": добавьте параметр WEBSITE_LOAD_USER_PROFILEприложения и задайте значение 1.

Проверка подлинности SSL-сертификата TLS/SSL

В параметрах ресурса приложения логики добавьте или измените параметр приложения WEBSITE_LOAD_ROOT_CERTIFICATES.
В качестве значения параметра укажите отпечаток сертификата TLS/SSL в качестве корневого сертификата, который должен быть доверенным.

"WEBSITE_LOAD_ROOT_CERTIFICATES": "<thumbprint-for-TLS/SSL-certificate>"

Например, при работе в Visual Studio Code выполните следующие действия.

Откройте файл local.settings.json проекта приложения логики.
В Valuesобъекте JSON добавьте или измените параметр WEBSITE_LOAD_ROOT_CERTIFICATES:
```
{
   "IsEncrypted": false,
   "Values": {
      <...>
      "AzureWebJobsStorage": "UseDevelopmentStorage=true",
      "WEBSITE_LOAD_ROOT_CERTIFICATES": "<thumbprint-for-TLS/SSL-certificate>",
      <...>
   }
}
```
Примечание.

Чтобы найти отпечаток, выполните следующие действия.
1. В меню ресурсов приложения логики в разделе Параметры выберите параметры>TLS/SSL, сертификаты закрытого ключа (PFX) или сертификаты открытого ключа (.cer).
2. Найдите сертификат, который вы хотите использовать, и скопируйте отпечаток.
Дополнительные сведения см. в статье "Поиск отпечатка " приложение Azure служба".

Дополнительные сведения см. в следующей документации:

Сертификат клиента или идентификатор Microsoft Entra ID OAuth с проверкой подлинности типа учетных данных "Certificate"

В параметрах ресурса приложения логики добавьте или измените параметр приложения WEBSITE_LOAD_USER_PROFILE.
Укажите 1 в качестве значения параметра.

"WEBSITE_LOAD_USER_PROFILE": "1"

Например, при работе в Visual Studio Code выполните следующие действия.

Откройте файл local.settings.json проекта приложения логики.

В Valuesобъекте JSON добавьте или измените параметр WEBSITE_LOAD_USER_PROFILE:

{
   "IsEncrypted": false,
   "Values": {
      <...>
      "AzureWebJobsStorage": "UseDevelopmentStorage=true",
      "WEBSITE_LOAD_USER_PROFILE": "1",
      <...>
   }
}

Дополнительные сведения см. в следующей документации:

Содержимое с типом multipart/form-data

Для обработки содержимого, которое имеет тип multipart/form-data в HTTP-запросах, можно добавить объект JSON, включающий атрибуты $content-type и $multipart, в текст HTTP-запроса, используя этот формат.

"body": {
   "$content-type": "multipart/form-data",
   "$multipart": [
      {
         "body": "<output-from-trigger-or-previous-action>",
         "headers": {
            "Content-Disposition": "form-data; name=file; filename=<file-name>"
         }
      }
   ]
}

Например, предположим, что у вас есть рабочий процесс, который отправляет HTTP-запрос POST для файла Excel на веб-сайт с помощью API этого сайта, который поддерживает multipart/form-data тип. В следующем примере показано, как может появиться это действие:

Стандартный рабочий процесс

Рабочий процесс потребления

Ниже приведен тот же пример, который показывает определение JSON действия HTTP в базовом определении рабочего процесса:

"HTTP_action": {
   "inputs": {
      "body": {
         "$content-type": "multipart/form-data",
         "$multipart": [
            {
               "body": "@trigger()",
               "headers": {
                  "Content-Disposition": "form-data; name=file; filename=myExcelFile.xlsx"
               }
            }
         ]
      },
      "method": "POST",
      "uri": "https://finance.contoso.com"
   },
   "runAfter": {},
   "type": "Http"
}

Содержимое с типом application/x-www-form-urlencoded

Чтобы предоставить данные form-urlencoded в тексте для HTTP-запроса, необходимо указать, что данные имеют тип содержимого application/x-www-form-urlencoded. В триггере или действии HTTP добавьте заголовок content-type. Задайте для заголовка значение application/x-www-form-urlencoded.

Например, предположим, что у вас есть приложение логики, которое отправляет запрос HTTP POST на веб-сайт, поддерживающий тип application/x-www-form-urlencoded. Вот как может выглядеть это действие:

Стандартный рабочий процесс

Рабочий процесс потребления

Асинхронное поведение запрос-ответа

Для рабочих процессов с отслеживанием состояния в мультитенантных и однотенантных Azure Logic Apps все действия на основе HTTP соответствуют стандартному шаблону асинхронной операции в качестве поведения по умолчанию. Эта модель указывает, что после того, как действие HTTP вызовет или отправит запрос в конечную точку, службу, систему или API, получатель немедленно возвращает ответ 202 ACCEPTED. Этот код подтверждает, что получатель принял запрос, но еще не завершил обработку. Ответ может включать заголовок location, указывающий URI и идентификатор обновления, который вызывающая сторона может использовать для опроса или проверки состояния асинхронного запроса до тех пор, пока получатель не прекратит обработку и не вернет сообщение об успешном завершении "200 OK" или другой ответ, отличный от 202. Однако вызывающей стороне не нужно ждать завершения обработки запроса, и можно продолжить выполнение следующего действия. Дополнительные сведения см. в разделе Асинхронная интеграция микрослужб обеспечивает автономность микрослужб.

Для рабочих процессов без отслеживания состояния в однотенантных Azure Logic Apps действия на основе HTTP не используют шаблон асинхронной операции. Вместо этого они выполняются синхронно, возвращают ответ "202 ACCEPTED " as-is и переходят к следующему шагу в выполнении рабочего процесса. Если ответ содержит заголовок location, рабочий процесс без отслеживания состояния не опрашивает указанный URI для проверки состояния. Чтобы следовать стандартному шаблону асинхронной операции, используйте вместо этого рабочий процесс с отслеживанием состояния.

Базовое определение JavaScript Object Notation (JSON) для действия HTTP неявно соответствует модели асинхронных операций.
Действие HTTP, но не триггер, имеет параметр асинхронного шаблона , который включен по умолчанию. Этот параметр указывает, что вызывающая сторона не ждет завершения обработки и может перейти к следующему действию, но продолжит проверку состояния, пока обработка не будет остановлена. При отключенном параметре вызывающая сторона будет ожидать завершения обработки перед переходом к следующему действию.

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

Стандартный рабочий процесс*
1. В конструкторе рабочих процессов выберите действие HTTP. В открывающейся области сведений выберите Параметры.
2. В разделе "Сеть" найдите параметр асинхронного шаблона .
Рабочий процесс потребления
1. В конструкторе рабочих процессов в строке заголовка действия HTTP нажмите кнопку с многоточием (...), которая открывает параметры действия.
2. Найдите параметр Асинхронная модель.

Отключение асинхронных операций

Иногда может потребоваться отключить асинхронное поведение действия HTTP в определенных сценариях, например при необходимости:

Избежать истечения времени ожидания HTTP для долго выполняющихся задач
Отключить проверку заголовков расположения

В конструкторе рабочих процессов выберите действие HTTP и на открываемой области сведений выберите Параметры.
В разделе "Сеть" найдите параметр асинхронного шаблона . Если этот параметр включен.

Отключение асинхронной модели в определении JSON для действия

В базовом определении JSON для действия HTTP добавьте параметр операции "DisableAsyncPattern" в определение действия, чтобы действие выполнялось по синхронной модели. Дополнительные сведения см. в разделе Выполнение действий при синхронной модели операций.

Как избежать истечения времени ожидания HTTP для долго выполняющихся задач

Время ожидания HTTP-запросов ограничено. При наличии длительного действия HTTP, время ожидания которого истекло из-за этого ограничения, доступны следующие варианты:

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

Настройка интервала между попытками повторных попыток с помощью заголовка Retry-After

Чтобы указать количество секунд между повторными попытками, можно добавить заголовок в Retry-After ответ действия HTTP. Например, если конечная точка назначения возвращает 429 - Too many requests код состояния, можно указать более длинный интервал между повторными попытками. Заголовок Retry-After также работает с 202 - Accepted кодом состояния.

Ниже приведен тот же пример, в котором показан ответ на действие HTTP, содержащий Retry-After:

{
    "statusCode": 429,
    "headers": {
        "Retry-After": "300"
    }
}

Поддержка разбивки на страницы

Иногда целевая служба отвечает, возвращая результаты на одну страницу за раз. Если ответ задает следующую страницу со свойством nextLink или @odata.nextLink , можно включить параметр разбиения на страницы в действии HTTP. Этот параметр приводит к автоматическому переходу по этим ссылкам для действия HTTP и получения следующей страницы. Однако если ответ указывает следующую страницу с любым другим тегом, может потребоваться добавить цикл в рабочий процесс. Сделайте этот цикл следующим тегом и вручную получите каждую страницу, пока тег не имеет значения NULL.

Отключение проверки заголовков расположения

Некоторые конечные точки, службы, системы или API возвращают ответ 202 ACCEPTED, у которого нет заголовка location. Чтобы действие HTTP постоянно не проверяло состояние запроса, если заголовок location не существует, можно использовать следующие параметры:

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

Известные проблемы

Пропущенные заголовки HTTP

Если триггер или действие HTTP включают эти заголовки, Azure Logic Apps удаляет эти заголовки из созданного сообщения запроса без предупреждения или ошибки:

Заголовки Accept-*, за исключением Accept-version
Allow
Заголовки Content-*, за исключением Content-Disposition, Content-Encoding и Content-Type, которые учитываются при использовании операций POST и PUT. Однако Azure Logic Apps удаляет эти заголовки при использовании операции GET.
Cookie заголовок, но Azure Logic Apps учитывает любое значение, указанное с помощью свойства Cookie .
Expires
Host
Last-Modified
Origin
Set-Cookie
Transfer-Encoding

Хотя Azure Logic Apps не остановит вас от сохранения приложений логики, использующих триггер HTTP или действие с этими заголовками, Azure Logic Apps игнорирует эти заголовки.

Содержимое ответа не соответствует ожидаемому типу контента

Действие HTTP вызывает ошибку BadRequest , если действие HTTP вызывает внутренний API с Content-Type заголовком, заданным для application/json, но ответ серверной части не содержит содержимого в формате JSON, который завершается сбоем внутренней проверки формата JSON.

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