Camunda Workflow BPMN 入门开发实践

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实例创建成功了。