驰骋工作流引擎设计系列08 接收人规则设计

第1节.关键字
驰骋工作流引擎 流程快速开发平台 workflow ccflow jflow

第1节.接收人规则设计

接收人员规则是节点属性的一个重要设置,是确定当前接受人范围的规则,该规则有多种方式组成。

1.1.1:概要说明

关键字:ccbpm节点访问规则 接收人规则。
相关功能:访问规则处理内容。
节点属性配置:如下图:
在这里插入图片描述

功能入口
解释说明:就是下一步工作人员的接受人范围处理规则。A运动到B,如何确定B的处理人范围。根据不同的业务场景,ccbpm提供了如下几种模式,您可以根据自动不同的业务背景设置自己的业务规则。
说明:
1, 下列设置类型,都设置当前节点作用于下一步节点。
2, 每一种类型,都有路径自动记忆功能,所说自动记忆功能是当节点第一次向下一个节点投递时,它把要投递的人记录下来。
如果您执行了分配系统就把分配的人员,做为接受人员计算.
可以设置的投递的类型:
为了更好的说明该规则,cc为我们提供了一个流程测试案例,如下图:
在这里插入图片描述

该案例详尽的设置了各个模式的方法,请打开相关的节点属性,对照节点的名称,运行该流程。

1.1.2:属性字段存储

该规则是一个节点字段属性,当然要存在节点表里,WF_Node

在这里插入图片描述

1.1.3:开始节点的接受人规则设计

开始节点是一个特殊的节点,是整个流程的入口,一个流程只有一个开始节点。
开始节点的访问规则是为了确定那些人可以发起该流程。
开始节点的访问规则与其他节点也不相同,如下图。
在这里插入图片描述

我们从规则名称的字面意思不难理解,如何为开始节点绑定可以发起的工作人员。

1.1.4:中间节点的接受人规则设计

1.1.4.1:按组织结构结算
本章节详细的介绍了每种访问规则在不同场景下的应用,用户可以根据不同的情况使用不同的访问规则。
1.1.4.1.1:按岗位智能计算
设置方法: 在下一个节点上的节点属性里,设置节点岗位。这是默认的投递规则,他是在下一个节点设置岗位时按照岗位计算. 他的计算方式,首先按照当前操作员的部门范围计算。如果该操作员部门下没有这个工作岗位的人员,CCBPM就会把当前操作员的部门级次提高一个级别,在寻找,依次计算。理解了这个算法,您就不难理解为什么,本部分的业务,只能让本部门的经理审批了.
在这里插入图片描述

举例说明:一个省机关下面有n个县,n个市,n个县. n个所. 一个所员受理人员的业务,只能让自己的所长审批,所长的业务只能投递到本区县的相关业务部分审批,而非其它区县业务部分审批。
这就是岗位的权限与部门权限的交叉形成的被投递的人员集合. 这就是ccbpm经常说的。
岗位:表示能做什么事情。部门: 表示能做那里的事情。岗位+部门: 表示一个操作员能做那里的那些事情。
1.1.4.1.2:按节点绑定的部门计算
设置方法:在当前节点上的节点属性里,设置节点岗位.
CCBPM会按照您指定的部门下面的人员,进行投递, 就是这个n个部门下面都可以接受这个工作. 这个类于发送邮件的按照邮件组进行发送。
在这里插入图片描述

1.1.4.1.3:按节点绑定的人员计算:
节点绑定那些人员,该系统就会发送给这些人,如下图设置。
在这里插入图片描述

1.1.4.1.4:按绑定的岗位与部门交集计算
设置方式:在节点岗位,节点部门都设置。
运行方式:ccbpm会取既具备此岗位集合的又具备此部门集合的人员,做为本节点的接受人员。

在这里插入图片描述

1.1.4.1.5:按绑定的岗位计算并且以绑定的部门集合为纬度
该场景用的较少,不说明了。
1.1.4.1.6:按指定节点的工作人员或者指定字段人员的岗位计算
应用场景:为一个单位设置一个设备维修流程,此单位下分好多部门,有一个IT部门负责计算机设备维修。每个部门的成员如果有设备维护的需要,首先填写一个单子向这个IT部门的受理人员发送详细的故障说明。IT受理人员接受到此请求后,根据情况发送到该发起人的部门领导那里去。
这是简单的三个步骤,发起-》IT部门受理-》发起的部门负责人审批。第一步骤基层人员发起,第二步骤是IT受理岗人员受理。第三个步骤中层领导审批。在第三个节点访问规则就是按按指定节点岗位计算。因为如果按岗位计算在第二步骤就要发送给IT部门经理审批而非发起人的部门经理审批了。默认的按岗位计算就是按上一个节点的岗位计算,现在的应用场景就是要按指定的节点岗位计算了。
设置方式:在接受对象中设置一个节点编号比如:101。
运行方式:ccbpm在处理接受人时,会按指定节点上的人员身份计算,而非按上一步骤的人员身份计算了。
其它:这种方式是对按岗位计算的补充。
变更记录: 2015/10/8为了适应能够按指定的表单字段作为人员,特支持为,也可以指定一个表单字段作为处理人。
对于原来设置节点的方式也有效,如果设置一个字段名称,ccbpm就从表单字段取值作为接收人。
1.1.4.1.7:仅按绑定的岗位计算
按照节点上绑定的岗位来计算接受人,这里去掉了部门维度的过滤。
1.1.4.2:按指定节点处理人
1.1.4.2.1:按上一节点表单指定的字段值作为本步骤的接受人
设置方式: 在当前节点属性访问规则处理内容中指定此方式,在上一个节点的表单上添加一个SysSendEmps的文本框。
运行方式: 在用户填写上一个步骤的节点表单时,这个指定的字段可以用逗号分号分开,可以输入多个接受人员的编号。下一步的接受人员就按用户输入的内容结束。
说明:这种方式就类似于发送邮件。
1.1.4.2.2:与上一节点处理人员相同
节点A是甲处理,发送到节点B,也是需要甲处理。
1.1.4.2.3:与开始节点处理人相同
当前节点的处理人与开始节点一致,发起人是zhangsan,现在节点的处理人也是他。
1.1.4.2.4:与指定节点处理人相同
应用场景1:A B C 三个节点, B向C发送时C的接受人员要求与A的工作人员一致。
设置方式: 在[访问规则处理内容]中设置一个节点ID比如:101。
应用场景2:如下图,当一个节点可以多个节点可以到达时,在【访问规则处理内容】需要配置多个节点的ID值,如下图:
在这里插入图片描述

节点3,可能是从节点1,或者节点2转到节点3,如果在节点3上配置此规则就要配置节点2节点1的两个节点ID,用逗号分开,例如: 507,509。这种情况下ccbpm就会自动判断节点3究竟是从那个节点上过来了,从而把处理人投递给节点3。
对父子流程的支持:
2015年1月28日为珠海高凌变更:如果是父子流程,在子流程上的一个节点要指定与父流程的一个节点的人员相同,配置方式不变化。
比如:父亲流程甲,调用子流程乙,在乙的一个节点上的工作处理人员与甲的一个节点处理人员相同,那就在该参数里设置甲的节点编号,可以是多个变化,如果甲是一个子线程也同样支持。

1.1.4.3:按自定义SQL计算

1.1.4.3.1:按设置的SQL获取接受人计算
按SQL计算通俗好理解,就是ccbpm在执行一个查询sql时,返回一个数据源,在数据源里约定该节点的接收人信息。
设置方法: 在当前节点属性里 [接受人SQL]设置一个sql 语句. 这个select 查询语句有一个列. No 分别表示,操作
编号, 操作员名称. 这个sql可以有参数.
比如: 1, SELECT No,Name FROM PORT_EMP WHERE FK_Dept=@WebUser.FK_Dept
查询出来当前操作员中的部门下的所有人员.
2, SELECT xxx as No, yyy as Name FROM dbo.xxxx.YourTable WHERE 字段名称=@表单字段名称.
从您的业务系统中,查找一组人员,变量可以是当前节点字段的编号,格式为 @+字段英文名称.
关于合流点的接受人按sql获取接受的表达式的问题
注意子线程向合流点发送时,接受人规则的表达式的变量是临近合流点的子线程节点变量。
比如: 流程编号为ABC三个节点.
A 是分流点,B是合流点 C是子线程。
如果C的接受人员规则是按sql计算:
配置的表达式如下表达式是错误的:
select UserNo as No, xx as Name from ND2701 WHERE OID=@OID
如下表达式才是正确的:
select UserNo as No from ND2701 WHERE OID=@FID
这是因为子线程在发送时获取的变量OID 是子线程的ID而非,干流上的WorkID.
关于子线程接受人的特殊约定:
如果遇到分组的维度,就约定返回4个列来解决问题,流程demo:\流程树\同表单分合流\一人多子线程模式(批次维度任务模式)流程.
在第2个子线程节点配置了如下SQL。
在这里插入图片描述

该数据源返回了三个列,分别是:No,Name, GroupMark
No=操作员编号,Name=操作员名称, GroupMark就是分组的维度.
比如配置的SQL: SELECTNo,Name,FK_DeptFROMPort_EmpWHEREFK_Deptin(‘2’,‘5’)

应用场景: 有一批物品需要化验,一个人员可能需要承担多个化验项目,这就需要这个人在这个子线程里有n件工作。再比如:一件工作需要下发两个部门处理,如果一个部门的一个人处理了,另外该部门的人员的工作就要自动去掉,属于抢办任务,也就是说,子线程也需要抢办任务。

对动态表单树的支持:
什么是动态表单树?请参节点属性、表单、表单类型章节。简单的说,该节点的表单是有上一步发送人员动态指定的。该节点大部分是子线程节点,也可以是多人处理的普通节点。
应用场景:a节点发向b节点,张三需要分配给,甲乙丙丁四个人去工作,但是这四个人工作内容不同。虽然甲乙丙丁四个人都可以接受到该节点的工作,但是填写的内容是由张三动态的分配的。
我们就要在这里约定数据源来表达接收人的信息,第一种情况没有批次号:返回的列需要有如下要求,No,Name,FrmIDs 第3列是表单ID,多个表单ID用逗号分开。
第二中情况具有批次号:需要返回的列是, No,Name,BatchNo,FrmIDs.
Ccbpm为该种应用场景做了一个demo,请参考:

在节点2属性里我们做了如下设置

实现步骤:在开始节点里ccbpm的节点表单里设计了一个明细表。

1.1.4.3.2:按SQL确定子线程接受人与数据源

此方法与分合流相关,只有当前节点是子线程才有意义。

  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值