工作流参考手册

第第 1 章章 总体说明总体说明 在使用 EOS WorkFlow 的过程中，无论是开发者在“开发环境”中定义业务 流程，还是“工作流引擎”控制流程流转，或是工作流参与者使用的“客户端” ， 再或者管理员使用的“管理与监控工具” ，在这期间都会贯穿 EOS Workflow 的 5 个主要对象流程定义、活动定义、流程实例、活动实例以及工作项。 1.1 EOS 工作流开发过程简述工作流开发过程简述 EOS 的工作流开发过程可以看作是一个不断迭代的过程，如下图： 流程定义 流程发布 流程执行 开始 完善功能或需求变更 首先是分析需求，然后根据需求定义流程，在这个阶段最主要的工作任务 其实是设计，根据业务需求来设计流程，这个流程要怎么走，流程相关的数据 如何流动，流程的参与者如何界定，与流程相关的业务数据如何流动及保存等 等。在这个阶段的工作结果是一个可以发布的流程，第一次形成的流程可能是 一个比较简单的，并不完善的版本，但是随着迭代的进行，这个流程将不断地 被修正和改进，直到形成一个能够使用的版本。 接下来是流程的发布，流程发布的目的是让工作流引擎能够识别该流程。 在开发环境(JBoss)下可以直接在 Studio 中发布流程，开发阶段一般用此方法， 在生产环境中一般是先打包，然后在 http:/localhost:端口/eosmgr 中发布。 流程发布后就可以执行了，流程在执行阶段叫流程实例，它有待启动、运 行、挂起、完成、结束、中止等六种状态。 我们在设计及开发的过程中可能会犯一些错误，从而导致发布的流程执行 不正确，或者还可能已经开发好的流程满足不了现在的需求，需要进行调整， 这个时候迭代就开始了。 1.2 概念说明概念说明 流程定义流程定义：描述一个完整的业务过程，它由若干活动组成。包括了流程的 基本信息、流程的开始和结束条件、组成的活动、活动间流转的规则、需要用 户执行的工作任务（工作项）、可能调用的应用程序以及流程相关数据等信息。 提交到流程定义库（WFProcessDefine）后会包含流程定义 ID（流程定义的唯 一标识）、流程定义名称、版本号、流程定义描述以及提交时间等描述。 活动定义活动定义：包含在流程定义之中，代表了一个相对独立的、逻辑的工作单 元。一个活动代表一个需要由相关资源处理，或者由计算机处理的任务。其中 定义了该活动的基本信息、执行该活动的参与者、时间限制、工作项信息、触 发事件、启动策略等信息。 流程实例流程实例：当流程定义提交、发布到服务器以后，就可以启动该流程，启 动时会创建流程定义的一个实例，叫流程实例。同一个流程定义可以有多个流 程实例。每一个流程实例会被保存在流程实例库(WFProcessInst)中，包括流 程实例 ID（唯一标识）、流程实例名称、流程定义 ID、流程实例的状态、该实 例的启动者、启动时间、相关数据等信息。 活动实例活动实例：流程实例中的每个活动称为活动实例。每一个活动实例会被保 存在活动实例库(WFActivityInst)中，包括活动实例 ID（唯一标识） 、活动实例 的状态、所属的活动定义 ID 以及流程实例 ID、时间限制、是否超时、创建时 间等信息。 工作项工作项：表示流程实例在流转过程中为完成某个活动实例所要参与者做的 工作。一个活动实例可以对应一个或多个工作项。每个工作项会被保存在工作 项库(WFWorkItem)中，包括工作项 ID（唯一标识） 、参与者 ID、工作项的状 态、所属的活动实例 ID，流程实例 ID 等信息。 对象间的主要关系对象间的主要关系 流程定义和活动定义是在工作流开发阶段所确定；流程实例、活动实例和 工作项则是在工作流运行阶段确定。 一个流程定义由多个活动定义组成。 一个流程定义可以创建多个流程实例。 一个流程实例包含多个活动实例，每个活动实例可以包含一个或多个工作 项 在一些特定的情况下（比如，一个活动要循环执行多次） ，一个活动定义会 存在多个活动实例 具体如下图所示： 其他概念其他概念 【工作流工作流】 工作流管理联盟（WFMC）给出的“工作流”定义是： 全部或者部分，由计算机支持或自动处理的业务过程； 干预过程、业务程序的自动化处理，文档、信息或者任务按照定义好的 规则在参与者间传递，来完成整个业务目标或者对整个业务目标的完成 做贡献。同时， “工作流”可能由手工组织。 【参与者参与者】 它主要描业务流程在实例化后的运行过程中参与操作的人员、角色或组织。 【工作流相关数据工作流相关数据】 工作流引擎根据工作流相关数据和转换条件进行推进，工作流相关数据的属性 包括数据名称、数据类型和数据值等。它是工作流引擎执行任务推进的依据。 【转移条件转移条件】 主要负责为流程实例的推进提供导航依据，引擎根据转移条件实现流程的流转。 【聚合模式聚合模式】 指当流程中的一个活动存在多个前驱活动时，该活动产生实例的规则将根据“聚 合模式”而定。聚合模式包括：全部聚合/单一聚合/多路聚合(AND/XOR/OR)； “全部聚合”模式表示只有当所有前驱活动都运行结束后才启动该活动实例，如 果存在尚未运行结束的前驱活动，则该活动处于等待状态。 “单一聚合”模式表示 只要任何一个前驱活动运行结束，则该活动即进入运行状态。 “多路聚合”模式表 示满足条件的前驱活动都完成，该活动才可进入运行状态。 【分支模式分支模式】 当一个活动的后继活动有多个时，需要确定这些后继活动产生活动实例的规则 （即分支模式） 。分支模式包括：全部分支/单一分支/多路分支(AND/XOR/OR)； “全部分支”模式表示条件表达式计算结果为“True“的所有活动都产生活动实例； “单一分支”模式则表示从后继活动中任选一个条件表达式为“True”的活动产生 实例。 “单一分支”模式下需要指定一个“缺省迁移”，当所有条件都为“False”时， 此缺省迁移对应的活动则会产生实例。 “多路分支”表示该活动的完成会触发所有 满足条件的后继活动。 【工作流客户端工作流客户端】 工作流客户端是提供给用户完成工作流任务的浏览，查询，执行的界面，以及 工作流程启动的界面。EOS 工作流客户端通过 web 界面的方式提供给用户。 按用户和角色取得工作项 工作列表的自定义归类 工作项的签收、拒收、执行、提醒 竞争工作项的处理 图形化的启动过程 【工作流管理监控工具工作流管理监控工具】 工作流管理监控工具是为用户提供基于 Web 方式的工作流实例的管理和监控功 能以及业务流程的管理。 支持图形化工作流实例的管理 支持图形化监控过程实例的运行情况 支持图形化业务流程的管理 运行期实时数据查询 图形化再现流程运行过程 工作项的重分配 流程统计分析、工作项统计分析 1.3 相关配置说明相关配置说明 以下是一些有用的配置说明，关于 EOS 工作流的具体配置说明请参考附录 配置文件 wfconfig.xml。 工作流数据连结的配置在哪里工作流数据连结的配置在哪里 在 config/eosconfig.xml 文件中的 module name=“workflowworkflow“ group name=“database“中，指定了工作流的包名称和 unitID。通过包名称及 unitID 就可以从 EOSEJBREGISTER 表中获得数据库连接的 DATASOURCE 和 IP 地址。 带有工作流的 EOS 应用一定要采用数据源的方式（配置了数据源与连接池，且 eosconfig.xml 文件中 single 值为 false）连接数据库，这样才能保证工作流 和业务系统中事务的完整性。而且工作流调度引擎需要连接池来处理对数据库 的并发控制，不能使用 JDBC 直接连接，否则在实际的使用中会出现并发控制错 误。例如：使用 EOS5.0，在工作流客户端的“我的任务待执行的工作任务” 执行一个待执行的工作项，该工作项的任务是调用一个人工活动去查一张表。 如果在 studio 中启动项目 server，功能一切正常，如果启动外部 server，这 个功能有时候正常，有时候出错，出错页面的截图和详细的 log 见附件！（注： 出错是不确定的，有时候连续好几次都报错，有时候连续好几次都对！）在编 写工作流的业务自动机（业务逻辑）中，相关的工作流操作（如：完成工作流 节点，回退，设置工作流的相关数据等操作）和外部的业务操作都要并在一个 transaction（事务）中。 工作流历史表的相关说明工作流历史表的相关说明 EOS 数据库中存在以 WF_H 开头的几张表，这是工作流历史表，分别对应了 流程实例、活动项实例、工作项实例等等，业务上经常需要通过这些历史数据 进行统计分析，至于什么时候进行记录备份，帮助文档中没有提到。 其实，在 EOS 系统配置文件 wfconfig.xml 中，定义了历史记录备份的策略，如 下： TIME_BASED 0:30,5:00 第第 2 章章 建模过程建模过程 EOS Studio 提供了可视化的开发环境来定义工作流业务流程模型，提供串 行、分支、并行、聚合、循环、同步、子流程等丰富的流程逻辑结构，以及人 工活动、自动活动、路由活动等多种活动类型，并可对这些活动属性进行定义， 如参与者类型、触发事件、子流程属性、时间限制、回退动作、多工作项等， 定义属性时可选择不同的数据类型、可灵活的扩展活动；可以通过表单数据为 活动节点设置动态表单，其表单数据实现了动态表单的编辑，为日常工作中表 单的定制提供了良好的设计工具。 2.1 流程定义流程定义 流程定义由流程属性、活动属性、连接线三部分构成。开发者可以根据实 际中的业务需要设置流程上的基本属性、触发事件、时间限制以及流程启动者。 对每一个具体的活动则可根据实际情况设定其运行的方式、参与者以及调用的 应用等信息。完成流程定义的描述后即可提交、发布。提交后的流程将生成 XML 格式的流程定义文件，存入流程定义库中 2.1.1 流程版本流程版本 版本号的产生方式如下： 1、开发人员指定 版本号的格式为: X.Y.ZX.Y.Z (其中 X0;Y:0-99;Z:0-99) ，若指定的版本在流 程定义库中不存在,则按指定的版本号生成新版本 。若指定的版本在流程定义 库中存在，则覆盖流程定义库中已有的版本 。例如，某流程在流程定义库中存 在 1.1.1 和 1.2.3 两个版本。若要提交第三个版本,开发人员指定新版本号 1.1.2,那么该流程提交流程定义库的版本号即为 1.1.2;若指定版本号为 1.1.1, 则该流程在提交流程定义库时会覆盖原有 1.1.1 版本的流程 2、自动生成新版本 获取流程定义库中同一流程的最大版本,并在此基础上“加 1“作为当前流程 的版本号。 2.1.2 触发事件触发事件 触发事件说明触发事件说明 流程触发事件表示按照流程定义中的设置流程实例在运行到某个阶段所需 要工作流引擎做某种类型的某个动作。“某个阶段”即为事件的触发时机， “某种类型”即为事件类型，“某个动作”即为事件的动作。 触发时机触发时机：表示指定的事件动作在何时触发。EOS WorkFlow 提供了创建、 动、结束、超时和提醒 5 个触发时机。 创建创建：表示指定的事件在流程实例创建时触发。此时流程实例实际上处于 “待启动”的状态，并没有合适的活动实例产生。简言之，流程实例此时只是 做好运行的准备，但未真正开始运行。例如：把田径比赛中的 110 米栏比作流 程实例，那么创建时的流程实例就相当于已站在助跑器前的运动员们等待发令 枪响的那一刻。 启动启动：表示指定的事件在流程实例启动时触发。此时，流程实例已真正处 于运行状态了，流程实例已开始运行，各活动实例将会相继产生。例如：流程 实例此时的状态若比作 110 米栏，就相当于运动员们听到发令枪响冲离起跑线 的那一刻。 结束结束：表示指定的事件在流程实例结束时触发。即流程实例中所有的活动 实例均已完成时触发。 超时超时：表示指定的事件在流程实例超时时触发。例如：若流程的超时时间 订为 1 天，那么定义的事件将在流程实例启动时开始计时，并在 1 天之后触发 此事件。 提醒提醒：表示指定的事件在流程实例指定的提醒时间触发。例如：若流程的 提醒时间订为 1 小时，那么定义的事件将在流程实例启动时开始计时，并在超 时前 1 小时触发此事件。 事件类型事件类型：标明事件动作的类型。EOS WorkFlow 提供基于 EOS 平台的业务 逻辑和运算逻辑两种类型。 事件动作事件动作：由开发人员根据具体的业务需求自行定义。可以是一个运算逻辑也可以是 一个业务逻辑。 触发事件设置方法触发事件设置方法 【场景】 在流程“启动的同时，获取指定节点信息并放入该流程实例相关数据的指定 节点下。如获取流程信息中创建者节点(WFContext/WFProcessInst/creator)，放 入相关数据区 Node/creator 下。 【分析】 通过【场景】的描述，我们可以采用流程触发事件的方式实现该需求。分 析为： 1、 “在流程启动的同时”，表示触发的时机为启动启动，调用方式为同步同步。 这里需要特别注意的是，调用方式同步和异步的区别。同步是指：以“同步”的 方式调用触发事件，等待事件运行完成后，该流程才启动 。 同步是指：以“异 步”的方式调用触发事件，该流程在启动完触发事件后就启动，而无需等待触发 事件运行完成。 2、 “获取指定节点信息”为事件动作，事件动作，可以用业务逻辑业务逻辑来实现。触发事件中 产生的数据还可以在业务逻辑中输出，这样就可以将这些数据直接设置为相关 数据了。 3、要将步骤 2 中获取的信息放入该流程实例相关数据的指定节点下，具体 可在事件参数事件参数中设置。 输入参数设置为 WFContext，在各类触发事件以及回退事件中，WFContext 属于流程实例的相关数据区部分，这块数据区有固定的数据结构，具体请见： 3.2.2 流程实例数据区。触发事件的数据来源于相关数据区，WFContext 是相关 数据区中固有的一块区域信息，这些信息都放在 Wfcontext 节点下。其中， WFContext 数据区内容是流程实例自身的信息，相关数据区的内容还有流程中 产生的过程数据，即业务数据。 输出参数设置为 creator，目标路径为 Node/userID。在触发事件所执行的 业务逻辑中会产生一个 crator 的节点，把这个节点放入到相关数据区 Node/userID 下。目标路径：表示将返回结果存入到流程实例相关数据中的什 么位置。如该例中是将调用业务逻辑的返回结果输出到该流程相关数据的 Node/userID 节点下。注意，目标路径目标路径仅对事件类型为业务逻辑业务逻辑的事件动作有 效。 图-设置触发事件的参数 注意：注意： 如果调用的事件类型为业务逻辑，业务逻辑，而参数的数据类型为字符串常量字符串常量或字符字符 串变量，串变量，那么路径路径中填入的格式必须为：nodeName=“value“nodeName=“value“或 nodeName=valuenodeName=value （因为业务逻辑不支持直接传入常量或变量） 例如：要传入常量 tiger 到所调用的业务逻辑中，就必须做如下设置 2.1.3 超时设置超时设置 如果想扩展和替换 EOS 工作流的超时和预警机制，可以根据工作流配置文件 wfconfig.xml 中的工作流引擎服务层相关配置 10000 参数 timelimit_calculator 流程和活动时间限制的计算方法类名称，该类必须实 现接口 com.primeton.eos.wf.service.api.TimeLimitCalculator。 配置为空或者不做配置，表示使用确省实现类： com.primeton.eos.wf.service.TimeLimitCalculatorDefault。 时间限制说明时间限制说明 流程的时间限制表示流程启动后必须在多长时间内完成。在流程时间限制 的设置中 EOS WorkFlow 为开发人员提供了指定具体的限制时间、超时是否进行 邮件通知、是否在超时前进行提醒、是否发提醒通知等功能。 流程时间限制的计时：从流程启动时开始计时 流程时间限制的获取：直接指定、从相关数据获取（格式：3.5.20 表示时 限为 3 天 5 小时 20 分钟） 发送提醒邮件：EOS WorkFlow 可根据流程定义中的具体设置给流程启动者 发提醒邮件，提醒他该流程还有多长时间将超时 发送超时邮件：EOS WorkFlow 可根据流程定义中的具体设置给流程启动者 发送超时邮件，告之他该流程已经超时 提醒时间必须小于指定的时间限制 EOSEOS WORKFLOWWORKFLOW 判断流程或人工活动超时的原理判断流程或人工活动超时的原理 流程或人工活动的时间限制中设置的限制时间将写入表 WFProcessInst 或 WFWorkItem 的 limitNum 字段中，单位为毫秒，limitNumDesc 是其描述字段； finalTime 是时间限制到达后的时间。EOS WorkFlow 将当前时间与 startTime 相减的结果与 limitNum 比较，一旦超出时间限制就将 isTimeOut 字段置为 Y， 表示超时；timeOutNum 表示超时了多长时间，在流程结束时写入。如果设置了 超时提醒，该字段可能出现负数，是未超时的表现，只有正数才表示超时的时 间，timeOutNumDesc 是其描述字段。 时间设置说明时间设置说明 【描述】 设置流程时间限制包括指定时间限制的值、提醒时间的值、决定是否发送超时 邮件或提醒邮件 【应用场景】 规定流程 A 必须在 1 天内完成，超时进行通知；并在超时前 10 小时发提醒通 知 【操作步骤】 1、双击流程 A 的编辑区，弹出属性设置属性设置窗口，点击时间限制时间限制选项卡 2、勾选启用时间限制启用时间限制 3、指定时间限制为：1 天 0 小时 0 分钟 4、勾选是否按设置的时间限制进行超时通知。是否按设置的时间限制进行超时通知。此处将会根据 wfconfig.xml 相关 配置给流程启动者发送邮件。 5、指定提前 0 天 10 小时 0 分钟提醒 6、勾选是否按设置的提醒时间进行超时预警。是否按设置的提醒时间进行超时预警。此处将会根据 wfconfig.xml 相关配置 给流程启动者发送邮件。 图-设置流程时间限制 1 说明： 1、无论是超时通知的邮件还是提醒的邮件，收件人都是流程启动者 2、这些邮件的发件人，可根据具体情况在配置文件 设置$Primeton HOMEeosserverconfig 目录下的 wfconfig.xml 设置，相关部分如下所示： zll zll 25 zll true 参数说明： Field 名称 可否空说明 mailServer 是邮件服务器 SMTP 地址 mailPort是SMTP 端口，一般设置为 25 authLogin 是SMTP 服务器是否需要进行用户验证，设置 true 则 需要进行用户认证，设置 false 则不需要进行认证 username是SMTP 服务器的用户名 password是SMTP 的用户口令 特别说明特别说明：EOS 工作流超时提醒只提醒一次。流程实例一旦超时，就会触发 相应的操作将流程实例中的 WFProcessInst/isTimeOut 节点设置为 Y。如果想 实现重复提醒功能，通常的做法是为流程设置超时的触发事件。在超时触发事 件中注册一个定时器，定时扫描该流程实例是否完成，如果没有完成就执行发 放邮件或者短信都通知的操作。 2.1.4 流程启动者流程启动者 流程启动者表示可以启动某个流程的组织、角色或人。EOS WorkFlow 提 供两种流程启动策略:任意人员启动和从组织机构树获取。这样做的目的主要是 从实际工作中的安全性考虑,视流程的具体情况限定可以启动该流程的人员范围。 图-流程启动者 当流程实例运行的时候，可以在相关数据区的如下节点 xpath 找到流程启动者： tiger 2.1.5 流程定义特别说明流程定义特别说明 工作流的自动活动或触发事件调用带事务的业务逻辑的注意事项工作流的自动活动或触发事件调用带事务的业务逻辑的注意事项 因为工作流的事务控制和业务逻辑的事务控制是分开的，所以，当工作流 的自动活动或触发事件调用了带事务控制的业务逻辑时，工作流引擎默认忽略 业务逻辑中的事务，这样就存在一个问题： 业务逻辑中出现了异常，并通过异常线回滚，这时，业务数据提交不成功， 但是，工作流引擎并没有接收到异常，它会继续往后走，最终就出现工作流事 务和业务事务不一致的现象。 【解决方案和步骤】 建议业务逻辑中不要用异常线回退到回滚，让异常直接抛出，这样工作流 引擎会接收到异常，进而做回滚！ 【备注】 1）异常线不能随便使用，如果一定要用，最好设置返回值返回，最后转向 出错页面； 2）使用异常线前还要注意 BL 方法是否会抛异常，因为不是所有的 BL 方法 都会抛异常。 2.2 活动定义活动定义 EOS WorkFlow 提供了六种类型的活动。开始活动、结束活动、人工活动、 自动活动、子流程活动以及路由活动。 活动图元介绍 图元名称含义 开始活动 表示一个业务流程的开始。在流程开始活动可以定义流程的 启动表单以及业务流程的触发事件。 人工活动指需要人工干预、进行某种操作的活动。比如填写表单等。 自动活动 指无需人工干预，系统自动执行的活动。比如获取系统时间、 往数据库中插入记录等。 子流程 一种特殊的活动，此活动本身是指向某一个流程，表示当流 程实例运行至此时，启动另外一个流程。子流程的启动分为 同步和异步两种方式。 路由活动 是一种逻辑活动，根据控制条件判断流程的流向。该活动本 身并不执行任何具体的操作。 结束活动表示一个业务流程的结束。 2.2.1 设置活动基本信息设置活动基本信息 活动包括：人工活动、自动活动、子流程。 1）自动活动的基本信息设置如下： 自动返回结果： “是是”：表示执行动作的返回结果全部自动放入相关数据相关数据的根路径下。 “否否”：表示执行动作的返回结果将不会自动放入相关数据中去。此时， 如要将返回结果中的某项返回到相关数据中，可在参数参数选项卡中设置。 该项设置仅对调用类型是业务逻辑业务逻辑有效 调用方式： “同步同步”： 直到调用的执行动作运行完后当前自动活动才结束 “异步异步”：当前自动活动在调用执行动作后就结束，而无需等待执行动 作运行完 结束方式： “自动自动”：调用完执行动作后，工作流引擎自动将当前自动活动结束 “人工人工：”调用完执行动作后，引擎不将当前自动活动结束，而是等待 外部调用结束该活动 2）子流程的基本信息设置如下： 调用方式： “同步同步”：以“同步”的方式调用子流程，等待子流程运行完成后，该 子流程活动才结束 “异步异步”：以“异步”的方式调用子流程，当前活动在启动完子流程后 就结束，而无需等待子流程运行完成 子流程：单击【选择】按钮，从弹出窗口的资源树中选择子流程或直 接输入子流程，填写规则为：构件包名. .工作流构件名. .业务流程名。如果调 用的子流程需要输入或输出一些参数请在参数参数选项卡中设置 2.2.2 聚合模式、分支模式聚合模式、分支模式 活动的“分支”与“聚合”模式在流程定义时设置，分别描述了活动在运 行时何时被触发以及或个运行结束后，它的后继活动如何被触发。 聚合模式聚合模式 聚合模式，表示该活动得以触发的方式。它包括“全部聚合（AND） ” 、 “单一聚 合（XOR） ”以及“多路聚合（OR） ”三种情况： 1.1.“全部聚合全部聚合”型聚合模式型聚合模式 表示该活动必须等到它的所有前驱活动全部完成才可以触发。 2.2.“单一聚合单一聚合”型聚合模式型聚合模式 表示当该活动的若干前驱活动中只要有一个满足条件的活动完成，该活动 即可被触发。 3.3. “多路聚合多路聚合”型聚合模式型聚合模式 表示该活动必须等到它的所有满足条件的前驱活动全部完成才可以触发。 满足条件的前驱活动包括： 1)它与该活动的连线是“默认值“； 2)它与该活动连线上条件为“true” ； 3)多路聚合还需要特别说明的是：多路聚合不一定要设置默认连线，也就 是说一个多路聚合的全部连线都可以设置条件。 【示例示例】 1.“全部聚合全部聚合”型聚合模式示例型聚合模式示例 图-“全部聚合”型聚合模式 如上图所示， “人工活动 3”的“聚合模式（JoinMode） ”设置为“全 部聚合” ，那么只有在它的前驱“人工活动” 、 “人工活动 1” ， “人工活动 2”都完成后， “人工活动 3”才可以运行。 2.“单一聚合单一聚合”型聚合模式示例型聚合模式示例 图-“单一聚合”型聚合模式 如上所示，由于“人工活动 3”的“聚合模式（JoinMode） ”设置为“单一 聚合” ，那么根据上面的算法说明，当“人工活动”完成后， “人工活动 3” 就可以运行了。而无需考虑“人工活动 1”或“人工活动 2”是否完成。 3.3.“多路聚合多路聚合”型聚合模式示例型聚合模式示例 1)由前驱活动射出的连线上中有默认值 图-“多路聚合”型聚合模式 如上图所示，由于“人工活动 3”的“聚合模式（JoinMode） ”是“多路聚 合”并且在处理的过程中“num=6” ，那么根据上面的算法说明由于“人工活动” 与“人工活动 3”以及“人工活动 1”与“人工活动 3”的连线上的条件都满足， 因此“人工活动 3”在“人工活动”和“人工活动 1”完成后被触发。 2)由前驱活动射出的连线上都设置条件 图-“多路聚合”型聚合模式 如上图所示，由于“活动 E”的“聚合模式（JoinMode） ”是“多路聚合” 并且在处理的过程中“num=6” ，那么根据上面的算法说明由于“活动 B 与“活 动 D”的射出的连线上的条件都满足，因此“活动 B 与“活动 D”都完成后，活 动 E 才被触发。 分支模式分支模式 分支模式，表示该活动结束后，它的后继活动的触发情况。它包括“全部 分支（AND） ” 、 “单一分支（XOR） ”以及“多路分支(OR)”三种情况： 1.1.“全部分支全部分支”型分支模式型分支模式 表示该活动结束后它的所有后继活动将同时被触发。 2.2.“单一分支单一分支”型分支模式型分支模式 如果该活动的分支模式为“单一分支” ，那么引擎会根据由该活动“射出” 的连接线上的条件进行判断，决定该触发哪个后继活动。具体分为下面三 种情况： 1)满足条件的连接线所指的活动被触发； 2)如果有若干个连接线上的条件都满足，那么比较连接线上的优先级， 优先级高的那条连接线所指的活动将被触发； 3)如果连接线上的条件都不满足，那么取“默认值”的那条连接线所 指的活动将被触发。 注注活动的“分支模式”为“单一分支”时，由它射出的连接线有且只有 一条线的取值是“默认值” 。 3 3 “多路分支多路分支”型分支模式型分支模式 如果该活动的分支模式为“多路分支” ，那么引擎会根据由该活动“射出” 的连接线上的条件进行判断，决定触发哪个或哪些后继活动。具体分为下 面二种情况： 1)如果连接线上取“默认值” ，那么由此连接线所指的后继活动会被触发； 2)如果连接线上的条件满足，那么由此连接线所指的后继活动会被触发。 3)多路分支还需要特别说明的是：多路分支不一定要设置默认连线，也就 是说一个多路分支的全部连线都可以设置条件。 【示例示例】 1.“全部分支全部分支”型分支模式示例型分支模式示例 图-“全部分支”型分支模式 如上图所示，由于 A 活动的分支模式是“全部分支” ，那么当 A 活动完 成后它后继的所有活动（B、C、D）将同时被触发。 2.2.“单一分支单一分支”型分支模式示例型分支模式示例 1)由该活动射出的连线上只有一个满足条件时 图-“单一分支”型分支模式 1 如图所示，由于“A” 活动的分支模式是“单一分支”并且在处理 的过程中“num=6” ，所以由“A”射出的连接线上只有“num 5”满 足条件，因此“B”活动满足条件被触发。 2)由该活动射出的连线上有若干个满足条件时 图-“单一分支”型分支模式 2 如上图所示，由于“A” 活动的分支模式是“单一分支”并且在 处理的过程中“num=1” ，尽管由 A 指向 B 和 C 的两条分支都满足条件， 但指向 B 的优先级大于指向 C 的优先级，因此“B”活动被触发。 3)由该活动射出的连线上没有一个满足条件时 图-“单一分支”型分支模式 3 如上图所示，由于“A” 活动的分支模式是“单一分支”并且在处理 的过程中“num=2” ，那么由“A”射出的连接线上没有满足条件的， 因此“D”活动被缺省触发。 3.“多路分支多路分支”型分支模式示例型分支模式示例 1)由活动射出的连线上中有默认值 图-“多路分支”型分支模式 如上图所示，由于“开始活动”的分支模式是“多路分支”并且在处理 的过程中“num=6” ，那么根据上面的算法说明，由“开始活动”射出的 连接线上为“默认值“所指的后继活动“人工活动”一定会被触发；又由 于满足“num5”的条件所以“人工活动 1”也会被触发 2)由活动射出的连线上中没有默认值，全部设置条件 如上图所示，由于“开始活动”的“分支模式”是“多路分支”并且在处 理的过程中“num=6” ，那么根据上面的算法说明由于射向“活动 B 与“活动 D”的连线上的条件都满足，因此“活动 B 与“活动 D”在开始活动结束后被触 发。 2.2.3 参与者设置参与者设置 活动参与者实际上是指在流程实例运行过程中，流程实例“流转”至此时 该活动实例所对应的工作项有哪些人可以执行。在流程定义时设置活动的参与 者实际上是圈定流程实例运行至此时可以执行该活动实例所对应工作项的人员 范围，可以是机构、角色或人。 EOS WorkFlow 提供了 4 种可以获取参与者的方式： 组织机构与角色组织机构与角色：参与者由开发人员从机构树中获取 只选择一人：表示该活动所对应的工作项直接分配给该人处理 超过一人：表示该活动所对应的工作项由这些人中的某个人以“领取” 的方式处理 虚拟岗位（机构虚拟岗位（机构+ +角色）角色）：表示在不设置岗位的情况下，由部门+角色共同决定 一个人工活动的参与者。 流程启动者流程启动者：表示活动参与者为该流程的启动者 活动执行者活动执行者：表示活动参与者为某个已完成的活动实例所对应工作项的执行者 从相关数据获取从相关数据获取：表示活动参与者由相关数据指定。由相关数据获取参与者的 规则详见从相关数据获取参与者 从规则逻辑获取从规则逻辑获取：表示活动参与者由某个规则逻辑的返回值确定。由规则逻辑 获取参与者的规则详见从规则逻辑获取参与者 特别说明特别说明:如果要改写组织机构权限并在参与者设置的时候显示新的组织机构树， 具体操作请参见知识库文档：组织机构与工作流集成方案.doc 虚拟岗位（机构虚拟岗位（机构+ +角色）设置参与者角色）设置参与者 -图通过机构+角色实现虚拟岗位设置参与者 用角色+机构的方式设置参与者需要特别注意的是，在该活动激活以前一定 要将上图中机构变量路径设置到相关数据区中。 此外，还有一种方法设置一组机构：把多个机构写成如下格式： 1 2 这样机构变量路径 xpath 写成：list/org/id 即可。这样，工作流引擎也会找 到多个机构 id，从而实现设置一组机构+角色的要求。如下图所示： 图-设置一组机构变量 从相关数据区设置参与者从相关数据区设置参与者 1）从相关数据获得一个具体的参与者）从相关数据获得一个具体的参与者 【算法说明】 从相关数据的 XPATH 中，直接指定一个参与者。 注：这种方式获得的参与者只能是个人。相关数据必须满足下面的结构。 tiger 2）从相关数据获得某一类型的参与者（指定一个或一组人员）从相关数据获得某一类型的参与者（指定一个或一组人员） 【算法说明】 从相关数据的 XPATH 中，获得某一类型的参与者。可以是一个人，也可以是 某一角色或某一机构的一组人。相关数据必须满足下面的结构。 3）从相关数据获得一系列参与者）从相关数据获得一系列参与者 【算法说明】 从相关数据的 XPATH 中，获得一组参与者。可以是一个人、一个角色、一个 岗位、一个机构，也可以是机构、角色或个人的集合，还可以是岗位列表的集 合。相关数据必须满足下面的结构。 id 和 type 的含义如上所示 特别说明特别说明 ：在上面 XPATH 结构中如果 type 是“person” ，那么 id 即为用 户 ID；如果 type 是 “role” ，那么 id 即为角色 ID；如果 type 是“organization” ， 那么 id 即为机构 ID；如果 type 是 “position” ，那么 id 即为岗位 ID；如果 type 是 “position_list” ，那么 id 即需满足如下格式： / type=”OR”表示组织机构 rolea/ 角色 ID $orgID / 获取机构 ID 的 XPATH（相对于相关数据的根路径） 。 ”$” 不可少，标识其后的串是个 XPATH。 此外，还有一种方法设置一组机构：把多个机构写成如下格式： 1 2 这样机构变量路径 xpath 写成：list/org/id 即可。这样，工作流引擎也会找 到多个机构 id，从而实现设置一组机构+角色的要求。 从规则逻辑设置参与者从规则逻辑设置参与者 从规则逻辑获取参与者从规则逻辑获取参与者 【算法说明算法说明】 从业务逻辑获取参与者列表，然后再按照“分配到组织机构”的模式进行分配。 从业务逻辑返回 Dom 当中找到参与者列表的方法： 1）如果返回的结果中包括下面的结构，系统从）如果返回的结果中包括下面的结构，系统从 listlist 节点中获取多个参与者。节点中获取多个参与者。 2）如果从规则逻辑中没有找到如果从规则逻辑中没有找到 listlist 节点，那么系统会查找节点，那么系统会查找 ParticipantParticipant 节点节点. . 获取参与者。格式如下所示：获取参与者。格式如下所示： id 和 type 的含义同上。 特别说明特别说明 ：如果如上所示的两种结构都存在于调用的规则逻辑的返回的 结果中，那么系统只会从 list 节点中获取参与者。 在上面 XPATH 结构中如果 type 是“personperson” ，那么 id 即为用户 ID；如果 type 是 “rolerole” ，那么 id 即为角色 ID；如果 type 是“organizationorganization” ，那么 id 即为机构 ID；如果 type 是 “positionposition” ，那么 id 即为岗位 ID；如果 type 是 “position_listposition_list” ，那么 id 即需满足如下格式： / type=”OR”表示组织机构 rolea/ 角色 ID $orgID / 获取机构 ID 的 XPATH（相对于相关数据的根 路径） 。 ”$”不可少，标识其后的串是个 XPATH。 此外，还有一种方法设置一组机构：把多个机构写成如下格式： 1 2 这样机构变量路径 xpath 写成：list/org/id 即可。这样，工作流引擎也会找 到多个机构 id，从而实现设置一组机构+角色的要求。 工作流参与者设置机制说明工作流参与者设置机制说明 流程实例根据流转条件依次激活实例中的相应的活动，当活动分配给某个 参与者（唯一的 userID）的时候，就在 WFWorkItem 表中形成一条工作项记录， 主键为 workItemID。在 WFWorkItem 工作项信息表里还有个很重要的字段： participant。这个字段描述该工作项的参与者具体是谁。在工作项参与者 WFWIParticipant 表中，也有工作项 workItemID 和参与者 participant，不过， 这个表里描述的是根据流程定义，活动被激活后工作项的分配情况，根据流程 定义的设置形成相应的记录，比如，流程定义中有 3 种参与者，那么在 WFWIParticipant 表中也形成 3 条记录，所以这里的参与者有可能是具体个人 （userID） ，也可能是角色（role） ，也可能是机构（orgID） ，也可能是岗位 （positionID） ，当工作项没有领取的时候，在 WFWorkItem 表中也会形成一条 记录，这条记录的参与者字段 participant 是用“|”隔开的参与者串，这个串 中的参与者是在流程定义的时候定义的。当工作项被领取以后，就会在工作项 表 WFWorkItem 表里出现具体的执行人信息。此外，有时候工作项会出现该派的 情况，这个时候，改派以后具体参与者也在工作项表 WFWorkItem 表有描述，而 工作项参与者 WFWIParticipant 表不会有什么变化。 2.2.4 时间限制时间限制 活动的时间限制表示活动实例启动启动后必须在多长时间内完成。在活动 时间限制的设置中 EOS WorkFlow 为开发人员提供了指定具体的限制时间、超时 是否进行邮件通知、是否在超时前进行提醒、是否发提醒通知等功能。 活动时间限制的设置：开发人员可以根据业务需要在“人工活动”和“子流程 活动”中进行设置。 活动时间限制的计时：从活动实例启动时开始计时 活动时间限制的获取：直接指定、从相关数据获取（格式：3.5.20 表示时 限为 3 天 5 小时 20 分钟） 活动还有超时的触发事件设置，可以针对超时做具体的操作。 EOSEOS WORKFLOWWORKFLOW 判断流程或人工活动超时的原理判断流程或人工活动超时的原理 流程或人工活动的时间限制中设置的限制时间将写入表 WFProcessInst 或 WFWorkItem 的 limitNum 字段中，单位为毫秒，limitNumDesc 是其描述字段； finalTime 是时间限制到达后的时间。EOS WorkFlow 将当前时间与 startTime 相减的结果与 limitNum 比较，一旦超出时间限制就将 isTimeOut 字段置为 Y， 表示超时；timeOutNum 表示超时了多长时间，在流程结束时写入。如果设置了 超时提醒，该字段可能出现负数，是未超时的表现，只有正数才表示超时的时 间，timeOutNumDesc 是其描述字段。 2.2.5 多工作项多工作项 一个活动到底产生多少个工作项并且产生的这些工作项又由谁来做呢？EOS WorkFlow 就工作项的产生和分配问题提供了 2 种策略： 按参与者设置个数领取工作项：按参与者设置个数领取工作项：按照此活动参与者的个数产生工作项。每 个参与者一个工作项，若参与者中包括若干人员（比如参与者的类型为机构或 角色） ，则这些人员可通过先“领取”的方式执行工作项。 例如：某活动设置了 3 个参与者：tiger，角色 B(包含 fish 和 goose 两人)， 机构 A(包含 kitty、snoppy、micky 三人)，那么按照此策略将产生 3 个工作项。 具体分配为：tiger 一个工作项，由其直接执行(该参与者只有一个人所以无需 先领取)；角色 B 一个工作项，由 fish 或 goose 中的一个人以领取的方式执行； 同理，机构 A 一个工作项，由 kitty、snoppy 或 micky 中的一个人以领取的方 式执行。 按操作员个数分配工作项按操作员个数分配工作项：根据参与者中的人员个数产生工作项，并且这 些工作项将直接分配到参与者中的人员，每人一个。 例如，上面的例子若按此策略将产生 6 个工作项， tiger、fish、goose、kitty、snoppy，micky 每人分配一个工作项，直接执行。 多工作项执行 不管工作项的个数如何相关人员每个人至多只能执行一个。 未完成工作项自动终止未完成工作项自动终止 1）选择选择“是是”：工作流引擎在结束活动实例的同时对于那些剩余的未完成 的工作项作“停止停止”处理。 2）选择选择“否否”：那些剩余的未完成的工作项仍处于运行运行状态，尽管此时活 动实例已结束。这些工作项的拥有者此时无论是否处理它们，已不会对运 行的流程造成任何影响，只有当流程实例结束时，引擎才会将这些工作项 终止 活动项与工作项活动项与工作项 活动项和工作项是一对多的关系，人工活动被激活后，形成活动项实例继 而有生成工作项实例，供参与者操作。在工作项表 WFWorkItem 中保存了活动项 实力和工作项之间的关系。 通过通过 BL_BL_finishActivityByDefIDfinishActivityByDefID 结束活动的方式结束工作项结束活动的方式结束工作项 在现有工作流工作项结束调用中一般都会采用 BL_finishWorkItem 这个运 算逻辑调用，但是也有情况可以通过 BL_finishActivityByDefID 来结束活动的 方式结束工作项。如果这样做的话会带来一个问题， BL_finishActivityByDefID 方法是结束活动，当活动中的工作项需要领取而又没有领取的情况下，如果直 接使用该方法，则会导致此活动被终止，而不是正常结束，所以这种情况下只 能直接使用 BL_finishWorkItem 来结束工作项。要么先领取，然后再用 BL_finishActivityByDefID 来结束活动。orkItem 2.2.6 触发事件触发事件 创建创建：指活动被实例化时 启动启动：指活动被实例化并满足启动条件时，当活动被创建的同时也会被启动， 所以这两项的触发时机是一致的。 结束结束：当活动完成时（finish） 超时超时：当活动超时时（如果设置了时间限制，该项有效）触发 事件类型：标明事件动作的类型。EOS WorkFlow 提供基于 EOS 平台的业务逻辑 和运算逻辑两种类型。 事件动作：由开发人员根据具体的业务需求自行定义。可以是一个运算逻辑也 可以是一个业务逻辑。 触发事件设置说明： 1、触发时机和调用方式。这里需要特别注意的是，调用方式同步和异步的 区别。同步是指：以“同步”的方式调用触发事件，等待事件运行完成后，该活 动才启动 。 异步是指：以“异步”的方式调用触发事件，该活动在启动完触发事 件后就启动，而无需等待触发事件运行完成。 2、触发事件。如果用业务逻辑业务逻辑来实现，那么触发事件中产生的数据还可以 在业务逻辑中输出，这样就可以将这些数据直接设置为相关数据了。如果是运 算逻辑则不能输出到相关数据区中。 3