web工作流管理系统开发1-5

之一工作流概念

曾经在2001年做CRM产品的时候，因为CRM产品的客户状态升迁，每个具体用户的升迁规则可能会不一样，技术主管说要集成一个工作流软件工具......，那是我第一次听说工作流。当时很不理解，这工作流软件如何能做到将业务流程定义进去呢？当然，那时候工作流软件工具还不成熟和完善，也或者我们也没有达到那个层次，后来终究还是没有用上工作流。

工作流软件，顾名思义，就是业务信息数据在多个环节模块之间的流转。按照工作流管理联盟的定义，工作流指的是“业务过程的部分或全部在计算机应用环境下的自动化”。在实际应用过程中，为了实现对业务过程的工作流管理，需要对业务流程及其各个步骤之间业务规则的抽象，概括，做成一个统一通用的流程管理软件系统，这种软件系统就是工作流管理系统。

工作流管理系统的主要功能是通过计算机技术的支持去定义、执行和管理工作流，协调工作流执行过程工作之间以及群体成员之间的信息交互。工作流管理系统将业务流程中工作如何组织协调在一起的规则抽象出来，从而分离了具体工作的逻辑和流程组织的逻辑。实现对业务过程的抽象建模、业务过程仿真分析、业务过程优化、业务过程管理与集成。从而最终实现业务过程的流程自动化管理。

开发人员或者流程的应用人员遵从工作流管理系统的规则或约定，设计和实现具体的业务流程。

工作流系统结构图：

天蓝色蓝色：软件构件，完成工作流管理系统不同组成部分功能的实现；

黄色：系统控制数据，工作流管理系统中的一个或多个软件构件使用的数据；

棕色：应用与应用数据，对于工作流管理系统来说，它们不是工作流管理系统的组成部分，而是属于外部系统和数据，它们被工作流系统调用来完成整个和部分工作流管理的功能。

web工作流管理系统主要功能：

业务流程建模;

参与的用户，权限，角色设计；

工作流测试运行；

业务表单模块的建立；

流程发布运行；

流程管理和监控；

流程出错后的修复。

通常开发一个工作流管理系统主要包含如下几个部分：

工作流引擎开发

工作流定义工具

自定义表单模块

流程管理和监控

工作流引擎：主要是实现业务流程的规则抽象，模型的建立，解释，以及为流程实例提供运行环境，并解释执行流程实例。

工作流定义工具：主要是实现工作流的描述文件的定义和建立，通过可视化的方式把复杂的流程定义以图形化的方式显示出来，并加以操作。

自定义模块：主要指自定义表单，实现业务模块的工具。

流程管理和监控：主要指组织机构、角色，流程实例等数据的维护管理和流程执行情况的监控；

之二工作流引擎

工作流引擎，主要是实现业务流程的规则抽象，模型的建立，解释，以及为流程实例提供运行环境，并解释执行流程实例。

工作流引擎必须要包含一个工作流模型的设计，工作流模型就是对业务流程抽象的一个模型，是整个工作流引擎的基础。所以模型设计的好坏决定引擎的功能是否灵活，也决定了工作流管理系统从设计实现到运行实施等诸多环节。

在信息管理自动化的环境下，工作流模型必须采用简单、直观、又具有较强描述能力的模型。我们公司的自定义工作流系统采用了有限状态机的数学模型来实现工作流模型，有限状态机（FSM）又称为有限状态自动机或简称状态机，是表示有限个状态以及这些状态之间的转移和动作等行为的数学模型。

状态转换图：

上图左数第一个图：为初始状态，用粗线圈表示；

SX,S0,S01,S011,S0110 为状态名称

U=0表示处于该状态的输入

连线箭头上的0或1表示导入状态转换时的输入

工作流模型正是利用这种状态和动作，动作的结果导致状态的转移来达到流程的流转。

工作流引擎的每一种状态(state)被描述成为一个步骤(step)和步骤的状态(status)。工作流实例从一种状态(state)升迁到另外一种状态是通过执行动作(action)来达到的，动作的结果(result)导向另外一种状态(state)，这样达到流程的流转。在一个工作流实例的生命周期内通常有一个或者多个活动的状态(state)。这些简单的思想表现在工作流引擎的核心包里面，并且通过一个简单的XML文件来描述业务工作流程。

一个简单的流程描述xml文件是这样的：

上图xml流程的图解状态过程如下：

开始节点-》初始化动作－-》步骤节点－》动作节点－-》结束

工作流引擎的基本元素：

步骤（step）

一个step描述的是工作流所处的位置。可能从一个step流转到另外一个step，或者也可以在同一个step内流转（因为step可以通Status来细分，形成多个state）。一个流程里面可以有多个step。如：总部营运中心总经理审批

状态（status与state）

状态status 是用来描述工作流程中具体step（步骤）状态的字符串。eWorkFlow中预置了三种步骤的状态 Underway（进行中）、Queued（等候处理中）、Finished（完成），用户可以任意扩展自己的状态。而工作流的状态state 则是由 step（步骤）＋status(步骤的状态)组成的。工作流状态state的升迁来达到工作流实例的推进。如：总部营运中心总经理审批完成

流转（transtion）

一个工作流实例状态state到另一个状态state的转移。如：从“总部营运中心总经理审批－等候”到“总部营运中心总经理审批－完成”

动作（action）

action 触发了发生在 step 内或 step 间的流转，或者说是基于 state 的流转。一个 step 里面可以有多个action。action 和step 之间的关系是，step 说明“在哪里”，action 说明“去哪里”。一个 action 典型地由两部分组成：可以执行此action（动作）的condition（条件），以及执行此动作后的 result （结果）。按：感觉是从属于流转（transtion）。

条件（condition）

类似于逻辑判断，可包含“AND”和“OR”逻辑。比如一个请假流程中的“本部门审批阶段”，该阶段利用“AND”逻辑，判断流程状态是否为等候处理中，以及审批者是否为本部门主管。

结果（result）

Result 代表执行action（动作）后的结果，指向新的 step 及其 step status，也可能进入 split 或者 join。result 分为两种， contidional-result （有条件结果），只有条件为真时才使用该结果，和 unconditional-result（无条件结果），当条件不满足或没有条件时使用该结果。

任务（task）

任务是当工作流状态发生转移的时候，产生的任务。任务可以指定为一个具体的角色，人，或者群组。任务具体分为待办，已办，竞争办理，代理待办等多种功能。

分支/合并（split/join）

流程的分支和合并。分支是指流程下一步可以同时分发给多个步骤，分支split 提供多个unconditional-result（无条件结果）；join 则判断多个current step 的状态提供一个 result（结果）。

子流程（subflow）

子流程，动作的结果可以指向一个子流程，子流程是一个独立的流程，可以单独启动也可以嵌套在另外的流程中启动，和主流程有同步或异步衔接的属性。

自由流（free transtion)

自由流是指当一个步骤的动作执行完成后，需要跳转到任务（任意？）的步骤。任意步骤，是指整个流程范围内的任意步骤，包含执行过的或未执行过的。

回退流（return transtion）

回退指当流程实例运行到某个步骤的时候，由于某些特殊原因需要回退到已经执行过的某个步骤上。回退是一种特殊的过程，只有在运行过程中才会明确知道要回退到那个步骤，回退往往需要执行业务补偿。回退和自由流不一样，回退会摸掉当前步骤到回退步骤之间的运行轨迹，就像初次运行到回退的步骤一样，同时需要辅助业务补偿来到达业务数据的回退。

工作流引擎核心包内，对这些基本元素做解释，并提供流程实例启动，动作执行，任务完成等等API，达到对业务流程的抽象。业务系统集成工作流后，做好业务流程建模，然后利用自定义表单做好相应业务数据的处理，将表单挂接到流程上。启动工作流系统，就可以实现业务系统了。

之三可视化流程设计器

在工作流管理系统中，引擎的所有的活动，驱动，和流转，都是以流程定义为基础而展开的。流程定义文件是流程能运行的先决条件，同时流程定义文件又是工作流引擎的设计基础，引擎必须要能生成，解释和获取到任意流程定义节点的信息。业务流程建模就是将一个具体的业务流程系统用流程定义文件来描述。而生成这个流程定义文件的可视化编辑工具就是流程设计器。

一般来说，只要是足够熟悉流程定义的各个步骤和节点的意义，流程描述文件可以用文本编辑器手动的输入来生成。但是这样做对用户的要求太高了。通常都会采用一个可视化的流程定义工具来实现。

工作流定义工具实现方式：

用java的图形界面包来实现：

生成一个java application，需要在客户端装jre，是c/s的应用，每个使用的客户端必须安装jre，安装这个可视化的编辑工具，这种方式根本不适合web管理系统的发布，每个客户端都需要安装，不理想；

用applet来实现：

这种方案虽然解决了每个使用的客户端安装程序的过程，但还是需要大量下载安装包，下载jre，也不是理想的实现方式。

用html+js+ajax来实现：

无须客户端安装，无须下载jre，只是第一次运行需要下载所有js的脚本，是理想的实现方式。

下面主要谈html+js+ajax的实现方式：

工作流流程定义，必须要图形化的实现流程的建模，使得流程建模变得简单和可操作，用户通过拖、拉、点、拽来实现流程的建模。

通过html和dhtml来实现界面的展示。

通过javascript和xml，dom分析实现动态的修改和编辑节点属性。

通过ajax来实现和后台的交互。

通过vml来实现图形化的操作，画线，画方框，拖动等等。

运用js, dhtml, xml, dom, vml 这些技术足可以将界面的编辑功能做得灵活简便，然后有ajax随时可以取得和后台交互，同时是web网页发布的，可以和应用程序一起集成发布，通过权限控制可以开放给最终端的用户使用。

一般来说流程定义文件的保存可以是保存成文件的形式，也可以保存到数据库的表中，因为采用ajax的方式来设计保存，这两种方式很容易都可以实现。同时通过文件方式的保存和数据库方式的保存，很容易做到流程的上传和下载，真是一举两得。

下面模拟一个业务流程建模工具操作界面：

之四自定义表单

在开发工作流管理系统时，很多人只重视流程引擎，流程模型的建立，而忽略了自定义表单工具。自定义表单工具是实现独立业务模块的可视化编辑工具，业务模块可以通过这种工具编辑生成。如果单纯从流程实现来说，确实自定义表单不是重点，流程实现了，可以挂接上表单就可以了。至于表单业务模块，可以

是表单工具生成的，也可以是代码编写的表单，总之能用代码来实现的是最灵活的。

但实际上流程的每一个步骤的业务数据都需要靠表单来展现，用表单来实现业务数据的存储，如果总是需要靠代码来实现的话，没有一个功能强劲的自定义表单工具来支撑的话，再好的工作流系统也不过是瘸腿的马，跑不长远，更别说可视化的完成业务流程了。

做过mis系统开发的人都知道，表单这块涉及到表现层，操作界面的人机交互，后台又涉及到业务逻辑，业务数据的存储，是开发mis系统的重点，难点。而工作流引擎都是将这层业务模块的实现剥离，让用户自己去实现，工作流引擎只实现一个抽象的流程流转。如果要做到流程的自定义，业务模块的自定义，一定需要有一个强大的自定义表单模块来支持，才能使得流程的定义变得可视化，可操作，可提供给最终端的用户使用。

自定义表单，因为涉及到界面的展示，人机操作交互，页面的构件一定要丰富。常用的构件：label,textbox,combobox,spin ， shape ， checkboxlist ，radiolist ， dropdownlist ， webgrid ， upload等等；

复杂的构件：表格，树控件，统计图标展现控件，多列下拉列表控件等等。

表格的展现和输入应该是最丰富的，功能应该做到很方便和强大，比如做到和数据集的绑定，快速方便的展现数据，单元格的输入支持多种输入方式，下拉combox，多列的下拉输入，弹出日期选择，弹出窗口选择，回选数据等等。单元格，行的事件的支持，双击，单据，离开等等。

多样齐全的数据验证功能：比如判断空，是否数字，取值范围判断，是否日期，是否电话号码，省份证验证，汉字验证，等等多样的验证。

自定义表单，有可视化表单设计界面，直接采用拖、拉、点、拽的方式来设计表单。常见的数据获取保存等等，直接用页面构件，不需要用户写代码就能完成（有时候简单的sql语句还是需要写）。

采用b/s的方式来设计，易于做web发布，提供给最终端的用户使用。

采用ajax的方式来实现随时随地的和后台交互，做到局部刷新，粒状更新，同步、异步调用等，使得界面交互性强，易于操作。

数据层和样式分离，便于和其它系统集成；

支持多种后台数据库；

编辑层和最终生成的表单分离，易于发布和集成。

下面是eform自定义表单，结合工作流管理系统的一个示例：

说明：

实现员工报销的一个流程

主要业务要求：

员工填写报销单，单据为主子表的设计，部门经理和总经理会签，任何一位经理拒签后，都打回重新填写，打回后员工也可作废报销单；

重新填写再次申报，直到经理都审核通过，财务通知领取报销金额，员工领取后，流程实例结束。

业务流程图：

eform自定义表单模块设计：费用报销单

启动流程：

流程运行轨迹图：流程刚完成初始化，运行到填写报销单步骤

提交费用报销申请：如下图，点击“保存执行”，即提交，流程会流转到审核阶段。

经理审核：

两步审核都通过后，财务发出通知

员工领取报销费用。

之五开源osworkflow之用户系统改造

前言：

osworkflow是个开源的工作流引擎，采用的是有限状态机的模型。内置有osuser这个用户系统，来处理用户权限相关的部分。但是功能很弱，只有用户表，用户组表，即简单的将用户划分给用户组。在定义流程的时候，可以将权限处理给一个具体的用户，也可以给一个用户组。

缺点：

功能太过简单，不利于扩展，也不利于和用户系统集成，还没有开源的源代码。

改造方案：

将osuser去掉，重新编写一套用户系统，此用户系统只在工作流系统中使用，因此数据权限等从简。

保留使用osuser.xml文件的配置，修改成fcuser.xml，此配置文件采用xml格式，配置具体执行和数据库交互的实现类，便于扩展各种数据库的个性化函数,sql，关键字的不同写法。

采用映射表的方式，和实际用户系统的表关联，因为用户系统要集成工作流，一般都有自己的用户组织机构管理系统。

工作流系统必须要和用户系统的用户权限系统无缝集成，所以没有必要再做一套用户系统，直接将用户系统的数据映射过来，达到集成的目的。如果不采用表数据的映射，也可以编写实现类，实现UserProvider接口，将用户系统已经有的方法关联过来实现。

用户映射表示意图：

表结构:

用户表，用户角色表，用户群组表

这几个表为演示系统使用，真正和用户系统集成的时候，采用映射表映射到用户系统的表。或者用户有自己编写好的用户权限等系统，也可以通过实现UserProvider接口的方式，将用户系统和工作流的用户系统集成到一起。

fcuser映射表：

一个简单的fcuser.xml映射表图例

https://www.360docs.net/doc/651692096.html,er.provider.jdbc.JDBCUserProvider 为UserProvider的指定实现类。

用户系统的UML图：

主要类功能描述：

UserManager为对外提供的用户系统的实现类，流程引擎实现类关联这个类，来实现用户系统的一切功能；

UserConfig为单例模式，主要读取fcuser.xml文件的内容UserConfiguration获取映射表配置信息

UserProvider接口，提供所有的用户系统功能，实现类可以根据数据库的不同选择各自的个性化实现类，通用的为JDBCUserProvider。

用户不使用表结构映射时，可以编写自己的实现类，实现UserProvider 接口来实现用户权限系统。

UserException，所有用户系统的抛出的异常。

User,UserImpl 用户接口，用户接口实现类

Role,RoleImpl 角色接口，角色接口实现类

Group,GroupImpl 用户群组，用户群组的实现类

通过改写这个用户系统集成到工作流引擎中，更利于和用户系统的结合。同时别忘记改写osworklfow的引擎包util中的各种和用户权限相关的类，调用userManage中的功能来做用户权限判断。