工作流管理系统设计说明

工作流管理系统设计说明

工作流管理系统定位及其应用

目前工作流系统的运行有两种方式，一种就是我们原来已经实现了的工作流引擎和第三方开发工具的集成而开发的具有工作流性质的业务系统，此系统运行在工作流引擎上，工作流引擎负责流程的解释监控和控制功能，而我们用第三方工具开发的部分主要是完成事务的处理，完成业务点的处理。这种方式很好的解决了开发带有工作流性质的业务系统的流程控制及其流程变更的问题，这种方式的另外一个优点就是利用第三方开发工具开发的业务功能模块不会受到功能的限制，可以进行复杂的业务处理。工作流引擎和我们开发的业务功能模块的低耦合度，使得利用这种方式可以设计开发比较复杂的带有流程控制的业务处理系统。缺点：对于任何的业务处理系统都必须进行业务功能模块的定制开发，不能随需而变，迅速定制灵活的业务处理点。

另一种就是工作流引擎和表单结合，我们称之为“工作流管理系统“，目前市场上大多数工作流系统采用这种方式，基本可以解决大多数的业务流程处理。这种方式的优点就是可以通过模型的建立，表单的设计等工作，完成带有流程性质的业务处理系统，而不需要进行业务模块的开发工作，从而实现了零代码编程，在用户需求改变或者有新的需求的情况下，可以迅速做出调整，满足用户需求。缺点：此种方式主要适合于类似审批性质的流程处理，因为在业务处理点上，不适合做复杂的操作，目前的工作流系统为了解决这个问题，也采取了众多的方式，如利用一些嵌入插件，控件等方式，这样做在一定程度上可以解决部分复杂业务的处理，但是这种方式相对利用工作流和第三方开发工具集成开发来说好像更加复杂，况且对业务处理的能力更加有限，所以我们不建议使用这种方式。

有没有一种折中的方式很好的发挥两者的优点，而避免各自的缺点呢？初步设想将两种方式结合起来使用，共同发挥各自的优势，弥补各自的缺点，打造一个灵活的，功能强大的工作流管理系统。但是由于目前在工作流与应用的结合上，经验不是很多，所以暂时采取第二种方式，来实现我们的工作流系统，就是完成工作流引擎和表单的结合，在实现的过程中可以多做一些接口和注意他的扩展能力，以便下一步的顺利进行。

工作流管理系统完成后，可以处理事务处理点比较简单的业务流程，主要表现在以下几个方面：事务处理点没有复杂的业务逻辑；所有信息通过表单或者附件为载体表现；单个事务处理点处理信息单一，底层没有复杂联系的表结构。

工作流管理系统，在通过一些事务处理点功能的扩展，基本可以满足大多数业务流程的需要。

各个系统结合方式及系统运行的详细描述

工作流引擎怎样和表单、身份认证、邮件系统和文档系统结合起来，来共同的解决不同领域的业务流程问题，也许是系统设计的难点所在。目前身份认证、邮件系统和文档系统都提供了相应api,可以说和工作流的结合难度不是很大，系统难度应该在工作流引擎和表单结合上面，怎样很好的解决不同业务流程事务处理点的操作差异上。

在研究了一些业务流程以及一些工作流产品后，也就更加感觉到这一点的重要性，因为不同的业务流程中的侧重点，操作方式，表现形式可能不尽相同，如果对每一种类型的业务流程进行设计，实现定制化，也就失去了用我们的表单统一设计实现零编码的意义，如何找出不同的业务流程的共性，抽象出适合大多数业务流程的工作流管理系统，就是我们目前的难点所在，这一点不容易把握，拿live flow来说，从他的例子来看，可能会感觉他的功能已经比较强大，几乎可以解决大多数业务流程问题，但是针对各种业务流程的特性，在live flow里面根本就一点都体现不出来，拿他的收发文来说，简直做的太简单了，虽然表面上好像也可以实现一个收发文流程，但是这样的发文系统，没有那个客户愿意使用的，本身也就失去了应用的意义。通过一段的学习，感觉工作流管理系统有两个比较重要的地方，一点当然就是对流程的控制上，怎样实现流程的灵活控制，这一点大多数的工作流管理系统已经做的比较好，我们原来设计的工作流引擎可以说在流程控制的支持上已经做的比较好，另外一点就是业务的处理上，也就是事务处理点的业务处理上，怎样抽象出业务流程事务处理的共性，怎样处理业务流程事务处理的特性，可能是大多数工作流管理系统需要面对的问题，我想也是我们所面对的问题所在。记得上次和那个顾问谈到工作流的时候，他提到一个问题“你们的系统是针对那个领域的？”，我想可能他就是针对上面我们提到的这个难点所提出的问题吧。由于我们原来的思路是工作流引擎和第三方开发工具结合，所以只存在上面两个重点问题的前一个，而不会存在业务流程的事务处理点操作的问题，所以我们的工作流引擎也就不会存在针对那个领域的问题。

在研究了部分业务流程后，我们将抽象出四种事务处理点信息表现的载体，分别是表单列表、正文、文件列表、业务报表。由于目前我们的报表服务还没有实现，所以暂时不考虑业务报表。表单列表完成业务流程中信息的采集工作、正文针对需要正文的业务流程而言，可以实现复杂的正文编辑及扩展功能，文件列表完成附件的添加，修改，删除等功能。通过这几种信息表现载体基本可以完成基本的事务处理点的事务操作的要求，基本解决了上面提到的工作流管理系统中存在的第二个问题。

下面将叙述工作流管理系统的运行，请看下图：

 

 

下面分别叙述每一部分的功能，及和其他部分的联系。

身份认证服务主要提供人员、部门、角色的基础信息，实现企业机构组织的管理，并为外部程序提供统一访问的接口；身份认证服务和其他各个部分联系密切，是系统设计运行的基础。

表单设计器，根据业务操作点的需要，完成和用户交互的表单的设计，这里包括数据库表的设计，表单样式的设计及其数据的绑定，最终运行还要通过页面引擎来生成同用户交互的页面。

流程建模工具负责流程的创建及其管理，并通过表单服务完成流程节点与用户交互表单的绑定以及针对流程节点进行表单上元素的权限分配，为了使系统能够支持更多的业务流程，这里我们规定一个流程可以对应多个表单，一个流程节点也同样也可以对应多个表单，通过上面提到的权限的分配，来控制不同的节点针对不同的表单的权限控制。这里表单不单单是同用户交互的界面，应该看成上面提到的信息的载体之一。流程建模工具通过身份认证服务完成流程节点产生的任务的指派。

页面生成引擎将根据引擎控制数据库的信息，得到流程当前所处的节点，并根据当前节点所对应的表单列表的权限，生成相应的表单。

程序运行辅助框架实际上正是为了表现上面提到的几种事务处理点信息表现的载体而设计的，我们考虑到如果只使用单个表单作为一个业务节点的交互，可能设计出来的系统功能非常狭隘，程序运行辅助框架很好的解决了这个问题。我们将在这里面集成表单列表资源，文件资源以及正文编辑的能力，其中表单列表通过表单生成引擎来生成，并根据建模时设计的业务节点的表单列表访问权限来根据当前所处的业务节点生成不同的表单，正文是我们为了满足一些特殊流程而加入的一个功能，他完成表单设计器不能完成的信息收集而设计的，尤其在申请审批流程中这一点就更加重要。文件列表也作为一个通用的业务流程的信息载体，更加有力的保障了一些特殊流程的要求。

程序运行辅助框架和表单生成引擎结合最终生成和用户交互的界面。

工作流引擎负责业务流程的流转控制，通过邮件系统提供的api很好的和邮件系统集成。