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

2025-07-26

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

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

Note

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

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

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

Prerequisites

Azure 帐户和订阅。如果没有 Azure 订阅，请注册试用版 Azure 订阅。
要调用的目标终结点的 URL。
包含要从中调用外部终结点的工作流的逻辑应用资源。

若要使用 HTTP 触发器启动工作流，需要有一个空白工作流。若要使用 HTTP 动作，工作流可以从最适合您场景的触发器开始。本文中的示例工作流使用 HTTP 触发器。

如果没有逻辑应用资源和工作流，请立即按照所需的逻辑应用的步骤创建它们：
- 创建示例“消耗”逻辑应用工作流
- 创建标准逻辑应用工作流示例

连接器技术参考

有关触发器和作参数的技术信息，请参阅架构参考指南中的以下部分：

添加 HTTP 触发器

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

Standard
Consumption

在 Azure 门户中，打开你的标准逻辑应用资源。
在资源边栏菜单中的 “工作流”下，选择“ 工作流”，然后选择空白工作流。
在工作流边栏菜单中的 “工具”下，选择设计器以打开工作流。
将 HTTP 内置触发器添加到工作流，方法是按照常规步骤添加触发器。

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

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

添加 HTTP 操作

此内置动作将 HTTPS 或 HTTP 调用发送到指定 URL 的终结点，并返回响应。

Standard
Consumption

在 Azure 门户中，打开你的标准逻辑应用资源。
在资源边栏菜单中的 “工作流”下，选择“ 工作流”，然后选择工作流。
在工作流边栏菜单中的 “工具”下，选择设计器以打开工作流。

此示例使用上一节中添加的 HTTP 触发器。
按照添加操作的常规步骤，将 HTTP 内置操作添加到工作流。

此示例将动作重命名为 HTTP动作 - 调用终结点 URL，以便该动作具有更具描述性的名称。此外，工作流中的操作名称必须是唯一的。
提供要包含在对目标终结点的调用中的 HTTP 操作参数的值。
从“高级参数”列表中选择“身份验证”。

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

触发器和操作输出

HTTP 触发器或作输出以下信息：

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

Status code	Description
200	OK
202	Accepted
400	Bad request
401	Unauthorized
403	Forbidden
404	Not Found
500	内部服务器错误。发生未知错误。

出站调用的 URL 安全性

有关来自工作流的出站调用的加密、安全性和授权的信息，例如传输层安全性（TLS）、自签名证书或 Microsoft Entra ID Open Authentication，请参阅访问其他服务和系统的出站调用。

单租户环境的身份验证

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

TLS 证书：添加应用设置 WEBSITE_LOAD_ROOT_CERTIFICATES，并将该值设置为 TLS 证书的指纹。
具有证书凭据类型的客户端证书或Microsoft Entra ID Open Authentication（Microsoft Entra ID OAuth）：添加应用设置 WEBSITE_LOAD_USER_PROFILE，并将值设置为 1。

TLS 证书身份验证

在您的逻辑应用资源的应用设置中，添加或更新名称为WEBSITE_LOAD_ROOT_CERTIFICATES的应用设置。有关具体步骤，请参阅 “管理应用设置 - local.settings.json”。
对于设置值，请提供 TLS 证书的指纹作为受信任的根证书。

"WEBSITE_LOAD_ROOT_CERTIFICATES": "<thumbprint-for-TLS-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-certificate>",
      <...>
   }
}

Note

若要查找指纹，请执行以下步骤：

在逻辑应用资源菜单上的 “设置”下，选择“ 证书”。
选择“自带证书”（.pfx）或公钥证书（.cer）。
找到要使用的证书并复制指纹。

有关详细信息，请参阅 “查找指纹 - Azure 应用服务”。

有关详细信息，请参阅 “管理应用设置 - local.settings.json”。

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

在您的逻辑应用资源的应用设置中，添加或更新名称为WEBSITE_LOAD_USER_PROFILE的应用设置。有关特定步骤，请参阅 “管理应用设置 - local.settings.json
指定 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",
      <...>
   }
}

如果在 Azure 门户中工作，请打开逻辑应用。在边栏菜单中的 “设置” 下，选择 “环境变量”。在 “应用设置”下，添加或编辑设置。

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

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

"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 ACCEPTED 响应。此代码确认接收方已接受请求，但尚未完成处理。响应可以包含一个 location 标头，该标头指定 URI 和刷新 ID，调用方可用于轮询或检查异步请求的状态，直到接收方停止处理并返回 200 OK 成功响应或其他非 202 响应。但是，调用方不必等待请求完成处理即可继续运行下一操作。有关详细信息，请参阅同步消息传送与异步消息传送。

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

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

若要查找 异步模式 设置，请执行以下作：
1. 在工作流设计器中，选择 HTTP 操作。
2. 在打开的信息窗格中，选择“设置”。
3. 在 “网络”下，找到 “异步模式 ”设置。

禁用异步操作

有时，你在特定场景下可能需要禁用 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"
    }
}

Pagination support

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

禁止检查位置标头

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

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

Known issues

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

通过