フローおよびサブフロー
|
このバージョンの Mule は、拡張サポートが終了する 2023 年 5 月 2 日にその すべてのサポートが終了しました。 このバージョンの Mule を使用する CloudHub には新しいアプリケーションをデプロイできなくなります。許可されるのはアプリケーションへのインプレース更新のみになります。 標準サポートが適用されている最新バージョンの Mule 4 にアップグレードすることをお勧めします。これにより、最新の修正とセキュリティ機能強化を備えたアプリケーションが実行されます。 |
Mule アプリケーションは、アプリケーション内の Flow および Subflow コンポーネントのスコープ内でセットアップされた Mule コンポーネント、 コネクタ、およびモジュールを使用して、Mule イベントのメッセージと他の要素を処理します。
単一のフローでアプリケーションを構成したり、処理を個別のフローとサブフローに分割し、それらをまとめてアプリケーションに追加および接続したりできます。通常、本番環境の Mule アプリケーションは複数のフローとサブフローを使用して、アプリケーションを機能モジュール別またはエラー処理目的で分割します。たとえば、1 つのフローで レコードを受信してデータを特定の形式に変換し、別の フローでそのデータを特別な方法で処理できます。
Flow Reference コンポーネントを使用するか、式および変換内で
DataWeave lookup 関数を使用して、それらを接続し、実行をトリガーできます。この関数は、現在のイベントをその後の処理を行う別の
フローに渡します。Flow Reference は、イベントを入力として受け取り、変更されたイベントを返す関数コールと考えることができます。
フローの使用
フローには、フローの実行をトリガーする Mule ソース (要求を受信する HTTP リスナーなど) を使用できます。ソースがフローをすぐに開始しない ようにする場合、最初に停止し、後で Runtime Manager を介して開始するようにフローを 設定できます。
他のプログラミング言語の関数やメソッドと同様に、Web クライアントから API 要求を受信し、イベントを処理してから適切な応答を返すなど、 特定の (たとえば再利用可能な) アクティビティにフローの焦点を絞る ことをお勧めします。イベント処理が複雑になったり、他のサービスをコールする 必要がある場合は、その動作を他のフローに組み込むことができます。
サブフローの使用
サブフローは、フローに似た方法でイベントプロセッサーをグループ化できるスコープですが、いくつかの相違点や制限があります。
-
サブフローにはイベントソースがありません。
-
サブフローにはエラー処理スコープがありません。
-
設計中には、サブフローはそれをコールする Flow Reference コンポーネントを置き換えるマクロとして機能します。
アプリケーションをビルドすると、サブフローをコールするすべての Flow Reference コンポーネントは、参照されるサブフローのコンテンツに置き換えられます。 -
フローを参照するよりもサブフローを参照する方がパフォーマンスは高くなります。
制限事項
サブフローを参照する Flow Reference コンポーネントがサブフローのコンテンツに置き換えられるため、実行時には、そのサブフロー内のイベントプロセッサーの複数のインスタンスがアプリケーション内に存在します。一意の ID またはインスタンスを使用して実行するイベントプロセッサー (バッチプロセッサーなど) では、この動作が問題になる可能性があります。
たとえば、サブフロー内でバッチジョブを設定すると、そのサブフローが複数の Flow Reference コンポーネントで参照されている場合には、アプリケーションがデプロイメント中に失敗します。アプリケーションがデプロイに失敗する理由は、同じジョブインスタンス ID のバッチジョブの複数のインスタンスが存在し、それが許可されないためです。
エラー処理
(サブフローではない) 各フローは、独自のエラー処理を使用できます。Flow Reference コンポーネントを 介してフローをコールする理由の 1 つは、エラー処理をさまざまな コンテキストに分離することです。たとえば、Web クライアント要求を受信する親フローで HTTP 関連のエラー処理を定義するとします。この親フローで その後の処理のために JMS キューをコールする場合、JMS イベントプロセッサーを 個別の子フローに配置し、Flow Reference コンポーネントを使用してそのフローを コールできます。その後、この子フローで独自の JMS 関連エラー処理を定義できます。 この方法は、Java などの他のプログラミング言語でエラーを処理または伝達 する方法と似ています。
フローまたはサブフローのように、Try スコープも独自の エラー処理を使用してイベントプロセッサーのシーケンスをグループ化します。個別の フローまたはサブフローを作成することなく、フローまたはサブフロー内に Try スコープを配置してフロー内のエラー処理を分離できます。このトレードオフは、 Try スコープによるエラー処理がフロー内でインラインで実行されるため、 他のフローまたはサブフロー間での再利用が困難になることです。
どちらの場合も、Java コード内での Try-Catch ブロックの使用と同様に、 フローをコールするか Try スコープを含めることで、エラー処理が分離されます。たとえば、 JMS キューイベント処理 (前述) を独自のフローまたは Try スコープ内に 配置すると、まったく同じエラー処理動作になりますが、 Try スコープ内のイベントプロセッサーを別のフローからコールする ことはできません。
イベント処理の分岐
フローでイベント処理を別々のスレッドに分岐し、フローの特定ポイントで イベントの非同期処理を可能にするスコープがいくつかあります。たとえば、 Scatter-Gather や Async スコープなどです。Choice ルーターでは、条件に基づいてイベントプロセッサーのダウンストリームシーケンス を変更できます。