工作流系统的设计与实现 1.0

拜读过0.82 版，很有参考价值

呵呵，很久没有看到这样的好文章了。timeson 兄你以你之才可以出本这方面的书了哈。文章讲得颇有深度，尤其是工作流部分。
有几个地方请教下：
1.在流程实例的执行过程中，流程实例是否允许退回到开始节点，如果允许退回到开始节点，那当流程实例退回到开始节点时，引擎对这种情况的后续处理是怎样的？
2.人工任务节点的参与者的处理，文章讲得很详细深入；但有一种情况没有提到，现实中经常出现，就是某个任务分配给某人处理了，但是这个人已经离职或调离了以前的岗位（反正就是这个人不可能再处理这个任务），这个时候该如何处理？

start属于event，并非activity，token是不能驻留在event上的，就算跳转到start上，流程也不会停留，而是直接向下流转。

所谓的“退回到开始”，其实是“跳转到流程的第一个人工节点”。

组织机构适配，属于流程引擎与外部服务相互调用的一个桥梁，流程引擎本身保存userId和groupId，所以难以保证userId或者groupId是否存在。

两种解决方法：
1.observer模式，设置userId或者groupId就先去组织机构适配器里校验一下。需要引擎本身提供这类支持。
2.提供一个后端管理控制台，让相关人员去查询哪些任务“死了”。

不管怎么样，后端的控制监控还是需要的。

xyz20003兄所说的'start属于event，并非activity，token是不能驻留在event上的，就算跳转到start上，流程也不会停留，而是直接向下流转。

所谓的“退回到开始”，其实是“跳转到流程的第一个人工节点”。' 应该是jbpm引擎中的处理方式，但我觉得这种处理方式在遇到如下情况就无法处理：当流程被退回到开始节点的时候意味着 流程申请者有些业务上的事情做得还不够故被打回来了可能要求重新对业务数据进行完善或处理然后重新开始流程的处理；也有可能是用户的误操作对无意义或错误的数据发起了流程处理，实际上这种情况流程发起者取消流程即可。这种业务需求在现实中是存在的。我现在并不关注开始节点是event还是activity，而是要满足这种业务需要。

对于 参与者无法处理这个问题，我觉得第一种方案还是不能完全解决这个问题，组织机构适配器校验无非是检查用户是非已经离职或什么的，这要求当用户不使用系统的同时而数据库中的状态就马上变成离职或对应的状态，有个切换时间；在这些时间里谁能保证不产生新的任务。第二个方案提到在流程监控中可以查看到，我觉得还可以进一步在这里可以指定新的执行人使流程继续往下进行。

对了，还有一个可能大家都比较关心的问题：如何提高流程引擎的性能？JBPM是个好东西，以前jbpm3出来我研究过但在企业应用环境下性能问题真是令人大伤脑筋；正是因为这个原因我抛弃了他自己写了个引擎。也不知道JBPM4的性能现在如何？xyz20003 兄应该很有发言权，拜读过你们整的帮助手册，呵呵。

这方面我没太明白，表单数据补充型退回我们现在也是使用退回第一个人工任务参与者方式来实现的。把start当做event来看待，更容易定义scope的边界，在jbpm中体现的还不多，在BPMN2中支持多达10种的event，可以标示丰富的业务含义。

如果是业务流程取消，建议直接end掉process instance。



jbpm提供的性能调优方面的建议是把耗时的操作设置为“异步”，迅速返还用户界面。学学bpel在消息请求方面加上mq应该也可以增大吞吐量，不过我还没有实际用过，不敢保证实际效果。

在流程引擎与实际业务绑定之前，单纯对数据库表的调优感觉没什么意义。

jbpm4方面主要是引入了history历史库的概念，把运行库与历史库分隔开来，避免因为流程数据库的不断积累影响流程引擎的运行效率。

这个可以归入工作流异常处理，任务超时交由系统重新分配工作项，或者直接通知给案例负责人。

另外，工作流系统需要支持工作交接和委派，这个在资源模式里都有。

估计中国国内的JBPM应用和其它流程系统的设计水平恐怕把JBOSS那边还高，光看这些讨论就会有这种感觉，这还不包括国内的其它流程框架的应用和设计，学院里面的那些设计。。。好一派繁荣景象。。。。

xyz20003兄有时间的话测试下jbpm结合mq使用的效果如何，
将历史数据分开存放对性能的提升是有帮助的。

工作交接，好主意，呵呵