「扫码关注我,面试、各种技术(mysql、zookeeper、微服务、redis、jvm)持续更新中~」
不知道大家在平时工作中有没有遇到过类似的问题?业务团队经常去线下收集各种业务表格,进行统计,然后进行部门、人员之间的流转、上报领导,我们在服务公司销售团队的时候遇到了以下问题。
问题一:通过手动、人工的方式进行收集信息会导致信息无法及时同步,影响工作效率,不利于团队共享管理。
问题二:工作中有很多申请和重要的信息变更,需要领导进行审批。
问题三:业务发展变化较快,页面表单也经常变动,固定的表单开发模式会影响业务发展的速度。
基于以上面临的问题,我们打算借助业内审批框架或者自建的方式来提高业务团队的整体工作效率,使流程线上化,提升流程合规性、达到记录可追溯、结果可复盘。同时针对页面表单经常变动的情况,我们计划打造一套用户自定义配置表单(拖拉拽)。整体设计向低代码平台进行探索。
我们调研了业务审批流相关开源框架,如:Activiti和Flowable等,特别是Activiti,但是Activiti存在一些弊端不能满足工单需求,主要包含以下几个方面:
Activiti是静态流程,对流程经常变动场景支持不灵活,需更改流程图发版上线;
Activiti更适合扁平简单的组织架构,对复杂、经常变动的组织架构的支持不足;
如果适配工单场景需大量二次开发,难度较大,耗时较久;
如果使用Activiti那么需要引入其相关数据库表,Activiti的查询是代码自动封装,复杂业务条件下自动生成的查询存在慢查询等性能问题;
Activiti审批流支持自下而上的审批方式,但是对于我们的业绩拆分场景,自上而下下发(按照部门树由高层级流向底层部门)目前是不支持的,而且对于我们部门层级变更不能灵活适配。
基于以上原因,于是决定自研工单引擎,在实现过程中很多思想也是参考审批流程框架来实现的,比如:
自定义表单设计
工单流程配置过程设计
工单引擎的设计核心就是在工单流程的灵活配置上,并且可以及时生效,不需要和传统审批流那样修改流程节点信息还需要发版才可以。
在设计工单引擎需要依赖部分基础数据,比如公司的部门架构、人员、岗位、基础业务表单等,所以我们整体列一下其中的表结构关系。
部门、人员组织架构表
工单流程表单配置和工单运行实例表
其中流程配置部分也是对应上面工单流程配置,是工单引擎设计的核心所在,因为在实际工单运行过程中,都是按照工单配置来流转的。
经过整体设计和开发,工单引擎具有以下特性: