zoukankan      html  css  js  c++  java
  • 驰骋工作流引擎设计系列08 接收人规则设计

    第1节. 关键字

    驰骋工作流引擎 流程快速开发平台 workflow ccflow jflow

    第1节. 接收人规则设计

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

    1.1.1: 概要说明

    关键字:ccbpm节点访问规则 接收人规则。

    相关功能:访问规则处理内容。

    节点属性配置:如下图:

    image

    功能入口

    解释说明:就是下一步工作人员的接受人范围处理规则。A运动到B,如何确定B的处理人范围。根据不同的业务场景,ccbpm提供了如下几种模式,您可以根据自动不同的业务背景设置自己的业务规则。

    说明:

    1, 下列设置类型,都设置当前节点作用于下一步节点。

    2, 每一种类型,都有路径自动记忆功能,所说自动记忆功能是当节点第一次向下一个节点投递时,它把要投递的人记录下来。

    如果您执行了分配系统就把分配的人员,做为接受人员计算.

    可以设置的投递的类型:

    为了更好的说明该规则,cc为我们提供了一个流程测试案例,如下图:

    image

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

    1.1.2: 属性字段存储

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

    image

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

    开始节点是一个特殊的节点,是整个流程的入口,一个流程只有一个开始节点。

    开始节点的访问规则是为了确定那些人可以发起该流程。

    开始节点的访问规则与其他节点也不相同,如下图。

    image

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

    1.1.4: 中间节点的接受人规则设计
    1.1.4.1: 按组织结构结算

    本章节详细的介绍了每种访问规则在不同场景下的应用,用户可以根据不同的情况使用不同的访问规则。

    1.1.4.1.1: 按岗位智能计算

    设置方法: 在下一个节点上的节点属性里,设置节点岗位。这是默认的投递规则,他是在下一个节点设置岗位时按照岗位计算. 他的计算方式,首先按照当前操作员的部门范围计算。如果该操作员部门下没有这个工作岗位的人员,CCBPM就会把当前操作员的部门级次提高一个级别,在寻找,依次计算。理解了这个算法,您就不难理解为什么,本部分的业务,只能让本部门的经理审批了.

    image

    举例说明:一个省机关下面有n个县,n个市,n个县. n个所. 一个所员受理人员的业务,只能让自己的所长审批,所长的业务只能投递到本区县的相关业务部分审批,而非其它区县业务部分审批。

    这就是岗位的权限与部门权限的交叉形成的被投递的人员集合. 这就是ccbpm经常说的。

    岗位:表示能做什么事情。部门: 表示能做那里的事情。岗位+部门: 表示一个操作员能做那里的那些事情。

    1.1.4.1.2: 按节点绑定的部门计算

    设置方法:在当前节点上的节点属性里,设置节点岗位.

    CCBPM会按照您指定的部门下面的人员,进行投递, 就是这个n个部门下面都可以接受这个工作. 这个类于发送邮件的按照邮件组进行发送。

    image

    1.1.4.1.3: 按节点绑定的人员计算:

    节点绑定那些人员,该系统就会发送给这些人,如下图设置。

    image

    1.1.4.1.4: 按绑定的岗位与部门交集计

    设置方式:在节点岗位,节点部门都设置。

    运行方式:ccbpm会取既具备此岗位集合的又具备此部门集合的人员,做为本节点的接受人员。

    image

    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值,如下图:

    image

    节点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。

    image

    该数据源返回了三个列,分别是: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,请参考:

    image

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

    image

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

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

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

  • 相关阅读:
    long和Long的区别
    C语言的变量的内存分配
    Java蓝桥杯 算法提高 九宫格
    Java实现 蓝桥杯算法提高金明的预算方案
    Java实现 蓝桥杯 算法提高 新建Microsoft world文档
    Java实现 蓝桥杯 算法提高 快乐司机
    Java实现 蓝桥杯 算法提高 三角形
    Java实现 蓝桥杯 算法提高 三角形
    Java实现 蓝桥杯 算法提高 三角形
    Java实现 蓝桥杯 算法提高 三角形
  • 原文地址:https://www.cnblogs.com/mengjuan/p/10263154.html
Copyright © 2011-2022 走看看