统一流程平台对Flowable的改造目录清单V1.0

自2020年6月启，我们对flowable6.5的改造将近两年，在我们改造前，已有兄弟部门改造了近1年，所以，整体来看，基于flowable的统一流程平台已是第3年。这三年预山开路，逢水搭桥慢慢形成了了符合中国国情与企业内部流程运转需求的平台。

以下是我们对统一流程平台的需求与改造内容：

1.业务流转与强业务意义关联：

flowable本身只关注业务流转，对于流转的意义默认为同意方案，但很多时候不完全满足。为解决业务流转与业务意义的关联，提供了审批结论流程走向映射配置。

流程走向有：继续/返回修改/终审同意/终止 四种类型。

审批结论可以根据具体的业务场景进行扩展，默认有：同意/驳回/保留意见等。

流程走向与审批结论进行映射后，业务操作端将做出结论后系统自动完成事项流转，保证了各审批环节语义的标准意愿性。

2.执行者概念的引入

bpm作为商务过程管理，不同的环节需要不同的人员参与，怎么获取到合适的执行人呢？在审批节点中提供了执行者概念，让不同的环节可以指定可参与当前环节的执行者集合【员工/岗位/部门/组织/人员组/岗位群/部门群】等内容。形成一级备选人员，在经过针对业务规划形成的执行者参照体系【业务字段参照/节点参照】等自动形成差集，最终让流程平台命中合适的人员。这将大大提升只到人员的配置方案。

3.返回修改策略引入

当业务人员执行驳回操作时，需要驳回到哪个位置呢？一般会由业务经办人进行修改数据后提交，所以默认驳回到业务发起人。

但很多时候需要驳回到特定的节点，这时返回修改的位置应该指定一个节点。

在更特殊的情况下，业务规划时无法确认需要谁进行修正，这时会配置为驳回到任意节点，由业务人员自行选择。

引入返回修改策略后，整个体系都面向了实际业务需求，项目交付组完全有自主决定权。

4返回修改后提交策略引入

当我们把事项驳回后，接收人修正后提交给谁呢？很多时候时谁驳回提交给谁，但有些业务，任何改动都需要执行后续审批，这时需要执行驳回的节点提供候选策略，在驳回修正提交时确认后续执行策略。

返回修改提交策略原则上提供两种：原有节点/继续提交。

5.独立系统改造

统一流程平台不在于业务系统直接关联而是形成独立的业务体系，以接口的方式与业务系统进行交互。

怎么独立呢？又怎么建立关联呢？

统一流程平台建立了【业务系统---->业务功能----->业务数据1维表】 三级感念，使统一流程平台有一个通用的业务模型，用于适配所有的备选审批业务。

最终把业务数据与flowable的执行流变量进行映射，完成flowable运行环境数据需求。

这样使统一流程平台有了生命力.

6.具有强行为意义的执行探针引入

flowable本身采用了大数据库事务来保证执行环节的一致性，保障了从一个节点能正常流转到下一节点。但实际业务执行过程中，较高的领导层并不会关注后续事项谁处理，这时要求系统完成一下几个事项：

1），如果后续节点系统能识别，自动流转过去。

2)，如果后续节点系统无法自动识别，需要根据节点的属性控制来确认是否有当前审批人确认下一环节，还是当前审批完成，然后等待发起人来确认下一环节。

7.基于BPMN-js完成了设计器改造

flowable完全支持bpmn规范，在业务实际落地中，需要根据业务需要提供特定的业务属性来控制行为，如【是否需要提交下一步】等属性。

我们基于bpmn-js提供的基础bpmn图元与属性的基础上，不断扩展形成了企业级流程模型扩展标准。

8.统一流程平台的核心在于运营

怎么保障业务快速变化能及时在流程平台中体系，在业务运营过程中，如果运行中出现了异常：技术异常/业务异常等，运维管理工具提供了全业务流程运营，基于流程业务运行全数据，工作流运营平台能进行全方位修正，并提供了运维行为日志用于后续审查。

9.引入行为状态机

基于flowable的指令集，为识别不同身份人员对业务单据的瞬时行为能力，引入了工作流状态机与行为能力指令对象，UI集成点需要根据行为能力指令对象显示人机交互能力，如执行审批，移交，撤回重选流程等。

10.业务扩展消息化改造

统一流程平台基于分布式集成需要，结合rabbitmq进行了消息队列开放业务层级/事项层级的扩展可能，让外围系统基于统一流程平台消息调度成为可能。