从JBPM WorkItemHandlers抛出异常？ [英] Throwing exceptions from JBPM WorkItemHandlers?
问题描述
JBPM用户指南意味着您不应该从WorkItemHandler中抛出异常。相反，处理程序应该捕获它们，或者以某种方式处理它们，否则将它们转换为错误消息，信号或类似信息。 JBPM甚至提供工作项处理程序包装器，捕获信号并将其转换为消息。在用户指南中没有讨论任何其他方式处理异常。
然后我们有jbpm-workitems包，其中包含相当多的特定编码的处理程序来抛出例外。该包中的任何继承自 AbstractLogOrThrowWorkItemHandler 可以抛出一个WorkItemHandlerRuntimeException，例如。也许这些处理程序只能被包装使用，但这似乎是一个奇怪的设计选择。
我还发现此第三方文档页面，称为Magnolia，显示不同的技术。您定义错误消息类型，其中错误代码值是异常类的完全限定名称。然后，您将调用处理程序的活动附加一个错误边界事件。如果处理程序抛出该异常，它将被错误事件捕获。我已经测试了这种方法，它工作正常;它甚至将异常对象捕获到流程变量中。
我感到困惑，因为Magnolia页面上显示的方法与JBPM用户指南中的方法完全不同， JBPM指南中没有任何内容，甚至暗示玉兰方法将会奏效。 Magnolia方法似乎更容易使用，但我担心可能不支持。
处理工作中抛出的异常的最佳实践方法是什么？项目处理程序？木兰属的方法是否被弃用，或者只是意外的呢？还是可以指望继续工作？
编辑：提示这个问题是我们的团队想使用 RESTWorkItemHandler 从jbpm-workitems。这个处理程序会在某些非常普通的情况下抛出异常JBPM文档基本上表示不让你的工作项处理程序抛出异常;在处理程序中捕获它们，或者将处理程序包装在捕获异常的装饰器中。这将使处理程序像REST处理程序一样精简，以正确构造和注册。而且我觉得奇怪的是，JBPM会保留一大堆标准的工作项处理程序，在另一个处理程序中不能使用它们。
然后我找到了描述的方法在Magnolia文档中，避免了将处理程序包装在装饰器中。但是，在JBPM文档中没有描述Magnolia文档中的方法。
本质上你正在提出两个问题，我们可以请分开看看我们是否可以解决您的疑虑：
- 处理工作项处理程序抛出的异常的最佳实践方法是什么？ ？
这里没有银弹。这取决于许多不同的因素，如：
-
你可以从异常中恢复吗？例如，如果jBPM和您在WorkItemHandler中访问的资源遵循相同的XA事务，并且有问题的异常将事务标记为回滚事务，则您的选项将受到限制，因为持久状态将不会被存储。
-
如果你能恢复，你想做什么？手动干预，中止流程并记录失败，或者在补偿流程中反转以前的活动？
-
根据您想要做什么，做最好的地方吗？ Java或BPMN？ BPMN是有益的补偿，但是一个WorkItemHandler或者一个Decorator可能更适合重试。也许这是两者的组合，您将Java异常转换为BPMN信号/错误，向呼叫者指示它应该重试。
这里没有单一的答案，许多不同的方法可能是有效的。
- 是否已经弃用了Magnolia方法，或者意外的是
？或者是我可以指望继续
工作吗？
不，不弃用，看代码我会说它的设计工作。请记住，在他们的例子中，你正在使用玉兰的装饰，在这种情况下，你应该问木兰人是否将来支持它。但是有很多装饰器的例子，你可以自己编写一些自己来实现你选择的异常处理技术。
I'm a little confused about the subject of throwing exceptions from JBPM work item handlers and handling the exception elsewhere in the business process. We're using JBPM 6.0.3 to run in Jboss EAP 6.1.
The JBPM User Guide implies that you should never throw exceptions from within a WorkItemHandler. Instead, the handler should catch them and either handle them some way or else convert them to an error message, signal, or similar. JBPM even provides work item handler wrappers which catch signals and converts them to messages for you. There's no discussion in the user guide about handling exceptions any other way.
Then we have the jbpm-workitems package, which contains quite a few handlers that are specifically coded to throw exceptions. Anything in that package which inherits from AbstractLogOrThrowWorkItemHandler can throw a WorkItemHandlerRuntimeException, for example. Maybe these handlers are only supposed to be used by wrapping them, but that seems like an odd design choice.
I've also found this third-party documentation page for something called Magnolia, which shows a different technique. You define an error message type where the error code value is the fully-qualified name of an exception class. Then you attach an error boundary event to the activity that calls the handler. If the handler throws that exception, it'll be caught by the error event. I've tested this method and it works fine; it even captures the exception object into a process variable.
I'm confused because the method shown on the Magnolia page is completely different from the method in the JBPM user guide, and there is nothing in the JBPM guide which even hints that the Magnolia method will work. The Magnolia method seems to be easier to use, but I'm concerned that it might not be supported.
What is the best-practice way to handle exceptions thrown by work item handlers? Is the Magnolia method something that's deprecated, or that works only by accident? Or is it something that I can count on continuing to work?
Edit: What prompted this question is that our team wanted to use the RESTWorkItemHandler from jbpm-workitems. This handler will throw exceptions in certain very ordinary circumstances. The JBPM documentation basically says not to let your work item handlers throw exceptions; catch them within the handler, or wrap the handler in a decorator that catches exceptions. That would make handlers like the REST handler finicky to construct and register properly. And I thought it strange that JBPM would maintain a bunch of standard work item handlers that couldn't be used without wrapping them in another handler.
Then I found the method described in the Magnolia documentation, which avoids having to wrap the handler in a decorator. But the method in the Magnolia documentation isn't described in the JBPM documentation.
Essentially you are asking two questions which we can address separately, and let's see if we can address your concerns:
- What is the best-practice way to handle exceptions thrown by work item handlers?
There is no silver bullet here. It depends on many different factors such as:
Can you recover from the exception? For example, if jBPM and the resource you access in the WorkItemHandler respect the same XA transaction and the exception in question marked the transaction for rollback, your options are limited as the persistent state won't be stored.
If you can recover, what do you want to do? Retry, intervene manually, abort the process and log the failure, or reverse previous activities in a compensation flow?
Based on what you want to do, where is the best place to do it? Java or BPMN? BPMN is good for compensation, but a WorkItemHandler or perhaps a Decorator may be better for retries. Maybe it is a combination of the two and you convert a Java Exception to a BPMN Signal/Error that indicates to the caller it should retry.
There is no single answer here and many different approaches could be valid.
- Is the Magnolia method something that's deprecated, or that works only by accident? Or is it something that I can count on continuing to work?
Nope, not deprecated, and looking at the code I'd say it works by design. Just keep in mind that in their example you are using Magnolia's decorators, in which case you should ask the Magnolia guys whether they will support it in future. But there are many examples of decorators and you are free to write some yourself to implement the exception handling technique(s) you choose.
这篇关于从JBPM WorkItemHandlers抛出异常？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
