MuleSoft - Mule 异常处理

对于每个项目来说，异常都是必然会发生的。这就是为什么捕获、分类和处理异常很重要，这样系统/应用程序就不会处于不一致的状态。有一个默认的异常策略隐式应用于所有 Mule 应用程序。自动回滚任何待处理事务是默认的异常策略。

Mule 中的异常

在深入研究异常处理之前，我们应该了解可能发生哪种异常，以及开发人员在设计异常处理程序时必须考虑的三个基本问题。

哪种传输很重要?

在设计异常处理程序之前，这个问题具有足够的相关性，因为并非所有传输都支持跨国性。

文件或HTTP不支持事务。这就是为什么，如果在这些情况下发生异常，我们必须手动管理它。

数据库支持事务。在这种情况下设计异常处理程序时，我们必须记住数据库事务可以自动回滚(如果需要)。

对于REST API，我们应该记住它们应该返回正确的HTTP状态代码。例如，未找到资源时返回404。

使用哪种消息交换模式?

在设计异常处理程序时，我们必须注意消息交换模式。可以有同步(请求-回复)或异步(即发即弃)消息模式。

同步消息模式基于请求-回复格式，这意味着该模式将等待响应并将被阻止，直到返回响应或发生超时。

异步消息模式基于即发即弃格式，这意味着该模式假定请求最终将被处理。

这是哪种类型的异常?

非常简单的规则是，您将根据异常类型处理异常。知道异常是由系统/技术问题还是业务问题引起的非常重要。

由系统/技术问题(例如网络中断)引起的异常应通过重试机制自动处理。

另一方面，由业务问题(例如无效数据)引起的异常不应通过应用重试机制来解决，因为如果不解决根本原因，重试是没有用的。

为什么要对异常进行分类?

众所周知，所有异常都不一样，因此对异常进行分类非常重要。从高层次上讲，异常可以分为以下两种类型 −

业务异常

发生业务异常的主要原因是数据不正确或流程不正确。这类异常通常本质上是不可重试的，因此配置回滚并不好。即使应用重试机制也没有任何意义，因为如果不解决根本原因，重试是没有用的。为了处理此类异常，处理应立即停止，并将异常作为对死信队列的响应发送回。还应向操作发送通知。

非业务异常

发生非业务异常的主要原因是系统问题或技术问题。这类异常本质上是可重试的，因此配置重试机制以解决这些异常是很好的。

异常处理策略

Mule 有以下五种异常处理策略 −

默认异常策略

Mule 隐式地将此策略应用于 Mule 流程。它可以处理我们流程中的所有异常，但也可以通过添加 catch、Choice 或 Rollback 异常策略来覆盖它。此异常策略将回滚任何待处理事务并记录异常。此异常策略的一个重要特征是，如果没有事务，它也会记录异常。

作为默认策略，Mule 在流程中发生任何错误时都会实施此策略。我们无法在 AnyPoint 工作室中进行配置。

回滚异常策略

假设没有可能的解决方案来纠正错误，那么该怎么办?一种解决方案是使用回滚异常策略，它将回滚事务，同时向父流的入站连接器发送消息以重新处理该消息。当我们想要重新处理消息时，此策略也非常有用。

示例

此策略可应用于银行交易，其中资金存入支票/储蓄账户。我们可以在这里配置回滚异常策略，因为如果在交易期间发生错误，此策略会将消息回滚到流的开头以重新尝试处理。

捕获异常策略

此策略捕获其父流中抛出的所有异常。它通过处理父流抛出的所有异常来覆盖 Mule 的默认异常策略。我们可以使用捕获异常策略来避免将异常传播到入站连接器和父流。

此策略还可确保在发生异常时不会回滚由流处理的事务。

示例

此策略可应用于航班预订系统，其中我们有一个用于处理来自队列的消息的流程。消息丰富器在消息上添加一个属性以分配座位，然后将消息发送到另一个队列。

现在，如果此流程中发生任何错误，则消息将引发异常。在这里，我们的捕获异常策略可以添加带有适当消息的标头，并将该消息从流中推送到下一个队列。

选择异常策略

如果您想根据消息内容处理异常，那么选择异常策略将是最佳选择。此异常策略的工作方式如下 −

• 首先，它捕获父流中抛出的所有异常。
• 接下来，它检查消息内容和异常类型。
• 最后，它将消息路由到适当的异常策略。

在选择异常策略中会定义多个异常策略，如 Catch 或 Rollback。如果此异常策略下没有定义策略，则它将消息路由到默认异常策略。它从不执行任何提交、回滚或消费活动。

引用异常策略

这指的是在单独的配置文件中定义的常见异常策略。如果消息抛出异常，此异常策略将引用全局捕获、回滚或选择异常策略中定义的错误处理参数。与选择异常策略一样，它也从不执行任何提交、回滚或消费活动。