Flowable工作流引擎技术方案

        应对越来越多的工作流使用场景，以及越来越灵活的业务情形，我们亟需对工作流引擎进行一次重构优化。目前市场上主流的工作流引擎，一种是我们熟知的activiti，另外一种就是flowable。众所周知，flowable才是原activiti核心团队这几年的迭代产出物，针对引擎核心代码做了大量优化升级，反观activiti则是将中心放在了云化上，所以，我们本次主要讨论flowable的集成使用。

        2019年初，我们开发了综治平台，该平台时间紧，任务重，为了快速交付上线，我们使用了第三方半开源的项目agileBPM，该项目功能已经很强大了，支持的场景也非常多，当时也顺利完成了交付。但是随着时间的推移，问题也在一点一点的显现。技术老旧，代码繁重，可维护性差，部署复杂冗余，项目集成重复工作多，表单模块实用性差，可定制程度低，各种BUG。这些问题在后续的工作中也着实带来了不小的挑战，虽然在2020年下半年我集中对agilebpm进行了一次架构升级，结合zookeeper做了多应用支持和脚本的发布订阅模式，但是由于项目原因中断，转而去忙公司的项目，也就不了了之。

        如今看来，再多基于第三方固化的东西进行二次开发，特别是技术陈旧且场景固定的项目，不是锦上添花，而是画蛇添足，强行赋予其原本不存在的价值，结果只能适得其反。换言之，我们需要真正结合自己的场景，真正的循序渐进，打造一个听话的，优雅的，轻量级，可持续扩展的工作流”引擎“，而非最开始就做一个平台。随着场景丰富，应用间通用性完善，我们逐步抽取为一个公共能力平台，才是最终可持续发展的重点。

        综上所述，我们早期需要做的是一个多场景可复用的轻量级引擎，以及引擎配套的SDK。

核心思路

工作流一定从引擎开始，它一定是一个渐进式的、根据场景逐步积累的工作。基本思路非常清晰，根据flowable核心架构，我认为最合适的集成方案是：

1. 独立部署引擎，基于SDK REST API进行交互

flowable项目原生支持多租户、几乎所有的Java API都提供了REST API，我们可以仅实现其适配器，我们的业务系统可以直接通过REST API进行集成，这样即使是早期，也可以共用引擎，无需重复部署

2. 同时拥有独立的UI界面和灵活的页面组件

项目早期，我们甚至可以不做任何的UI界面，通过现有的流程设计器，然后仅通过业务逻辑 REST API即可完成所有功能，实现业务流转。项目中期，我们需要前端同事的参与，开发一套工作流引擎管理页面，负责管理租户、流程定义、流程实例、实例任务以及系统状态。同时，我们的模型设计器、流程设计器也可以封装为一个独立组件，通过NPM包管理灵活嵌入各个业务系统中，集成流程设计功能。后续我们会慢慢加入表单设计器、决策设计器、案例设计器等以支持更加丰富的场景。

3. 灵活解耦，可插拔

本次工作流引擎的建设目标，就是要充分解耦，将该功能真正做到既轻量级、又无比强大，打造成一款强大好用、代码优雅、可持续更新的精品组件。关于解耦的部分，我们可以基于许多中间件进行实现，如基于消息队列完成异步事件的回调，或者基于Zookeeper完成事件的回调，甚至可以用Redis存储回调标识来实现。只要避免相关代码直接耦合交互，这些都是完全没有问题的。

二、怎么集成，如何使用

Flowable官方团队在两周前发布了flowable 6.8.0，该版本着重加强了原生对脚本的支持，增强了事件监听器，将SpringBoot也更新到了我们的基线版本2.7.6，可谓天时地利人和。

集成的主要工作有以下四点：

1. Flowable核心API适配。下图是flowable的核心api。我们需要将这些api在SDK进行封装适配，内部使用flowable自带的REST API进行代理实现，让使用SDK的业务系统调用起来跟直接使用flowable原生api一样。这部分工作还包含和引擎约定鉴权方式，flowable

1. 多应用（租户）支持。flowable天生支持多租户，且支持表内字段隔离和Schema级别隔离。通过封装少量配置即可快速支持库表分离。

2. 用户权限适配。flowable有一套自己的用户体系，但是从v6开始，idm模块便单独剥离出去，IdentityService也充分解耦，流程引擎不再强关联IDM模块。对于我们来说，不需要关注flowable的用户，只需要在流程设计、流程发起时传入用户id即可。我们在实现相关页面时，仅需要调用自己的用户体系接口即可。对于用户权限的控制，由于核心Service入口都在SDK，交由业务系统自己控制，SDK提供默认实现。

3. 自定义业务回调。在充分解耦的系统中，单向通信是基本原则，但是作为一个成熟的引擎，拥有定制化的能力也是必需的。在许多业务场景下涉及到业务回调，同时还有需要的事件监听需要我们实现。这部分工作将分为两个阶段：

早期：抽取WorkflowScript接口。在引擎端基于数据库实现简单的脚本管理器（租户级别），存取脚本标识符，SDK提供REST代理，在项目启动时注册项目中实现的WorkflowScript，流程引擎调用时使用RMI反向调用。该方案不需要中间件支持。

后期：基于Zookeeper管理脚本节点，引擎端监听并实时更新脚本映射，用户任务触发脚本调用回调到业务系统。该方案需要使用ZK作为注册中心，增加了部署难度，调试难度，建议等基本功能稳定了再进行开发。

SDK提供的需要实现的接口：

1. WorkflowIdentityProvider。必须实现。作为标准的用户访问api，为了保证代码结构稳定，流程设计器调用接口稳定，需要业务系统自行实现相关逻辑，包括用户列表，用户详情，用户权限列表，用户权限过滤，部门列表，部门权限等。

2. WorkflowScript。可选实现。注册到引擎的脚本，可以在流程设计器中的脚本编辑器使用，可回调到业务系统执行相关逻辑。

3. WorkflowListener。可选实现。可以动态监听所有流程实例和任务流转的每个状态，早期不实现，需要结合zookeeper实现。

集成后业务系统如何使用呢？

1. 引入SDK，并添加workflow.yml配置文件，配置引擎地址，应用标识等基本信息。

2. 用户权限控制模块实现。需要结合自身的用户体系来实现该WorkflowIdentityProvider

3. 引入流程设计器和流程图渲染器，在需要的页面嵌入流程设计器，在查看流程进度时展示流程图进行状况。

4. 根据实际业务调用流程发起接口，在涉及到流转的页面调用流程流转接口。

三、实现模式一览

 

这篇好文章是转载于：学新通技术网