- 浏览: 2539 次
- 性别:
- 来自: 深圳
文章分类
最新评论
<script type="text/javascript">writeStars(0, "784005");</script> 注册于: 13/02/2007 00:00:00 帖子总数: 61 离线 |
<!---->
三、学习JPDL 3.1 、简介 JPDL(JBPM Process Definition Language)是JBPM流程定义语言。JPDL详细定义了这个状态图的每个部分,如: 开始、结束状态,状态之间的转换等。这种语言的定义对于用户来说比较容易理解,也比较容易对其进行扩展。 一个JBPM的流程定义XML文件中包含一个< process-definition>元素,而一个< process-definition>元素又包含零个或一个< description>元素,零个或多个的< swimlane>元素,一个< start-state>元素,零个或多个的< state>元素或< decision>元素或< fork>元素或< join>元素,以及零个或多个的< action>元素,零个或多个<task-node>和<node>元素,一个< end-state>元素等等。此外,< process definition>元素有一个标示符,以“name”属性来表示,这个属性必须存在,用来表示该流程的名称。 3.2 、流程版本(Version) 我们的流程XML文件定义完成之后,接下来的工作就是要将其发布到对应的数据库中,当我们每次将我们的流程定义部署到数据库时,部署时流程的名称就是前面提高的<process definition>里定义的name”属性的值。 JBPM的版本机制允许在数据库中多个同名流程定义共存,流程实例以当时的最新版本来启动,并且在它的整个生命周期中将保持以相同的流程定义执行。当一个新的版本被部署,新的流程实例以新版本启动,而老的流程实例则以老的流程定义继续执行。 在部署的时候,jbpm 安排一个版本(version)号码(数字)给流程定义。为了实现安排version号码,如果它是第一个版本(version),JBPM采取1+或者1。从ProcessDefinition pd=JbpmContext.getGraphSession() .findLatestProcessDefinition("processName") 中可以通过一个给定的processName查找最近的流程定义,这里的processName就是前面我们在定义流程的时候在<process definition>里定义的name”属性的值,这个属性就是用来表示该流程的名称。如我们的下列代码就是要列出JBPM数据库里的有所有最后一次发布的流程定义的版本: JbpmContext context=JbpmContext.getCurrentJbpmContext(); List ls=context.getGraphSession().findLatestProcessDefinitions(); /* 这里返回的List是ProcessDefinition的集合 */ 3.3 、流程定义 3.3.1 process-definition(流程定义) 流程定义的根节点,是所有节点的父节点 名称 类型 多样性 描述 name 属性 可选的 流程的名称。 swimlane 元素 [0..*] 流程中使用的泳道。泳道表示流程角色,它们被用于任务分配。 start-state 元素 [0..1] 流程起始状态。注意,没有起始状态的流程是合法的,但是不能被执行。 {end-state|state|node|task-node|process-state|super-state|fork|join|decision} 元素 [0..*] 流程定义的节点。注意,没有节点的流程是合法的,但是不能被执行。 event 元素 [0..*] 作为一个容器服务于动作的流程事件。 {action|script|create-timer|cancel-timer} 元素 [0..*] 全局定义的的动作,可以在事件和转换中引用。注意,为了被引用,这些动作必须指定名称。 task 元素 [0..*] 全局定义的任务,可以在动作中使用。 exception-handler 元素 [0..*] 一个异常处理器列表,用于这个流程定义中的委托类所抛出的所有异常。 3.3.2 node(自动节点) 这种节点和State相反,也称自动节点。当业务程序实例执行到这个节点,不会停止执行。而是会继续往下执行。如果该节点存在多个离开转向。那么,就会执行其中的第一个离开转向,在Node状态中,不需要外部参与者的参与,业务流程的这个部分是自动的、即时完成的。 名称 类型 多样性 描述 {action|script|create-timer|cancel-timer} 事件 1 用于表示这个节点行为的定制动作。 普通节点元素 请参考普通节点元素。 3.3.3 start-state(开始状态) start-state是我们整个流程的开始节点,所有的流程实例从这里开始。 名称 类型 多样性 描述 Name 属性 可选的 节点的名称。 Task 元素 [0..1] 起始一个流程实例的任务,或者用来捕获流程发起者 Event 元素 [0..*] 支持的事件类型:{node-leave}。 transition 元素 [0..*] 离开转换,每个离开节点的转换必须有一个不同的名称。 exception-handler 元素 [0..*] 一个异常处理器列表,用于这个流程节点中的委托类所抛出的所有异常。 3.3.4 end-state(结束节点) 对于每一个流程定义都会有一个结束节点,与开始节点对应 名称 类型 多样性 描述 Name 属性 必需的 结束状态的名称。 event 元素 [0..*] 支持的事件类型:{node-enter}。 exception-handler 元素 [0..*] 一个异常处理器列表,用于这个流程节点中的委托类所抛出的所有异常。 3.3.5 state(状态) State节点也叫手工节点,进入到这种节点,整个流程的执行就会中断。直到系统外参与者发起继续执行的命令,即调用signal或end方法,业务程序实例的执行才能够继续下去。 名称 类型 多样性 描述 name 属性 必需的 节点的名称。 async 属性 {true|false},默认是false 如果设置为true,这个节点将会异步执行。请参考“第13章异步继续”。 transition 元素 [0..*] 离开转换。每个离开节点的转换必须有一个不同的名称,最多只允许所有离开转换中的一个没有名称。第一个转换被指定为默认转换,当离开节点而没有指定转换时,默认转换发生。 event 元素 [0..*] 支持的事件类型:{node-enter|node-leave}。 exception-handler 元素 [0..*] 一个异常处理器列表,用于这个流程节点中的委托类所抛出的所有异常。 timer 元素 [0..*] 指定一个定时器,用来监视节点中的一个执行所持续的时间。 3.3.6 task-node (任务节点) 其性质和node节点一样,在没有task的时候,也都是自动执行,不等待。task-node被归类为一个等待节点,是指在task-node中的task列表中的task没有全部执行完之前,它会一直等待。Task可以在task-node节点下定义,也可以挂在process-definition节点下。最普遍的方式是在task-node节点下定义一个或多个任务。默认情况下,流程在task-node节点会处于等待状态,直到所有的任务被执行完毕。Task的执行是按顺序执行的,任务都完成后,token仍然不会指向后面的节点;需要自己手动调用processInstance.signal()才会驱动流程到下面的节点。 名称 类型 多样性 描述 signal 属性 可选的 {unsynchronized|never|first|first-wait|last|last-wait},默认是last。signal指定了任务的完成对流程执行继续的影响。 create-tasks 属性 可选的 {yes|no|true|false},默认是true。当需要在运行时通过计算来决定哪个任务将被创建时,可以设置为false,如果这样的话,在node-enter事件上加一个动作,在动作中创建任务,并且把create-tasks设置为false。 end-tasks 属性 可选的 {yes|no|true|false},默认是false。如果设置end-tasks为true,在离开节点时,所有打开的任务将被结束。 task 元素 [0..*] 当执行到达本节点时所应被创建的任务。 普通节点元素 请参考普通节点元素。 为了帮助读者理解task-node节点的signal属性,这里举例如下: 对于这样的流程定义: <task-node name='a'> <task name='laundry' /> <task name='dishes' /> <task name='change nappy' /> <transition to='b' /> </task-node> a) 这里没有定义signal属性的值,这就表明当节点中的三个任务都完成后,流程才进入后面的节点 b) 当<task-node name='a' signal='unsynchronized'>表明token不会在本节点停留,而是直接到后面的节点 c) 当<task-node name='a' signal='never'>表明三个任务都完成后,token仍然不会指向后面的节点;需要自己手动调用processInstance.signal()才会驱动流程到下面的节点 d) 当<task-node name='a' signal='first'>表明只要有一个任务完成后,token就指向后面的节点 e) 当<task-node name='a' signal='first-wait'>表明当第一个任务实例完成时继续执行;当在a节点入口处没有任务创建时,token在a任务节点处等待,直到任务被创建或完成。 f) 当<task-node name='a' signal='last'>时,这是默认值,和不设置signal属性的情况相同。 g) 当<task-node name='a' signal='last-wait'>时,当最后一个任务实例完成时候继续执行下去。 当a这个任务节点没有任务被建立时,任务节点等待直到任务被建立。 3.3.7 fork(分支) 一个fork把一个执行路线分割成多个执行路线. 默认分支的行为是为每个离开分支转换建立一个子令牌,在令牌要到达的分支之间建立一个父母-子女关系 名称 类型 多样性 描述 name 属性 必需的 节点的名称。 async 属性 {true|false},默认是false 如果设置为true,这个节点将会异步执行。请参考“第13章异步继续”。 transition 元素 [0..*] 离开转换。每个离开节点的转换必须有一个不同的名称,最多只允许所有离开转换中的一个没有名称。第一个转换被指定为默认转换,当离开节点而没有指定转换时,默认转换发生。 event 元素 [0..*] 支持的事件类型:{node-enter|node-leave}。 exception-handler 元素 [0..*] 一个异常处理器列表,用于这个流程节点中的委托类所抛出的所有异常。 timer 元素 [0..*] 指定一个定时器,用来监视节点中的一个执行所持续的时间。 3.3.8 join(联合) 默认联合(join)假设所有来自同一个父母的子令牌联合,当在上使用fork(分支)这个情形就出现了并且所有令牌分支建立,并且到达同一个联合(join)。当全部令牌都进入联合的时候联合就结束了, 然后联合将检查父母-子女, 当所有兄弟令牌到达联合(join),父母令牌将传播(唯一的)离开转换,当还有兄弟令牌活动时,联合的行为将作为等待状态。 名称 类型 多样性 描述 name 属性 必需的 节点的名称。 async 属性 {true|false},默认是false 如果设置为true,这个节点将会异步执行。请参考“第13章异步继续”。 transition 元素 [0..*] 离开转换。每个离开节点的转换必须有一个不同的名称,最多只允许所有离开转换中的一个没有名称。第一个转换被指定为默认转换,当离开节点而没有指定转换时,默认转换发生。 event 元素 [0..*] 支持的事件类型:{node-enter|node-leave}。 exception-handler 元素 [0..*] 一个异常处理器列表,用于这个流程节点中的委托类所抛出的所有异常。 timer 元素 [0..*] 指定一个定时器,用来监视节点中的一个执行所持续的时间。 对于Join节点,我们知道默认是要等到所有分支都到了流程才能往下继续走,要改变这一情况,我们可以通过给该节点加Action的方法改变该Join节点的Discriminator,就可以使只要有一个分支到达流程就可以继续执行的效果了,如下面的Action: package workflow.test.action; //这里通过设置Discriminator可以实现只要有一个分支到达流程就可以继续了,它的默认值是false import org.jbpm.graph.def.ActionHandler; import org.jbpm.graph.exe.ExecutionContext; import org.jbpm.graph.node.Join; public class JoinAction implements ActionHandler{ public void execute(ExecutionContext arg0) throws Exception { Join join=(Join)arg0.getNode(); join.setDiscriminator(true); } } 3.3.9 decision(决策) 一个decision用以决定在多个执行路径中哪个才可以被执行。如果你是一个程序员,把它可以理解成switch case结构即可,一个decision能够具有许多离开的transition。 名称 类型 多样性 描述 handler 元素 要么指定“handler”元素,或者在转换上指定条件。 一个org.jbpm.jpdl.Def.DecisionHandler的实现名称。 transition 元素 [0..*] 离开转换。决策的离开转换可以被扩展为拥有一个条件,决策会查找条件计算为true的第一个转换,没有条件的转换被认为计算为true(为了建模“otherwise”分支)。请参考condition元素。 普通节点元素 请参考普通节点元素。 Handler所指定的DecisionHandler的实现类里的decide方法返回一个字符串,表示要执行哪个transition,如下例: package workflow.qingjia.shenpi.common; import org.jbpm.graph.exe.ExecutionContext; import org.jbpm.graph.node.DecisionHandler; public class ForkDecision implements DecisionHandler{ public String decide(ExecutionContext arg0) throws Exception { String dayCount=(String)arg0.getVariable("dayCount"); String go="to boss approve"; if(Integer.parseInt(dayCount)>10){ go="to join"; } return go; } } 3.3.10 transition(变迁) 变迁用来指定节点之间的连接。transition元素放在node里面,那么这个transition就会从这个节点出离开。 名称 类型 多样性 描述 name 属性 可选的 转换的名称。注意,每个节点的离开转换必须有一个不同的名称。 to 属性 必需的 目标节点的分级名称,有关分级名称的更多信息请参考“第9.6.3节分级命名”。 {action|script |create-timer |cancel-timer} 元素 [0..*] 发生转换时将要执行的动作。注意,转换的动作无需放入事件(因为只有一个事件)。 exception-handler 元素 [0..*] 一个异常处理器列表,用于这个流程节点中的委托类所抛出的所有异常。 3.3.11 event(事件) JBPM定义了一系列与工作流节点元素相关联的事件,例如,流程实例运行过程中,可以触发节点进入(node-enter)、节点离开 (node-leave)、流程启动(process-start)、流程结束(process-end)、任务创建(task-create)、 任务分派(task-assign)、任务启动(task-start)等事件。 在流程定义时,JBPM的事件均与action绑定。事件的触发将导致相应actions的执行。 名称 类型 多样性 描述 type 属性 必需的 表示相对于事件要放置的元素事件类型。 {action|script|create-timer| cancel-timer} 元素 [0..*] 在这个事件上将要执行的动作列表。 3.3.12 action(动作) 一个action是一段java代码。在流程执行期间在一些事件之上定义,这样会在相关事件触发时自动在工作流引擎上执行。 名称 类型 多样性 描述 name 属性 必需的 动作的名称。当动作被指定名称后,它们可以在流程定义中被查出,这对于运行时动作以及仅一次声明动作是有用的。 class 属性 或者用ref-name,或者用expression。 实现org.jbpm.graph.def.ActionHandler接口的类的全名。 ref-name 属性 或者用class。 所引用动作的名称。如果指定一个引用动作,则本动作不需要再做处理。 expression 属性 或者指定一个class,或者ref-name。 一个解决一个方法的jPDL表达式。请参考“第16.3节表达式”。 accept- propagated-events 属性 可选的 {yes|no|true|false},默认是yes|true。如果设置为false,则动作仅在本动作元素的触发事件上被执行。更多信息,请参考“第9.5.4 事件传播”。 config-type 属性 可选的 {field|bean|constructor|configuration-property}。指定动作对象将被怎样创建以及本元素的内容怎样象配置信息那样被动作对象所使用。 async 属性 {true|false} 默认false,这意味着动作将在当前执行的线程中被执行。如果设置为true,一个消息将被发送到命令执行器,并且执行器组件将在一个独立的事务中同步执行动作。 {内容} 可选的 action的内容可以被作为你定制动作实现的配置信息,这是考虑到可重用的委托类的创建。有关委托配置的更多信息,请参考“第16.2.3节委托配置”。 3.3.13 script(脚本) Script里是动作执行的beanshell脚本. 更多有关beanshell的的信息请参考Beanshell的网站: http://www.beanshell.org 。如下所示 <process-definition> <event type="node-enter"> <script> System.out.println("this script is entering node "+node); </script> </event> ... </process-definition> 表格 16.16 名称 类型 多样性 描述 name 属性 可选的 脚本动作的名称。当动作被指定名称后,它们可以在流程定义中被查出,这对于运行时动作以及仅一次声明动作是有用的。 Accept -propagated -events 属性 可选的[0..*] {yes|no|true|false},默认是yes|true。如果设置为false,则动作仅在本动作元素的触发事件上被执行。更多信息,请参考“第9.5.4 事件传播”。 expression 元素 [0..1] beanshell脚本。如果你没有指定variable元素,可以写表达式作为脚本元素的内容(忽略expression元素标签)。 variable 元素 [0..*] 脚本所需变量。如果没有指定变量,则当前令牌的所有变量将被装载到脚本,当你想要限制装载到脚本中的变量数量时使用variable。 3.3.14 expression(表达式) Expression里可书写Beanshell脚本 名称 类型 多样性 描述 {内容} 一个beanshell脚本。 3.3.15 variable(变量) 一个是变量是一种key-value对。它与过程实例(一次过程执行)相关联。Key是java.lang.string,value是任何java类型的任何pojo。所以任何是java类型,即使不给jbpm知道也能被应用到变量中。JBPM的流程变量在尽量模仿java.util.map的语义。这一点可以通过JBPM的API来了解。也就是说一个变量只能当它被插入时被赋值,任何java类型都可以作为变量中的value。 名称 类型 多样性 描述 name 属性 必需的 流程变量的名称。 access 属性 可选的 默认是read,write,用逗号分割的一个访问列表。迄今为止,使用的访问仅为read,write和required。 mapped-name 属性 可选的 默认是变量的名称。用来指定变量名称被映射的名称,mapped-name的含义依赖于这个元素所被使用的上下文。对于一个脚本,将是一个脚本变量名称;对于一个任务控制器,将是任务表单参数的标签;对于一个process-state,将是在子流程中使用的变量名称。 3.3.16 handler(句柄) Handler是在定义一个decision时需要为其定义一个DecisionHandler时采用。 名称 类型 多样性 描述 expression 属性 或者用class 一个jPDL表达式,返回结果被用toString()方法转换为字符串,结果字符串应该与某个离开转换匹配。请参考“第16.3 表达式”。 class 属性 或者用ref-name 实现了org.jbpm.graph.node.DecisionHandler接口的类的全名。 Config -type 属性 可选的 {field|bean|constructor|configuration-property}。指定动作对象将被怎样创建以及本元素的内容怎样象配置信息那样被动作对象所使用。 {内容} 可选的 action的内容可以被作为你定制动作实现的配置信息,这是考虑到可重用的委托类的创建。有关委托配置的更多信息,请参考“第16.2.3节委托配置”。 3.3.17 timer(定时器) 定时器timer可以被用于decision fork join node process-state state super-state task-node,可以设置开始时间duedate和频率repeat,定t器动作可以是所支持的任何动作元素,如action或script,会运行我们设置的动作。 timer 还有一个很重要的属性cancel-event,这个是timer和task结合时使用的,任务定时器的cancel-event可以被定制。默认情况 下,当任务被结束时(=完成)任务上的定时器将被取消,这是通过在定时器上使用cancel-event属性,流程开发者可以定制诸如task- assign或task-start。cancel-event支持多个事件,通过在属性中指定一个用逗号分割的列表,可以组合cancel-event 的类型。 名称 类型 多样性 描述 name 属性 可选的 定时器的名称。如果没有指定名称,则采用外部的节点名称。注意,每个定时器应该有一个唯一的名称。 duedate 属性 必需的 所指定的定时器创建到定时器执行之间的期限(可以用业务时间来表示)。请参考“第14.1节期限”中的语法。 repeat 属性 可选的 {duration|’yes’|’true’}当一个定时器在预期时间执行后,“repeat”可选项指定了在离开节点之前重复的执行定时器之间的期限。如果指定为true或yese,则与duedate相同的期限被使用。请参考“第14.1节期限”的语法。 transition 属性 可选的 当定时器执行、定时器事件触发后以及执行动作时时所使用的转换名称。 cancel-event 属性 可选的 这个属性只用在任务的定时器中,它指定了定时器将被取消的事件。默认是task-end事件,但是也可以被设置为如task-assign或task-start。cancel-event的类型也可以通过指定一个用逗号分割的列表被组合。 {action|script| create-timer| cancel-timer} 元素 [0..*] 当定时器被触发时所应被执行的动作。 3.3.18 create-timer(创建定时器) Create-timer是定时器的创建 名称 类型 多样性 描述 name 属性 可选的 定时器的名称。这个名称可被用于用一个cancel-timer动作取消定时器。 duedate 属性 必需的 所指定的定时器创建到定时器执行之间的期限(可以用业务时间来表示)。请参考“第14.1节期限”中的语法。 repeat 属性 可选的 {duration|’yes’|’true’}当一个定时器在预期时间执行后,“repeat”可选项指定了在离开节点之前重复的执行定时器之间的期限。如果指定为true或yese,则与duedate相同的期限被使用。请参考“第14.1节期限”的语法。 transition 属性 可选的 当定时器执行、定时器事件触发后以及执行动作时时(如果要)所获取的转换名称。 3.3.19 cancel-timer(取消定时器) Cancel-timer是定时器的取消 名称 类型 多样性 描述 name 属性 可选的 要被取消的定时器的名称。 3.3.20 task(任务) Task 是是流程定义里的一部分,它决定了task instance的创建和分配 名称 类型 多样性 描述 name 属性 可选的 任务的名称。命名的任可以被引用并且可以通过TaskMgmtDefinition被查出。 blocking 属性 可选的 {yes|no|true|false},默认是false。如果blocking设置为true,当任务没有结束时节点不能被离开;如果设置为false(默认),令牌上的一个新号被用来继续执行并离开节点。默认设置为false,因为通常是由用户接口来强制阻塞。 signalling 属性 可选的 {yes|no|true|false},默认是true。如果设置signalling为false,则本任务将没有触发令牌继续的能力。 duedate 属性 可选的 一个绝对的期限表达式或象“第14章业务日历”中解释的业务时间。 swimlane 属性 可选的 引用一个swimlane,如果在任务上指定了一个swimlane,则assignment将被忽略。 priority 属性 可选的 {highest,high,normal,low,lowest}之一。作为选择,可以为priority指定任何整数,供参考:(highest=1,lowest=5)。 assignment 元素 可选的 描写一个委托,该委托将在任务被创建时把任务分配给一个参与者。 event 元素 [0..*] 支持的事件类型:{task-create|task-start|task-assign|task-end}。为了任务分配,我们特别的为TaskInstance添加了一个非持久化的属性previousActorId。 exception -handler 元素 [0..*] 一个异常处理器列表,用于这个流程节点中的委托类所抛出的所有异常。 timer 元素 [0..*] 指定一个监视本任务执行期限的一个定时器。对于任务定时器特殊的是可以指定cancel-event,cancel-event默认是task-end,但是它可以被自定义如task-assign或task-start。 controller 元素 [0..1] 指定流程变量怎样被转换为任务表单参数。任务表单参数有用户界面使用,用力向用户表现一个任务表单。 3.3.21 swimlane(泳道) 实际应用中,一个人是一个流程中多个Task的参与者(actor)的情况是很常见的。在jbpm中通过创建一个swimlane并且把swimlane赋给一个task的方式来设置当前task的参与者(actor)。一个业务流程中的swimlane可以被看做为一个参与者的参与者对象的名称,当然它不一定是固定的某个人,它可以是一个用户组,一个特定用户的角色等。首次执行到达一个Task,赋给该Task的一个swimlane就会算出参与者(actor)。 名称 类型 多样性 描述 name 属性 必需的 泳道的名称。泳道可以被引用并且可以通过TaskMgmtDefinition被查出。 assignment 元素 [1..1] 指定泳道的分配。这个分配在本泳道中的第一个任务实例被创建时完成。 3.3.22 assignment(委派) 当流程执行到某个Task的时候,引时流程引挚要调用相应的swimlane或assignment将当前的task分配(委派)给某个参与者,外部参与者可以是一个人也可以是某个系统等。 名称 类型 多样性 描述 expression 属性 可选的 由于历史原因,这个属性的表达式不是jPDL表达式,而是对jBPM身份组件的一个分配表达式。有关怎样写jBPM身份组件表达式的更多信息,请参考“第11.11.2节分配表达式”。注意,这个依赖于jbpm身份组件。 actor-id 属性 可选的 一个actorId,可以与pooled-actors协同使用。actor-id被作为一个表达式,因此你可以引用一个固定的actorId,如actor-id=”bobthebuiler”;或者你可以引用一个可以返回一个字符串的属性或方法,如actor-id=”myVar.actorId”,这将调用任务实例变量“myVar”上的getActorId方法。 Pooled -actors 属性 可选的 一个逗号分割的actorId列表,可以与actor-id协同使用。一个固定的参与者池可以指定如下:pooled-actors=”chicagobulls,pointersisters”。 pooled-actors被作为一个表达式,因此你可以引用一个返回String[]、Collection、或一个逗号分割的池中的参与者列表的属性或方法。 class 属性 可选的 一个实现org.jbpm.taskmgmt.def.AssignmentHandler接口的类的全名称。 config-type 属性 可选的 {field|bean|constructor|configuration-property}。指定分配处理器对象(assignment-handler-object)对象将被怎样创建以及本元素的内容怎样象配置信息那样被分配处理器对象所使用。 {内容} 可选的 assignment元素的内容可以被作为分配处理器(AssignmentHandler)实现的配置信息,这是考虑到可重用的委托类的创建。有关委托配置的更多信息,请参考“第16.2.3节委托配置”。 3.3.23 controller(控制器) 在任务执行时,可能需要读、写流程变量;在任务完成并提交时,可能需要写流程变量。为此,jBPM提供了"任务变量"的概念。在某些情况下,任务变量和流 程变量并非简单的一一对应关系,例如,三个流程变量代表三个月的销售额,任务变量只需要它们的平均值。为实现任务与流程实例之间的信息交流,jBPM设置 了任务控制器机制。该机制也采用递进模式:首先,jBPM提供基本(默认)的任务控制器;如果不敷使用,二次开发人员可以使用自定义的任务控制器。 jBPM的任务控制器机制在流程变量和任务变量之间架起了一座桥梁。 名称 类型 多样性 描述 class 属性 可选的 一个实现org.jbpm.taskmgmt.def.TaskControllerHandler接口的类的全名称。 Config -type 属性 可选的 {field|bean|constructor|configuration-property}。指定分配处理器对象(assignment-handler-object)对象将被怎样创建以及本元素的内容怎样象配置信息那样被分配处理器对象所使用。 {内容} controller元素的内容要么是指定的任务控制处理器的配置信息(如果指定了class属性),要么必须是一个variable元素列表(如果没有指定任务控制器)。 variable 元素 [0..*] 如果没有通过class属性指定任务控制处理器,则controller元素的内容必须是变量列表。 3.3.24 process-state 子流程 process-state是JBPM提供的用来处理子流程的节点,一个process-state只能对应一个子流程,究竟指到哪个子流程可以在process-state的action里指定,当token执行到指定的子流程时,子流程就已经启动,不用像启动主流程一样手工启动子流程。其它部分的处理就和普通的流程没有区别了。 名称 类型 多样性 描述 name 属性 必需的 名称。 3.3.25 condition 条件 名称 类型 多样性 描述 {内容}或属性 表达式 必需的 condition元素的内容是一个计算结果为布尔值的jPDL表达式。决策采用第一个表达式处理结果为true的转换(按在processdefinition.xml中的顺序),如果没有条件处理结果为true,则采用默认离开转换(也就是第一个)。 3.3.26 exception-handler 异常处理 Jbpm的异常处理机制仅仅集中于java异常,流程定义本身的执行不会导致什么异常,只有在执行委托类时才会导致异常。 在流程定义(process-definitions)、节点(nodes)和转换(transitions)上,可以指定一个异常处理(exception-handlers)清单,每个异常处理(exception-handler)有一个动作列表,当在委托类中发生异常时,会在流程元素的父层次搜索一个适当的异常处理(exception-handler),当它被搜索到,则异常处理(exception-handler)的动作将被执行。 注意,Jbpm的异常处理机制与java异常处理不完全相似。在java中,一个捕获的异常可以影响控制流,而在Jbpm中,流程不会被Jbpm异常处理机制所改变。异常要么被捕获,要么不捕获,没有被捕获的异常被抛向客户端(例如客户端调用token.signal()),而被捕获的异常则是通过Jbpm的exception-handler,对于被捕获的异常,图执行仍会继续,就像没有异常发生一样。 注意,在处理异常的动作中,可以使用Token.setNode(Node node)把令牌放入图中的任何节点。 名称 类型 多样性 描述 exception-class 属性 可选的 指定与本异常处理器所匹配的java throwable类,如果这个没有指定这个属性,则它匹配所有异常(java.lang.Throwable)。 action 元素 [1..*] 当异常被异常处理器捕获时将要执行的动作列表。 小结 看到这里,我们已经对JPDL的流程定义语言有了较深的理解,接下来我们可以自己动手写一些流程定义的文件,以此加深对JPDL的理解。我们来看一下下面的流程定义文件内容: <?xml version="1.0" encoding="UTF-8"?> <process-definition xmlns="" name="test"> <!—定义一个开始结点,名为start,指向fork1--> <start-state name="start"> <transition name="" to="fork1"></transition> </start-state> <!—在fork1分支结点上,我们定义了两个走向(transition)tr1和tr2,其中tr1指向top-state节点,tr2指向一个process-state,当token到达for1时会自动形成两个child token,沿着tr1和tr2的指向继续向执行--> <fork name="fork1"> <transition name="tr1" to="top-state"></transition> <transition name="tr2" to="test-sub-process"></transition> </fork> <!—top-state是一个state类型的节点,也就是前面提到的手工节点--> <state name="top-state"> <transition name="to test-task" to="test-task"></transition> </state> <!—test-task是一个task-node类型的节点,它可以有多个task节点,生成我们的taskInstance,这里我们定义了三个节点--> <task-node name="test-task" signal="first"> <task name="task-a"></task> <task name="task-b"></task> <task name="task-c"></task> <transition name="to buttom-node" to="buttom-node"></transition> </task-node> <!-- buttom-node 是一个node节点,可以自动执行,不用人工干预处理--> <node name="buttom-node"> <transition name="" to="join1"></transition> </node> <!—在test-sub-process里我们加上了一个子流程处理,子流程定义我们写在了里面定义的enter-sub-process-action 里--> <process-state name="test-sub-process"> <event type="node-enter"> <action name="enter-sub-process-action" class="gaojie.process.action.EnterSubProcessAction"></action> </event> <transition name="" to="join1"></transition> </process-state> <!—join1是一个join节点,与fork节点对应,从fork分支出发的所有child token汇集到join后继续向下执行--> <join name="join1"> <transition name="" to="end"></transition> </join> <!—最后是结束结点,流程执行到此就宣告结束了--> <end-state name="end"></end-state> </process-definition> <!----> |
相关推荐
通过学习和实践,开发者可以熟练掌握jbpm工作流的使用,从而提升企业的业务流程自动化水平。无论是对于初学者还是有经验的开发者,深入理解jbpm的工作原理和整合方法都是至关重要的,它可以帮助构建出高效、灵活且...
【JBPM工作流全套学习资料】是一份详尽的学习资源,涵盖了JBPM工作流系统的基础到高级知识。JBPM(Java Business Process Management)是开源的企业级工作流管理系统,它允许开发者设计、部署和执行业务流程。这个...
【工作流程JBPM工作流管理】是企业信息化建设中至关重要的一环,它涉及到组织内部的任务自动化、业务流程优化以及跨部门协作效率的提升。JBPM(JBoss Business Process Management)是Red Hat公司推出的一款开源的...
jbpm工作流引擎基于J2EE的轻量级,纯java,开源的工作流管理系统。
jbpm工作流是一款开源的工作流程管理系统,主要用于设计、执行和管理业务流程。它结合了Java技术和BPM(Business Process Management)理念,为开发者提供了一套强大的工具,使得企业能够更有效地自动化和优化业务...
对于初学者而言,通过实践jbpm的简单实例,可以快速掌握工作流的基本概念和操作,为进一步深入学习和应用奠定基础。在实际项目中,jbpm可以有效地提高工作效率,减少人为错误,提升业务流程的规范化和智能化水平。
jbpm工作流学习资料大全是一份综合性的资源集合,涵盖了jbpm工作流的各个方面,适合初学者和进阶者深入理解这一技术。jbpm(Java Business Process Management)是一款开源的工作流管理系统,它允许开发者设计、执行...
【李腾飞JBPM工作流引擎代码test01到test04】是一系列关于使用JBPM工作流引擎进行程序开发的示例代码。...每个test文件代表一个逐步进阶的实践案例,对于学习和理解JBPM工作流引擎的运作机制非常有帮助。
JBPM工作流技术是Java业务流程管理的简称,是一种用于管理业务流程的开源框架。JBPM遵循业务流程管理(BPM)的标准,通过定义和管理工作流的活动(即任务点或活动点)来实现业务流程的自动化。JBPM提供了一套完整的...
**jBPM工作流详解** jBPM,全称Java Business Process Management,是Red Hat公司开发的一款开源的工作流管理系统,它提供了对业务流程的建模、执行和监控能力。jBPM不仅支持传统的工作流标准,如BPMN 2.0,还集成...
**JBPM工作流详解** JBPM(Java Business Process Management)是一个开源的工作流管理系统...通过学习并实践如"销售批复"这样的具体例子,我们可以更好地理解和掌握JBPM的使用,从而在实际工作中提升流程管理的能力。
本指南由胡奇编写,旨在为开发者提供一个全面的参考,帮助他们快速学习和掌握使用jBPM4进行工作流应用的开发。 ### 标题知识点: - **工作流应用开发:** 工作流应用开发是指通过建立工作流模型,使用计算机程序来...
jbpm(Java Business Process Management)是一款开源的工作流引擎,它为业务流程自动化提供了一套强大的框架。jbpm致力于实现业务流程的建模、部署、执行和监控,是基于Java技术的,因此它天然地适用于Java开发环境...
**基于JBPM工作流的OA办公系统** JBPM(Java Business Process Management)是Talend公司推出的一款开源的工作流管理系统,主要用于实现业务流程自动化。它提供了全面的工作流解决方案,包括流程设计、执行、监控和...
【jbpm工作流详解】 工作流(Workflow)是业务过程在计算机环境下的自动化体现,旨在使多参与者间按照预定义规则传递文档、信息或任务,以达成特定的业务目标。工作流管理系统(WfMS)是实现这一目标的关键,它负责...
JBPM 工作流引擎内核设计思想及构架笔记分享 上文提到,工作流引擎内核是一种微内核的流程引擎架构,它只包含最基本的对象和服务,以及用于解决流程运行问题的调度机制和执行机制。引擎内核的设计思想是围绕着如何...
JBPM工作流引擎是一种基于Java的开源工作流管理系统,它允许开发者和企业构建、部署和管理业务流程。JBPM提供了全面的工作流解决方案,包括流程设计、执行、监控和优化,旨在提高工作效率,简化复杂的业务操作。 ...
jbpm工作流请假案例是一个基于jbpm流程引擎的实践项目,旨在帮助用户理解并学习如何在实际场景中应用工作流技术。jbpm是一款开源的工作流管理系统,它提供了强大的流程建模、执行和监控功能,广泛应用于企业级业务...
Jbpm是一个开源的工作流管理系统,它用于自动化和管理复杂的业务流程。理解Jbpm的工作流编程步骤全过程有助于我们构建高效、可维护的企业级应用程序。下面将详细解释Jbpm中的关键概念和编程步骤。 1. **工作流基础...
jbpm开发指南 jbpm开发指南 jbpm 工作流 自定义