对于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
本站仅提供存储服务,所有内容均由用户发布,如发现有害或侵权内容,请
点击举报。