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

2025-10-15

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

Azure 逻辑应用对作可以在逻辑应用工作流中处理的消息内容设置不同的大小限制。这些限制因逻辑应用资源类型和工作流运行环境而异。限制还有助于减少存储和处理大型消息所产生的任何开销。有关消息大小限制的详细信息，请参阅 Azure 逻辑应用中的消息限制。

如果使用内置 HTTP 动作或特定的托管连接器动作来处理大于默认限制的消息，则可以启用分块。此方法将大型消息拆分为较小的消息，因此仍可在特定条件下传输大型文件。

对于这些内置 HTTP 操作和特定的托管连接器操作，分块是 Azure Logic Apps 处理大型消息的唯一途径。 Azure 逻辑应用和其他服务之间的基础 HTTP 消息交换必须使用分块，或者托管连接器创建的连接必须支持分块。

注释

由于交换多个消息的开销增加，Azure 逻辑应用不支持对触发器进行分块。此外，Azure Logic Apps 使用其自身协议实现 HTTP操作的分块传输，如本文章所述。即使您的网站或 Web 服务支持分块，它们仍然不适用于 HTTP 动作分块。

若要对网站或 Web 服务使用 HTTP 动作分块功能，请实现 Azure Logic Apps 使用的相同协议。否则，不要在 HTTP 操作中启用分块。

本文概述了大型消息的含义、分块的工作原理，以及如何在 Azure 逻辑应用中对受支持的作设置分块。

什么使消息变得“大”？

消息的 大小会有所不同，具体取决于处理这些消息的服务。大型消息的确切大小限制因 Azure 逻辑应用和连接器作而异。 Azure 逻辑应用和连接器在没有分块的情况下，无法直接处理大型消息。

有关 Azure 逻辑应用消息大小限制，请参阅 Azure 逻辑应用限制和配置。有关每个连接器的消息大小限制，请参阅连接器参考。

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

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

当该操作属于连接器时，该操作必须原生支持分块。
动作必须在该动作的运行时配置中启用分块支持。

否则，尝试访问大型内容输出时会出现运行时错误。

连接器的分块消息处理

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

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

在支持和启用分块的操作中，不能使用触发器主体、变量和表达式，例如triggerBody()?['Content']。使用上述任一输入可防止分块操作发生。请改用 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 属性设置分块。可以使用代码视图编辑器在作定义中设置此属性，如稍后所述，也可以在工作流设计器中设置此属性，如下所示：

在设计器上，选择 HTTP操作以打开操作信息窗格，然后选择“设置”。
在 “内容传输”下，将 “允许分块 ”设置为 “打开”。
若要完成对下载或上传的分块设置，请继续阅读以下部分。

以区块为单位下载内容

使用 HTTP GET 请求从外部终结点下载内容时，许多外部终结点会自动以区块方式发送大型消息。此行为要求终结点支持部分内容请求或 分块下载。因此，如果工作流中的作发送 HTTP GET 请求以从外部终结点下载内容，并且终结点使用 206 部分内容 状态代码进行响应，则响应包含分块内容。

Azure 逻辑应用无法控制外部终结点是否支持部分内容请求。当工作流中的请求操作收到状态代码为206 部分内容的第一个响应时，该操作会自动发送多个请求以下载所有内容。

若要检查外部终结点是否支持部分内容，请发送 HTTP HEAD 请求，请求仅包含状态行和标头部分的响应，省略响应正文。此请求可帮助你确定响应是否包含 Accept-Ranges 标头。

如果终结点支持部分内容作为分块下载，但不发送分块内容，则可以通过在 HTTP GET 请求中设置标头Range此选项。

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

在您的工作流程中，动作将 HTTP GET 请求发送到端点。

请求标头可以选择性地包含一个字段，该字段描述请求内容块的字节范围。
终结点使用 206 状态代码和 HTTP 消息正文进行响应。

有关此区块中内容的详细信息显示在响应的 Content-Range 标头中。这些详细信息包括有助于 Azure 逻辑应用确定区块的开始和结束信息，以及分块之前整个内容的总大小。
该动作会自动发送后续的 HTTP GET 请求，直到检索完所有内容。

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

"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 逻辑应用用于将工作流中的作中的分块内容上传到外部终结点的详细过程：

在工作流中，一个动作通过发送空消息正文的初始 HTTP POST 或 PUT 请求。

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

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

端点以200成功状态代码响应，并提供以下信息：

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

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

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

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

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

在每个 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"
}