工作流系统的硬伤- 修改有数据的表单限制及解决方式分析
最近客户部署了某著名公司的工作流软件，我也顺便研究了一下，发现了一些问题。
目前的工作流系统，从结构体系看都是相似的，主要包括：
- 工作流引擎
- 图形化的流程设计器
- 表单设计器
如果从企业数据角度来看，我们分析一下各个组件的含义
工作流引擎当然是处理具体的业务数据（或叫流程实例）的节点状态流转，保存的是节点状态数据
表单当然保存了业务数据，由于不同流转步骤需要的数据不同，表单里面也存在着非常多的脚本信息，这些脚本中以字段名的方式标识着数据计算公式。
流程设计器保存的是业务流程流转的规则，由于很多流程跳转是有条件的，因此这里面就产生了大量的脚本，而流程跳转条件又多与表单中的字段有关，因此脚本中也存在着大量的字段名标记。
由于流程设计器和表单设计器是两个独立的系统，一般来说表单是被动的，因此流程的修改对表单不会产生太大影响，或者说可以通过编程方式进行检测和自动调整。 但是表单作为数据的保存地，它发生了变化就有些麻烦了，我们来看看问题及解决思路：
- 如果字段名发生了变化，那么所有保存在流程设计器及表单其他字段中的脚本就都有可能发生错误。解决的办法只能是在脚本完成后再进行“编译”处理，将脚本中调用的所有字段名与表单字段的识别码（通常是ID）来关联，这样字段名称发生了变化不会引起程序变化。
- 如果字段被删除，那麻烦可能就很大，因为如下公式： [出差日补贴]×[出差天数]如果删除了“出差天数”的话公式就变成了 “[出差日补贴]×”是个无效的公式， 解决的方法就只能是禁止删除或禁用这些字段。但是有些字段又是需要禁用/删除的，这样就必须有能力通过编程的方式将这些被调用的字段找到。
回到业务的考虑中来，现有的很多著名工作流产品大都不能实现对已经有数据的表单进行修改，而实际业务中业务及流程的调整又是非常频繁的，因此大都采用使用新的表单版本甚至新的流程版本处理，基于数据分析角度考虑，这又往往制造了很多“信息孤岛”，使大量有用的数据无法进行分析（或者需要专门的编程才可以）。
其实，如果能够解决表单字段变更与删除的自动处理问题，从理论上说修改使用中的表单应该是可行的，而如果能够实现此功能，将会大大提高工作流的适用环境。
