jBPM-jPDL学习笔记—框架设计简介(二)

jBPM-jPDL学习笔记—框架设计简介(二)

关键字: jbpm jpdl 工作流

 

...上接 jBPM-jPDL学习笔记—框架设计简介(一)

 

jPDL业务流程模型

 

理解现实生活中的业务流程

       下面我们通过一个简单的部门借款流程来了解现实中的业务流程概念，流程图如下：

上图表达了一个抽象的流程定义（Process Definition）。之所以称之为抽象，是因为它没有表示确切的执行者。当上述的借款人被具体化为“张三”，部门主管就成为张三的部门经理“李四”，而财务则明确为“王五”的时候，这个流程定义就被具体化，成为了一个流程实例（Process Instance）。此外，过程中的相关人员我们称之为参与者（Actor）；过程中需要参与者介入的环节称之为任务（Task）；每个任务在流程实例中的具体化称之为任务实例（Task Instance）；从一个任务（结点）到另一个任务（结点）的转化过程叫做流转(Transition)；而在流程中，由程序预先设定的行为如发送邮件，我们称之为活动（Action）。         通过上述样例，我们了解了业务流程中一些专有名词和概念。接下来，我们要从程序设计的角度来讲述jPDL中定义的流程对象模型。

         在jPDL中，对流程的建模被划分为两大部分，一是针对“流程定义”的静态模型部分；二是针对具体“流程实例”的运行时动态模型。在这一章节，我们将详细的讲述jPDL的对象及对应的数据库设计。

 

静态的流程定义模型

编号	PD-001
对象	流程定义实体（Process Definition）
描述	流程定义实体是对一个流程抽象的对象化定义，如图-002。一套系统中，用户可以定义保存多个流程定义实体，如：报销流程定义、请假流程定义、人事录用流程定义等。每个流程定义还可以有多个不同的版本，如:针对同样的报销流程可以有修订前和修订后的两个流程定义，同时存储于jPDL数库中。用户可以通过流程名称和版本号获取相应的流程定义。在默认请况下，系统启用最新的流程定义。
Java对象	org.jbpm.graph.def.ProcessDefinition
数据库表	JBPM_PROCESSDEFINITION该表存储流程定义的通用信息，如：流程名称、版本号
表关联说明	JBPM_PROCESSDEFINITION表中，每条记录有自己的数据库流水号     ID_JBPM_PROCESSDEFINITION的外键（Foreign Keys）： startstate_ 同JBPM_NODE（流程结点）表关联。此外键指向流程定义中的起始结点ID

 

编号	PD-002
对象	流程结点（Node）
描述	流程结点是对流程中的过程环节/行为的抽象对象化定义，如图-002中的每个方框即代表一个结点。结点有两个主要职责：一，实现某个指定行为，这在jBPM中就是执行一段制定的Java代码；二，转递、维持流程的延续，直至达到最终结点。在jPDL的结点设计中，系统开放了充分的用户行为模型，程序员可以基于这些行为接口，实现自定义的业务功能。在jPDL中，系统预定义了一系列的Node类型，同时也允许程序员开发定义自己的Node类型。
Java对象	org.jbpm.graph.def.Node
数据库表	JBPM_NODE该表存储结点的定义信息。
表关联说明	JBPM_NODE表中，每条记录有自己的数据库流水号   ID_JBPM_NODE的外键（Foreign Keys）： processdefinition_ - 此外键说明该Node从属的流程定义对象ID subprocessdefinition_- 此外键指定了一个由该Node发起的子流程。在主流程离开当前结点之前，该子流程必须完成执行过程。action_ - 此外键指定该结点动作类的ID superstate_ - 该外键是一个自关联键，指向结点的上级父结点ID。一个子流程中的多个结点从属于同一个父流程结点。 decisiondelegation_ – 该外键指定了结点委派的判定类ID（所谓委派判定类是指根据用户的业务逻辑，判定流程的下一个流向的Java Class）

 

Node类型祥解：

 

 任务结点（task-node）任务结点是代表由人介入的一个或多个任务。因此当流程运行到一个任务结点时，会生成“任务实例对象（task instances）”，并添加到参与人的任务列表中，之后结点会处于等待状态，直到参与人完成他们的任务，并激活流程继续向下执行。

 

状态结点（state）

状态结点是一个典型的等待状态。同任务结点不同的是，状态结点不会向任务列表添加任务实例。当业务进程需要等待外部系统的干预时，这种结点是很有用的。假设如下情况：在进入该结点时，通过node-enter事件向外部系统发送一个消息，然后结点进入等待状态；当外部系统完成处理，并回送一个消息，这将导致触发一个token.signal()方法的运行，该方法重新激活正在等待的流程继续下行。

 

  判定结点（ decision ） 判定节点的作用就同它的命名一样，用来决定业务流程的走向。有两个不同裁决模式，两者的区别在“谁”来做决定：是由流程内部的变量，还是由外部实体来提供决定的依据。 当需要对流程执行方向做判定时，就要使用“判定结点（ decision ）”。有两种方法来指定判定条件。最简单的是在转向（ transitions ）中添加条件元素，条件可以是能返回 boolean 值的 EL 表达式或者 beanshell 脚本。 在运行过程中，判定结点将首先轮训有条件设定的转向（ leaving transitions ），轮训的顺序是按照 XML 文件中指定的。当找到第一个条件返回为 true 的转向时，该出口将被选中。如果所有的表换中的条件判定都是 false ，则选择 XML 文件中排在第一位的转向作为出口。还有一种途径是在判定结点上定义一个返回转向名称的表达式，通过表达式计算返回的名称，决定选择哪个 transition. 另一方式是在结点上设定“处理（ handle ）”元素。在结点上指定一个实现了 DecisionHandler 接口的 Java 处理类，该类通过返回选定的 transition 的名称来决定流程的出口方向。

当判定结点的出口是由外部程序来给出的时候，建议使用多个transition或者具有等待状态的结点。可以通过外部的触发器结束一个等待状态并提供一个transition的判定。

 

  分支结点（ fork ）

         分支结点的作用是将单个执行流程分裂成多个并发的执行流程。默认的行为是为每个子流程生成一个子令牌，并建立子令牌和主流程根令牌之间的父子关系。

 

  合并结点（ join ）

         相对于fork结点的分支，join结点将分支收拢。默认的行为模式是当所有的分支（由同一个fork衍生出来的分支）都到达该结点的时候，join结点将结束这些分支上的子token，并通过token上的父子关系找到上一级流程的token，将此token通过唯一的transition传播下去。如果只有分支中的部分token到达时，join结点将处于等待状态。

 

 普通结点（node）普通类结点主要用于提供用户定制自己的程序代码。普通结点拥有一个action子元素，当流程到达该结点时，这个action就会被执行。可以通过实现ActionHandler接口来执行你想要的任何代码。此外普通结点也一样要负责流程的延续。

 

         在流程图上，普通结点用来表达一个用户关心的、与业务相关的处理逻辑；相比而言Action（下文中将会提到）则允许添加业务逻辑以外的程序处理，这些程序处理在流程图上是不可见的，也是业务流程分析所不用关心的。

 

 

编号	PD-003
对象	流程转向（Transitions）
描述	流程转向是描述流程中从一个结点到另一个结点的状态转换过程，因此一个转向一定有一个源结点和一个目标结点。 在jPDL中transition的命名是通产是唯一的，结点依靠transition的命名来区别到下一结点的路径，当一个Node中存在有多个同名的transition的时候，第一个transition将会被选中。结点转向的过程中，排在transition列表第一位置的即是默认的transition。
Java对象	org.jbpm.graph.def.Transition
数据库表	JBPM_TRANSITION该表存储流程定义中的转向对象。
表关联说明	JBPM_TRANSITION表中，每条记录有自己的数据库流水号   ID_JBPM_TRANSITION的外键（Foreign Keys）： processdefinition_ - 该外键指向transition所属的流程定义对象ID from_ - 该外键指向transition的源结点ID to_ -该外键指向transition的目标结点ID

 

编号	PD-004
对象	动作（Actions）
描述	Actions是指一系列的在流程事件中运行的Java代码。流程图是软件需求的传达的重要手段，但它只是软件需求的一个投影，隐藏了很多技术实现的细节。Actions则是向流程图添加技术实现细节的一种机制，它可以很好的补充和修饰流程图。这意味着在不改变流程图结构的情况下，可以将Java的代码与之关联。Actions通过事件（Events）同流程绑定，常用的主要事件包括：进入结点、离开结点、进行转向。请注意，同Events关联的Actions和处于Node中的Actions是有不同的。处于Events中的Actions是通过事件触发执行的，它是典型的观察者模式，是无法影响流程控制的流向。而处于Node中的Action则要承担起流程传递的责任。此外，Actions是可以命名的。可以通过Actions的命名在任何地方引用该Actions。命名的Actions可以作为主流程定义的公用子元素。这个功能可以提高对Actions定义的复用。
Java对象	org.jbpm.graph.def.Action
数据库表	JBPM_ACTION该表存储流程定义中的动作对象。
表关联说明	JBPM_ACTION表中，每条记录有自己的数据库流水号ID_   JBPM_ACTION的外键（Foreign Keys）： processdefinition_ - 指明action所属的流程定义ID event_ - 指明action绑定的event ID actiondelegation_ - 指明action的委派对象ID exceptionhandler_ - 指定action的异常处理ID referencedaction_ - 指向当前action引用的action的ID timeraction_ - 指向当前action引用的计时器action

 

编号	PD-005
对象	事件（Events）
描述	事件表示流程执行中的某个特定的时刻。在流程执行的过程中，通过jBPM的引擎触发事件，这通常发生在jbpm计算后续状态的时候。事件总是和流程中的元素绑定，这些元素包括：流程定义（process definition）、流程结点（node）、流程转向（transition）和任务（task）。不同的元素会触发不同的事件，拿node元素来说，有 node-enter事件和node-leave事件。事件是action的钩子，一个事件可以回调一系列的action。当jBPM引擎触发事件的时候，事件中绑定的action就会被执行。在jBPM中，事件模型是可传播的。一个子元素触发的事件，将逐层向上传播到顶层的流程定义元素。这样的设计使得事件可以被集中化处理。
Java对象	org.jbpm.graph.def. Event
数据库表	JBPM_EVENT该表存储流程定义中的事件对象，这些事件与相关的action绑定。
表关联说明	JBPM_EVENT表中，每条记录有自己的数据库流水号ID_   JBPM_EVENT的外键（Foreign Keys）： processdefinition_  - 指向event所属的流程定义ID node_  - 指向event所属的node ID transition_  - 指向event所属的transition ID task_  -  指向event所属的任务ID

 

 (----续 jBPM-jPDL学习笔记—框架设计简介(三))