BPMN Process Token与Gateway——Camunda Workflow 开发实践（二）
前言
最近工作在用Camunda搞Workflow，认识到了一种全新的程序设计理念。它将程序分为两种：Task和Process。Task只提供服务，Process只负责流程，它俩彼此并不知道且不关心对方的存在，实现了业务流程与代码的解耦。
接下来，我以自己浅薄的碎片化知识，来讲下它是怎么玩的。
Notes：Camunda 支持Java和JS，以及REST Api。
开发环境
- 按照官网介绍安装Camunda (流程引擎) localhost 登录地址
- 安装Camunda Modeler（BPMN 流程编辑器）
- Postman
BPMN文件也可以用VS Code之类的工具打开，它其实是XML。
排他网关
上图菱形中间有个X的是一个排他网关，排他指的是它只会选择一个出口（only one sequence flow is selected ）
正如上图所示，每条线都加了对应条件(else 表示默认)，
- 假如满足多个条件，它只会选择最先定义的那个。
- 假如没有满足任一条件，它会选择else；如果没有定义else，会导致异常。
Notes：假如排他网关有多个输入，那么满足其中一个就会往下走，不会等待其他。
包容网关
上图菱形中间有个⚪的是一个包容网关。它的出口可以同时满足多条线的条件，并且会fork流程，满足条件的线会并行得到执行。
Notes：包容网关有两个输入(Join)，这时要分情况来判断。
假如上图paymentReceived = false，而shipOrder = true，那么两个条件都满足，这时Ship Order 和 Receive order两个User Task 都会被激活。此时包容网关会等待两者都完成才会往后进行。
假如paymentReceived = false，而shipOrder = false，那么只有Receive order 会被激活。此时包容网关只会等待Receive order完成。
官方原文是： the gateway will first join all incoming sequence flows that have a process token. Process Token是一个比较抽象的概念，我后面会写一个博客专门来学习。
并行网关
并行网关的出口(outgoing sequence flow)是不能带条件的，每条线都会并行得到执行。
并行网关也会等待所有条件到达才会往下执行，但这里有个坑。
Notes：并行网关在等待的时候，只看到达的sequence flow数量！也就是说，假如Receive payment任务执行两次，那么它就不会再等待Ship order，而是直接往下进行。如果有流程回退操作，需要考虑这一点。
the gateway triggers as soon as the following holds: The number of arrived tokens is equal to the number of incoming sequence flows. It is not required that a token arrives on every incoming flow.
用户任务
用户任务通常是一些需要人工确认(confirm)的任务。当我们的流程实例(Process Instance)激活了一个用户任务之后，我们可以直接在Camunda Tasklist面板来结束它，当然你也可以用代码实现。
Notes：先Claim，添加需要的Output Parameters，然后Complete。
服务
Service Task 通常用来执行外部任务，也就是需要程序员实现的部分。使用Java代码可以直接监听Service Task的创建事件并进行逻辑处理。比如增加一条审批记录，或者帮财务完成自动打款。
接下来，我们讲一下如何用REST Api来完成：Camunda Docs
打开Postman 按顺序调用以下接口：
Get List -> Fetch and Lock -> Complete
每个Service Task 都需要用workerId先lock才可以，而且应该指定一个lock时间, workerId 可以是任意字符串，但是Complete的时候，必须使用相同的workerId 才可以结束。
Message Event
上面给大家演示了下一个简单的Message Event怎么创建的，这个Message Event就和服务关联起来了。你可以自行设置收到Message Event之后的Workflow。
当服务已经激活时，使用Postman调用：Event Subscription | docs.camunda.org查询当前服务正在监听的Events, 你可以看的定义的Message Event，然后使用 Message | docs.camunda.org
来模拟一个事件，当前Task收到事件之后，会执行事件逻辑，而忽略其他出口。
Notes：Postman 使用 basic auth模式进行身份认证即可。
开启一个Workflow Instance
在Camunda Modeler画好workflow，起个名字，点左下角Deploy。
到 点右上角Start Process，选择已部署的workflow，
Add Variables: 添加所需要的变量
然后到 Camunda Cockpit | Dashboard就可以看到process实例创建成功了。
