Leer en inglés

Compartir a través de

在 Azure 逻辑应用中使用分块处理工作流中的大型消息

  • Artículo
  • 23/05/2025

适用于：Azure 逻辑应用（消耗）

Azure 逻辑应用对触发和作在逻辑应用工作流中可以处理的消息内容大小有不同的最大限制，具体取决于逻辑应用资源类型和运行逻辑应用工作流的环境。 这些限制有助于减少存储和处理 大型消息所产生的任何开销。 有关消息大小限制的详细信息，请查看 Azure 逻辑应用中的消息限制。

如果您正在使用内置的 HTTP 操作或特定的托管连接器操作，并且需要 Azure 逻辑应用处理大于默认限制的消息，则可以启用 分块功能，将大型消息拆分为较小的消息。 这样，你仍然可以在特定条件下传输大型文件。 事实上，使用这些内置 HTTP 操作或特定的托管连接器操作时，分块是 Azure 逻辑应用可以处理大型消息的唯一方式。 此要求意味着 Azure 逻辑应用和其他服务之间的基础 HTTP 消息交换必须使用分块，或者要使用的托管连接器创建的连接也必须支持分块。

Nota

由于交换多个消息的开销增加，Azure 逻辑应用不支持对触发器进行分块。 此外，Azure Logic Apps 使用自己的协议实现 HTTP 操作的分块，如本文中所述。 因此，即使您的网站或 Web 服务支持分块，它们也无法与 HTTP 动作分块一起使用。 若要对网站或 Web 服务使用 HTTP 分块传输，必须实现 Azure Logic 应用使用的相同协议。 否则，不要在 HTTP 操作中启用分块。

本文概述了 Azure 逻辑应用中的分块工作原理以及如何在受支持的作上设置分块。

什么使消息变得“大”？

根据所处理消息的服务，消息被认为是“大”的。 大型消息的确切大小限制因 Azure 逻辑应用和连接器而异。 Azure 逻辑应用和连接器都不能直接使用必须分块的大型消息。 有关 Azure 逻辑应用消息大小限制，请参阅 Azure 逻辑应用限制和配置。 有关每个连接器的消息大小限制，请参阅 连接器的参考文档。

Azure 逻辑应用的分块消息处理

Azure 逻辑应用不能直接使用大于消息大小限制的分块消息的输出。 只有支持分块的作业才能访问这些输出中的消息内容。 因此，处理大型消息的操作必须满足以下 任一 条件：

  • 当该操作属于连接器时，该操作必须原生支持分块。

  • 动作必须在该动作的运行时配置中启用分块支持。

否则，尝试访问大型内容输出时会出现运行时错误。 若要启用分块，请参阅 “设置分块支持”。

连接器的分块消息处理

与 Azure 逻辑应用通信的服务可以有自己的消息大小限制。 这些限制通常小于 Azure 逻辑应用限制。 例如，假设连接器支持分块，则连接器可能会认为大小为 30 MB 的消息，而 Azure 逻辑应用则不会。 为了符合此连接器的限制，Azure 逻辑应用将大于 30 MB 的任何消息拆分为较小的区块。

对于支持分块的连接器，基础分块协议对最终用户不可见。 但是，并非所有连接器都支持分块，因此，当传入消息超出连接器的大小限制时，这些连接器将生成运行时错误。

对于支持并启用分块操作的操作，不能使用触发器正文、变量和诸如 triggerBody()?['Content'] 之类的表达式，因为使用这些输入中的任何一种都将阻止分块操作。 请改用 Compose 动作。 具体而言，必须使用Compose操作来创建body字段，以存储来自触发器主体、变量、表达式等的输出数据，例如：

"Compose": {
    "inputs": {
        "body": "@variables('myVar1')"
    },
    "runAfter": {
        "Until": [
            "Succeeded"
        ]
    },
    "type": "Compose"
},

若要引用数据，在分块作中使用表达式 body('Compose')，例如：

"Create_file": {
    "inputs": {
        "body": "@body('Compose')",
        "headers": {
            "ReadFileMetadataFromServer": true
        },
        "host": {
            "connection": {
                "name": "@parameters('$connections')['sftpwithssh_1']['connectionId']"
            }
        },
        "method": "post",
        "path": "/datasets/default/files",
        "queries": {
            "folderPath": "/c:/test1/test1sub",
            "name": "tt.txt",
            "queryParametersSingleEncoded": true
        }
    },
    "runAfter": {
        "Compose": [
            "Succeeded"
        ]
    },
    "runtimeConfiguration": {
        "contentTransfer": {
            "transferMode": "Chunked"
        }
    },
    "type": "ApiConnection"
},

通过 HTTP 设置分块

在通用 HTTP 方案中，可以通过 HTTP 拆分大型内容下载和上传，以便逻辑应用和终结点可以交换大型消息。 但是，必须按照 Azure 逻辑应用预期的方式对消息进行分块。

如果终结点已启用用于下载或上传的分块，则逻辑应用中的 HTTP作会自动对大型消息进行分块。 否则，必须在端点上设置分块支持。 如果不拥有或控制终结点或连接器，则可能无法设置分块。

此外，如果 HTTP 操作尚未启用分块，则还必须在操作的 runTimeConfiguration 属性中设置分块。 可以在操作内设置此属性，可以直接在代码视图编辑器中设置，稍后将详细说明，或者在工作流设计器中按如下所述进行设置：

  1. 在 HTTP 操作的右上角，选择省略号按钮（...），然后选择设置。

    在操作时，打开设置菜单

  2. 在 “内容传输”下，将 “允许分块 ”设置为 “打开”。

    打开分块

  3. 若要继续为下载或上传设置分块，请继续阅读以下部分。

以区块为单位下载内容

通过 HTTP GET 请求下载时，许多终结点会自动以区块方式发送大型消息。 若要通过 HTTP 从终结点下载分块消息，终结点必须支持部分内容请求或 分块下载。 当逻辑应用向终结点发送 HTTP GET 请求以下载内容，并且终结点使用“206”状态代码进行响应时，响应包含分块内容。 Azure 逻辑应用无法控制终结点是否支持部分请求。 但是，当逻辑应用获得第一个“206”响应时，逻辑应用会自动发送多个请求来下载所有内容。

若要检查终结点是否可以支持部分内容，请发送 HEAD 请求。 此请求可帮助你确定响应是否包含 Accept-Ranges 标头。 这样，如果终结点支持分块下载但不发送分块内容，则可以通过在 HTTP GET 请求中设置Range标头来建议此选项。

这些步骤描述了 Azure 逻辑应用用于将分块内容从终结点下载到工作流的详细过程：

  1. 工作流将 HTTP GET 请求发送到终结点。

    请求标头可以选择性地包含一个字段，该字段描述请求内容块的字节范围。

  2. 终结点使用“206”状态代码和 HTTP 消息正文进行响应。

    有关此区块中内容的详细信息显示在响应的 Content-Range 标头中。 这些详细信息包括有助于 Azure 逻辑应用确定区块的开始和结束信息，以及分块之前整个内容的总大小。

  3. 逻辑应用会自动发送后续 HTTP GET 请求。

    逻辑应用会发送后续 GET 请求，直到检索整个内容。

例如，此动作定义显示一条设置 Range 标头的 HTTP GET 请求。 标头 建议 终结点应使用分块内容进行响应：

"getAction": {
    "inputs": {
        "headers": {
            "Range": "bytes=0-1023"
        },
       "method": "GET",
       "uri": "http://myAPIendpoint/api/downloadContent"
    },
    "runAfter": {},
    "type": "Http"
}

GET 请求将“Range”标头设置为“bytes=0-1023”，即字节范围。 如果终结点支持对部分内容的请求，终结点将使用请求范围中的内容区块进行响应。 根据终结点，“Range”标头字段的确切格式可能有所不同。

在区块中上传内容

若要从 HTTP 操作上传分块内容，必须通过操作的 runtimeConfiguration 属性启用分块支持。 此设置允许进行启动分块协议的操作。 然后，逻辑应用可以将初始 POST 或 PUT 消息发送到目标终结点。 终结点使用建议的区块大小进行响应后，逻辑应用会通过发送包含内容区块的 HTTP PATCH 请求来跟进。

以下步骤描述了 Azure 逻辑应用用于将分块内容从逻辑应用上传到终结点的详细过程：

  1. 工作流使用空消息正文发送初始 HTTP POST 或 PUT 请求。

    请求标头包含有关逻辑应用要在区块中上传的内容的以下信息：

    请求标头字段 价值 类型 DESCRIPTION
    x-ms-transfer-mode 分块 字符串 表示内容以分块上传
    x-ms-content-length < content-length> 整数 分块前的整个内容大小（以字节为单位）

  2. 端点返回“200”成功状态代码和以下信息：

    端点响应标头字段 类型 必选 DESCRIPTION
    位置 字符串 是的 用于发送 HTTP PATCH 消息的 URL 位置
    x-ms-chunk-size 整数 否 建议的区块大小（以字节为单位）

  3. 工作流创建并发送后续 HTTP PATCH 消息 - 每个消息都包含以下信息：

    • 基于 x-ms-chunk-size 或某个内部计算得出的大小的内容区块，按顺序上传直到总内容达到 x-ms-content-length。

    • 每个 PATCH 消息中发送的内容块有以下标头信息：

      请求标头字段 价值 类型 DESCRIPTION
      Content-Range < 范围> 字符串 当前内容区块的字节范围，包括起始值、结束值和总内容大小，例如：“bytes=0-1023/10100”
      内容类型 < 内容类型> 字符串 分块内容的类型
      Content-Length < content-length> 字符串 当前区块的大小长度（以字节为单位）

  4. 在每个 PATCH 请求后，端点通过响应“200”状态代码和以下响应头信息确认已收到每个分块：

    终结点响应标头字段 类型 必选 DESCRIPTION
    范围 字符串 是的 终结点接收的内容的字节范围，例如：“bytes=0-1023”
    x-ms-chunk-size 整数 否 建议的区块大小（以字节为单位）

例如，此操作定义显示用于将分段内容上传到端点的 HTTP POST 请求。 在动作的runTimeConfiguration属性中，contentTransfer属性将transferMode设置为chunked：

"postAction": {
    "runtimeConfiguration": {
        "contentTransfer": {
            "transferMode": "chunked"
        }
    },
    "inputs": {
        "method": "POST",
        "uri": "http://myAPIendpoint/api/action",
        "body": "@body('getAction')"
    },
    "runAfter": {
    "getAction": ["Succeeded"]
    },
    "type": "Http"
}