MuleSoft-ミュールの例外処理

すべてのプロジェクトの場合、例外に関する事実は、例外が発生することです。そのため、システム/アプリケーションが矛盾した状態にならないように、例外をキャッチ、分類、および処理することが重要です。すべてのESB Muleアプリケーションに暗黙的に適用されるデフォルトの例外戦略があります。保留中のトランザクションを自動的にロールバックすることがデフォルトの例外戦略です。

ESB Muleの例外

例外処理を詳しく説明する前に、例外ハンドラーの設計時に開発者がしなければならない3つの基本的な質問とともに、どのような例外が発生する可能性があるかを理解する必要があります。

どのトランスポートが重要ですか？

すべてのトランスポートは多国籍性をサポートしていないため、この質問は例外ハンドラーを設計する前に十分な関連性があります。

ファイル*または *HTTP はトランザクションをサポートしていません。そのため、これらのケースで例外が発生した場合、手動で管理する必要があります。

データベース*はトランザクションをサポートします。この場合の例外ハンドラを設計するとき、データベーストランザクションは自動的にロールバックできることに注意する必要があります（必要な場合）。

*REST API* の場合、正しいHTTPステータスコードを返す必要があることに注意してください。 たとえば、リソースが見つからない場合の404。

どのメッセージ交換パターンを使用しますか？

例外ハンドラを設計するときは、メッセージ交換パターンに注意する必要があります。同期（要求-応答）または非同期（消火-忘れ）メッセージパターンがあります。

同期メッセージパターン*は要求/応答形式に基づいています。つまり、このパターンは応答を予期し、応答が返されるかタイムアウトが発生するまでブロックされます。

非同期メッセージパターン*は、ファイアフォーゲット形式に基づいています。つまり、このパターンは、リクエストが最終的に処理されることを前提としています。

どのタイプの例外ですか？

非常に単純なルールは、そのタイプに基づいて例外を処理することです。例外の原因がシステム/技術的な問題なのかビジネス上の問題なのかを知ることは非常に重要ですか？

システム/技術的な問題（ネットワークの停止など）によって発生した例外は、再試行メカニズムによって自動的に処理される必要があります。

一方、根本的な原因を修正せずに再試行するのは役に立たないため、再試行メカニズムを適用しても、ビジネス上の問題（無効なデータなど）によって発生した例外は解決できません。

例外を分類する理由

すべての例外が同じではないことがわかっているため、例外を分類することは非常に重要です。高レベルでは、例外は次の2つのタイプに分類できます-

ビジネスの例外

ビジネス例外が発生する主な理由は、不正なデータまたは不正なプロセスフローです。これらの種類の例外は通常、本質的に再試行不可能であるため、ロールバック*を設定することは適切ではありません。 *retry メカニズムを適用しても、根本的な原因を修正せずに再試行することは役に立たないため、意味がありません。このような例外を処理するには、処理を直ちに停止し、デッドレターキューへの応答として例外を送り返す必要があります。通知もオペレーションに送信する必要があります。

非ビジネス例外

ビジネス以外の例外が発生する主な理由は、システムの問題または技術的な問題です。これらの種類の例外は本質的に再試行可能であるため、これらの例外を解決するために*再試行*メカニズムを構成することをお勧めします。

例外処理戦略

ESB Muleには、次の5つの例外処理戦略があります-

デフォルトの例外戦略

ESB Muleは暗黙的にこの戦略をESB Muleフローに適用します。フロー内のすべての例外を処理できますが、catch、Choice、またはRollback例外戦略を追加することでオーバーライドすることもできます。この例外戦略は、保留中のトランザクションをロールバックし、例外もログに記録します。この例外戦略の重要な特徴は、トランザクションがない場合にも例外をログに記録することです。

Muleはデフォルトの戦略であるため、フローでエラーが発生した場合にこれを実装します。 AnyPointスタジオでは構成できません。

ロールバック例外戦略

エラーを修正する可能な解決策がない場合はどうすればよいでしょうか？解決策は、ロールバック例外戦略を使用して、親フローのインバウンドコネクタにメッセージを送信するとともにトランザクションをロールバックし、メッセージを再処理することです。この戦略は、メッセージを再処理する場合にも非常に役立ちます。

例

この戦略は、当座預金口座に資金が入金される銀行取引に適用できます。ここでロールバック例外ストラテジーを設定できます。トランザクション中にエラーが発生した場合、このストラテジーはメッセージをフローの最初にロールバックして処理を再試行するためです。

キャッチ例外戦略

この戦略は、親フロー内でスローされるすべての例外をキャッチします。親フローによってスローされたすべての例外を処理することにより、Muleのデフォルトの例外戦略をオーバーライドします。キャッチ例外戦略を使用して、インバウンドコネクタおよび親フローへの例外の伝播も回避できます。

また、この戦略により、フローが処理するトランザクションが例外発生時にロールバックされないようになります。

例

この戦略は、キューからのメッセージを処理するフローがあるフライト予約システムに適用できます。メッセージエンリッチャーは、シートの割り当てのためにメッセージにプロパティを追加し、メッセージを別のキューに送信します。

このフローでエラーが発生すると、メッセージは例外をスローします。ここで、キャッチ例外戦略は、適切なメッセージにヘッダーを追加し、そのメッセージをフローから次のキューにプッシュできます。

選択例外戦略

メッセージの内容に基づいて例外を処理する場合は、例外戦略を選択するのが最適です。この例外戦略の働きは次のようになります-

まず、親フロー内でスローされたすべての例外をキャッチします。
次に、メッセージの内容と例外の種類を確認します。
そして最後に、メッセージを適切な例外戦略にルーティングします。

選択例外戦略内で定義される、キャッチやロールバックなどの複数の例外戦略があります。この例外戦略の下で戦略が定義されていない場合、メッセージはデフォルトの例外戦略にルーティングされます。コミットやロールバックを実行したり、アクティビティを消費したりすることはありません。

参照例外戦略

これは、別の構成ファイルで定義されている一般的な例外戦略を指します。メッセージが例外をスローする場合、この例外戦略は、グローバルキャッチ、ロールバック、または選択例外戦略で定義されたエラー処理パラメーターを参照します。選択例外戦略のように、コミットまたはロールバックを実行したり、アクティビティを消費したりすることはありません。

Mulesoft-mule-exception-handling

目次