Mule文档指出catch-exception-strategy类似于java catch块。但不幸的是，有效载荷被消耗（消息消耗）;从catch块中丢失有效负载（与java方法不同，在java方法中，您可以从catch / finally块访问方法输入参数）。
这种设计的问题在于，在任何情况下，（从捕获策略流程）都不可能知道错误和最后使用的已知富集有效负载（导致错误？）。这使得导致错误的数据的审计变得复杂。
假设存在具有10个消息处理器的流，则识别出错误的消息处理器变得冗长乏味。
我可以看到有关有效载荷的2个解决方法：
1）在入站端点之后，在每个消息处理器之前将有效负载推送到流量变量（另一个缺点是入站属性和附件会发生什么？）
2）使用Rollback异常策略，尝试为零（事务将回滚），并且原始输入消息可用。 （缺点：很难反思错误发生的原因以及消息处理器 - 例如：我可能有5个或6个DB处理器）
这一点变得很重要的原因是支持生产中的ESB应用程序变得更容易。
例如，如果我们能够管理有效负载和异常详细信息（链接到单个UID），则从catch块中，您可以运行日志监视工具，将其推送到实时仪表板以进行监视目的/提醒警报。可以将相同的方法统一应用于所有应用程序/流和Java组件等。
MMC在这方面很弱 - 例如，如果你想在5次出现后从批处理作业中抑制警报，MMC就无法做到。
我的问题是： 1）为什么有效载荷不可用有什么原因吗？ 可能的解决方法是将（最后已知数据）推送到另一个变量，作为名为originalPayload或originalInboundProperties的消息的一部分？ 2）任何其他直接的方法将异常和有效负载管道到一个appender（而不是解决方法）？
Ananth Krishnan（WHISHWORKS.com）