LogicFlow与原生BPMN的对比

一、弃用及选用缘由
bpmn.js原生的局限
① bpmn.js对于外部自定义不友好,bpmn.js 的拓展能力不足，很难在代码层面进行个性化修改, 自定义节点支持成本很高，而且只能全量引入，无法按需引入。
② bpmn强调的是流程与固定步骤的执行，OA中某些流程可能不存在严格的先后顺序，更多的是对于审判者的决策和事件的执行，比如订单客户在某个节点有定制化需求等等，虽然使用并行网关+事件处理可以实现，但会复杂一些。
③ 与后端配套的流程引擎适配的话成本较高，且不支持数据转换、不支持流程的校验等业务定制需求。
logicFlow的优点
logicFlow是滴滴团队在bpmn2.0规范的的基础上利用svg等改造的，出于以下考虑选用了这套框架。
① 通过内置bpmn.js插件,生成的数据xml基本与后台相符，页面呈现也基本相同，修改成本低，后台基本不用做大的框架的修改。
首先是 bpmn-js 中的各种节点和连线，比如用户节点(userTask)、判断节点(gateWay)、顺序流(sequenceFlow)等，我们利用 LogicFlow 自定义节点和自定义连线机制, 将所有的 bpmn-js 需要的基础图形封装成 BpmnElement 插件。
LogicFlow 默认生成的数据格式是节点和边组成的 json, 而 bpmn-js 需要生成的数据格式是满足 bpmn 2.0 标准的xml。所以我们提供了一个 BpmnAdapter，在数据输入到 LogicFlow 的时候将 bpmn xml 转换为 LogicFlow Data, 在输出的时候又将 LogicFlow Data 转换为 bpmn xml.
最后我们再把流程图绘制过程中需要用到的菜单、画板、快捷工具等利用 LogicFlow 的自定义组件功能，封装成 Bpmn Component 组件。
将上面的三个插件，一起封装为 Bpmn 插件。

LogicFlow 本身只是一个单纯的流程图编辑器，不带有业务属性。为了更好的易用性，我们提供了 Bpmn-js 插件，让使用 bpmn-js 的项目能够快速替换。有了 Bpmn 插件后，直接通过 LogicFlow 装载 bpmn 插件，这个页面就表现成为 bpmn-js 了。

import LogicFlow from '@logicflow/core';
import { Bpmn } from '@logicflow/extension';
LogicFlow.use(Bpmn);

② api相对完善，拓展能力强，各种需要都能通过插件来实现自定义，各种流程场景都能适应，后期维护也较容易。

二、 协调问题
虽然通过内置bpmn.js插件生成xml基本相同，但之前定义并生成的一些会签任签的标签等等需要重新自定义。
前台需要重新处理画布和抽屉内的表单以及节点联动的逻辑（时间成本）
拖拽节点及画布上节点样式问题是否严格按照ui样式

目前框架提供的样式可供参考
4 . 流程校验逻辑较为复杂 若纯前端实现 难度系数较大 是否后台可配合
5 . 连线逻辑是否可进行进一步精简优化

三、 一些链接
​全网最详细bpmn教材
https://juejin.cn/post/6844904017584193544
bpmn.js使用总结
https://blog.csdn.net/qq_39211165/article/details/109152644