对于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后，在业务数据方面基本不会减少工作。