camunda 流程执行追踪_Camunda 流程引擎的一种 Adapter 层实现

上一篇说明了选择 Camunda 的理由。这一篇说明如何实现适配层。

当前还没有专门写一篇对 Camunda 各个功能的详细介绍。如果要获得比较直观的感受，可以下载 Modeler 或者使用在线版的 Modeler 。

https://demo.bpmn.io/

目录：

为什么要做适配层？

要对 Camunda 做扩充的部分

数据表的扩充

流程实例的操作

前端动态表单的渲染

结语

为什么要做适配层？

现有引擎无法满足业务

如果能满足，加个代理层就够了。

避免改源码导致升级困难

我们部门有个基于 k8s 源码修改的项目，当年拿过公司的大奖。现在由于没人维护的来，已经凉了。

可以兼容其他流程引擎

当前选的引擎即使能满足当前业务需要，但未必满足其他业务的需要。更何况要形成一个基础设施给其他组件使用。

+---------+

| |

| System |

| |

+--+--+---+

| ^

v |

+--+--+---+

| |

| Adapter |

| |

+--+--+---+

| ^

v |

+--+--+---+

| |

| Camunda |

| |

+---------+

要对 Camunda 做扩充的部分

各业务系统有自己的系统界面，也有各自需要展示的内容，不能直接使用 Camunda 自带的管理界面。

Camunda 内置的表单支持使得业务系统对其有一定的依赖。要改成在业务层处理。

Camunda 在一次请求跳转时只能对原任务和目标任务同时应用或者不应用参数检测。但其实应该要在取消原任务的执行时不检测参数，在创建目标任务的执行时检测参数，因此要分两次。

流程和流程实例 ID 是 UUID，但要展示整数 ID 给用户。

流程实例自动化任务出错时，要转交给运维处理。

制定 External Task Client 的规则

数据表的扩充

为了适应业务需要，需要另外创建几张数据表：

流程定义信息表

流程实例信息表

流程节点日志表

服务定义表

服务请求客户端管理表

流程定义信息表

无论是团队内部沟通还是和需求方沟通，最经常用到的用于区别流程的信息是流程的 ID。大家都不太喜欢用流程的名称来沟通，除非是比较少见的流程。而且在各种文档中也是使用流程的 ID。因此这个 ID 信息需要展示给用户。

由于是从旧系统迁移过来的，所以要保证原先流程的 ID 不变。所以不适用自增 ID 作为流程 ID，而是新增一列专门存储这些 ID。

以下 pd 表示 process definition，e 表示 engine 。

字段

作用

id

自增 ID

pd_id

流程 ID，兼容旧系统

e_pd_key

底层流程引擎的流程名称，也用于翻译后作为名称展示

e_pd_version

当前使用的流程版本号

e_pd_version_max

底层流程引擎的流程最高版本号

category

流程分类

maintainer

维护人

doc_link

文档地址

note

备注

Camunda 可以通过流程名称和流程版本确定一个特定的流程定义 UUID，所以不需要在这里加上 UUID。

如果要加入其他引擎，且这些引擎不是用 key 和 version 确定，则可以加入 UUID 字段。并且还需要加入 engine 字段用于标识使用哪个引擎。

当新版本发布时，e_pd_version_max 加一， e_pd_version 保持不变，只能人为修改。这样便于做测试。

这一部分没有什么特别的点，实现起来不难。

流程实例信息表

pi 表示 process instance

字段

作用

id

自增 ID，作为流程实例 ID

pd_id

流程 ID

e_pi_id

流程引擎的流程实例 ID，用于与流程引擎的实例保持关联

e_pd_key

底层流程引擎的流程名称，也用于翻译后作为名称展示

e_pd_version

当前使用的流程版本号

e_pi_activity_name

当前所在的节点名称

name

流程实例名称，由创建人填写

creator

创建人

source

创建来源，其他系统可调用 Restful API 创建流程实例

priority

优先级

handlers

处理人，可以有多个

status

当前流程实例状态

tags

标签，作为补充信息

流程实例状态：

类型

作用

创建

流程实例刚创建

待提交表单

需要等待用户提交表单

等待执行器

自动化执行步骤，需要等待 External Task Client 获取任务

执行中

任务执行中

出错

执行时报错

暂停

暂停流程实例执行

结束

正常流程结束

终止

人工关闭流程或者其他非正常结束关闭

自增 ID：

一开始打算直接用 UUID 作为流程实例的 ID，但产品经理说使用跟原系统一样的数字 ID 比较好，用户用起来也比较习惯。

举个例子，这个有点像 B 站以前用 AV 号而现在用 BV 号给用户带来的区别。

由于流程实例本身有权限控制，用自增 ID 也爬不了多少。就算爬了也没有什么影响，所以还是保留了自增 ID，并且初始 ID 设置为比当前流程实例多一个数量级，以保证迁移过程中不会出现 ID 冲突。

当前所在的节点名称：

用户在查看列表的时候想直到流程实例的进度，可以用这个名称展示给用户。

另外还可以作为重启流程实例时跳转的节点。

创建来源：

流程实例有时候碰到问题会回退给创建人，这就要求创建人必须是一个具体的用户。而如果不标注来源，则该具体用户可能无法获取相关信息来解决问题。

优先级：

这个字段用于给 External Task 标注优先级，优先级越高越先执行。

处理人：

分为两种情况：

填写表单的人

自动化步骤出现一些意外的问题，将会转交给相关运维人员处理

流程实例状态：

对底层引擎流程实例状态的缓存，用于列表查看时减少对底层引擎的查询。

但是什么时候更新这个状态就成了一个问题。如果没有及时更新，会给用户带来疑惑。比如说流程实例在底层引擎已经结束了，但是这个状态却不是结束状态。后续会对此做详细说明。

标签：

目前作为一些业务信息的补充，仅用于展示。

流程节点日志表

这个信息用于展示哪些节点执行过，以及相关时间点和输出信息。

由于各种数据或者业务问题，或者确实是正常的执行但用户误认为流程实例的流向有问题，这个时候可以