Async スコープ

Async スコープは、メインフローと同時に実行される分岐処理ブロックです。メインフローは、Async スコープの開始中や処理中に実行され続けます。非同期フローに埋め込まれた最後のメッセージプロセッサーがタスクを完了するまで、フローは一時停止する必要はありません。

Async は、応答を開始フローに返信する必要がない、時間のかかる操作 (ファイルの印刷やメールサーバーへの接続など) を実行する場合に役立ちます。

同時分岐処理を容易にするため、Async スコープは受信したメッセージの 1 つのコピーを独自の処理ブロック内にある最初の埋め込みメッセージプロセッサーに送信します。同時に、メインフロー内の次のメッセージプロセッサーにメッセージの別のコピーを送信します。

Async + スコープ + 概略図

Async スコープは「ファイヤアンドフォゲット」方式で実行されるため、スコープ内の処理の結果はメインフローでは使用できません。

Async の設定

Async スコープは設定できます。

項目 説明

Display Name (表示名) (​name​)

Async スコープの名前。

Max Concurrency (最大同時実行) (​maxConcurrency​)

省略可能。スコープが処理できる同時メッセージの最大数を設定します。デフォルトでは、メッセージの処理時にパフォーマンスを最適化するために使用される最大スレッド数は、コンテナスレッドプールによって異なります。スコープが最大数の同時メッセージを処理している間は追加要求を受信できません。

スコープが要求を 1 つずつ処理するようにするには、​maxConcurrency​ を ​1​ に設定します。

最大同時実行値に達した後の Mule の動作についての詳細は、「​バックプレッシャーの管理​」を参照してください。

Async スコープとサブフローの比較

Async スコープは、次の点でサブフローと異なります。

  • メインフローの例外戦略を継承しない。

    Async スコープでエラーを処理するには、Try スコープを使用する。

  • メッセージを非同期的に処理する。

  • データをメインフローに渡さない。

  • メインフロースレッドの範囲内に存在する。

  • Flow Reference コンポーネントからはコールされない。

  • 再利用できない。

Async スコープが Mule メッセージのコピーを受信しても、ペイロードはコピーされません。同じペイロードオブジェクトが両方の Mule メッセージによって参照されます。そのメッセージの 1 つは元のフローに沿って進み続け、もう 1 つは Async スコープによって処理されます。

つまり、メッセージのペイロードが可変オブジェクト (異なる項目が含まれる Bean など) であり、Async スコープ内のメッセージプロセッサーがいずれかの項目の値を変更した場合、Async スコープ外部のメッセージプロセッサーが変更された値を参照できます。

Async スコープの設定例

次の XML フラグメントは、アプリケーションフローでの Async スコープの設定例を示しています。Async スコープにある ​file:read​ 操作は、トリガーされると非同期に実行され、アプリケーションはフローの次の操作である ​http:request​ の処理に移ります。

<!-- Main application flow -->
<flow name="myMainFlow" >
  <!-- HTTP Listener as message source -->
  <http:listener doc:name="Listener" />
  <!-- A Transform operation that executes as part of the main flow -->
  <ee:transform doc:name="Transform Message" >
    <ee:message >
      <ee:set-payload >
        <![CDATA[%dw 2.0
        output application/json
        ---
        payload]]>
      </ee:set-payload>
    </ee:message>
  </ee:transform>
    <!-- The Async scope executes its message processors in a different thread, while the main flow continues its execution -->
    <async doc:name="Async" >
      <!-- A Try scope to handle errors, because the async scope does not inherit the error strategy from the flow -->
      <try doc:name="Try" >
        <!-- A Write operation -->
        <file:write doc:name="Write" path="/" />
        <!-- Error handling strategy defined in the Try scope, to handle errors during the Async scope execution -->
        <error-handler >
          <on-error-continue enableNotifications="true" logException="true" doc:name="On Error Continue" type="ANY">
            <!-- Some error handling logic for this strategy -->
            ...
          </on-error-continue>
        </error-handler>
      </try>
    </async>
  <!-- This HTTP Request operation starts executing without waiting for the Async scope to finish its execution -->
  <http:request method="GET" doc:name="Request" />
  ...
</flow>