第5章 业务流程

5.1 概述

X5业务流程是基于PetriNet原理的业务流程定义和运行体系，PetriNet是当今被广泛应用于业务流程描述和运行算法的理论体系。在PetriNet中只有三个基本元素，它们分别是Place（容器），Activity（处理）和Token（令牌），PetriNet的基础原则都是围绕这三个元素定义的，它们分别是：

Place是用来存放Token的。

Activity用来消耗其输入Place中的Token，并且给它的输出的Place产生新Token。

Activity和Activity不能直接互连接的，只能通过Place互连。如图所示。

图5.1 基本的PetrnNet图

Activity激活的条件是其输入的所有Place中都有Token。

一个Token被一个Activity消耗以后就没了，不能再被消耗。

虽然X5的业务流程体系是基于PetriNet原理的，但由于业务模型层封装的原因，在实际的业务流程建模过程中并不会太多接触到底层PetriNet的东西。所以在这里就不再对PetriNet做详细描述了，具体PetriNet的详细信息请参阅与PetriNet相关的专业文档。

X5的业务流程以PetriNet作为基础理论依据，把业务流程元素和PetriNet元素做了一一对应，并且在此基础之上扩展出更合适于业务模型层的复杂业务流程规则，以形成业务流程定义。同样的，在业务流程运行时的算法体系中也遵循了基本的PetriNet原理，并在此基础之上根据业务流程定义的扩展，也对业务流程运行扩展出相应特性。如图所示就是上个PetriNet图对应的流程图。

图5.2 与PetriNet图对应的业务流程图

业务流程本质上就是把业务表单在人之间传来传去，负责传送业务表单并且通知对方进行处理的媒介途径是待办任务。所以X5业务流程体系中待办任务是核心基础，无论是业务流程还是协同只要牵扯到业务表单在人之间的传递都要依赖待办任务。基于以上的理解和考虑，X5业务流程体系是以待办任务为核心，结合业务流程与协同于一身的业务流程体系。

X5业务流程体系分为三部分，它们分别是业务流程定义，业务流程运行和业务流程实例（业务流程控制数据）。业务流程定义描述业务流程的整个过程和各种规则，从使用上说画的流程图和设置的流程规则就是业务流程定义。业务流程运行的核心是业务流程引擎，它解析业务流程定义，推进业务流程的运行，运行的结果就是业务流程实例。一个业务流程定义被运行一次就产生一个业务流程实例，在业务流程实例中包含若干待办任务。

5.2 业务流程定义

业务流程定义描述的是企业实现一个业务目标（业务审批）需要包含多少个环节步骤，各环节步骤间前后顺序和同步关系，各步骤由谁来处理等信息。抽象到业务模型上，步骤对应业务环节，顺序关系由连接弧定义，处理人对应执行者，处理要求对应到处理规则，所以业务流程定义是由环节，处理规则和连接弧组成。

业务过程中画在流程图上的业务环节，将以业务流程的方式使用待办任务作为入口来运行。此类业务环节需要在执行者收到待办任务以后，通过打开处理待办任务才可以运行业务环节。业务流程定义特指此类业务环节的定义，在业务过程中包含的没被画在流程图上的业务环节都是静态的业务环节，它们不包含在业务流程定义的范畴内。

5.2.1 启动规则

启动规则是在调用流程启动动作（startProcessQueryAction）时起作用，用来初始化业务流程实例的规则。启动规则不是必须设置，当它没有设置是会根据缺省的启动规则初始化业务流程。启动规则的详细描述，见5.4.1。

5.2.2 通知规则

通知规则是在调用流程结束动作（finishProcessAction）时或调用流程终止动作（abortProcessAction）时起作用的，用于给相关人产生通知待办任务的规则。通知规则不是必须设置的，当它没有设置时就表示不产生通知。通知规则的详细描述，见5.4.2。

5.3 业务流程环节

业务流程环节是业务流程里最基本最重要的组成元素，它描述业务流程中需要人为参与的处理，自动的处理和业务流程中路径的选择，分支和合并等。需要注意的是，所有业务流程环节定义的各种规则和条件都只有在业务流程执行讯问动作的时候起作用。

5.3.1 静态环节

业务流程中有两类环节：一类是非流程图上的环节，称之为静态环节；一类是流程图上的环节，称之为流程环节（后续介绍的都是流程环节）。
一般平台默认为每个业务流程生成一个mainActivity的静态环节，用来启动流程；通知规则中指向的环节，可以根据业务需求指定静态环节或流程环节。

5.3.2 开始环节

开始环节是业务流程里的一种标志环节，在一个业务流程定义只能有唯一的一个开始环节。从PetriNet的角度来说，流程必须都是从Place开始的，所以开始环节映射到PetriNet时其实是一个Place。

入口环节，启动环节和开始环节是比较容易混淆的几个概念。入口环节指的是连在开始环节后的第一层活动环节，它肯定是被画在流程图中开始环节之后的业务环节。启动环节指的是调用流程启动动作（startProcessAction）触发流程启动的环节，一般它是静态业务环节（mainActivity）而不被画在流程图中。

开始环节的意义不仅仅在于可以让代码能更容易的理解和找到业务流程的“起始点”，更重要的是当一个业务流程有多个入口环节时，在开始环节后可以跟分支环节或者条件环节来定义多入口环节之间的逻辑关系。如图所示。

图5.3 开始环节后跟条件分支选择入口

5.3.3 结束环节

和开始环节一样，结束环节也是业务流程里的一种标志环节，一个业务流程定义只能有唯一的一个结束环节。从PetriNet的角度来说，每个流程结束以后都会产生产物，所以当结束环节映射到PetriNet时其实也是一个Place。

当结束环节和其他环节组成分支的时候，结束环节和其他环节之间只能是排它（XOR）的关系，也就是说要么流入结束环节，要么流入其他环节，二者同时只能选其一，如图所示。

图5.4 结束环节和其他环节必须是XOR关系

需要注意的是，业务流程运行到结束环节并不一定代表整个流程就结束了，判断流程是否结束只有一个依据，那就是所有的活动环节的待办任务是否都处理完了。

5.3.4 活动环节

活动环节代表企业中的一个单独的、独立的业务环节。活动环节其实就是被画在流程图里的业务环节，运行时它和静态业务环节的区别在于活动环节必须由业务流程通过待办任务触发后才可以运行，而不像静态业务环节随时可以被运行。

活动环节是在业务流程运行的过程中唯一可进行人工干预处理的地方。当业务流程运行到活动环节时就会给指定的执行者生成待办任务，并且业务流程的运行会停下来，等执行者以待办任务为入口打开业务环节处理业务表单后，执行者再决定流程是要继续往后运行还是要重新处理。

活动环节映射到PetriNet里时是一个Activity。需要注意的是此Activity并非指的是业务环节。

条件（condition）
条件使用表达式的方式定义活动环节满足什么条件才可以被激活。活动环节的条件属性上定义的表达式只有在其他环节做流转操作流入当前活动环节时被计算，计算结果为true则表示当前活动环节可以激活并生成待办任务，计算为false则表示当前活动环节不允许激活。条件是必须设置的属性，如果定义常量则直接写true或false就可以了。条件表达式的设置和其中的函数，如何取业务数据详见5.6.3。

执行规则（ExecuteRule）
执行规则定义活动环节的执行者，待办任务属性和处理方式等信息。执行规则只有在其他环节做流转操作流入当前活动环节时才起作用，它为生成活动环节的待办任务提供素材信息，当待办任务生成了以后它就不再作用了。执行规则不是必须设置的，当它没有设置的时候会根据缺省的执行规则计算活动环节执行者和生成待办任务。执行规则的详细描述，详见5.4.3。

流转规则（AdvanceRule）
流转规则定义活动环节在做流转操作时的一些处理选项。流转规则不是必须设置的，当它没有设置的时候会根据缺省的流转规则进行流转操作。流程规则的详细描述，详见5.4.4。

回退规则（BackRule）
回退规则定义活动环节在做回退操作时的一些处理选项。回退规则不是必须设置的，当它没有设置的时候会根据缺省的回退规则进行回退操作。回退规则的详细描述，详见5.4.5。

转发规则（TransferRule）
转发规则定义活动环节在做转发操作时的一些处理选项。转发规则不是必须设置的，当它没有设置的时候会根据缺省的转发规则进行转发操作。转发规则的详细描述，详见5.4.6。

通知规则（NoticeRule）
通知规则定义活动环节在做流转，回退和转发等操作时需要通知其他人的处理选项。通知规则不是必须设置的，当它没有设置的时候就表示不需要通知。通知规则的详细描述，详见5.4.2。

5.3.5 自动环节

自动环节是通过调用指定业务动作或指定代码完成业务处理的环节，它一般用来实现同步更新业务数据或调用其他WebService等需求。当业务流程运行进入自动环节时并不会停下来，而是调用完指定业务动作或执行完指定代码后就直接进入下一步环节。自动环节只有在其他环节做流转操作进入它时，它才会起作用。

调用指定业务动作和执行指定代码的需求当然可以在事件实现，但是自动环节的好处在于可以从业务流程的图上看出有一个明显的自动处理。

自动环节本质上也属于“处理”，所以映射到PetriNet里时是Activity（处理）。

条件（condition）
条件使用表达式的方式定义自动环节满足什么条件才可以被激活。自动环节的条件属性上定义的表达式只有在其他环节做流转操作流入当前自动环节时计算，计算结果为true则表示当前自动环节可以激活并进行自动处理，计算为false则表示当前自动环节不允许激活。条件是必须设置的属性，如果定义常量则直接写true或false就可以了。条件表达式的设置和其中的函数，如何取业务数据详见5.6.3。

业务动作（Action）
自动环节上业务动作的设置和业务环节是一样的，不同点在于自动环节上设置的业务动作将被自动调用。业务动作在自动环节中是必须设置的属性。

5.3.6 条件环节

条件环节就是通过定义条件表达式的方式描述环节能否激活，从而控制路径是否畅通的环节，类似公路上的红绿灯。条件环节采用条件表达式的方式，根据表达式计算结果来控制流程能流入哪些环节，不能流入哪些环节。条件环节只有在其他环节做流转操作流入它时才起作用，如果条件表达式计算结果为true，则表示“此路畅通”可以直接经过条件环节后进入到下一步环节，反之则不能经过。那么，在活动环节前加一个条件环节和直接设置活动环节的条件属性，两者是等价的。
条件环节本质上属于“处理”，所以映射到PetriNet里时是Activity。

条件（condition）
条件使用表达式的方式定义条件环节满足什么条件才可以被激活，激活的意思进入。自动环节的条件属性上定义的表达式只有在其他环节做流转操作流入当前条件环节时计算，计算结果为true则表示“此路畅通”直接进入下一步环节，计算为false则表示“此路不通”而不能进入下一步环节。条件是必须设置的属性，如果定义常量则直接写true或false就可以了。条件表达式的设置和其中的函数，如何取业务数据详见5.6.3。

5.3.7 条件分支环节

条件分支环节虽然和条件环节一样是通过条件表达式的方式来描述路径是否畅通的环节。但是条件分支环节和条件环节有着本质上的不同，条件分支环节无论条件表达式怎么设置其实它一直都是畅通的，条件表达式只是用来选择它要从哪个输出流出而已。条件分支环节只允许有两个输出，一个输出用来定义是当条件表达式计算结果为真（true）时走的路径，另外一个则用来定义条件表达式结果为假（false）时走的路径。条件分支只有在其他环节做流转操作流入它时，它才起作用。
条件分支环节本质上属于“处理”，所以映射到PetriNet里时是多个Activity的组合，如图所示。

图5.5 条件分支对应到PetriNet

条件（condition）
使用条件表达式的方式选择输出，条件表达式计算结果为真（frue）就流入条件为真的输出，反之就流入条件为假的输出。条件是必须设置的属性，如果定义常量则直接写true或false就可以了。条件表达式的设置和其中的函数，如何取业务数据详见5.6.3。

条件为真的输出（true-output）
条件为真的输出上的属性值只能从与条件分支直接连接的输出的环节中选择。用来标识条件表达式计算结果为真（true）时要走的输出路径。它的选择范围是直接连在条件分支环节后的环节。条件为真的输出此属性是必须设置的。

条件为假的输出（false-output）
条件为假的输出上的属性值只能从与条件分支直接连接的输出的环节中选择。用来标识条件表达式计算结果为假（false）时要走的输出路径。它的选择范围是直接连在条件分支环节后的环节。条件为假的输出此属性是必须设置的。

5.3.8 AND环节

连接弧用来描述环节间的前后顺序，则环节间的逻辑关系则是使用逻辑环节（XOR或AND）来描述。在业务流程中，逻辑环节有AND环节和XOR环节。它们都可以用来做分支和做合并，描述环节间的协作和同步的关系。

AND环节有两种模式分别为分支模式和合并模式，当它有多个输出时即为AND分支，当它有多个输入时即为AND合并。AND环节可以同时具有多个输入和多个输出，即同时处于AND分支和AND合并下，也可以只单独处于分支模式或者单独处于合并模式。

AND环节映射到PetriNet里时是一个Activity。

AND分支
AND分支表示所有输出路径中只要是畅通的路径就必须都走。从使用上说，只要经过AND分支系统就会默认把所有畅通的输出都默认选上，并且在流转对话框中不能取消选择，以达到AND分支的目的。从待办任务的角度来说是把待办任务进行了拆分，一条待办任务在经过AND分支以后就拆分成了多条待办任务，每条待办任务都可以做各自独立的流转和回退操作。

AND分支其实本质就是一个待办任务拆分的过程。它和执行规则中多个执行者同时处理一条待办任务的不同点在于，多个执行者同时处理一条待办任务时执行者间具有协作关系的，而AND分支是把待办任务拆分到后续多个活动环节了，除非是遇到AND合并，要不然多个活动环节间是不具备任何协作关系的。AND分支后的每个活动环节的执行者都会收到在活动环节间各自独立的待办任务。毫无疑问这种待办任务拆分也只有在其他环节做流转操作，流入AND分支时才起作用的。

分支规则是对AND分支的一些特殊情况的处理，例如在AND的三个输出中只有两个是必选的，而另外一个选不选要用户自己决定。分支规则不是必须设置的属性，当它没有设置时会默认按照AND分支每个都是必须走的原则来处理。分支规则的详细说明。

AND合并
AND合并表示它所有的输入路径中只要有可能流入到AND环节中的待办任务，那就必须等到全部都流入AND环节了以后把所有流入的待办任务合并成一条待办任务，流程才可以继续运行到下一步环节。从待办任务的角度来说AND合并进行了待办任务的合并，多条待办任务经过AND合并以后就合并成了一条待办任务往下走，AND合并的后序的活动环节只会收到一条待办任务。

AND合并其实本质就是一个待办任务合并的过程，一般都和AND分支配对使用。当业务流程运行经过了AND分支以后，同时给多个活动环节生成了待办任务，每个待办任务可以独立流转和回退，只有在经过AND合并以后多个待办任务才会又合并成一个待办任务继续运行。

在AND合并的多个输入中，有可能有的输入的待办任务会先流转到AND合并，有的则后到。这时的处理原则是，先到达AND合并的待办任务需要等待其他尚未到达AND合并的待办任务，直到已经没有待办任务会流入AND合并时才允许通行到它的下一步环节。

合并规则是对AND合并多个输入之间的逻辑规则，描述什么情况下才进行待办任务的合并。例如某些重要的主要的输入先达到AND合并，那就可以不需要等待其他次要输入了。而次要的输入先到达就必须要等待主要的输入达到后才可以流入到下一环节。合并规则不是必须设置的属性，当它没有设置时会按照AND合并的所有输入都是必须的原则来处理。合并规则详细描述，详见5.4.7。

5.3.9 XOR环节

逻辑环节中的AND环节所描述的是环节之间的同时同步的关系，或者叫并发关系。XOR环节则描述的是环节间的独立排它的关系。

XOR环节也有两种模式分别为分支模式和合并模式，XOR环节有两种模式分别为分支模式和合并模式，当它有多个输出时即为XOR分支，当它有多个输入时即为XOR合并。XOR环节可以同时具有多个输入和多个输出，即同时处于XOR分支和XOR合并下，也可以只单独处于分支模式或者单独处于合并模式。XOR环节同样也只有在其他环节做流转操作流入XOR环节时起作用。

XOR环节映射到Pertri Net里时是一个Place。

XOR分支
XOR分支表示XOR环节所有输出的畅通的路径中只能同时走其中唯一的一条路径。从使用的角度来说，业务流程运行经过XOR分支会在所有畅通的输出中缺省选出其中当一条路径作为默认流出，同时在流转对话框中用户也可以更改默认选择，但是流转对话框限制了同时只能选中一个输出来保证XOR分支的特性。
当前待办任务经过XOR分支以后还是一条待办任务，所以经过XOR分支不会造成待办任务的拆分。

XOR合并
XOR合并表示XOR环节所有输入中任何一个输入达到XOR环节都可以接通行到流入下一环节。
当前待办任务经过XOR分支以后还是一条待办任务，所以本质上XOR分支不会造成任何待办任务之间的等待或合并。

5.4 业务流程规则

业务流程规则定义业务流程的执行者，各种操作的处理选项和通知等信息。为了支持复杂业务流程，所有业务流程规则都是可以设置多条的，在业务流程运行的时候根据设置的生效条件和规则的排列顺序计算出唯一的一条生效的规则。也就是说相同类型的业务流程规则在同一时刻只有唯一的一条可以生效。

业务流程规则的计算一般都在调用讯问相关的业务动作时计算，计算时根据业务流程规则定义的顺序一条一条的计算，当找到一条可以生效就不再往下计算了。

5.4.1 启动规则

启动规则是定义在业务流程上的当调用startProcessQueryAction动作启动业务流程时，为业务流程实例数据做初始化的规则定义。在启动规则里一般做一些流程实例的标题，限制时间的初始化，但是其实启动规则可以对业务流程实例所属的概念SA_Task的所有关系赋值。

启动规则只有在调用startProcessQueryAction时生效，而以后流程运行中就不再起作用了。所以当业务流程运行中业务数据值发生改变时这里是不会自动跟着变的，而只能写代码主动去刷新。

生效条件
生效条件使用表达式的方式定义规则满足什么条件才起作用。生效条件里定义的表达式最终计算结果必须是真（true）或假（false）。生效条件属性是必须设置的，如果定义常量则直接写true或false就可以了。条件表达式的设置和其中的函数，如何取业务数据等描述，详见5.6.3。

任务标题
任务标题使用表达式的方式定义业务流程实例的标题。任务标题里定义的表达式最终计算结果必须是一个字符串，如果定义常量则也需要使用单引号引起来。任务标题属性不是必须设置的，当没有设置时默认使用业务过程的标题作为业务流程实例的标题。任务标题表达式的设置和其中的函数，如何取业务数据等描述，详见5.6.3。

业务流程实例的标题最重要的作用是被用来生成各个活动环节的待办任务标题和通知的待办任务标题，如果把业务单据的制单人姓名和单据编号生成到业务流程实例的标题中，则此所有通知和活动环节的待办任务就可以很容易通过标题就区分开来。

任务标题最终被存入业务流程实例所属概念SA_Task的sName关系中。

限制时间
限制时间定义业务流程必须在某个时间段内处理完成。限制时间里定义的表达式最终计算结果必须是一个日期时间类型的值，一般是根据当前日期加上几天来定义业务流程必须在几天内处理完。限制时间表达式的设置和其中的函数，如何取业务数据等描述，详见5.6.3。

限制时间属性的计算结果将被存入业务流程实例的限制时间属性里，基于这个可以做一些自动的处理，例如超过限制时间自动结束，自动提醒和自动催办等。
限制时间最终被存入业务流程实例所属概念SA_Task的sLimitDate关系中。

任务属性
启动规则用来初始化业务流程实例的数据，其中任务标题和限制时间本质上都是给业务流程实例数据的关系赋值，把它们单独拿出来配置是出于方便性的考虑。任务属性可以给业务流程实例的任意关系赋值，只要指定关系名和对应的值表达式即可。在流程启动时会把所有任务属性里的计算结果存入到业务流程实例所属待办任务的各个关系中。任务属性中各关系值表达式的设置和其中的函数，如何取业务数据等描述，详见5.6.3。

由于业务流程实例本质上也是存入任务表的，所以任务属性这里属性名的选择范围就是概念SA_Task下的所有关系。任务属性就是对概念SA_Task的关系的赋值的规则定义。

在业务过程上没有定义启动规则时，缺省的启动规则中生效条件属性值为true，任务标题属性值是业务过程的标题，而其他属性都没有值。

5.4.2 通知规则

通知规则用于当业务流程在运行的过程中做了某个操作而需要通知有关人时。通知规则里定义通知接收人，接收人的处理方式等信息。当通知规则定义于业务流程自身上时是根据一些业务流程级别的操作生效，而当通知规则定义于活动环节上是就根据活动环节级别的一些操作来生效。

生效条件
生效条件使用表达式的方式定义规则满足什么条件才起作用。生效条件里定义的表达式最终计算结果必须是真（true）或假（false）。生效条件属性是必须设置的，如果定义常量则直接写true或false就可以了。条件表达式的设置和其中的函数，如何取业务数据等描述，详见5.6.3。

通知确认
在执行操作的过程中如果产生通知的话，是否需要弹出对话框，使当前用户可以手工修改一下通知的接受者或者通知的属性。当通知规则设置于活动环节上时是否要弹出流转对话框由活动环节上的流转规则和回退规则来确定，通知规则里的通知确认不起作用。由于流转而引发的业务流程结束时通知也一样流转规则确定是否弹出对话框。

通知时机
通知时机定义业务流程执行什么操作时通知规则才起作用。它其实和生效条件意义是一样的，都是为了定义满足什么条件通知规则才起作用。在业务流程运行时，通知时机被转换成条件表达式使用isExecutionAction函数来判断目前正在调用的业务动作，和生效条件一起决定通知规则是否起作用。

流转时通知是只有通知规则被定义在活动环节上时才有的属性。它表示在活动环节上做流转操作时通知规则才起作用。流转时通知其实是判断当前调用的业务动作是否是advanceProcessQueryAction动作。

回退时通知是只有通知规则被定义在活动环节上时才有的属性。它表示在活动环节上做回退操作时通知规则才起作用。回退时通知其实是判断当前调用的业务动作是否是backProcessQueryAction动作。

结束时通知是只有通知规则被定义在业务过程上时才有的属性。它表示整个业务流程实例结束时通知规则才起作用。结束时通知其实是判断当前调用的业务动作是否是finishProcessAction动作，此业务动作在做流转操作时如果业务流程实例可以被结束就会被自动触发，当然了也可以外界主动的调用它结束流程。

终止时通知是只有通知规则被定义在业务过程上时才有的属性。它表示执行流程终止操作时通知规则才起作用。结束时通知其实是判断当前调用的业务动作是否是abortProcessQueryAction。

通知标题
通知标题使用表达式的方式定义生成通知的待办任务的标题。任务标题里定义的表达式最终计算结果必须是一个字符串，如果定义常量则也需要使用双引号引起来。任务标题属性不是必须设置的，当没有设置时默认使用“通知：”加业务流程实例的标题作为通知的待办任务的标题。通知标题表达式的设置和其中的函数，如何取业务数据等描述，详见5.6.3。

通知标题表达式计算结果的值，最终被存入通知的待办任务所属的概念SA_Task的sName关系中。

限制时间
限制时间定义通知接收者在指定的时间点一起必须要把通知的待办任务处理掉。限制时间里定义的表达式最终计算结果必须是一个日期时间类型的值，一般是根据当前日期加上几天来定义通知的待办任务必须在几天内处理完。通知标题表达式的设置和其中的函数，如何取业务数据等描述，详见5.6.3。

限制时间属性的计算结果将被存入通知的待办任务的限制时间属性里，基于这个可以做一些自动的处理，例如超过限制时间自动结束，自动提醒和自动催办等。
限制时间表达式计算结果的值，最终被存入通知的待办任务所属的概念SA_Task的sLiimitDate关系中。

处理页面
处理页面定义通知的待办任务的接受者使用哪个业务环节打开待办任务。处理页面属性的值指定的就是一个业务环节的URL。业务环节的URL的就是其整个模块的路径加业务环节的ID。

处理页面最终被存入通知的待办任务所属的概念SA_Task的sEURL关系中。

打开时自动完成
打开时自动完成定义通知的接收者收到待办任务以后，在待办页面或者任务中心打开待办任务时立即把待办任务的状态设置为已结束（tesFinished）。本质上打开待办任务的时候其实是调用了executeTaskAction业务动作，在此业务动作里去结束当前待办任务。

打开时自动完成属性如果设置上，那最终其实是把通知的待办任务所属的概念SA_Task中的关系sExecuteMode2的值设置为finishWhenOpen。在调用executeTaskAction业务动作时判断此标记更新待办任务的状态。

当流入此环节时
当流入此环节时通知属性是只有通知规则在活动环节上定义时才会起作用的，和通知时机一样用来决定通知规则在什么时候起作用。例如某个活动环节后续有多个环节，那么可以定义只有流入其中某个环节时才需要通知，否则不通知。此属性的取值范围是直接连在活动环节后的环节的ID。当流入此环节时不是必须设置的，当它没有设置是就表示流入任意环节都产生通知。

当流入此环节时通知属性一般用在某个活动环节后既有结束环节又有其他环节时，只想流入结束时产生通知，而流入其他环节则不产生通知，此时属性值的就可以设置成结束环节的ID。

执行者设置
执行者设置通过组织机构范围函数的方式定义通知的待办任务的接收者的可选范围和默认选择的接收者。执行者表达式的设置，其中的函数和如何取到业务数据的描述，详见5.5。

执行者不仅仅指人员成员，还可以是机构，部门和岗位。也就是说，待办任务的不仅仅 可以发给人，还可以发给机构，部门和岗位等属于“组织”的组织单元。当待办任务是发给组织时，此组织下的所有人员成员都会收到待办任务，这些人员成员根据待办任务上定义的执行模式来处理待办任务。

执行者类型定义的是在流转对话框中用户可以选择什么类型的组织节点。此属性和其他属性没有任何关系，而仅仅作用于流转对话框。如果不弹流转对话框，则它就没什么意义。

执行者表达式通过组织机构函数的方式定义通知的默认接收者。实际业务流程运行时，不管是否有弹出流转对话框默认接收者都是起作用的，都会给默认接收者生成通知的待办任务。执行者表达式的计算结果必须是组织单元的列表，其表达式的设置，其中的函数和如何取到业务数据的描述，详见。

执行者范围表达式通过组织机构函数的方式定义通知的接收者的最大的可选范围。执行者范围表达式的计算结果一般只在流转对话框里使用，用它来确定流转对话框中组织机构树的显示和选择范围。如果它的计算结果是一个组织则流转对话框会默认显示组织下的人员成员。执行者范围表达式的计算结果必须是组织单元的列表，其表达式的设置，其中的函数和如何取到业务数据的描述，详见。

如果最大的接收者可选范围和默认选择接收者一样的或者不需要流转对话框时，就把执行者表达式和执行者范围表达式设置成一样就可以避免重复组织机构表达式计算造成速度慢。

任务协作
任务协作定义如何给通知的接收者生成待办任务，是多个接收者一起一条待办任务还是每个接收者一条待办任务，以及接收者应该如何来处理待办任务。

任务分配模式定义给执行者生成待办任务的模式。共同分配就是给所有执行者生成一条待办任务，那么只有等所有执行者都处理完成或被其中一个执行者抢占处理完成后此待办任务才算结束，才可以进行流转回退等操作。独立分配就是给每个执行者都生成一条待办任务，它们各自独立互不影响。每个执行者都可以把自己的结束待办任务处理完成后进行流转和回退等操作。同部门独立分配指的是给属于同一个部门的执行者生成同一条待办，用于在只有在部门之间要求待办任务互相独立的需求时，各部门下的人员成员都处理完成或者被某个一个人员成员抢占处理完成后自己部门的待办任务就结束，但不影响其他部门的。同机构独立分配和同组织独立分配的意思和同部门独立分配是一样的。

任务执行模式定义每一条待办任务内的执行者处理待办任务的方式，执行模式最终被存入到待办任务所属概念SA_Task的sExecuteMode关系中。抢占模式（temPreempt）表示待办任务的所有执行者中根据抢占模式只有一个执行者能抢到此待办任务进行处理，那么在抢的同时把其他执行者状态都设置为取消（tesCanceled）。同时模式（temSimultaneous）指的是待办任务中所有执行者都可以处理此待办任务，当所有执行者都处理完毕或者当控制者处理完毕了以后，待办任务才可以做流转和回退等操作。顺序模式（temSequential）指的是待办任务的执行者可以按照一定顺序来处理此待办任务，顺序是由执行者表达式里返回的组织单元顺序或者在流转对话框中选择执行者的顺序来确定的，当生成待办任务时只有第一个执行者的状态是待办（tesReady），其他执行者状态都是等待中（tesSleeping），等第一个执行者处理完毕以后才把第二个执行者的状态设置为（tesReady），以此类推到所有执行者都处理完毕后待办任务才可以做流转或回退操作。任务执行模式最终被存到待办任务的执行模式属性里了。

任务抢占模式定义当任务执行模式为抢占时，待办任务执行者做什么操作可以抢到待办任务。打开时抢占（tpmOpen）是指谁先打开待办任务就算谁的，其实就是在执行executeTaskAction时执行抢占操作。处理时抢占（tpmExecute）是指谁先做流转，回退或者转发等待办任务操作就算谁的。抢占是把除当前操作者以外的其他所有执行者的状态都设置为取消（tmsCanceled）。任务抢占模式最终被存到待办任务的执行模式属性里了。

任务属性
任务属性用来在生成通知的待办任务时给待办任务的关系赋值的，其实通知标题和限制时间都是用来给待办任务的关系赋值，把它们单独拿出来配置是出于方便性的考虑。任务属性可以给待办任务的任意属关系值，只要指定关系名和对应的值表达式即可。在通知时会把所有任务属性里的关系和的值表达式的计算结果存入到待办任务中。任务属性中各关系值表达式的设置和其中的函数，如何取业务数据等描述，详见5.6.3。

由于待办任务本质上也是存入任务表的，所以任务属性这里属性名的选择范围就是概念SA_Task下的所有关系。任务属性就是对概念SA_Task的关系的赋值的规则定义。

5.4.3 执行规则

执行规则用于定义活动环节的执行者，执行者可选范围，待办任务属性和处理方式等信息。执行规则是在其他环节做流转动作（且只有在做流转动作）流入当前活动环节时起作用的，在给当前活动环节计算执行者且生成了待办任务以后执行规则就不再起作用了。

生效条件
生效条件使用表达式的方式定义执行规则满足什么条件才起作用。生效条件里定义的表达式最终计算结果必须是真（true）或假（false）。生效条件属性是必须设置的，如果定义常量则直接写true或false就可以了。条件表达式的设置和其中的函数，如何取业务数据等描述，详见5.6.3。

任务标题
任务标题使用表达式的方式定义生成活动环节的待办任务的标题。任务标题里定义的表达式最终计算结果必须是一个字符串，如果定义常量则也需要使用双引号引起来。任务标题属性不是必须设置的，当没有设置时默认使用当前活动环节的标题加“：”号再加业务流程实例的标题作为当前待办任务的标题。任务标题表达式的设置和其中的函数，如何取业务数据等描述，详见56.3。

任务标题表达式的计算结果，最终是被存入到活动环节的待办任务所属概念SA_Task中的关系sName上的。

是否需要保存
当前通知中选择的信息是否保存，以供下次使用。

限制时间
限制时间定义活动环节的执行者在指定的时间点必须要把活动环节的待办任务处理完毕。限制时间里定义的表达式最终计算结果必须是一个日期时间类型的值，一般是根据当前日期加上几天来定义待办任务必须在几天内处理完。限制时间表达式的设置和其中的函数，如何取业务数据等描述，详见5.6.3。
限制时间表达式的计算结果，最终是被存入到活动环节的待办任务所属概念SA_Task中的关系sLimitDate上的。

执行者设置
执行者设置通过组织机构范围函数的方式定义活动环节的待办任务的执行者可选范围和默认选择的执行者。执行者表达式的设置，其中的函数和如何取到业务数据的描述，详见5.5。

执行者不仅仅指人员成员，还可以是机构，部门和岗位。也就是说，待办任务的不仅仅 可以发给人，还可以发给机构，部门和岗位等属于“组织”的组织单元。当待办任务是发给组织时，此组织下的所有人员成员都会收到待办任务，这些人员成员根据待办任务上定义的执行模式来处理待办任务。

执行者类型定义的是在流转对话框中用户可以选择什么类型的组织节点。此属性和其他属性没有任何关系，而仅仅作用于流转对话框。

执行者表达式通过组织机构函数的方式定义活动环节的默认执行者。实际业务流程运行时，不管是否有弹出流转对话框默认执行者都是起作用的，都会给默认执行者生成待办任务。执行者表达式的计算结果必须是组织单元的列表，详见（）

执行者范围表达式通过组织机构函数的方式定义活动环节的执行者的最大的可选范围。执行者范围表达式的计算结果一般只在流转对话框里使用，用它来确定流转对话框中组织机构树的显示和选择范围。如果它的计算结果是一个组织则流转对话框会默认显示组织下的人员成员。

一般情况下，如果执行者范围和默认执行者一样的或者不需要流转对话框的话，就把执行者表达式和执行者范围表达式设置成一样。

任务协作
任务协作定义如何给通知的接收者生成待办任务，是多个接收者一起一条待办任务还是每个接收者一条待办任务，以及接收者应该如何来处理待办任务。

任务分配模式定义给执行者生成待办任务的模式。共同分配就是给所有执行者生成一条待办任务，那么只有等所有执行者都处理完成或被其中一个执行者抢占处理完成后此待办任务才算结束，才可以进行流转回退等操作。独立分配就是给每个执行者都生成一条待办任务，它们各自独立互不影响。每个执行者都可以把自己的结束待办任务处理完成后进行流转和回退等操作。部门间独立分配指的是给属于同一个部门的执行者生成同一条待办，用于在只有在部门之间要求待办任务互相独立的需求时，各部门下的人员成员都处理完成或者被某个一个人员成员抢占处理完成后自己部门的待办任务就结束，但不影响其他部门的。机构间独立分配和组织间独立分配的意思和部门间独立分配是一样的。

任务执行模式定义每一条待办任务内的执行者处理待办任务的方式，执行模式最终被存入到待办任务所属概念SA_Task的sExecuteMode关系中。抢占模式（temPreempt）表示待办任务的所有执行者中根据抢占模式只有一个执行者能抢到此待办任务进行处理，那么在抢的同时把其他执行者状态都设置为取消（tesCanceled）。同时模式（temSimultaneous）指的是待办任务中所有执行者都可以处理此待办任务，当所有执行者都处理完毕或者当控制者处理完毕了以后，待办任务才可以做流转和回退等操作。顺序模式（temSequential）指的是待办任务的执行者可以按照一定顺序来处理此待办任务，顺序是由执行者表达式里返回的组织单元顺序或者在流转对话框中选择执行者的顺序来确定的，当生成待办任务时只有第一个执行者的状态是待办（tesReady），其他执行者状态都是等待中（tesSleeping），等第一个执行者处理完毕以后才把第二个执行者的状态设置为（tesReady），以此类推到所有执行者都处理完毕后待办任务才可以做流转或回退操作。任务执行模式最终被存到待办任务的执行模式属性里了。

任务抢占模式定义当任务执行模式为抢占时，待办任务执行者做什么操作可以抢到待办任务。打开时抢占（tpmOpen）是指谁先打开待办任务就算谁的，其实就是在执行executeTaskAction时执行抢占操作。处理时抢占（tpmExecute）是指谁先做流转，回退或者转发等待办任务操作就算谁的。抢占是把除当前操作者以外的其他所有执行者的状态都设置为取消（tmsCanceled）。任务抢占模式最终被存到待办任务的执行模式属性里了。

任务属性
任务属性是用来在生成活动环节的待办任务时给它的属性赋值的，其实任务标题和限制时间本质上都是给待办任务的属性赋值，把它们单独拿出来配置是出于方便性的考虑。任务属性可以给待办任务的任意属性赋值，只要指定属性名和对应的值表达式即可。在通知时会把所有任务属性里的属性的计算结果存入到待办任务对应的各个属性中。

任务属性一般用来给用户扩展的或者默认没有提供配置选项的属性赋值。

由于待办任务本质上也是存入任务表的，所以任务属性这里属性名的选择范围就是概念SA_Task下的所有关系。

5.4.4 流转规则

业务流程运行中当某个活动环节处理完毕以后要流到下一步去，即为流转。顾名思义流转规则就是在当前活动环节做流转操作时生效的规则，这来的流转操作指的是advanceProcessQueryAction动作。它定义的是当前活动环节调用advanceProcessQueryAction动作时的一些选项，例如是否需要弹出流转对话框等。
需要注意的是，流转到下一步是哪些环节和是哪些执行者则由环节间的关系和下一步活动环节的执行规则来定的。

生效条件
生效条件使用表达式的方式定义流转规则满足什么条件才起作用。生效条件里定义的表达式最终计算结果必须是真（true）或假（false）。生效条件属性是必须设置的，如果定义常量则直接写true或false就可以了。条件表达式的设置和其中的函数，如何取业务数据等描述，详见5.6.3。

流转确认
流转确认定义活动环节在做流转操作时，是否需要弹出流转对话框。如果直接调用advanceProcessAction业务动作实现流转操作，则此选项是不起作用的。只要是流转操作，则在流转规则上的流转确认起着决定性的作用，不管引发它通知的通知规则里是怎么设的，都以这里的为准。

允许跳转
允许跳转定义活动环节在做流转操作时，是否允许抛弃原有流转而跳转入其他后续环节。允许跳转仅仅作用于需要流转对话框时，如果允许跳转则在流转对话框里就会显示跳转页面进行跳转选择，否则不显示。

在流转对话框中跳转的选择范围是当前活动环节后的任意活动环节。由于跳转本身就属于一种特殊情况，所以跳转到当前活动环节的后续环节时，这些后续环节的执行规则是不起作用的，执行者也只能从整个组织机构中任意选择。

对于业务流程的业务动作来说，不管此属性如何设置其实都是支持跳转的，只要能构造出ProcessControl就可以了。

是否需要保存
当前流转动作中选择的信息是否保存，以供下次使用。

允许定制流程
允许定制流程定义活动环节在做流转操作时，是否允许抛弃原有流转而自由指定，甚至自由添加几个环节（已经存在的）并指定这些环节的顺序。
定制流程允许当前活动环节不按流程图的定义进行流转，不仅可以指定后序环节以及环节的执行者，并且可以指定后序若干个环节及环节的执行者。允许定制流程后，可以指后后序环节的选择范围。

强制流转
强制流转定义在活动环节做流转操作时，是否忽略存储于待办任务中的执行模式而直接可以进行流转或回退操作。其实只有在执行模式设置为同时或顺序，并且当前执行者不是待办任务的最后一个执行者或不是控制者时此属性才起作用。强制流转就是待办任务的任意执行者都可以做流转操作，否则就要收到执行模式的约束。

强制流转以后，把其他尚未处理完成的执行者的状态都设置为取消（tmsCanceled）。类似于做了抢占处理一样。

任务等待
任务等待的基础是任务分支。在业务流程中有两种情况会造成任务分支，第一种是经过了AND分支，而第二种则是在某个活动环节上的执行规则中任务分配模式被设置为独立分配。业务流程中的待办任务在某个点分支以后，可以理解为在业务流程中出现了多条线路并行处理。

任务等待就是定义当前待办任务流转时是否需要等待其他有可能流入当前活动环节的待办任务，如果需要任务等待且确实还有其他待办任务可能流入当前活动环节，则流转操作只是把当前待办任务状态设置为已结束（tmsFinished）而并不实际往下流转到下一步，反之如果已经没有可能流入当前活动环节的其他待办任务了，那就把当前待办任务和其他已经结束而尚未实际流转的待办任务一起流转。

任务等待会造成当前环节的下一步活动环节同时收到多条待办任务，因为流转操作时可能以前已经有待办任务结束了但尚未实际流转，而流转操作会把此类待办任务和当前的待办任务一起流转。本质上和这些待办任务单个单独的流转是没有区别的。

任务合并
在业务流程中有两种情况会造成任务合并，第一种就是经过了AND合并，而第二种则是这里的任务合并。任务合并是要以任务等待为基础的，如果已经没有可能流入当前环节的待办任务了，那就把当前待办任务和其他已经结束但没有流转的待办任务一起流转，但后续每个活动环节只会收到一条待办任务。

任务分支环节
需要任务等待的时候，业务流程引擎会自动计算待办任务是从哪个环节开始分支的，确定一个分支环节到当前环节的范围，根据范围内的待办任务参与任务等待和任务合并的计算。但是自动计算出来的就分支环节未必是百分支百严格，所以任务分支环节用于配置当自动计算结果不严格是可以手工指定待办任务发生分支的环节。

任务分支环节可以是一个活动环节也可以是一个AND分支。

5.4.5 回退规则

业务流程运行中在某个活动环节由于某种原因不能继续发流到下一步，而需要发回给上一步重新处理既为回退。顾名思义流转规则就是在当前活动环节做回退操作时生效的规则，这里的回退操作指的是backProcessQueryAction动作。它定义的是当前活动环节调用backProcessQueryAction动作时的一些选项，例如是否需要弹出流转对话框等。

需要注意的是，回退操作是把待办任务再发给曾经经过的活动环节，所以给曾经经过的活动环节生成新的待办任务的依据不再是这些活动环节上定义的执行规则，而是这些活动环节当初用来流转的待办任务。曾经的待办任务由谁处理就把新待办任务发给谁，并且执行模式，抢占模式等一些属性都从旧待办任务上直接拷贝到新待办任务里的。

生效条件
生效条件使用表达式的方式定义执行规则满足什么条件才起作用。生效条件里定义的表达式最终计算结果必须是真（true）或假（false）。生效条件属性是必须设置的，如果定义常量则直接写true或false就可以了。条件表达式的设置和其中的函数，如何取业务数据等描述，详见5.6.3。

是否需要保存
当前回退动作中选择的信息是否保存，以供下次使用。

回退确认
回退确认定义活动环节在做流转操作时，是否需要弹出回退对话框。如果直接调用backProcessAction业务动作实现回退操作，则此选项是不起作用的。只要是回退操作，则在回退规则上的回退确认起着决定性的作用，不管它引发通知的通知规则里是怎么设的，都以这里的为准。

强制回退
强制回退定义活动环节在做回退操作时，是否忽略存储于待办任务中的执行模式而直接可以进行回退操作。其实只有在执行模式设置为同时或顺序，并且当前执行者不是待办任务的最后一个执行者或不是控制者时此属性才起作用。强制回退就是待办任务的任意执行者都可以做回退操作，否则就要受到执行模式的约束。
强制回退以后，把其他尚未处理完成的执行者的状态都设置为取消（tmsCanceled）。类似于做了抢占处理一样。

按原路返回
在活动环节上做回退操作了以后，把待办任务发给某个活动环节曾经的执行者。那么此执行者处理完成了以后是把待办任务直接再发给退来的环节呢，还是根据业务流程定义把待办任务再重新一步一步流到退来环节。如图所示，途中虚线表示回退和回退后的流转，左边是按原路返回，右边是重新一步一步流到退来环节。

图5.6 按原路返回和不按原路返回

按原路返回指的就当前活动环节的待办任务回退以后，要求待办任务的执行者处理完成以后就把待办任务再直接发回来，而不要再重新流一次。按原路返回最终是把发给对方的待办任务所属的概念SA_Task的关系sExcuteMode2赋值为flowToFront。再对方做流转操作时，根据此关系的的值作为依据就可以知道流转操作的目标。

如果当前活动环节处于一个AND分支中的，并且回退操作的目标活动环节处于AND分支外。当指定了按原路返回属性时，回退操作不会吧AND分支中的其他待办任务取消。否则就默认取消AND分支中的其他待办任务。本质在于如果待办任务曾经经过了分支处理，回退操作时的目标活动环节超过了分支范围的话，做回退操作时按原路返回属性不会导致其他分支范围内待办任务的取消。否则就会取消分支范围内的其他待办任务。

如果当前活动环节是需要多人处理的，并且执行模式是同时或顺序时。执行回退操作时按原路返回属性不会导致其他分支范围内待办任务的取消。否则就会取消分支范围内的其他待办任务。

回退范围
回退范围定义活动环节在做回退操作时，可以退到曾经经过的活动环节中的哪些环节。回退范围的选择范围是当前活动环节前序的所有活动环节，此属性是必须设置的。

前序人指的是退给当前待办任务的前一个待办任务的执行者。需要注意的是当前待办任务的前一个待办任务未必就是当前活动环节的前一个活动环节的待办任务。例如当前待办任务是转发过来的，那么当前待办任务和前一个待办任务就属于同一个活动环节。

前序环节指的是退给当前待办任务所属活动环节的前一个活动环节的待办任务的执行者。如果当前活动环节的前面有多个活动环节相连，例如AND合并后的活动环节，则可以任意选择其中活动环节的执行者回退。

首环节指的是退给业务流程启动时生成待办任务的活动环节的执行者。首环节一般都是指入口环节，但是并不一定是入口环节，因为业务流程其实可以把任意活动环节作为入口环节。

指定环节指的是退给指定的某个前序环节的执行者。指定环节可以是单个或者多个，但是都必须是当前活动环节的前序环节。当指定的是多个环节时，可以从其中任选一个退给它的执行者。

所有前序环节指的是回退时把当前待办任务所有曾经经过活动环节都列出来，任选其中一个退给它的执行者。

5.4.6 转发规则

业务流程运行中某个活动环节的执行者无法决定要怎么处理，或者需要先把待办任务发给其他人看看然后再做处理即为转发。转发规则就是在当前活动环节做转发操作时生效的规则，这里的转发操作指的是transferTaskQueryAction动作。它定义的是当前活动环节调用transferTaskQueryAction动作时的一些选项，例如是否需要弹出流转对话框等。

转发和流转区别在于，流转是把待办任务发给了下一步活动环节的执行者，业务流程的当前活动环节和执行者都变了。而转发虽然也把待办任务流给了其他执行者，但是业务流程的当前活动环节没有发生改变。

转发规则的属性配置和执行规则一摸一样，所以转发规则的详细信息请参考执行规则的详细信息。详见。

5.4.7 合并规则

合并规则是定义在AND合并上用来描述AND合并的多个输入之间的关系的。合并规则是在所有直接输入到AND合并的活动环节中，只要任意活动环节做流转操作时它都会起作用。

生效条件
生效条件使用表达式的方式定义合并规则满足什么条件才起作用。生效条件里定义的表达式最终计算结果必须是真（true）或假（false）。生效条件属性是必须设置的。如果定义常量则直接写true或false就可以了。条件表达式的设置和其中的函数，如何取业务数据等描述，详见5.6.3。

是否需要保存
当前转发动作中选择的信息是否保存，以供下次使用。

合并模式
合并模式是AND合并上对输入的待办任务应该如何做合并的定义。在此过程中所有流入AND合并的属于合并规则可选输入的待办任务是没有任何决定权限，只有属于必选输入的待办任务流入AND合并才会计算AND合并是否允许通行。

AND合并是否允许通行的规则是就计算是否还存在有可能流入AND合并的属于必选输入的待办任务，如果有则不允许通行。反之允许通行。AND合并通行的规则是，把当前待办任务和已经结束但是尚未实际流转的待办任务合并成一条待办任务，往下流转。

合并指是常规的待办任务合并。当有必选输入流入AND合并时，判断是否还有属于必选输入的待办任务可能会流入AND合并，如果有则AND合并不能通行，把当前待办任务状态设置为已完成（tmsFinished）但不实际流入下一环节。如果已经没有了，则把当前待办任务和已完成且尚未实际流转的待办任务合并后流入下一步环节，同时取消（tmsCanceled）其他所有尚未流入AND合并的待办任务。在此过程中所有属于可选输入的待办任务流入AND合并都缺省被当作AND合并不能通过处理。

抢占指的是在AND合并所有的必选输入中只要有其中一条待办任务流入AND合并，则AND合并就可以通行流入下一环节，同时把所有尚未流入AND合并的待办任务都取消（tmsCanceled）。

可选输入
可选输入定义AND合并哪些输入是可选的，剩下的则是必选的。可选输入的选择范围是和AND合并直接相连的前顺环节。可选输入只有在计算合并模式的使用起作用，详见合并模式。

5.4.8 分支规则

合并规则是定义在AND分支上用来定义AND分支的多个输出之间的关系的。分支规则是在AND分支前的活动环节做流转操作时起作用的。例如某个活动环节后的AND分支后有3个活动环节，在此活动环节流转时想要做到其中2个活动环节是必须选择的，剩下1个活动环节是否选择由用户自己定。在分支规则中描述，用户自己决定的活动环节为可选输出，剩下就是必选输出了。

生效条件
生效条件使用表达式的方式定义分支规则满足什么条件才起作用。生效条件里定义的表达式最终计算结果必须是真（true）或假（false）。生效条件属性是必须设置的。如果定义常量则直接写true或false就可以了。条件表达式的设置和其中的函数，如何取业务数据等描述，详见5.6.3。

可选输出
可选输出定义AND分支后的环节中，哪些是用户在流转时可自己决定选还是不选。在流转对话框中，可选环节是可以被去掉的，而必选环节则不可以被去掉。以保证必选和可选的特性。

5.5 业务流程执行者

业务流程从本质上说其实就是待办任务在不同人之间按照既定的顺序和规则间传来传去，所以业务流程是否能和组织机构紧密结合是衡量业务流程是否可用的一大标准。

X5业务流程通过组织机构函数的方式实现在业务流程和组织机构的紧密整合，使用组织机构函数组成组织机构表达式，用来选择任意复杂的组织范围作为业务流程执行者。同时一般的表达式函数也可以穿插用于组织机构表达式中，实现了业务流程可以从任意地方获取执行者。业务流程执行者定义目前用在执行规则，通知规则和转发规则中，执行规则用来定义活动环节的执行者，通知规则用来定义通知接收者，转发规则用来定义转发时的接收者。

之所以叫执行者而不叫处理人的原因在于，业务流程的待办任务不仅仅可以发给人员成员，还可以发给岗位，部门和机构等组织单位。当待办任务的执行者是一个人员成员时只有他自己能看到和处理这个待办任务。而当待办任务的执行者是岗位，部门或机构等组织单位时，这些组织和它们的子组织下分配的所有人员成员都可以看到和处理待办任务。

执行者函数和其他一般函数最大的区别在于返回值的格式，执行者函数的返回值类型必须是指定类型（OrgUnit）的组织单元的列表。组织单元是用FID和FName两个标识一起来描述。

其实执行者函数本质就是选择出各种条件的组织单元。执行者函数本身也不仅仅可以在业务流程中使用，在系统其他有根据条件选择组织单元的地方可以通过直接调用函数或者调用表达式的方式使用。其他一般函数的返回值只要和执行者函数的输入参数匹配，就可以直接当作执行者函数的传入参数使用。

5.5.1 基于组织机构的执行者函数

根据组织机构的树形层次，成员，授权和管理关系而提供的选择组织单元的函数。这些函数不依赖业务流程的任何东西，所以它们不仅仅在业务流程中用，在任何其他选择组织范围的地方都可以用。

表5.1 组织机构函数及其用途

5.5.2 基于业务流程的执行者函数

根据业务流程图上的环节和前后关系而提供的选择组织单元的函数，由于这些函数依赖了业务流程中的待办任务，所以只能在业务流程中使用。

在所有基于业务流程的执行者函数中，指定环节的参数都可以传入标识环节的相对参数，例如ROOT（首环节），ALL（所有环节），PREV（前序环节）。

基于业务流程的执行者函数中所有取FID的函数都只是返回一个字符串，只能当作其他函数的输入参数，而无法直接当作执行者。

表5.2 业务流程的执行者函数及其用途

5.5.3 其他执行者函数

用于给执行者函数之间进行逻辑运算和参数转换而提供的函数。下表列的只是一些常用函数而不是所有函数。所有函数以STUDIO中表达式构造器上公布的函数为准。

表5.3 其他执行者函数及其用途

5.5.4 执行者函数的扩展

执行者函数的扩展中最基础，最重要的就是要返回值满足执行者的要求，否则就只能当作一般的函数作为其他函数的输入参数使用。
在JAVA中写代码的时候，可以使用任意的方式从任意地方把组织单元的FID和FName获取到后，用它们来创建OrgUnit对象。最后吧OrgUnit对象加入到标准的JAVA List中。

5.6 业务流程与业务数据

业务流程的本质就是待办任务在不同的人之间传来传去，待办任务其实是“桥梁”起到通知提醒的作用，而实际在人之间传来出去的实体应该是业务表单。所以，业务流程能否和业务数据紧密结合就是业务流程是否可用的另一大衡量标准。

在业务流程中使用业务数据有三种方式，它们分别是在事件的JAVA代码中直接访问业务数据库，业务流程变量和业务表达式。三种方式分别有不同的用途，在JAVA代码中一般直接访问业务数据库更新业务数据。业务流程变量中一般记录一些从业务数据上取来的值参与业务流程各种表达式计算。业务表达式则是业务模型底提供的公共机制，里面有一些函数可以访问业务数据中的值。

5.6.1 sData

当待办任务在不同的人之间传来传去时，首先要解决的一个问题就是如果让双方的业务表单保持一致。例如人员A通过待办任务把一个单号为001的申请单发给人员B审批，则人员B打开待办任务处理的时候看到的业务单据就应该是单号为001的申请单。

在待办任务中业务数据的传递是通过sData来实现的。sData只是一个泛指，在待办任务的概念SA_Task中它其实是靠4个关系来描述的，它们分别是sData1，sData2，sData3和sData4。当业务流程启动时，在调用流程启动动作（startProcessAction）的地方要求必须传入一个值为sData1的初始值。这个值被记录在sData1中在待办任务中一直传着走，在上例中从人员A的待办任务传入人员B的待办任务。当人员B打开待办任务处理时，从sData1中把值取出来参与业务表单的过滤。

一般情况下，赋值给sData的都是当前业务单据的单号，也就是业务主表的主键。业务主表只有一个主键时，自然sData1就够用了。如果业务主表是多主键则就需要把每个主键字段的值分别填写入sData1，sData2，sData3和sData4。也就是说，目前只支持4个字段的联合主键。

当启动一个业务流程需要同时处理多条业务主表的数据时，一般推荐的方案是为这多条业务数据生成一个批号，再把批号赋值给sData。同样也可以把多个单据的单号分别都赋值给sData。也就是说一个待办任务可以有多套sData。每套sData里都包含sData1，sData2，sData3和sData4。

在业务表达式中常常会这样用“:sData1”，这其实是业表达式中变量的用法，也就是说在业务表达式中使用“:sData1”来引用sData1的值，同样的可以“:sData2”， “:sData3”和“:sData4”。

在业务流程事件的代码中，分别使用ProcessUtils.getProcessData1()，ProcessUtils.getProcessData2()，ProcessUtils.getProcessData3()和ProcessUtils.getProcessData4()获取到sData的值。

5.6.2 业务流程变量（不支持）

业务流程变量把从业务数据中取到的或者从系统代码中取到的一些值存入业务流程的实例中，参与业务数据的过滤或者业务流程表达式的计算。其实业务流程表达式的计算不一定需要依赖到变量而可以直接调用函数来算，但是依赖变量的好处是只有在为变量赋值的地方业务流程需要和业务模块产生联系，而直接调用函数就是每个调用点都有依赖业务模块了。

sData1, sData2, sData3, sData4也是业务流程变量的一种，只是它们是特殊的，主体用来参与业务过滤的系统级的业务流程变量。

在业务表达式中使用?号加变量名的方式使用访问变量值。而在业务流程事件的JAVA代码中则是通过当前待办任务来访问变量值。

全局变量
定义于业务过程（Process）上的变量，当业务流程启动时根据定义把每个变量的值算出来，然后和变量名一起存入到业务流程实例中。这种变量可以在业务流程中任何一个地方直接引用。

局部变量
定义于活动环节（Activity）上的变量，当其他活动环节做流转动作流入当前活动环节时根据定义把每个变量的值计算出来，然后和变量名一起存入当前活动环节的待办任务中。这种变量只能在当前活动环节中使用。

5.6.3 业务表达式

在业务流程中使用的表达式分为两大类，它们分别用来执行者的组织机构表达式，和一般的业务表达式。两种表达式可以互相使用。
业务表达式其实是业务模型底层公共的表达式，它不仅仅在业务流程中用，在概念定义等其他地方也用。业务表达式中的函数同样不是写死的，任何的函数基本都可以当作业务表达式的函数来用。

在业务流程中可以使用任意的业务表达式函数，在这里就不一一列举，而只列出来一些业务流程中最常用的函数以供参考。

业务流程的业务表达式函数
在表达式中，获取业务数据的值基本都使用relationValue函数，这种函数本质上就是根据传入参数构造一个SQL去数据库里把对应表和字段的值查出来。在多条关联时，这些函数是完全可以互相嵌套使用的，如果一个表达式里有多个这种函数，也就是说这个表达式计算时将发多个SQL到数据库里取值。这些取值的函数是业务模型底层提供的公共的获取业务数据值的函数，不仅仅在只在业务流程里使用。

表5.4 业务流程的业务表达式函数及其用途

5.7 业务流程动作

由于业务流程是属于业务模型层的模块，所以部署运行在BusinessServer中，BusinessServer与外界交互的唯一手段就是通过业务动作。在业务表单里查询和提交业务数据是通过业务动作实现的，同样的，流程的各种动作也是基于业务动作来实现的。

业务流程的各种操作，一般都由讯问和实际做两大类业务动作构成，只有个别操作没有提供关于讯问的业务动作。所有讯问的业务动作都只是基于内存的推导和运算，把相关需要计算的规则，环节和执行者都计算完毕后生成ProcessControl，而不留下任何痕迹。实际做的业务动作都是根据传入的ProcessControl完成实际的操作，并且把结果存入数据库。

业务流程默认提供的业务动作都是系统级别的，不需要在Activity里主动引用就可以直接调用的。基本所有的业务流程的业务动作都是两个动作一起组合起来实现一个流程操作，例如流转操作是由advanceProcessQueryAction动作先查出ProcessControl，然后advanceProcessAction动作根据ProcessControl实际流转。

业务流程所有业务动作都是基于待办任务公布的，不但业务流程本身可以用，协同任务也可以用。也就是说只要是待办任务的操作，基本都可以调用业务流程的业务动作。

5.7.1 启动

启动的本质是根据业务流程定义产生新的业务流程实例，并且为业务流程的入口活动环节生成待办任务。需要注意的是，启动不一定只能给入口活动环节生成待办任务，只是在界面模型层里系统默认提供的流程启动函数是那样实现的，其实启动时可以给业务流程中任何活动环节生成待办任务，也就是说业务流程未必一定要从入口启动，还可以从中间某个环节启动。

启动操作由startProcessQueryAction和startProcessAction两个业务动作组成。

startProcessQueryAction
启动讯问，在实际启动前讯问有哪些入口环节，每个入口环节可以选择哪些执行者等信息。startProcessQueryAction不会实际让业务流程启动，它只是在内存里推导运行了整个启动的过程，然后把运行结果以ProcessControl的形式返回而不会留下任何痕迹。基于ProcessControl可以弹对话框选环节和选执行者，还可以在代码中修改ProcessControl实现代码控制启动。通过修改ProcessControl可以实现任意复杂的启动方式，从任意环节和任意人启动流程。

在调用startProcessQueryAction时首先计算的是启动规则，然后从开始环节往后找到入口环节，计算入口环节的执行规则后生成ProcessControl，所以在开始环节和入口环节中间的任何其他类型的环节和规则都将会被计算。

startProcessAction
实际启动，调用这个业务动作实际生成业务流程实例和指定入口环节的待办任务，并且存入数据库。只是在界面模型层里系统默认提供的流程启动函数其实就是直接调用了startProcessAction。通过传入ProcessControl参数可以实现对启动的控制，而当传入的ProcessControl值为NULL时它在BusinessServer内部首先调用了startProcessQueryAction获取到ProcessControl的值后再进行实际启动的。

其实startProcessAction本身不会产生任何计算规则和计算环节的行为，它仅仅就是根据ProcessControl实现启动。

界面模型层提供的流程启动函数xui-start-process，直接调用startProcessAction动作，且ProcessControl参数值为NULL。

5.7.2 流转

流转的本质首先是把当前待办任务的状态设置为已结束（tsFinished），然后为下一步活动环节生成新的待办任务，当前待办任务和新待办任务间使用前后关系关联。

流转操作由advanceProcessQueryAction和advanceProcessAction两个业务动作组成。

advanceProcessQueryAction
流转讯问，在实际流转前讯问当前活动环节的下一步有多少个活动环节，每个活动环节有多少执行者。advanceProcessQueryAction实际上不会为下一步环节生成待办任务，它只是把流转的运行过程在内存里推导运行了一遍，然后把运行结果以ProcessControl形式返回，不会留下任何痕迹。基于ProcessControl可以弹出流转话框选择下一步环节和选择执行者，还可以在代码中修改ProcessControl实现代码控制流转。通过操作ProcessControl可以实现任意复杂的流转，像跳转和自由流就是通过操作ProcessControl来实现的。

在调用advanceProcessQueryAction时首先计算当前活动环节的流转规则，然后基于当前活动环节往后找到下一步活动环节，计算这些活动环节的执行规则后生成ProcessControl。所以在当前活动环节和下一步活动环节之间的所有环节和规则都将被计算。

advanceProcessAction
实际流转，调用此业务动作把当前待办任务结束后生成下一步活动环节的待办任务，并且存入数据库。通过传入ProcessControl参数可以实现对流转的自定义，而当传入的ProcessControl为NULL时它在BusinessServer内部首先调用了advanceProcessQueryAction获取到ProcessControl的值后再进行实际流转的。

其实advanceProcessAction本身不会产生任何计算规则和计算环节的行为，它仅仅就是根据ProcessControl实现流转。

执行完毕advanceProcessAction以后，如果当前业务流程实例的所有待办任务都已处理完成，则自动触发finishProcessAction把当前业务流程实例的状态也设置为已结束（tesFinished）。

界面模型层的process组件上有流转操作的函数，它们分别是advanceQuery/advanceQueryExt和advance/advanceExt。advanceQuery/advanceQueryExt首先调用advanceProcessQueryAction动作获取ProcessControl，判断是否需要弹出流转对话框，如果需要则基于ProcessControl构造流转对话框，并且把流转对话框的选择结果再存入ProcessControl，最后传入ProcessControl调用advanceProcessAction动作。advance/advanceExt则直接调用advanceProcessAction动作，ProcessControl参数值传入为NULL。由于advance/advanceExt减少了ProcessControl的传递，所以速度上会比advanceQuery/advanceQueryExt要高一些。

5.7.3 回退

回退的本质首先是把当前待办任务状态设置为已退回（tesReturned），然后给曾经经过的指定的活动环节生成新的待办任务。当前待办任务和新待办任务间使用前后关系关联。

回退操作由backProcessQueryAction和backProcessAction两个业务动作组成。

backProcessQueryAction
回退讯问，在实际回退前讯问当前活动环节能回退到哪些活动环节，每个活动环节有多少执行者。backProcessQueryAction只是把回退的运行过程在内存里推导运行了一遍，然后把运行结果以ProcessControl形式返回，不会留下任何痕迹。基于ProcessControl可以弹回退话框选择回退的活动环节和选择执行者，还可以在代码中修改ProcessControl实现代码控制回退。通过操作ProcessControl可以实现任意复杂的回退，甚至是业务流程定义和规则中本来就不支持的。

在调用backProcessQueryAction时首先计算当前活动环节的回退规则，然后再根据回退规则找出能退到哪些活动环节去，在获取到这些活动环节曾经的待办任务后生成ProcessControl。所以在回退时只会计算当前环节的回退规则，而不会产生其他任何计算行为。

backProcessAction
实际流转，调用此业务动作把当前待办任务结束后生成目标活动环节的待办任务，并且存入数据库。通过传入ProcessControl参数可以实现对回退的控制，而当传入的ProcessControl为NULL时它的代码实现其实是首先调用了backProcessQueryAction获取到ProcessControl的值后再进行实际回退。

其实backProcessAction本身不会产生任何计算规则和计算环节的行为，它仅仅就是根据ProcessControl实现回退。

界面模型层的process组件上有两个关于回退操作的函数，它们分别是backQuery/backQueryExt和back/backExt。backQuery/backQueryExt首先调用backProcessQueryAction动作获取ProcessControl，判断是否需要弹出流转对话框，如果需要则基于ProcessControl构造流转对话框，并且把流转对话框的选择结果再存入ProcessControl，最后传入ProcessControl调用backProcessAction动作。back/backExt则直接调用backProcessAction动作，ProcessControl参数值传入为NULL。由于back/backExt减少了ProcessControl的传递，所以速度上会比backQuery/backQueryExt要高一些。

5.7.4 转发

转发的本质首先是把当前待办任务的状态设置为已转发（tesTransmited），然后基于当前活动环节给其他执行者生成新的待办任务。当前待办任务和新待办任务采用前后关系关联。

转发操作由transferTaskQueryAction和transferTaskAction两个业务动作组成。

transferTaskQueryAction
转发讯问，在实际转发前讯问当前活动环节能转发给哪些执行者。transferTaskQueryAction只是把转发的运行过程在内存里推导运行了一遍，然后把运行结果以ProcessControl形式返回。基于ProcessControl可以弹转发话框选择执行者，还可以在代码中修改ProcessControl实现代码控制转发。通过操作ProcessControl可以实现任意复杂的转发，甚至是业务流程定义和规则中本来就不支持的。

在调用transferTaskQueryAction时首先计算当前活动环节的转发规则，然后根据转发规则后生成ProcessControl。所以在转发时只会计算当前环节的转发规则，而不会产生其他任何计算行为。

transferTaskAction
实际流转，调用此业务动作把当前待办任务结束后给选择的执行者生成新待办任务，并且存入数据库。通过传入ProcessControl参数可以实现对转发的控制，而当传入的ProcessControl为NULL时它的代码实现其实是首先调用了transferTaskQueryAction获取到ProcessControl的值后再进行实际转发。

其实transferTaskAction本身不会产生任何计算规则和计算环节的行为，它仅仅就是根据ProcessControl实现转发。

界面模型层的process组件上有两个关于转发操作的函数，它们分别是transferQuery/transferQueryExt和transfer/transferExt。transferQuery/transferQueryExt首先调用transferTaskQueryAction动作获取ProcessControl，判断是否需要弹出流转对话框，如果需要则基于ProcessControl构造流转对话框，并且把流转对话框的选择结果再存入ProcessControl，最后传入ProcessControl调用transferTaskAction动作。transfer/transferExt则直接调用transferTaskAction动作，ProcessControl参数值传入为NULL。由于transfer/transferExt减少了ProcessControl的传递，所以速度上会比transferQuery/transferQueryExt要高一些。

5.7.5 终止

终止的本质就是把当前业务流程实例和其下所有待办任务的状态都设置为已终止（tesAborted）。

终止操作由abortProcessQueryAction和abortProcessAction两个业务动作（Action）组成。

abortProcessQueryAction
终止讯问，在实际终止前讯问需要通知给哪些相关人。abortProcessQueryAction根据在业务过程（Process）上设置的通知规则生成ProcessControl。基于ProcessControl可以弹出通知对话框选择执行者，还可以在代码中修改ProcessControl实现代码控制终止时通知。
在调用abortProcessAction时首先计算业务过程（Process）上的通知规则，然后根据通知规则后生成ProcessControl。所以在终止时只会计算当前业务过程的通知规则，而不会产生其他任何计算行为。

abortProcessAction
实际终止，调用此业务动作（Action）把更新当前业务流程实例和其所有待办任务的状态为已终止（tesAborted），并且存入数据库。通过传入ProcessControl参数可以实现对终止时通知的控制，而当传入的ProcessControl为NULL时abortProcessAction的代码实现其实是首先调用了abortProcessQueryAction获取到ProcessControl的值后再进行实际终止。

其实abortProcessAction本身不会产生任何计算规则和计算环节的行为，它仅仅就是根据ProcessControl实现终止。

界面模型层的process组件上有两个关于终止操作的函数，它们分别是abortQuery/abortQueryExt和abort/abortExt。abortQuery/abortQueryExt首先调用abortProcessQueryAction动作获取ProcessControl，判断是否需要弹出流转对话框，如果需要则基于ProcessControl构造流转对话框，并且把流转对话框的选择结果再存入ProcessControl，最后传入ProcessControl调用abortProcessAction动作。abort/abortExt则直接调用abortProcessAction动作，ProcessControl参数值传入为NULL。由于abort/abortExt减少了ProcessControl的传递，所以速度上会比abortQuery/abortQueryExt要高一些。

5.7.6 暂停

暂停的本质就是把当前业务流程实例和其所有待办任务的状态都设置为已暂停（tesPaused）。暂停和终止在代码实现上是没什么区别的，从业务上说两者区别在于暂停可以再次被恢复，而终止则指的是以后都不再处理了。

暂停操作由suspendProcessQueryAction和suspendProcessAction两个业务动作组成。

suspendProcessQueryAction
暂停讯问，在实际暂停前讯问需要通知给哪些相关人。suspendProcessQueryAction根据在业务过程（Process）上设置的通知规则生成ProcessControl。基于ProcessControl可以弹出通知对话框选择执行者，还可以在代码中修改ProcessControl实现代码控制暂停时通知。

在调用suspendProcessQueryAction时首先计算业务过程（Process）上的通知规则，然后根据通知规则后生成ProcessControl。所以在终止时只会计算当前业务过程的通知规则，而不会产生其他任何计算行为。

suspendProcessAction
实际终止，调用此业务动作（Action）把更新当前业务流程实例和其所有待办任务的状态为已暂停（tesPaushed），并且存入数据库。通过传入ProcessControl参数可以实现对终止时通知的控制，而当传入的ProcessControl为NULL时suspendProcessAction的代码实现其实是首先调用了suspendProcessQueryAction获取到ProcessControl的值后再进行实际终止。

其实suspendProcessAction本身不会产生任何计算规则和计算环节的行为，它仅仅就是根据ProcessControl实现终止。

界面模型层的process组件上有两个关于暂停操作的函数，它们分别是suspendQuery/suspendQueryExt和suspend/suspendExt。suspendQuery/suspendQueryExt首先调用suspendProcessQueryAction动作获取ProcessControl，判断是否需要弹出流转对话框，如果需要则基于ProcessControl构造流转对话框，并且把流转对话框的选择结果再存入ProcessControl，最后传入ProcessControl调用suspendProcessAction动作。suspend/suspendExt则直接调用suspendProcessAction动作，ProcessControl参数值传入为NULL。由于suspend/suspendExt减少了ProcessControl的传递，所以速度上会比suspendQuery/suspendQueryExt要高一些。

5.7.7 恢复

恢复的本质就是把当前业务流程实例和其所有待办任务中所有状态为已暂停（tesPaushed）的都把状态设置为待办中（tesReady）。使其能重新得到处理。
恢复操作只有resumeProcessAction一个业务动作。

resumeProcessAction
实际恢复，调用此业务动作把当前业务流程实例和其所有待办任务中状态为已暂停（tesPaused）的都更新为待办中（tesReady），并且存入数据库。
其实abortProcessAction本身不会产生任何计算规则和计算环节的行为，它仅仅实现对状态的更新。

界面模型层的process组件上有流程唤醒函数resume/resumeExt，直接调用resumeProcessAction动作，且ProcessControl参数值为NULL。

5.7.8 处理

处理是指在待办任务页面，任务中心或者其他任何能看到待办任务的地方打开待办任务相关的业务表单进行处理，此时会调用executeTaskAction实现待办任务打开时的一些自动特性。

executeTaskAction
此业务动作是在待办任务页面或者任务中心处理待办任务时自动调用的，实现一些打开时的自动特性。例如打开时抢占，打开时结束，打开时流转。

5.7.9 定制

定制是指运行时不按流程定义运行，动态指定指定一个流程模板，使得后续按指定的流程模板运行。流程模板包含若干个环节及其之间的关系，对于每个环节，可以指定相应的执行者，流程模板中的环节必须是当前流程定义中存在的环节。

定制不仅可以重新定义一个新的流程模板，而且可以选择已经定义过的流程模板。

定制操作由startCustomizedProcessQueryAction、startCustomizedProcessAction和cancelCustomizedProcessAction组成。

startCustomizedProcessQueryAction
此业务动作是查询当前环节实例是否关联了流程模板，如果关联了流程模板，返回具体的流程模板标识及所处的位置信息。

startCustomizedProcessAction
此业务动作是将指定的流程模板关联到当前环节，使得从当前环节开始按指定的流程模板运行。

cancelCustomizedProcessAction
此业务动作是取消当前环节实例与流程模板的关系。

5.8 业务流程事件

在实际业务需求中往往需要写一些代码用来控制业务流程运行，或根据业务流程的运行结果同步业务数据，更有甚者通过代码是实现一些业务流程原本不支持的特性。而写这些代码的切入点就是事件。

业务流程事件其实就是业务流程默认提供的业务动作的事件。它不只包含下面列的这些事件，还可以给任意动作扩展事件。

业务流程事件可以在业务过程上定义，也可以在业务环节上定义。它们的触发顺序是先触发业务过程上级的事件，后触发业务环节上的事件。

5.8.1 业务过程级事件

业务过程级事件在业务过程的任意业务环节中执行对应业务动作都会触发。在此事件中一般写一些公共的处理。这里列举的只是一些最常用事件，不是所有事件。每个业务Action都有before和after事件。

表5.5 业务过程级事件和动作

5.8.2 业务环节级事件

业务环节只有基于当前业务环节执行对应业务动作时才会触发。在业务环节级的事件中一般写一些私有的处理。这里列举的只是一些最常用事件，不是所有事件。事件是完全可以根据action来扩展的。

表5.6 业务环节级事件和动作

5.8.3 业务流程事件的函数

业务流程事件的函数一般只能在业务流程相关的事件的代码中调用，其他地方不能调。它用来业务动作的输入参数和修改业务动作的返回值，还包括获取底层提供的业务流程相关对象。这引起函数都在ProcessUtils里，这里列举的只是一些最常用函数，不是所有函数。

表5.7 业务流程事件的函数

5.9 业务动作

业务动作分为三个级别：全局的业务动作、业务过程级的业务动作、业务环节级的业务动作。

业务动作的执行必须在一个特定的环境下执行，即某个业务过程（process）的某个环节（activity）下执行。业务环节可以执行的业务动作包括三种：当前模块可见的全局的业务动作、当前业务过程级的业务动作和当前业务环节级的业务动作。

5.9.1 全局的业务动作

全局的业务动作是指在业务动作定义时，声明为global（即global属性为“true”）的业务动作，例如：

<action name="startProcessAction" global="true" log-enabled="true"
	procedure="startProcessProcedure">
	<public name="process" type="String" />
	<public name="attributes" type="Map" />
	<public name="control" type="Object" />
	<private name="tokens" type="List" />
</action>

<has-action action="" access-permission="public/protecetd"
	data-model="" log-enabled="">
	<public name="" type="" value="" />
	<protected name="" type="" value="" />
	……
</action>

<has-action name="startProcessAction" log-enabled="true"
	access-permission="protected">
	<public name="process" type="String" />
	<public name="attributes" type="Map" />
	<public name="control" type="Object" />
</action>

<listener action="" event="before/after" handler="" />

<listener action="startProcessAction" event="before" handder="myEventHandlerProcedure"/>

<xhtml:div id="processbar"

         component="/UI/system/components/processBar.xbl.xml#processBar">

         <item name="back-process-item" />

         <item name="advance-process-item" />

         <item name="transfer-task-item" />

         <item name="suspend-process-item" />

         <item name="abort-process-item" />

         <item name="customized-process-item" />

         <item name="process-chart-item" />

</xhtml:div>

<process-control>

         <status />

         <dialog-enabled />

         <save-history />

         <task-join />

         <customized-enabled />

         <jump-enabled />

         <runnable-activities />

         <to>

                   <process-control-item activity-id=”” selected=””

                            readonly=”” is-end=””>

                            <process />

                            <unit />

                            <executor-kinds />

                            <executor-range>

                                     <org-unit>

                                               <fid />

                                               <fname />

                                               <responsible />

                                     </org-unit>

                                     <org-unit />

                            </executor-range/>

                            <executors>

                                     <org-unit />

                            </executors>

                            <task-relation-value>

                                     <sEURL />

                                     <sCURL />

                                     <!-- tagName是任务的关系名称，值是关系的值 -->

                            </task-relation-value>

                   </process-control-item>

         </to>

         <notice>

                   <-- 与to的格式类似 -->

         </notice>

</process-control>