Mulesoft 简明教程

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

File 或 HTTP 不支持事务。因此，如果在这些情况下发生异常，我们必须手动对其进行管理。

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

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

在设计异常处理程序时，我们必须注意消息交换模式。可以有同步（请求-响应）或异步（防火）消息模式。

Synchronous message pattern 基于请求-响应格式，这意味着此模式将期待响应，并且在返回响应或超时之前将被阻塞。

Asynchronous message pattern 基于防火格式，这意味着此模式假定最终将处理请求。

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

system/technical issue 发生的异常（例如网络中断）应该由重试机制自动处理。

另一方面， by a business issue 发生的异常（例如无效数据）不应该通过应用重试机制来解决，因为在未修复根本原因的情况下，重试是没有用的。

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

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

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

作为默认策略，Mule 在流中出现任何错误时实现此策略。我们无法在 AnyPoint Studio 中进行配置。

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

Example

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

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

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

Example

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

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

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

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

这涉及一个在独立配置文件中定义的常见异常策略。如果消息引发异常，此异常策略会引用在全局 catch、rollback 或 choice 异常策略中定义的错误处理参数。与 choice 异常策略一样，它也不会执行任何 commit 或 rollback 或消费活动。