从JBPM WorkItemHandlers抛出异常？

Question

我对从JBPM工作项处理程序抛出异常以及在业务流程的其他地方处理异常这一主题感到有些困惑。我们使用JBPM 6.0.3在Jboss EAP 6.1中运行。

JBPM User Guide意味着您不应该从WorkItemHandler中抛出异常。相反，处理程序应该捕获它们并以某种方式处理它们，或者将它们转换为错误消息，信号或类似信息。 JBPM甚至提供工作项处理程序包装器，它们捕获信号并将它们转换为消息。用户指南中没有关于以任何其他方式处理异常的讨论。

然后我们有了jbpm-workitems包，其中包含了一些专门编码以抛出异常的处理程序。例如，该包中继承自AbstractLogOrThrowWorkItemHandler的任何内容都可能抛出WorkItemHandlerRuntimeException。也许这些处理程序只能用于包装它们，但这似乎是一种奇怪的设计选择。

我还发现了this third-party documentation page这个名为Magnolia的东西，它显示了一种不同的技术。您定义错误消息类型，其中错误代码值是异常类的完全限定名称。然后将错误边界事件附加到调用处理程序的活动。如果处理程序抛出该异常，它将被错误事件捕获。我已经测试了这种方法并且工作正常;它甚至将异常对象捕获到流程变量中。

我很困惑，因为Magnolia页面上显示的方法与JBPM用户指南中的方法完全不同，JBPM指南中没有任何内容甚至暗示Magnolia方法可行。 Magnolia方法似乎更容易使用，但我担心它可能不受支持。

处理工作项处理程序抛出的异常的最佳实践方法是什么？ Magnolia方法是否已被弃用，或仅仅是偶然的？还是我可以指望继续工作？

编辑：提示此问题的原因是我们的团队想要使用jbpm-workitems中的RESTWorkItemHandler。此处理程序将在某些非常普通的情况下抛出异常。 JBPM文档基本上说不要让你的工作项处理程序抛出异常;在处理程序中捕获它们，或将处理程序包装在捕获异常的装饰器中。这将使像REST处理程序这样的处理程序很难构造和正确注册。而且我觉得奇怪的是，JBPM会维护一堆标准的工作项处理程序，如果不将它们包装在另一个处理程序中就无法使用。

然后我找到了Magnolia文档中描述的方法，它避免了必须在处理器中包装处理程序。但是，在JBPM文档中没有描述Magnolia文档中的方法。

Answer 1

基本上，您提出两个我们可以单独解决的问题，让我们看看我们是否可以解决您的疑虑：

1. 处理工作项处理程序抛出异常的最佳实践方法是什么？

这里没有银弹。这取决于许多不同的因素，例如：

• 你可以从异常中恢复吗？例如，如果jBPM和您在WorkItemHandler中访问的资源尊重相同的XA事务，并且有问题的异常标记了回滚事务，那么您的选项将受到限制，因为不会存储持久状态。

  < / LI>

• 如果你能恢复，你想做什么？手动重试，干预流程并记录故障，或者在补偿流程中撤销之前的活动？

• 根据您的目标，最佳去处是哪里？ Java还是BPMN？ BPMN适用于补偿，但WorkItemHandler或者装饰器可能更适合重试。也许它是两者的组合，您将Java异常转换为BPMN信号/错误，向调用者指示它应该重试。

这里没有单一的答案，许多不同的方法都是有效的。

1. Magnolia方法是否已被弃用或有效 只是偶然？或者是我可以指望继续下去的东西 工作？

不，不要弃用，看看代码，我说它是按设计工作的。请记住，在他们的例子中你使用的是Magnolia的装饰者，在这种情况下你应该问Magnolia人是否会在将来支持它。但是有许多装饰器的例子，你可以自己编写一些来实现你选择的异常处理技术。

Answer 2

在jBPM 6.2中，您可以使用Error边界事件，您可以＆＃34;附加＆＃34;到特定的任务。因此，例如，如果在Evaluation任务内部抛出java.lang.ArithmeticException，则可以使用此边界事件来捕获异常，并将其转到另一个任务来处理异常。

如果这不正确，请纠正我，但我认为边界异常处理与执行抛出错误的任务异步。

您可以尝试以下内容：