工作流技术方案

工作流技术方案
目录
1概述 (3)
1.1工作流现状 (3)
1.2建设原则 (3)
1.3建设目标 (3)
2总体设计方案 (4)
2.1业务架构设计 (4)
2.1.1业务功能设计 (4)
2.1.2业务模型设计 (5)
2.2总体架构设计 (6)
2。

2.1工作流总体结构图 (6)
2.3技术架构设计 (7)
2。

3.1展现层 (7)
2.3。

2控制层 (7)
2。

3.3业务逻辑层 (7)
2。

3.4数据持久层 (8)
2。

3。

5缓存 (8)
3应用系统设计 (8)
3.1流程定义 (8)
3。

2流程管理和监控 (8)
3.3工作流引擎 (8)
3。

4工作项列表 (9)
1概述
1.1工作流现状
工作流是实现企业业务过程建模、业务过程仿真、业务过程管理与集成,从而实现最终业务过程自动化化的核心技术。

传统的工作流管理系统缺乏柔性，不能及时响应变化和相互之间缺乏互操作的缺点不能满足这种复杂业务流程管理的需要.针对这种情况,提出工作流管理平台的实现方案，以便更好地对企业业务流程实行管理。

1.2建设原则
工作流管理平台的设计主要遵循实用性、稳定性、高效性、灵活性等原则：
（1）稳定性原则：需要采用成熟的技术模型、稳定的软硬件产品、软件开发平台和工具。

（2）安全性原则:提供完整备份机制，提供安全的数据访问机制。

（3）友好性原则：考虑到平台将针对各个层面的用户群体，使用者的计算机水平参差不齐，所以需求平台提供的界面简便友好、操作方便。

（4）扩展性原则：系统设计应具有良好的可扩展性和升级能力，可以根据新的业务拓展，方便地追加新的模块，也可以根据运营的状况,自由地追加硬件,
以实现对系统有效的负载均衡。

（5）快速开发原则：提供封装的开发构件,提供基本的系统管理模块，提供简洁的开发模板，能够满足各类业务需求的快速开发.
1.3建设目标
根据上述原则，工作流管理平台建设的主要建设目标为：
（1）实现基于Jbpm的流程引擎的二次开发.
（2）实现图形化的流程定义工具和流程管理监控工具.
（3）实现工作项列表（包括待办事宜、已办事宜、历史事宜）的统一管理界面。

（4）实现在流程生命周期中应用系统对流程触发的动作的相关服务接口:工作流定义相关服务、工作流引擎相关服务、工作项列表相关服务。

2总体设计方案
2.1业务架构设计
2.1.1业务功能设计
以上图表说明系统功能的物理结构及调用关系。

以下分四部分说明:
系统的层次结构大致是:前台功能模块—〉后台功能模块（Action层+Service层+Dao层)，即:前台功能模块通过Ajax与后台功能模块的Action交互，Action调用Service层相关接口,与底层Dao/Spring Framework交互，完成数据的存取.
【流程定义模块】涉及到语义解析，需通过【格式转换模块】转换并被【jbpm 引擎的定义模块】处理后才能存取。

【流程管理监控模块】中的暂停/恢复/终止等管理功能需经过【工作流公共模块】并被【jbpm引擎的运行时模块】处理才能完成.其查询功能直接通过DAO层完成，【工作流工作项列表模块】也是如此。

外部接口实现，【工作流提供的外部接口】及【工作流调用的外部接口】为WebService形式，功能由【工作流公共模块】实现。

引擎增强实现方式，一是在已有的jbpm引擎类上增加属性及逻辑，如【预警定义】，【查询界面及处理界面设置】等功能；二是通过新增类来扩充功能,如【流程/流程节点数据定义】、【流程参与人表达式定义】,【参与人表达式解析模块】、【多实例（任务/子流程）模块】等功能。

2.1.2业务模型设计界面Url定义
流程定义工作流流程数据定义
节点数据定义
节点
任务
参与人及表达式定义
工作流分类
流程实例
流程令牌
数据实例
任务实例
非工作流待办
下一步参与人转移
【工作流分类】是对工作流进行管理的目录层次，在此目录下创建一个或多个【工作流】；
【工作流】是【流程定义】的总称，代表一个业务流程的名称.并且它为【流程定义】指定一个或多个可用的【界面Url定义】;
【界面Url定义】是指人工活动的操作界面或查看界面的url链接；
【流程定义】是【工作流】的具体内容，即一个业务流程的定义。

【流程定义】是可变的，即有不同版本之分;【流程定义】是由【节点】和【转移】组成,并且拥有自己的【流程数据定义】；
【流程数据定义】（以及【节点数据定义】）是外部程序与工作流引擎交互的媒介。

通过它外部程序可影响到工作流的【节点】调度；
【节点】是指【流程定义】的一个活动，【节点】中的人工活动拥有操作界面或查看界面，【节点】拥有一个或多个【任务】；
【任务】代表【节点】的一种类型，即“人工活动"，【任务】可指定完成人工活动的【参与人及表达式定义】；
【转移】是一个源【节点】跳转到下一个目的【节点】的条件；
【节点数据定义】类似【流程数据定义】，不同的是后者是全局数据,前者是局部数据；
【参与人及表达式定义】是定义完成【节点】(人工活动)的参与者。

【流程实例】是工作流引擎运行时依照【流程定义】创建的一个实例。

它拥有一个或多个【流程令牌】；【流程令牌】代表流程运行时的一个路径分支，指示当前运行到达的【节点】；当到达一个人工活动【节点】时，将创建该【节点】的【任务】的一个或多个实例，即【任务实例】，并根据【参与人及表达式定义】创建完成【任务实例】的【下一步参与人】；
在流程的生周期的任何时刻，根据【节点数据定义】和【流程数据定义】,可创建一个或多个【数据实例】，以影响到流程的进程。

工作流引擎按照以上规则，不断产生【任务实例】及完成【任务实例】，直到流程结束。

【非工作流待办】是指不需要构建流程定义而任意创建的【任务实例】.
2.2总体架构设计
2.2.1工作流总体结构图
上图是WFMC(Workflow Management Coalition)为实现不同工作流产品之间的交换,给出的5类接口规范。

接口一描述流程的模型及定义，接口二、三描述与应用之间的接口(即客户端应用程序及统一框架等）,接口四描述不同工作流引擎间的集成，接口五描述对流程的监控.
接口一即XPDL(XML Process Definition Language）,是由WFMC提出的一个工作流描述规格，使用XML文件让不同的工作流程软件间交换商业流程定义。

XPDL是一个通用的框架,据WFMC认证列表统计目前全球约有80个厂商支持该标准，包括IBM、BEA(Oracle）、Tibco相关流程产品,目前XPDL的最新版本是2。

1(2008年4月23日approve version)。

XPDL给定了流程定义间进行相互转换的XML Schema元模型，这个XML Schema可理解为与运行控制无关的描述结构,为设计流程和运行流程提供了形式上的可分离,这样无论开发者使用Java、。

Net还是轻量级的PHP、Python语言，采用有限状态机还是Petri网，只要外部接口符合XPDL规范，那么就可以保持相同的表示形式和互操作,这就为厂商间标准合规性验证提供了一个通用的描述框架,更重要的是XPDL对不支持的厂商个性场景提供了扩展，这个扩展框架约束能够保证流程对外表现形式的一致性。

正是这个定位使得XPDL在与十几年中出现的众多潜在新兴竞争标准之争中仍然保持旺盛的生命力，并催生了不同竞争活力的工作流产品。

对于实现XPDL规范的工作流产品,以XPDL为持久格式，由厂商实现的流程引擎执行该描述。

接口一、二、三的标准化，可以使得应用系统使用不同的工作流产品均可以平滑过渡。

接口四的标准化，主要是实现工作流引擎级联。

2.3 技术架构设计
2.3.1 展现层
由HTML 页面组成，提供与用户进行交互接口.用户在此输入数据、提交数据并得到执行结果对于绝大多数功能，使用JSP 来实现。

对于某些WEB 页面无法完成的工作，例如自定义报表,自定义申请单等，通过JSP 中嵌套客户端程序ActiveX 来实现。

2.3.2 控制层
即Web 服务层，是对展现层的请求进行处理，将用户提交的数据转发给业务逻辑层，同时还对业务逻辑层应用层的返回资料进行处理，生成相应HTML 页面传送到展现层.
控制层采用Struts web 应用框架，Struts 框架分离开页面数据处理、页面流转控制、页面生成，使程序架构更加清晰,代码可重用性高。

Struts 框架提供了扩充的JSP 标签库，简化开发人员开发JSP 界面。

采用Struts 框架，页面设计人员和代码编写人员可以各司其职,开发分工更加合理。

2.3.3 业务逻辑层
业务逻辑层进行实际的业务逻辑处理，并将数据存储到数据持久层中。

业务逻辑
应用层实现业务数据库的缓冲，在业务量大的情况下可以减轻数据库的负担，提高业务处理能力。

业务逻辑层采用Spring应用框架，完成IOC容器，AOP,事务管理，DAO支持等工作;SPRING的WEB层技术没有采用。

Spring框架结构简单,可配置性好，实现了系统的松散耦合。

2.3.4数据持久层
数据持久层实现数据的物理存储和使用。

由于控制层和业务逻辑层运行在中间件服务器软件平台上,因此可以很容易的实现与各种各样数据库或者与企业已有的各个信息系统的连接
数据持久层使用Hibernate访问数据库.
2.3.5缓存
将平台相关的配置信息、参数信息一次性加载到内存中，对数据的获取直接通过共享内存取得。

为了不使缓存信息丢失，应用服务应该支持热部署，如果选用的应用服务器不支持热部署，则需要考虑多机集群保证缓存信息不丢失。

3应用系统设计
根据业务分析,工作流平台包括流程定义、流程管理和监控、工作流引擎、工作项列表等几个部分。

3.1流程定义
业务流程能在工作流引擎中流转的第一步就是用严谨的计算机化的方式描述业务流程,这种严谨的描述叫做流程定义。

流程定义由活动及其关系的网络组成,它有明确的开始和结束，活动间的逻辑关系以及特定活动的相关信息(如活动的参与人等).有关流程定义的操作包括对其进行语法、语义的校验,以及发布、保存、导出等。

3.2流程管理和监控
流程管理员对所有的流程实例，都能够图形化展示流转的历史记录。

对流程实例的发起信息、每一步活动的处理信息、流程及活动的所有数据进行展示；对于子过程活动，双击后能够看到对应子流程的流转全过程，实现企业级流程全貌展现；能够在流程图上模拟流程流转的全过程.特别对于运行中的流程实例，还提供暂停、恢复、终止、删除等管理功能；对于当前流程实例中运行中的活动，提供跳过、回退、重新指定参与者等管理功能。

3.3工作流引擎
主要是对Jbpm的二次开发，对工作流引擎的增强,主要是要增加参与人表达式的计算、多实例节点、预警处理、流程数据处理、流程定义格式转换、多实例子流程等.
参与人表达式的计算：流程定义中流程节点的参与人表达式(字符串形式）,工作流
引擎根据表达式及流程运行时的上下文动态解析出某节点的参与人;表达式会依赖于权限的设置。

多实例节点：流程定义中某节点的属性为多实例，指定分裂方式（按角色、人员）,工作流引擎负责保存、解释及实现多实例属性，在流程运行时根据上下文动态解析出本节点的参与人及实例个数.
预警处理：流程节点指定本节点的任务从创建到完成的限定时间和提前的警示时间。

当指定的警示时间到期时,在待办列表中用红色字体显示本待办事项，警示用户任务即将到期。

流程数据处理：流程数据是用户与流程交互的方式之一.通过流程数据,用户可以影响流程运行如分支选择（驳回，结束）等，也可以用来保存业务数据如申请单号。

流程定义格式转换：Jbpm有自己的流程定义格式,但缺少可视化的流程定义工具。

通过流程定义工具,允许按其格式处理流程定义,但存储时需要将其定义的格式转换为Jbpm的能理解的格式;流程定义工具加载流程定义时，需要将Jbpm的格式转换回流程定义的图形界面。

多实例子流程：当一个节点的工作项包含多个处理步骤时，适于采用子流程处理.子流程可以是一个实例也可能是多个实例。

3.4工作项列表
流程流转的时候与用户交互的流转步骤会产生若干工作项，而要处理的所有流程的工作项为待办事宜，已经处理过的工作项为已办事宜，已经处理过并且其业务流程已经流转完成的工作项为历史事宜.。