下载掌阅APP，畅读海量书库
立即打开
本章将讨论以下内容：
• 介绍一种可执行流程建模语言，即业务流程模型与标记法（Business Process Model and Notation, BPMN）。
• 解释流程模型是如何执行的，以及流程模型与代码是如何组合的。
• 概述研发流程解决方案时的注意事项。
上一章我们直接快进到了可执行流程，现在往前退一退，详细了解跳过的部分。首先从流程建模语言开始，你可以通过它设计在工作流引擎上运行的流程蓝图。它可以表达一系列任务以及围绕任务的那些“螺丝螺母”，比如决策点、并行任务和同步点。
不同的工具可能会使用不同的流程建模语言。在本书中，我将使用BPMN，原因主要有两个：第一，它是现行的标准；第二，它很好用。在5.2节中我会详细阐述它，但这里，我需要介绍一些基础知识。
当然，并非所有流程模型都需要在引擎上执行，有时你可能需要画一个图来理解或记录某些逻辑。虽然这是一个很棒的用法，但不是本书的重点。尽管如此，用于讨论或记录的业务流程图可以帮助大家理解工作流引擎，了解使用它实现流程自动化的巨大潜力。只需要确保你使用的是可执行的流程建模语言（比如BPMN）即可。
BPMN流程如图3-1中的例子所示。
图3-1：BPMN流程
BPMN流程同时也是一个XML文档。在日常工作中，你可能永远不需要查看这个XML。尽管如此，我还是要在这里展示一下它，我向你保证，其中既没有魔法，也没有隐藏的复杂性：
工作流引擎和建模工具所需的信息都已经包含在XML文档中了，且可视化定义所包含的信息也足以让人（包括非技术人员）快速理解它。BPMN模型是一个同时包含了源码和文档的制品。这种二元性使得BPMN非常强大。
BPMN是流程建模和执行的行业标准。它最初创建于2004年，在2011年进行了重大改进，由国际标准化组织（ISO）发行，编号ISO/IEC 19510: 2013。由于不断变化版本会削弱标准化的优势，因此在那之后标记一直刻意保持不变。你可以在对象管理组织（Object Management Group）的网站 [1] 上找到PDF格式的规范文本。
今天，许多公司都采用了BPMN。关于它的书籍和资料有很多，大学课程中也会教授BPMN。许多现代工作流厂商都遵守BPMN，没有能与之竞争的标准。
我建议每一个进入流程自动化领域的人都学习BPMN。它可以帮助你理解流程自动化相关的范式，即便你决定使用的工具用的是其他类型的流程建模语言。关于不同建模语言的讨论可以在5.2节中找到。
下面的章节涵盖了BPMN流程建模中最重要的范式。学习了这些内容，你就能理解本书中的示例以及随书发布的代码，同时也帮助你理解可执行流程模型的机制和能力。
本书没有深入讨论BPMN，只涵盖了该语言的一个子集。有很多可用的资源，在本书的网站
[2]
上可以找到入口。
首先，每个流程都需要一个起点，这就是BPMN中的开始事件。每启动一个新的流程实例，都会在这里开始。同理，结束事件是流程结束的地方，如图3-2所示。
图3-2：流程的开始事件和结束事件
为了更好地理解流程，我们要先理解token。
根据BPMN规范，token是“一个虚拟概念，用来辅助定义正在执行中的流程的行为”。本质上是token在BPMN中实现控制流。
你可以将每个流程实例当作在流程模型中运行的token。流程启动时，在开始事件处生成一个token。如图3-3所示，每完成一步，它都会沿着流程路径流向下一个任务。当token到达结束事件时，流程实例的生命周期就到达了尾声。
图3-3：BPMN流程
每当遇到决策点时，token都需要准确地走向某一条路径。当token到达结束事件时，就会被销毁，流程实例也将结束。每个流程实例启动时都会创建一个token，所以能看到多个token同时流过模型。
工作流引擎通常会保存token的状态，因为它们能准确地描述给定的实例在流程中的等待位置。
你可以将token类比成路上行驶的汽车。在每个十字路口，司机必须决定要继续直行，还是左转右转。道路系统可以对应为流程模型，车辆所选的任意一条具体的路径可以类比成流程实例。只不过，当我们讨论并行路径时，这个比喻就不合适了，因为你不能瞬间克隆一辆汽车，让它在继续直行的同时又向左转，但对于流程模型中的token，你可以轻松地做到这一点，详细内容会在3.1.5节中谈到。
BPMN顺序流（sequence flow）定义了流程中每一个步骤发生的顺序。在BPMN的可视化定义中，顺序流是两个节点的连线，箭头的方向体现了它们的执行顺序。
任务是BPMN流程的基本元素。在BPMN流程中，任务是一个原子的工作单元。每当token到达任务的位置时，token都会停下，直到任务完成。之后，它才会沿着顺序流流出。
任务粒度如何选择取决于建模流程的人。例如，处理订单的动作可以建模为一个任务，也可以分为支付确认、提取货物和发出货物三个独立任务。10.5.1节将讨论如何准确地划分任务。
BPMN定义了各种任务类型，这些类型对工作单元的概念做了细化。
服务任务（service task）是很重要的一种类型。当token经过服务任务时，将会执行一些软件功能。通常来说是调用其他服务、微服务、方法、函数或者架构。在2.3节中看到，你可以简单地用惯用的编程语言实现胶水代码连接到这样一个服务任务，如图3-4所示。
图3-4：服务任务会触发一些功能，最常见的是执行一些代码
另一种任务类型是人工任务，如图3-5所示。在这个例子中，有一家小公司，其取货、运货都简单地由人工来完成。流程描述了一些需要人工完成的工作，并在任务列表中为取货、运货的人生成待办事项。工作流引擎将等待他们勾选待办事项。
图3-5：包含服务任务和人工任务的BPMN工作流
其他常用的任务类型还包括业务规则任务（business rules task）和脚本任务（script task），前者可以利用决策引擎对规则表进行计算，后者可以使用工作流引擎定义的脚本语言在引擎中执行脚本。
通常最困难的部分是定义你的任务及其顺序。一旦这些清晰了，你可能会先从人工任务开始制作原型（一个只能“点点点”的模型），也可能在生产环境中发布第一个迭代。随着任务不断地自动化，你会逐步替换这些人工操作。
网关与顺序流都用来路由token，不过它有比普通顺序流元素更复杂的工作模式。排他网关（exclusive gateway）会基于数据从多个顺序流中选择其中一个。在图3-6中你能看到一个例子，只有选择了预付款的方式才会进入“支付确认”任务。
图3-6：一个由排他网关决定输出流的BPMN流程
我们暂时先不讨论这个决定应该由订单履约流程处理，还是由支付任务处理。这个问题在第7章会有更详细的解答。
并行网关为了激活多个顺序流会生成新的token。比如，你可以在支付成功前决定是否购买，如图3-7所示。
图3-7：包含并行网关的BPMN流程在并行工作
需要重点说明的是，这并不一定意味着任务在同时运行，它不是多线程中讨论的并行。流程是与等待相关的，所以“并行”的含义基本上是说，你可以在某条路径等待时在另一条路径上做些什么。
BPMN中的事件代表发生了某件事情。一个流程可以通过“捕捉”事件来对事件做出反应。有个很好的例子来说明这些，计时器事件单纯地在等待设定好的时间的到来。在图3-8中，你可以看到使用计时器事件的两种不同的方式。
第一个计时器在顺序流中，它表示流程要在计时器事件这个点上等待一天（比如，等待可撤销时间到期）。
图3-8：包含计时器事件的BPMN流程
第二个计时器是边界事件。在这种状态下，只要流程还在这个任务中，它就能响应这个事件。具体到这个流程里，它表示支付成功前我们可以等待5天；如果到期没有支付成功，工作流引擎将取消当前的任务（支付确认），并流向另一个顺序流再结束这个流程（当然，这可能不是处理支付延迟的最佳业务方案）。
图3-9中的例子介绍了另一个重要元素，消息事件。
图3-9：包含消息事件的BPMN流程
消息事件从工作流引擎外部发送到流程实例中。这个事件可能会触发一个新的流程实例，也可能让现有的实例继续执行。
如果开发者熟悉消息代理，可能会对消息事件有一些困惑，因为人们往往会把BPMN消息事件与消息代理联系在一起。事实上，BPMN消息只是指来自工作流引擎之外的触发动作。从技术上来说，它的可能性非常丰富，可能是来自你服务里一个简单的REAST API调用，也可能是来自消息代理或来自事件代理。
让我们把这个概念再具体化一点，假设你需要让一个流程响应消息代理中的消息，通常会编写一些胶水代码来和它建立连接，如图3-10所示。当然，一些厂商也为常见的场景提供了开箱即用的连接器。
消息事件也经常与事件子流程结合使用，这样你就可以在收到消息时中断流程实例，并且与流程实例当前等待的任务无关。
以图3-11为例。如果收到取消订单的请求，就要立即中断订单履约流程，无论我们是刚要开始收款，还是已经要发货了。在第9章中你还会读到，在这种状况下要采取什么策略恢复一致性，比如退款。
图3-10：你需要通过服务中的代码将工作流引擎与你的“世界”相连
图3-11：包含事件子流程的BPMN流程
[1] https://www.omg.org/spec/BPMN 。
[2] https://ProcessAutomationBook.com 。