七张核心表

68747470733a2f2f73322e617831782e636f6d2f323031392f30392f32302f6e6a4166426a2e706e67.png

表定义详细

WF_PROCESS

流程定义，例如请假申请，用车申请等流程定义

153019_729ddee2_13178.png

WF_ORDER

流程实例，当前运行中的流程实例的信息，比如，我申请了一条请假流程，流程编号“请假-001”，这个请假流程“请假-001”就是一个流程实例

WF_HIST_ORDER

历史流程实例，只要启动过的流程，历史流程实例表中就会存储流程的实例信息，比如这条流程是否结束

WF_TASK

任务，某个流程中某个节点，叫做任务实例。比如“请假-001”中需要上级审批，“上级审批”这个节点就是一个任务实例

WF_HIST_TASK

历史任务(就是执行完了的任务)，所有任务结束以后都会在历史任务信息表里存一条记录

WF_TASK_ACTOR

每个任务对应的参与者(记住谁可以签收或处理)，可能会有多个人或者用户组。

WF_HIST_TASK_ACTOR

历史的参与者表，任务处理完以后，对应处理人的信息会存到这个表里面

详细讲解

WF_PROCESS:存放流程定义，通过编辑一个后缀为.snaker的xml文档来定义流程的走向；在前端流程定义管理里有个部署流程的按钮，可以将编辑好的xml文档保存到WF_PROCESS表中，并产生一条记录。xml文档里有流程的名字，如果这个名字在WF_PROCESS已经存在了，则保存时产生的新的记录的version字段值会自动加1。processId是唯一的，不重复。

WF_ORDER:存放流程实例的。开启一个流程实例时，WF_ORDER表有个字段PROCESS_ID和流程定义的process_id相关联，他们是一对多的关系。当开启一个流程实例WF_ORDER时，在WF_ORDER和WF_HIST_ORDER都新增一条记录，并且同时产生的那两条记录的主键id是一样的。，其中WF_HIST_ORDER比WF_ORDER多一个字段ORDER_STATUS 流程实例状态(0：结束；1：活动)。

当流程没跑完时，ORDER_STATUS的值是1；

当整个事件流程跑完了，WF_ORDER表的那条记录会被删除，WF_HIST_ORDER表对应的那条记录的ORDER_STATUS的值变成0，表示流程实例跑完了。

WF_TASK：存当前任务的；当流程执行完当前任务节点时，WF_TASK的这条记录会被剪切到WF_HIST_TASK表中，然后在WF_TASK表中新增下一个任务节点的信息记录。新增的下一任务节点的task有个字段parent_task_id记住上一个任务节点在WF_HIST_TASK表里的WF_HIST_TASK_ID(上一个任务节点从WF_TASK表剪切到WF_HIST_TASK了)；这样就可以实现回退等功能。

WF_TASK_ACTOR：存哪个任务关联了那些参与者的，就是哪些人可以签收或者处理。如果当前任务节点被执行了，则相关的参与者会被剪切到WF_HIST_TASK_ACTOR表里，和WF_TASK、WF_HIST_TASK类似，这样回退时，就知道以前这一步是谁处理的。

假如现在执行节点的任务是A2，上述中wf_task存的是执行中的记录，也就是说在执行A2前，wf_task中肯定会有一条执行中的任务记录，假设为A1，那么执行A2时的增删改为先将wf_task和wf_task_actor表中A1的记录插入wf_hist_task和wf_hist_task_actor中；其次是删除wf_task和wf_task_actor中A1记录，然后将A2的信息插入到wf_task和wf_task_actor中。此时wf_task表的parent_task_id是历史表A1记录的Id，通过此可将所有任务串联起来。task表的variable中的值为局部变量只能在当前task中使用。有人会有疑问，假设有如下流程图，执行task1时会怎么样？

image.png

因为开始节点是一个比较特殊的nodemodel，群主称之为流转逻辑元素(下面总体设计思路中会有详细介绍)，它只负责流转到下一节点不负责执行，也就没有数据库的增删改。这样直接流转到task1，插入wf_hist_task和wf_hist_task_actor，并且又直接流转到end节点，end节点也是一个流转元素，它会直接删除wf_order表的记录并更改该流程实例wf_hist_order表的order_state的状态。

至此一个流程的所有增删改查结束。