MuleSoft - Mule異常處理

在每個專案中，異常都會發生的事實是不可避免的。因此，捕獲、分類和處理異常非常重要，以防止系統/應用程式處於不一致狀態。所有Mule應用程式都隱式應用了預設的異常策略。自動回滾任何掛起的交易是預設的異常策略。

Mule中的異常

在深入探討異常處理之前，我們應該瞭解可能發生的異常型別，以及開發人員在設計異常處理程式時必須考慮的三個基本問題。

在設計異常處理程式之前，這個問題非常重要，因為並非所有傳輸都支援事務性。

檔案或HTTP不支援事務。因此，如果在這些情況下發生異常，我們必須手動處理它。

資料庫支援事務。在此情況下設計異常處理程式時，我們必須記住資料庫事務可以自動回滾（如果需要）。

對於REST API，我們應該記住它們應該返回正確的HTTP狀態碼。例如，資源未找到則返回404。

在設計異常處理程式時，我們必須注意訊息交換模式。可以是同步（請求-回覆）或非同步（即發即忘）訊息模式。

同步訊息模式基於請求-回覆格式，這意味著此模式將期望一個響應，並且將在返回響應或超時之前被阻塞。

非同步訊息模式基於即發即忘格式，這意味著此模式假設請求最終會被處理。

非常簡單的規則是，您將根據異常型別來處理它。瞭解異常是由系統/技術問題還是業務問題引起非常重要。

由系統/技術問題（例如網路中斷）引起的異常應由重試機制自動處理。

另一方面，由業務問題（例如無效資料）引起的異常不應透過應用重試機制來解決，因為在不解決根本原因的情況下重試是沒有用的。

眾所周知，並非所有異常都相同，因此對異常進行分類非常重要。在高層次上，異常可以分為以下兩種型別：

業務異常發生的主要原因是資料不正確或流程不正確。這些型別的異常通常不可重試，因此配置回滾不好。甚至應用重試機制也沒有意義，因為在不解決根本原因的情況下重試是沒有用的。為了處理此類異常，應立即停止處理，並將異常作為響應傳送到死信佇列。還應向操作人員傳送通知。

非業務異常發生的主要原因是系統問題或技術問題。這些型別的異常是可重試的，因此配置重試機制來解決這些異常是很好的。

Mule具有以下五種異常處理策略：

Mule將此策略隱式應用於Mule流程。它可以處理流程中的所有異常，但也可以透過新增catch、Choice或Rollback異常策略來覆蓋。此異常策略將回滾任何掛起的交易並記錄異常。此異常策略的一個重要特徵是，如果沒有任何事務，它也會記錄異常。

作為預設策略，Mule在流程中發生任何錯誤時都會實現它。我們無法在AnyPoint Studio中進行配置。

假設如果沒有可能的解決方案來糾正錯誤，該怎麼辦？一個解決方案是使用回滾異常策略，該策略將回滾事務，並向父流程的入站聯結器傳送訊息以重新處理訊息。當我們想要重新處理訊息時，此策略也非常有用。

示例

此策略可以應用於銀行交易，其中資金正在存入支票/儲蓄賬戶。我們可以在這裡配置回滾異常策略，因為如果交易過程中發生錯誤，此策略會將訊息回滾到流程的開頭以重新嘗試處理。

此策略捕獲在其父流程中丟擲的所有異常。它透過處理父流程丟擲的所有異常來覆蓋Mule的預設異常策略。我們可以使用捕獲異常策略來避免將異常傳播到入站聯結器和父流程。

此策略還確保當發生異常時，流程處理的事務不會回滾。

示例

此策略可以應用於航班預訂系統，在該系統中，我們有一個流程用於處理來自佇列的訊息。訊息增強器在訊息上新增一個屬性以分配座位，然後將訊息傳送到另一個佇列。

現在，如果此流程中發生任何錯誤，則訊息將丟擲異常。在這裡，我們的捕獲異常策略可以新增一個帶有適當訊息的標頭，並將該訊息從流程推送到下一個佇列。

如果您想根據訊息內容處理異常，那麼選擇異常策略將是最佳選擇。此異常策略的工作原理如下：

在選擇異常策略中將定義多個異常策略，例如Catch或Rollback。如果在此異常策略下沒有定義任何策略，則它將訊息路由到預設異常策略。它永遠不會執行任何提交、回滾或使用活動。

這指的是在單獨的配置檔案中定義的通用異常策略。當訊息丟擲異常時，此異常策略將引用在全域性catch、rollback或choice異常策略中定義的錯誤處理引數。與選擇異常策略一樣，它也不會執行任何提交、回滾或使用活動。

列印頁面