工作流技术方案
工作流技术方案
目录
1概述3
1.1工作流现状 (3)
1.2建设原则 (3)
1.3建设目标 (3)
1 (4)
2总体设计方案4
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 (8)
3.1流程定义 (8)
3.2流程管理和监控 (8)
3.3工作流引擎 (8)
3.4工作项列表 (9)
1 (9)
1.1 (9)
1.2 (9)
1.3 (9)
1 (9)
1.1 (9)
1.2 (9)
1.3 (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工作流总体结构图
建立时功能
运行时过程
实例化及控
制功能
同用户及应
用软件的交
互功能
换，给出的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 业务逻辑层
业务逻辑层进行实际的业务逻辑处理，并将数据存储到数据持久层中。业务逻辑