(End)从.net到java,工作流平台的延展

      2022年6月6日，我们进入了java工作流平台的第3个年头，在这三年里，平台完成了上100万次的业务审批验证，经历了从能运行-->可使用--->基本能用--->全业务能力--->近期修正的运行性能危机应对，我们已完成了从工作流平台到企业统一流程平台的转身。

      2015年7月，完成在广州的聘用合同期，回到长沙，在特殊的时期加入了企业流程平台自主研发的大军，在原有平台的分析与企业使用情况的调研起步，从简单听说过流程平台开始到2016年1月第一个版本上线，是一个多么奇妙的开始。一路走来，经历了全自主研发的.netR11流程平台的落地，规模化应用，运行性能应对；到基于flowable的java工作流平台的重新认知与基于.netR11工作流类别的企业应用需求集成，并对2019自己提出的运营优先的技术方针落地，我们当下的流程平台运维能力已经覆盖了80%的日常用运营要求，工作流平台从开始的超高风险到像风类水，在无感知中融入到了业务落地之中...........

        本身山中人，悠然自得；努力的人生，不断的折腾.....

1.产品的结构

         作为企业管理平台中最基础的一环，工作流平台的简单/易用/高扩展/标准化集成能力是基本要求，决定了企业管理平台的基础稳定性。作为一家以基础平台自居，超长年限磨合的企业基础应用管理平台，在2020年从.net方向硬转向java方向，实施团队与技术团队的认知差形成了公司的对立风景。以客户优先的策略让实施交付团队给技术团队带来了压倒性的压力......

1.1我们接收的起点

1.1.1技术起点：

以0基础起步，有的是对计算机基础知识的理解，进入java方向后从语法开始，IDE的研究开始，进行全方位的学习/实践/学习......超强度的学习与业务推进压力，让大家都较为随意，身体或是更胖或者出现一些小的预警......

从vue+elementUI基础起步，因为我们知道，企业基础管理平台的基本架构应该是：基础平台+业务落地的模式推进。基础平台提供业务运行的基础服务，业务落地将在基础平台的扩展接口中业务需求。

整体的技术架构术语为：认证--->首页---->网格--->单据---->流程--->报表---->报表之后的事务。所以我们从vue+element ui开始，让大家练习基本的前端能力。

后台采用ssm+mvc架构完成业务实现，基于我们对业务平台面向超大规模企业的基础需求，基于产品基础能力划分，最终形成了17+4的基础应用局面，尽可能多的形成业务内聚。由于工作流平台本身就以独立于业务平台的模式构建，并有组织结构服务/消息平台服务/面向移动的审批应用等。

我们构建了工作流平台/组织结构数据服务/消息平台/rabbitmq消息中间件集成插件/以审批为基础的移动应用平台。这五个服务的逐步完善为平台的基本运行提供了保证。

对于工作流平台，我们拿到了一个(antd+react+bpmn-js)+(flowable+初步基础改造）的可表面是实现基本运行的源码包，经过研究后的8月才初步更够按照我们的猜想初步运行。

1.1.2业务起点

从2007年起步，10几年对企业基础应用管理平台的研究，以及对超大规模企业应用积累的业务基础与管理基础，让我们有强大的业务建模能力，超大规模组织级企业管理平台，多层级/跨组织的的业务审批需求，分层级的数据管理运营需求，跨业务板块的整合需求，让我们的团队有较为明确的技术方向。

1.1.3团队起点

由于是硬转向，java的基础非常之少。加之在新常态下的工作模式，团队建设都是置后的，由于业务的超关联性以及基于业务建模的构造方案，无法直接在市场中寻找的合适的人员。所以基本由我们现有的开发团队，重新培训/学习后转向。

1.2我们的改造之旅

1.2.1业务模型改造

作为组织级的中立流程平台规划，为工作流平台重新设计了基于业务系统-->业务功能--->单据数据模型三个层级的业务数据模型，最终形成了业务数据快照与flowable运行变量融合的简化业务数据方案；在业务数据性能改造期，这个系统模型起到了指导效应。

1.2.2基于业务功能流程管理

业务流程是基于业务存在的，业务将为业务流程运行提供业务数据参考，让业务流程基于业务规划自动识别不同的流转分支。

1.2.3流程运行分支改造

作为流程运行分支条件，必须与业务关联才由意义，flowable使用juel表达式计算分支，并从执行流变量库中提取数据作为数据容器进行计算。为了业务数据与分支条件能明确关联起来，在流程分支条件配置中使用了简化业务模型中的数据字段，让流程平台能自我认知，同时为流程平台的性能优化中变量定位提供了依据。

1.2.4流程适用组织改造

由于面向超大规模组织提供流程管理能力，流程管理进行了分层级管理，并为流程规划适用组织的设计。让流程可以在特定的内部组织中使用，也可跨组织共用流程。

1.2.5子流程改造

基于管理的需求，当特定业务在高层组织中运行时，业务基本一致，所以这部分信息可以设计为子流程，降低流程变更带来的运维工作量，同时降低了业务运行错误。在我们的规划中，子流程应该作为高层管理组织的运行部分存在，让高层组织审批环节一致性存在。当前在某省港集团运行情况看，基本达到了流程运维需求与业务管理需求，在超大规模组织管理中将会是亮点存在。

1.2.6 加签信息改造

作为符合中国国情的业务流程平台，加签必不可少，在flowable原生不存在加签方案，并且加签操作是实例级别的内容，怎么设置加签？当引入子流后，子流程驳回加签信息怎么处理？

当我们把flowable定义为运行内核，在flowable之外，采用事件驱动模式完成有组织意义的审批历史建模后，这一切就变得简单了。加签信息落地根实例中，也就是业务单据主流程中，这样不管怎么操作，根流程实例是不变的，整个加签方案将伴随主流程完成相关生命周期内的使命。

1.2.7新增业务运行图

在业务流程规划时，是存在分支与子流程的，当流程发起后，整个流程将是线性的，重新引入虚拟运行，让整个业务运行图按照当前的业务场景展开，形成显性运行图。

1.2.8基于业务数据/组织结构/流程三个维度的执行者模型引入

在当前市面上的大多数流程执行者是设计到人员或者由审批人在组织中选择后续执行人员，但实际工作中业务人员并不关心后续由谁处理，核心工作是完成自身的审核事项，并流转出去即可。

而作为超大规模组织结构业务规划平台，需要有自我推断能力，基于.net工作流平台引入的执行者成功的实施，并对实施过程中遇到问题的改进，执行者的概念在java版工作流平台中得到了升华，最终形成了更为有效的执行人选择方案。

当出现系统无法确认时，业务平台也可以提供相应的属性让流程平台来确认谁来执行人员选择，有的是发起人选择/也可以指定有审批人选择。这种机制的引入让我们在业务运行规划时更有灵活性，应对运营需求更自然。

1.2.9流程预设置引入

在某省港集团上线前夕，在每个港口给我们提出了流程预设置方案，让业务经办人可以在流程发起时对整个业务运行过程的执行人进行一个确认。以便流程能较为快速的推进，不再被人员指定时间所打断。

这个需求的引入只是时间问题，让整个相同上线时间推迟了1个月。基于后续的运行统计，在平台中需要进行设置的内容并不多。但从流程平台的完整性来说，业务推断是基本需求，只是我们整个平台的构建时间较短，内部还没有驱动到这个位置，强插入后我们使用了近1个月的时间来功能规划/功能验证/用户验证等测试工作。

整体来看这个功能就是业务运行图+执行者选择器构成，核心的内容是改造量太大，在不太稳定的平台中全面业务重构，有点像在豆腐中传入一根线，并让这根线能吊起整个豆腐.......

由于我们的执行者是由完全的推断能力，实际中90%的节点能够被推断，所以实际设置的信息并不多，但改造完成后，我们对流程平台的控制更为顺手

1.2.10 状态机的引入

大家都在诟病流程状态机，但它确实是能解决多业务维度下的处理能力。工作流平台在引入状态机后，可以基于当前的业务现状及系统登录身份，快速提供当前登录身份能进行的相关能力。并且在此基础构建了代理审批能力。能在特殊状态下完成企业运营的相关事项驱动........

1.2.11代理审批能力

代理审批是可以将相应的事项进行重新分配或转移，采用了多个维度的代理设置方案，让具体的业务启用不同的代理方案，使业务分配更为精准。

1.2.12撤回能力引入

当事项已完成流转后，如果后续环节暂时未进行处理，办理人员能进行相关的事项的撤回，当进行相关事项修正后，继续提交。这是流程运营过程中的标准操作。

而当我们面向运营管理时，为了让不好的事项影响降低到最小，运维平台提供了撤回到任意环节的能力。这将大大提升工作流平台的适应能力，让业务运行更为顺畅。但不要有侥幸心理，相关的操作有完整的记录，并无法进行删除。方便系统审计需求。

1.2.13工作流运维功能

业务运行数据在工作流管理平台中提供了统一的运维入口，让整个流程生命周期的数据与执行事项被汇集，并提供了相关事项手动重试方案，让整个业务运行实现了全行为监控，可人工干预的全闭环运维

1.2.14基于消息的业务驱动引入

当我们拿到最原始的代码时，发现基本无法使用，我们在.net平台中已经引入了rabbitmq作为消息中间件，并对外公开了相应的消息主题来定位相应的业务事项，并成功的在工作流平台中拆分出了业务办理消息与业务流转消息。整个体系在rabbitmq中间件的协助下完成了分布式业务驱动。

作为全新的面向超大规模企业应用的流程平台，基于消息驱动的业务流转与业务编排成为了标配。工作流平台必须在保证自身完整性的同时使用消息队列驱动外围业务前行.

办理消息驱动将改变flowable基于任务数据的驱动模式，必须引入状态机后方能实现.....这也是我们的工作流平台与其他流程平台的差异之初，只要有登录身份/业务数据 流程平台将自动完成操作能力的制动识别.

1.2.15全面的SDK方案

在规划之初就被强行拆分，为了完成于业务平台无差异集成，我们提供了全方位业务集成sdk.(备注：长沙团队设计的主键都提供了sdk，为微应用集成提供了便捷之门)。

在于企业内部业务平台集成时，我们使用sdk构建了一套完整的参考实现，并作为我们的标准组件对外运行。本既是运行主件，也是参考实现。

1.2.16其他改造

为了实现企业级统一流程平台的夙愿，我们进行了其他一整套支持方案的改造，平心而论，flowable成为了统一流程平台的内核选择之一，如果有其他的需要，完全可以被替换.

1.3整体架构设计

1.3.1组件架构

1.3.2技术栈

工作流管理平台：react+antd+bpmn-js

工作流引擎：flowable+spring+spring boot+oauth2+mvc+mybatis

消息平台：spring+spring boot+oauth2+mvc+mybatis

组织结构服务：:spring+spring boot+ thymeleaf+vue+elementui+mybatis

工作流消息中间件：rabbitmq

统一缓存组件：redis/ehcache/mongodb（由于安全问题暂时停用）

SDK: 单应用版 Resttemplate/微服务版fegin

2.产品的能力

2.1我们的应用场景

工作流平台面对的是企业管理中最复杂的合同管理业务流程而生，并且是全面线上审阅。存在大量的分支于流转要求。并且在审批事项中引入了审批任务单据与审批文件概念。最新版本将支持节点级审查清单事项集成。是一个真正面向企业复杂运营的在线审批平台。

2.2面对的问题

我们必须从流转规划/流程定义/流程发布运行/流程运行维护/流程优化改进等多维度出发，形成企业业务流程梳理/固化/改造/重构全生命周期管理工具。让接入的业务平台能简单平稳第完成接入工作，并形成相关的参考实现。

2.3最终平台能力

序号	业务组件	业务场景
1	管理能力	集成系统列表管理
2		系统功能清单
3		特定功能业务字段维护
4		业务功能流程模型管理
5		业务流程分配
6		业务流程模型发布
7		已发布流程管理
8		流程实例全数据管理
9		运维操作日志
10	SDK	提供流程业务流转全能力封装
11	Org服务	提供组织/部门/岗位/员工/组织群/部门群/岗位群/人员组/ 人员等维度细腻些
12	消息平台	提供 待办/已办/发起/通用/第三方集成等消息完整能力
13	工作流引擎	业务流程清单
14		流程发起
15		流程预设置
16		流程预设置后流程发起
17		执行审批
18		会签跳过
19		执行者选择
20		提交下一步
21		撤回
22		驳回
23		驳回后提交
24		前加签
25		后加签
26		添加会签人
27		移交审批人
28		流程终止
29		流程终审
30		批量移交
31		代理审批
32		流程暂停
33		流程暂停后恢复
34		流程作废
35		业务办理消息发送
36		业务编排消息发送
37		节点自动审批
38		节点合并审批
39		基于子流程的以上功能集成
40		子流程穿透
41		运行流程图
42		其他

3.平台发展方向

3.1自身使用

工作流平台优先作为基础平台的一部分在产品中承载相关业务，并不断对业务与工作流平台的融合机制进行磨合。工作流平台作为中立组件，在产品推广时按照优先使用甲方已有的统一流程平台（bpm），当无法满足我们的业务平台需求或未建立企业级统一流程平台时，将启用我们的工作流平台。（由于经过大量客户实战磨合，会更为顺畅）

3.2企业统一流程平台

我们自己的流程平台已匹配了四个产品线，也就是说流程平台本身是具备企业级统一流程平台能力的。如果有条件或有需求，将可以承担起企业统一流程平台的职责。

我们已有案例让其他系统接入我们的流程平台。

同时我们自己的流程平台作为配角，核心业务采用已顺畅的统一流程平台完成。

工作流平台也可以作为整体运营流程中的一部分，让平台能与其他流程平台分段融合，形成多维度整合的业务流程串。

不管是那种方式，我们自身的流程平台能站在补位的角度，快速推进企业信息化项目的落地。

3.3企业流程平台参照

我们的工作流平台已集成了近十几年对业务流程运营的成功，具有较高的参考价值，如果需要构建企业级统一流程平台，不妨借鉴一下。

3.4其他

4.在最后

工作流平台最终的归宿是企业级统一流程平台，站在企业整体的角度，构建或重构企业级运营流程，在数据挖掘与风险识别/合规识别的基础之上，让企业运营在合法/合规/风险可控的前提下正常运行............................

工作流平台基础研发将结束，下一个方向将会是数据挖掘与数据应用，提升企业数据化成果与利用价值，最终反向来提升/优化企业的运营模式。