camunda 流程执行追踪_流程引擎为什么选 Camunda

2019 年初我在重新设计我们组负责的流程系统时，选择了 Camunda 流程引擎，并基于该流程引擎实现了一套适配方案。以前就想做一次总结，但总拖着。

最近公司中台在做流程引擎选型，相关同事找我了解 Camunda 以及基于 Camunda 的应用方案。经过我一番说明，对方表示收获很大。我想着也是时候把这些经验写下来了。

我把内容分为两部分：

Camunda 自身的介绍(为什么选 Camunda ？)

基于 Camunda 的一种适配层实现方案

这一篇只包括第一部分的内容。

为什么选 Camunda ？

做选型的时候，需要说明我们需要什么样的功能和不需要什么样的功能。

我们项目的特点是什么？

流程以自动化为主

极少数节点需要人工操作(审批、补充信息)

使用 PHP 作为业务层语言

流程引擎必须作为一个服务存在，不能为了使用流程引擎而更改语言。

必须有一个机制，使得流程实例执行自动化操作时，请求业务层 API。

流程同一时间最多只有一个节点在执行

不需要支持并行加签、多分支同时执行、单节点多并发执行。

可以强行跳转到其他节点执行

由于业务的不确定性因素，难以或无法通过优化流程来预先规划好各种情况下的分支。

因此需要在自动化步骤出现某些无法预知的情况时，由运维修改流程实例的状态，跳过当前节点的执行或者回到前面的节点重新执行。

可以重启一个处于结束或终止状态的流程实例

同样是业务的要求。

支持多分支

有些流程引擎只能选择 “是” 或者 “否” 这两个分支，无法支持多种情况。