Activiti工作流引擎数据库表结构

时间:2020-12-15 05:42:07

数据库表的命名

Acitiviti数据库中表的命名都是以ACT_开头的。第二部分是一个两个字符用例表的标识。此用例大体与服务API是匹配的。

l ACT_RE_*:’RE’表示repository。带此前缀的表包含的是静态信息,如,流程定义,流程的资源(图片,规则等)。

l ACT_RU_*:’RU’表示runtime。这是运行时的表存储着流程变量,用户任务,变量,职责(job)等运行时的数据。Activiti只存储实例执行期间的运行时数据,当流程实例结束时,将删除这些记录。这就保证了这些运行时的表小且快。

l ACT_ID_*:’ID’表示identity。这些表包含标识的信息,如用户,用户组,等等。

l ACT_HI_*:’HI’表示history。就是这些表包含着历史的相关数据,如结束的流程实例,变量,任务,等等。

l ACT_GE_*:普通数据,各种情况都使用的数据。

数据结构图

Activiti工作流引擎数据库表结构

 Activiti工作流引擎数据库表结构

数据库表结构说明

l ACT_GE_PROPERTY:属性数据表。存储这个流程引擎级别的数据。

1. NAME_:属性名称

2. VALUE_:属性值

3. REV_INT:版本号

l ACT_GE_BYTEARRAY:用来保存部署文件的大文本数据

1. ID_:资源文件编号,自增长

2. REV_INT:版本号

3. NAME_:资源文件名称

4. DEPLOYMENT_ID_:来自于父表ACT_RE_DEPLOYMENT的主键

5. BYTES_:大文本类型,存储文本字节流

l ACT_RE_DEPLOYMENT:用来存储部署时需要持久化保存下来的信息

1. ID_:部署编号,自增长

2. NAME_:部署包的名称

3. DEPLOY_TIME_:部署时间

l ACT_RE_PROCDEF:业务流程定义数据表

1. ID_:流程ID,由流程编号:流程版本号:自增长ID”组成

2. CATEGORY_:流程命名空间(该编号就是流程文件targetNamespace的属性值)

3. NAME_:流程名称(该编号就是流程文件process元素的name属性值)

4. KEY_:流程编号(该编号就是流程文件process元素的id属性值)

5. VERSION_:流程版本号(由程序控制,新增即为1,修改后依次加1来完成的)

6. DEPLOYMENT_ID_:部署编号

7. RESOURCE_NAME_:资源文件名称

8. DGRM_RESOURCE_NAME_:图片资源文件名称

9. HAS_START_FROM_KEY_:是否有Start From Key

注:此表和ACT_RE_DEPLOYMENT是多对一的关系,即,一个部署的bar包里可能包含多个流程定义文件,每个流程定义文件都会有一条记录在ACT_REPROCDEF表内,每个流程定义的数据,都会对于ACT_GE_BYTEARRAY表内的一个资源文件和PNG图片文件。和ACT_GE_BYTEARRAY的关联是通过程序用ACT_GE_BYTEARRAY.NAMEACT_RE_PROCDEF.NAME_完成的,在数据库表结构中没有体现。

l ACT_ID_GROUP:用来存储用户组信息。

1. ID_:用户组名*

2. REV_INT:版本号

3. NAME_:用户组描述信息*

4. TYPE_:用户组类型

l ACT_ID_MEMBERSHIP:用来保存用户的分组信息

1. USER_ID_:用户名

2. GROUP_ID_:用户组名

l ACT_ID_USER:

1. ID_:用户名

2. REV_INT:版本号

3. FIRST_:用户名称

4. LAST_:用户姓氏

5. EMAIL_:邮箱

6. PWD_:密码

l ACT_RU_EXECUTION

1. ID_

2. REV_:版本号

3. PROC_INST_ID_:流程实例编号

4. BUSINESS_KEY_:业务编号

5. PARENT_ID_

6. PROC_DEF_ID_:流程ID

7. SUPER_EXEC_

8. ACT_ID_

9. IS_ACTIVE_

10. IS_CONCURRENT_

11. IS_SCOPE_

l ACT_RU_JOB:运行时定时任务数据表。

1. ID_

2. REV_

3. TYPE_

4. LOCK_EXP_TIME_

5. LOCK_OWNER_

6. EXCLUSIVE_

7. EXECUTION_ID_

8. PROCESS_INSTANCE_ID_

9. RETRIES_

10. EXCEPTION_STACK_ID_

11. EXCEPTION_MSG_

12. DUEDATE_

13. REPEAT_

14. HANDLER_TYPE_

15. HANDLER_CFG_

l ACT_RU_TASK:运行时任务数据表。

1. ID_ 

2. REV_ 

3. EXECUTION_ID_ 

4. PROC_INST_ID_ 

5. PROC_DEF_ID_ 

6. NAME_ 

7. DESCRIPTION_ 

8. TASK_DEF_KEY_ 

9. ASSIGNEE_ 

10. PRIORITY_ 

11. CREATE_TIME_

l ACT_RU_IDENTITYLINK任务参与者数据表。主要存储当前节点参与者的信息。

1. ID_ 

2. REV_ 

3. GROUP_ID_ 

4. TYPE_ 

5. USER_ID_ 

6. TASK_ID_

l ACT_RU_VARIABLE:运行时流程变量数据表。

1. ID_

2. REV_

3. TYPE_

4. NAME_

5. EXECUTION_ID_

6. PROC_INST_ID_

7. TASK_ID_

8. BYTEARRAY_ID_

9. DOUBLE_

10. LONG_

11. TEXT_

12. TEXT2_

l ACT_HI_PROCINST 

l ACT_HI_ACTINST 

l ACT_HI_TASKINST 

l ACT_HI_DETAIL

结论及总结

流程文件部署主要涉及到3个表,分别是:ACT_GE_BYTEARRAYACT_RE_DEPLOYMENTACT_RE_PROCDEF。主要完成部署包”-->“流程定义文件”-->“所有包内文件的解析部署关系。从表结构中可以看出,流程定义的元素需要每次从数据库加载并解析,因为流程定义的元素没有转化成数据库表来完成,当然流程元素解析后是放在缓存中的,具体的还需要后面详细研究。

流程定义中的java类文件不保存在数据库里 

组织机构的管理相对较弱,如果要纳入单点登录体系内还需要改造完成,具体改造方法有待研究。

运行时对象的执行与数据库记录之间的关系需要继续研究

历史数据的保存及作用需要继续研究。