Flex Gateway新着情報
Governance新着情報
Monitoring API Manager
このバージョンの Mule は、拡張サポートが終了する 2023 年 5 月 2 日にその すべてのサポートが終了しました。 このバージョンの Mule を使用する CloudHub には新しいアプリケーションをデプロイできなくなります。許可されるのはアプリケーションへのインプレース更新のみになります。 標準サポートが適用されている最新バージョンの Mule 4 にアップグレードすることをお勧めします。これにより、最新の修正とセキュリティ機能強化を備えたアプリケーションが実行されます。 |
Async スコープは、メインフローと同時に実行される分岐処理ブロックです。メインフローは、Async スコープの開始中や処理中に実行され続けます。非同期フローに埋め込まれた最後のメッセージプロセッサーがタスクを完了するまで、フローは一時停止する必要はありません。
Async は、応答を開始フローに返信する必要がない、時間のかかる操作 (ファイルの印刷やメールサーバーへの接続など) を実行する場合に役立ちます。
同時分岐処理を容易にするため、Async スコープは受信したメッセージの 1 つのコピーを独自の処理ブロック内にある最初の埋め込みメッセージプロセッサーに送信します。同時に、メインフロー内の次のメッセージプロセッサーにメッセージの別のコピーを送信します。
Async スコープは「ファイヤアンドフォゲット」方式で実行されるため、スコープ内の処理の結果はメインフローでは使用できません。
Async スコープは、次の点でサブフローと異なります。
メインフローの例外戦略を継承しない。
Async スコープでエラーを処理するには、Try スコープを使用する。
メッセージを非同期的に処理する。
データをメインフローに渡さない。
メインフロースレッドの範囲内に存在する。
Flow Reference コンポーネントからはコールされない。
再利用できない。
Async スコープが Mule メッセージのコピーを受信しても、ペイロードはコピーされません。同じペイロードオブジェクトが両方の Mule メッセージによって参照されます。そのメッセージの 1 つは元のフローに沿って進み続け、もう 1 つは Async スコープによって処理されます。
つまり、メッセージのペイロードが可変オブジェクト (異なる項目が含まれる Bean など) であり、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>