MuleSoft-ミュール例外処理

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

Muleの例外

例外処理について深く掘り下げる前に、開発者が例外ハンドラーを設計する際に必要な3つの基本的な質問とともに、どのような種類の例外が発生する可能性があるかを理解する必要があります。

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

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

File または HTTPトランザクションはサポートしていません。そのため、このような場合に例外が発生した場合は、手動で管理する必要があります。

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

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

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

例外ハンドラーを設計するときは、メッセージ交換パターンに注意する必要があります。同期（要求-応答）または非同期（ファイア-フォーゲット）のメッセージパターンがあります。

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

Asynchronous message pattern はファイアフォーゲットフォーマットに基づいています。つまり、このパターンは、リクエストが最終的に処理されることを前提としています。

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

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

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

一方、例外が発生しました by a business issue （無効なデータなど）根本的な原因を修正せずに再試行することは有用ではないため、再試行メカニズムを適用して解決しないでください。

なぜ例外を分類するのですか？

すべての例外が同じではないことがわかっているので、例外を分類することは非常に重要です。大まかに言えば、例外は次の2つのタイプに分類できます。

ビジネスの例外

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

ビジネス以外の例外

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

例外処理戦略

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

デフォルトの例外戦略

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

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

ロールバック例外戦略

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

Example

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

例外をキャッチする戦略

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

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

Example

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

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

選択例外戦略

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

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

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

参照例外戦略

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