对jbpm的开发，你应当具有的基本知识是对表结构的理解，和对API的熟习，下面我就带大家总结1下这两方面的知识：
1、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。而具体的参与者既可以是单1用户，也能够是用户组 。
JBPM4_SWIMLANE泳道表。SwimLane是1种Runtime Process Role。通过SwimLane，多个Task可以1次分配到同1Actor身上 。
JBPM4_JOB 寄存的是Timer 的定义 。
JBPM4_VARIABLE 存的是进行时的临时变量。
JBPM4_PROPERTY 引擎参数表
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 这3张表很常见，基本的权限控制，关于用户认证方面建议还是自己开发1套，组件自带的功能太简单，使用中有很多需求难以满足
2、流程引擎对象：
ProcessEngine是jbpm4所有Service API之源
在jbpm中各种服务相互依存，但所有的service API都从ProcessEngine中取得，它是由Configuration类构建的，即工作流引擎根据配置产生。
ProcessEngine是线程安全的，因此它可以保存在静态变量中，乃至JNDI命名服务中或其他重要位置。在利用中，所有线程和要求都可使用同1个ProcessEngine对象，以下代码告知您如何取得ProcessEngine：
ProcessEngine processEngine=Configuration.getProcessEngine();
上面代码中的Configuration使用了classpath根目录下的默许配置文件jbpm.cfg.xml创建1个ProcessEngine。如果你要自定义位置，那末可以这样做：
ProcessEngine processEngine=new Configuration().setResource(“myjbpm.xml”)
buildProcessEngine();
然后，那6个service直接可以用processEngine.getXXX()得到。下面把这6个service描写1下：
1.操作资源库和运行时服务（4个）
RepositoryService―流程之源服务的接口。提供对流程定义的部署，查询，删除等操作。
ExecutionService―流程履行服务的接口。提供启动流程实例，“履行”推动，设置流程变量等操作
ManagementService―流程管理控制服务的接口，提供异步工作(Job)相干的履行和查询操作。
TaskService―人工任务服务的接口。提供对任务(Task)的创建，提交，查询，保存，删除等操作。
HistoryService―流程历史服务的接口。提供对流程历史库(即已完成的流程实例归档)中历史流程实例，历史活动实例等记录的查询操作。还提供诸如某个流程定义中所有活动的平均延续时间，某个流程定义中某转移的经过次数等数据分析服务。
3.操作身份认证服务 （1个）
IdentityService―身份认证服务的接口。提供对流程用户，用户组和组成员关系的相干服务
3、当前使用工作流的问题：
1、对当前任务的条件查询：
jBPM不提供灵活进行条件查询的api，如果需要，可以自定义hibernate查询，从jbpm相应的数据表中查询任务数据。但需要对jBPM机制比较了解，而且有些复杂条件难以用jBPM本身的信息查到。
2、统计各个流程实例的状态：
可以通过流程实例，在jbpm系统表中查询，也能够在业务表的相应数据上加上状态列来统计。前1个比较麻烦，后1个比较直观，但不会因使用jBMP而使工作量减少。
3、工作流数据与业务数据结合：
1般通过在流程实例中添加相应的1笔数据的标识作为变量来关联。也能够有针对性的扩大jbpm的系统表来实现与业务的关联性。
4、修改流程后的历史数据兼容性问题：
Jbpm工作流流程定义有版本的概念，修改流程后要重新发布，与旧的流程不是1个同1个版本。系统可以区分开新旧流程来。
总结： 关于业务数据与jBPM本身的数据
理论上说，如果使用jBPM，可以将所有业务数据放到jBPM的context中管理，不再保护业务数据表。但这样的结果是在流程以外的环境（比如在统计报表中）中没法容易的得到业务数据。所以1般会建立业务数据表，我不使用工作流时1样，然后让jBMP从业务数据表中得到业务数据，而不在jBPM中保存业务数据。因此，使用jBPM后，在业务数据方面基本不会减少工作。
对jbpm的学习还是处于低级阶段，其中对表结构的熟习，和对流程引擎对象使用的熟练程度，都需要在项目中去历练。而现在的想法，与思惟上的困难也只有在真实的看到项目上线的那天才会明了。