工作流框架的设计要点

       最近几年的工作一直都跟工作流有关，不知不觉之中也积累了一些经验，收获了一些教训。现在拿出来跟大家分享一下。

工作流框架的设计在满足用户需求的前提下要尽可能的简洁、低耦合，流程图的设计可以采用图形拖拽控件的方式，这样用户及维护人员上手最容易。

所以要满足这一点需要单独开发一个流程图设计工具（独立于框架本身），然后把设计好的流程文件（一般是xml）通过上传部署的方式正式启用起来。 

      独立设计工具的好处主要是下面几个方面：

    1、减轻了框架本身的体量，降低了复杂度。框架只需要关注如何支持得到的流程文件xml 就行了。至于它是怎么来的，完全不用关心。

    2、独立设计工具可以作为一个独立的产品单独维护和销售，也更有经济性。

    3、流程被保存成一个xml文件，可以任意导入导出，方便备份、部署、带走和修改。跟应用系统彻底解耦。

    4、流程配置文件集合在一个xml配置文件中比拆分成多个xml要更合适。首先，流程的元素复用的可能性很低，没必要拆分成任务、表单、步骤。。。一大堆出来。其次，一大堆配置文件无疑大大加重了配置和管理的难度，同时数据库的相关表结构跟记录也更为复杂。而把流程相关的一切统统集中在一个配置文件中则完全没有这些问题（数据库甚至都不需要建立相关的配置表）。

     通过版本号来管理流程的版本，每部署一个同名的流程，则自动将新的版本的版本号加1。旧版本仍然保留并处在可用状态，只是发起新流程的时候默认发起版本最高的那个。如果想走旧的，也是可以的（人工选择一下即可）。这样可以有效避免版本丢失导致的历史数据问题。    

      工作流在实际运行个几年之后，肯定会产生大量的数据，这些巨量的数据会严重影响框架的性能。所以工作流框架的性能问题始终是个不可回避的难题。

为了解决性能问题，我们必须在设计的时候就应该注意以下几点。

      1、设计流程框架的时候，把正在跑的流程跟已经跑完的流程区分开（数据库表级别的区分）。就是说分为两类表，一类是运行中的表，一类是历史表，流程一旦跑完，所有数据就被挪到历史表中，以保证运作中的表数据量始终很少，这样数据库的访问速度就大大提高了。这样可以有效保证运行中流程的性能。而访问历史流程的概率很低，所以对用户的体验影响不大

     2、就是统一所有对流程相关的数据查询，也就是说不是谁都可以写sql去流程相关的表里查数据了，而是提供接口，让其他程序员调用接口。而接口的实现则由专门的人来负责，这样就可以根据接口实现的模式针对性的建表索引，也可以加快数据库访问速度。

    3、就是把流程的配置简化，很多流程上面的操作通过设置监听器的方式分离出去，由其他普通类的方法函数去执行。这样流程本身的流畅度就不会受这些操作的影响。

   4、把流程相关的数据分成多个表，比如流程定义表、流程实例表、任务表、任务表单表、任务执行对象表等等，尽可能的把数据拆开。这样可以有效降低数据量，也可以更有效的建立索引。

   5、流程上所有的任务操作在数据库中的反应都是填加记录，尽量避免修改记录（修改数据库记录开销太大）。对任务的重做，也只是再添加一次记录，而不是把之前的历史记录修改掉。

  6、将流程跟报表严格剥离开，之前的系统要求在流程任务步骤上展示一些特定格式的报表。这无疑加重了流程框架的复杂度，降低了其性能。其实这些报表完全可以由报表系统独立承担，只是其数据来源是从流程表单中获取而已。工作流只负责工作流，而不负责其他无关的工作。报表功能从工作流上剥离开，也使其自身的报表版本管理变的更容易了。

 

7、流程图只是一张image 图形文件，只负责向用户展示目前的流程走向而已，不再负责在其上进行交互和操作。之前的系统对流程图的要求很高，需要在上面进行复杂的交互和操作，这导致流程图的绘制非常复杂，性能大受影响，流程的配置也变的极为复杂。这都对将来的维护造成极大的困难。所以将交互的任务从流程图上剥离开变得非常重要。流程的交互只能通过任务链接的方式。

   在代码层面上按照MVC 的模式开发设计。工作流的基础功能汇聚到几个静态类中实现，大部分业务逻辑的实现则通过监听器来实现即可。程序员只需要把精力集中在如何实现监听器就行了，对工作流框架的侵入性几乎为零。  彻底的将业务与框架分离开，这样就基本上可以满足需求了。