当前位置:文档之家› 基于OA系统的工作流引擎设计方案

基于OA系统的工作流引擎设计方案

基于OA系统的工作流引擎设计方案1引言1.1课题的背景与目标工作流的概念起源于生产和办公自动化领域,是针对日常工作中具有固定流程的业务活动提出的一个概念。

工作流管理联盟(WFMC)给出的工作流定义是:工作流是一类能够完全或者部分自动执行的经营过程,它根据一系列过程规则、文档、信息或任务能够在不同的执行者之间进行传递与执行。

该技术的目的是通过将工作分解成定义良好的任务、角色,按照一定的规则和过程来执行这些任务并对它们进行监控,达到提高工作效率、降低生产成本、提高企业生产经营管理水平和企业竞争力的目标。

工作流管理系统的核心部分是工作流引擎,引擎是驱动流程流动的主要部件,它负责解释工作流流程定义,创建并初始化流程实例,控制流程流动的路径,记录流程运行状态,挂起或唤醒流程,终止正在运行的流程,与其他引擎之间通讯等等工作。

目前,工作流技术还处于发展曲线的初级阶段,然而,关于这方面的研究十分活跃,形成了许多规标准。

例如主要的有:工作流管理联盟(Workflow Management Coalition ,WfMC)在体系结构[6]、工作流相关术语[7]及应用程序接口[8]、管理控制接口[9]、过程语言描述[10]等方面提出的一系列规。

还有Microsoft, BEA, IBM, SAP等公司联合提交发布的BPEL规等等。

在实际应用中开源产品占据了重要的地位,如JBoss 项目中的jBPM、由OpenSymphony组织开发的OSWorkflow、Enhydra组织开发的Shark。

在国,交通大学的基于Petri网点分布是工作流管理的研究,大学的基于工作流过程定义语言(WPDL)的工作流建模平台,都取得了良好的研究成果。

但是工作流管理技术很多方面还不成熟,在使用过程中往往会遇到的一个重要问题是系统过于庞大复杂:一些工作流软件产品,特别是国外成熟的产品,经过多年的发展,功能强大,配置和接口多样灵活。

对于国大部分初次使用工作流技术的中小型项目来说,这些工作流软件的功能特性大大超过了需要,客户需要承受漫长的学习周期、复杂的安装配置等带来的风险。

鉴于上述的原因,本课题的目标在于提出一个配置简单、使用方便、功能实用的工作流引擎的设计方案,并完成编码。

该工作流引擎——OAworkflow是借鉴了已有的工作流引擎,对某些复杂功能进行简化后,重新设计的。

与传统工作流管理系统相比,本工作流管理系统具有以下优点:1)支持灵活的流程定制该系统能够针对办公自动化系统中的典型流程案例对流程进行灵活定制,支持的流程路由包括:顺序路由、汇聚路由和分支路由。

用户可以根据具体的业务流程,使用客户端建模工具定制合适的模型。

2)功能详细实用例如该系统支持流程分支跳转的时候,允许用户手动指定流程的直接后续步骤;当审批不合格时,文档回退的功能等。

3)文件权限设置精确该系统的每个业务流程绑定一个公文,处于流程中的各个活动对公文的读写权限看精确到字段。

4)支持可视化建模5)结构清晰,配置简单1.2课题研究容及文本组织本课题的重点研究容有:1)模型定义。

本文分析了办公自动化项目的功能需求,然后针对项目对流程控制的灵活需求,采用了一种结构清晰、功能完整的过程定义格式,使引擎在支持流程分支跳转的时候,还允许用户手动指定流程的直接后续步骤,在借鉴了现有工作流引擎设计思想的基础上,给出了一个工作流引擎的设计方案。

2)工作流引擎的实现。

本文分别从流程实例化、流程实例管理、流程导航和维护相关数据等模块详细描述了实现方案,其中关于系统的关键功能部分给出了具体API语义分析。

3)技术架构。

本项目采用了Spring + Hibernate 这种流行的Web应用程序设计框架组合。

从而使得该引擎具有架构清晰开放的特点,系统有着清晰的分层结构。

本文由以下六章和参考文献组成:第一章引言,介绍了本课题的背景和意义。

第二章相关技术及原理,介绍了Spring 开发框架、Hibernate 数据库持久层技术、Ajax 技术、JavaScript、JSTL第三章需求分析,给出了用例阐述及用例图第四章系统设计,包括数据库设计、时序图等第五章实现,重点从流程实例化、流程实例管理、流程导航和维护相关数据等模块描述了实现方案及一些关键API 的分析第六章总结2相关技术及原理2.1工作流技术工作流的概念起源于生产组织和办公自动化领域,它是针对日常工作中具有固定程序的活动而提出的一个概念。

目的是通过将工作分解成定义良好的任务、角色,按照一定的规则和过程来执行这些任务并对它们进行监控,达到提高工作效率、降低生产成本、提高企业生产经营管理水平和企业竞争力的目标。

2.1.1工作流引擎核心功能工作流引擎降低了工作流系统应用模块与业务流程之间的祸合度,当业务流程发生变化时,只需修改流程定义,具体的应用程序保持不变,工作流引擎对于用户来说是透明的。

目前,工作流引擎的应用可以分为三种方式:➢作为一个完整的系统提供给最终用户,能单独运行,如IBM的Lotus Domino/Notes系统。

➢仅仅作为企业应用集成(Enterprise Application Integration EAI)平台。

EAI将进程、软件、标准和硬件联合起来,在两个或更多的企业系统之间实现无缝集成,使它们就像一个整体一样,如B2B形式的电子商务。

➢嵌入到企业应用中,只提供工作流引擎服务,开源领域的OS Workflow引擎即属于这种情况。

从图2.1.1中可以看出,用户可以通过系统提供的客户端(如建模工具、任务列表等)与工作流引擎进行交互。

从应用上来说,一个工作流引擎必须具有的核心功能包括:(1)流程实例化及执行过程模型:解释企业经营过程的流程定义,根据过程执行需要的初始条件和执行参数生成过程实例,运行过程实例并管理其运行过程。

一个过程模型实际是企业经营过程的一个模板,它可以被执行多次,也可以有多个有关这个过程模型的实例在同时运行。

(2)为过程和活动的执行进行导航:包括启动和终止实例,根据活动定义中的条件决定后续活动的执行顺序。

(3)与外部资源交互完成业务活动:分为用户应用接口和直接调用应用接口两种情况。

用户应用接口是指首先通过任务列表管理器向用户提供任务列表,供用户选择相应的任务(必要的时候可以调用相应的工具来完成),任务完成后由用户修改任务项的状态。

直接调用应用接口是指由工作流引擎直接调用相应的应用程序,应用将执行情况反馈给工作流引擎,如一份流转过程中的学校公文经过校领导会签以后,系统进行归档并自动发往各相关职能部门。

(4)维护工作流相关数据:工作流在执行过程中要维护不同过程和活动实例的部状态信息,以及用于协调和恢复的各种检查数据和恢复/重起信息,向用户传递必要的相关信息。

图2.1.1工作流引擎应用层次图2.1.2两种现有工作流引擎目前,OpenSymphony组织开发的OS Workflow,和Moss项目中集成的jBPM是应用比较广泛的工作流产品,本节将对这三种引擎的设计方案和实现机制进行分析介绍。

1.jBPMjBPM结合了工作流应用开发的便利性和企业应用集成能力,其业务流程是通过本身提供的流程定义语言jPDL (jBPM Process Definition Language)进行配置,但由于没有提供规接口,从而不易于与其它工作流引擎进行交互。

由于JBPM持久层采用Hibernate技术来实现,因此具有一定的可扩展性。

jBPM中结合了状态图、活动图和PetriNet的知识,它采用了Token的概念,用来表示任务分配给某一个Acto叹执行者,可以是人或应用系统)的依据,即只有当某个执行者获得了一个Token,才有可能去执行任务,因此,jBPM的流程推进机制实际上表现为Token的转移。

引擎在一个流程实例开始的时候产生一个Root-Token,而这个Token对象会随着流程实例运行而转移,从而来表示任务的依序执行。

在此过程中,如果将一项任务分配给某个执行者,该执行者就会获得一个Token对象标识。

2.OSWorkflowOSWorkflow基于有限状态机(Finite State Machine, FSM)的概念,它的每个State是通过StepID和Status联合表示,而State的转换是由动作驱动的。

在工作流生命期有至少一个或多个活动的State.OSWorkflow本身自带了一个可选的用户组织模型,该模型只提供了用户和用户组的存储,没有涉及用户的角色概念,在系统访问控制和授权方面不够完善,因此使用时通常选择配置使用自己实现的用户组织模型。

OSWorkflow具有一定的灵活性,在流程建模方面不仅支持BeanShell脚本,还支持Java, BSF和EJB等,并且可以采用JDBC, Hibernate, EJB等多种数据持久化方式。

[1]流程建模OS Workflow采用自己的流程定义格式,其流程定义遵守的规则包括:一个工作流定义由多个步骤(Step)组成,其中每一个步骤由一个或多个动作(Action)组成,一个动作可以由用户触发执行,也可能自动运行.每个动作至少有一个Unconditional Results和零个或多个Conditional Results,如果指定了多个Conditional Results,那么第一个符合条件的将会被执行,如果没有符合条件的Conditional Result,那么Unconditional Result将会被执行。

一个步骤的后续步骤有可能是其本身、一个新的步骤、一个分支结构(Split)或者一个汇合(Join)结构,当然,这些情况下工作流自身的状态也有可能发生改变。

如果结果是一个分支结构,在流程定义时需要设置一个“split”属性,其值表示将要执行的分支路径的标识。

相应地,一个分支结构也具有一个或多个Unconditional Results. Unconditional Results的值指向分支结构的各个不同分支。

OSWorkflow流程定义文件开始部分包括的initial-actions标签里面定义的是流程的初始化动作,每个步骤(就叩)里面包含一个或多个动作(action);在每个动作里面可以手动设置pre-functions和post-functions,表示在该action执行之前或之后要执行的动作;results元素则定义了执行完该动作后的结果流向。

[2]流程推进机制OS Workflow的流程推进机制与通常所说的流程不同,其驱动是通过动作(Action)的执行来进行的,其实现是分为两个步骤,一是具体实施动作,另一个是维护流程状态变迁。

一个动作的执行所造成的状态改变,可能使流程从一个Step 的某个Status变为另一个Status,也可能从一个Step的某一个Status变为另一个Step的Status。

相关主题