ESB - 业务流程关系
5.00/5 (3投票s)
ESB 如何高效支持业务流程
引言
前段时间，我写了几篇文章，探讨了ESB（企业服务总线）的各个方面。这些文章讨论了在使用发布-订阅机制分发应用程序之间的事件信息时可能需要考虑的问题：消息应该是什么样的？路由应该由什么来控制？如何记录发布-订阅机制中的活动？
在本文中，我将背景化并回答以下问题：集成如何与业务流程结合，以及业务流程如何确定所需的集成类型？这是从稍微更高的企业架构层面来审视事件驱动的集成。
业务流程？
当我尝试以通用方式思考业务流程时，我想到了波特的价值链。它基本上指出存在一个主要生产过程和一些支持过程，例如销售和簿记。为了更明确地说明ESB如何有效地解决集成需求，我想介绍一个我大约10年前创建的流程模型。它反映了波特模型中的思想，但在解释流程之间可能存在的关系方面更加具体。
该模型定义或描述了三个流程：报价-现金、供应和生产。
看起来是这样的：
用普通的话来说，该模型关注三个问题：我们如何生产产品？我们如何销售产品？以及我们如何确保客户获得他们所支付的东西？
在提供一些网络产品的SaaS业务中，你会将服务视为产品，“报价-现金”（Q2C）流程是你的订阅如何创建的，可能也通过网站创建，而“供应”是你的系统如何知道客户应该被授予访问权限的。
有趣的是，该模型已被证明适用于非常不同的公司类型。最近，我用它来描述一家出版公司的基本应用程序关系。我称之为我的标准H模型——尽管它是一个侧卧的“H”。
更详细地说，这三个流程是
- 报价-现金流程，涉及销售和相关过账，在这个狭窄的上下文中处理资金。它是典型公司财务流程的一小部分，通常还包括支付流，无论是来自网络前端的采购流还是来自已付发票的收款。
在此流程中，第一步是创建订单。这可能是在受控的客户流程中，即通过Salesforce CPQ中的报价流程，或者可以通过在线订单表单或任何其他购买流程（例如移动应用中的应用内购买）启动。无论如何，订单都会创建并提交给电子商务应用程序，该应用程序创建实际订单，捕获付款，可能创建订阅、发票以及与订单相关的任何其他内容。然后，将购买详情报告给ERP系统，其中包含账簿、收入确认、年度报告等所需的详细信息。
-
供应流程，该流程在电子商务系统中创建订单后启动。此流程旨在确保客户获得他们购买的产品，例如，通过以用户权限的形式表达购买，这可能通知某些生产系统，告知用户应允许访问什么。它也可能是发送到MES系统（制造执行系统）的生产订单。因此，供应流程的最后一部分是生产系统的某个部分——在Web应用程序中，它将是应用程序前端。
- 生产流程，由某个输入系统或后端、业务逻辑和表示组件以及某个交付点组成。在Web应用程序环境中，这些组件可能是CMS、Web服务器应用程序和客户端浏览器。
为了更接近流程、集成和集成类型，我将在标准H模型中添加一些箭头和对象，以指示可能在组件之间流动的数据类型。我还会更改一些组件的名称：该模型是通用的，重要的是使用它来在企业中形成对流程的心理图像
事件驱动还是请求-响应？
看看这些箭头，哪些关系可能是事件驱动的，哪些是请求-响应类型的，这相当明显。考虑这些流程，有些流作为事件的结果发生是有道理的：CRM（客户关系管理）系统中订单的创建导致订单被发送到电子商务系统，而另一些则由请求触发：用户请求某些数据需要API询问授权服务，如果该用户有权获取它。
只有事件驱动的集成才与ESB环境相关，但这恰好也是图中大多数集成点的质量。在您的产品是Web应用程序的环境中，您可能需要考虑这样一个事实：后端的大多数集成都是事件驱动、单向、异步的，而涉及客户的集成往往是请求-响应、双向和同步的。
我已经在其他文章中讨论了ESB的主要特性，其核心思想是ESB是一个应用程序可以发布数据供其他应用程序订阅的地方。当对象发生更改时，应用程序可以发布对象的最新状态（最好是发布整个对象），需要了解更改的应用程序可以订阅该消息并相应地更新自己的数据，而无需进一步操作。
但发布-订阅基础设施究竟应该是什么样子，会涉及哪些组件？
我之前建议ESB应该提供
- 接收位置
- 路由机制
- 一种转换机制
- 传递机制
这些组件构成了从应用程序A到应用程序B传输和转换消息的基础
然而，这种简单的设置（您只需要创建Web服务端点和转换/交付组件——消息队列是现成的）是不够的，如果您想为企业范围内的关键数据对象（如订单、订阅、用户、产品、支付等）创建分发和重用基础设施。
在之前的一篇文章中，我主张应用程序应始终在自己的交换机上发送消息。我想补充一点，我认为应用程序应以适合甚至标准化的格式发送消息。对于某些应用程序而言，直接订阅这些消息并自行处理特定格式转换可能是有意义的。显然，由于没有对源系统的抽象，这种集成就变成了一种异步的点对点集成，但这在例如迁移场景、中间解决方案或用于日志记录或监控中可能是有意义的——简而言之：随着源系统消失而消失的集成。
当然，这里需要讨论很多关于契约和版本的问题——如何让交付的消息发生变化，同时仍然避免这些变化破坏下游订阅者逻辑。我已经在我的其他文章中提到了这一点。
然而，在企业环境中，您可能希望使用更规范的格式来处理您的关键对象，例如，允许更多应用程序生成相同类型的消息：如前所述，您可能既有销售人员在销售组织中创建的订单，也有客户自己通过您的网站创建的订单。对于订阅系统来说，哪个应用程序创建了订单不一定重要，因此您可能希望为消费应用程序提供一个规范的订单格式供其订阅。
总结一下，我建议
- 消息以源应用程序特定格式发布到源应用程序专用交换机
- 消息可以转换为规范对象消息并发布到流程专用交换机
这表明了一种稍微复杂的设置，但正如之前文章中提到的，这些组件可能几乎是通用的，只是在例如转换逻辑上有所不同。设计看起来像这样
请注意，在上面，我省略了单独的交付组件。此职责可以是转换组件的一部分，但为了实用（即能够拥有完全通用的转换组件），将这两个职责分开到各自的组件中可能更实际。
将设计应用于上述流程，一个实现可能如下所示——作为起点
有了这样的环境，企业中的任何应用程序都可以设置自己的队列，以侦听描述发布应用程序中已更改对象状态的事件消息。图中说明了几个这样的消费者，以展示例如ERP系统如何监听发票，或业务逻辑组件如何监听后端数据输入。
通常，你会看到API被构建成这样的消费者，以便添加一个请求-响应选项，让应用程序能够请求，例如，给定发票ID的发票数据。API将是简单的缓存机制，由一个转换和插入组件、一个存储消息的数据库和一个从数据库检索对象的API端点组成。
如果我们将它看作某种SaaS应用程序，那么这种API的例子可以是授权服务和生产流程。转换组件可以负责将转换后的消息插入API数据库。
关于模型的一些思考
我花了很多时间在模型上，从Yourdon到UML，我坚信它们。事实上，我相信我们理解世界的方式是通过模型：我们不理解现象本身，我们创建思维模型来表示它们，并理解它们的特征和属性。模型是我们理解事物的核心。
在创建模型来传达对像我在这里讨论的这类系统的理解时，我认为它们有两个重要的标准
- 它们必须是直观的。使用像UML这样的标准在模型中嵌入的信息密度方面有一些优势：对象可以采用不同的形状来表达其类型，关系也可以具有形状和属性来做同样的事情。然而，要使其奏效，需要阅读模型的人了解所有这些。如果他们不了解，额外的信息就会变成噪音，降低可读性。由于大多数人不会每天都看UML模型，我倾向于只使用两三种形状来制作模型：气泡、方框和箭头。箭头表示流向，方框可以包含任何类型的逻辑、函数或必须执行的任务。大多数人无需介绍就能理解这些。
而且仍然可以在形状上添加你直观阅读的属性：在上面的模型中，我在交换和队列框中添加了线条来表示它们的功能，消息队列组件前面的网络服务很小，表示它只是一个接收http请求的地方——那里几乎没有逻辑。
- 模型的范围必须正确。过于简单的模型，例如“我们生产东西然后出售”，是没有意义的。我们都知道这一点。另一方面，包含大量方框和路径的大而详细的模型也很少有意义。我有时使用复杂的UML图来阐述，例如复杂的采购流程，但它们主要只是为了我自己理解流程，而不是为了沟通正在发生的事情。如果更接近代码，建模就很少有意义了——代码通常是无论如何都应该查看的地方。
您希望达到一个最佳点，即模型易于理解，同时仍能提供信息——记录设计决策，封装角色和职责等。上述两个模型（据我所知）在不同层面做到了这一点：一个提供了功能总体布局的概览，而另一个则让您能够理解，为了例如添加特定消息的消费者，您需要构建哪些组件，以及将它们放在何处。
然而，关于模型最重要的事情是创建事物的共同形象。当我们有了共同形象时，关于模型范围相关问题的对话就会变得简单得多，也精确得多。
历史
- 2023年8月1日：初始版本