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

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

  • Статья

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

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

Примечание.

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

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

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

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

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

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

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

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

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

  • Установите или используйте средство, которое может отправлять HTTP-запросы для тестирования решения, например:

    Внимание

    В сценариях, в которых есть конфиденциальные данные, такие как учетные данные, секреты, маркеры доступа, ключи 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.

    В следующем примере показана полная схема 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.

    В следующем примере показано, как заголовок 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 :

    Снимок экрана: рабочий процесс потребления, триггер запроса и добавление параметра Method.

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

    Снимок экрана: рабочий процесс потребления, триггер запроса и список

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

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

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

    Снимок экрана: рабочий процесс потребления, триггер запроса и кнопка копирования URL-адресов.

    Примечание.

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

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

Примечание.

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

Сведения о безопасности, проверке подлинности и шифровании для входящих вызовов в рабочий процесс, таких как TLS, ранее известный как Протокол SSL, OAuth с идентификатором Microsoft Entra ID, подписанными URL-адресами (SAS), предоставление ресурсов приложения логики с помощью 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 , как упоминалось ранее в этой статье. В поле Текст можно выбрать выходной текст триггера из динамического списка содержимого.

    Снимок экрана: портал Azure, рабочий процесс потребления и сведения о действии ответа.

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

    Снимок экрана: портал Azure, рабочий процесс потребления и заголовки действий ответа в представлении

  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-адресов, поступающих из входящих вызовов, см. в разделе .Безопасный доступ и данные. Доступ для входящих вызовов триггеров на основе запросов.

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