Получение и реагирование на входящий вызов HTTPS, отправленный рабочим процессам в Azure Logic Apps

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

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

Примечание.

Действие ответа работает только при использовании триггера запроса .

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

получение HTTPS-запроса и ответ на него для данных в локальной базе данных;
Получение и реагирование на HTTPS-запрос, отправленный из другого рабочего процесса приложения логики.
Активация рабочего процесса при возникновении внешнего события веб-перехватчика.

Чтобы запустить рабочий процесс, отправив исходящий или исходящий запрос, используйте встроенный триггер HTTP или встроенное действие HTTP.

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

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

Ресурс приложения логики с рабочим процессом, в котором требуется получить входящий HTTPS-запрос.

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

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

Установите или используйте средство, которое может отправлять HTTP-запросы для тестирования решения, например:
- Visual Studio Code с расширением из Visual Studio Marketplace
- PowerShell Invoke-RestMethod
- Microsoft Edge — средство сетевой консоли
- Бруно
- локон
Внимание

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

Добавление триггера запроса

Триггер запроса создает вызываемую вручную конечную точку, которая обрабатывает только входящие запросы по протоколу HTTPS. Когда вызывающий объект отправляет запрос в эту конечную точку, триггер запроса запускается и запускает рабочий процесс. Для получения информации о том, как вызвать этот триггер, см. статью «Вызов, триггер или вложенные рабочие процессы с конечными точками HTTPS в Azure Logic Apps».

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

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

После появления поля сведений о триггере укажите следующие сведения:

Имя свойства	Имя свойства JSON	Обязательное поле	Описание
URL-адрес HTTP	{нет}	Да	URL-адрес конечной точки, созданный после сохранения рабочего процесса и используемый для отправки запроса, который активирует рабочий процесс.
Схема JSON текста запроса	`schema`	нет	Схема JSON, описывающая свойства и значения в тексте входящего запроса. Конструктор использует эту схему для создания токенов для свойств в запросе. Таким образом, рабочий процесс может анализировать, использовать и передавать выходные данные триггера запроса в рабочий процесс. Если у вас нет схемы JSON, можно создать схему из примера полезных данных с помощью примера полезных данных Use sample payload для создания возможностей схемы .

В следующем примере показан пример схемы JSON:

В следующем примере показана полная схема JSON:

{
   "type": "object",
   "properties": {
      "account": {
         "type": "object",
         "properties": {
            "name": {
               "type": "string"
            },
            "ID": {
               "type": "string"
            },
            "address": {
               "type": "object",
               "properties": {
                  "number": {
                     "type": "string"
                  },
                  "street": {
                     "type": "string"
                  },
                  "city": {
                     "type": "string"
                  },
                  "state": {
                     "type": "string"
                  },
                  "country": {
                     "type": "string"
                  },
                  "postalCode": {
                     "type": "string"
                  }
               }
            }
         }
      }
   }
}

При вводе схемы JSON конструктор может показать напоминание, чтобы включить Content-Type заголовок в запрос и задать для него значение application/json. Дополнительные сведения см. в статье Обработка типов содержимого.

В следующем примере показано, как Content-Type заголовок отображается в формате JSON:

{
   "Content-Type": "application/json"
}

Чтобы создать схему JSON, основанную на ожидаемой полезной нагрузке (данные), можно использовать инструмент, например json-schema.org, или выполнить следующие действия:

В триггере Запрос выберите Использовать пример полезных данных, чтобы создать схему.

Введите образец полезных данных и нажмите кнопку Готово.

В следующем примере показан пример полезных данных:

{
   "account": {
      "name": "Contoso",
      "ID": "12345",
      "address": {
         "number": "1234",
         "street": "Anywhere Street",
         "city": "AnyTown",
         "state": "AnyState",
         "country": "USA",
         "postalCode": "11111"
      }
   }
}

Чтобы убедиться, что текст запроса во входящем вызове соответствует указанной схеме, выполните приведенные ниже действия.
1. Чтобы входящее сообщение имело именно те поля, которые описаны в вашей схеме, добавьте свойство required в схеме и укажите необходимые поля. additionalProperties Добавьте свойство и задайте значение false.
  
  Например, на следующей схеме указано, что у входящего сообщения должно быть поле msg, а не другие поля:
```
{
   "properties": {
     "msg": {
        "type": "string"
     }
   },
   "type": "object",
   "required": ["msg"],
   "additionalProperties": false
}
```
2. В конструкторе выберите триггер "Запрос". На открывающейся панели сведений выберите вкладку "Параметры ".
3. Разверните узел "Обработка данных" и установите для проверки схемы значение On.
  
  Если текст запроса входящего вызова не соответствует схеме, триггер возвращает ошибку HTTP 400 Bad Request .
Из списка методов выберите метод, который триггер ожидает для обработки входящих запросов.
Если для триггера существуют другие параметры, откройте список дополнительных параметров и выберите нужные параметры.
Когда вы будете готовы, сохраните рабочий процесс. На панели инструментов конструктора выберите Сохранить.

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

Примечание.

Если вы хотите включить хэш-символ или фунт (#) в URI при вызове триггера запроса , используйте следующую закодированную версию: %25%23

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

После появления поля сведений о триггере укажите следующие сведения по мере необходимости:

Имя свойства	Имя свойства JSON	Обязательное поле	Описание
URL-адрес HTTP	{нет}	Да	URL-адрес конечной точки, созданный после сохранения рабочего процесса и используемый для отправки запроса, который активирует рабочий процесс.
Схема JSON текста запроса	`schema`	нет	Схема JSON, описывающая свойства и значения в тексте входящего запроса. Конструктор использует эту схему для создания токенов для свойств в запросе. Таким образом, рабочий процесс может анализировать, использовать и передавать выходные данные триггера запроса в рабочий процесс. Если у вас нет схемы JSON, можно создать схему из примера полезных данных с помощью примера полезных данных Use sample payload для создания возможностей схемы .

В следующем примере показан пример схемы JSON:

В следующем примере показана полная схема JSON:

{
   "type": "object",
   "properties": {
      "account": {
         "type": "object",
         "properties": {
            "name": {
               "type": "string"
            },
            "ID": {
               "type": "string"
            },
            "address": {
               "type": "object",
               "properties": {
                  "number": {
                     "type": "string"
                  },
                  "street": {
                     "type": "string"
                  },
                  "city": {
                     "type": "string"
                  },
                  "state": {
                     "type": "string"
                  },
                  "country": {
                     "type": "string"
                  },
                  "postalCode": {
                     "type": "string"
                  }
               }
            }
         }
      }
   }
}

В следующем примере показано, как Content-Type заголовок отображается в формате JSON:

{
   "Content-Type": "application/json"
}

В триггере Запрос выберите Использовать пример полезных данных, чтобы создать схему.

Введите образец полезных данных и нажмите кнопку Готово.

В следующем примере показан пример полезных данных:

{
   "account": {
      "name": "Contoso",
      "ID": "12345",
      "address": {
         "number": "1234",
         "street": "Anywhere Street",
         "city": "AnyTown",
         "state": "AnyState",
         "country": "USA",
         "postalCode": "11111"
      }
   }
}

Чтобы убедиться, что текст запроса во входящем вызове соответствует указанной схеме, выполните приведенные ниже действия.
1. Чтобы входящее сообщение имело именно те поля, которые описаны в вашей схеме, добавьте свойство required в схеме и укажите необходимые поля. additionalProperties Добавьте свойство и задайте значение false.
  
  Например, на следующей схеме указано, что у входящего сообщения должно быть поле msg, а не другие поля:
```
{
   "properties": {
     "msg": {
        "type": "string"
     }
   },
   "type": "object",
   "required": ["msg"],
   "additionalProperties": false
}
```
2. В конструкторе выберите триггер "Запрос". На открывающейся панели сведений выберите вкладку "Параметры ".
3. Разверните узел "Обработка данных" и установите для проверки схемы значение On.
  
  Если текст запроса входящего вызова не соответствует схеме, триггер возвращает ошибку HTTP 400 Bad Request .
Из списка методов выберите метод, который триггер ожидает для обработки входящих запросов.
Если для триггера существуют другие параметры, откройте список дополнительных параметров и выберите нужные параметры.
Если для триггера существуют другие параметры, откройте список дополнительных параметров и выберите нужные параметры.
Когда вы будете готовы, сохраните рабочий процесс. На панели инструментов конструктора выберите Сохранить.

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

Примечание.

Если вы хотите включить символ хэша или знак решетки (#) в URI при вызове триггера запроса, используйте следующую закодированную версию: %25%23

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

Проверка схемы для рабочих процессов без отслеживания состояния

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

"extensions": {
   "workflow": {
      "Settings": {
         "Runtime.StatelessFlowEvaluateTriggerCondition": "true"
      }
   }
}

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

Примечание.

Рабочий процесс сохраняет входящий запрос открытым только в течение ограниченного времени. Если рабочий процесс также включает действие ответа, если рабочий процесс не возвращает ответ вызывающему объекту после истечения этого срока действия, рабочий процесс возвращает состояние 504 GATEWAY TIMEOUT вызывающему объекту. Если рабочий процесс не включает действие ответа, рабочий процесс немедленно возвращает состояние 202 ACCEPTED вызывающему объекту.

Сведения о безопасности, аутентификации и шифровании для входящих вызовов рабочего процесса, таких как Transport Layer Security (TLS), OAuth с идентификатором Microsoft Entra ID, Специальные ключи доступа (SAS), предоставление вашего логического приложения с помощью Azure API Management или ограничение IP-адресов, с которых поступают входящие вызовы, см. в разделе Доступ для входящих вызовов триггеров на основе запросов.

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

В следующей таблице перечислены выходные данные триггера запроса:

Имя свойства JSON	Тип данных	Описание
`headers`	Объект	Объект JSON, описывающий заголовки из запроса
`body`	Объект	Объект JSON, описывающий содержимое текста из запроса

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

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

Внимание

Если действие ответа содержит следующие заголовки, Azure Logic Apps автоматически удаляет эти заголовки из созданного сообщения ответа без предупреждения или ошибки. Azure Logic Apps не включает эти заголовки, хотя служба не остановит вас от сохранения рабочих процессов с действием "Ответ" с этими заголовками.
- Allow
- Content-* заголовки, кроме Content-Disposition, Content-Encodingи Content-Type при использовании POST и PUT операциях, но не включены для GET операций
- Cookie
- Expires
- Last-Modified
- Set-Cookie
- Transfer-Encoding
Если у вас есть одно или несколько действий ответа в сложном рабочем процессе с ветвями, убедитесь, что рабочий процесс обрабатывает по крайней мере одно действие ответа во время выполнения. В противном случае, если все действия ответа пропущены, вызывающий объект получает ошибку 502 Bad Gateway , даже если рабочий процесс успешно завершится.
В рабочем процессе без отслеживания состояния приложения логики уровня "Стандартный" действие ответа должно отображаться в рабочем процессе. Если действие отображается в любом месте, Azure Logic Apps по-прежнему не будет запускать действие, пока все остальные действия не будут запущены.

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

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

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

В поле сведений о действии добавьте необходимые значения для сообщения ответа.

Имя свойства	Имя свойства JSON	Обязательное поле	Описание
Код состояния	`statusCode`	Да	Код состояния, возвращаемый в ответе
Заголовки	`headers`	нет	Объект JSON, который описывает один или несколько заголовков, включаемых в ответ
Текст	`body`	нет	Текст ответа

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

Например, в поле "Заголовки" используйте content-Type в качестве имени ключа и задайте значение ключа application/json , как упоминалось ранее в этой статье. В поле "Тело" можно открыть список динамического содержимого и выбрать выходные данные тела триггера.

Чтобы просмотреть заголовки в формате JSON, выберите команду Перейти в представление текста.

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

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

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

В поле сведений о действии добавьте необходимые значения для сообщения ответа:

Имя свойства	Имя свойства JSON	Обязательное поле	Описание
Код состояния	`statusCode`	Да	Код состояния, возвращаемый в ответе
Заголовки	`headers`	нет	Объект JSON, который описывает один или несколько заголовков, включаемых в ответ
Текст	`body`	нет	Текст ответа

Чтобы просмотреть заголовки в формате JSON, выберите команду Перейти в представление текста.

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

Тестирование рабочего процесса

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

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

Безопасность и проверка подлинности

В рабочем процессе логического приложения уровня "Стандартный", который начинается с триггера запроса (но не с триггера вебхука), можно использовать возможность Azure Functions для проверки подлинности входящих вызовов, отправленных в конечную точку, созданную этим триггером, с помощью управляемого удостоверения. Это положение также называется Easy Auth. Дополнительные сведения см. в разделе "Запуск рабочих процессов" в стандартных приложениях логики с помощью Easy Auth.

Дополнительные сведения о безопасности, авторизации и шифровании для входящих вызовов в рабочий процесс приложения логики, таких как Transport Layer Security (TLS), проверка подлинности через Microsoft Entra ID OAuth, обеспечение доступности приложения логики с помощью "Управление API Azure" или ограничение IP-адресов, от которых инициируются входящие вызовы, см. в статье Доступ для входящих вызовов триггеров на основе запросов.

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

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

Last updated on 2025-07-02