流程可配置

要实现流程的“可配置”，即相当于由用户自己“组建”流程，那么，对于程序的开发者，要做的事自然就是一个相反的过程（“拆解”流程）。考虑如何拆解流程能使用户重新组建时省力省心，实际上就是设计一个好用的、可配置的工作流的过程。

清楚了我们要做的事之后，在开始做事之前，我们还需要制定一些做事的原则（“拆解”的原则和方向），毕竟，我们的初衷，不仅仅是能把事做完，把事情做好才是最终目标。那么，什么才是一个好用的可配置的工作流呢？我们认为，好的工作流应包含下面几个特点：组建过程简单、快速，易于维护，用户无需培训、易于掌握等。

制定了上述原则后，我们现在就开始来拆解流程了，首先画一个简单的流程图作为参考。

简单流程图

大致看一下图1中的流程图，先不考虑复杂的内容，我们对一个流程最直观的判断是：流程由环节和路径组成。如果仅将流程拆分成这两个元素，对用户来说是非常好理解的。那么下面，我们就尝试使用这两个元素建立可配置的流程。先粗略地拟一下各元素对应的表单需要包含的域：

1、环节文档：环节名称、处理人员

2、路径文档：路径起点环节名称、路径终点环节名称、流转条件

上面两个文档都是配置文档，要建立一个完整的工作流系统，除配置文档之外，我们还要建立一个包含待审批的业务信息的文档（以下称为主文档），主文档要与配置文档相关联，就需要在主文档中记录一些配置文档相关的信息，这里也先粗略地拟一下这些信息：

3、主文档：当前环节、当前用户

相关基础文档建立起来之后，接下来就开始考虑将各个分散的内容连接起来形成一个完整的工作“流”。假设当前主文档处于申请人环节，那么下一个环节是A领导还是B领导呢？从我们现有的配置文档来看，两个环节文档是通过路径文档连接的，那么我们首先要找到以申请人为起点的所有相关路径，搜索结果为：路径1、路径2、路径3都符合要求。接下来就是判断当前文档符合哪一个路径流转的条件即可筛选出唯一确定的一个路径。然后，从唯一确定的路径文档中可获得下一个环节的名称，通过下一个环节的名称搜索环节文档即可获得下一个环节的处理人员。将上述处理过程放大，就可以实现一个任意庞大的流程。

流程流转过程

看上去上面的方案似乎已经完全实现了一个“可配置”的流程，实际如何呢？下面，我们拿一个复杂一点的流程来分析这种方案的优缺点：

有重复环节和路径的流程图

可以看到，“B领导审核”环节和“会计”环节出现了2次，“B领导审核”到“会计”的路径也出现了两次，假设当前环节为“A领导审核”环节，如果通过上面的处理方式，我们搜索到的符合条件的下一个环节是“B领导环节”环节，然而，“B领导环节”以后有2个可能的路径，如果仍按上述方式处理，我们本来要走的路径5可能会走到路径6而导致流程最终无法流经“总经理”环节。为了避免这种情况，我们可以有很多种选择，下面列出了其中的两种：

第1种：将两个“B领导审核”环节命名为不同名称，如其中一个环节名称改为B领导审核2。

第2种：在环节文档中增加一个位置域，标志其所处位置以区别不同位置出现的同一个环节名称，即使用位置取代环节名称作为环节文档的关键字。

采用第1种方式虽然较“笨”，但是可以不修改我们原来的程序，而且流程的组建过程也是最简单的。但是有些用户可能不会接受这种方式，因为在这样的系统架构下，组建流程的管理员需要绞尽脑汁地考虑“第二名称”怎样命名，而且这个“第二名称”不一定会获得最终用户的认可。为了避免这些麻烦，我们可以采用第二种方式。

下面我们看看环节文档中增加了位置域的效果（图4）。采用“位置”域作为关键字，在主文档、路径文档也相应增加当前位置域即可以唯一确定流程的走向。

增加环节的位置信息

在环节文档中增加位置域的方法解决了环节名称重复的问题，但进一步看，我们仍需要为相同环节名称不同位置的两个环节建立两个环节文档，站在系统管理角度来说，这也是一种很不好的方式，因为调整这种重复环节文档中的任何信息（如：调整环节包含的人员）的时候都需要修改2个或者更多的文档（很可能改了一个忘了一个）。因此，我们有必要将环节名称的其他信息和位置信息再拆分，拆分后各文档包含的域有：

角色文档（职位文档）：角色名称、处理人员

环节文档：角色名称、位置

同时，为了配合这一改动，我们还需要将路径文档、主文档中当前的环节信息拆分成当前角色和位置：

路径文档：路径起点的位置、路径终点的位置

主文档：当前角色名称、当前位置、当前用户

解决了同一流程中重复环节的问题后，我们将流程继续扩展，接下来还将遇到不同流程使用同一环节，不同部门使用同一流程等问题。经过同样的分析过程，我们仍将面临为各种配置文档添加关键字域以区别不同情况或再次拆分成不同配置文档的情况。就像上面提到过的一样，选择添加域或者拆分各有有缺点，添加域可以维持程序的易用性，而拆分成不同文档可以减少系统中的重复配置，提高配置文档的可重用性和可维护性。易用性和可重用性这两个特性在大多数时候是一对矛盾体，如何取舍就全靠我们的系统设计人员把握了。我们这里采用的是以易用性为主，可重用性为辅的策略。图5显示了我们这种策略下的一种数据结构。

可配置的工作流的数据结构

刚才我们都是将流程不断扩大来细化我们的拆分方案，现在，我们将从另一个同样重要方向来继续这一过程，即流程环节的增、删、改。上面我们也曾提到过流程环节的“修改”（修改承办人员），一般情况下修改环节都不是问题，难点的在于增加和删除环节。下面我们尝试在“A领导审核”环节和“B领导审核”之间增加一个“C领导审核”，看看我们的系统是否需要做出修改，见下图：

增加环节

增加环节时，我们需要删除路径4文档（起点位置为2，终点位置为3），增加“C领导审核”环节文档和路径8文档（起点位置为2，终点位置为8）、路径9文档（起点位置为8，终点位置为3）。假如当前环节为“A领导审核”，程序流转时仍将使用主文档中保存的当前位置（位置2）搜索路径文档，此时结果可以从路径4文档变成路径8文档，可见这种设计是可以适应增加环节的。同样，这个设计也可以适应删除环节的情况。

注意，环节增删改时还有一种特殊情况，即删改当前环节。这种情况下不仅仅要修改流程配置文档，主文档中的相关内容也要进行更新，如果没有“外力”，主文档包含的当前处理人（这个还涉及了主文档的读写权限）和当前位置是不会自动发生变化的，因此，需要其他手段配合才能实现一个完美的“可配置”工作流。

到目前为止，一个简单的可配置的工作流就算完成了（跟关系式数据库建模的过程非常相似）。经过这一个过程，才发现其实IBM在Lotus WorkFlow中建立的工作流引擎（数据结构）在技术上已经是一种比较完美的方案了。我们绕来绕去自以为会发现新大陆，到了最后还是回到了前人走过的路上（对比Lotus WorkFlow，主要的不同之处是我们这里没有把人员和角色分拆，原因是不想再配置一次names.nsf中已存在的用户）。不管怎么样，从这个简单的可配置流程设计的过程中，我们还是获益匪浅，也深刻认识到一个再完美的工作流引擎也不可能成为普世真理，因为工作流的易用性和适应能力常常是矛盾的，不同的用户会提出不同的要求。因此，技术人员不必执着于技术不可自拔。