JBPM学习笔记（一）（摘自银狐）

引擎内核所关注的是一个非常“抽象”层面的问题，而不同引擎关注的“一套完整的执行环境”。或者我们可以这么来说，引擎内核的职责是非常“精简”的：确保流程按照既有的定义，从一个节点运行到另一个节点，并正确执行当前节点。
总的来说，引擎内核主要关注四个方面的问题：
（1） 流程定义问题：不是说如何图形化的定义流程，而是如何用一套定义对象，来诠释所定义的流程。
（2） 流程调度问题：提供什么的机制，可以确保流程能够处理复杂的“流程图结构”，诸如串行、并行、分支、聚合等等，并在这复杂结构中确保流程从一个节点运行到另一个节点。
（3） 流程执行问题：当流程运行到某个节点的时候，需要一套机制来解决：是否执行此节点，并如何执行此节点的问题，并维持节点状态生命周期。
（4） 流程实例对象：需要一整套流程实例对象来描述流程实例运行的状态和结果。

现在这里从技术角度来分析jbpm3的优点，简单罗列几个大家都容易看见的：
（1） jbpm的模型是采用UML Activity Diagram的语义，所以便于开发人员理解流程。
（2） jbpm提供了可扩展的Event-Action机制，来辅助活动的扩展处理。
（3） jbpm提供了灵活的条件表达式机制，来辅助条件解析、脚本计算的处理。
（4） jbpm提供了可扩展的Task及分配机制，来满足复杂人工活动的处理。
（5） 借助hibernate的ORM的优势，jbpm能够很容易支持多种数据库。

process的本质就是“节点”和“有向弧”，当然你也可以说是Node和Link，或者Node和Transition，或者Activity和Transition等等之类的。jBpm采用的是Node和Transition来表示“节点”和“有向弧”。

对于一个节点来说，从定义角度，其只关心几个事情：
（1） 这是个什么类型的节点。这个节点可能是start state，也可能是一个task node，或者是一个fork。
（2） 这个节点的转入Transition和转出Transition。

ExecutionContext是一个“执行环境”，对context这个概念应该比较熟悉了，它关联了Transition、Node、Token、ProcessInstance、TaskInstance、Task等对象。通过这个“执行环境”，我们就能取得这些对象。


记住两个重要的机制：过程调度机制和执行机制。
过程调度机制是保证token是如何正确的从一个节点流转到下一个节点的。具体怎么流转呢？
可以通过两种方式：
一是通过processInstance的signal()方法。


总结:
Token.signal(Transition)
--> Node.leave(ExecutionContext,Transition)
--> Transition.take(ExecutionContext)
--> Node.enter(ExecutionContext)
--> Node.execute(ExecutionContext)

二是通过taskInstance的end操作。
而执行机制是为提供一个运行机制，来保证节点的“正确执行”。

jBpm内核结构与实例对象：

在流程执行时候流程变量包含上下文信息. 流程变量同java.util.Map相似映射名字到值,值可能是个java对象 . 流程变量被永久化作为流程实例的一部分。

// 从流程实例中为流程变量获得上下文实例
ContextInstance contextInstance =
  processInstance.getContextInstance();

// 我们准备设置一些流程变量在流程实例上下文中
contextInstance.setVariable("amount", new Integer(500));

// 访问变量通过contextInstance.
assertEquals(new Integer(500), contextInstance.getVariable("amount"));

jBPM工作流引擎和组织模型是分开的,一种用来计算参与者表达语言总是受限的. 因此,你不得不指定AssignmentHandler的实现来计算任务的参与者。
<task name='change nappy'>
<assignment class='org.jbpm.tutorial.taskmgmt.NappyAssignmentHandler' />
</task>

节点同转换相比有超过一个事件类型(event type)转换(transition)只有一个事件，节点有enter-node和 leave-node 事件。

<state name='s'>" +
  "    <event type='node-enter'>" +
  "      <action class='org.jbpm.tutorial.action.MyActionHandler' />" +
  "    </event>" +
  "    <event type='node-leave'>" +
  "      <action class='org.jbpm.tutorial.action.MyActionHandler' />" +
  "    </event>" +
  "    <transition to='end'/>" +
  "  </state>
JBPM持久化

contextSession跟jbpmContext的关系？
因为JBPM是使用hibernate来持久化，所以必须得到session，我们在用的时候通常会把获得session的过程通过配置到JBPM里，把session跟JBPM结合起来，用jbpmContext就可以了。

上下文同流程变量有关.流程变量是同流程实例相关的key-value对 维护信息. 因为上下文必须保存在数据库中,将会稍微约束使用。
org.jbpm.context.exe.ContextInstance 作为提供流程变量服务的中央接口. 你可以从ProcessInstance 获得ContextInstance。

每个执行路线(参看: 令牌) 有它自己的一套流程变量. 变量请求总是在令牌上发生. 流程实例有令牌树 (参看 面向图的程序设计 ). 当请求一个变量没有指明令牌, 那么默认的令牌是根令牌.

当在令牌上设置不存在变量,那么变量就在根令牌root-token上被建立 .这就是说每个变量默认就是整个流程范围. 如果想建立一个令牌的局部变量,必须显式的使用API:
ContextInstance.createVariable(String variableName, Token token);       

当需要与JBPM数据库交互时，即我们需要从JBPM数据库中查找数据时，都是使用XXXSession的方法，常用的如：taskMgmtSession，注意它跟taskMgmtInstance的区别，后者从名字上看就知道是一个实例，说明是用来创建任务实例的，即创建taskInstance的，相反，taskMgmtSession就是从JBPM数据库中查询某个参与者拥有的任务实例。其他的接口也有类似的规则。

通俗的理解，泳道是任务实例的集合。一个分配handler实现在任务实例建立的时候被调用. 在这个时候,任务实例可以分配给一个或多个参与者.  AssignmentHandler 实现可以调用 Assignable 方法(setActorId或 setPooledActors )来分配任务. 可分配的要么是一个 TaskInstance 或者 SwimlaneInstance (= 流程角色).我们可以把任务实例或者泳道分配给参与者。
但是具体怎么分配呢？

分配任务实例和分配swimlance实例到参与者的数据模型如下。每个 TaskInstance 有actorId和一组被缓存的参与者：