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

Применяется к: Azure Logic Apps (Расход + Стандарт)

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

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

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

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

Предпосылки

• Учетная запись и подписка Azure. Если у вас еще нет подписки Azure, зарегистрируйтесь для получения бесплатной учетной записи Azure.

• URL-адрес конечной точки назначения, которую требуется вызвать.

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

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

  Если у вас нет ресурса приложения логики и рабочего процесса, создайте их сейчас, выполнив действия для приложения логики, которое вы хотите:

  • Создание примера рабочего процесса приложения логики потребления
  • Создание примера рабочего процесса стандартного приложения логики

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

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

• Параметры триггера HTTP
• Параметры действия HTTP

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

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

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

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

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

Триггер HTTP или действие выводит следующие сведения:

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

Сведения о шифровании, безопасности и авторизации исходящих вызовов из рабочего процесса, таких как TLS, самозаверяющий сертификат или открытый идентификатор Microsoft Entra ID, см. в статье Access для исходящих вызовов к другим службам и системам.

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

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

• Сертификат TLS: добавьте параметр WEBSITE_LOAD_ROOT_CERTIFICATESприложения и задайте значение отпечатка сертификата TLS.

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

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

1. В параметрах приложения логики добавьте или обновите параметр приложения, называемый WEBSITE_LOAD_ROOT_CERTIFICATES. Дополнительные сведения см. в разделе "Управление параметрами приложения" — local.settings.json.

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

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

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

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

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

   {
      "IsEncrypted": false,
      "Values": {
         <...>
         "AzureWebJobsStorage": "UseDevelopmentStorage=true",
         "WEBSITE_LOAD_ROOT_CERTIFICATES": "<thumbprint-for-TLS-certificate>",
         <...>
      }
   }
   

Дополнительные сведения см. в разделе "Управление параметрами приложения " local.settings.json".

Клиентский сертификат или Microsoft Entra ID OAuth с аутентификацией типа учетных данных сертификата

1. В параметрах приложения логики добавьте или обновите параметр приложения, называемый WEBSITE_LOAD_USER_PROFILE. Инструкции по управлению параметрами приложения см. в разделе "Управление параметрами приложения " local.settings.json

2. Для значения параметра укажите 1.

   "WEBSITE_LOAD_USER_PROFILE": "1"

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

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

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

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

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

Содержимое с несколькими частями или типом данных формы

Чтобы обрабатывать содержимое типа 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

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

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

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

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

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

• Базовое определение JSON действия HTTP неявно следует шаблону асинхронной операции.

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

  Чтобы найти параметр асинхронного шаблона , выполните следующие действия.

  1. В конструкторе рабочих процессов выберите действие HTTP .
  2. В открывшейся информационной панели выберите Параметры.
  3. В разделе "Сеть" найдите параметр асинхронного шаблона .

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

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

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

Отключите асинхронную настройку шаблона.

1. В конструкторе рабочих процессов выберите действие HTTP и на открываемой области сведений выберите "Параметры".

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

Отключение асинхронной модели в определении 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, использующим эти заголовки, однако игнорирует их.

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

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

Связанный контент

• Управляемые соединители для Azure Logic Apps
• Встроенные коннекторы для Azure Logic Apps