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