MuleSoft - Mule 异常处理

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

Mule 中的例外情况

在深入研究异常处理之前，我们应该了解会发生什么类型的异常以及开发人员在设计异常处理程序时必须遇到的三个基本问题。

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

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

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

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

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

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

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

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

由于系统/技术问题（例如网络中断）发生的异常应该由重试机制自动处理。

另一方面，由于业务问题（例如无效数据）而发生的异常不应该通过应用重试机制来解决，因为在不解决根本原因的情况下重试是没有用的。

众所周知，所有例外情况并不相同，因此对例外情况进行分类非常重要。在高层次上，异常可以分为以下两种类型 -

业务异常发生的主要原因是数据不正确或流程不正确。这些类型的异常本质上通常是不可重试的，因此配置回滚并不好。即使应用重试机制也没有任何意义，因为在不修复根本原因的情况下重试是没有用的。为了处理此类异常，处理应立即停止，并将异常作为响应发送回死信队列。还应向运营部门发送通知。

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

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

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

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

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

例子

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

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

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

例子

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

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

如果你想根据消息内容来处理异常，那么选择异常策略将是最好的选择。该异常策略的工作原理如下：

在选择异常策略中定义的异常策略将不止一种，例如 Catch 或 Rollback。如果该异常策略下没有定义策略，那么它将把消息路由到默认的异常策略。它从不执行任何提交或回滚或消耗活动。

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