工作流-审批中心设计整理

项目背景

近期新接手一个老系统的技改，改系统原是各个渠道（小程序、app、网页端）的统一后台，所有渠道通过该系统调用下游的理财、保险、贷款等业务系统。

问题

对现有的接口统一分析之后，发现技术上主要改造点在审批流程从原状态机模式改到工作流引擎（用flowable）上。其中针对审批流，中台团队设计了流程管理服务，见下图方式一。
另外审批流程是该系统后续的核心需求，于是我重新做了调研分析，对前期讨论的四种方案做了对比如下：

1. 区分审批任务和系统自动任务，将审批任务编排在流程管理中，由上游系统再串联自动任务

   

   * 完整的可视化业务流程被编排两个服务里
   

2. 服务内嵌flowable工作流引擎，分领域独立部署

   

   * 没有统一的数据源查看某用户所有代办事项，需组合查询
   * 开发简单
   

3. 服务内嵌flowable工作流引擎，不分服务部署

   

   * 未分微服务，不同场景可能的个性化处理导致复杂度不可控
   * 开发简单
   

4. 使用flowable提供的flowable-rest服务，独立部署flowable工作流引擎，通过rest api接口调用flowable的相关服务

   

   * 较少团队选择rest api方式，项目初期有可能有一些技术难点需要攻克
   * 有统一的业务流程视图，统一审批管理
   

最终选择

不同的实施方案都有自己的适应场景。经过调研及同业交流，基于以下原因我们选择了方案一实施。

1. 审批通过后业务场景多
2. 希望审批系统专人维护形成较稳定的服务

这样也引入了一些额外的复杂度。对于大部分场景个人建议内嵌的方式，会更简单

计划

1. 团队内部缺少flowable的专业人员，需先做最小可行性验证，看最终在业务层的产品还有多少
2. 前期讨论时，部分同事对服务编排和工作流引擎的概念不清晰，提到用服务编排框架编排flowable工作流引擎的接口。后续会整理服务编排和工作流引擎的相关资料