Tom就是我了,zmyliyu是一位研究JBPM的网友
zmyliyu Tom 问一个问题,一个审核的TASKNODE审核不通过后,可以直接返回以前的TASKNODE么
Tom zmyliyu 如果你需要审批不通过返还的话,那么你应该有一条从审批Node--〉递交审批Node的路径transition
zmyliyu Tom 是,这个没有问题。
zmyliyu Tom 原来的TASKNODE是不是就会生成一个新的TASKINSTANCE呢。
Tom zmyliyu of cours
Tom zmyliyu e
zmyliyu Tom 恩,好的。
zmyliyu Tom 你好,忙不忙呀。
Tom zmyliyu ??
zmyliyu Tom 我象问几个JBPM方面的问题。
Tom zmyliyu 你说
zmyliyu Tom 就是setPooledActors你门用了么。
Tom zmyliyu yes
zmyliyu Tom 是怎么使用的呢?
zmyliyu Tom 我觉得对于角色的来说,这是个好办法。
Tom zmyliyu 其实如果你是使用自己的用户模型的话,PooledActors既可以是你的用户,也可以是用户角色,这个取决于你想如何去用
zmyliyu Tom 还有一种想法,就是只用ACTORID来做。
zmyliyu Tom 因为任务最后都要落实到人的。
zmyliyu Tom 不是使用:PooledActors
zmyliyu Tom 任务授权的确是一个比较麻烦的事情。
Tom zmyliyu yes,你说的很多,在分配任务的时候用pooledactors,这样可以保证任务的1:n的分配,但是在真正执行任务的时候,用actor这个用可以保证任务完成得唯一性(除了会签)
Tom zmyliyu 你说的很对
zmyliyu Tom 对了。如何将TASK与功能也面对应起来呢。
Tom zmyliyu 这个也是一个比较棘手的问题,我是使用自定义表,然后把task和表单(处理action)建立关系
zmyliyu Tom 恩,我也是这样想的,但是,具体的业务信息怎么办呢。
zmyliyu Tom 比如,我一个采购流程的处理。
zmyliyu Tom 我需要连接功能,同时需要知道表单号
Tom zmyliyu hoho,你说的是把每一个订单和你的订单流程关联起来吧?
zmyliyu Tom 其实是一个定单呵一个定单的流程实例关联起来。
Tom zmyliyu yes,订单和流程实例关联起来
Tom zmyliyu hoho
zmyliyu Tom 如:一个采购人员填写,这个是一个节点,关联到采购单填写PAGE;然后交审核 ,审核人员从任务列表里头,只能看到TASK,但是不知道这个采购员填写了哪个单据。
zmyliyu Tom 这怎么办呢。
Tom zmyliyu 我现在有3种,两类方法来处理这个问题
zmyliyu Tom 往不吝赐教呀。
zmyliyu Tom 望
Tom zmyliyu 其实最简单的就是在你的单据表添加一个字段,用来在你启动流程的时候,把流程实例ID纪录下来,这样你就可以知道单据在哪里了。不过这样就是耦合高了点,让流程和订单细节联系到一起了
zmyliyu Tom 恩,是的。但是这个是必然的。也是合理的。
zmyliyu Tom 还有更好的办法么。
Tom zmyliyu 当然,你还有另外一个办法
zmyliyu Tom 不过,审核人员怎么知道我审核的是哪个定单呢。
Tom zmyliyu 这个方法应该会比较好一点,耦合小一些
zmyliyu Tom 因为审核的TASK和填写的TASK是不一样的。
zmyliyu Tom 恩。还有什么方法呀。
Tom zmyliyu 先回答你上面一个问题,你做的关联是processInstanceId和订单Id,所以这个跟哪个task没有关系,只要是同一个ProcessInstance就可以了
zmyliyu Tom 哦。 这个是可以的。
zmyliyu Tom ProcessInstance里头去配置一些自己的表,因为我觉得去设置一些流程变量的话,不便于以后升级。
Tom zmyliyu ?
Tom zmyliyu ProcessInstance里头去配置一些自己的表?什么意思
zmyliyu Tom 就是建立一个自己的表,和ProcessInstance做关联,存储一些流程公用信息。
Tom zmyliyu 嗯,是这样
Tom zmyliyu 不会给升级带来什么麻烦啊
zmyliyu Tom 恩。现在也只能那么处理了。
Tom zmyliyu 不然,还有一个办法,就是所以的信息都用流程变量来保存,这样就不用见表了
zmyliyu Tom 是的。但是这样就可能增加了系统偶合。
zmyliyu Tom 毕竟这个是流程相关数据,和流程本生来说没有关系。而且偏应用数据。
Tom zmyliyu 你要把订单和流程实例联系在一起,本身就是一种耦合,如果不然,就成了两个没有关系的东西了,适当的耦合是必须也是必要的
zmyliyu Tom 所以,个人认为建立表比较合适,如果要影响流程流转的,考虑用变量方式去处理比较合适的。
zmyliyu Tom 对。就是一些接口处理的。
Tom zmyliyu 嗯,我现在就使建表的
zmyliyu Tom 我现在正在设计表。呵呵。
zmyliyu Tom 现在正头痛呢。
zmyliyu Tom 对了。我不想使用POOLEDACTOR,感觉那个东西把事情搞麻烦了。
Tom zmyliyu hoho,是阿,有很多的细节的问题需要考虑。我现在也还有很多的细节要处理
zmyliyu Tom 因为分派任务来说,最后一定是给一个人处理。
Tom zmyliyu 但是如果你不用的话,你就不能实现用户和任务N:1的关系。
zmyliyu Tom ACTORID可以存放角色信息。然后通过角色分派给用户来处理。
zmyliyu Tom 可以的。
zmyliyu Tom 或则通过用户来获取角色任务。这个问题就解决了。
zmyliyu Tom 一般来说,一个任务不会分给多个角色来处理。
Tom zmyliyu 虽然是一个人处理,但是有可以是N个人都可以处理这个任务,所以,虽然最后都是一个人处理,但是在TaskList中必须要N个人都能看到Task
zmyliyu Tom 恩,是的。这个是没有问题的。可以通过角色列表看到的。
Tom zmyliyu hoho,如果你的系统不存在N个角色处理一个任务的情况,那么你可以只用Actor来处理
zmyliyu Tom 恩,是的。这样我感觉不错的。
Tom zmyliyu 但是你还是必须面对一个问题,就是你如果使用Actor来处理,你必须在一个人完成这个Task的时候,把这个Task的Actor改称实际处理人的userId,而不是角色,否则,你跟踪审批信息的时候,就会有不知道究竟是谁处理了这个Task的麻烦了。
zmyliyu Tom 不过SWIMLANE,的确是一个更为妥善的解决办法的。
zmyliyu Tom 考虑到以后升级,呵呵。JBPM里头的表还真不敢乱放信息。呵呵。
Tom zmyliyu 嗯,我基本是不考虑去改动JBPM自身的表
zmyliyu Tom 我也是的。自己增加表,然后增加补充定义是个好办法。
Tom zmyliyu bingo
zmyliyu Tom ???呵呵。什么意思哦。
Tom zmyliyu yes!好!正确!等等,挺复杂的,就是表示因为做对什么事情而激动
zmyliyu Tom 我现在定义了一部分了。好多问题还在想。
zmyliyu Tom 对了。关于委托,还有就是回退处理,你是怎么考虑的呢。
Tom zmyliyu 会退基本还是使用fork来处理,至于委托,我是想在自己的系统中实现,也就相当于自己定义,实现
Tom zmyliyu 会退基本还是使用fork来处理,至于委托,我是想在自己的系统中实现,也就相当于自己定义,实现
zmyliyu Tom 对的。你提到的,比如审核返回,然后需要返回给处理者本人的。这个也许需要考虑的。很合理,但是不知道怎么实现好。
Tom zmyliyu 恩,这个我已经实现了,hoho,这个主题我会写道blog上面去的,你要是有兴趣,可以去看看,就这两天吧,我就写上去;)
zmyliyu Tom 恩,好的。需要加其他表,么。
zmyliyu Tom 我想联系流程实例ID,然后就是TASKID然后做一个记录,基本就够了。
zmyliyu Tom 但是细节还需要好好考虑的。
Tom zmyliyu 不需要多加表
Tom zmyliyu 嗯,你的思路也可以,不过加太多表也不是个办法
zmyliyu Tom 恩,是的。
zmyliyu Tom 我加了流程分类表。
zmyliyu Tom 然后加了5个左右的表。
Tom zmyliyu 我加了3个
zmyliyu Tom 流程分类你怎么处理的呢。
Tom zmyliyu 不好意思,手头上有点活,下次聊?
zmyliyu Tom 好的。要得哈。
Tom zmyliyu 嗯!下次聊!拜拜
zmyliyu Tom S Y