工作流框架(引擎)设计

日期

版本

说明

作者

2011.02.19 

1.00 

初始正式版本

杨纲

2011.02.21 

1.01 

杨纲

2011.02.28 

1.02 

节点元素添加了

state-code

属性；

转

换

元

素

添

加

了

operation 

operation-code 

operation-label

等

属性，删除了

task-summarize

属

性；并修改相关的数据库和类设

计

杨纲

设计目的及背景

1

、

现有的工作流框架有何弊端和风险？

就目前的设计而言，

流程事项的各状态节点和流转路径相对固定，

虽然使用了

状态机的框架，

但是流程的实现依然过度依赖硬编码

（表现为用户界面的数量和内

容以及触发状态变化的操作对固有流程的依赖度过大）

，因此当固有流程变化时，

程序维护量比较大，不直观。然而当我们的系统在广东、东莞、商务部、湖南等各

个独立的平台运行时，用户对固有流程变化的需求将不断出现。

目前系统对各个用户的个性化工作流需求采用无约束的自流转来实现，

即事项

当前的处理人可以批复意见，

但对事项的流程不产生强制性影响，

同时可以自由的

选择下一个处理人，

这就好比我们提供一个数据录入界面，

但不提供任何数据逻辑

校验一样，

必须完全由用户去判断操作的正确性。

这样必然增加了用户无意出错或

有意出错的机会和增加用户的工作量；

作为一个临时的解决方案，

可以让用户按照

实际的工作流程将业务勉强进行下去，但长期如此，必然会被用户垢病。

在审批系统及后续的发证系统中，

工作流的概念将在很多地方出现，

例如项目

预审批、项目审批、项目审查、发证审批等等，我们需要一个简易、方便使用，易

于扩展，

贴近我们的应用类型的工作流框架来简化我们的开发和维护，

提升系统的

用户满意度。