前言:
在BPM领域支持流程运转的理论模型有多种,有的21种、28种,32种。每种模式都代表了这种模式的理论设计者研究者的人员主张、思想。这些模式尽可能的,完全去覆盖到现实生产、工作、应用上的流程流转规则。但是任何领域都有自己未探索到的流程运转可能,如果说自己的理论能够涵盖所有的应用需求,那就说的有点太早。
就类似于世界上的教派或者哲学家一样,不同的教主与哲学家有不同的世界观,不同的世界认识,都对自己的“追随者”来宣扬自己的主张、观点,但是他们也能“和谐”相处,对于同一个事物都有自己的观点,也有相同的认识,同时也有自己的“理论”解释不了的事物。
这篇文章介绍了Ccbpm的流程的4大运行模式,以及是如何支持各式各样的流程变化。
Ccbpm控制流程运行模式的方式:
Ccbpm使用节点模式、流程属性、节点属性来控制流程运转规则,以不不变应万变的方式来应对各种生产、管理模式下的流程运转需要。
Ccbpm的概念比较简单容易理解,它有4大运行模式,分别是线性流程、同表单分合流、异表单分合流、父子流程。
节点类型:普通节点、分流节点、合流节点、分合流节点、子线程节点。
节点多人处理模式:抢办模式、协作模式、队列模式、共享模式。
与父子流程相关的一些属性控制等等,如下图。
Ccbpm 的4大流程运转模式的解释:
线性流程:在统一个时间点,只有一个活动的节点,每个节点都按照一定的步骤,一定的顺序就执行,在特定的节点允许跳转、允许自定义以后的流程运行步骤,我们把这样的流程称为线性流程,也叫顺序流程。在一个系统中大约85%以上的流程,都是该类流程。
自由流程:
同表单分合流:ccbpm的强大在于ccbpm集成了ccform。流程与表单是相辅相成的,就好像一个火车头与车厢的关系,同表单的分合流,就是一个节点上可以存在多个活动的线程,线程与处理人是1对1的关系,每个处理人的内容都是一样的,所以我们成为同表单的分合流。
如下图:
异表单分合流:如果您了解了同表单的分合流,就不难了解这个流程模式的概念了。如下图:
父子流程: 父子流程,就是在一个流程A的一个节点上,可以启动另外的一个流程B,当前的流程我们称为父流程,被启动的流程成为子流程,如果子流程B的一个节点上启动另外一个流程C,那末B流程与C流程就是父子流程, A 与C就是爷爷与孙子关系,但是ccbpm不研究跨界关系,仅仅研究相近的两个流程之间的关系。
比如:一个工程类的流程,调用施工流程、与催款流程,如下图:
节点多人处理工作模式:
详细文档地址:http://jflow.mydoc.io/?v=5404&t=17947
多人待办工作处理模式,也是待办处理模式。是当接受的节点是多个人的时候,如何处理待办?
根据不用的场景,ccBPM把多人在普通节点下的处理模式分为如下几种。
抢办模式:
A发送到B ,B节点上有n个人可以处理。这n个人都可以看到待办,当其中一个人处理后,其他人的待办就消失了。这样的工作模式属于抢办,这n个人可以同时打开,当一 个人发送后,其他人都不能在发送了。通俗的说,也就是谁抢到了这件工作,就是谁处理的。抢办模式是一个默认的处理模式。
协作模式:
A发送到B ,B节点上有n个人可以处理。这个n个人都可以去处理,都可以去发送,有最后一个处理人发送到下一个节点上去,这n个人的处理不分顺序。这样的模式我们叫做协作模式。
协作模式通常用在具有审核组件的表单中,每个人都可以填写自己的意见,发表自己的看法,在审核组件里审核每个人在一个节点上只能写入一条数据,也就是说只能表达一次意见。
也经常用在传阅的情况下,必须这些人都读取了,知道了才能向下运动。它与抄送不同的地方是,抄送可以不看,就可以向下运行,但是他必须处理才能向下运行。
通常的协作模式,就是多人都要点击一下发送功能按钮,来确认自己处理了,确认自己同意了或者认可了。
队列模式:
A发送到B ,B节点上有n个人可以处理。这个n个人按照设置的先后顺序去处理,在同一个时间点必须有一个人待办,其他人看不到。
应用场景: 一个公文发送给一个部门,该部门下n个人可以接受(注意这是一个节点),按照国内的行政制度,这n个人会从小到达排一个队列,有最小的级别的工作人员审 批,然后依次类推,走到最后由最后一个人发送到下一个节点去。这n个人都是该节点的处理人,这n个人的审核步骤是由他们的顺序确定的,所以在设置该节点的接受人时,要按照顺序执行。
通常这样的模式也与审核组件一起使用,每个人表达意见后,就发送到下一个节点,当然这样的模式也
共享模式:
A发送到B ,B节点上有n个人可以处理。ccBPM有一个任务池,这写人都需要从这个任务池里获取。
关于对ccBPM任务池的描述:
1,在流程属性与全局配置设置了启动任务池的状态下,如果一个节点遇到多个人处理,这个任务就放在了任务池里,只有参与处理的人人员才能看得到。
2,工作人员在处理该工作之前需要申请,放到自己的代办里,一人申请之后,其他人就不能申请了,多个人同时申请第一个人申请的先得到。
3,申请之后,任务池里就不出现在条工作而是进入了被申请人的待办里。
4,如果申请人处理不了这件工作,他可以把该工作放入任务池中,放入任务池的工作可以被其他的N个人可以看到。
5,不管取回与放入,都需要写入流程日志。
6,任务池的设计:
1,在流程引擎控制表 WF_GenerWorkFlow 中增加了如下字段: TaskSta, 枚举类型, 0=不启用,1=共享,2=被申请。 TodoEmpsNum, Int类型,处理人员数量,当前节点工作有多少人待办,如果此值大于等于2,讨论共享任务才有意义。 TodoEmps varchar(500) 待办人员,格式为 处理人员编号,处理人员名称; 比如:guobaogeng,郭宝庚;fuhui,福惠;
2,在流程引擎控制表的人员列表中 WF_GenerWorkerList 中对于IsEnable字段,进行扩充了,如果等于 -1=任务池禁用,0=分配工作被屏蔽,1=正常。 3,增加了一个功能界面 /WF/TaskPoolSmaller.aspx 次功能界面是有在任务池启用才能被使用。
4,在流程属性里增加一个字段 IsEnableTaskPool 是否启用任务池? 此字段用来控制该流程是否启用任务池。
任务池的SDK接口:
1,获得共享任务: DB_TaskPool
2,获得共享任务中我的待办:DB_TaskPoolOfMy
3,从共享任务中取回:Node_TaskPoolTakebackOne
4,把取回的共享任务放入任务池: Node_TaskPoolPutOne
综述:一个好的工作流引擎,一定是与业务接地气的引擎,一个好用的流程引擎应用在MIS系统上,一定是与表单引擎结合的引擎。流程在运动过程中可以操纵表单数据的处理。
您如果对CCBPM感兴趣。请关注微信获取源码:
版权声明:本文为博主原创文章,未经博主允许不得转载。