与工作流平台的一些往事 2024

2023已经过去，在2024的春节前，整理下这些年与工作流平台的一些往事.......

1.我们的往事

2009年，本有缘参与一套oa系统的研发，由于总总原因没有真正的参与

2013年,有幸参与了一个带有固定流程的平台研发，但我的角色是居于autocad进行图形处理的二次开发，图纸绘制与查看只是其中的一个基础环节，没有太多的流程相关的事务。

2015年，正式加入当前的团队，当时团队处于由R7工作流平台带来的混乱期，需要一套兼容当前平台数据/设计全新的工作流平台来替换R7版本。

2020年，经过一段的时间的积累，正式启动了基于flowable6.5的java版统一流程平台的研发。

今天回头看，流程平台也就那样，站在企业管理平台的核心位置，驱动着业务标准化，承载着企业日程运营的运转，是一个底座式组建，不卑不亢地默默运行着-----正常时无人问津，异常时全员攻击。随着时间的流逝，流程平台不断成长，已覆盖大多数场景，集团级场景应用已被大量的数据尝试......

2.我们与OA的差异

企业级管理系统有着领域级方法论，驱动着各个供应商最终实现的一致性。但在企业管理平台中，工作流平台管理模式发展成为了2个方向：

1）传统OA类以管理事项构建单据，并采用特定的流程与之相匹配，形成了业务单据---审批流程一一对应体系。

2）现代的以事项域为管理起点，业务单据面向事项域模型构建，基于业务属性匹配不同的业务流程与分支。最终实现基于业务领域模型与业务流转流程集之间的关系，形成业务单据与业务流程1对多模型。

我们一直按照业务域构架管理模型，采用流程集作为业务域的流程流转方案，以智能识别方式尽可能精准的匹配流程。

3.自研的两个工作流版本：.net版本与JAVA版本

3.1 R9工作流平台（.net）

由于R7以在客户现场运行将近一年多，数据库模型必须兼容R7，也就是数据库模型在这次改造中只能增量，不能全新构建。

技术体系：C#+IIS+silverlight

本次的核心工作：分析R7数据库模型/采用全新模式构建工作流引擎/提供符合业务要求的工作流前端。

R7的问题：

R7采用了编程式实现流程流转，所有事项采用了流式实现，没有架构主题，最终代码实现混乱无法运营，新增功能成本过高。

R9的架构设计：

需要解决企业管理多变的需求，同时简化业务功能集成点。整个体系被明确定义：

新版本引入了一层状态机，明晰了与简化了产品实现机制，最终采用了37个职责明确/逻辑清晰的独立组建构建了新一代流程引擎。

.net版本工作流数据模型：

R9平台缺陷

1. 只是企业级规范/缺失对国际标准的支持
2. 并行分支支持不足

3.2 liveBPM平台（java）

启动基点

2019年大连之行，在兄弟部门见到基于flowable6.5的工作流定制原型。

2020年6月，从最后接手的西安兄弟团队中接手到原型源码（后续没有同行人）

2020年7月进入到liveBPM平台构建阶段............

.........

liveBPM架构机制

数据模型

当前执行效果与挑战

到上周完成消息平台调优后，整个产品已经满足规模企业商业化方案。与R9相比，只缺失流程扩展服务与树节点方案，其他基本已经覆盖，并在推广过程中已经证实可以在用户无感知的情况下切换大liveBPM版本。

面对大数据与企业流程多层集规划方案，产品需要进一步完善数据存储与应用相关的能力。

4.对企业管理平台工作流部分的建议

1. 最优的方案是接入企业级统一流程平台，而不是自己提供一套方案。
2. 尽可能不自己研发工作流相关的组建，采购成熟平台更为有效益
3. 在决定自研的时候，尽可能多考虑难度，不要太乐观
4. 对于开源的工作流平台或内置工作流平台,java方向大多采用接入flowable与activity，合理规划数据量，与业务难度，符合中国国情下的工作流业务需求跟这两个平台是有冲突的，需要评估自身的把控能力。

5.未来方向

liveBPM/Databus/bizmsgplatform三大基础组件在内部已经相对成熟，不在是重点方向。数据流平台是下一个研究点，将驱动平台加入企业数字资产化/数字化进程。业务编排将会是liveBPM的一个简化分支，实现企业数字服务可视化编排。