分毫不差：利用 Bluemix 和 IBM 集成产品组合构建一个 ISO 20022 支付平台

支付系统需要实时维持大量工作负载。这些面向业务的实时系统每天都有一些在线交易要处理，它们需要一些 API 来集成可扩展性和可靠性（这是该系统的核心），并满足大部分 API 经济需求。

在平台即服务 (PaaS) 和 SaaS 中提供的弹性能力和网格计算对于实时支付业务应用程序非常有价值，因为它们具有 “小处着手，大处着眼” 的范式。此外，业务接口不仅要求零停机时间，还要求具有较短的开发周期，可以对不断变化的需求做出反应，在这里，我们所指的需求是立即支付消费的需求。IBM® Bluemix® 为可靠的服务即平台提供了这个跳板解决方案，降低了实现数字化改造的门槛。

本教程将介绍如何使用 Bluemix 服务和 IBM Integration Bus 组件在常见的大数据事务中实现实时互动。例如，您将学习如何构建一个符合国际标准化组织 (ISO) 20022 消息标准的支付系统。该系统适用于客户对银行支付应用程序，并提供在结算银行、税务机关或下属信用社等支付代理之间的额外运营服务。该示例中的组件包括 IBMCloudant®、Node.js、StrongLoop® 运行时、Businesses Rules for Bluemix，以及 IBM Integration Bus 和 IBM MQ 集成产品组合。

混合云模型配置

在本教程中，您将学习如何通过使用云 API 网关、业务规则、NoSQL 数据，以及内部部署的消息引擎，有效地配置混合云模型。总之，这些资源适用于安全性、转型和相互关系等关键企业能力。

通过使用 Bluemix 中的安全模块，您可以启用公钥基础架构 (PKI) 和数据加密标准 (DES) 的安全策略，防止泄漏云上的信息。这些模块在本地将服务与其安全算法和基础架构绑定在一起，参见图 1 中的示意图。

图 1. 智能混合云支付中心

以下消息模式最适合使用 IBM Integration Bus 和协调支付流程的这个平台：

• 具备 PKI 安全性的消息存储和转发
• 传递给大量收信人的多线程实时消息
• 使用安全授权/拒绝的复制
• 在复制到一个中心点之后，复制到广播消息
• 支付交易异常后消息补充

随着互动参与系统在移动端的普及，并且物联网 (IOT) 参与消费者的交易源选择，支付所需的信息管理面对的是庞大的历史数据。它也是高度事务性和高度安全的，其中被暴露的 API 的服务质量 (QoS) 成为一个关键因素。

数据有效负载的安全性，和灵活、可恢复的流程编排，以及面向集成的 API 管理是至关重要的，有助于实现实时可见的公共系统的战略性增长。新兴的微服务架构更为普遍，以新的方式迅速组成服务，专注于具有高附加价值的代码，让云可以处理规模、一致性和可靠性。

依赖于大量数据的企业都需要复杂的消息协议。他们从构建到部署的 DevOps 过程都要求敏捷性和灵活性，在不断变化的环境中维持生存，并跟上客户的需求。出于这个原因，有一个标准化的信息流很重要。ISO 20022、环球银行金融电信协会消息类型 (SWIFT MT) 和 ISO 15022 等协议是基础，各平台必须符合这些协议，并在中间件架构层内明确无误地融入它们。它们有助于减少受到跨多个地理区域的不断变化和颠覆性技术影响的风险。

支付的 ISO 标准对行业的跨域信息流有益。现在，新的支付平台由多国司法管辖区指挥，以增加金融系统行业内所有参与者的创新。现在，行业标准加速采用常规的策略和常见用例的互操作性（参见图 2）。因此，ISO 等组织的意图是维持数据定义的单一真相来源。他们帮助目标行业中的信息 API 的生产者和消费者用相同的语言进行交流，包括在监管报告和内部沟通中使用相同的词汇。

图 2. 支付平台的用例

但是，他们将使用相同的语言来处理不同的系统上下文翻译。ISO 20022 是用于消息分类的金融服务标准，允许使用互操作性。ISO 20022 的目标是实现 一个针对金融行业通信的 方法、流程和存储库的标准 。由于金融网络中的客户和供应商是异构的，远程消息为交易管理带来了复杂性，包括时间延迟、消息丢失、排序和多阶段确认。因此，IBM Cloud 软件带来的具有消息复制和交付保证的解决方案就非常适合。

然而，专有的 XML 或最大传输单元 (MTU) 模型和标准 ISO 模型的目的不是要减少敏捷性，或者要与后端应用程序绑定严格的关系。相反，对于业务信息模型和数据结构，它们是良好的实践。因此，支付平台需要一个稳健而又敏捷的消息总线来调解和转换紧密分布的消息格式。IBM Integration Bus 是最好的连接技术，作为主要的流程处理引擎，自动调整相邻的模型。这样一来，业务应用程序就可以只专注于消息负载、业务规则和客户数据的相关创新。

阅读： BlueMix 和 StrongLoop 入门

构建应用程序需要做的准备工作

• 一个 Bluemix 帐户
• IBM Integration Service Bus Toolkit
• IBM Operational Decision Manager (ODM) Rule Designer

第 1 步. 在云规则引擎中创建消息传输的决策服务

每日增加运营透明度的策略规则是在处理流程中创建决策点的候选方法。表 1 显示了由 ISO 20022 Message Transport 模型 定义的传输特性的消息规则。

表 1. ISO 20022 Message Transport 规则

要为最佳的面向服务架构 (SOA) 创建决策服务，需要使用 安装 Rule Designer 中介绍的 Rule Designer，将这组不对称的条件转换成决策表（参见图 3）。要在 ODM 中创建决策表，请访问 IBM 知识中心并参阅其中 IBM Operational Decision Manager 的使用决策表 主题。

图 3. ISO 20022 Message Transport 定义的决策服务的决策表

ISO 20022 消息映射：有关 ISO 20022 消息映射实践的详细信息，请参阅 IBMdeveloperWorks® 文章 在支付处理解决方案中实现 ISO 20022 支付初始化消息 ，其中介绍了 IBMInfoSphere® 的映射功能。本教程演示 Bluemix PaaS 的 ISO 标准的集成实践和服务实施。

包含频繁的变更并要求进行业务治理的业务规则适用于决策服务。这些规则包括：税收规则、利率规则、产品供应费，以及权利。

然后，您可以将规则集部署到 IBM Business Rules for Bluemix Service 。在 Bluemix 目录中选择 Business Rules ，并创建一个服务。在 Rule Designer RuleApp 项目中，使用从控制台提供的凭证，连接到 Rule Execution Server 并部署规则（参见图 4）。

图 4. 将 Transport RuleSet 部署到云规则引擎

阅读： 不熟悉 IBM Business Process Management

阅读： Rule Designer 教程

第 2 步. 用 NoSQL 模型创建记录交易系统来提高速度并维持弹性增长

现在，利用 Cloudant 查询创建数据层，帮助减少查找数据文档的往返时间和数量。基于 NoSQL 格式的大数据记录交易系统适用于此目的。这些系统使用了过滤器，仅显示选定的文档属性，不需要复杂的模型。或者，它们可能会显示基于 SQL 的数据库有时需要的深层内联。对于大数据增长，SQL 的增长相对较慢，有时采购和维护的费用昂贵。SQL 系统有时很难适应不断变化的数据建模需求，而且没有巨额投资就很难做到弹性容量增长。

在处理行业标准协议的时候，遵循的是 ISO 标准的规范模型，而不是用于存储数据的 SQL 数据结构。您可以选择多个功能来设置统一的参数，并在大量数据中快速返回特定的数据。这样，随着数量的大幅增长，使用 Cloudant 的业务域 NoSQL 查询就可以利用网格技术的优势。业务对象模型是 REST API 查询的一部分，要求结构良好的响应。

在使用消费者公共 API 时，数据访问是可靠的。Cloudant 视图提供了一种选择特定数据的简单方法，其中，索引可以提高基于文本或 JSON 对象类型的查询速度。这些组件的组合让 Cloudant 数据库即服务 (DBaaS) 可以专注于非标准化形式的数据结构。

利用 Cloudant NoSQL 创建记录交易系统：

1. 创建支付的文档定义。
2. 创建支付交易的视图。
3. 为 StrongLoop API 或其他 API 消费者所使用的搜索创建 find 查询。

来自 C2B 交互的支付借记/贷记交易具有 ISO 20022 结构，如图 5 所示：

• 借方 是订购买家；您从这一方的帐户中记入借项。
• 贷方 为收款的卖家，他们负责接收付款。
• 借方代理 就是银行，资金在这里被取出并转账到借方代理，即卖方的银行。

图 5 示出一个简化的 ISO 数据模型。它显示了 Cloudant 的 JSON 对象文档中的文档关系。这些数据将供那些为了完成借记卡、信用卡或现金支付而创建的 API 服务平台使用。平台通过支付初始化过程读取数据，而该过程由 IBM Integration Bus 中的消​​息流进行协调。

图 5. 支付、代理和当事人的数据企业模型

使用 Cloudant 工具可以轻松创建这个平台的所有视图。图 6 显示了 Bluemix 管理控制台重做支付视图。该控制台包括以下基于 ISO 20022 的文档类型：

• Payment
• Debtor
• Party initiator（客户买家）
• Financial institution（结算方 1）
• Creditor（结算方 1）
• Taxation office（结算方 2）
• Investigation case

图 6. Cloudant NoSQL DB 视图和文档

本教程中的示例在视图中使用了 Apache Lucene ^TM 查询语法，以可靠的格式快速返回数据。具有数据访问对象的索引由 Lucene 结构创建，它包括组合多个字段和特征的能力，如下面的例子所示：

curl.exe -H "Content-Type: application/json"  https://bluemix.cloudant.com/marcdb/_design/customer/_search/customer_index?q=customer_name:marcelo*

第 3 步. 通过用 StrongLoop API 连接到 Node.js的服务，显示支付业务函数

StrongLoop 是用于创建 API 的一个框架，在 Node.js 上面运行。您可以使用 StrongLoop Composer 工具，它会快速自动化对文档源的访问，显示数据库中的数据模型。然后，您可以在 Bluemix Docker 容器中将应用程序部署到 StrongLoop Process Manager。

Node.js 主要充当 Payments initiator、Payments settler 或 Payments receiver 的运行时引擎。由于轻量级平台采用了便携式实时服务器的形式，Node.js 增加了一些内存占用较小的运行时，这是面向物联网应用程序和移动工具（如手机或平板电脑）运行和操作功能齐全、可扩展的便携式框架所必需的。

安装 Node.js 和 StrongLoop

在本教程中，Node.js 被用作 API 服务服务器，具有 StrongLoop 框架和数据访问对象层，以指导企业支付功能。企业支付功能的一个例子是一种交易，在该交易中，借方在开始履行支付义务后发起现金结算。客户可以从便携式移动或电子设备发起支付交易。

类似命令的模式将会运行一些操作，这些操作是由特定于大数据户信息的记录交易系统的用户界面流程请求的。

安装 Node.js 和 StrongLoop 与数据库连接器：

# npm install –g nodejs # npm install –g strongloop # npm install loopback-connector-cloudant

创建 StrongLoop 支付 API

通过使用 StrongLoop，您可以创建 API 来访问 Cloudant 内容，迅速减少测试和开发时间，以可靠的方式支持大型实时交易。利用搜索和查询内容的多种功能，API 可以访问单个数据对象或数组，返回 JSON 类型的文档对象，降低转换和数据传输所需的 CPU、带宽和周期。

结构良好的 API 得以持久的关键在于对商业消费者可见所带来的好处。基于 ISO 20022 标准中的业务域对象的标准协议，创建 StrongLoop API 和模型。

是设计通用 API 还是特定 API 作为微服务的合理权衡

对于是设计特定的 API 还是通用 API 的权衡，在于确定操作业务对象。也就是说，采用一个公认的业务成果作为目标，比如，用一个 API 获得来自贷方的所有付款。然后，您可以集中精力用一个声明式 StrongLoop REST 视图充实请求，并使用底层的 Cloudant 查询去匹配结果。查询语法是灵活的，文档有良好的版本管理，以适应持续的变化。

技术不应该强制企业服务 API 如何显示企业意图，而是应该以可靠的方式补充业务意图。API 越是具体和独立，就越容易维护和操作。利用微服务架构，您可以通过执行敏捷式的生命周期，迭代提供业务价值来实现直接的业务成果，并利用可视化 API 不断达到业务目标。有关微服务的详细说明，请参阅 微服务：这个新架构术语的定义 。

根据 ISO 20022 创建业务对象模型

在这个云应用程序中，该支付平台采用了 ISO 20022 协议将客户（方）支付交易从借方映射到贷方。世界各地的转账结算在处理支付时都使用了 ISO 20022 标准作为主要的数据字典和存储库元数据指引。有关此协议的更多信息，请参阅 每个消息集的 ISO 20022 支付消息定义列表 。

在本例中，客户（方）将执行以下贷记转账功能：

• 发起支付（贷方）
• 支付清算功能（由银行执行）
• 支付结算

使用 StrongLoop 命令工具创建 API 时要考虑到这些关键业务功能。没有创建 ISO 20022 Customer Credit Transfer Initiation 消息集的 Header 部分。这个信息在消息传输层是有价值的，并留在该层，实现可能的恢复和重新排序。

要创建主应用程序，请输入 slc lookback 命令，该命令将创建一个骨架：

# slc loopback payments_platform # slc loopback:model

图 7 显示了 StrongLoop LoopBack 工具，该工具将为 Customer Credit Transfer Initiation API 创建 Node.js 支付平台。

图 7. 创建 StrongLoop 支付平台 API

图 8 显示了持久保存到 Cloudant NoSQL DBaaS 所需的连接器安装。

图 8. 安装用于访问 Cloudant DB 的连接器

阅读： 微服务理论到实践

第 4 步. 用动态 API 创建支付模型

遵循 ISO 20022 模式，当事人具有手机号码、姓名和电子邮件地址等属性。图 9 显示了 Customer Credit Transfer Initiation 消息模式类型和关联规则。在这里，当事人的定义后面就是在惟一客户身份识别中更为普遍的条目。有关模式的详细信息，请参阅 每个消息集的 ISO 20022 支付消息定义 。

图 9. ISO 20022 pain.001.001.06 Customer Credit Transfer Initiation Schema

您为所有 ISO 相关的组件添加模型和属性，首先是当事人，以及账户、代理、支付指令和支付的关系。您可以使用 StrongLoop Arc 工具（参见图 10）来帮助创建模型，添加关系，并将业务功能显示为声明式 REST API。

图 10. 使用 StrongLoop 命令行工具创建支付模型

然后，添加 ISO 标准的关系，如图 11 所示。您可以用声明式定义创建模型属性选项，以保持数据一致性或自动生成唯一 ID。如果想了解更多的属性，请参阅 StrongLoop 的 模型定义 JSON 文件 。

图 11. 创建当事人、支付指令和代理的模型关系

图 12 显示了映射的关系，并配置了外键和主键。

图 12. StrongLoop JSON 支付对象的关系映射

如图 13 所示，可以使用 StrongLoop Arc Composer 工具创建 ISO 模型所需的对象关系映射 (ORM) 层，将这些模型持久保存到 Cloudant NoSQL DB 中的 NoSQL 数据源中。

图 13. StrongLoop Arc Composer 创建模型和持久性

StrongLoop Arc Composer 是用于创建和映射 API 的强大工具。支付应用程序现在会自动显示以下主要功能：

• 发起支付（创建付款指令）
• 付款（从贷方代理创建新的贷记项）
• 结算支付（在借方代理中创建新的借记项）
• 解决支付纠纷（为异常情况创建新的案例管理器实例）

可以使用 StrongLoop Arc Composer Manager 自动创建这些功能，以显示基于之前的关系的 API。

在 Docker 容器中的 Compose Strongloop Process Manager

现在，使用容器目录中的 Bluemix Docker 容器（参见图 14）编写一个 StrongLoop Process Manager。随着支付负载逐渐增大，您可以扩展它，按需增加更多可扩展的组，在工业化的混合云平台上采用一致方式添加选项。

图 14. Bluemix Docker 容器托管 StrongLoop Process Manager

您构建了支付平台，并使用 slc 命令行界面 (CLI) 在本地部署它，然后将其部署到公共 Bluemix 容器：

#slc build --npm  #slc deploy –-service="payments_platform" http://134.xxx.xx.167:8701 ../payments_platform-1.0.0.tgz

或者，您可以使用本地 StrongLoop Build and Deploy 组件来构建该平台（参见图 15）。

图 15. 使用 StrongLoop Process Manager 将 Payments API 部署到 Bluemix

全规模的基础架构中现在已提供该平台，该平台由异地 Bluemix PaaS 托管，基于 ISO 20022 标准，并且可以作为 RESTful API 进行访问（参见图 16）。

图 16. Payments ISO 20022 模型的 Payments API

现在，您可以连接到 Payments API 来启动 IBM Integration Bus 集成，并协调支付客户应用程序和参与的财务代理之间的流程。

第 5 步. 用本地的 IBM Integration Bus 和异地的 PaaS 协调 ISO API 消息

IBM Integration Bus 负责核心路由、传输、转换，而且是 ISO 20022 消息流的保障。它确保所有转发的消息都能成功发送和接收，并监控是否需要处理任何异常情况和中继。IBM Integration Bus 创建消息所需的基础架构，以确保业务成果（参见图 17），同时不会丢失交易。如果交易丢失，可以明确地识别出线索，帮助解决问题。为了实现有效性、效率和可靠性，可以使用 IBM Integration Bus 为 API 消息提供服务。

图 17. 混合的智能集线器 PaaS 基础架构

从实现的角度来看，如图 17 所示的混合智能集线器基础架构具有以下主要组件：

• WebSphere MQ Advanced 充当网关信道和接收方。它拥有 MQ Internet Pass-through，支持远程集群和高级消息安全性 (AMS)，实现基于证书和基于策略的安全性。
• MQ Manager Clusters 用于 ISO 20022 和 SWIFT 消息，采用了全共享存储库配置，以提高可用性和负载均衡。通过这种方式，可以在多个队列管理器中定义队列和订阅，实现可靠性和消息传递保证。
• MQTT 支持长期订阅为在 Bluemix MQTT 组件中运行的 MQTT 客户端启动消息的支付。
• Business Events 作为传入消息的洞察触发器。拥有 ODM 洞察的事件管理程序使用 IBMWebSphere® eXtreme Scale 来支持随时间而增加的消息数据。该组件的网格计算特性使得数据缓存和客户端响应适用于长期增长。
• IBM Integration Bus 消息流 协调传入的消息并对它们进行排序，为管理消息转换逻辑创建操作模式。
• Rules manager 运行并治理实际的业务逻辑，以显示易受变化影响的支付相关的策略。示例包括消息执行的模式、税收政策、计算和 ISO 消息概念模型的强制性准则。
• StrongLoop 和 Node.js 为 API 管理提供一组可扩展的 Docker 容器。
• BPM 是有状态事务管理和异常情况管理的用例进程管理器，在异常情况下修复和补充支付交易。

混合的智能集线器基础架构在支付系统中带来操作灵活性、低耦合，以及业务逻辑的透明度，以防止孤立并提高业务灵活性。

在 IBM Integration Bus 的支付平台协调和排序中，将会使用以下模式：

• 模式 1：具备 PKI 安全性的消息存储和转发
• 模式 2：传递给大量收信人的多线程实时消息
• 模式 3：使用安全授权/拒绝的复制
• 模式 4：在复制到一个中心点之后，复制到广播消息
• 模式 5：支付交易异常后消息补充

模式 1：具备 PKI 安全性的消息存储和转发

存储和转发消息模式（参见图 18）在将消息发送给收件人之前先检查消息的完整性。完整性检查将会监视安全不可抵赖攻击 (security non-repudiation attacks)，或保证发送方满足定制条件才能将费用转发给接收方。

在付款功能启动之前（在本例中是指结算），您必须先更新其他客户应用程序（例如，帐户分类账），然后与最终贷方确认交易。在确认过程中，不论过程多么短暂，都需要对消息进行加密并将它安全地存储在一个 MQ 存储库或临时数据库中。

图 18. 使用 PKI 证书的消息存储和转发

用 PGP RSA 公钥加密消息有效负载，并使用 PGP 密钥进行解密。证书颁发机构 (CA) 的注册表将会生成公钥对。允许接收付款的每个代理人都将向 CA 发出一个签名请求，并接收和保存一个签名证书，配合支付有效负载使用。

接收方，即贷方代理，可以访问其公钥 (Cpub)、私钥 (Cpriv)，以及借方代理发布者的公钥 (Cpub)。贷方随后用自己的公钥签署消息，并用借方的公钥 (Ppub) 加密信息。然后，借方用自己的私钥 (Ppriv) 解密消息，并用贷方的公钥 (Ppub) 验证签名。在 MQ Advanced Message Security 中提供了这种能力。如欲了解有关的更多信息，请在 IBM 知识中心参阅 IBM WebSphere MQ 的公钥基础架构 主题。

模式 2：传递给大量收信人的多线程实时消息

传递给大量收信人的多线程实时消息模式将消息发送给延迟较少的多个接收方（参见图 19）。作为大量支付的结算方，系统需要确保支付被接收、接受和清算。

图 19. 多个收信人的多线程实时消息

多线程机制支持消息群发，对多个贷方代理进行大量并发支付。因为在 IBM Integration Bus 节点的消息流运行时被认为是线程安全的，您可以在多个操作系统线程上运行多个消息流。增加消息流的吞吐量非常简单，只需增加分配给消息流的线程。

模式 3：安全授权/拒绝中的复制

“安全授权/拒绝中的复制” 模式涉及到多个操作。首先，要将消息复制到另一个机构，然后提供一个成功的支付交易（参加图 20）。在复制消息的时候，会给它添加安全标头，实现不可抵赖性防范，以便提供支付的完整性和来源证据。该消息与绑定到消息 ID 的加密方 ID 有关联。支付消息的各个部分将被过滤和转换。特定于代理的应用程序将会读取消息中的有效负载，并检查业务规则，验证在响应或敲定交易之前，是否执行信用卡或洗钱策略。

图 20. 安全授权/拒绝中的复制

该模式将对生产商的支付消息执行以下操作：

• 复制 当事人消息。
• 丰富 贷方或借方的安全数字证书令牌（基于 PKI 富集模式）。

该模式将对消费者代理的支付消息执行以下操作：

• 将 Tax、Credit 和 Debit 部分过滤到目标代理中的相应部分。
• 转换 到应用程序数据模型。
• 检查 Business Payments Credit 或 Debit Business 规则，以允许授权。
• 关联 到后端代理系统，并响应生产商。

IBM Integration Bus 消息流通过使用预先构建的组件控制这些活动的顺序与每个动作的操作节点，降低复杂性，并减少运营维护。

模式 4：在复制到中心点之后再复制到广播消息

“在复制到中心点之后再复制到广播消息” 模式包括对多个支付的复制，或者拆分消息（参见图 21），并将其广播到多个订阅方。

图 21. 在复制到中心点之后再复制到广播消息

长期订阅 WebSphere MQ 或 MQTT（遥测协议）可以提高消息传递的 QoS。在这里，贷方代理和税务代理是借方代理的网络的订阅者，借方代理的网络可以是提供支付网络的子公司合作伙伴或经纪人。MQTT 提供了内存占用较少的方案，让移动和物联网客户端可以基于订阅采取行动。

贷方代理 A 连接到服务器，然后再连接到借方代理网络的 Topic。然后，借方代理客户端发布 Payment Credit 启动消息。然后，贷方客户端代理、税务代理，或两者共同接收支付。用长期订阅方法来执行发布/订阅，连接到支付平台的客户端在网络中断时不会丢失任何消息。当使用物联网应用程序进行订阅时，包括使用移动电话或便携式电子产品，这种模式特别有用。

模式 5：支付交易异常后的消息补充

支付交易并不总是成功完成。有时，它们的结果可能因为技术或信贷策略异常而产生错误。ISO 20022 标准在 Exceptions and Investigations 中提供了这些异常的参考，解释了因为交易失败开始的支付调查的调查解决过程。

消息补充模式在消息负载中添加一个 Correlation Id 和 Process Id，将它与 Payment Instructions Id 相匹配。IBM Integration Bus 不是有状态引擎，这是执行消息转换并消除不可靠的点对点集成的主要功能。像 IBM Business Process Manager (IBM BPM) 这样的进程管理器将会发起长时间运行的进程，以保持具有长期订阅和时间调度程序的 Payment Transaction 的状态。它确保客户服务等级协议 (SLA) 的解决时间得以保持。

在图 22 中，发起方代理将会生成一个 Correlation Id，IBM Integration Bus 使用它作为支付的惟一标识。IBM Integration Bus 将 Correlation Id 与 Payments Instruction Id 相结合，将它添加到 Payments 消息正文。然后，消息流将它发送到目标贷方代理或最终代理。贷方代理的 IBM BPM 系统创建一个 Instance Id，结合长时间运行的流程和惟一的 Correlation Id。案例管理程序使用这个 Process Id 来匹配所有必要的调查活动，以解决和跟踪问题。在案例得到解决之后，IBM BPM 系统向发起方代理发送一个响应，表示该事务已完成，并提供 Correlation Id。

图 22. 支付交易异常后的消息补充

结束语

本教程介绍了如何使用 IBM Bluemix 和 IBM Integration Bus 基于 ISO 20022 标准来构建 SaaS 支付系统。您学会了如何关联整个 API 来创建支付平台，从而实现实时处理。此外，您还学会了在处理以 IBM Integration Bus 为核心的、高度依赖和安全的 API 时，如何使用常用的软件集成模式。您研究了支持支付平台的一个强大的混合云基础架构模式。该模式强调冗余、集​​群和 MQ 的低故障转移点的需求，在物联网和面向消费者的数字应用的时代，可以防止交易损失，并提高面向消费者的 SaaS 的可靠性。

致谢

特别感谢 Ernese Norelus 对本教程内容的审阅。

BLUEMIX SERVICES USED IN THIS TUTORIAL:

• Cloudant NoSQL DB 服务 提供对始终在线的完全托管的 NoSQL JSON 数据层的访问。该服务与 CouchDB 兼容，并且可通过移动和 Web 应用程序模型的一个简单易用的 HTTP 接口进行访问。
• IBM Business Rules for Bluemix 服务 使开发人员在业务策略变化时能够花更少的时间进行重新编码和测试。Business Rules 服务通过保持业务逻辑与应用程序逻辑分离，最大限度地减少代码更改。