jbpm的表结构以及六大服务

对于jbpm的开发，你应该具备的基本知识是对于表结构的理解，以及对于API的熟悉，下面我就带大家总结一下这两方面的知识：

一、jbpm表结构介绍

1.资源库和运行时表结构（10张表）

JBPM4_DEPLOYMENT，JBPM4_DEPLOYPROP，JBPM4_LOB 存储流程定义相关的部署信息 。

JBPM4_EXECUTION主要是存放JBPM4的执行信息，Execution机制代替了JBPM3的Token机制 。

JBPM4_TASK存放需要人来完成的Activities(活动)，需要人来参与完成的Activity 被称为Task 。

JBPM4_PARTICIPATION参与者表，存放参与者信息，参与者的种类有Candidate、Client、Owner、Replaced Assignee和Viewer。而具体的参与者既可以是单一用户，也可以是用户组 。

JBPM4_SWIMLANE泳道表。SwimLane是一种Runtime Process Role。通过SwimLane，多个Task可以一次分配到同一Actor身上 。

JBPM4_JOB  存放的是Timer 的定义 。

JBPM4_VARIABLE 存的是进行时的临时变量。

JBPM4_PROPERTY 引擎参数表

2.历史数据库表结构 （5张表）

JBPM4_HIST_PROCINST 与JBPM4_HIST_ACTINST 分别存放Process Instance和Activity Instance的历史记录 。

JBPM4_HIST_DETAIL 流程历史详细表，保存 Variable的变更记录 。

JBPM4_HIST_VAR 保存历史的变量 JBPM4_HIST_TASK Task的历史信息 。

JBPM4_HIST_TASK 任务历史表，Task的历史信息。

3.身份认证表结构 （3张表）

JBPM4_ID_GROUP ，JBPM_ID_MEMBERSHIP ，JBPM4_ID_USER 这三张表很常见，基本的权限控制，关于用户认证方面建议还是自己开发一套，组件自带的功能太简单，使用中有很多需求难以满足

二、流程引擎对象：

ProcessEngine是jbpm4所有Service API之源

在jbpm中各种服务相互依存，但所有的service API都从ProcessEngine中获得，它是由Configuration类构建的，即工作流引擎根据配置产生。

ProcessEngine是线程安全的，因此它可以保存在静态变量中，甚至JNDI命名服务中或者其他重要位置。在应用中，所有线程和请求都可以使用同一个ProcessEngine对象，以下代码告诉您如何获得ProcessEngine：

[java] view plaincopyprint?

ProcessEngine  processEngine=Configuration.getProcessEngine();

上面代码中的Configuration使用了classpath根目录下的默认配置文件jbpm.cfg.xml创建一个ProcessEngine。如果你要自定义位置，那么可以这样做：

[java] view plaincopyprint?

ProcessEngine processEngine=new Configuration().setResource(“myjbpm.xml”)       buildProcessEngine();

然后，那6个service直接可以用processEngine.getXXX()得到。下面把这6个service描述一下：

同样我们对比着数据库的表结构来区分这几个服务

1.操作资源库和运行时服务（4个）

RepositoryService—流程之源服务的接口。提供对流程定义的部署，查询，删除等操作。

ExecutionService—流程执行服务的接口。提供启动流程实例，“执行”推进，设置流程变量等操作

ManagementService—流程管理控制服务的接口，提供异步工作(Job)相关的执行和查询操作。

TaskService—人工任务服务的接口。提供对任务(Task)的创建，提交，查询，保存，删除等操作。

2.操作历史数据库服务 （1个）

HistoryService—流程历史服务的接口。提供对流程历史库(即已完成的流程实例归档)中历史流程实例，历史活动实例等记录的查询操作。还提供诸如某个流程定义中所有活动的平均持续时间，某个流程定义中某转移的经过次数等数据分析服务。

3.操作身份认证服务 （1个）

IdentityService—身份认证服务的接口。提供对流程用户，用户组以及组成员关系的相关服务

三、当前使用工作流的问题：

1、对当前任务的条件查询：

jBPM不提供灵活进行条件查询的api，如果需要，可以自定义hibernate查询，从jbpm相应的数据表中查询任务数据。但需要对jBPM机制比较了解，而且有些复杂条件难以用jBPM本身的信息查到。

2、统计各个流程实例的状态：

可以通过流程实例，在jbpm系统表中查询，也可以在业务表的相应数据上加上状态列来统计。前一个比较麻烦，后一个比较直观，但不会因使用jBMP而使工作量减少。

3、工作流数据与业务数据结合：

一般通过在流程实例中添加相应的一笔数据的标识作为变量来关联。也可以有针对性的扩展jbpm的系统表来实现与业务的关联性。

4、修改流程后的历史数据兼容性问题：

Jbpm工作流流程定义有版本的概念，修改流程后要重新发布，与旧的流程不是一个同一个版本。系统可以区别开新旧流程来。

总结：   关于业务数据与jBPM本身的数据

理论上说，如果使用jBPM，可以将所有业务数据放到jBPM的context中管理，不再维护业务数据表。但这样的结果是在流程之外的环境（比如在统计报表中）中无法容易的得到业务数据。所以一般会建立业务数据表，我不使用工作流时一样，然后让jBMP从业务数据表中得到业务数据，而不在jBPM中保留业务数据。因此，使用jBPM后，在业务数据方面基本不会减少工作。

对于jbpm的学习还是处于初级阶段，其中对表结构的熟悉，以及对流程引擎对象使用的熟练程度，都需要在项目中去历练。而现在的想法，与思维上的困难也只有在真正的看到项目上线的那天才会明了。

上一篇jbpm4.4环境搭建 下一篇Hibernate工作原理简单分析

顶2