自定义流程数据结构设计

时间:2024-03-22 08:31:38

结构设计及考虑

自定义流程数据结构设计

图1.

定义流程主要用到3涨表:process,task_node,sequence_flow.

process表:定义流程,主要字段有process_name--流程名,due-date--过期时间,relate-table--关联业务表,

status--状态:状态 1:正在使用 2.未使用(能修改删除)3.挂起(能删除)

task_node表:定义流程节点,一个流程有一个开始节点,一个结束节点及多个任务节点,在任务节点上需要 定义任务执行人。主要字段分析:task_id--任务节点标识,这个字段与主键id起始作用是一样 的,但是我在写新增流程接口的时候需要同时传入流程信息,节点信息和迁移信息,迁移信息中 需要关联起始节点和指向节点,但是直接用任务节点的id是拿不到的因为数据库也还没有,所以 需要有这个字段。task_name--任务节点名,process_id--流程id,流程和节点是一对多的关系 node_type--节点类型:1.任务节点 2.开始节点 3.结束节点 ,因为一个流程只会有一个开始节点 和结束节点,所以可以在表中把这两个节点的两条数据先插入,distribute_type--分配类型: 1.指定角色 2.指定人 3.根据条件指定 4.暂无 会签任务时指定,这个字段有点复杂,1和2不解释 了,根据条件指定,如上图中的流程图,每个员工都能请假,但是请假需要自己部门的 领导审批,这个时候怎么给审批步骤附人员。指定人显然不对,因为每个员工领导都不是固定 的,指定角色也不对,张三请假只需要张三的领导审批,其他人并不需要收到这个审批,在程序中 当张三这个环节完成时,应该把manager指定具体的人,这样任务就可以自动就流转到manager 上。会签先放一下,等会儿单独说。当指定类型为指定角色时,需要关联node_role表,uid--当 指定类型为指定人时,uid表示指定人id,distribute_condition--条件表达式,当指定类型为根据条 件指定时,需要定义表达式,如上图部门领导审批中的#{manager},sign_type--会签类型: 1.顺序 串行会签 2.无序串行会签 3.并行会签,refuse_type--会签不通过类型 1.驳回上节点 2.直接否 决,approve_type--通过规则:1.一票否决 2.少数服从多少 3.自定义规则,approve_condition--会签 通过规则 默认为空,这几个字段都跟会签有关,之后会将这里就不解释了。

sequence_flow 表:迁移表,指定节点的流向和条件。主要字段包括:process_id--流程id,source_task_id--起 始节点,target_task_id--指向节点,condition--条件语句,如#{amount }<= 500 && # {amount >= 100}

会签

上述的分配人员能解决节点固定的工作流,但是有时候仍满足不了我们的业务。

自定义流程数据结构设计

比如我们公司的请假业务,审批的时候需要同时发送给多个人审批,且每个人必须审批完成这个步骤才算结束。  这个场景下:   1.所有人都必须进行审批,无论是同意还是不同意。   2.会签过程中,无法退回,只能选择同意还是不同意,当然也可以输入一些备注,附加附件   3.当所有人会签完毕后,流程会自动转到下一步去

在这个场景下我们就需要用到会签了,在一个任务环节中可以多人执行,并且在定义流程的时候不定义执行人等创建任务实例的时候使创建者自己去定义这个环节的执行人

自定义流程数据结构设计

会签主要分三种情况:

1.串行顺序:任务节点需要多人执行,且是有序的,且需要所有人按顺序接收到任务全部完成才执行下一步骤 A->B->C ​ 2.串行无序:任务节点需要多人执行,且是无序的,且需要所有人能同时接收到任务全部完成才执行下一步骤 ​ 3.并行:任务节点有多人能同时接收到该任务,但只需要一个人执行即可

这三种会签场景也很常见,这里就不举例了。在回去看task_node表的会签字段就容易理解了

 

实例表

定义了流程之后,用户就可以创建流程了,所以需要有process_insance--流程实例表和task_instance--任务实例表。

process_instance表:流程实例表,定义了具体的流程实例对象。主要字段包括:process_id--流程 id,process_instance_name--流程实例名称,node_id--执行到了哪个环节,expire_time-- 过期时间,status--状态 1:进行中 2.已完成 3.被否决 4.被冻结,freeze_time--冻结时间, active_time--**时间,finish_time--完成时间,create_uid--创建人id,reason--取消原 因,chain--之前的环节 如/1/2/3 代表之前完成了1,2,3步环节,business_key--业务表 字段: 表名:id,这样就可以根据流程实例找到业务的主表对象,对表单业务对象进行一些处 理。

注意:当创建任务实例时,如果遇到定义的流程包含会签节点,需要在创建实例时添加会签环节的执行人时,则需要用到sign_user表。

sign_user表:会签用户表,主要字段包括:process_instance_id--流程实例id,node_id--环节id,user_id--用户id, 流程实例与会签用户是1对多的关系。

task_instance表:任务实例表,如接收的待办任务,完成任务,历史任务节点等都是面向这个表的对象。主要字 段包括:process_instance_id--流程实例id,node_id--环节id,deal_user_type--处理人类型 node表冗余字段 便于查询 ,file--附件,因为我们用的是阿里云,所以这里只需要传文件的 key就行,message--备注,如审批信息,status--状态:0--未到达1--待接收 2--进行中 3--通 过 4--退回 5--否决,next_node_id--处理后环节,chain--完成的历史链路 如 /1/2/3/2/3/4, sign_type--会签类型: 1.顺序串行会签 2.无序串行会签 3.并行会签,start_node_flag--是否是 首节点 0.不是 1.是,用于判断是否可以回退,last_node_flag--是否是末节点 0.不是 1.是, 判断流程实例是否结束。

注意:有的任务节点会出现条件判断,若未给出具体的条件,流程指向就不明确了,只有在完成当前节点后,传入具体的条件,流程才会指向下一个节点,如图1的员工请假节点,只有明确请假天数account和员工部门departmentId流程实例才能顺利到下一个节点,需要用到task_instance_parameter--任务实例参数表。

task_instance_parameter:任务实例参数表,完成任务时,增加数据,根据迁移判断流程指向哪个节点。主要 字段包括:name--参数名,type--参数类型 1.整型 2.小数 3.字符串 4.波尔,value-- 参数值,这里直接定义varchar了,程序中需要根据type转型,task_instance_id-- 任务节点实例id。