BPMN Process Token与Gateway——Camunda Workflow 开发实践

Process Token

Process Token 是BPMN当中的一个理论概念，它像是能唤醒Activity的灵魂。

起源

每个Process Token都起源于Start节点，当我们开始一个Process时，它的Process Token就创建出来了。

不同于身份认证当中的Token，Process Token不包含任何信息。如下图所示，当StartProcess之后，一个蓝色的1便出现在了Task A 的左下角，这是Camunda为Process Token做的可视化。

Activity

简单来说，workflow当中的每个圆角矩形都代表了一个Activity。在Process Token到来之前，它们都处于Inactive状态，当Process Token到达之后，它们会被激活成Ready状态，比如下图中的Task A。

Complete User Task

我们可以在Camunda 的TaskList 面板来结束一个User Task, 并且可以让它传出一组变量到后面的流程。

可以看到当设置Price 为50时，Process Token经过排他网关来到了Task C，此时Task C处于Ready状态。

我们可以用同样的操作来完成Task C和 E，那么伴随着Process Token的消亡，这个Process Instance便也结束了。

Process Token的分裂与同步

当我们将上图中的排他网关替换为并行网关之后，便可以观察到Process Token分裂的结果。

并行网关的特性导致了Task B、C、D同时被激活，Process Token此时也变为了三个。

其实分裂这个词并不准确，因为Process Token本身并不包含信息，而且分裂之后的Token依然可以唤醒Activity。因此我们可以认为，并行网关的作用其实是fork了当前的流程。

上图当中，并行网关会等待三个Process Token都到来才会继续往下进行。

注意并行网关等待的是Process Token的数量。假如workflow当中有回路，Task B被激活两次并完成，Task C完成，而此时虽然Task D还未完成，但并行网关已经满足了触发条件，下游的Task E将被到来的Process Token激活。

Parallel Gateway 与Process Token

在Task B之后，我添加了一个包容网关inclusive-gateway，并且添加了一条回路。当Price <= 50时，Task B将再次被激活，并且无论怎样，包容网关每次都会fork一个Token到下游的并行网关。

接下来，我们先完成Task B并且让Price小于50, 然后再完成Task C。

我们可以清楚的看的下图当中，下游的并行网关处显示已经有两个Process Token到达，分别来自Task C和Task B，而Task B因为Price < 50， 所以再次被激活。

当我们第二次以Price = 60来结束Task B之后，可以看到并行网关因为收到三个Token而被触发，下游的Task E也因此被激活，此时Task D还在Ready状态。并行网关并不关心是否还有未到达的Token。

生命周期

借助上个例子，我们正好可以观察下Process token与Process Instance生命周期的关系。

一个Process Token产生于Start Event，消亡于End Event。

当我们结束Task E之后，Process Instance并没有结束，因为Task D依然存活。

当我们Complete Task D之后，我们可以认为此时的ProcessInstance陷入了崩溃状态。

因为并行网关还会等待三个Process Token的到来，显然这里的条件已无法满足。

我们需要手动销毁这个实例。

Start Event 每创建一个Process Token，便意味着创建了一个Process Instance。Process Token会分裂，会同步，但不会离开Process的边界，它不会从一个Process跳到另一个Process。

Inclusive Gateway 与Process Token

包容网关的outgoing策略非常好理解，这里不再赘述。我们重点来看下它的incoming策略与并行网关的区别。

如图所示，将下游的并行网关替换为包容网关。

让我们以同样也的步骤，将Task C完成，Task B以Price = 20执行一次。我们可以看到，与并行网关一样，包容网关也会等待Process Token的同步。

当我们再次Complete Task B之后，Task E被激活，证明包容网关也是需要满足数量的Process Token到达才会被触发。

但是当我结束Task E，然后再Complete Task D之后。包容网关并没有像并行网关那样，继续等待三个Process Token的到来，而是直接被触发，将Process Token 传到下游。

总结

Parallel Gateway会根据 incoming sequence flows的数量，来决定需要等待的Process Token个数。

而Inclusive Gateway则根据incoming sequence flows thathave process token的数量，来决定需要等待的Token个数。

Hold On

我们再来思考下面这种情况，假如Task C和Task D先完成，而Task B还未完成且结果未知，包容网关会有什么样的表现呢？

包容网关依然会等待这个前途未卜的Process Token的到来，我们将Task B以Price = 20的参数结束，它的Process Token也将会转向上方的End Event而消亡。

那么下游的包容网关会因为它所等待的Process Token的消亡而触发吗？

答案是不会，workflow会再次陷入崩溃状态。。。

总结

写到这里也结束了，在文章最后放上一个小小的福利，以下为小编自己在学习过程中整理出的一个关于 java开发 的学习思路及方向。从事互联网开发，最主要的是要学好技术，而学习技术是一条慢长而艰苦的道路，不能靠一时激情，也不是熬几天几夜就能学好的，必须养成平时努力学习的习惯，更加需要准确的学习方向达到有效的学习效果。

由于内容较多就只放上一个大概的大纲，需要更及详细的学习思维导图的 点击我的Gitee获取。
还有 高级java全套视频教程 java进阶架构师 视频+资料+代码+面试题！

全方面的java进阶实践技术资料，并且还有技术大牛一起讨论交流解决问题。