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

这话要留给对老板和销售说，要留给客户说，跟我们说没有用的。如果你对他们说了，而且他们认同的给钱了，那就是你牛

很多网友提过这个部署模式，但是我认为理论上可行，但是实际情况可能不行。

这种SOA的结构，我试图尝试过，问题会出在对扩展Handler的远程调用上，还是有技术难点的

听起来，很有激情。

to zip117:
是Example中缺少两个jar包，一个是jta.jar,一个是commons-pool-1.3.jar,
这两个包需要放在WEB-INF/lib目录下。


你可以到Fire workflow群的共享区去下载，或者在google上搜索一下

曾经搞过工作流
好像这个跟电子政务的不太一样

还未仔细的拜读过您的的所有文档和例子，只是想选问一下，你的工作流项目对于并发子流程有没有很的解决方式？我以前使用jbpm3时的解决方式实在是太丑陋了，具体也是参考网上的一篇文章来实现的。

我认为Fire workflow 对于并发有很好的解决方式，对于子流程也有很好的解决方式，你可以看一下《3_各种工作流模式的实现》，在Fire workflow的模拟器中可以对上述模式进行模拟，非常方便。不过你提到的是“并发子流程”具体不知道是那种模式，不过我想Fire workflow肯定能够优雅地解决你的问题。

我说的并发子流程的意思是，会签的过程也是一个子流程。比如，一张工单需要通过:
部门1班组长审批->部门1中心经理审批->部门1主管审批
部门2班组长审批->部门2中心经理审批->部门2主管审批
部门3......
部门4...
....
各个部门的相关人员的审核才算通过并且各个部门是不确定的。

我觉得你这里最大的不同之处就是“各个部门是不确定的”这个约束。
我用Fire workflow设计了一个父子流程。父流程如下图，这个图没有什么好说的，在“会签审核”环节包含一个子流程Task，该Task调用“会签审核”子流程。


"会签审核"子流程如下图，要达到会签的要求，Task的AssignmentStrategy必须设置为“ALL”。那么“各个部门是不确定的”如何体现呢？这是通过Performer中的"cn.firesoft.xyz.MyAssignmentHandler"实现的。在该Assignment Handler中可以拿到角色名称和TaskInstance，你可以在这个类里面确定哪个或者哪些TaskInstance具体由哪些部门来会签。



另外，你这个案例看上去是“并发”和“子流程”的一个结合，其实并不需要搞得这么复杂，用下面的流程可以更加简洁的完成你的需求。即 将子流程合并到父流程中。



该帖所有的流程定义文件在附件中。