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

  • Статья

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

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

Примечание.

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

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

  • получение HTTPS-запроса и ответ на него для данных в локальной базе данных;

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

  • Активация рабочего процесса при возникновении внешнего события веб-перехватчика.

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

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

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

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

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

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

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

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

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

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

    Если у вас нет схемы JSON, можно создать схему из примера полезных данных с помощью примера полезных данных Use sample payload для создания возможностей схемы .

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

    Screenshot showing Consumption workflow and Request trigger with example JSON schema.

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

    Screenshot showing Consumption workflow, Request trigger, and reminder to include

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

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

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

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

      Screenshot showing Consumption workflow, Request trigger, and

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

      Screenshot showing Consumption workflow, Request trigger, and sample payload entered to generate schema.

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

      {
   "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 Обязательное поле Description
    Method method Нет Метод, который входящий запрос должен использовать для вызова приложения логики
    Относительный путь relativePath Нет Относительный путь для параметра, который может принимать URL-адрес конечной точки приложения логики

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

    Screenshot showing Consumption workflow, Request trigger, and adding the

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

    Screenshot showing Consumption workflow, Request trigger, and the

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

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

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

    Screenshot showing Consumption workflow, Request trigger, and URL copy button selected.

    Примечание.

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

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

Примечание.

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

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

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

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

Имя свойства JSON Тип данных Description
headers Объект Объект JSON, описывающий заголовки из запроса
текст Объект Объект 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 Обязательное поле Description
    Код состояния statusCode Да Код состояния, возвращаемый в ответе
    Заголовки headers Нет Объект JSON, который описывает один или несколько заголовков, включаемых в ответ
    Текст body Нет Текст ответа

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

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

    Screenshot showing Azure portal, Consumption workflow, and Response action information.

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

    Screenshot showing Azure portal, Consumption workflow, and Response action headers in

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

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

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

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

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

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

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

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