Получение и реагирование на входящий вызов 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 — средство сетевой консоли
  • Бруно
  • Curl

  Внимание

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

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

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

Потребление

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

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

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

   Имя свойства	Имя свойства JSON	Обязательное поле	Описание
   URL-адрес HTTP POST	{нет}	Да	URL-адрес конечной точки, созданный после сохранения рабочего процесса и используемый для отправки запроса, который активирует рабочий процесс.
   Схема JSON текста запроса	schema	No	Схема 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 на основе ожидаемых полезных данных, можно использовать такое средство, как JSONSchema.net, или выполнить указанные ниже действия.

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

      

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

      

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

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

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

   1. Чтобы входящее сообщение имело именно те поля, которые описаны в вашей схеме, добавьте свойство required в схеме и укажите необходимые поля. addtionalProperties Добавьте свойство и задайте для параметра значение false.

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

      {
         "properties": {
           "msg": {
              "type": "string"
           }
         },
         "type": "object",
         "required": ["msg"],
         "additionalProperties": false
      }
      

   2. В строке заголовка триггера запроса нажмите кнопку многоточия (...).

   3. В параметрах триггера включите проверку схемы и нажмите кнопку Готово.

      Если текст запроса входящего вызова не соответствует схеме, триггер возвращает ошибку HTTP 400 Bad Request .

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

   Имя свойства	Имя свойства JSON	Обязательное поле	Описание
   Method	method	No	Метод, который входящий запрос должен использовать для вызова приложения логики
   Относительный путь	relativePath	No	Относительный путь для параметра, который может принимать URL-адрес конечной точки приложения логики

   В следующем примере добавляется свойство Method :

   

   Свойство Метод отображается в триггере, что позволяет выбрать метод из списка.

   

6. Когда вы будете готовы, сохраните рабочий процесс. На панели инструментов конструктора выберите Сохранить.

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

7. Чтобы скопировать созданный URL-адрес, щелкните значок копирования рядом с URL-адресом.

   

   Примечание.

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

Стандартные

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

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

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

   Имя свойства	Имя свойства JSON	Обязательное поле	Описание
   URL-адрес HTTP POST	{нет}	Да	URL-адрес конечной точки, созданный после сохранения рабочего процесса и используемый для отправки запроса, который активирует рабочий процесс.
   Схема JSON текста запроса	schema	No	Схема 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 на основе ожидаемых полезных данных, можно использовать такое средство, как JSONSchema.net, или выполнить указанные ниже действия.

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

      

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

      

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

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

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

   1. Чтобы входящее сообщение имело именно те поля, которые описаны в вашей схеме, добавьте свойство required в схеме и укажите необходимые поля. addtionalProperties Добавьте свойство и задайте для параметра значение false.

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

      {
         "properties": {
           "msg": {
              "type": "string"
           }
         },
         "type": "object",
         "required": ["msg"],
         "additionalProperties": false
      }
      

   2. В конструкторе выберите триггер запроса . На открывающейся панели сведений выберите вкладку "Параметры ".

   3. Разверните узел "Обработка данных" и установите для проверки схемы значение On.

      Если текст запроса входящего вызова не соответствует схеме, триггер возвращает ошибку HTTP 400 Bad Request .

5. Чтобы добавить другие свойства или параметры в триггер, перейдите на вкладку "Параметры ", откройте список "Добавить новый параметр" и выберите нужные параметры.

   Имя свойства	Имя свойства JSON	Обязательное поле	Описание
   Method	method	No	Метод, который входящий запрос должен использовать для вызова приложения логики
   Относительный путь	relativePath	No	Относительный путь для параметра, который может принимать URL-адрес конечной точки приложения логики

   В следующем примере добавляется свойство Method :

   

   Свойство Метод отображается в триггере, что позволяет выбрать метод из списка.

   

6. Когда вы будете готовы, сохраните рабочий процесс. На панели инструментов конструктора выберите Сохранить.

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

7. Чтобы скопировать созданный URL-адрес, щелкните значок копирования рядом с URL-адресом.

   

   Примечание.

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

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

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

Примечание.

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

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

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

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

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

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

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

Внимание

• Если действие ответа содержит следующие заголовки, 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 по-прежнему не будет запускать действие, пока все остальные действия не будут запущены.

Потребление

1. В конструкторе рабочих процессов выполните следующие общие действия, чтобы найти и добавить встроенное действие ответа с именем Response.

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

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

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

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

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

   

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

   

3. Чтобы добавить дополнительные свойства для действия, например схему JSON для текста ответа, в списке "Добавить новый параметр" выберите параметры, которые требуется добавить.

4. Закончив работу, сохраните свой рабочий процесс. На панели инструментов конструктора выберите Сохранить.

Стандартные

1. В конструкторе рабочих процессов выполните следующие общие действия, чтобы найти и добавить встроенное действие ответа с именем Response.

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

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

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

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

   

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

   

3. Чтобы добавить дополнительные свойства для действия, например схему JSON для текста ответа, откройте список новых параметров и выберите параметры, которые требуется добавить.

4. Закончив работу, сохраните свой рабочий процесс. На панели инструментов конструктора выберите Сохранить.

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

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

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

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

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

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

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

• Безопасный доступ к данным — доступ для входящих вызовов триггеров на основе запросов
• Управляемые или размещенные в Azure соединители в Azure Logic Apps