jbpm

理解JBPM(java Business Process Management)的基本概念：

jPDL - JBPM Process Definition Language

JBPM简要过程：
1、定义流程（利用JPDL）
2、部署流程（部署到数据库）
3、创建公文并与流程实例绑定
4、可通过JBPM的接口，触发流程向下流动
5、可通过JBPM的接口，获得流动到某个用户那里的文档（即待处理任务列表）
6、可通过JBPM的接口，结束某个用户的任务（这将触发流程继续向下流动）
7、如此，直到结束

----------------------------------------------
测试：

1、安装JBPM
- 引入Hibernate依赖包
- 引入JBPM依赖包
* bsh.jar
* jcr-1.0.jar
* jbpm-identity.jar
* jbpm-jpdl.jar
- 引入数据库驱动
* mysql-connector-java-3.1.13-bin.jar
2、定义相关配置文件
- Hibernate配置文件
* 提供hibernate配置文件（可以从config/目录下拷贝，并修改其中的数据库连接设置即可）
3、假设现在有一个公文，需要经过：张三、李四、王五的审批之后才能结束
4、我们定义一个Document对象，及其hibernate映射，并将修改hibernate配置文件，将映射添加到其配置中（以便创建相应的数据库表）
5、现在让我们来测试一下：
- 创建数据库表: JbpmConfiguration.getInstance().createSchema();
- 定义流程: 参考process.xml
- 部署流程:
* JbpmConfiguration.getInstance() - 创建jbpmConfiguration对象
* ProcessDefinition.parseXmlResource(String); - 读取流程定义文件，创建processdefinition对象
* jbpmConfiguration.createJbpmContext(); - 创建jbpmContext对象
* context.deployProcessDefinition(definition); - 部署流程到数据库
* context.close(); - 关闭context对象
- 创建公文
- 将公文与流程绑定（即需要创建流程实例）
* JbpmConfiguration.getInstance() - 创建jbpmConfiguration对象
* jbpmConfiguration.createJbpmContext(); - 创建jbpmContext对象
* context.setSessionFactory(sessionFactory),将JBPM与程序中的session绑定
* context.getGraphSession().findLatestProcessDefinition("流程名称");
* new ProcessInstance(definition); - 创建流程实例
* context.save(processInstance); - 存储流程实例
* 在Document中添加Long processInstanceId 属性
* context.getSession().load 操作，加载Document对象
* document.setProcessInstanceId - 绑定流程实例到公文
* processInstance.getContextInstance.createVariable("document",document.getId()) - 绑定公文到流程实例
- 公文创建者提交公文
* (Document)context.getSession().load(Document.class, 1); - 加载公文信息
* context.getProcessInstance(从公文中获取的流程实例ID); - 即根据流程实例ID加载流程实例
* processInstance.getRootToken().signal(); - 触发流程往下走（即到达第一个节点）
- 这时候，我们可以测试一下，看看流程当前所处的节点
* processInstance.getRootToken().getNode().getName()
- 第一个节点对应的用户登录，应该能够查询到其当前的任务（有公文等待其审批）
* List tasks = context.getTaskMgmtSession().findTaskInstances("张三"); - 查找张三的任务列表
* 列表元素是TaskInstance实例
* 通过：taskInstance.getProcessInstance().getContextInstance().getVariable("document"); 可以找到其绑定的公文ID
- 查找到当前的任务对应的公文之后，即可对其审批，并继续往下走
* taskInstance.end();
- 如此，直到结束
* processInstance.hasEnded() - 如果流程已经到达终点，本调用将返回true

（1） jbpm的模型是采用UML Activity Diagram的语义，所以便于开发人员理解流程。
（2） jbpm提供了可扩展的Event-Action机制，来辅助活动的扩展处理。
（3） jbpm提供了灵活的条件表达式机制，来辅助条件解析、脚本计算的处理。
（4） jbpm提供了可扩展的Task及分配机制，来满足复杂人工活动的处理。
（5） 借助hibernate的ORM的优势，jbpm能够很容易支持多种数据库。

当然，还有一些优点，是很多开发人员并不太注意的，比如：
（1） jbpm的Node机制非常灵活，开发人员可以很容易定制“业务化语义的节点”，并满足运行时候处理的需要。

有很多灵活的优点，当然也少不了存在一些“局限”。
（1） 很显然，只能有一个start-state。
（2） jbpm依靠Token来调度和计算，在同一个时刻中，一个ProcessInstance只允许一个Token对象只存在一个Node中（分支当然用Child Token对象处理）。所以本质上就不支持“multi-instance”模式。
（3） jbpm作为一款开源的工作流引擎，其更多的是关注“如何辅助你更容易的让流程运行完成”，但是并不记录“流程运行的历史和轨迹”。这一点可能是东西方文化的差异性所在，因为国内的流程应用，比较关注“运行轨迹”。

至于其他的一些局限，比如不支持“回退”、“跳转”等操作，这也是因为东西方文化的差异所在。西方人认为“往回流转的情况肯定也是一种业务规则所定义，那么肯定可以通过分支或条件来解决”，而东方则把“回退作为一个人性化管理和处理的潜在特点”。所以诸如此类的一些“特定需求”，估计只能通过扩展jbpm来实现了，甚至有时候，简单的扩展是无法解决问题的——正如上一节所说的那样，“引擎的抽象”会影响“引擎的应用”的复杂度支持。