对于参与者,有以下几种:
流程参与者包含以下三种类型:
- Creator:流程的创建者
- Agent:流程创建的代理者
- CurrentUser:当前用户
通过指定某个系统用户的登录帐号来指定某个环节的参与者。
通过指定角色名称来获取该角色的所有成员。具体的某个角色都是属于其中一个部门的,如:开发服务部的“经理”角色,行政部的“经理”角色是有区别的,所以在指定角色参与者的时候都需要指定一个基准用户,通过该用户所在部门来求解出该部门的对应角色成员。也可以通过指定部门名称(DeptName)来获取该部门的对应角色成员。
通过指定环节名称来获取参与过该环节的用户。
注意:只有参与了该环节并且自己完成了的用户才能被求解出来。
很多情况下,在处理业务表单时,业务表单上已经包含了下一环节的参与者的信息,如:出车单上面指定了出车司机信息,这时候只需要指定环节参与者为业务数据参与者,流程核心就可以将该用户求解出来。
如果工作流的表单数据包含了复杂应用,用户信息存放于XML数据中,则可以使用XML参与者。
流程中经常会出现当前的环节参与者指定后续环节参与者的情况,尤其是OA类型的应用。如果流程出现这种情况时可以使用用户选择参与者,其中InnerUser的指定是供用户选择的范围。
通过Python脚本求解参与者,便于求解需要通过业务判断才能决定的参与者列表。
使用SQL语句直接访问数据表,求解出所需的参与者。
对于迁移,有以下几种:
可以在基本迁移上面绑定任何支持的条件类型以使工作流在运行时判断迁移是否成立。
为了设计方便,选择迁移只是在基本迁移上面默认绑定了选择条件而已。具体用途请参照“选择条件”。
在设置迁移条件时可以根据需求灵活设置是否回退选项,以便在流程流转过程中,根据流程要求,选择将流程回退到上一步骤。
对于条件,有以下几种:
最常用的条件类型,因为工作流里面常用到的流程分支,某个环节的判断结果不一样就会影响后续环节的走向,如:某个审批环节同意走向结束,不同意打回到开始。
使用环节条件可以由两种方式,一种就是判断环节结果,另外一种就是使用CheckFinish属性,判断某个环节是否执行过。
XML条件适用于各种复杂的计算,当流程绑定的业务数据或者参数是XML数据时,可以通过指定XML的XPath来计算。从而计算出条件是否成立。
在流程中有时候需要用户选择下一步的走向时,通常会在UI中列出当前环节所有的后续环节以供选择,UI层会将用户选择的值放置于Choice的流程参数中。选择条件,就是通过该参数来判断条件是否成立的。
当业务数据绑定的是ADO .NET的DataSet的时候我们可以通过计算某个数据表中的某些数据是否大于等于某个固定的数据值来判断条件是否成立。
如果业务数据绑定的不是一个DataSet而是某个对象(常见于各种ORMapping的系统),这时候就可以使用对象属性条件来直接通过比较该对象的某一属性来判断条件是否成立。
通过Python脚本计算条件是否成立,用于较复杂的条件判断。
复合条件可以看作为一个条件的容器,通过与和或的关系,组合不同的条件以实现复杂的条件计算。
好了,流程的所有元素就大概介绍到这里吧。从以上各元素的丰富的类别,其灵活性可略见一斑!能支持的业务系统可以说包罗万象,从一般的OA系统,到流程超级复杂的业务系统都能提供很好的支持。另外,上述流程的四大元素均提供可扩展性,如果仍无法满足特定需求,还可自己扩展自定义的环节、参与者、迁移、条件等,这是很多国内的工作流产品所无法比拟的!详情请看高级扩展篇。