|
锁定老帖子 主题：jbpm3与jbpm4实现对比
该帖已经被评为良好帖
|
|
|---|---|
| 作者 | 正文 |
|
发表时间：2009-02-18
left405 写道 请问 jbpm3 还没有搞得非常明白, 就去看jbpm4 合适吗
应该没问题，两者差别比较大！ |
| 返回顶楼 | |
|
发表时间：2009-02-19
147175882 写道 snowfox2008 写道 5、历史库的加入
jBPM3中数据库设计一直是我比较诟病的地方，尤其是其实例数据库没有设计历史库的概念并按照办结状态将运行结束的实例数据归入历史库，在这种情况下它的实例数据库就会随着时间而无限膨胀，这就阻碍了它的真实应用，而在jBPM4的最新代码中（注意Alpha1还没有出现），历史库的相关功能代码竟然出现了！详见ExecutionImpl最新代码中的fireHistoryEvent方法及一系列的historyXXX方法。在ActivityBehaviour的execute方法中加入了historyTaskStart方法的调用、signal方法中加入了historyTaskEnd方法的调用，而以上2个方法在ExecutionImpl中都是以历史事件（HistoryEvent有4个实现子类ProcessInstanceStart、ProcessInstanceEnd、ActivityStart、ActivityEnd分别用作流程实例的创建结束期、活动实例的创建结束期的历史数据处理）的触发机制来实现的，也就是在整个流程实例执行的过程中，都加入了对将运行数据存入历史库的历史事件（HistoryEvent）的触发。这样实例列表的查询可以只查询历史库。不过这里很遗憾的是，这个事件没有同时清除运行库的数据，这样还是会造成运行库的无限膨胀问题。 大家对此的意见呢？ 个人觉得这是个比较鸡肋的功能,因为当一个流程结束后,如果把数据放进历史库那么会存在很多问题,因为一个实际的生产流程往往很复杂,当一个流程结束后,会在很多jbpm自带的表里面会生成很多数据,随随便便就可以上百条都是可能的.这时,如果要在流程结束时同步插入到历史表且删除现行表中的相关数据会是一个很复杂的功能,(比如说:表之间都是建了关联的,不管是插入还是删除都要注意顺序问题,而且表中如果建了索引的话,增删都相对慢).当然如果不出问题的话,这样也行.但如果删除数据过程中出现了异常,可能就是个很棘手的问题,1事务要不要回滚,事务的粒度怎么定位,换句话说,要不要把用户的操作也回滚掉.2回滚事务的话,数据是不会被删的(因为事务回滚),那么怎么通知系统下次删除这批数据. 当然问题可能更多,我觉得jbpm开发人员不做这些处理不是因为他们没想到,可能只是把jbpm定位在一个插件或挂件级别.不好做处理. 为了解决这个问题,以前我们项目组就采用了异步的方法.用quarz做了个定时任务,定时归档已经处理完的任务,也就是插入到历史表且删除现行表的相关数据. 个人感觉,即使jbpm4也很难从本质上解决楼主所说的这个问题. 呵呵，不错！不过如果jbpm4不解决这个问题，那么它还是一个中看不中用的引擎，那么就必须由项目的开发人员去做这件事，就像你们用quartz处理一样。其实复杂不复杂还是在于实例数据之间的关系，jbpm的数据库表个人一直认为太过于复杂，不过对于基于orm来实现持久层的产品来说，实现起来就要简单一些，因为po之间的关系已经由orm工具维护好了（例如流程实例就是所有其它实例的祖父，删除所有实例时，只对流程实例做操作就可以了，不会像您所说的要处理关系什么的），至于工作流实例本身的事务也不用担心，而对于业务数据也不需要处理，只要业务数据和工作流实例数据有一个唯一的关联关系就可以了，移到历史库关系不会做改变。 最后要说明的是，这个归入历史库，清除运行库的操作，在流程结束时去触发一个异步的事件，由这个异步的事件来干这件事，这样就不会影响流程的最后一个用户的体验了。而对于索引问题，这时运行库就会稳定一个数量级上基本上就不会变化，因此运行库就没有必要建索引了。而历史库肯定需要建索引（因为主要用来查询），但是对于历史库的查询，在真实的业务系统中，使用的频率本身就很低，所以影响也不会很大。 |
| 返回顶楼 | |
|
发表时间：2009-02-19
有没有简单的demo
|
| 返回顶楼 | |
|
发表时间：2009-02-23
ynstudio 写道 高手！
我也在研究jbpm4。我们的工作流就基于jbpm4来做的，不过现在才开始流程管理之类的功能的开发。 jbpm的alaph版本你们也敢用？ 你们的基于jbpm4是做实际项目还是只是作为研究的项目？ |
| 返回顶楼 | |
|
发表时间：2009-02-23
147175882 写道 snowfox2008 写道 5、历史库的加入
jBPM3中数据库设计一直是我比较诟病的地方，尤其是其实例数据库没有设计历史库的概念并按照办结状态将运行结束的实例数据归入历史库，在这种情况下它的实例数据库就会随着时间而无限膨胀，这就阻碍了它的真实应用，而在jBPM4的最新代码中（注意Alpha1还没有出现），历史库的相关功能代码竟然出现了！详见ExecutionImpl最新代码中的fireHistoryEvent方法及一系列的historyXXX方法。在ActivityBehaviour的execute方法中加入了historyTaskStart方法的调用、signal方法中加入了historyTaskEnd方法的调用，而以上2个方法在ExecutionImpl中都是以历史事件（HistoryEvent有4个实现子类ProcessInstanceStart、ProcessInstanceEnd、ActivityStart、ActivityEnd分别用作流程实例的创建结束期、活动实例的创建结束期的历史数据处理）的触发机制来实现的，也就是在整个流程实例执行的过程中，都加入了对将运行数据存入历史库的历史事件（HistoryEvent）的触发。这样实例列表的查询可以只查询历史库。不过这里很遗憾的是，这个事件没有同时清除运行库的数据，这样还是会造成运行库的无限膨胀问题。 大家对此的意见呢？ 个人觉得这是个比较鸡肋的功能,因为当一个流程结束后,如果把数据放进历史库那么会存在很多问题,因为一个实际的生产流程往往很复杂,当一个流程结束后,会在很多jbpm自带的表里面会生成很多数据,随随便便就可以上百条都是可能的.这时,如果要在流程结束时同步插入到历史表且删除现行表中的相关数据会是一个很复杂的功能,(比如说:表之间都是建了关联的,不管是插入还是删除都要注意顺序问题,而且表中如果建了索引的话,增删都相对慢).当然如果不出问题的话,这样也行.但如果删除数据过程中出现了异常,可能就是个很棘手的问题,1事务要不要回滚,事务的粒度怎么定位,换句话说,要不要把用户的操作也回滚掉.2回滚事务的话,数据是不会被删的(因为事务回滚),那么怎么通知系统下次删除这批数据. 当然问题可能更多,我觉得jbpm开发人员不做这些处理不是因为他们没想到,可能只是把jbpm定位在一个插件或挂件级别.不好做处理. 为了解决这个问题,以前我们项目组就采用了异步的方法.用quarz做了个定时任务,定时归档已经处理完的任务,也就是插入到历史表且删除现行表的相关数据. 个人感觉,即使jbpm4也很难从本质上解决楼主所说的这个问题. 我也那么认为，历史数据可以作为时候备份的机制来处理，如果jbpm4支持可以配置的备份机制，否则还是在实际应用中根据需求来进行选择备份。 |
| 返回顶楼 | |
|
发表时间：2009-04-25
我们系统现在每天要启动5万左右的流程单子，都是流程归档时移入历史表中。
|
| 返回顶楼 | |
|
发表时间：2009-06-09
请问下，流程审批人撤回操作支持吗，也就是说他刚批完，流程转到了下一步，突然发现自己批错了，想撤回来重新批，这时的逻辑如何处理（可能他刚才的审批时执行了动作，比如金额加了100等），谢谢高手回答，呵呵
|
| 返回顶楼 | |
|
发表时间：2009-06-09
melin 写道 我们系统现在每天要启动5万左右的流程单子，都是流程归档时移入历史表中。
是用jbpm吗？？ |
| 返回顶楼 | |
|
发表时间：2009-06-15
我现在用的CR1,问题也很多，有很多examples流程中的element在jpdl-4.0.xsd根本没有定义，现在在查原因。。
|
| 返回顶楼 | |
|
发表时间：2009-10-12
是哦， jbpm4 实现方式看起来复杂了，，给用户（程序员）的方面则简单了不少，，也更好处理咯。。
|
| 返回顶楼 | |
