1.3 工作流引擎和可执行流程模型

那么，除了硬编码的工作流逻辑或自研的工作流引擎外，是否还有什么替代方案呢？你可以使用现有的工具，例如，本书网站[1]上精选的产品列表中的某一个。

工作流引擎会自动控制流程。它允许你定义并部署流程蓝图（蓝图是以特定建模语言描述的流程定义）。部署流程定义后，你可以启动流程实例，工作流引擎会跟踪维护它们的状态。

图1-2展示了前面提到的支付例子的流程。流程在有支付请求时开始运行，如流程模型中的第一个圆形图标（即开始事件，标记流程的开始）所示。之后，它仅经过一个服务任务，图标为齿轮。此服务任务将执行对外部信用卡服务的REST调用。在第2章中，你将学习到具体的实现。而现在，简单地假设你已经为此编写了一些正常的代码，即胶水代码。服务任务执行结束后，流程进入结束状态，如图1-2中粗边的圆形所示。

图1-2：一个非常简单的流程，它已经可以处理信用卡例子中的大部分请求

图1-3通过一些伪代码展示了如何使用此流程模型实现支付服务。首先，你需要编写一些代码来响应外部消息。例如，调用REST端点来收集支付请求。然后，这些代码将使用工作流引擎提供的API启动一个新流程实例。此流程实例由工作流引擎进行持久化，图1-3通过关系数据库可视化了这一点。本书之后的内容会介绍不同的引擎架构、持久化类型及部署场景。

图1-3：工作流引擎

下一步，你要编写一些胶水代码执行信用卡付款。这些代码类似于回调，流程实例启动后，在运行至信用卡付款任务时会自动执行。理想情况下，信用卡支付会立即被处理，流程实例随后结束。你的REST端点甚至可以向客户端返回同步响应。但在信用卡服务中断的情况下，工作流引擎可以安全地暂停任务，等待信用卡服务恢复后触发重试。

我们刚刚谈到了工作流引擎的两项最重要的功能：

• 持久化状态，支持任务暂停。

• 任务调度，比如说重试。

根据工具特点，可能需要用特定的语言编写胶水代码。但也有一些产品允许使用任意编程语言，因此，如果你下定决心要整理荒野大集成的项目，也许还能复用大部分代码，只需利用工作流引擎进行状态处理和调度即可。

当然，许多流程的复杂度远远超出了这个简单的例子。在检索支付状态时，流程模型可能需要解决很多业务问题。例如，如图1-4所示，该流程会对过期的信用卡做出反馈，并等待用户更新其支付信息。

图1-4：支付流程可能会迅速复杂化

到目前为止，这个支付流程更像是一个集成流程，而不是典型的自动化流程。不过我喜欢从这样的流程开始讨论，因为它有助于技术受众了解工作流引擎的核心功能，我们将在下一节展示一个更典型的业务流程。