对配置化工作流的一些思考

最近，项目里用到了工作流技术，由于需求变更，原来1个审核环节要改为3个审核环节。到底是通过硬编码的方式解决？还是让工作流变成可配置化？

由此，展开了思考。

一、高可配置化的工作流

要做成高可配置化的工作流，那么我们的开发任务如下所示：

一、前端：表单引擎实现表单拖拉可配置(简单输入表单可以，但对前端交互和展示复杂的界面不太可行) (钉钉表单比较简单，但业务系统的表单比较复杂)
二、后端：数据存储方面，不是为每个对象设置单独的表，而是把表单录入的数据全部保存作为流程变量，保存到工作流的表中(act_hi_varinst)。工作流中保存流程变量的表，采用竖表的设计模式(竖表的特定是保存对象的字段灵活可变，但是会产生大量的数据记录，而且查询的时候需要转变成横排，查询性能比较差，特别是在需要查询出列表页的情况下查询性能会更差).
1、竖表样例（数据库的横表与竖表）
2、工作流流程变量表结构的展示。
结论：这种设计模式对于OA这种以审批和待办为核心的系统比较合适，但是对处理复杂的业务为主、审批流程和待办处理为辅的系统是不合适的(为了迁就流程可配置化，抛弃对业务系统更友好的底层核心数据库设计，以后还很可能要面临性能问题，不值得)。

二、部分可配置化的工作流

要做成部分可配置化的工作流，我们的开发任务如下所示：
1）复杂环节：像编辑账单、创建结算单，这样的流程环节，有复杂的界面和数据包保存到业务模型的数据结构中，所以流程中有新增这样的环节，肯定要改代码，而且要改不少。所以要减少后期的代码改动，需求方需要尽量把流程分析清楚尽量固化下来。不支持配置。
2）简单环节：像有些简单的审批，本质上是只是修改单据状态，理论上前端可复用这些相同或相似的界面，后端接口就是提供一个update的接口可以通用，业务流程层面也可以提供通用的方法实现。需注意的是：要想做到增加简单审批环节，后端业务层代码不用修改，就必须把单据状态变更管理交给工作流层面的代码去做，这样虽然可以实现这个目的，但是会造成工作流跟业务逻辑的紧耦合，可能带来一些潜在的问题，要慎重。

三、有技巧的硬编码（角色控制工作流的审批权限）

先上一张图

我来解释一下这张图，一张单的状态分3种（工作流状态、数据库状态、界面显示的状态）。这3种状态是互相独立的。回顾一下变更后的需求：原来1个审核环节要改为3个审核环节。我们可以如下处理：

1）数据库的状态不变。审批中依然是1。

2）界面显示的状态要变化。原先是“审批中”，现在改为“审批中(2审)”。审批中共有3个环节，具体进行到哪个环节，前端可以调用工作流的接口查询一下。

3）工作流的状态要变化。工作流由原先的1个环节变更为3个环节。

4）通过系统角色配置功能，将工作流的审核功能配置给相应角色。

如此，即可通过硬编码解决问题。虽然是硬编码，但是以后再需要新增审核环节的时候，只需要改工作流部分，前端稍微调整一下，就足以应对了。

小结

上面就是我们对配置化工作流的一些思考。这些方案，没有优劣，只是适用的场景不同。请大家根据实际情况做决定。