Создание рабочих процессов, которые можно вызвать, активировать или вложить с помощью конечных точек HTTPS в Azure Logic Apps

  • Статья

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

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

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

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

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

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

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

Создание вызываемой конечной точки

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

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

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

  3. При необходимости в поле Схема JSON текста запроса можно ввести схему JSON, описывающую полезные данные или данные, которые должны быть получены триггером.

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

    В этом примере введите следующую схему:

    {
   "type": "object",
   "properties": {
      "address": {
         "type": "object",
         "properties": {
            "streetNumber": {
               "type": "string"
            },
            "streetName": {
               "type": "string"
            },
            "town": {
               "type": "string"
            },
            "postalCode": {
               "type": "string"
            }
         }
      }
   }
}

    Screenshot shows Standard workflow with Request trigger and Request Body JSON Schema parameter with example schema.

    Можно также создать схему JSON, предоставив пример полезных данных:

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

    2. В поле Введите или вставьте образец полезных данных JSON введите образец полезных данных, например:

      {
   "address": {
      "streetNumber": "00000",
      "streetName": "AnyStreet",
      "town": "AnyTown",
      "postalCode": "11111-1111"
  }
}

    3. Когда будете готовы, нажмите кнопку Готово.

      Теперь в поле Схема JSON текста запроса будет отображаться созданная схема.

  4. Сохраните результаты своих действий.

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

    Screenshot shows Standard workflow, Request trigger, and generated callback URL for endpoint.

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

    • Справа от ПОЛЯ URL-адреса HTTP POST выберите Копировать URL-адрес (значок копирования файлов).

    • Скопируйте URL-адрес обратного вызова на странице обзора рабочего процесса.

      1. В меню рабочего процесса выберите "Обзор".

      2. На странице обзора в разделе URL-адрес рабочего процесса переместите указатель на URL-адрес и выберите "Копировать в буфер обмена":

        Screenshot shows Standard workflow and Overview page with workflow URL.

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

    В этом примере используется метод POST:

    POST https://{logic-app-name}.azurewebsites.net:443/api/{workflow-name}/triggers/{trigger-name}/invoke?api-version=2022-05-01&sp=%2Ftriggers%2F{trigger-name}%2Frun&sv=1.0&sig={shared-access-signature}

Выбор ожидаемого метода запроса

По умолчанию триггер запроса ожидает запрос POST. Однако можно указать другой метод, который должен использовать вызывающий объект, но только один метод.

  1. В триггере запроса откройте список расширенных параметров и выберите метод, который добавляет это свойство в триггер.

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

    В этом примере выберите метод GET, чтобы вы могли позже проверить URL-адрес конечной точки.

Передача параметров через URL-адрес конечной точки

Если вы хотите принимать значения параметров через URL-адрес конечной точки, у вас есть следующие варианты:

  • Принимать значения с помощью параметров GET или параметров URL.

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

  • Принимать значения с помощью относительного пути для параметров в триггере запроса.

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

Принимать значения с помощью параметров GET

  1. В триггере запроса откройте расширенные параметры, добавьте свойство Method в триггер и выберите метод GET.

    Подробнее см. в разделе Выбор ожидаемого метода запроса.

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

    В этом примере выберите действие с именем Response.

  3. Чтобы создать выражение triggerOutputs(), получающее значение параметра, выполните следующие действия.

    1. В действии "Ответ" выберите внутри свойства Body , чтобы параметры динамического содержимого (значок молнии) и редактор выражений (значок формулы) отображались. Щелкните значок формулы, чтобы открыть редактор выражений.

    2. В поле выражения введите следующее выражение, заменив parameter-name имя параметра и нажмите кнопку "ОК".

      triggerOutputs()['queries']['parameter-name']

      Screenshot shows Standard workflow, Response action, and the triggerOutputs() expression.

      В свойстве Body выражение разрешается в маркер triggerOutputs().

      Screenshot shows Standard workflow with Response action's resolved triggerOutputs() expression.

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

      Screenshot shows Standard workflow with Response action's resolved expression for parameter name.

      В представлении кода свойство Body отображается в определении действия "Ответ" следующим образом:

      "body": "@{triggerOutputs()['queries']['parameter-name']}",

      Предположим, что необходимо передать значение для параметра с именем postalCode. Свойство Body задает строку Postal Code: с конечным пробелом и соответствующим выражением:

      Screenshot shows Standard workflow with Response action and example triggerOutputs() expression.

Проверка вызываемой конечной точки

  1. Скопируйте URL-адрес рабочего процесса из триггера запроса и вставьте URL-адрес в другое окно браузера. В URL-адресе добавьте имя и значение параметра в URL-адрес в следующем формате и нажмите клавишу ВВОД.

    ...invoke/{parameter-name}/{parameter-value}?api-version=2022-05-01...

    Например:

    https://mystandardlogicapp.azurewebsites.net/api/Stateful-Workflow/triggers/When_a_HTTP_request_is_received/invoke/address/12345?api-version=2022-05-01&sp=%2Ftriggers%2FWhen_a_HTTP_request_is_received%2Frun&sv=1.0&sig={shared-access-signature}

    Браузер возвращает ответ с этим текстом: Postal Code: 123456

    Screenshot shows browser with Standard workflow response from request to callback URL.

Примечание.

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

Прием значений по относительному пути

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

    Screenshot shows Standard workflow, Request trigger, and added property named Relative path.

  2. В свойстве Relative path укажите относительный путь для параметра в схеме JSON, который должен принимать URL-адрес, например /address/{postalCode}.

    Screenshot shows Standard workflow, Request trigger, and Relative path parameter value.

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

    Для этого примера добавьте действие Ответ.

  4. В свойстве Body действия "Ответ" добавьте токен для параметра, который вы указали в относительном пути триггера.

    Предположим, вы хотите, чтобы действие ответа вернуло Postal Code: {postalCode}.

    1. В свойстве Body введите Postal Code: с конечным пробелом. Оставьте курсор в поле редактирования, чтобы список динамического содержимого оставался открытым.

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

      Screenshot shows Standard workflow, Response action, and specified trigger output to include in response body.

      Свойство Body теперь включает выбранный параметр:

      Screenshot shows Standard workflow and example response body with parameter.

  5. Сохраните результаты своих действий.

    В триггере запроса URL-адрес обратного вызова обновляется и теперь включает относительный путь, например:

    https://mystandardlogicapp.azurewebsites.net/api/Stateful-Workflow/triggers/When_a_HTTP_request_is_received/invoke/address/%7BpostalCode%7D?api-version=2022-05-01&sp=%2Ftriggers%2FWhen_a_HTTP_request_is_received%2Frun&sv=1.0&sig={shared-access-signature}

  6. Чтобы протестировать вызываемую конечную точку, скопируйте обновленный URL-адрес обратного вызова из триггера запроса, вставьте URL-адрес в другое окно браузера, замените %7BpostalCode%7D в URL-адресе на 123456 и нажмите клавишу Enter.

    Браузер возвращает ответ с этим текстом: Postal Code: 123456

    Screenshot shows browser with Standard workflow response from request to callback URL.

Примечание.

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

Вызов рабочего процесса с помощью URL-адреса конечной точки

После создания конечной точки можно активировать рабочий процесс, отправив HTTPS-запрос на полный URL-адрес конечной точки. Рабочие процессы Azure Logic Apps поддерживают встроенную поддержку конечных точек прямого доступа.

Токены, созданные из схемы

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

Например, если добавить дополнительные свойства, например "suite"в схему JSON, маркеры для этих свойств доступны в последующих шагах рабочего процесса. Ниже приведена полная схема JSON:

{
   "type": "object",
   "properties": {
      "address": {
         "type": "object",
         "properties": {
            "streetNumber": {
               "type": "string"
            },
            "streetName": {
               "type": "string"
            },
            "suite": {
               "type": "string"
            },
            "town": {
               "type": "string"
            },
            "postalCode": {
               "type": "string"
            }
         }
      }
   }
}

Вызов других рабочих процессов

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

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

    В списке "Имя рабочего процесса" отображаются подходящие рабочие процессы для выбора.

  2. В списке "Имя рабочего процесса" выберите рабочий процесс, который требуется вызвать, например:

    Screenshot shows Standard workflow, action named Invoke a workflow in this workflow app, opened Workflow Name list, and available workflows to call.

Ссылка на содержимое из входящего запроса

Если тип содержимого входящего запроса — application/json, можно ссылаться на свойства во входящем запросе. В противном случае содержимое обрабатывается как одна двоичная единица, которую можно передать в другие API-интерфейсы. Чтобы сослаться на это содержимое в рабочем процессе приложения логики, необходимо сначала преобразовать это содержимое.

Например, при передаче содержимого, имеющего тип application/xml, можно использовать @xpath() выражение для выполнения извлечения XPath или использовать @json() выражение для преобразования XML в JSON. Подробнее о работе с поддерживаемыми типами контента см. здесь.

Чтобы получить выходные данные из входящего запроса, можно использовать @triggerOutputs выражение. Предположим, у вас есть выходные данные, как в этом примере:

{
   "headers": {
      "content-type" : "application/json"
   },
   "body": {
      "myProperty" : "property value"
   }
}

Чтобы получить доступ к свойству body, вы можете использовать @triggerBody() выражение в качестве сочетания клавиш.

Реагирование на запросы

Иногда требуется ответить на определенные запросы, которые активируют рабочий процесс, возвращая содержимое вызывающему объекту. Чтобы создать код состояния, заголовок и текст вашего ответа, вы можете использовать действие "Ответ". Это действие может отображаться в любом месте рабочего процесса, а не только в конце рабочего процесса. Если рабочий процесс не включает действие ответа, конечная точка немедленно отвечает с состоянием 202 Accepted.

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

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

Создание ответа

В текст ответа можно включить несколько заголовков и любого типа содержимого. Например, заголовок следующего ответа указывает, что тип контента ответа и application/json что текст содержит значения для town и postalCode свойств, основанных на схеме JSON, описанной ранее в этом разделе для триггера запроса.

Screenshot shows Response action and response content type.

У ответов есть следующие свойства:

Свойство (Display) Свойство (JSON) Description
Код состояния statusCode Код состояния HTTPS, используемый в ответе для входящего запроса. Это может быть любой допустимый код состояния, который начинается с 2xx, 4xx или 5xx. Однако коды состояния 3xx не разрешены.
Заголовки headers Один или несколько заголовков для включения в ответ
Текст body Объект body может быть строкой, объектом JSON и даже двоичным содержимым из предыдущего шага.

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

"Response": {
   "type": "Response",
   "kind": "http",
   "inputs": {
      "body": {
         "postalCode": "@triggerBody()?['address']?['postalCode']",
         "town": "@triggerBody()?['address']?['town']"
      },
      "headers": {
         "content-type": "application/json"
      },
      "statusCode": 200
   },
   "runAfter": {}
}

Вопросы и ответы

Вопрос. Что такое безопасность URL-адресов для входящих вызовов?

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

Важно!

Для рабочих и более высоких систем безопасности настоятельно рекомендуется вызывать рабочий процесс непосредственно из браузера по следующим причинам:

  • ключ общего доступа отображается в URL-адресе;
  • невозможно управлять политиками безопасного содержимого из-за общих доменов, используемых клиентами Azure Logic Apps.

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

Вопрос. Могу ли я дополнительно настроить конечные точки?

Ответ. Да, конечные точки HTTPS поддерживают расширенную конфигурацию через Azure API Management. Эта служба также предлагает вам возможность согласованно управлять всеми своими API, включая приложения логики, настраивать имена домена, использовать дополнительные методы проверки подлинности и т. д. В частности она предоставляет следующие возможности:

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