flowable培训

概念分析

1.并行网关与排他网关

并行网关难以处理中国式流程回退的情况（程序难以回退不同子分支的执行情况）

2.父子流程调用

子流程退回是否要退回到父流程？如何处理？

3.数据表分析

关注流程处理部分：

用户角色权限体系引用自身的业务表：考虑实际数据库设计

流程不对用户做校验，只是记录标记，后续实现根据自身的业务逻辑实现（作匹配）

4.数据表自动更新（项目数据库版本迭代）

Dependency Analyzer?

ProcessEgngineAutoConfiguration: 初始化建表（匹配是否存在，存在则更新）

Springboot的AutoConfig？？？

5.网关说明

网关是判断一个事情是否符合这个某个要求？符合某个要求则跳转分支。

与‘同意’、‘驳回’的概念不同：此处指的是流程节点的跳转。区分实现方式

6.反射？

框架

7.驳回

上一节点；如果是跳转不同的节点？

8.遍历历史数据

随着时间迭代执行效率低下，考虑从原生的流程图去追踪

9.子流程嵌套

通过服务节点触发子流程的运行（JavaDelegate实现），可自动触发或者是通过网关进行限定（结合管理员任务包配置）

10.实际应用场景项目说明

docker？

多模块项目搭建：

父工程统一maven版本管理

用户角色权限体系：springboot_security、shiro

​ 区分系统自定义接口和公有API接口，shiro实现需要开发指定接口的过滤或者携带token进行验证

11.流程关联任务表单

建立关联配置：绑定流程实例和关联的业务数据的关系

配置项实现，数据表设计

实体类转化：自定义domain实现

12.外呼项目分析

管理员更新（指定）分配规则：是否允许？实现上？

​ flowable未必能实现

外呼呼出流程结束后启动子流程是否会对子流程造成影响？

​ 考虑通过关联表关联，拆分不同的业务流程：Spring Statemachine多实例:状态转化？（考虑系统维护），或者通过自定义数据表进行关联维护

任务启动：

​ 坐席人员匹配相应坐席进行登记 （考虑数据对接的问题，有可能出现外部系统的数据和外呼系统数据不匹配的情况，无法在过程中进行校验），可能出现登记他人的信息的情况，系统无法限定（包括指定分配人员，两边系统需要管理员进行匹配）

创建任务包：任务包配置（流程启动前进行配置，配置完成确认后再处理）

区分业务流程和逻辑流程的概念，技术选型。

区分流程和功能的概念？

Spring工具类

SpringTemplate

缓存（提高后台响应效率）

本地缓存：CoffineConfig 项目配置

hutool：接口生成

Swagger（接口文档生成）

JWT ：生成token 对外提供接口的时候使用

ApplicationRunner:@Order启动顺序

程序启动的时候触发操作，初始化

应用场景：处理内存缓存数据（针对常量型的数据，不怎么变动的数据），程序一次启动便初始化

考虑内存缓存同步问题，如果是针对变量性数据则考虑使用CoffineConfig实现(失效策略），springboot caffeine

ApplicationEventPublisher:可简单实现消息推送

消息中间件应用场景：例如一个人登录，其他人想了解这个人的登录状态，则可以通过从中间件中获取数据来源

不考虑第三方中间件的使用，（从设计模式上是监听器的实现），数据存储到内容中（与运行程序相关联，程序重启缓存失效），后续考虑持久化存储到其他数据库

代码生成

import freemarker.template.Configuration;

ftl定义sql模板，随后使用Template processTemplate = configuration.getTemplate("ds_task_flow.ftl");动态生成数据

FreeMarkerTemplateUtils

Flowable

CustomGroupManager

FlowableIdmConfig:

FlowableUtils（自定义流程工具类）

项目应用

flowable:

1.后台管理系统进一步完善：流程管理、监控，不同子系统嵌入

通过设定用户访问权限限制用户可发起的流程

2.任务节点自定义动态assignee(单个用户，分组概念)：

目前实现前端页面动态指定下一处理人，如果是动态分组如何处理（预设处理，或者是每个任务节点进行动态指定）

3.流程变量存储的管理与业务数据的管理

针对外置表单数据的存储关联，假设流程关联数据不小心被清理了，如何有效的额外维护自己的一套数据存储体系

流程数据的归档处理：针对不同的流程可能衍生出许多变量参数或者记录，后续如何有效进行管理和维护

4.通用实体类、接口方法封装

自定义实体类对flowable的实体进行转化

5.动态节点的生成和指定（业务侧希望能够自定义流程图按照既定的规则进行处理），前后端页面如何进行交互，是否需要提供设计器

初步整理的一些学习意向和疑惑点

【1】flowable常见的业务开发场景的介绍和项目设计思路，希望老师能够通过具体的项目案例去阐述业务开发扩展的一些开发思路、技巧以及常见的flowable应用问题、误区

例如在flowable的用户角色权限中，根据业务需求整合一套完整的权限管理，如何将现有业务的目录-菜单-按钮的多级权限和flowable的权限概念结合

【2】除却简单的flowable引擎的应用，如何避免重复代码开发，抽离公共的内容，构建通用的流程管理体系？在数据库和项目框架设计层面上如何去构建一个合理的框架，将业务层和flowable层进行抽离？

​ 目前现有项目设计可能更多的是将flowable引擎作为一个工具类的概念，在业务层直接进行引用，并没有实现很好的代码解耦和流程通用性，当有其他子系统业务需要扩展的时候，不断迭代重复工作。flowable能不能设计一个通用的流程，在不同业务遇到类似的流程的时候，可以基于现有的一个通用流程，结合业务需求并通过配置方式动态添加部分节点产生一个新的流程，减少流程图设计的重复工作

【3】后续的想法是基于行内现有系统开发需求的基础上，构建一个公共的后台管理平台，用于统一规范、维护子系统相关的内容，后续也考虑引入flowable引擎，通过抽离公共的flowable层服务（参考盘古BPM工作流平台），给子系统提供公共服务接口进行业务扩展。后续子系统或者是子模块的开发可以基于这个平台基础上通过配置项进行业务扩展，但在实现和方案设计上可能还欠缺考虑，希望老师能够针对我们现有的问题结合一下自身的一些开发经验和技巧，分享一下这类后台管理系统的设计思路和扩展方向。