工作流参考手册

第1章总体说明在使用EOS WorkFlow的过程中，无论是开发者在“开发环境”中定义业务流程，还是“工作流引擎”控制流程流转，或是工作流参与者使用的“客户端”，再或者管理员使用的“管理与监控工具”，在这期间都会贯穿EOS Workflow 的5个主要对象——流程定义、活动定义、流程实例、活动实例以及工作项。

1.1 EOS工作流开发过程简述EOS的工作流开发过程可以看作是一个不断迭代的过程，如下图：首先是分析需求，然后根据需求定义流程，在这个阶段最主要的工作任务其实是设计，根据业务需求来设计流程，这个流程要怎么走，流程相关的数据如何流动，流程的参与者如何界定，与流程相关的业务数据如何流动及保存等等。

在这个阶段的工作结果是一个可以发布的流程，第一次形成的流程可能是一个比较简单的，并不完善的版本，但是随着迭代的进行，这个流程将不断地被修正和改进，直到形成一个能够使用的版本。

接下来是流程的发布，流程发布的目的是让工作流引擎能够识别该流程。

在开发环境(JBoss)下可以直接在Studio中发布流程，开发阶段一般用此方法，在生产环境中一般是先打包，然后在xlocalhost:端口/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="workflow" 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中，定义了历史记录备份的策略，如下：<group name="trans_history"><!--转移历史的策略：可能的值 TIME_BASED（固定时间转移）|ON_FINISH（流程实例结束时转移）|NEVER（不转移）|ON_START（系统启动时候转移）--><configValue key="trans_strategy">TIME_BASED</configValue><!--转移时间点列表：当trans_strategy配置为TIME_BASED时候有效。

表示转移到历史表的时间,格式示例:1:00,2:00,8:一八--><configValue key="time_list">0:30,5:00</configValue></group>第2章建模过程EOS Studio提供了可视化的开发环境来定义工作流业务流程模型，提供串行、分支、并行、聚合、循环、同步、子流程等丰富的流程逻辑结构，以及人工活动、自动活动、路由活动等多种活动类型，并可对这些活动属性进行定义，如参与者类型、触发事件、子流程属性、时间限制、回退动作、多工作项等，定义属性时可选择不同的数据类型、可灵活的扩展活动；可以通过表单数据为活动节点设置动态表单，其表单数据实现了动态表单的编辑，为日常工作中表单的定制提供了良好的设计工具。

2.1 流程定义流程定义由流程属性、活动属性、连接线三部分构成。

开发者可以根据实际中的业务需要设置流程上的基本属性、触发事件、时间限制以及流程启动者。

对每一个具体的活动则可根据实际情况设定其运行的方式、参与者以及调用的应用等信息。

完成流程定义的描述后即可提交、发布。

提交后的流程将生成XML格式的流程定义文件，存入流程定义库中2.1.1流程版本版本号的产生方式如下：1、开发人员指定版本号的格式为:X.Y.Z (其中X>0;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"作为当前流程的版本号。