フローおよびサブフロー

このバージョンの 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​ ルータでは、条件に基づいてイベントプロセッサのダウンストリームシーケンス を変更できます。