从自研到使用开源再到自研,我的工作流开发心路历程

项目简介

🐜 AntFlow是一款采用Springboot+Mybatis+activiti+ruoyi+vue3等主流前后端技术开发的仿钉钉工作流引擎,结合中国式办公特点深度定制,可以作为钉钉工作流的开源替代。致力解决传统activiti/flowable流程图必须由专业程序员绘制,学习曲线陡峭,上手难、排查问题难、维护成本高等问题。如果喜欢请给颗⭐️。

我的工作流开发历程

AntFlow的最早开发可以追溯到十年前,那时候苦逼的作者在一个二十线小城市做外包开发.由于开发的项目需要使用到审批流.这时候面临一个问题,是使用成熟的工作流引擎还是自己研发?市面上有成熟的工作流引擎比如ActivitiJBPMcamunda等(那时候可能flowable可能还没有出现)。使用流程引擎固然有利于项目长期发展维护,然而工期只有三个月时间(还有一堆的的OA功能需要开发😭😭😭),鉴于项目虽然功能繁多,但是流程数量比较少(就两三个)的特点,最终决定结合项目实际需求,来定制一个简单的执行引擎。

确定方案,马上开干

由于时间紧,任务重,压力大。决定自研以后,大概花了一个星期的时间梳理业务以及设计了技术方案(文档早已没有了🥺🥺)。简单分享一下当时的表设计并组合表设计讲一下大致的实现思路。

  • 流程和业务关联表。流程和业务关联表主要用于将流程执行业务和业务表单逻辑分离。里面存储着流程编号,业务表单Id,流程状态,流程发起人,流程摘要(主要为了流程多了以后发起人、审批人可以通过摘要快速检索到历史流程),通过这个表将流程执行业务和业务表单逻辑分离开来。
  • 流程主表 用户可以在web界面设计流程图,设计完以后,要将信息提交到后台。流程主表是整个流程的全局配置,字段有流程名称(这是一个什么样的流程),流程key(和名称对应,生成流程时流程编号的前缀。比如请假申请的流程key为QJSQ,发起的流程实例的编号是QJSQ-001,QJSQ-002或者QJSQ-20240506-001这样子,规则都是可以自定义的),停用禁用,是否在使用(用户可能会更改流程配置,更改以后重新存储为条新的记录,而不是在原记录上修改),流程类别等信息。
  • 流程节点表,用户可以在web界面设计流程图,设计完以后提交后台时整个流程的信息存储在流程主表里,流程节点信息存储在流程节点表里,主要记录节点Id,节点名称,节点审批方式(会签,需要全部审批人都同意;或签,只需要其中一个审批人同意)。
  • 流程节点审批人表,由于一个节点上可能会有多个审批人,因此节点和审批人是一对多关系。需要设计一个专门的表,存储审批人信息,并通过节点Id和流程节点表进行关联。
  • 流程节点通知表,这个表比较简单,就是存储要通知方式(短信,邮件),通知模板信息
  • 流程执行记录表,流程发起以后,每有一个人审批完成以后,就会把他的审批记录存储在审批记录表里。审批记录表主要存储了审批节点,审批时间,审批人,审批意见等信息。
    有了这些核心的表之后,一个流程便可以执行起来了,很多号称自主研发的流程引擎也无非逃不了这些设计。其实很多读者仔细思考思考,自己也能做出来,主要原因可能是实际工作没有需求没有压力去做。或者被activiti这样成熟的,设计复杂的,功能繁多的流程引擎给吓住了。其实实现一个简单流程流转业务不是非常难的。

以下是一个简单的从流程设计到流程流转示意图
在这里插入图片描述

写时一时爽,维护火葬场

项目如期交工,不久公司顺利拿到全部款项。聚餐,跳舞,蹦迪。。。各种娱乐活动,由于没有使用流程引擎就独立做出了一个流程执行引擎,被同事们刮目相看,还有人称你一声:大佬。感觉人生到达了巅峰。。。

然而,好景不长,麻烦随后开始出现,
今天xxx领导不在,需要让他的秘书帮审批一下。。。
局里最近成立了审计科,xxx流程需要加个审计节点,并且不同审计人员负责审批不同部门的流程。。。
xxx领导要看到流程,但是不审批,并且要体现在流程节点上。。。
😩😩😩
有些功能还好改,有些则比较麻烦,常常加班的深夜来填坑,代码越糊越厚。。。
后来离职了,终于解脱了。。。

泥玛又是富士康

可能是由于自己有一点OA开发经验,刚逃出魔掌,后面又拉被去负责OA业务。。。

痛定思痛,总结反思

由于有过被工作流折腾的痛苦经历,这此肯定不能再重蹈覆辙,总结起来,之前做OA工作流的核心问题在于自己初入行,见过的审批流程少,对审批中的复杂场景没有预见性。设计架构完全基于特定的场景,没有扩展性。

心态归零,重新出来

由于中间这些年做的都不是工作流和审批相关业务,自己在审批流方面的经验较之前并没有增加多长,所以心态也很容易归零,没有历史包袱,历史资产虽然当 时足以上自己沾沾自喜,然而到了大城市之后见到了更多的人,了解了更多的事,才发现自已只是一个螺丝钉。这时候除了维护公司OA审批流,在工作和业余时间,狂补activiti基础知识,工作中每遇到一个问题就以此为切入点,以点带面全面了解某一个方面的知识。就这样日复一日年复一年curd,学习,解决bug。。。龟速发育

公司迎来快速发展,风暴席卷而来,是挑战,也是机会

虽然技术烂透顶了,业务系统做的也是一塌糊涂,三天一小炸,五天一大炸,内存打满导致redis挂了,磁盘写满导致F5负债均衡出现诡异问题,发布把uat变量带到生产,项目发错机器导致全部404。。。然而系统也不是不能用,每次出问题被吊一顿,然后又该怎样还怎样。。。

然而,你敢信,你敢相信,公司竞然上市了!!!上市以后迎来了迅猛发展,股价上升比狂飙兄弟跑的都快,由于流量激增,那个原本还能用系统终究还是扛不住了。公司高层,投资人震怒,震惊,开始对技术部大换血,从大厂招大佬带着他的几十个小弟来势汹汹,来者不善。开始先是杀鸡儆猴,谁出问题谁走人,后面直接把主要负责人杀掉,还是不行整个部门分部裁撤,系统重写。

做为OA系统负责人,此时的我压力山大,整夜睡不着觉,然而相比其它系统,OA系统还算是靠谱的,虽然小问题不断,但是还是能用,可能由于并不是核心业务系统的缘故,OA系统并没有被大佬约谈,但是我心里并不踏实,惶惶不可终日。终于有一天,我终于坐不住了,去找新来的大佬谈一谈,进去之前我就把所有问题都罗列了一遍,并分析具体原因。由于准备充分,大佬的问题我都能从容面对。被问起准备怎么做时,这时候我详细分析了为什么使用原生activiti已经无法满足公司现在业务的业务发展速度了,并且祭出了我结合工作经验以及遇到的问题在业余时间编写的新的工作流系统AntFlow(当时并不叫这个名字)。为了消除大佬的戒心,我讲速了自己最早自研工作流引擎的经历,虽然最初做的不好,但是简单,可控,可调试,可观测应当是大型工作流系统的基石。AntFlow规避了之前的不少设计问题,并且在朋友的公司已经落地实践(较大规模客服系统,有近三万名客服,之所以敢在他们那里用而没在自己公司用是因为朋友公司是全新系统,而我们的在支撑着线上全公司的审批业务)。并且跟大佬分享的我是如何努力的学好工作流,基础知识如何扎实,并且愿意让大佬从他的同事中或者从外面找人来考我)。聊了整整一个下午,大佬非常赞同我的重构的方案。并且调了一名曾经在钉钉工作的产品来负责OA系统重构设计。于是重构很快就开始了,在后面的工作中,这位产品给了我很多好设计理念和思路,并且他人也很nice,对于他提出的很多设计被我否定的(有的只是和项目deadline冲突暂时不做)功能他基本都接受了。最后经历了差不多三个月时间项目便如期上线了,后面用了差不多半年时间。我们迁移了旧系统全部的大约30个核心流程。当然我们并不全是在做迁移。由于新的仿钉钉的引擎简单快捷,设计优秀。上手开发起来非常快,基本一天就可以上线一个不是特别复杂的流程。人手不足时外援也可以迅速上手来开发流程(AntFlow引擎和业务完全分离,新来的人不需要懂工作流程,在有经验的负责人带领下能很快介入流程研发)。不断有业务方提出新的需求,如雨后春笋,并且我们的支持合作态度都非常好,赢得和公司其它业务方的认可和好评。最终一年内流程数量迅速增加到近三百个。后面虽然也有新的流程开发需求,但是新需求频率和数量都少了很多,更多是对现有流程的优化。

AntFlow开源

AntFlow经历了在公司稳定运行几年之后,我们决定将AntFlow开源,让更多的有类似业务场景的公司(审批业务繁多,开发团队人员少)使用,并在使用中根据反馈解决问题,优化现有功能,开发新功能,不断适应更多业务场景。

AntFlow基本介绍

🐜 AntFlow是一款采用Springboot+Mybatis+activiti+ruoyi+vue3等主流前后端技术开发的仿钉钉工作流引擎,结合中国式办公特点深度定制,可以作为钉钉工作流的开源替代。致力解决传统activiti/flowable流程图必须由专业程序员绘制,学习曲线陡峭,上手难、排查问题难、维护成本高等问题

AntFlow核心特性:

开源,完全免费,没有任何收费功能,无付费引导。(如果您的企业使用了,麻烦让作者知道,帮助作者推广开源项目,作者也会帮您进行技术支持,帮您在企业快速落地)

引擎遵守高内聚低耦合设计理念,将流程引擎和审批业务完全分离,流程引擎业务不会入侵到业务里,只需要关注业务流转逻辑编写,极大降低入门门槛,开发超级简单,只需要实现一个接口即可完成一个流程开发

流程设计简单,流程设计器用户友好,人人可用:AntFlow提供了一个简洁的流程设计器,摒弃了传统设计工具的复杂性,使得用户能够直观、轻松地设计和管理工作流程。

流程引擎和用户角色系统解耦,可以较方便的接入用户系统现有的用户角色系统,快速集成到现有业务系统中

流程可调试:AntFlow 提供了一个管理流程调试界面,同样不需要程序员介入,流程管理员便可通过流程调试界面解决大部分日常常见流程问题。把程序员从繁琐的重复的日常小问题排查中解放出来专注于解决更有价值的问题。

引擎完全透明化,流程所有节点、任意属性都是可追溯的,出了问题有据可依,心里有底.

久经生产检验的:AntFlow经历了多个版本的迭代更新.在某大中型客服公司、某中型互联网公司、某大型快递公司落地使用,经受住了复杂业务场景海量数据压力的考验。

AntFlow系统界面一览

在这里插入图片描述
在这里插入图片描述
在这里插入图片描述

基本功能一览

功能功能解释&场景示例完成情况
审批人前去重不同节点都需要同一个审批人审批时,审批人只在最前面节点出现(可能刚接触流程业务的人不理解为什么要去重,如果审批流每个节点都是固定人员,当然不需
,实际情况是复杂的办公流程很多节点都不是指定的人,而是根据规则带出来的.比如一个报销流程需要直属领导和部门负责人审批,有的员工的直属领导就是
部门负责人(比如你是研发组长))
审批人后去重不同节点都需要同一个审批人审批时,审批人只在最后面节点出现.前去重还是后去重是根据实际业务决定的.比如在一个财务流程中需要资金经理和财务总监
都审核。财务总监可能也是资金经理(资金经理有多个),这时候流程对他后去重比较合理,流程先让其它资金经理把关,没问题了再到他那里(
审批人不去重审批人前去重后去重都是针对流程整体而言的,针对流程的某个节点,有需要不去重的场景(即去重逻辑对它失效)。比如某个大额打款流程需要出纳在
特定的机器上操作(可以实现对流程特定节点控制)。如果他在打款节点被去重掉了,则将导致打款行为无法进行(流程设计时是对打款这个节点进行控制)
会签流程某个节点需要多人审批时(通常是一类角色,会有多个人),需要所有人都审核通过流程才能继续进行。比如一个项目立项流程需有个审批节点是副总
经理审批,可能公司有多个副总经理,需要他们都同意流程才继续
顺序会签上面的会签是不分顺序的,强调需要审批节点上的人都需要同意方可继续。顺序会签则是流程到了这个审批节点,需要按预先设计好的顺序依次审批通过
还以上面项目立项流程为例。假如多个副总经理有一个是起决定作用,其它人都是象征性同意。则可以将流程设计为他最先执行,然后再到到其它人审批
具体需要不需要顺序,要结合具体的业务设计。总体上而言,不需要依次审批的效率会高一些(这里批审批的流转效率,技术上没有区别)
或签流程某个节点是多人审批节点,但是只需要一个人审批通过流程就可以继续向下执行。比如一个财务报销流程,到了出纳审批的环节公司可能有多个出纳,
但是只需要任意一个出纳审核票据无误就可以继续向下进行
打回修改AntFlow的特色功能(市面上一些竞品也有这项功能),流程发起后,由于表单字段填写错误,这时候让发起人重新填写显然效率非常低,也容易让人暴躁,
AntFlow支持将流程打回到发起人重新修改后再提交,然后流程继续
流程同意、拒绝审批流的基本功能
流程加批流程加批用在一些组织角色不明确的流程中,比如一个开发人员发起了一个数据库变更流程,需要他对应的产品同意,公司中一般可能没有开发对应的产品
是谁这样的划分,这时候流程可以设计为允许加批,开发在发起流程时选择自己的产品进行审批。
流程作废在流程还没有审批完成时,流程发起人对流程执行作废操作,终结掉当前流程
变更当前处理人变更流程当前正在执行节点。使用场景:正常离职需要办理离职交接手续,其中有一步是交接手上正在处理的流程给别人,但是有些
特殊关系户,他在离职的时候只需要找个招呼就行了。这个时候需要他审核的流程就会卡住进行不下去,这时候可以向领导请求他手里的流程可以交接给谁
然后把处理人变更为指定的人。变更处理人直接更改引擎中当前节点的处理人,是危险操作,可能会查看审批路径人审批人看起来不对
变更未来节点处理人有些流程由于开发时存在逻辑bug或者运营人员在配置时候配置错了,导致不应该出现在当前审批流中的人出现了。比如加班餐20元报销流程不一般不需要
老板亲自审批,但是走到老板那里了。一大早上老板的OA系统出现一堆加班餐报销流程,想想老板会是什么心情💀。这时候如果流程还没到老板那里,可以变
更一下流程处理人。注意,变更未来节点处理人是一补救措施。和变更当前处理人的区别第一点当然是节点状态不同。第二点就是变更处当前处理人一般针
单个具体流程实例(通俗讲就是有流程编号的一个流程),变更未来处理人一般为整个流程级别的。比如所有的已发起的加班餐报销流程
流程委托处理人将自己需要处理的流程转交给别人代处理的过程称作流程委托。比如为了感谢你对公司辛勤付出,领导给你放一个月假让你到三亚旅游一圈,此间你
不想处理任何与工作相关的事务(那是不可能的),这时候可以发起一个流程委托申请流程,被委托人和相关负责人都审批通过后流程就自动委托给指定的
人处理了(流程委托也是危险操作,不能轻易开放。比如一个百万级别的采购流程公司副总擅自委托给一个不知明喽啰审批显然是不合适的😄)
流程限时制委托流程处理人将自己需要处理的流程在指定时间段内委托给指定人代处理的过程叫作限时委托。有些委托是永久性的,比如老板会将一些非必要自己审批的流程
委托给自己的秘书(老板委托自己的流程也要发起流程申请?are you kidding me?其实要看怎么设计的,如果老板会严格遵守公司规范没问题,如果不是则
就需要特殊考虑,比如给管理员增加一个手动修改流程委托人权限,这也可以防止程序出现意外情况有补救措施。比如别人流程委托申请的流程走完了,结果
逻辑没生效。你让别人再重新发起一个流程?这个时候自己手动私下处理掉得了🙄。回到正题,实际工作中很多流程委托都不是永久性的,比如上面的你到三
亚旅旅游的案例。你只需要在这段时间内将流程委托出去,你回来了还得继续当牛做马干活🤐
定时流程工作中有很些场景流程并不会是由用户手动发起的,有的是系统以指定用户的名义发起的。比如员工试用期转正申请。如果让员工自己来关注会比较累,让hr
来提醒hr也会比较累。这时候可以制定一些定时流程,在员工试用期到的时候自动以他的名义发起一个试用期转正申请流程(流程节点上要把他设置为审批人
不然他自己都不知道,一脸蒙蔽🥴)
流程灰度在日常开发中,有些比较规范的团队会有灰度发版操作。同样,在重度依赖审批流的公司中,审批流出错可能会导致严重的问题,轻则批评责备,重则相应
开发负责人员卷铺盖走人。为了将新上线的流程可能的bug导致的风险降到最低。可以对流程进行灰度试点。灰度的策略有很多,比如指定人员使用,指定
角色使用,指定部门使用等。线上运营一段时间没有问题时再放开给整个公司使用。(看到这里你是不是感觉可能会非常困难,其实使用起来非常简单。这也
是AntFlow的追求,让流程尽量简单,流程开发完成以后运营能做的事尽量不让开发来做。后面会出教程详细介绍
流程遇到指定人结束这是流程设计时的一种功能,非运行时的。比如一个按公司部门组织层层审批的流程,有时候不知道需要向上审批多少层结束,但是可以在有某个人出现的时候
终止。
超时自动审批目前尚不支持,开发起来没有太大技术难度。但是作者一直坚持流程同意应当是审批人的真实意愿,可以结合oa系统站内信提醒,IM工具发消息提配,线下电
话沟通等方式让他同意掉。而不仅仅是为了时效性通过技术手段让流程自动通过。(AntFlow有很多中国式办公的功能,比如某个人不在了导致流程无法进行
这时候可以变更处理人来处理。总之有很多方法)。当然如果大家觉得这个功能很必要,出可以开发
流程抄送审批流的基本功能,将流程抄送给指定的人方便他查阅、归档管理。
流程自定义条件流程设计的时候往往会根据不同的条件决定执行不同的流程分支。条件也多种多样,和公司业务有密切关系。也是AntFlow中为数不多需要自己开发定制的功能
当然开发起来也非常简单。只需要实现一个接口构造一个返回true或者false的函数即可。剩下的交给引擎来完成。
流程执行运作流程在审批某个特定节点\审批完成时执行一个运作。比如一个用户发起一个腾讯云账号申请流程。有的公司是流程完成之后负责这个流程的人手动给员工开通
账号,对于大型企业每天有成千上百的人需要申请各自云平台账号,这样显然是低效的,可以更进一步,流程完成以后会发起回调事件,在回调事件里写上特定
的和云平台对接开通账号的逻辑即可。流程执行运作也是危险行为,需要注意设计逻辑的完整性
流程完结后自动发起
新流程
比如在一些公司有着复杂的离职流程,一般公为几个有先后顺序的流程,最后一个流程走完了才算离职完成。这里可以通过流程运作来完成,单独拎出来说是因
为作者觉得这个功能非常基础。也是为了帮助大家拓宽思路。结果流程引擎的现有某项或者某几项能力来完成一项功能
外部流程接入外部流程接入是指公司内以OA系统为核心,将流程引擎做为基础组件提供给公司其它业务系统来使用。比如果Devops系统,CRM系统,WMS系统等。这些外部
系统接入了之后便可以使用OA流程引擎的基础功能,一方面便于流程集中管理,另一方面减少研发资源的浪费。很多团队比如Devops团队做流程引擎自然没有做
OA系统的人专业。他们随便在网上找个组件使用一面方存可能存在能力不足问题,另一方面可能存在各种bug需要处理,他们可能处理不了。这些专业的事情应该交
给一个专业的团队来做(这块功能作者在做企业级开发的时候做过,但是效果不是很满意,这块功能正在重新规划中)
🕘

开源易,如果你喜欢,给点项目个点星吧

后端gitee地址
后端github地址
后端gitcode地址
前端地址

功能都是开源免费的,无付费引导,无收费套路

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

国通快递驿站

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付:¥1
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值