工作流设计Word格式.docx
《工作流设计Word格式.docx》由会员分享，可在线阅读，更多相关《工作流设计Word格式.docx（17页珍藏版）》请在冰豆网上搜索。
}
if（“B”.equals（sts））{
intresult=do业务代码2。
doFlow（“D”）;
if（“C”.equals（sts））{
intresult=do业务代码3。
doFlow（“A”）;
if（“D”.equals（sts））{
业务代码4。
return;
//结束
如上代码所示，复杂的并不是业务逻辑代码，而是代码承担了过多的职责，夹杂了复杂的流程逻辑判断。
显然，我们将这段代码进行职责分离能够降低代码复杂性。
合适的架构来自于Refector，工作流引擎亦来源于流程逻辑从业务逻辑中的分离。
目标明确了，当然我们需要归纳分析具体有哪些流程逻辑，之后才能升华。
抛开工作流、流程、节点、任务等已被定义的概念，按照自己的思路去思考引擎所要解决的系列逻辑问题如下：
Ø
工作流核心逻辑
1）处理先后顺序。
2）谁能处理。
3）是否可以处理了。
4）如何处理。
5）在哪里处理。
6）处理完后如何切换状态。
工作流考虑问题
1）版本问题。
工作流的逻辑是会变化的，自然是老的走老的，新的走新的。
2）每次的处理顺序记录。
需要引入流程定义与实例的概念，显然每次的处理逻辑都可能是不一样的。
3）子流程问题。
父流程，子流程如何交互？
4）聚合分支问题。
5）动态人员分配问题，即无法在流程定义的时候定义谁来处理这个问题，只有在运行时才能确定。
比如考核，只有在运行时，根据被考核人，才能确认它的考核人是谁（被考核人的上级）。
6）流程事件
工作流与应用系统整合的问题
1）如何整合应用系统与工作流系统的权限。
2）如何让用户直接查询到需要处理的流程主体列表，比如合同列表、申请列表等。
3）如何整合应用系统与工作流系统的事务。
4）应用系统与工作流系统如何交互。
基于以上考虑，参考各大流行工作流引擎，我们设计了SevenStarWorkflowEngine
可以说它未必是规范、完美的，但一定是相当实用的，没有丝毫学院派味道。
2引擎模型
图2-1-1引擎模型图
引擎将工作流的定义与运行完全分离，这样可以在运行时改变流程。
Definition
1.流程定义：
功能为区分不同的流程，需要考虑的主要是版本问题，主要属性如下
序号
名称
列名
类型
备注
1
流程名称
id
number（12）
2
流程版本
name
varchar2（200）
3
流程主体类型
mainpart_type
流程处理的主体类型，比如说合同/申请/审批/请假等
2.节点定义：
流程定义与节点定义为1对多关系，节点需要考虑的主要问题
1）聚合分叉，即串并行问题
2）节点执行条件，特殊情况下要考虑节点是否能启动
节点名称
varchar2（100）
显示名称
display_name
4
流程定义
proc_def_id
5
节点类型
type
varchar2（10）
start起始节点
startfork起始分叉
end结束节点
endjoin结束聚合
fork分叉节点
join聚合节点
joinfork分叉聚合
plain普通
6
节点执行条件类型
condition_type
如果是shell，则value为脚本id
如果是action，则为实现类
主要在于实现join的节点，只有判断所有的节点都到了才能执行
7
节点执行条件
condition_value
varchar2（20）
3.任务定义：
节点定义与任务定义为一对多关系，任务需要考虑的主要问题
1）任务的类型，任务可能是表单/工单、动态表单，也可能是java代码、脚本、启子流程等
2）任务可能是必须执行的,也可能是可选的,比如OA中的[办]与[阅]的任务
3）任务的完成,可以执行此任务的可能有多个人员分配,可能中间一个人完成了就可以了,也可能需要所有人一起完成,也可能是认领模式,当然也可能是更灵活的模式
任务名称
任务显示名称
节点
node_def_id
任务类型
action_type
form表单执行（人工任务），填url
dynamic动态表单
action后台任务
shell脚本
subflow子流程
任务值
action_value
varchar2（1000）
看action_type的值
如果是form，则填入表单页面
如果是dynamic，则填入动态表单id
如果是action，则填入实现类
如果是shell，则填入beanshell调用脚本id
如果是subflow，则填入子流程id
是否必须完成
is_must
varchar2
（1）
Y/N
如果必须完成的话，只有完成，节点才能往后走
8
是否必须每个人都完成
is_all
如果必须全部完成，只有分配的人员每个人都完成了，任务才能完成，节点才能往后走
9
是否打开认领模式
is_claim
如果是认领模式，分配人员必须先认领，才能开始做任务
人员分配定义：
即任务上的人员分配定义,哪些人可以执行此任务,需要考虑的问题
1）与现有权限架构的整合
2）运行时才能确认可以执行人员的问题
分配类型
assign_type
user/role/dept/group。
action/shell如果是action/shell的话那就是根据脚本确定执行人，比如人员是根据创建人动态确定的
分配值
assign_value
如果是user，则为user_id
dept则为dept_id
分配名称
assign_name
任务定义表
task_def_id
状态
sts
任务事件定义：
即任务的Action监听事件
事件名称
事件显示名称
事件类型
start/end/error/finally/back
关联类型
target_type
node/task
关联值
target_value
动作类型
action/shell
动作值
4.路径定义：
即节点之间走向,状态切换,主要考虑的问题
1）动态路径问题,即目标节点是运行时确认的
2）路径执行的条件问题,即是否可以走这条路径
节点定义
转移名称
转移条件类型
如果有条件的话，只有满足条件的才能走这条路径
转移条件值
如果condition_type是action，则放实现WokflowAction接口的类路径，如果是shell，放s_flow_script表的id
转移类型
to_type
plain正常的路径
action通过action选择目标路径
script通过脚本选择目标路径
转移值
to_value
如果to_type是plain的话，则为目标路径定义的id，如果是action，则为实现TransitionAction接口的action类路径，如果为script，则为s_flow_script表的id
5.节点事件定义：
即节点的Action事件监听
v
升级会员 