Azure Logic Apps でチャンクを使用してワークフローで大きなメッセージを処理する

適用対象: Azure Logic Apps (従量課金 + 標準)

Azure Logic Apps では、ロジックアプリワークフローで操作が処理できるメッセージコンテンツにさまざまなサイズ制限が設定されます。これらの制限は、ロジックアプリのリソースの種類とワークフローが実行される環境の両方によって異なります。また、この制限は、大きなメッセージの格納と処理によって生じるオーバーヘッドを軽減するのにも役立ちます。メッセージサイズの制限の詳細については、「 Azure Logic Apps でのメッセージの制限」を参照してください。

組み込みの HTTP アクションまたは特定のマネージドコネクタアクションを使用して、既定の制限を超えるメッセージを処理する場合は、 チャンクを有効にすることができます。この方法では、大きなメッセージをより小さなメッセージに分割するため、特定の条件下でも大きなファイルを転送できます。

これらの組み込みの HTTP アクションと特定のマネージドコネクタアクションでは、Azure Logic Apps が大きなメッセージを使用できる唯一の方法はチャンクです。 Azure Logic Apps と他のサービス間の基になる HTTP メッセージ交換でチャンクを使用するか、マネージドコネクタによって作成された接続でチャンクをサポートする必要があります。

注

複数のメッセージを交換するオーバーヘッドが増加するため、Azure Logic Apps ではトリガーに対するチャンク処理がサポートされていません。また、Azure Logic Apps では、この記事で説明するように、独自のプロトコルを使用して HTTP アクションのチャンクを実装します。 Web サイトまたは Web サービスがチャンクをサポートしている場合でも、HTTP アクションチャンクでは機能しません。

Web サイトまたは Web サービスで HTTP アクションチャンクを使用するには、Azure Logic Apps で使用されるのと同じプロトコルを実装します。それ以外の場合は、HTTP アクションでチャンクを有効にしないでください。

この記事では、大きなメッセージの意味、チャンクのしくみ、および Azure Logic Apps でサポートされているアクションにチャンクを設定する方法の概要について説明します。

メッセージが "大きい" 理由

メッセージは、それらのメッセージを処理するサービスに基づいて 大きくなります 。大きなメッセージの正確なサイズ制限は、Azure Logic Apps とコネクタアクションによって異なります。 Azure Logic Apps とコネクタの両方で、チャンク分割なしに大きなメッセージを直接処理することはできません。

Azure Logic Apps のメッセージサイズの制限については、 Azure Logic Apps の制限と構成に関するページを参照してください。各コネクタのメッセージサイズの制限については、コネクタのリファレンスを参照してください。

Azure Logic Apps のチャンク化されたメッセージ処理

Azure Logic Apps では、メッセージサイズの制限を超えるチャンクされたメッセージからの出力を直接使用することはできません。チャンクをサポートするアクションのみが、これらの出力のメッセージコンテンツにアクセスできます。大きなメッセージを処理するアクションは、次 のいずれかの 条件を満たす必要があります。

アクションがコネクタに属している場合は、そのアクションがチャンクをネイティブにサポートする必要があります。
アクションでは、そのアクションのランタイム構成でチャンクのサポートが有効になっている必要があります。

それ以外の場合は、大きなコンテンツ出力にアクセスしようとするとランタイムエラーが発生します。

コネクタの分割されたメッセージ処理

Azure Logic Apps と通信するサービスには、独自のメッセージサイズの制限があります。多くの場合、これらの制限は Azure Logic Apps の制限よりも小さくなります。たとえば、コネクタがチャンクをサポートしている場合、コネクタでは 30 MB のメッセージが大きいと見なされますが、Azure Logic Apps では考慮されません。このコネクタの制限に準拠するために、Azure Logic Apps は 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 Logic Apps が想定する方法でメッセージをチャンクする必要があります。

外部エンドポイントがチャンクダウンロードまたはアップロードするように設定されている場合、ワークフロー内の HTTP アクションは自動的に大きなメッセージをチャンクします。それ以外の場合は、エンドポイントでチャンクのサポートを設定する必要があります。エンドポイントを所有または制御していない場合は、チャンクを設定できない可能性があります。

HTTP アクションでチャンクがまだ有効になっていない場合は、アクションの runTimeConfiguration プロパティを使用してチャンクを設定する必要があります。このプロパティは、後で説明するようにコードビューエディターを使用するか、ワークフローデザイナーで次のようにアクション定義で設定できます。

デザイナーで、HTTP アクションを選択してアクション情報ウィンドウを開き、[ 設定] を選択します。
[ コンテンツ転送] で、[ チャンクを許可する] を [オン] に設定します。
ダウンロードまたはアップロードのチャンクの設定を完了するには、次のセクションに進みます。

コンテンツをチャンクでダウンロードする

HTTP GET 要求を使用して外部エンドポイントからコンテンツをダウンロードすると、多くの外部エンドポイントが大きなメッセージをチャンクで自動的に送信します。この動作では、エンドポイントが部分的なコンテンツ要求または チャンクされたダウンロードをサポートする必要があります。そのため、ワークフロー内のアクションが外部エンドポイントからコンテンツをダウンロードするための HTTP GET 要求を送信し、エンドポイントが 206 Partial Content 状態コードで応答する場合、応答にはチャンクコンテンツが含まれます。

Azure Logic Apps では、外部エンドポイントが部分的なコンテンツ要求をサポートしているかどうかを制御できません。ワークフローの要求アクションが 206 Partial Content 状態コードを含む最初の応答を取得すると、そのアクションは、すべてのコンテンツをダウンロードするための複数の要求を自動的に送信します。

外部エンドポイントが部分的なコンテンツをサポートしているかどうかを確認するには、HTTP HEAD 要求を送信します。HTTP HEAD 要求は、応答本文を省略して、状態行とヘッダーセクションのみを含む応答を要求します。この要求は、応答に Accept-Ranges ヘッダーが含まれているかどうかを判断するのに役立ちます。

エンドポイントが部分的なコンテンツをチャンクダウンロードとしてサポートしているが、チャンクコンテンツを送信しない場合は、HTTP GET 要求でヘッダーを設定することで、このオプションをRangeできます。

次の手順では、Azure Logic Apps が外部エンドポイントからワークフローにチャンクコンテンツをダウンロードするために使用するプロセスについて説明します。

ワークフローでは、アクションによってエンドポイントに HTTP GET 要求が送信されます。

要求ヘッダーには、必要に応じて、コンテンツチャンクを要求するためのバイト範囲を記述する Range フィールドを含めることができます。
エンドポイントは、 206 状態コードと HTTP メッセージ本文で応答します。

このチャンク内のコンテンツの詳細は、応答の Content-Range ヘッダーに表示されます。これらの詳細には、Azure Logic Apps がチャンクの開始と終了を決定するのに役立つ情報と、チャンク前のコンテンツ全体の合計サイズが含まれます。
このアクションは、すべてのコンテンツが取得されるまで、フォローアップ HTTP 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 Logic Apps が使用する詳細なプロセスについて説明します。

ワークフローでは、アクションによって、空のメッセージ本文を含む最初の HTTP POST または PUT 要求が送信されます。

要求ヘッダーには、ロジックアプリがアップロードするコンテンツに関する次の情報がチャンク単位で含まれています。

要求ヘッダーフィールド	価値	タイプ	Description
x-ms-transfer-mode	チャンク	String	コンテンツがチャンク単位でアップロードされることを示します
x-ms-content-length	< content-length>	整数	チャンク前のコンテンツサイズ全体 (バイト単位)

エンドポイントは、成功状態コードと次の情報 200 応答します。

エンドポイント応答ヘッダーフィールド	タイプ	必須	Description
場所	String	イエス	HTTP PATCH メッセージを送信する URL の場所
x-ms-chunk-size	整数	いいえ	推奨されるチャンクサイズ (バイト単位)

ワークフローアクションは、次の情報を含むフォローアップ HTTP PATCH メッセージを作成して送信します。

x-ms-content-length の長さのコンテンツがすべてアップロードされるまでの x-ms-chunk-size または内部的に計算されたサイズに基づくコンテンツのチャンク

各 PATCH メッセージで送信されるコンテンツチャンクに関する次のヘッダー情報。

要求ヘッダーフィールド	価値	タイプ	Description
Content-Range (コンテンツレンジ)	< 範囲>	String	開始値、終了値、合計コンテンツサイズなど、現在のコンテンツチャンクのバイト範囲。次に例を示します。 `bytes=0-1023/10100`
Content-Type（コンテンツの種類）	< content-type>	String	チャンクされたコンテンツの種類
Content-Length	< content-length>	String	現在のチャンクのサイズの長さ (バイト単位)

各 PATCH 要求の後、エンドポイントは、 200 状態コードと次の応答ヘッダーで応答することで、各チャンクの受信を確認します。

エンドポイント応答ヘッダーフィールド	タイプ	必須	Description
Range	String	イエス	エンドポイントが受信したコンテンツのバイト範囲。次に例を示します。 `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"
}

フィードバック

このページはお役に立ちましたか?

Last updated on 2025-09-16