ProcessToken

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

起源

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

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

Activity

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

CompleteUserTask

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

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

我们可以用同样的操作来完成TaskC和E，那么伴随着ProcessToken的消亡，这个ProcessInstance便也结束了。

ProcessToken的分裂与同步

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

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

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

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

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

ParallelGateway与ProcessToken

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

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

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

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

生命周期

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

一个ProcessToken产生于StartEvent，消亡于EndEvent。

当我们结束TaskE之后，ProcessInstance并没有结束，因为TaskD依然存活。

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

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

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

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

InclusiveGateway与ProcessToken

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

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

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

当我们再次CompleteTaskB之后，TaskE被激活，证明包容网关也是需要满足数量的ProcessToken到达才会被触发。

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

总结

ParallelGateway会根据incomingsequenceflows的数量，来决定需要等待的ProcessToken个数。

而InclusiveGateway则根据incomingsequenceflowsthathaveprocesstoken的数量，来决定需要等待的Token个数。

HoldOn

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

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

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

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