前言：

在BPM领域支持流程运转的理论模型有多种。有的21种、28种。32种。

每种模式都代表了这样的模式的理论设计者研究者的人员主张、思想。这些模式尽可能的，全然去覆盖到现实生产、工作、应用上的流程流转规则。

可是不论什么领域都有自己未探索到的流程运转可能，假设说自己的理论可以涵盖全部的应用需求，那就说的有点太早。

就类似于世界上的教派或者哲学家一样。不同的教主与哲学家有不同的世界观。不同的世界认识，都对自己的“追随者”来宣扬自己的主张、观点，可是他们也能“和谐”相处，对于同一个事物都有自己的观点，也有同样的认识，同一时候也有自己的“理论”解释不了的事物。

这篇文章介绍了Ccbpm的流程的4大执行模式。以及是怎样支持各式各样的流程变化。

 

Ccbpm控制流程执行模式的方式：

Ccbpm使用节点模式、流程属性、节点属性来控制流程运转规则，以不不变应万变的方式来应对各种生产、管理模式下的流程运转须要。

Ccbpm的概念比較简单easy理解。它有4大执行模式。各自是线性流程、同表单分合流、异表单分合流、父子流程。

节点类型：普通节点、分流节点、合流节点、分合流节点、子线程节点。

节点多人处理模式：抢办模式、协作模式、队列模式、共享模式。

 

与父子流程相关的一些属性控制等等，例如以下图。

Ccbpm 的4大流程运转模式的解释：

     线性流程：在统一个时间点，仅仅有一个活动的节点，每一个节点都依照一定的步骤，一定的顺序就执行。在特定的节点同意跳转、同意自己定义以后的流程执行步骤。我们把这种流程称为线性流程，也叫顺序流程。

在一个系统中大约85%以上的流程，都是该类流程。

自由流程：

同表单分合流：ccbpm的强大在于ccbpm集成了ccform。流程与表单是相辅相成的。就好像一个火车头与车厢的关系，同表单的分合流，就是一个节点上能够存在多个活动的线程，线程与处理人是1对1的关系。每一个处理人的内容都是一样的。所以我们成为同表单的分合流。

例如以下图：

异表单分合流：假设您了解了同表单的分合流。就不难了解这个流程模式的概念了。

例如以下图：

父子流程： 父子流程，就是在一个流程A的一个节点上，能够启动另外的一个流程B，当前的流程我们称为父流程，被启动的流程成为子流程，假设子流程B的一个节点上启动另外一个流程C，那末B流程与C流程就是父子流程， A 与C就是爷爷与孙子关系。可是ccbpm不研究跨界关系。只研究相近的两个流程之间的关系。

比方：一个project类的流程。调用施工流程、与催款流程。例如以下图：

节点多人处理工作模式：

     具体文档地址：http://jflow.mydoc.io/?v=5404&t=17947

     多人待办工作处理模式，也是待办处理模式。是当接受的节点是多个人的时候，怎样处理待办？

依据不用的场景。ccBPM把多人在普通节点下的处理模式分为例如以下几种。

抢办模式:

A发送到B ，B节点上有n个人能够处理。这n个人都能够看到待办，当当中一个人处理后。其它人的待办就消失了。这种工作模式属于抢办，这n个人能够同一时候打开，当一 个人发送后，其它人都不能在发送了。

通俗的说，也就是谁抢到了这件工作，就是谁处理的。

抢办模式是一个默认的处理模式。

协作模式:

A发送到B ，B节点上有n个人能够处理。

这个n个人都能够去处理，都能够去发送，有最后一个处理人发送到下一个节点上去，这n个人的处理不分顺序。这种模式我们叫做协作模式。

协作模式通经常使用在具有审核组件的表单中。每一个人都能够填写自己的意见。发表自己的看法，在审核组件里审核每一个人在一个节点上仅仅能写入一条数据。也就是说仅仅能表达一次意见。

也经经常使用在传阅的情况下，必须这些人都读取了，知道了才干向下运动。

它与抄送不同的地方是。抄送能够不看，就能够向下执行，可是他必须处理才干向下执行。

通常的协作模式，就是多人都要点击一下发送功能button，来确认自己处理了，确认自己允许了或者认可了。

队列模式:

A发送到B 。B节点上有n个人能够处理。这个n个人依照设置的先后顺序去处理，在同一个时间点必须有一个人待办。其它人看不到。

应用场景: 一个公文发送给一个部门。该部门下n个人能够接受（注意这是一个节点），依照国内的行政制度，这n个人会从小到达排一个队列，有最小的级别的工作人员审 批。然后依次类推，走到最后由最后一个人发送到下一个节点去。这n个人都是该节点的处理人，这n个人的审核步骤是由他们的顺序确定的。所以在设置该节点的接受人时，要依照顺序运行。

通常这种模式也与审核组件一起使用。每一个人表达意见后。就发送到下一个节点。当然这种模式也

共享模式:

A发送到B ，B节点上有n个人能够处理。

ccBPM有一个任务池。这写人都须要从这个任务池里获取。

　　关于对ccBPM任务池的描写叙述：

　　１。在流程属性与全局配置设置了启动任务池的状态下，假设一个节点遇到多个人处理，这个任务就放在了任务池里，仅仅有參与处理的人人员才干看得到。

　　２，工作人员在处理该工作之前须要申请。放到自己的代办里。一人申请之后，其它人就不能申请了，多个人同一时候申请第一个人申请的先得到。

　　３。申请之后，任务池里就不出如今条工作而是进入了被申请人的待办里。

　　４。假设申请人处理不了这件工作，他能够把该工作放入任务池中，放入任务池的工作能够被其它的Ｎ个人能够看到。

　　５。无论取回与放入，都须要写入流程日志。

　　6。任务池的设计：　　

　　１，在流程引擎控制表 WF_GenerWorkFlow 中添加了例如以下字段: 　　　　 TaskSta,　枚举类型。 0=不启用，1=共享，2=被申请。

　　　　TodoEmpsNum, Int类型，处理人员数量。当前节点工作有多少人待办，假设此值大于等于２，讨论共享任务才有意义。 TodoEmps varchar(500) 待办人员,格式为　处理人员编号，处理人员名称；　比方：guobaogeng,郭宝庚;fuhui,福惠;　　　　　　

　　２，在流程引擎控制表的人员列表中　WF_GenerWorkerList 中对于IsEnable字段,进行扩充了。假设等于　-1=任务池禁用。０＝分配工作被屏蔽，１＝正常。 　　　３，添加了一个功能界面　/WF/TaskPoolSmaller.aspx 次功能界面是有在任务池启用才干被使用。

　　４，在流程属性里添加一个字段　IsEnableTaskPool 是否启用任务池？　此字段用来控制该流程是否启用任务池。

　　任务池的ＳＤＫ接口：

　　１。获得共享任务：　DB_TaskPool

　　２，获得共享任务中我的待办：DB_TaskPoolOfMy

　　３，从共享任务中取回：Node_TaskPoolTakebackOne

４，把取回的共享任务放入任务池：　Node_TaskPoolPutOne

 

综述：一个好的工作流引擎。一定是与业务接地气的引擎，一个好用的流程引擎应用在MIS系统上，一定是与表单引擎结合的引擎。流程在运动过程中能够操纵表单数据的处理。

您假设对CCBPM感兴趣。

请关注微信获取源代码：