国内开源工作流 Fire Workflow 出炉了

我觉得不是马上成立一个团队，应该先把项目的根基打好，明确方向。然后再慢慢建立一个以LZ为中心的团队持续发展。

对这方面极其感兴趣，首先留下姓名先，看过源代码后，再发表想法。

个人感觉，楼主跟我一样，是在jBPM的基础上改进并重写了一个工作流而已。

但楼主应该将流程编辑器该成web的，让用户使用eclipse或者netbean不太现实。

其次，楼主在你的文章中还是没有解决收回问题。你只想到了上一步可以修改下一步的数据，没有考虑，上一步根本就不应该审核通过的情况，就是不能发到下一步手中。所以在流程上必须收回。

你这么说，我就有要不谦虚地说几句哦。应该说只有2个地方借鉴了jbpm，即AssignmengHandler，TaskInstanceManager设计思路，其他的地方好像没有。
所以不仅仅是“改进并重写了一个工作流而已”，我尤其不喜欢“而已”这个词啊，哈哈。



实际上我从来不赞成Web的流程设计器。要做成Web的也顶多是“流程调整器”。



建议你看一下《5_工作流应用中经典问题的解决方案》

我就是看过了这篇文章中关于收回的处理才说的。
上面谈到了修改数据，以及节点的循环，但收回处理比这些复杂，有些牵涉到事务的回退（如果你在下行的过程中触发了一个行为，在收回的时候就要回滚或者补偿这个行为）

首先感谢你的质疑。
在我看来收回可能没有那么复杂。我以三个环节的流程“A->B->C”为例表达一下我的观点。

首先，A环节操作员收回的根本原因应该是业务表单某个地方填写错了，需要重新填写。所以从这个层面讲，业务系统可以通过某种途径使得A环节的操作员补录一下表单即可。因此，从这个意义上说，用不上工作流系统的“收回”功能。

如果一定要用到工作流系统的收回，则要看B环节的状态。如果B环节已经签收或者已经结束了，流程流转到了C。则工作流系统应该不允许A收回；另一种情况，如果B环节启动了后台程序，则也不允许A收回，否则B的后台程序会执行两遍。

所以，收回是有条件的，无条件的收回太复杂也没有必要。我认为，在这种情况下的收回其实就是循环，只是这个循环不是B环节的操作员发起的，而是A环节的操作员发起的。

很高兴能找到志同道合的朋友一起研究。

就拿你上面的例子而言，A发送到B，B还没有签收，这时A发现，这个单子刚才看错了，或者点的太快了，应该作废或驳回A的上一步的，现在最好就是在B看到前收回错误下发的表单，这个是有可能的（我半个月前就碰到这样的事，财务提交审批给老总，后来发现自己看错了，根本是不能审核通过的，她不想让老总看了后挨骂，就找我们说，能不能赶紧收回），因此必须从B回收到A，修改表单在这时是完全无意义的。当然如果是单纯这样的回收还好，这还不算糟糕的。

一旦在A发到B的过程中，触发了某个机器处理的事件，比如A审批报销通过了，从部门预算中扣除了报销额度（这个Hanlder可能是配置在离开A节点的事件上），这是发现有错误，要收回，则必须补回部门预算的，即撤销已经触发的事件。这就麻烦一些了。

更麻烦的还有呢，特别在分支节点和子流程嵌套的收回上。我也一直在寻找一个比较优雅的解决方式来处理这些东东！！

从业务结果的角度讲，“单纯修改表单”为什么没有意义呢？都是在老总看到报表的时候，报表已经修正了，不是吗？



我认为最优雅的方式就是 不处理。为什么呢？如果的确有这种业务需求，那么在设计阶段，甚至更早就应该考虑解决方案，能避免的要尽量避免，不能避免的也尽量在业务系统中解决，扔到工作流里面不是一个好方案。

dddddd

期待看见一个与jbpm对比的表格，这样可以让有兴趣的读者快速的了解该工作流的优势，同时也可以审视一下该框架是否真的具有开发价值。