FFT系统之flowable整合

FFT系统开发总结——flowable整合

中心思想：

​ 1、使用flowable开发项目与没有使用flowable开发项目的区别（学习成本、开发周期、工作效率等方面）；

​ 2、使用flowable的开发遇到的问题、技术瓶颈和可拓展性；

​ 3、flowable在后续处理流程类项目需求中能否高效的运用。

一、数据库设计思路

1、用户角色权限表

【1】权限表：

​ 目前使用两套权限表的概念

​ 一是常规的“目录—菜单—按钮”的权限，主要是控制业务中对应角色的访问权限和页面展示相关的功能；

​ 二是使用flowable工作流流程的权限，因为flowable的思想是，每设计出一个流程，对于每个角色都需要设置这个流程可访问性的权限

​ （例如：假设有流程1和流程2，且只要部分用户可以访问流程1，那么就需要对这个流程进行访问权的分配）

思考：是否有可能对这个两种权限进行整合？那种思路比较符合逻辑？

【2】用户信息表/角色表：

​ 因为flowable本身的表结构不符合业务的需求，故目前用自己的用户信息表、角色表代替flowable的用户表和角色表

​ （且不太熟悉flowable操作是否关联这些表，所以暂时不动这些没用到的表，而是从新设置新表）

2、业务数据信息相关信息表

二、框架架构设计思路

1、flowable结合业务的开发思路：

【1】目前的想法：考虑到后续会有多个项目使用flowable，且flowable工作流自身也有很多数据表，为了flowable表能够复用，目前设计上是 后台管理系统+多个子系统 的概念【目前考虑的还不够周全，如果要后续拓展增加子系统，还需要做一些调整】；

说明：

① 后台管理系统——主要负责系统管理和流程维护两个模块

（

子系统维护：包括子系统的增删改查、管理员管理、角色设置和权限设置；

流程监控管理：部署子系统的流程、流程定义的管理、流程角色的流程权限设置和运行流程管理

）

权限设置：指一般的“目录—菜单—按钮”权限

流程角色的流程权限设置：指某些角色可以发起某些流程

② 子系统（业务系统，如福费廷系统）——主要负责业务功能的开发

步骤一：先在后台管理系统中增加子系统，并配置好角色权限；

步骤二再部署该子系统需要的流程，并配置好流程权限；

步骤三：在业务的开发中，根据步骤一和步骤二的配置信息运用在业务的逻辑开发中

【2】深开的开发思路：深开使用flowable的技术也是类似按照后台管理系统+业务系统 的思路开发，但是在后台管理系统的设计却是不同的，我们目前只是运用到流程部署和流程权限设置这两个主要功能，但是深开的后端管理涉及的功能整合得更加复杂（有流程的设计、流程节点的维护等功能），最后封装成jar包的方式并提供接口供业务系统开发时使用，而我们目前是直接在业务系统中调用flowable的方法。

三、技术瓶颈和疑惑

技术难点：flowable运用的难点和填充并生成word类似的难点

四、支持条件

1、需要有完善的后台管理系统来管理flowable：每个系统都单独使用flowable开发有点不符合实际情况