流程定义语言

CompanyDocumentnumber：WUUT-WUUY-WBBGB-BWYTT-1982GTCompanyDocumentnumber：WUUT-WUUY-WBBGB-BWYTT-1982GT流程定义语言一JPDL流程定义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..*]一个异常处理器列表，用于这个流程定义中的委托类所抛出的所有异常。node(自动节点)这种节点和State相反，也称自动节点。当业务程序实例执行到这个节点，不会停止执行。而是会继续往下执行。如果该节点存在多个离开转向。那么，就会执行其中的第一个离开转向，在Node状态中，不需要外部参与者的参与，业务流程的这个部分是自动的、即时完成的。名称类型数量描述action|script|create-timer|cancel-timer事件1用于表示这个节点行为的定制动作。普通节点元素请参考普通节点元素。start-state(开始状态)start-state是我们整个流程的开始节点，所有的流程实例从这里开始。名称类型数量描述Name属性可选的节点的名称。Task元素[0..1]起始一个流程实例的任务，或者用来捕获流程发起者Event元素[0..*]支持的事件类型：｛node-leave｝。transition元素[0..*]离开转换，每个离开节点的转换必须有一个不同的名称。exception-handler元素[0..*]一个异常处理器列表，用于这个流程节点中的委托类所抛出的所有异常。end-state(结束节点)对于每一个流程定义都会有一个结束节点，与开始节点对应名称类型数量描述Name属性必需的结束状态的名称。event元素[0..*]支持的事件类型：｛node-enter｝。exception-handler元素[0..*]一个异常处理器列表，用于这个流程节点中的委托类所抛出的所有异常。state(状态) State节点也叫手工节点，进入到这种节点，整个流程的执行就会中断。直到系统外参与者发起继续执行的命令，即调用signal或end方法，业务程序实例的执行才能够继续下去。名称类型数量描述name属性必需的节点的名称。async属性{true|false}，默认是false如果设置为true，这个节点将会异步执行。请参考”异步执行”章节。transition元素[0..*]离开转换。每个离开节点的转换必须有一个不同的名称，最多只允许所有离开转换中的一个没有名称。第一个转换被指定为默认转换，当离开节点而没有指定转换时，默认转换发生。event元素[0..*]支持的事件类型：｛node-enter|node-leave｝。exception-handler元素[0..*]一个异常处理器列表，用于这个流程节点中的委托类所抛出的所有异常。timer元素[0..*]指定一个定时器，用来监视节点中的一个执行所持续的时间。task-node(任务节点)其性质和node节点一样，在没有task的时候，也都是自动执行，不等待。task-node被归类为一个等待节点，是指在task-node中的task列表中的task没有全部执行完之前，它会一直等待。Task可以在task-node节点下定义，也可以挂在process-definition节点下。最普遍的方式是在task-node节点下定义一个或多个任务。默认情况下，流程在task-node节点会处于等待状态，直到所有的任务被执行完毕。Task的执行是按顺序执行的，任务都完成后，token仍然不会指向后面的节点；需要自己手动调用()才会驱动流程到下面的节点。名称类型数量描述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-nodename='a'><taskname='laundry'/><taskname='dishes'/><taskname='changenappy'/><transitionto='b'/></task-node>这里没有定义signal属性的值，这就表明当节点中的三个任务都完成后，流程才进入后面的节点当<task-nodename='a'signal='unsynchronized'>表明token不会在本节点停留，而是直接到后面的节点当<task-nodename='a'signal='never'>表明三个任务都完成后，token仍然不会指向后面的节点；需要自己手动调用()才会驱动流程到下面的节点当<task-nodename='a'signal='first'>表明只要有一个任务完成后，token就指向后面的节点当<task-nodename='a'signal='first-wait'>表明当第一个任务实例完成时继续执行；当在a节点入口处没有任务创建时，token在a任务节点处等待，直到任务被创建或完成。当<task-nodename='a'signal='last'>时，这是默认值，和不设置signal属性的情况相同。当<task-nodename='a'signal='last-wait'>时，当最后一个任务实例完成时候继续执行下去。当a这个任务节点没有任务被建立时,任务节点等待直到任务被建立。fork(分支)一个fork把一个执行路线分割成多个执行路线.默认分支的行为是为每个离开分支转换建立一个子令牌,在令牌要到达的分支之间建立一个父母-子女关系名称类型数量描述name属性必需的节点的名称。async属性{true|false}，默认是false如果设置为true，这个节点将会异步执行。请参考”异步执行”章节。transition元素[0..*]离开转换。每个离开节点的转换必须有一个不同的名称，最多只允许所有离开转换中的一个没有名称。第一个转换被指定为默认转换，当离开节点而没有指定转换时，默认转换发生。event元素[0..*]支持的事件类型：｛node-enter|node-leave｝。exception-handler元素[0..*]一个异常处理器列表，用于这个流程节点中的委托类所抛出的所有异常。timer元素[0..*]指定一个定时器，用来监视节点中的一个执行所持续的时间。join(联合)默认联合(join)假设所有来自同一个父母的子令牌联合，当在上使用fork(分支)这个情形就出现了并且所有令牌分支建立，并且到达同一个联合(join)。当全部令牌都进入联合的时候联合就结束了，然后联合将检查父母-子女，当所有兄弟令牌到达联合(join)，父母令牌将传播(唯一的)离开转换，当还有兄弟令牌活动时，联合的行为将作为等待状态。名称类型数量描述name属性必需的节点的名称。async属性{true|false}，默认是false如果设置为true，这个节点将会异步执行。transition元素[0..*]离开转换。每个离开节点的转换必须有一个不同的名称，最多只允许所有离开转换中的一个没有名称。第一个转换被指定为默认转换，当离开节点而没有指定转换时，默认转换发生。event元素[0..*]支持的事件类型：｛node-enter|node-leave｝。exception-handler元素[0..*]一个异常处理器列表，用于这个流程节点中的委托类所抛出的所有异常。timer元素[0..*]指定一个定时器，用来监视节点中的一个执行所持续的时间。对于Join节点，我们知道默认是要等到所有分支都到了流程才能往下继续走，要改变这一情况，我们可以通过给该节点加Action的方法改变该Join节点的Discriminator，就可以使只要有一个分支到达流程就可以继续执行的效果了decision(决策)一个decision用以决定在多个执行路径中哪个才可以被执行。如果你是一个程序员，把它可以理解成switchcase结构即可，一个decision能够具有许多离开的transition。名称类型数量描述handler元素要么指定“handler”元素，或者在转换上指定条件。一个的实现名称。transition元素[0..*]离开转换。决策的离开转换可以被扩展为拥有一个条件，决策会查找条件计算为true的第一个转换，没有条件的转换被认为计算为true（为了建模“otherwise”分支）。请参考。请参考。Handler所指定的DecisionHandler的实现类里的decide方法返回一个字符串，表示要执行哪个transitiontransition(转换)转换用来指定节点之间的连接。transition元素放在node里面，那么这个transition就会从这个节点出离开。名称类型数量描述name属性可选的转换的名称。注意，每个节点的离开转换必须有一个不同的名称。to属性必需的目标节点的分级名称，表示将要达到的那个节点名称.action|script|create-timer|cancel-timer元素[0..*]发生转换时将要执行的动作。注意，转换的动作无需放入事件（因为只有一个事件）。exception-handler元素[0..*]一个异常处理器列表，用于这个流程节点中的委托类所抛出的所有异常。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..*]在这个事件上将要执行的动作列表。action(动作)一个action是一段java代码。在流程执行期间在一些事件之上定义，这样会在相关事件触发时自动在工作流引擎上执行。名称类型数量描述name属性必需的动作的名称。当动作被指定名称后，它们可以在流程定义中被查出，这对于运行时动作以及仅一次声明动作是有用的。class属性或者用ref-name，或者用expression。实现接口的类的全名。ref-name属性或者用class。所引用动作的名称。如果指定一个引用动作，则本动作不需要再做处理。expression属性或者指定一个class，或者ref-name。一个解决一个方法的jPDL表达式。accept-propagated-events属性可选的{yes|no|true|false}，默认是yes|true。如果设置为false，则动作仅在本动作元素的触发事件上被执行。更多信息，请参考“”。config-type属性可选的{|||}。指定动作对象将被怎样创建以及本元素的内容怎样象配置信息那样被动作对象所使用。async属性{true|false}默认false，这意味着动作将在当前执行的线程中被执行。如果设置为true，一个消息将被发送到命令执行器，并且执行器组件将在一个独立的事务中同步执行动作。请参考”异步执行”章节。{内容}可选的action的内容可以被作为你定制动作实现的配置信息，这是考虑到可重用的委托类的创建。有关委托配置的更多信息，请参考“”。script(脚本)Script里是动作执行的beanshell脚本.名称类型数量描述name属性可选的脚本动作的名称。当动作被指定名称后，它们可以在流程定义中被查出，这对于运行时动作以及仅一次声明动作是有用的。Accept-propagated-events属性可选的[0..*]{yes|no|true|false}，默认是yes|true。如果设置为false，则动作仅在本动作元素的触发事件上被执行.expression元素[0..1]beanshell脚本。如果你没有指定元素，可以写表达式作为脚本元素的内容（忽略expression元素标签）。variable元素[0..*]脚本所需变量。如果没有指定变量，则当前令牌的所有变量将被装载到脚本，当你想要限制装载到脚本中的变量数量时使用variable。expression（表达式）Expression里可书写Beanshell脚本名称类型数量描述{内容}一个beanshell脚本。variable(变量)一个是变量是一种key-value对。它与过程实例（一次过程执行）相关联。Key是，value是任何java类型的任何pojo。所以任何是java类型，即使不给jbpm知道也能被应用到变量中。JBPM的流程变量在尽量模仿的语义。这一点可以通过JBPM的API来了解。也就是说一个变量只能当它被插入时被赋值，任何java类型都可以作为变量中的value。名称类型数量描述name属性必需的流程变量的名称。access属性可选的默认是read,write，用逗号分割的一个访问列表。迄今为止，使用的访问仅为read，write和required。mapped-name属性可选的默认是变量的名称。用来指定变量名称被映射的名称，mapped-name的含义依赖于这个元素所被使用的上下文。对于一个脚本，将是一个脚本变量名称；对于一个任务控制器，将是任务表单参数的标签；对于一个process-state，将是在子流程中使用的变量名称。handler(句柄)Handler是在定义一个decision时需要为其定义一个DecisionHandler时采用。名称类型数量描述expression属性或者用class一个jPDL表达式，返回结果被用toString()方法转换为字符串，结果字符串应该与某个离开转换匹配。class属性或者用ref-name实现了接口的类的全名。Config-type属性可选的{|||}。指定动作对象将被怎样创建以及本元素的内容怎样象配置信息那样被动作对象所使用。{内容}可选的Action里的内容可以用来帮助结合我们的业务来处理我们的流程,同时我们可以在Action里加上业务处理逻辑,以更好的利用流程.timer(定时器)定时器timer可以被用于decisionforkjoinnodeprocess-statestatesuper-statetask-node，可以设置开始时间duedate和频率repeat，定时器动作可以是所支持的任何动作元素，如action或script。timer还有一个很重要的属性cancel-event，这个是timer和task结合时使用的，任务定时器的cancel-event可以被定制。默认情况下，当任务被结束时（=完成）任务上的定时器将被取消，这是通过在定时器上使用cancel-event属性，流程开发者可以定制诸如task-assign或task-start。cancel-event支持多个事件，通过在属性中指定一个用逗号分割的列表，可以组合cancel-event的类型。名称类型数量描述name属性可选的定时器的名称。如果没有指定名称，则采用外部的节点名称。注意，每个定时器应该有一个唯一的名称。duedate属性必需的所指定的定时器创建到定时器执行之间的期限（可以用业务时间来表示）。repeat属性可选的{duration|yes|true}当一个定时器在预期时间执行后，“repeat”可选项指定了在离开节点之前重复的执行定时器之间的期限。如果指定为true或false，则与duedate相同的期限被使用。transition属性可选的当定时器执行、定时器事件触发后以及执行动作时时所使用的转换名称。cancel-event属性可选的这个属性只用在任务的定时器中，它指定了定时器将被取消的事件。默认是task-end事件，但是也可以被设置为如task-assign或task-start。cancel-event的类型也可以通过指定一个用逗号分割的列表被组合。action|script|create-timer|cancel-timer元素[0..*]当定时器被触发时所应被执行的动作。create-timer(创建定时器)Create-timer是定时器的创建名称类型数量描述name属性可选的定时器的名称。这个名称可被用于用一个cancel-timer动作取消定时器。duedate属性必需的所指定的定时器创建到定时器执行之间的期限（可以用业务时间来表示）。请参考“”中的语法。repeat属性可选的{duration|’yes’|’true’}当一个定时器在预期时间执行后，“repeat”可选项指定了在离开节点之前重复的执行定时器之间的期限。如果指定为true或yese，则与duedate相同的期限被使用。请参考“”的语法。transition属性可选的当定时器执行、定时器事件触发后以及执行动作时时（如果要）所获取的转换名称。cancel-timer(取消定时器)Cancel-timer是定时器的取消名称类型数量描述name属性可选的要被取消的定时器的名称。task(任务)Task是是流程定义里的一部分，它决定了taskinstance的创建和分配名称类型数量描述name属性可选的任务的名称。命名的任可以被引用并且可以通过TaskMgmtDefinition被查出。blocking属性可选的{yes|no|true|false}如果blocking设置为true，当任务没有结束时节点不能被离开（必须要通过()方法离开节点）；如果设置为false（默认），允许用户通过signal继续执行和离开节点。默认设置为false，因为通常是由用户接口来强制阻塞。signalling属性可选的{yes|no|true|false}，默认是true。如果设置signalling为false，则任务没有触发令牌继续的能力。duedate属性可选的延迟时间（任务执行的的延迟时间）。请见业务日历中的解释。swimlane属性可选的引用一个，如果在任务上指定了一个swimlane，则assignment将被忽略。priority属性可选的{highest,high,normal,low,lowest}之一。作为选择，可以为priority指定任何整数，供参考：(highest=1,lowest=5)。元素可选的描写一个，该委托将在任务被创建时把任务分配给一个参与者。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]指定流程变量怎样被转换为任务表单参数。任务表单参数有用户界面使用，用力向用户表现一个任务表单。swimlane(泳道)实际应用中，一个人是一个流程中多个Task的参与者(actor)的情况是很常见的。在jbpm中通过创建一个swimlane并且把swimlane赋给一个task的方式来设置当前task的参与者（actor）。一个业务流程中的swimlane可以被看做为一个参与者的参与者对象的名称，当然它不一定是固定的某个人，它可以是一个用户组，一个特定用户的角色等。首次执行到达一个Task，赋给该Task的一个swimlane就会算出参与者(actor)。名称类型数量描述name属性必需的泳道的名称。泳道可以被引用并且可以通过TaskMgmtDefinition被查出。assignment元素[1..1]指定泳道的分配。这个分配在本泳道中的第一个任务实例被创建时完成。assignment(委派)当流程执行到某个Task的时候，引时流程引挚要调用相应的swimlane或assignment将当前的task分配（委派）给某个参与者，外部参与者可以是一个人也可以是某个系统等。名称类型数量描述expression属性可选的由于历史原因，这个属性的表达式不是，而是对jBPM身份组件的一个分配表达式。actor-id属性可选的一个actorId，可以与pooled-actors协同使用。actor-id被作为，因此你可以引用一个固定的actorId，如actor-id=”bobthebuiler”；或者你可以引用一个可以返回一个字符串的属性或方法，如actor-id=””，这将调用任务实例变量“myVar”上的getActorId方法。Pooled-actors属性可选的一个逗号分割的actorId列表，可以与actor-id协同使用。一个固定的参与者池可以指定如下：pooled-actors=”chicagobulls,pointersisters”。pooled-actors被作为，因此你可以引用一个返回String[]、Collection、或一个逗号分割的池中的参与者列表的属性或方法。class属性可选的一个实现接口的类的全名称。config-type属性可选的{|||}。指定分配处理器对象（assignment-handler-object）对象将被怎样创建以及本元素的内容怎样象配置信息那样被分配处理器对象所使用。{内容}可选的assignment元素的内容可以被作为分配处理器（AssignmentHandler）实现的配置信息，这是考虑到可重用的委托类的创建。controller(控制器)在任务执行时，可能需要读、写流程变量；在任务完成并提交时，可能需要写流程变量。为此，jBPM提供了"任务变量"的概念。在某些情况下，任务变量和流程变量并非简单的一一对应关系，例如，三个流程变量代表三个月的销售额，任务变量只需要它们的平均值。为实现任务与流程实例之间的信息交流，jBPM设置了任务控制器机制。该机制也采用递进模式：首先，jBPM提供基本（默认）的任务控制器；如果不敷使用，二次开发人员可以使用自定义的任务控制器。jBPM的任务控制器机制在流程变量和任务变量之间架起了一座桥梁。名称类型数量描述class属性可选的一个实现接口的类的全名称。Config-type属性可选的{|||}。指定分配处理器对象（assignment-handler-object）对象将被怎样创建以及本元素的内容怎样象配置信息那样被分配处理器对象所使用。{内容}controller元素的内容要么是指定的任务控制处理器的配置信息（如果指定了class属性），要么必须是一个variable元素列表（如果没有指定任务控制器）。variable元素[0..*]如果没有通过class属性指定任务控制处理器，则controller元素的内容必须是变量列表。process-state子流程process-state是JBPM提供的用来处理子流程的节点，一个process-state只能对应一个子流程，究竟指到哪个子流程可以在process-state的action里指定，当token执行到指定的子流程时，子流程就已经启动，不用像启动主流程一样手工启动子流程。其它部分的处理就和普通的流程没有区别了。名称类型数量描述name属性必需的名称。Sub-process元素只能定义一个子流程variable变量[0…*]Variable是用来指定如何把数据从父流程copy到子流程sub-process子流程名称类型数量描述name属性必需的子流程的名称version属性可选子流程的版本。如果没有指定该属性，默认将会采且该子流程的最后一个版本condition条件名称类型数量描述{内容}或属性表达式必需的condition元素的内容是一个计算结果为布尔值的jPDL表达式。决策采用第一个表达式处理结果为true的转换（按在中的顺序），如果没有条件处理结果为true，则采用默认离开转换（也就是第一个）。exception-handler异常处理Jbpm的异常处理机制仅仅集中于java异常，流程定义本身的执行不会导致什么异常，只有在执行委托类时才会导致异常。

在流程定义（process-definitions）添加的exception-handler对整个流程起作用、节点（nodes）上添加异常只对当前的节点起作用（同时如果在process-definitions里也设置了exception-handler那么将不会再执行process-definitions里的exception-handler），和转换（transitions）添加exception-handler只对当前的transitions起作用（同时如果在process-definitions里也设置了exception-handler那么将不会再执行process-definitions里的exception-handler），可以指定一个异常处理（exception-handlers）清单，每个异常处理（exception-handler）有一个动作列表，当在委托类中发生异常时，会在流程元素的父层次搜索一个适当的异常处理（exception-handler），当它被搜索到，则异常处理（exception-handler）的动作将被执行。

注意，Jbpm的异常处理机制与java异常处理不完全相似。在java中，一个捕获的异常可以影响控制流，而在Jbpm中，流程不会被Jbpm异常处理机制所改变。异常要么被捕获，要么不捕获，没有被捕获的异常被抛向客户端（例如客户端调用()），而被捕获的异常则是通过Jbpm的exception-handler，对于被捕获的异常，图执行仍会继续，就像没有异常发生一样。

在处理异常的动作中，可以使用(Nodenode)把令牌放入图中的任何节点。名称类型数量描述exception-class属性可选的指定与本异常处理器所匹配的javathrowable类，如果这个没有指定这个属性，则它匹配所有异常（）。action元素[1..*]当异常被异常处理器捕获时将要执行的动作列表。二XPDL元模型定义了流程定义里所包含的实体、它们的关系以及属性，其中属性不仅仅为了执行需要，很多属性是为了统计与监控的需要。包（Package）流程模型包含许多作用域大于流程定义的实体，例如参与者声明、应用程序声明和相关数据元素，它们可能被多个流程定义所引用。为了避免每个流程定义都重复定义这些实体，XPDL引入包的概念，包作为流程定义的容器，对流程定义按照关联性进行分组。在包上定义的实体被其包含的流程定义继承，同时，包能够为所属流程定义声明一系列的通用属性，例如作者、版本号、状态等。XPDL里的包等价于BPMN里的业务流程图（BusinessProcessDiagram）。泳道（Swimlanes）泳道被用来对流程定义和活动进行布局。我们使用泳道在流程级别上定义参与者信息（部门、公司），在活动级别上定义执行者信息（角色、人员）。我们使用一系列非重叠的长方形来描述泳道，这些长方形称为池（Pool），同时，池又被细分为一系列的子泳道（Lane）。如下图2-6所示：图2-6泳道同样的在下图中描述了一个包含贷款应用流程的池。池中没有道。流程可以是可重用的子流程或内嵌的子流程。要注意迁移（顺序流）可以穿越同一个池中的道。迁移可能不会穿越池。流程定义(ProcessDefinition)流程定义是对流程的建模和描述，为流程中的其他实体提供上下文信息。其属性包括创建时间、作者、初始化参数、执行优先级、时间约束、仿真信息等。文档包含对流程集（包）的流程定义。Xml文档不仅被模型工具、模拟工具和执行工具使用，它同样为bam报表工具提供了基本信息，特别是为OLAP立体报表技术提供了维度和变量信息。在这里我们描述了使用管理工具发送xpdl流程定义到分析工具并传达能捕捉执行的详细情况的日志事件流的企业流程管理系统。分析工具根据流程定义、参与者和队列信息来构造数据库和OLAP立方。分析工具处理事件来更新数据库中实际和维度上的表，并且利用excel和（或）其他拥有的流程以及企业智能工具立体处理事件来完成对切片和切块查看数据的交互的准备。一个可供选择的数据展示的方法显示了流程定义的视觉环境中选择的数据。这个可以由历史展示或动画执行系统或模拟运行来实现。活动（Activity）活动是流程中的一个步骤，一个基本活动具有属性。这些属性提供了在这一步骤中谁可以执行这个活动、什么应用或Web服务会被调用、正在工作的对象的哪些内容被使用了以及（或）被改变了等信息。参与者（资源）和应用可能会定义在一个流程中，或者被定义在企业流程模型的整个流程集中。工作对象的内容同样可以定义在一个流程中或整个模型中。活动有一些其他属性更进一步定义了它们的特殊角色或它们是如何实现的一个流程包含一个或多个活动，活动对应着流程里的一个工作单元。一个典型的活动能被人力资源或计算机所执行。XPDL的活动粒度比较粗，分为四类，分别对应BPMN里的任务、子流程、网关和事件。如下图2-7所示：图2-7XPDL活动与BPMN的映射转移线(Transition)活动之间通过转移线连接。转移线包括3个属性：源活动、目标活动和条件。转移线可以是有条件的（设置表达式），也可以是无条件的。XPDL的转移线对应于BPMN里的顺序流，如下图2-8所示：图2-8XPDL转移线对应BPMN里的顺序流参与者声明（ParticipantDeclaration）描述执行流程和活动的资源。资源可以是单个人、也可以是角色、部门、还可以是自动执行的机器资源（例如打印机）。应用程序声明（ApplicationDeclaration）活动可以调用的IT系统、接口、Web服务。BPMN使用内置的服务任务（ServiceTask）直接代表对应用程序的调用。人工产出物(Artifact)为流程附加额外的建模信息，这些信息不属于基本的流程实体（活动、转移线、消息流），它们通过关联与流程实体联系在一起。在BPMN里，人工交付物包括3种类型，如下图2-9所示：图2-9人工产出物消息流（MessageFlow）消息流用来展示两个参与者/流程之间的消息流向。在BPMN中，用泳道中的池代表两个参与者/流程。消息流不能连接同一个池中的活动。图2-10消息流消息流一般由Web服务或消息队列实现。在例子中我们阐述了不同池中的活动之间的消息流是怎样流动的。这使得我们可以图形化的展示流程之间各方面的安排。应该注意的是消息流不会出现在同一个池中的活动之间。换句话说，顺序流用来连接同一个池中的活动，而消息流用来展示不同池中的活动之间的通信。这个例子中的池被画成水平方向并且扩展到整个页面。但是，规范中也支持垂直池，并允许限制宽度和高度。这支持了规范中抽象流程和安排对池的使用。关联(Association)我们使用关联将信息、人工产出物与流程实体连接起来，为流程模型提供更多的信息，它不影响流程的执行。如下图2-11所示：图2-11关联相关数据元素（Relevantdatafield）为流程定义执行过程中创建或使用到的数据，这些数据被活动、应用程序和流程中定义的各种表达式（转移线条件计算、网关条件计算）所使用。数据类型与表达式（DataTypesandExpressions）定义相关数据元素、系统与环境数据、参与者数据的数据类型，这包括了一些标准类型，例如String、int、date等等，也包括了自定义的扩展。表达式被用于各种条件计算（转移线、网关）以及给数据元素赋值。系统与环境数据（SystemandEnvironmentalData）由工作流系统和外部环境所维护的数据，这些数据被流程在执行过程中使用。资源仓库（ResourceRepository）执行活动的资源可以是人、也可以是角色、部门、程序、还可以是自动执行的机器资源，所以我们使用资源仓库将流程所涉及到的资源管理起来。资源仓库包括了对组织机构建模的支持。厂商/用户自定义扩展（VendororUserspecificExtensions）工作流系统厂商/用户可以针对自己的业务需求对流程元素和属性进行扩展。流程交换一般的元模型允许工具交换模型。这些工具有：模拟工具监控工具执行工具模型工具库工具下图展示了再BPM套件中流程交换的使用。三一个BPMNXML流程的根是definitions元素。在命名状态，子元素会包含真正的业务流程定义。每个process子元素可以拥有一个id和name。的基本结构：事件与活动和网关一起，事件用来在实际的每个业务流程中。事件让业务建模工具用很自然的方式描述业务流程，比如“当我接收到客户的订单，这个流程就启动”，“如果两天内任务没结束，就终止流程”或者当我收到一封取消邮件，当流程在运行时，使用子流程处理邮件。注意典型的业务通常使用这种事件驱动的方式。人们不会硬编码顺序创建，但是他们倾向于使用在他们的环境中发生的事情（比如，事件）。在BPMN规范中，描述了很多事件类型，为了覆盖可能的事情，在业务环境中可能出现的情况。事件：空启动事件一个启动事件说明了流程的开始（或子流程）。图形形式，它看起来是一个圆（可能）内部有一个小图标。图标指定了事件的实际类型会在流程实例创建时被触发。空启动事件画出来是一个圆，内部没有图标，意思是这个触发器是未知或者未指定的。jPDL的开始活动基本是一样的语法。流程实例的流程定义包含一个空启动事件，可以使用executionService的API调用创建。一个空开始事件像下面这样定义。id是必填的，name是可选的。<startEventid="start"name="myStart"/>事件：空结束事件结束事件指定了流程实例中一个流程路径的结束。图形上，它看起来就是一个圆拥有厚边框（可能）内部有小图标。图标指定了结束的时候会执行哪种操作。空结束事件画出来是一个圆，拥有厚边框，内部没有图标，这意味着当流程到达事件时，不会抛出任何信号。jPDL中的结束事件与空结束事件语义相同。空结束事件可以像下面一样定义，id是必填的，name是可选的。<endEventid="end"name="myEnd"/>下面的例子显示了只使用空开始和结束事件的流程：这个流程对应的可执行XML像这样（忽略声明用的definitions根元素）<processid="noneStartEndEvent"name="BPMN2Examplenonestartandendevent"><startEventid="start"/><sequenceFlowid="flow1"name="fromStartToEnd"sourceRef="start"targetRef="end"/><endEventid="end"name="End"/></process>事件：终止结束事件终止和的区别是实际中流程的路径是如何处理的（或者使用BPMN的术语叫做token）。终止结束事件会结束整个流程实例，而空结束事件只会结束当前流程路径。他们都不会抛出任何事情当到达结束事件的时候。一个终止结束事件可以像下面定义。id是必填的，name是可选的。<endEventid="terminateEnd"name="myTerminateEnd"><terminateEventDefinition/></endEvent>终止结束事件被描绘成结束事件一样（圆，厚边框），内部图标时一个完整的圆。在下面的例子中，完成task1会结束流程实例，当完成task2时只会结束到达结束事件的流程路径，只剩下task1打开。顺序流顺序流是事件，活动和网关之间的连线，显示为一条实线带有箭头，在BPMN图形中（jPDL中等效的是transition）。每个顺序流都有一个源头和一个目标引用，包含了活动，事件或网关的id。<sequenceFlowid="myFlow"name="MyFlow"sourceRef="sourceId"targetRef="targetId"/>与jPDL的一个重要区别是多外向顺序流的行为。在jPDL中，只有一个转移会成为外向转移，除非活动是fork（或自定义活动拥有fork行为）。然而，在BPMN中，多外向顺序流的默认行为是切分进入的token（jBPM中术语叫做execution）分成token集合，每个顺序流一个。在下面情况中，在完成第一个任务，就会激活三个任务。为了避免使用一个顺序流，必须添加condition条件到顺序流中。在运行时，只有当condition条件结果为true，顺序流才会被执行。活动（比如用户任务）和网关（比如唯一网关）可以用户默认顺序流。默认顺序流只会在活动或网关的所有其他外向顺序流的condition条件为false时才会使用。默认顺序流图形像是顺序流多了一个斜线标记。默认顺序流通过指定活动或网关的'default'属性来使用。也要注意，默认顺序流上的表达式会被忽略。网关BPMN中的网关是用来控制流程中的流向的。更确切的是，当一个token（BPMN中execution的概念注解）到达一个网关，它会根据网关的类型进行合并或切分。网关描绘成一个菱形，使用一个内部图标来指定类型唯一，广泛，其他）。所有网关类型，都可以设置gatewayDirection。下面的值可以使用：unspecificed(默认)：网关可能拥有多个进入和外出顺序流。mixed：网关必须拥有多个进入和外出顺序流。converging：网关必须拥有多个进入顺序流，但是只能有一个外出顺序流。diverging：网关必须拥有一个进入顺序流，和多个外出顺序流。网关：唯一网关唯一网关表达了一个流程中的唯一决策。会有一个外向顺序流被使用，根据定义在顺序流中的条件。对应的jPDL结构，相同的语法是decision活动。唯一网关的完全技术名称是'基于数据的唯一网关'，但是也经常称为XOR网关。XOR网关被描绘为一个菱形，内部有一个'X'，一个空的菱形，没有网关也象征着唯一网关。下面图形显示了唯一网关的用法：根据amount变量的值，会选择唯一网关外向的三个外向顺序流中的一个。网关：并行网关并行网关用来切分或同步相关的进入或外出顺序流。并行网关拥有一个进入顺序流的和多于一个的外出顺序流叫做'并行切分或'AND-split'。所有外出顺序流都会被并行使用。注意：像规范中定义的那样，外出顺序流中的条件都会被忽略。并行网关拥有多个进入顺序流和一个外出顺序流叫做'并行归并'或AND-join。所有进入顺序流需要到达这个并行归并，在外向顺序流使用之前。下面的图形显示了一个并行网关可以如何使用。在流程启动后，“prepareshipment”和“billcustomer”用户任务都会被激活。并行网关被描绘为一个菱形，内部图标是一个十字，对切分和归并行为都是一样。任务一个任务表示工作需要被外部实体完成，比如人工或自动服务。重要的是注意BPMN语法的'task'与jPDL语法的区别。在jPDL中，'task'的概念总是用在人工做一些事情的环境。流程引擎遇到jPDL中的task，它会创建一个task，交给一些人的任务列表，然后它会进入等待状态。然而在BPMN中，这里有很多任务类型，一些表示等待状态（比如，UserTask一些表示自动活动（比如，ServiceTask。所以小心不要混淆了任务的概念，在切换语言的时候。任务被描绘成一个圆角矩形，一般内部包含文字。任务的类型（用户任务，服务任务，脚本任务，等等）显示在矩形的左上角，用小图标区别。根据任务的类型，引擎会执行不同的功能。任务：人工任务usertask是典型的'人工任务'，实际中的每个workflow或BPMN软件中都可以找到。当流程执行到达这样一个usertask时，一个新人工任务就会被创建，交给用户的任务列表和的主要区别是（也与人工工作对应）是流程引擎了解任务。引擎可以跟踪竞争，分配，时间，其他，这些不是manualtask的情况。usertask描绘为一个圆角矩形，在左上角是一个小用户图标。usertask被定义为下面的BPMNXML：<userTaskid="myTask"name="Mytask"/>根据规范，可以使用多种实现（WebService,WS-humantask，等等）。通过使用implementation属性。当前，只有标准的jBPM任务机制才可以用，所以这里（还）没有定义'implementation'属性的功能。规范包含了一些方法把任务分配给用户、组、角色等等。当前的实现允许使用一个resourceAssignmentExpression来分配任务，结合humanPerformerorPotentialOwner结构。这部分希望在未来的版本里能够进一步演化。potentialOwner用来在你希望确定用户、组、角色的时候。这是一个task的候选人。也要注意，需要在流程外部定义一个资源，这样任务分配器可以引用到这个资源。实际上，任何活动都可以引用一个或多个资源元素。目前，只需要定义这个资源就可以了（因为它是规范中的一个必须的元素），但是在以后的发布中会进行加强（比如，资源可以拥有运行时参数）。任务：Java服务任务ServiceTask是一个自动活动，它会调用一些服务，比如webservice，javaservice等等。当前jBPM引擎只支持调用javaservice，但是webservice的调用已经在未来的版本中做了计划。定义一个服务任务需要好几行XML（这里就可以看到BPEL的影响力）。当然，在不久的未来，我们希望有工具可以把这部分大量的简化。一个服务任务需要如下定义：<serviceTaskid="MyServiceTask"name="Myservicetask"implementation="Other"operationRef="myOperation"/>服务任务需要一个必填的id和一个可选的name。implementation元素是用来表示调用服务的类型。可选值是WebService,Other或者Unspecified。因为我们只实现了Java调用，现在只能选择Other。服务任务将调用一个操作，operation的id会在operationRef属性中引用。这样一个操作就是下面实例的interface的一部分。每个操作都至少有一个输入信息，并且最多有一个输出信息。<interfaceid="myInterface"<operationid="myOperation2"name="myMethod"><inMessageRef>inputMessage</inMessageRef><outMessageRef>outputMessage</outMessageRef></bpmn:operation></interface>对于java服务，接口的名称用来指定java类的全类名。操作的名称用来指定将要调用方法名。输入/输出信息表示着java方法的参数/返回值，定义如下所示：<messageid="inputMessage"name="inputmessage"structureRef="myItemDefinition1"/>BPMN中很多元素叫做'item感知'，包括这个消息结构。这意味着它们会在流程执行过程中保存或读取item。负责这些元素的数据结构需要使用ItemDefinition。在这个环境下，消息指定了它的数据结构，通过引用structureRef属性中定义的ItemDefinition。任务：脚本服务任务本任务时一个自动活动，当到达这个任务的时候流程引擎会执行一个脚本。脚本任务使用方式如下：<scriptTaskid="scriptTask"name="ScriptTask"scriptLanguage="bsh"><script><![CDATA[for(inti=0;i<;i++){}]]></script></scriptTask>脚本任务，除了必填id和可选的name之外，还允许指定scriptLanguage和script。因为我们使用了JSR-223（java平台的脚本语言），修改脚本语言就需要：把scriptLanguage属性修改为JSR-223兼容的名称在classpath下添加JSR规范的ScriptEngine实现上面的XML对应图形如下所示（添加了空开始和结束事件）。任务：手工任务手工任务时一个由外部人员执行的任务，但是没有指定是一个BPM系统或是一个服务会被调用。在真实世界里，有很多例子：安装一个电话系统，使用定期邮件发送一封信，用电话联系客户，等等。<manualTaskid="myManualTask"name="Callcustomer"/>手工任务的目标更像文档/建模提醒的，因为它对流程引擎的运行没有任何意义，因此，当流程引擎遇到一个手工任务时会简单略过。任务：java接收任务receivetask是一个任务会等到外部消息的到来。除了广泛使用的webservice用例，规范在其他环境中的使用也是一样的。webservice用例还没有实现，但是receivetask已经可以在java环境中使用了。receivetask显示为一个圆角矩形（和task图形一样）在左上角有一个小信封的图标。在java环境中，receivetask没有其他属性，除了id和name（可选），行为就像是一个等待状态。为了在你的业务流程中使用等待状态，只需要加入如下几行：<receiveTaskid="receiveTask"name="wait"/>流程执行会在这样一个receivetask中等待。流程会使用熟悉的jBPMsignalmethods来继续执行。注意，这些可能在未来改变，因为'signal'在BPMN中拥有完全不同的含义。Executionexecution=("receiveTask");());四BPEL简介业务流程执行语言（BusinessProcessExecutionLanguage,BPEL,发音为'bipple'或'bee-pell'），也叫业务过程执行语言，是一种基于XML的，用来描写业务流程的编程语言，被描写的业务流程的每个单一步骤则由Web服务来实现。BPEL的目标是要实现业务流程定义格式的标准化，使得公司之间可以通过Web服务无缝的进行交互。BPEL是基于Web服务的，并且依赖于WSDL。一个BPEL流程可以发布为一个WSDL定义的服务，并像其它Web服务一样被调用。而且，BPEL希望一个Web服务合成所包含的全部外部Web服务，都是用WSDL服务契约定义的，这令BPEL流程可以调用其它BPEL流程，甚至可以递归的调用自己。值得注意的是BPEL不直接支持人机对话，BPEL所描写的过程仅与Web服务通信，而这些Web服务却可以提供与用户的信息交换，但它们不是用户本身。用BPEL编写的流程可以在任何支持BEPL规范的平台或产品上运行。BPEL支持两类不同类型的业务流程可执行流程：定义了要执行的各项具体任务，以及完成业务流程所需要调用的各个服务，它们遵循编排规范，可以被一个编排引擎所执行。（orchestration）

抽象流程：详细说明了双方或多方的公共消息交换，但没有定义流程流的内部行为细节，不可执行。（choreography）

BPEL现已成为被业界广泛认可和接受的进行Web服务编排的事实标准。BPEL与其它Web服务技术的关系BPEL是建立在Webservices技术之上的，因此与WSDL、XML、SOAP和UDDI等标准密切相关。BPEL流程模型是在WSDL定义的服务模型之上的一层。一个业务流程定义了一个流程实例和它的伙伴之间的交互。为了定义一个业务流程，BPEL引入了一些新的XML元素，例如Partners:业务事务中的参与者（actors）Containers:组成业务流程中的某一状态的一组消息Operations:所需Web服务的类型Porttypes:operations所要求的相关Web服务的关系BPEL包含的范围处理活动的顺序，特别是网络服务互操作。消息和处理实例之间的关系。在发生错误和例外情况下的恢复行为处理角色之间的基于网络服务关系的双面性。BPEL语言支持的两类任务BPEL支持两类任务或者说是行为：基本任务（basictasks）和结构化任务(structuredtasks)。基本任务是指由业务流程的一个基本的步骤，任务内不会嵌套其它任务；而结构化任务从外部看是一个步骤而从内部看却有若干个步骤。基本任务包括：Invoke任务——允许业务流程在某一个Web服务提供的portType上调用单向的（one-way）或请求/响应（request/respose）操作。Receive任务——允许业务流程停下来等待消息到来。Reply任务——允许业务流程对收到的消息发送一个回复消息。Wait任务——通知流程等待一段时间。Assign任务——把数据从一处复制到另一处。Throw任务——表明发生了某个错误。Terminate任务——终止整个编排实例。结构化任务包括：Sequence任务——定义一个有序的任务序列Switch任务——根据条件选择某一分支Pick任务——停下并等待某一适当消息的到来，或者等到超时继续前进。只要多个触发器中的一个发生，就执行相应的活动，任务便结束了。While任务——定义循环执行，直至满足某一个条件的一组任务。Flow任务——表明一