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

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

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

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

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

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

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

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

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

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

    Внимание

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

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

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

  1. На портале Azure откройте ресурс стандартного логического приложения.

  2. В меню боковой панели ресурсов в разделе "Рабочие процессы" выберите "Рабочие процессы" и выберите пустой рабочий процесс.

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

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

    Этот пример продолжается с триггером с именем "При получении HTTP-запроса".

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

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

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

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

    Снимок экрана: стандартный рабочий процесс с триггером запроса и параметром схемы JSON текста запроса с примером схемы.

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

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

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

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

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

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

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

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

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

  7. Скопируйте URL-адрес обратного вызова, выбрав значок копирования файлов рядом с полем URL-адреса HTTP .

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

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

    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. В триггере Request в списке Method выберите метод, который должен ожидать триггер. Или можно указать пользовательский метод.

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

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

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

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

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

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

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

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

  1. В триггере запроса в списке методов выберите метод GET .

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

  2. Добавьте действие ответа в рабочий процесс, выполнив общие действия, чтобы добавить действие.

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

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

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

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

      Снимок экрана: стандартный рабочий процесс, действие ответа и выражение triggerOutputs.

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

      Скриншот: стандартный рабочий процесс с разрешенным выражением триггера Outputs() действия «Ответ».

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

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

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

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

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

      Снимок экрана: стандартный рабочий процесс с действием ответа и примером выражения triggerOutputs.

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

  1. Скопируйте 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}

    Браузер возвращает ответ с этим текстом: "Почтовый код: 123456"

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

Примечание.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

    В триггере запроса 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}

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

    Браузер возвращает ответ с этим текстом: "Почтовый код: 123456"

    Снимок экрана показывает браузер со Стандартным рабочим процессом в ответ на запрос на 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. В списке "Имя рабочего процесса" выберите рабочий процесс, который требуется вызвать, например:

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

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

Если тип содержимого входящего запроса — 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, описанной ранее в этом разделе для триггера запроса.

Снимок экрана: действие ответа и тип контента ответа.

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

Свойство (Display) Свойство (JSON) Описание
Код состояния 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-адресов для входящих вызовов?

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

Внимание

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

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

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

Можно ли настроить вызываемые конечные точки дальше?

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

Связанный контент

  • Last updated on