从 Azure 逻辑应用中的工作流调用外部 HTTP 或 HTTPS 终结点

Artículo
07/08/2024

适用范围：Azure 逻辑应用（消耗型 + 标准型）

某些方案可能需要创建逻辑应用工作流，通过 HTTP 或 HTTPS 将出站请求发送到其他服务或系统上的终结点。例如，假设需要通过在特定计划中检查某个终结点来监视网站的服务终结点。当某个特定事件发生在该终结点时，例如网站关闭，该事件会触发工作流并运行该工作流中的操作。

注意

若要创建接收和响应入站 HTTPS 调用的工作流，请参阅创建可以使用 Azure 逻辑应用中的 HTTPS 终结点调用、触发或嵌套的工作流以及内置的请求触发器和响应操作。

本指南介绍如何使用 HTTP 触发器和 HTTP 操作，以便工作流可以将出站调用发送到其他服务和系统，例如：

若要按定期计划检查或轮询某个终结点，可添加 HTTP 触发器作为工作流中的第一个步骤。每次触发器检查终结点时，触发器都会调用该终结点或向该终结点发送请求。终结点的响应决定工作流是否运行。触发器将终结点响应中的任何内容传递到工作流中的操作。
若要从工作流中的任何其他位置调用终结点，请添加 HTTP 操作。该终结点的响应确定了工作流剩余操作的运行方式。

先决条件

Azure 帐户和订阅。如果没有 Azure 订阅，请注册试用版 Azure 订阅。
要调用的目标终结点的 URL
要从中调用目标终结点的逻辑应用工作流。若要从 HTTP 触发器开始，则需要空白的工作流。若要使用 HTTP 操作，请使用所需的任何触发器启动工作流。此示例的第一步是使用 HTTP 触发器。

连接器技术参考

有关触发器和操作参数的技术信息，请参阅以下部分：

添加 HTTP 触发器

此内置触发器对终结点的指定 URL 发出 HTTP 调用，并返回响应。

标准
消耗

在 Azure 门户的设计器中，打开标准逻辑应用资源和空白工作流。
按照以下常规步骤将名为HTTP的内置触发器添加到工作流。

此示例将触发器重命名为 HTTP 触发器 - 调用终结点 URL，以便触发器具有更具描述性的名称。此外，示例稍后会添加 HTTP 操作，并且工作流中的操作名称必须是唯一的。
提供要包含在对目标终结点的调用中的 HTTP 触发器参数的值。设置希望触发器检查目标终结点的频率的重复周期。

如果选择的身份验证类型不是“None”，则身份验证设置将根据你的选择而有所不同。有关可用于 HTTP 的身份验证类型的更多信息，请参阅以下主题：
- 向出站调用添加身份验证
- 使用托管标识对资源访问者进行身份验证
要添加其他可用参数，请打开“高级参数”列表，然后选择所需的参数。
添加触发器触发时要运行的任何其他操作。
完成后，保存工作流。在设计器工具栏上选择“保存”。

添加 HTTP 操作

此内置操作对终结点的指定 URL 发出 HTTP 调用，并返回响应。

标准
消耗

在 Azure 门户中，打开设计器中的消耗型逻辑应用和工作流。

此示例使用上一部分中添加的 HTTP 触发器作为第一步。
按照以下常规步骤将名为HTTP的内置操作添加到工作流。

此示例将操作重命名为 HTTP 操作 - 调用终结点 URL，以便步骤具有更具描述性的名称。此外，工作流中的操作名称必须是唯一的。
提供要包含在对目标终结点的调用中的 HTTP 操作参数的值。

如果选择的身份验证类型不是“None”，则身份验证设置将根据你的选择而有所不同。有关 HTTP 可用的身份验证类型的详细信息，请参阅以下主题：
- 向出站调用添加身份验证
- 使用托管标识对资源访问者进行身份验证
要添加其他可用参数，请打开“高级参数”列表，然后选择所需的参数。
完成后，保存工作流。在设计器工具栏上选择“保存”。

触发器和操作输出

以下是有关 HTTP 触发器或操作输出的更多信息，它返回以下信息：

properties	类型	说明
`headers`	JSON 对象	请求中的标头
`body`	JSON 对象	包含请求中正文内容的对象
`status code`	Integer	请求中的状态代码

状态代码	说明
200	确定
202	已接受
400	错误的请求
401	未授权
403	禁止
404	未找到
500	内部服务器错误。发生未知错误。

出站调用的 URL 安全性

有关工作流中出站调用的加密、安全性和授权的信息，如传输层安全性 (TLS)（以前称为安全套接字层 (SSL)）、自签名证书或 Microsoft Entra ID 开放身份验证 (Microsoft Entra ID OAuth)，请参阅安全访问和数据 - 对其他服务和系统的出站调用访问。

单租户环境的身份验证

如果在单租户 Azure 逻辑应用中有标准逻辑应用资源，并且希望将 HTTP 操作与以下任何身份验证类型一起使用，请确保完成相应身份验证类型的额外设置步骤。否则，调用会失败。

TLS/SSL 证书：添加应用设置 WEBSITE_LOAD_ROOT_CERTIFICATES，并将值设置为你的 TLS/SSL 证书的指纹。
客户端证书或凭据类型为“证书”的 Microsoft Entra ID 开放式身份验证 (Microsoft Entra ID OAuth)：添加应用设置 WEBSITE_LOAD_USER_PROFILE，并将值设置为1。

TLS/SSL 证书身份验证

在逻辑应用资源的应用设置中，添加或更新应用设置WEBSITE_LOAD_ROOT_CERTIFICATES。
对于设置值，请提供 TLS/SSL 证书的指纹作为受信任的根证书。

"WEBSITE_LOAD_ROOT_CERTIFICATES": "<thumbprint-for-TLS/SSL-certificate>"

例如，如果使用 Visual Studio Code，请执行以下步骤：

打开逻辑应用项目的 local.settings.json 文件。
在 Values JSON 对象中，添加或更新 WEBSITE_LOAD_ROOT_CERTIFICATES 设置：
```
{
   "IsEncrypted": false,
   "Values": {
      <...>
      "AzureWebJobsStorage": "UseDevelopmentStorage=true",
      "WEBSITE_LOAD_ROOT_CERTIFICATES": "<thumbprint-for-TLS/SSL-certificate>",
      <...>
   }
}
```
注意

若要查找指纹，请执行以下步骤：
1. 在逻辑应用资源菜单上的“设置”下，选择“TLS/SSL 设置”>“私钥证书(.pfx)”或“公钥证书(.cer)”。
2. 找到要使用的证书并复制指纹。
有关详细信息，请查看查找指纹 - Azure 应用服务。

有关详细信息，请查看以下文档：

客户端证书或凭据类型为“证书”的 Microsoft Entra ID OAuth 的身份验证

在逻辑应用资源的应用设置中，添加或更新应用设置WEBSITE_LOAD_USER_PROFILE。
指定 1 作为设置值。

"WEBSITE_LOAD_USER_PROFILE": "1"

例如，如果使用 Visual Studio Code，请执行以下步骤：

打开逻辑应用项目的 local.settings.json 文件。

在 Values JSON 对象中，添加或更新 WEBSITE_LOAD_USER_PROFILE 设置：

{
   "IsEncrypted": false,
   "Values": {
      <...>
      "AzureWebJobsStorage": "UseDevelopmentStorage=true",
      "WEBSITE_LOAD_USER_PROFILE": "1",
      <...>
   }
}

有关详细信息，请查看以下文档：

具有多部分/表单数据类型的内容

若要处理 HTTP 请求中具有 multipart/form-data 类型的内容，可以使用此格式向 HTTP 请求的正文添加包含 $content-type 和 $multipart 属性的 JSON 对象。

"body": {
   "$content-type": "multipart/form-data",
   "$multipart": [
      {
         "body": "<output-from-trigger-or-previous-action>",
         "headers": {
            "Content-Disposition": "form-data; name=file; filename=<file-name>"
         }
      }
   ]
}

例如，假设你有工作流，其使用网站的 API（支持 multipart/form-data 类型）向该网站发送 Excel 文件的 HTTP POST 请求。以下示例显示了此操作的显示方式：

标准工作流

消耗工作流

下面是相同的示例，显示了基础工作流定义中的 HTTP 操作的 JSON 定义：

"HTTP_action": {
   "inputs": {
      "body": {
         "$content-type": "multipart/form-data",
         "$multipart": [
            {
               "body": "@trigger()",
               "headers": {
                  "Content-Disposition": "form-data; name=file; filename=myExcelFile.xlsx"
               }
            }
         ]
      },
      "method": "POST",
      "uri": "https://finance.contoso.com"
   },
   "runAfter": {},
   "type": "Http"
}

具有 application/x-www-form-urlencoded 类型的内容

若要在 HTTP 请求的正文中提供 form-urlencoded 数据，必须指定数据具有 application/x-www-form-urlencoded 内容类型。在 HTTP 触发器或操作中，添加 content-type 标头。将标头值设置为 application/x-www-form-urlencoded。

例如，假设你有一个逻辑应用，它向支持 application/x-www-form-urlencoded 类型的网站发送 HTTP POST 请求。下面是此操作的可能外观：

标准工作流

消耗工作流

异步请求-响应行为

对于多租户和单租户 Azure 逻辑应用中的有状态工作流，所有基于 HTTP 的操作都遵循标准异步操作模式作为默认行为。该模式指定在 HTTP 操作调用某个终结点、服务、系统或 API 或向其发送请求后，接收方立即返回“202 已接受”响应。此代码确认接收方已接受请求，但尚未完成处理。响应可能包括一个 location 标头，该标头指定的 URI 和刷新 ID 可供调用方用于轮询或检查异步请求的状态，直到接收方停止处理并返回“200 正常”成功响应或其他非 202 响应。但是，调用方不必等待请求完成处理即可继续运行下一操作。有关详细信息，请参阅异步微服务集成强制实施微服务自治。

对于单租户 Azure 逻辑应用中的无状态工作流，基于 HTTP 的操作不使用异步操作模式。相反，它们仅同步运行，按原样返回“202 ACCEPTED”响应，然后继续执行工作流的下一步。如果响应包含 location 标头，则无状态工作流不会轮询指定的 URI 来检查状态。若要遵循标准异步操作模式，请改用有状态工作流。

HTTP 操作的基础 JavaScript 对象表示法 (JSON) 定义隐式遵循异步操作模式。
HTTP 操作（而不是触发器）具有默认启用的异步模式设置。此设置指定调用方不等待处理完成即可继续执行下一操作，但需继续检查状态直到处理停止。如果禁用，则此设置指定调用方需等待处理完成才能继续执行下一操作。

要查找异步模式设置，请根据工作流是标准工作流还是消耗工作流，执行以下步骤：

标准工作流*
1. 在工作流设计器中，选择 HTTP 操作。在打开的信息窗格中，选择“设置”。
2. 在“网络”下，找到“异步模式”设置。
消耗工作流
1. 在工作流设计器的 HTTP 操作的标题栏上，选择省略号 (...) 按钮，这将打开操作的设置。
2. 找到“异步模式”设置。

禁用异步操作

有时，你在特定场景下可能需要禁用 HTTP 操作的异步行为，例如，当你希望实现以下目的时：

避免长时间运行的任务发生 HTTP 超时
禁止检查位置标头

在工作流设计器中，选择“HTTP 操作”，然后在打开的信息窗格中，选择“设置”。
在“网络”下，找到“异步模式”设置。如果已启用，请将设置转到“关闭”。

在操作的 JSON 定义中禁用异步模式

在 HTTP 操作的基础 JSON 定义中，向操作的定义添加 "DisableAsyncPattern" 操作选项，使操作改为遵循同步操作模式。有关详细信息，另请参阅在同步操作模式下运行操作。

避免长时间运行的任务发生 HTTP 超时

HTTP 请求有一个超时限制。如果有长时间运行的 HTTP 操作由于此限制而超时，则可使用以下选项：

禁用 HTTP 操作的异步操作模式，使该操作不会持续轮询或检查请求的状态，而是等待接收方在请求完成处理后以状态和结果做出响应。
将 HTTP 操作替换为 HTTP Webhook 操作，后者会等待接收方在请求完成处理后以状态和结果做出响应。

使用 Retry-After 标头设置重试尝试之间的间隔

要指定重试尝试之间的秒数，可以将 Retry-After 标头添加到 HTTP 操作响应。例如，如果目标终结点返回 429 - Too many requests 状态代码，则可以指定更长的重试间隔。 Retry-After 标头也适用于 202 - Accepted 状态码。

下面是相同的示例，显示了包含 Retry-After 的 HTTP 操作响应：

{
    "statusCode": 429,
    "headers": {
        "Retry-After": "300"
    }
}

分页支持

有时，目标服务通过一次返回一页结果来进行响应。如果响应使用 nextLink 或@odata.nextLink 属性指定下一页，则你可以在 HTTP 操作中开启 Pagination 设置。此设置会导致 HTTP 操作自动跟踪这些链接并获取下一页。但是，如果响应使用任何其他标记指定下一页，则你可能需要向你的工作流添加一个循环。使此循环跟踪该标记，并手动获取每一页，直至该标记为空。

禁止检查位置标头

某些终结点、服务、系统或 API 会返回没有 location 标头的 202 ACCEPTED 响应。若要避免 HTTP 操作在 location 标头不存在时不断检查请求状态，可以使用以下选项：

禁用 HTTP 操作的异步操作模式，使该操作不会持续轮询或检查请求的状态，而是等待接收方在请求完成处理后以状态和结果做出响应。
将 HTTP 操作替换为 HTTP Webhook 操作，后者会等待接收方在请求完成处理后以状态和结果做出响应。

已知问题

忽略了 HTTP 标头

如果 HTTP 触发器或操作包含这些标头，则 Azure 逻辑应用会从生成的请求消息中删除这些标头，且不显示任何警告或错误：

Accept-* 标头（Accept-version 除外）
Allow
Content-* 头（Content-Disposition、Content-Encoding 和 Content-Type 除外），在使用 POST 和 PUT 操作时使用。但使用 GET 操作时，Azure 逻辑应用会删除这些标头。
Cookie 标头，但 Azure 逻辑应用优先处理使用 Cookie 属性指定的任何值。
Expires
Host
Last-Modified
Origin
Set-Cookie
Transfer-Encoding

尽管 Azure 逻辑应用不会阻止保存这些逻辑应用（使用具有这些标头的 HTTP 触发器或操作的逻辑应用），但 Azure 逻辑应用会忽略这些标头。

响应内容与预期的内容类型不匹配

如果 HTTP 操作调用 Content-Type 标头设置为“application/json”的后端 API，但后端的响应实际上不包含 JSON 格式的内容（这将导致内部 JSON 格式验证失败），则 HTTP 操作会引发 BadRequest 错误。

Compartir a través de