工作流中如何实现加签和动态增加节点

在中国式流程中，往往会有一些特殊的流程，比如说在实例运行的时候进行一些节点的动态添加和删减操作，而这些节点呢，在流程模板中没有进行预定义，完全是在运行的时候动态进行添加和删除。在BPMN2.0标准中，我们首先需要绘制一个流程，然后当前模板下面的实例会根据这个模板的预定义进行解析和执行。

这样的标准有好处也有坏处，好处呢就是方便我们去控制不同版本的流程，这里以费用报销为例进行说明。假设现在定义了第一个版本的流程，该流程有三个节点。当前版本的流程运行一段时间之后，随着需求的不断迭代，可能或多或少的对当前的模板进行节点的删减或者添加操作。假设新版本有5个节点，那这样的话每一个版本都对应到一个具体的模板。因此也必须要求程序去两个版本的模板以及每一个版本流程实例的精细化控制。BPMN2.0标准的核心理念就是：修改模板必须重新发布和启动。

但是在中国式流程中往往不喜欢这么做。我们需要在这个实例运转的时候去增加节点，而不是去修改全局的模板。由于模板是全局的，这样导致用户不能随便的去修改模板，本质原因是所有的实例均需要按照模板的预定义进行执行。实例与模板为1对1关系。如何优雅的在不修改模板的前提下多每一个实例进行动态的添加和删除节点呢？接下来看一下盘古BPM工作流引擎的一些设计。

盘古BPM加签设计

在工作流引擎系统中，加签往往也是一个比较复杂的一个工作量。上文也详细对该问题进行了阐述。

因为每一个实例都有可能去动态增加或者删除节点，而模板是全局的啊，这也意味着我们不能去修改模板，因为如果我们把模板给修改了，那这这也意味着当前模板下面所有正在运行的实例都会受到轻微的影响。极端的情况下呢，可能我们每一个节点呢都有可能去进行添加节点操作，这也衍生了另外一个问题，如何让固话的流程更加的自由化和发散。如果一个实例下面的每一个节点都要去加签，那页意味着用户的喜好完全是自由流。

自由流它本质上是没有模板的概念，或者说每一个实例都是一个不确定的模板。这种思想与BPMN2.0标准的预定义模型完全相悖，甚至说是冲突的。为此呢，盘古BPM工作流引擎在设计的时候已经考虑到了这个场景，

盘古BPM工作流引擎在实现的时候，采用的是固话流程+自由流程。固话流程按照BPM2.0执行，自由流程一个实例对应一个模板，当前的实例只要有添加或者删除模板的操作，系统自动生成一个新的模板，彻底摆脱了模型与实例1多多的问题，进而可以支持1对1，多对1和多对多操作。这样也会诞生数据量大的问题，比如Flowable工作流引擎开源版本支持简单的加签场景，但是就会造成数据量过多的问题。Flowable工作流引擎开源版的加签采用的是一个实例下面的一个节点就是一个模板，并且只要有加签动作，会自动部署新的模板，然后将旧的数据迁移到新的模板中。这样就会导致数据量特别的大，比如你有1个模板，12个节点，10个实例，极端情况下每一个节点都要加签，则最终生成的模板数量是：1*12*10=120。可想而知数据量很快就会成为系统的瓶颈，为此盘古BPM工作流引擎在设计的时候已经发现了该问题，采用了一个折中的方案。同样的场景在盘古BPM工作流引擎中数据量为：1*12*1=12。数据量是Flowable工作流引擎开源版的1/N个。（N有实例的个数和节点的个数决定）。Flowable工作流引擎开源版这样设计可能是为商业版的批处理铺路。

加签带来的问题？

如果说一个实例进行了加签操作，那么当这个用户查询跟踪流程的时候，肯定期望这个流程图也可以这个动态化的显示，也就是说加签的节点要在流程图上体现。那这个又涉及到另外一个问题，加签节点如何显示以及如何重新布局。市面上不管是Activiti/Camunda/Zeebe/Flowable采用的是awt技术生成图片，相对而言不好看，不美观以及严重影响性能，为此盘古BPM工作流引擎特意搞了一套前端渲染技术，在前段直接渲染模型图和自动局部，目前Activiti/Camunda/Zeebe/Flowable开源版均没有这个功能。这样做就可以完全不用依赖后端和不会造成系统瓶颈问题。我们只需要一个标准的BPMN2.0模型就可以图形化方式显示模型，相对来说呢，更加的友好，这也为后续的彻底自由流铺路。