背景

目前, 国内关于 Salesforce 的中文技术文档非常有限, 大多数都是支持日文和英文. 鉴于此, 笔者决定翻译一些优质的 Salesforce 技术文档，并与大家分享。希望这些文档能够助力更多人了解并使用Salesforce平台，在他们的工作和业务中发挥更加重要的作用。

文档

https://developer.salesforce.com/docs/atlas.en-us.integration_patterns_and_practices.meta/integration_patterns_and_practices.

版本

Summer '23 (API version 58.0)

意见 & 交流

如果你对此文档有任何疑问或者对译文有任何建议的话, 请联系我, 欢迎随时交流沟通.

Integration Patterns Overview

当您实施 Salesforce 项目时, 您经常需要与其他应用程序集成. 尽管每个集成场景都是独一无二的, 但有一些共同的问题是开发人员必须解决的.

本文档描述了这些常见集成场景的策略(以模式的形式). 每个集成模式都描述了一个特定场景的设计和方法, 而不是具体的实现. 在这个文档中, 你会发现:

• 一些解决关键原型集成场景的模式
• 选择矩阵可帮助您确定哪种模式最适合您的场景
• 集成技巧和最佳实践

Purpose and Scope

本文档适用于需要将 Lightning 平台与其企业中的其他应用程序集成的设计师和架构师. 此内容是 Salesforce 架构师和合作伙伴的许多成功实施的精华.

如果您正在考虑大规模采用基于 Salesforce 的应用程序(或 Lightning 平台), 请阅读集成模式的总结和筛选矩阵, 了解可用的集成功能和选项. 在 Salesforce 集成项目的设计和实施阶段, 架构师和开发人员应考虑这些集成模式的细节和最佳实践.

如果项目实施得当, 这些集成模式可以使您尽可能快地投入到生产环境上使用, 并拥有一套稳定,可扩展和免维护的应用程序架构. Salesforce 自己的咨询架构师在架构审查中会使用这些模式作为参考点, 并且也会积极参与维护和改进它们.

与所有模式一样, 这些内容涵盖了大多数集成场景, 但不是全部. 虽然 Salesforce 允许用户界面(UI)集成-- 例如: Mashups, 但这种集成超出了本文档的范围. 如果您觉得您的要求超出了这些模式所描述的范围, 请与您的Salesforce代表讨论.

Mashups 是指将 Salesforce 用户界面(UI)与其他 Web 应用程序或服务集成的能力. 这允许用户在Salesforce的 UI 中直接访问外部网站或应用程序的功能和数据, 而无需离开 Salesforce 界面. 例如,您可以通过在 Salesforce UI 中嵌入 Google Map 来快速查看客户所在位置, 或者通过在 Salesforce UI 中嵌入 Twitterfeed 来跟踪公司的社交媒体活动等.

参考官方的文档, 了解更多关于 Mashups 的内容

Pattern Template

每个集成模式都遵循一个一致的结构. 这为每个模式所提供的信息提供了一致性, 也使模式的比较更加容易.

Name

模式标识符,也表示模式中包含的整合类型.

Context

该模式解决的整体集成场景. 上下文提供了关于用户试图完成什么的信息, 以及应用程序将如何表现以支持这些要求.

Problem

该模式旨在解决的情景或问题(以问题的形式表达). 在查看每个集成模式时, 请阅读这一部分, 以迅速了解该模式是否适合你的集成场景.

Forces

使所述场景难以解决的约束和环境.

Solution

解决集成场景的推荐方法.

Sketch

一个 UML 序列图,向你展示解决方案如何解决这个场景.

Results

这一部分解释了如何将解决方案应用于你的集成方案中去, 以及如何解决与该方案相关的细节. 本节还包含应用该模式后可能出现的新挑战.

Sidebars

与模式相关的其他部分包含关键技术问题,模式的变化,特定于模式的问题等.

Example

一个端到端的场景, 描述了如何在真实的 Salesforce 场景中使用设计模式. 这一部分的示例解释了集成目标以及如何实施集成模式来实现这些目标.

Pattern Summary

下面的表格列出了本文档中包含的集成模式.

List of Patterns

Pattern Approach

本文档中的集成模式分为三类:

• 数据集成: 这些模式解决了在两个或更多系统中驻留的数据需要进行同步, 以便两个系统始终包含实时性和有意义的数据的要求. 数据集成通常是最简单的集成类型, 但需要适当的信息管理技术来使解决方案可持续且具有成本效益. 这些技术通常包括主数据管理(MDM), 数据治理, 主数据处理, 去重, 数据流设计等方面.
• 流程集成: 这一类别的模式解决了业务流程利用两个或多个应用程序来完成其任务的需求. 当您实施此类集成的解决方案时, 触发的应用程序必须跨越流程边界调用其他应用程序. 通常, 这些模式也包括协调(其中一个应用程序是中央 "控制器")和编排(其中应用程序是多参与者,没有中央 "控制器"). 这些类型的集成往往需要复杂的设计, 测试和异常处理要求. 此外, 此类复合应用程序通常对底层系统的要求更高, 因为它们通常支持长时间运行的事务, 并具有报告和/或管理进程状态的能力.
• 虚拟集成: 这个类别的模式解决了用户查看, 搜索和修改存储在外部系统中的数据的需求. 当你实施这种类型的集成的解决方案时, 触发的应用程序必须调用其他应用程序, 并与他们的数据进行实时交互. 这种类型的集成消除了跨系统数据复制的复杂性, 也意味着用户总是与最新的数据进行交互.

在这里将 Virtual Integration 翻译为 虚拟集成. 是因为个人理解虛擬集成应该是通过信息技术和协作工作平台等虚拟手段实现不同组织或企业间的数据交互和协作,而无需在本地复制数据. 在 Salesforce 的上下文中,它描述了一种在 Salesforce 平台上与外部系统进行实时数据交换的方法.

为您的系统选择最佳集成策略并非易事. 有许多方面需要考虑, 也有许多工具可以使用, 其中一些工具比其他工具更适合某些任务. 每个模式都针对特定的关键领域, 包括每个系统的能力, 数据量, 故障处理和事务性.

Pattern Selection Guide

下面的选择矩阵表列出了模式和它们的一些关键环节, 以帮助你确定哪种模式最适合你的集成要求. 使用下面这些维度对模式进行分类.

Note

集成可能需要外部中间件或集成解决方案(例如: Enterprise Service Bus), 具体取决于哪些方面适用于您的集成方案.

Integrating Salesforce with Another System

本表列出了这些模式及其关键环节, 以帮助你确定当你的集成方案从 Salesforce 到另一个系统时, 哪个集成模式最适合你的要求.

Integrating Another System with Salesforce

本表列出了这些模式及其关键方面,以帮助你在你的集成方案从另一个系统到 Salesforce 时确定最适合你的要求的模式.

在 Salesforce 中,Call-in 是指外部系统从 Salesforce 中获取数据的过程, 通常是通过调用 Salesforce 的 API 进行数据查询,搜索,更新等操作.

与 Call-In 不同,在 Salesforce 中 Call-out 是 Salesforce 主动发送请求获取外部系统数据的过程, 通常是通过调用外部系统的 API 进行数据查询,搜索,更新等操作.

¹ "Synchronous vs. Asynchronous Communication in Applications Integration", MuleSoft, last accessed October 13, 2021, https://www.mulesoft.com/resources/esb/applications-integration.

² Ibid.

Middleware Terms and Definitions

下面列出了一些与中间件有关的术语及其与这些模式有关的定义.

Event handling

事件处理是在指定的接收者("Handler")处接收可识别的事件. 事件处理涉及的关键流程包括:

• 确定一个事件应该转发到哪里.
• 执行该转发操作.
• 接收转发的事件.
• 采取某种适当的响应措施, 例如写入日志,发送错误或恢复程序, 或者发送额外的消息.

请记住,事件处理最终可能会将事件转发给一个事件消费者.

该功能与中间件的常见用途可以扩展到包括流行的 "发布/订阅" 或 "pub/sub" 功能.在发布/订阅场景中, 中间件将请求或消息从活跃的数据事件发布者那里路由到活跃的数据事件订阅者.然后,这些有活动监听器的消费者可以在事件发布时检索它们.

在使用中间件的 Salesforce 集成中, 事件处理的控制由中间件层承担; 它收集所有相关事件(同步或异步)并管理分发到所有端点, 包括 Salesforce.

另外, 这个功能也可以通过使用带有平台事件的 event bus 在 Salesforce 企业消息平台上实现.

请查看: http://searchsoa.techtarget.com/definition/event-handler.

Protocol conversion

协议转换 "通常是一种软件应用程序,将一个设备的标准或专有协议转换为适合另一个设备的协议,以实现互操作性.

在中间件的背景下,与特定目标系统的连接可能受到协议的限制.在这种情况下,消息格式需要转换为目标系统的格式,或者封装在目标系统的格式中,在那里可以提取 payload.这也被称为隧道(tunneling)".¹

Salesforce 不支持本机协议转换, 所以假定任何此类要求都由中间件层或终端来满足.

请查看: https://www.techopedia.com/definition/30653/protocol-conversion

Translation and transformation

转化是将一种数据格式映射到另一种数据格式的能力, 以确保被整合的各种系统之间的相互操作性. 通常情况下, 这需要在转换过程中对信息进行重新格式化, 以符合发送方或接收方的要求. 在更复杂的情况下, 一个应用程序可以用它自己的本地格式发送消息, 而其他两个或更多的应用程序可能分别以它们自己的本地格式收到该消息的副本.

中间件转换和转换工具通常包括为遗留或其他非标准端点创建服务的能力; 这允许这些端点看起来是服务可分配的.

对于 Salesforce 的集成, 我们认为中间件层或终端都能满足任何此类要求. 数据的转换可以在 Apex 中进行编码, 但出于维护和性能方面的考虑, 我们不建议这样做.

请查看: http://en.wikipedia.org/wiki/Message-oriented_middleware

Queuing and buffering

排队和缓冲通常依赖于异步的消息传递, 而不是请求-响应架构. 在异步系统中, 当目标程序繁忙或连接受到影响时, 消息队列提供临时存储. 此外, 大多数异步中间件系统提供持久性存储来备份消息队列.

异步消息进程的主要好处是, 如果接收方的应用程序由于任何原因发生故障, 发送方可以继续不受影响; 发送的消息只是积累在消息队列中, 以便在接收方重新启动时进行处理.

Salesforce 仅以基于工作流的出站消息传递形式提供显式排队功能. 要为其他集成场景(包括编排,流程编排,服务质量等)提供真正的消息队列, 需要一个中间件解决方案.

请查看: http://en.wikipedia.org/wiki/Message-oriented_middleware

Synchronous transport protocols

同步传输协议指的是支持以下活动的协议: "调用者中的单个线程发送请求消息, 阻塞以等待回复消息, 然后处理回复...., 等待回复的请求线程意味着只有一个未完成的请求, 或者这个请求的回复通道对这个线程是私有的 ". ²

Asynchronous transport protocols

异步传输协议是指支持活动的协议, 其中 "调用者中的一个线程发送请求消息并为回复设置回调. 一个单独的线程侦听回复消息. 当回复消息到达时, 回复线程调用适当的回调, 重新建立调用者的上下文并处理回复. 这种方法使多个未完成的请求能够共享一个回复线程." ³

Mediation routing

调解路由是指从组件到组件的复杂的消息 "流" 的规范. 例如, 许多基于中间件的解决方案依赖于一个消息队列系统. 虽然有些实现允许路由逻辑由消息传递层本身提供, 但其他实现则依赖于客户端应用程序提供路由信息,或允许两种模式的混合.在这种复杂的情况下,(中间件方面的)调解简化了开发,集成和验证.

"具体来说, 调解员协调一组对象, 这样它们[不]需要知道如何相互协调...., 然后, 每个消费者可以专注于处理特定种类的消息, 而协调者[调解员]可以确保正确的消息到达正确的消费者手中."⁴

Process choreography and service orchestration

流程编排和服务编配都是"服务组合"的形式, 其中协调任意数量的端点和功能.

编排和服务协调之间的区别在于:

• 编排可以被定义为"由一群没有中央权威的互动个体实体产生的行为."⁵
• 协调可以被定义为"由中央指挥者协调执行独立任务的各个实体的行为而产生的行为."⁶

此外, "编排显示了每个服务的完整行为,而编排结合了每个服务的接口行为描述." ⁷

业务流程编排的部分内容可以在 Salesforce 工作流中或使用 Apex 构建. 由于 Salesforce 的超时限制和治理者限制(特别是在需要真正的事务处理的解决方案中), 我们建议所有复杂的编排都在中间件层实现.

Transactionality (encryption, signing, reliable delivery, transaction management)

事务性可以定义为支持包含针对每个所需资源的所有必要操作的全局事务的能力. 事务性意味着支持所有四个 ACID(原子性,一致性,隔离性,持久性)属性, 其中原子性保证工作单元(事务)的结果要么全有要么全无.

虽然 Salesforce 本身是事务性的 ,但它无法参与分布式事务或在 Salesforce 外部发起的事务. 因此, 假设对于需要复杂的多系统事务的解决方案, 事务性(以及相关的回滚/补偿机制)在中间件层实现.

请查看: http://en.wikipedia.org/wiki/Distributed_transaction

Routing

路由可以定义为指定从组件到组件的复杂消息流. 在现代基于服务的解决方案中, 此类消息流可以基于许多标准,包括数据头(header), 内容类型, 规则和优先级.

对于Salesforce的集成, 我们认为中间件层或终端都能满足任何此类要求. 消息路由可以在 Apex 中进行编码, 但出于维护和性能方面的考虑, 我们不建议这样做.

Extract, transform, and load

提取,转换和加载 (ETL) 是指涉及以下过程的过程:

• 从源系统中提取数据. 这通常涉及来自几个源系统的数据, 以及关系型和非关系型的结构.
• 转换数据以满足运营需求, 其中可能包括数据质量级别. 转换阶段通常对从源系统中提取的数据应用一系列规则或函数, 以导出要加载到最终目标环境中的数据.
• 将数据加载到目标系统中. 目标系统可能与数据库, 操作数据存储, 数据集市(data mart), 数据仓库(data warehouse)或其他操作系统有很大不同.

虽然并非绝对必要,但大多数成熟的 ETL 工具都提供变更数据捕获的功能. 此功能是该工具识别源系统中自上次提取后发生更改的记录的地方, 从而减少了记录处理量.

Salesforce现在还支持 "Change Data Capture", 即发布代表 Salesforce 记录变更的变更事件. 通过 Change Data Capture, 客户或外部系统会收到Salesforce记录的近乎实时的变更. 这使得客户或外部系统能够同步外部数据存储中的相应记录.

请查看: https://en.wikipedia.org/wiki/Extract,_transform,_load and Change Data Capture 开发者指南.

小知识:

Data mart 和 Data warehouse 都是用于存储和管理企业数据的解决方案, 它们之间的区别在于规模,范围和目的.

Data mart 是一个专门为单个业务部门或特定用户群体设计的小型数据仓库. 它通常包含与该部门或用户群体相关的数据, 并且可以由该部门或用户群体独立地管理和使用. Data mart 通常是针对特定问题或业务需求构建的, 因此它们具有较小的规模和范围, 并且可以更快速地实现.

相比之下, Data warehouse 是一个集中式的,大型的,跨部门的数据存储解决方案. 它涵盖了整个组织的数据, 并且旨在帮助用户从不同的角度分析数据来支持业务决策. 数据仓库需要进行复杂的数据集成和转换, 以确保所有数据都可以在一起使用, 这通常需要更长的时间和更多的资源.

总之, data mart 更小,更局限, 而 data warehouse 更大,更全面. 选择哪种解决方案取决于企业的特定需求和预算.

Long polling

长轮询,也称为 Comet 编程, 模拟从服务器到客户端的信息推送. 与普通轮询类似,客户端连接并向服务器请求信息. 但是, 如果信息不可用,服务器不会发送空响应, 而是保留请求并等待直到信息可用(事件发生). 然后服务器向客户端发送一个完整的响应. 然后客户立即重新请求信息. 客户端持续保持与服务器的连接, 因此它总是在等待接收响应. 如果服务器超时, 客户端会再次连接并重新开始.

Salesforce Streaming API使用 Bayeux 协议和 CometD 进行长时轮询.

• Bayeux是一个传输异步信息的协议, 主要通过HTTP传输.
• CometD是一个可扩展的基于HTTP的事件路由总线, 使用被称为 Comet 的 AJAX 推送技术模式. 它实现了 Bayeux 协议.

^{1 Gregor Hohpe, and Bobby Woolf, Enterprise Integration Patterns (Boston: Addison-Wesley Professional, 2003).}

^{2 Gregor Hohpe, and Bobby Woolf, Enterprise Integration Patterns (Boston: Addison-Wesley Professional, 2003).}

^{3 Ibid.}

^{4 Ibid.}

^{5 "Choreography and Orchestration: A Software Perspective," e-Zest, last accessed April 11, 2019, http://www.e-zest.net/blog/choreography-and-orchestration-a-software-perspective/.}

^{6 Ibid.}

^{7 "Orchestration vs. Choreography," Stack Overflow, last accessed April 11, 2019, http://stackoverflow.com/questions/4127241/orchestration-vs-choreography.}

Design Pattern

远程系统调用-请求和回复

远程进程调用-请求和回复

Context

您使用 Salesforce 来跟踪潜在客户,管理您的销售渠道,创建业务机会. 但是,Salesforce 系统不包含或处理订单. 在 Salesforce 中获取到订单详细信息后, 将在远程系统中创建订单, 该系统管理订单直至流程结束.

当您在项目中实施这种模式时,Salesforce 调用远程系统来创建订单, 然后等待订单成功创建. 如果成功, 远程系统会同步响应订单状态和订单号. 作为同一事务的一部分, Salesforce 在内部更新订单号和状态.订单号被用作外键, 用于随后对远程系统的更新.

Problem

当 Salesforce 中发生事件时,如何启动远程系统中的进程,将所需信息传递给该进程,接收来自远程系统的响应,然后使用该响应数据更新 Salesforce 的数据?

Forces

在使用基于这一模式的解决方案时,要考虑以下因素.

• 对远程系统的调用是否要求 Salesforce 在继续处理之前等待响应? 对远程系统的调用是同步请求-回复还是异步请求?
• 如果对远程系统的调用是同步的, Salesforce 是否必须将响应作为初始调用的同一事务的一部分来处理?
• 信息量是小还是大?
• 集成是基于特定事件的发生, 如 Salesforce 用户界面上的按钮点击, 还是基于 DML 的事件?
• 远程系统的 API 是否能够以低延迟响应请求? 在高峰期,有多少用户可能会执行这项交易?

Solution

下面将包含了这些集成问题的解决方案.

Option 1 (Match: Best)

增强型的外部服务(External Services)调用 REST API

建议:

增强型外部服务允许您以声明的方式调用外部托管服务(无需代码). 这个功能最好在满足以下条件时使用:

• 外部托管的服务是一个 RESTful 服务,其定义以 OpenAPI 2.0 JSON 的格式提供.
• 请求和响应定义包含原始数据类型, 例如布尔值, 日期时间, 双精度, 整数, 字符串或原始数据类型数组. 支持嵌套对象类型和发送参数, 例如 HTTP 请求中的标头.
• 该事务可以从一个 flow 中调用.

Option 2 (Match: Best)

• Salesforce Lightning: Lightning 组件或页面启动了一个同步的 Apex SOAP 或 REST 的 Call-out.
• Salesforce Classic: 自定义 Visualforce 页面或按钮会启动一个同步的Apex SOAP Call-out.
• 如果远程 API 构成了高延迟响应的风险(关于这里适用的限制,请参考最新的文档),那么建议使用异步Call-out,也称为 Continuation, 以避免达到同步 Apex 事务治理者的限制.

建议:

Salesforce 使您能够使用 WSDL 并生成结果代理 Apex 类. 此类提供调用远程服务所需的逻辑.

Salesforce 还允许您使用标准的 GET, POST, PUT 和 DELETE 方法来调用 HTTP(REST) 服务.

Visualforce 页面或 Lightning 页面上的用户发起的动作会调用 Apex 控制器, 然后执行这个代理 Apex 类来执行远程调用. Visualforce 页面和 Lightning 页面需要自定义 Salesforce 应用程序.

Option 3 (Match: Best)

一个自定义的 Visualforce 页面或按钮会启动一个同步的Apex HTTP Call-out.

建议:

Salesforce 使您能够使用标准的 GET,POST,PUT 和 DELETE 方法调用 HTTP 服务. 您可以使用多个 HTTP 类来与 RESTful 服务集成. 也可以通过手动构造 SOAP 消息来集成到基于 SOAP 的服务. 不推荐使用后者,因为 Salesforce 可能会使用 WSDL 来生成代理类.

Visualforce 页面上的用户启动操作随后调用 Apex 控制器操作,该操作随后执行此代理 Apex 类以执行远程调用. Visualforce 页面需要自定义 Salesforce 应用程序.

Option 4 (Match: Suboptimal)

从 Salesforce 数据的更改来调用同步触发器去执行异步 Apex SOAP 或 HTTP Call-out.

建议:

您可以使用 Apex 触发器根据记录数据的变化来执行自动化.

一个 Apex 代理类可以通过使用 Apex 触发器作为 DML 操作的结果来执行. 但是, 在触发器上下文中进行的所有调用都必须异步执行. 因此, 不建议在这种集成问题中使用此解决方案. 此解决方案更适合于 Remote Process Invocation—Fire and Forget 模式.

Option 5 (Match: Suboptimal)

Batch Apex job 执行一个同步的Apex SOAP或HTTP Call-out.

建议:

你可以从一个批处理作业中对远程系统进行调用.这种解决方案允许在 Salesforce 中批量执行远程流程并处理来自远程系统的响应.然而,一个给定的批处理对调用的数量有限制.欲了解更多信息,请阅读 Governor Limits.

给定的批处理运行可以执行多个事务上下文(通常以 200 条记录为间隔). 每个事务上下文都会重置 limits.

Sketch

此图说明了使用 Apex 进行同步远程流程调用.

执行流程:

1. 在 Visualforce 或 Lightning 页面上触发一个动作(例如: 点击按钮).
2. 浏览器(在 Lightning 组件中, 通过客户端控制器)执行 HTTP POST,然后在相应的 Apex 控制器上执行具体操作.
3. 控制器执行对远程服务的实际调用.
4. 来自远程系统的响应被返回到 Apex 控制器.控制器处理该响应,根据实际场景来更新 Salesforce 中的数据, 并重新将响应数据显示在页面上.

在必须跟踪后续状态的情况下, 远程系统会返回存储在 Salesforce 记录中的唯一标识符.

Results

与此模式相关的解决方案的应用允许事件触发的远程流程调用, 其中 Salesforce 处理了进程的过程.

Calling Mechanisms

调用机制取决于为实现这一模式而选择的解决方案.

Error Handling and Recovery

将错误处理和恢复策略作为整体解决方案的一部分是很重要的.

• 错误处理-当错误发生时(异常或错误代码被返回给调用者), 调用者来管理错误信息的处理. 例如: 在终端用户的页面上显示错误信息, 或记录到一个需要进一步操作的 object 中.
• 恢复-在调用者收到成功的响应之前, 数据的响应变化不会被提交到 Salesforce .例如: 在收到表示成功的响应之前, 数据库中的订单状态不会被更新. 如果有必要, 调用者可以重试该操作.

Idempotent Design Considerations

幂等能力可以保证重复调用是安全的. 如果没有实现幂等性, 同一条消息的多次调用可能会产生不同的结果, 可能导致数据完整性问题. 潜在的问题包括创建重复记录或重复处理事务.

确保被调用的远程过程具有幂等性非常重要. 如果调用是由用户界面事件触发的, 则几乎不可能保证 Salesforce 只调用一次. 即使 Salesforce 只进行了一次调用, 也不能保证其他进程(例如中间件)会执行相同的操作.

构建幂等接收者的最典型方法是让它根据消费者发送的唯一消息标识符来跟踪重复项. 必须自定义 Apex web service 或 REST Call 来发送唯一的消息 ID.

此外, 在远程系统中创建记录的操作必须在插入之前进行重复项检查. 通过传递来自 Salesforce 的唯一记录 ID 进行检查. 如果该记录存在于远程系统中, 则更新该记录. 在大多数系统中, 此操作称为 Upsert 操作.

Security Considerations

任何对远程系统的调用必须保持请求的保密性,完整性和可用性. 以下是在这种模式下使用 Apex SOAP 和 HTTP 调用的具体安全考虑.

• 单向SSL默认启用,但支持使用自签名和CA签名证书来实现双向SSL, 以维护客户端和服务器的真实性.
• Salesforce 目前并不支持 WS-Security.
• 必要时,考虑使用 Apex Crypto 类方法中的单向哈希或数字签名,以确保请求的完整性.
• 必须通过实施适当的防火墙机制来保护远程系统.

Web Service 安全性(WS-Security) 描述了对 SOAP 消息传递的改进, 即通过消息完整性,消息机密性以及单一消息认证提供保护功能. WS-Security 机制可用于采纳各种安全模型和加密技术.

WS-Security 是一个消息级别的标准, 主要用于通过 XML 数字签名保护 SOAP 消息, 通过 XML 加密保护机密性以及通过安全性令牌保护凭证传播. Web Service 安全性规范定义了保护消息完整性和机密性的功能,并且提供了使安全相关声明与消息关联的机制.

WS-Security 为安全性令牌与消息的关联提供了一个通用机制. WS-Security 不需要任何特定类型的安全性令牌. 它具有可扩展性, 例如,支持多种安全性令牌格式.

Sidebars

Timeliness

在这种模式下,及时性很重要.通常情况下:

• 请求通常是从用户界面发起的, 因此该过程不能让用户等待.
• Salesforce 对来自 Apex 的 call 有一个可配置的超时时间, 最长可达 120 秒.
• 及时地完成远程过程的调用,在 Salesforce 超时限制内结束.
• 外部调用受 Apex 同步事务限制, 因此请确保减轻实例化超过 10 个事务并且每个事务运行时间超过 5 秒钟的风险. 除了确保外部 API 具有良好的性能之外, 降低超时风险的选项还包括:
  • 将外部 Call-out 的超时时间设置为 5 秒
  • 在 Visualforce 或 Lightning 组件中使用 [continuation](https://developer.salesforce.com/docs/atlas.en-us.apexref.meta/apexref/apex_class_System_Continuation.htm) 来处理长时间运行的事务.

Data Volumes

由于 Apex call 解决方案的请求或响应的超时值较小, 因此此模式主要用于小批量实时活动. 不要在消息中包含数据 payload 的批处理请求中使用此模式.

Endpoint Capability and Standards Support

对 endpoint 的能力和标准支持取决于你选择的解决方案.

State Management

在集成系统时, 唯一键对于持续状态的跟踪是很重要的. 这里有两个选项:

• Salesforce 存储远程系统的主键或唯一标识符来标识远程记录.
• 远程系统存储 Salesforce 唯一的记录ID或其他唯一的标识符.

根据包含主记录的系统,处理系统集成唯一键有一些具体注意事项,如下表所示:

Complex Integration Scenarios

在某些情况下,该模式规定的解决方案可能需要实现多个复杂的集成方案. 最好使用中间件或让 Salesforce 调用一个组合服务来实现. 这些场景包括:

• 涉及复杂流程逻辑的业务流程和规则的编排
• 对多个系统的调用及其结果进行汇总
• 入站和出站消息的转换
• 在对多个系统的调用之间保持事务完整性

Governor Limits

有关 Apex 限制的信息,请查看Execution Governors and Limits

Middleware Capabilities

下表显示了构建此模式的中间件系统的理想特性.

Example

一家公用事业公司使用 Salesforce, 并有一个单独的系统包含客户的账单信息. 他们想显示客户账户的账单历史, 而不在 Salesforce 中存储这些数据. 他们有一个现有的 Web Service, 可以返回一个给定账户的账单列表和细节, 但不能在浏览器中显示这些数据.

这一要求可以通过以下方法来实现:

• Salesforce 使用 Apex 代理类中的消费账单历史服务 WSDL.
• 通过创建一个 Lightning 组件和一个自定义 Controller 或一个 Visualforce 页面和自定义 Controller, 执行 Apex 代理类, 并将账号作为唯一的标识符.
• 然后, 自定义 controller 解析来自 Apex call-out 和 Lightning 组件或 Visualforce 页面的返回值, 然后将客户的账单数据呈现给用户.

这个例子证明了:

• 使用存储在 Salesforce Account 对象上的帐号跟踪客户的状态.
• 呼叫方对响应信息进行后续处理.

远程系统调用-即发即弃

Context

您使用 Salesforce 来跟踪潜在客户,管理您的销售渠道,创建业务机会. 但是,Salesforce 系统不包含或处理订单. 在 Salesforce 中获取到订单详细信息后, 将在远程系统中创建订单, 该系统管理订单直至流程结束.

当您在项目中实施这种模式时,Salesforce 调用远程系统来创建订单, 但并不等待调用的成功完成. 远程系统可以选择在一个单独的事务中用新的订单号和状态更新 Salesforce 数据.

Problem

当 Salesforce 中发生事件时,如何在远程系统中启动一个流程, 并将所需信息传递给该流程, 而无需等待远程系统的响应?

Forces

在应用基于这一模式的解决方案时, 要考虑以下几个方面:

• 调用远程系统是否需要 Salesforce 等待响应才能继续处理?调用远程系统是同步还是异步的?
• 如果对远程系统的调用是同步的, 那么响应是否需要作为调用的一部分在 Salesforce 中进行处理?
• 传递的信息量是否很小?
• 集成是基于特定事件的发生的吗? 如 Salesforce 用户界面上的按钮点击,还是基于 DML 的事件?
• 从 Salesforce 到远程系统的消息传递是否有保证?
• 远程系统能否参与以契约(contract)为先的集成,其中 Salesforce 指定集成规范(contract)? 在某些解决方案变体(例如,出站消息), Salesforce 指定远程系统实现指定的规范.
• Endpoint 或企业服务总线(ESB)是否支持长轮询?
• 声明性配置的方法是否优于自定义 Apex 开发? 在这种集成模式下, 像平台事件这样的解决方案优于 Apex 调用.

这里的 Contract 可以理解为一个规范或协议, 用于描述两个或多个系统之间的交互行为. 在这种情况下, Salesforce 定义了一个规范, 要求远程系统按照规范进行实现.

关于长轮询(Long Polling), 它是一种 Web 应用的实时通信技术, 允许客户端发送异步请求并保持打开连接, 在有新数据可用时即时接收响应. 而 ESB 是一种支持不同应用和服务集成的中间件, 用于管理不同服务之间的通信.

Solution

下面几个部分包含了这个集成问题的解决方案:

方案一: 流程驱动的平台事件(Process-driven platform events) (适配度: Best)

在 Salesforce 中实现平台事件不需要定制化. 推荐的解决方案是在插入或更新事件中调用远程系统.

平台事件是一个事件消息(或通知), 以便您的应用程序在发送和接收消息后可以采取进一步操作, 平台事件简化了在不编写复杂逻辑的情况下通信变化并响应的过程. 一个或多个订阅者可以侦听同一事件并执行操作.

例如: 软件系统可以发送包含打印机墨盒信息的事件. 订阅者可以订阅事件, 来监控打印机墨水量, 并下订单更换墨水量低的墨盒.

外部应用程序可以通过 CometD 订阅一个 Channel 来监听事件消息. 平台应用程序, 如 Visualforce 页面和 Lightning 组件, 也可以用 CometD 订阅事件消息.

方案二: 基于自定义驱动的平台事件(Customization-driven platform events) (适配度: Good)

类似于方案一, 但是此方案是是由Apex Trigger 或 Class 创建的, 你可以通过使用 Apex 或 API 来发布和消费平台事件.

平台事件通过 Apex Trigger 与 Salesforce 平台集成. Apex Trigger 是 Salesforce 平台上监听事件消息的事件消费者.

当外部应用程序使用API或 Salesforce应用程序使用 Apex 发布事件消息时, 就会触发该事件的触发器. 触发器运行响应事件通知的动作.

方案二: 基于工作流驱动的出站消息传递(Workflow-driven outbound messaging) (适配度: Good)

在 Salesforce 中实现出站消息不需要定制化. 针对这种类型的集成, 建议的解决方案是在插入或更新事件中调用远程过程. Salesforce 提供了基于工作流的出站消息功能, 允许在 Salesforce 中的插入或更新操作触发时向远程系统发送 SOAP 消息. 这些消息是异步发送的, 与 Salesforce 用户界面无关.

出站消息被发送到特定的远程端点. 远程服务必须能够参与以契约为先的集成, 其中 Salesforce 提供契约规范.

收到消息后, 如果远程服务没有用肯定的确认信息回应, Salesforce 将重试发送消息, 提供一种保证交付的方式.当使用中间件时, 这个解决方案成为 第一英里(first-mile) 交付保证.

在这里, first-mile 指的是从消息发送方到中间件的传输阶段, 也就是消息传输的起始阶段. 因此, first-mile guarantee of delivery 是指在消息从发送方到达中间件的过程中, 确保消息的可靠交付.

方案三: 出站消息和回调(Outbound messaging and callbacks) (适配度: Good)

回调提供了一种方法来减轻消息顺序错乱的影响.此外,它们还处理这些场景:

• 幂等性: 如果没有及时收到确认, 则出站消息执行重试. 可以向目标系统发送多条消息. 使用回调确保检索到的数据是在特定时间点, 而不是在发送消息时.
• 获取更多数据: 单个出站消息只能发送单个对象的数据. 可以使用回调从其他相关记录检索数据, 例如与父对象相关联的相关列表.

出站消息提供了一个唯一的 SessionId, 您可以使用它作为认证令牌来使用 SOAP API 或 REST API 进行回调的认证和授权. 执行回调的系统不需要单独向 Salesforce 进行身份验证. 然后可以使用任一 API 的标准方法来执行所需的业务功能.

这个变体的典型用途是 Salesforce 向远程系统发送出站消息以创建记录的场景. 回调会使用在远程系统中创建的记录的唯一键更新原始的 Salesforce 记录.

方案四: 自定义 Lightning 组件或 Visualforce 页面,使用 Apex SOAP 或 HTTP 异步调用(Custom Lightning component or Visualforce page that initiates an Apex SOAP or HTTP asynchronous call-out) (适配度: Suboptimal)

这种解决方案通常用于基于用户界面的场景,但需要定制.此外,解决方案必须在代码中处理消息的可靠传递.

类似于 远程流程调用的--请求和回复 模式的解决方案, 指定使用 Visualforce 页面或 Lightning 组件, 以及 Apex call-out. 不同的是, 在这种模式中, Salesforce 不会等待请求完成后再将控制权交给用户.

在收到消息后, 远程系统会做出响应并表示收到消息, 然后异步处理该消息. 远程系统在开始处理消息之前将控制权交还给 Salesforce; 因此, Salesforce 无需等待处理完成.

方案五: 从 Salesforce 数据变化后触发触发器再执行一个 Apex SOAP 或 HTTP 异步调用(Trigger that's invoked from Salesforce data changes performs an Apex SOAP or HTTP asynchronous cal-lout) (适配度: Suboptimal)

你可以使用 Apex 触发器基于记录数据的变化来执行自动化.

使用Apex触发器可以将Apex代理类作为DML操作的结果执行. 但是, 从触发器上下文中发起的所有调用都必须异步执行.

方案六: 使用 Batch Job 执行 Apex SOAP 或 HTTP 异步 call-out(Batch Apex job that performs an Apex SOAP or HTTP asynchronous call-out) (适配度: Suboptimal)

可以在 Batch Job 中调用远程系统. 该解决方案允许批量执行远程进程, 并在 Salesforce 中处理来自远程系统的响应. 然而, 在给定的批处理上下文中, 调用数量存在限制. 有关更多信息, 请查看 Salesforce Developer Limits and Allocations Quick Reference

Sketch

以下图表说明了Salesforce向远程系统发起调用的情况, 其中对记录进行创建或更新操作会触发调用.

具体步骤:

1. 一个远程系统订阅了 Salesforce 平台事件.
2. 更新或插入发生在 Salesforce 的一组特定记录上.
3. 当满足一组条件时, Salesforce流程将被触发.
4. 这个过程创建一个平台事件.
5. 远程监听器接收事件消息, 并将消息放置在本地队列中.
6. 排队的应用程序将消息转发给远程应用程序进行处理.

在远程系统必须对 Salesforce 执行操作的情况下, 您可以实现一个可选的回调操作.

Results

与此模式相关的解决方案的应用可以实现:

• 用户界面发起的远程进程调用, 其事务结果可以显示给最终用户.
• DML事件启动的远程进程调用, 其中事务的结果可以由调用进程处理.

Calling Mechanisms

调用机制取决于为实现这一模式而选择的解决方案.

Error Handling and Recovery

处理错误和恢复策略必须作为整体解决方案的一部分进行考虑.最佳方法取决于您选择的解决方案.

方案一: Apex callouts

• 错误处理: 远程系统交接最终进程的调用,因此调用仅处理远程服务的初始调用中的异常.例如,如果没有收到来自远程调用的肯定确认,则会触发超时事件.当初始调用被交接进行异步处理时,远程系统必须处理随后出现的错误.
• 恢复: 在这种情况下, 恢复更加复杂. 如果需求要求高质量的完成, 则必须创建自定义重试机制.

方案二: Outbound messaging

• 错误处理: 因为此模式是异步的, 所以远程系统负责错误处理. 对于出站消息, 如果在超时期内未收到肯定的确认,则 Salesforce 发起重试操作, 时间最长为24小时.

错误处理必须在远程服务中执行,因为该消息以 fire-and-forget 的方式有效地移交给远程系统.

• 恢复: 因为此模式是异步的,系统必须根据服务质量要求启动重试.对于出站消息,如果在超时时间内未从出站监听器收到肯定的确认,Salesforce 将启动重试,最长达24小时.重试间隔随时间呈指数增长, 从15秒间隔开始, 到60分钟间隔结束. 超时时间可以通过向 Salesforce 支持部门请求延长至七天, 但自动重试仅限于24小时. 所有24小时后失败的消息都将放置在队列中, 管理员必须监视此队列以查找超过24小时交付期限的任何消息, 并在必要时手动重试.

方案三: Platform Events

• 错误处理: 错误处理必须由远程服务执行,因为该事件实际上已移交给远程系统进行进一步处理. 由于此模式是异步的, 因此远程系统处理消息排队,和错误处理等. 此外, 在数据库事务中无法处理平台事件. 因此, 发布的平台事件无法在事务内回滚.

• 恢复: 由于此模式是异步的, 因此远程系统必须根据服务的服务质量要求发起重试. 与每个事件相关联的 replay ID 是原子性的, 并随着每个已发布事件的增加而增加. 可以使用此 ID (例如,基于最后成功捕获的事件)来 replay 特定事件的流. 大容量平台事件消息存储时间为 72 小时(三天). 当使用 CometD 客户端订阅一个频道时, 可以检索过去的事件消息.

Idempotent Design Considerations(幂等性设计的注意事项)

平台事件只会被发布到总线上一次. Salesforce 端不会进行重试. 请求重播事件取决于 ESB. 平台事件的 replay ID 保持不变, ESB 可以根据 replay ID 尝试重复消息.

幂等性对于出站消息传递很重要, 因为它是异步的, 并且在未收到肯定确认时会启动重试. 因此, 远程服务必须能够以幂等方式处理来自 Salesforce 的消息.

出站消息会为每个消息发送一个唯一的 ID, 任何重试都会保持这个 ID 不变. 远程系统可以基于这个唯一的 ID 跟踪重复的消息. 同时也会发送正在更新的每条记录的唯一记录 ID, 可以用来防止重复记录创建.

远程过程调用-请求和回复 模式中的 idempotent design considerations 也适用于这个模式.

Security Considerations

任何对远程系统的调用必须保持请求的保密性,完整性和可用性. 根据你选择的解决方案, 适配不同的安全考虑因素.

方案一: Apex callouts

对远程系统的调用必须保持请求的保密性,完整性和可用性.以下是在这种模式下使用 Apex SOAP 和 HTTP 调用的具体安全考虑:

• 单向SSL默认启用, 但支持使用自签名和CA签名证书来实现双向SSL, 以维护客户端和服务器的真实性.
• Salesforce 目前并不支持 WS-Security.
• 必要时,考虑使用 Apex Crypto 类方法中的单向哈希或数字签名,以确保请求的完整性.
• 必须通过实施适当的防火墙机制来保护远程系统.

Web Service 安全性(WS-Security) 描述了对 SOAP 消息传递的改进, 即通过消息完整性,消息机密性以及单一消息认证提供保护功能. WS-Security 机制可用于采纳各种安全模型和加密技术.

WS-Security 是一个消息级别的标准, 主要用于通过 XML 数字签名保护 SOAP 消息, 通过 XML 加密保护机密性以及通过安全性令牌保护凭证传播. Web Service 安全性规范定义了保护消息完整性和机密性的功能,并且提供了使安全相关声明与消息关联的机制.

WS-Security 为安全性令牌与消息的关联提供了一个通用机制. WS-Security 不需要任何特定类型的安全性令牌. 它具有可扩展性, 例如,支持多种安全性令牌格式.

方案二: Outbound Messaging

对于出站消息, 默认启用了单向SSL. 但是, 双向 SSL 可以与 Salesforce outbound messaging 证书一起使用.

以下是一些额外的安全考虑因素:

• 为远程集成服务器添加 Salesforce 服务器 IP 范围到白名单中.
• 通过实施适当的防火墙机制来保护远程系统.

方案三: Platform Events

对于平台事件, 订阅的外部系统必须能够对 Salesforce streaming API 进行认证.

平台事件遵循在 Salesforce 组织中配置的现有安全模型. 要订阅事件, 用户需要对事件实体具有读取访问权限. 要发布事件, 用户需要在事件实体上具有创建权限.

Sidebars

Timeliness

对于即发即弃模式,及时性不是一个重要因素. 控制权立即或在成功将消息交付到远程系统后得到积极确认后即返回给客户端. 对于 Salesforce 出站消息, 确认必须在 24 小时内发生(可以延长到 7 天); 否则, 消息过期. 对于平台事件, Salesforce 将事件发送到事件总线, 而不等待订阅者的确认. 如果订阅者没有收到消息, 订阅者可以使用事件 reply ID 请求重播事件. 事件消息会存储 72 小时(三天). 要检索过去的事件消息, 请使用 CometD 客户端订阅频道.

Data Volumes

数据量的考虑取决于您选择的解决方案.关于每个解决方案的限制,请参考 Salesforce Limits Quick Reference Guide.

Endpoint Capability and Standards Support

对 Endpoint 的能力和标准支持取决于你选择的解决方案.

方案一: Apex SOAP callouts

考虑因素:

该端点必须能够通过 HTTP 处理 Web 服务调用. Salesforce 必须能够通过公共互联网访问该端点.

这个解决方案要求远程系统与 Salesforce 所支持的标准兼容. 在撰写本文时,Salesforce 为 Apex SOAP call-outs 所支持的网络服务标准是:

• WSDL 1.1
• SOAP 1.1
• WSI-Basic Profile 1.1
• HTTP

方案二: Apex HTTP callouts

考虑因素:

该端点必须能够接收 HTTP 调用.Salesforce 必须能够通过公共互联网访问该端点.

你可以使用 Apex 的 HTTP call-out, 使用标准的 GET, POST, PUT和 DELETE 方法来调用 REST 服务.

方案三: Outbound message

考虑因素:

• 该端点必须能够实现一个监听器,能够接收从 Salesforce 发送的预定义格式的 SOAP 消息.
• 远程监听器必须参与契约优先的规则,其中规则由 Salesforce 提供.
• 每个出站消息都有自己预定义的 WSDL.

方案四: Platform Events

• 触发器, 流可以订阅事件. 无论事件是如何发布的, 你都可以收到事件通知.
• 使用 CometD 从外部客户端订阅平台事件. 实现自己的 CometD 客户端或使用 EMP Connector, 这是一个开源的, 由社区支持的工具, 它实现了连接到 CometD 并监听通道的所有细节. Salesforce 按照接收顺序依次向 CometD 客户端发送平台事件. 事件通知的顺序基于事件的 replay ID.

State Management

在集成系统时, 唯一键对于持续状态的跟踪是很重要的. 这里有两个选项:

• Salesforce 存储远程系统的主键或唯一标识符来标识远程记录.
• 远程系统存储 Salesforce 唯一的记录ID或其他唯一的标识符.

下表列出了这种模式下状态管理的注意事项:

Complex Integration Scenarios

这个模式中的每个解决方案对复杂的集成场景都有不同的考虑:

方案一: Apex Callout

在某些情况下,该模式规定的解决方案可能需要实现多个复杂的集成方案. 最好使用中间件或让 Salesforce 调用一个组合服务来实现. 这些场景包括:

• 涉及复杂流程逻辑的业务流程和规则的编排
• 对多个系统的调用及其结果进行汇总
• 入站和出站消息的转换
• 在对多个系统的调用之间保持事务完整性

方案二: Outbound messaging

鉴于出站消息的静态,声明性质, 在 Salesforce 中不能执行复杂的集成方案, 如聚合,协调或转换. 远程系统或中间件必须处理这些类型的操作.

方案三: Platform Events

鉴于事件的静态,声明性质, 在 Salesforce 中不能执行复杂的集成方案, 如聚合,协调或转换. 远程系统或中间件必须处理这些类型的操作.

Governor Limits

由于Salesforce平台是多租户的性质, 因此对于出站调用存在一些限制. 这些限制取决于出站调用的类型和调用的时间.

如果是平台事件, 适用不同的限制和分配. 参考Platforms Events Developer Guide..

出站消息没有具体的限制. 参考Salesforce Limits Quick Reference Guide.

Reliable Messaging

可靠的消息传递试图解决保证向远程系统传递消息的问题, 其中的各个组件是不可靠的. 确保远程系统收到消息的方法取决于你选择的解决方案.

Middleware Capabilities

下面的表格强调了一个中间件系统在这种模式中所应具备的理想特性.

解决方案变体 - 平台事件:发布行为和事务

当平台事件消息为立即发布时,事件发布不会关心发布过程的事务边界. 在事务完成之前或即使事务失败, 事件消息都可以被发布. 这种行为可能会导致问题, 如果订阅者期望在发布事务提交后找到数据, 但是当订阅者接收事件消息时, 可能会发现数据并不存在. 为解决此问题, 请在事件定义中将平台事件发布行为设置为 "提交后发布". 可以设置在平台事件定义中的发布行为有:

• 选择 提交后发布 选项,可以在事务成功提交后才发布事件消息.如果订阅者依赖于发布事务提交的数据,请选择此选项.例如,一个进程发布了一个事件消息并创建了一个任务记录.订阅该事件的第二个进程被触发,并期望找到这个任务记录.选择此行为的另一个原因是您不希望在事务失败时发布事件消息.
• 选择 立即发布 选项,可以在发布调用执行时发布事件消息.如果您希望不管事务是否成功都要发布事件消息,请选择此选项.如果发布者和订阅者是独立的,并且订阅者不依赖于发布者提交的数据,请选择此选项.例如,立即发布行为适用于用于记录目的的事件.使用此选项,订阅者可能会在发布者事务提交数据之前收到事件消息.

解决方案变体 - 出站消息和消息排序

Salesforce出站消息传递不能保证其消息的交付顺序,因为一条消息可以在24小时内重试.在远程系统中,有多种处理消息顺序的方法.

• Salesforce 为每个出站消息实例发送一个唯一的消息ID. 远程系统会丢弃具有重复消息ID的消息.
• Salesforce 只发送 RecordId. 远程系统对 Salesforce 进行回调, 以获得处理请求的必要数据.

解决方案变体 - 出站消息和删除

Salesforce工作流规则无法跟踪记录的删除.规则只能跟踪记录的插入或更新.因此,您不能从记录的删除直接启动出站消息.但是,您可以通过以下过程间接地触发消息.

• 创建一个自定义对象来存储被删除记录的关键信息.
• 创建一个Apex触发器,在记录被删除时触发, 以便存储信息, 例如在自定义对象中的唯一标识符.
• 实施一个工作流规则, 在创建自定义对象记录的基础上启动一个出站消息.

重要的是，通过在 Salesforce 中存储远程系统的唯一标识符或在远程系统中存储 Salesforce 的唯一标识符来启用状态跟踪。

Example

一家电信公司希望使用 Salesforce 作为前端，通过从潜在客户到商业机会的过程创建帐户。当商业机会是 Close & Win 时，Salesforce 中将创建一个订单，但是后端 ERP 系统是数据主系统。订单必须保存到 Salesforce 业务机会记录中，并通过更改业务机会的状态以表明已创建订单。

适用以下限制条件:

• 不需要在 Salesforce 中进行定制开发.
• 您不需要在业务机会转换为订单后立即收到订单编号的通知.
• 该组织拥有支持 CometD 协议并能够订阅平台事件的 ESB.

这个例子最好使用Salesforce平台事件实现，但需要 ESB 订阅该平台事件.

在 Salesforce 这边:

• 创建一个 Process Builder 流程来启动平台事件（例如，当机会状态改变为Close-Won）.
• 创建一个新的平台事件, 发布业务机会的详细信息.

在远程系统一侧:

• ESB 使用 CometD 协议订阅了 Salesforce 平台事件.
• ESB会收到一个或多个通知，表明该机会将被转换为订单.
• ESB将消息转发到后端 ERP 系统, 这样就可以创建订单.
• 在ERP系统中创建订单后，将使用SessionId作为认证令牌，通过单独的线程回调到Salesforce系统，以更新对应机会的订单编号和状态。您可以使用Salesforce平台事件、Salesforce SOAP API、REST API或Apex Web服务等经过文档化的模式解决方案进行回调操作.

这个例子展示了以下内容:

• 异步调用远程过程的实现.
• 端到端的可靠传递.
• 对Salesforce的后续回调，以更新记录的状态.

批量数据同步

Context

如果您正在将您当前的 CRM 系统迁移到 Salesforce, 并希望实现以下目标:

• 从当前 CRM 系统中提取和转换客户账户,联系人和商机,并将数据加载到 Salesforce 中(初始数据导入)
• 每周从远程系统中提取,转换和加载客户的账单数据到 Salesforce 中(持续进行).
• 每周从 Salesforce 中提取客户活动信息并将其导入到本地数据仓库中(持续性任务).

Problem

在考虑到这些导入/导出的动作可能会在工作时间干扰到最终用户的操作, 有些时候可能会涉及大量数据操作, 那么您如何将这些数据导入 Salesforce 或从 Salesforce 导出?

Forces

在应用基于此模式的解决方案时, 有许多要考虑的因素:

• 数据是否应该存储在 Salesforce 中?如果不是,架构师可以考虑其他的集成选项(例如 mashups).
• 如果数据应存储在Salesforce中,那么是否应根据远程系统中的事件刷新数据?
• 数据是否应定期刷新?
• 这些数据是否支持主要的业务流程?
• 这些数据在 Salesforce 中的可用性是否对分析(报告)需求产生影响?

Solution

下表包含了解决这些集成问题的各种方案.

Sketch

下图说明了这种模式下的事件顺序,其中远程系统是数据主站.

下图说明了这种模式下的事件顺序,其中Salesforce是数据主站.

Results

在以下情况下, 你可以将来自外部系统的数据与 Salesforce 集成:

• 外部系统是数据主站, Salesforce 是由单个源系统或多个系统提供的数据的使用者.在这种情况下,通常会有一个数据仓库(Data Warehouse)或数据集市(Data Mart),将数据汇总后再导入到 Salesforce 中.
• Salesforce是数据主站: Salesforce 是某些实体的记录系统,Salesforce Change Data Capture 应用程序可以获知 Salesforce 数据的变更情况.

在一个典型的Salesforce集成方案中, 实施团队会做以下工作之一:

• 在源数据集上实施 Change Data Capture.
• 在一个中间的本地数据库中实现一组支持性的数据库结构,称为控制表.

然后, ETL工具被用来创建程序,这些程序将:

• 读取控制表以确定作业的最后运行时间,并提取所需的任何其他控制值.
• 使用上述控制值作为过滤器,查询源数据集.
• 应用预定义的处理规则,包括验证,增强等.
• 使用 ETL 工具的可用连接器/转换功能来创建目标数据集.
• 将数据集写入 Salesforce 对象.
• 如果数据处理成功,更新控制表中的控制值.
• 如果处理失败, 用能够重新启动和退出的值更新控制表.

Note:

我们建议您在一个 ETL 工具可以访问的环境中创建控制表和相关的数据结构,即使无法访问 Salesforce.这样可以提供足够的弹性.在这个过程中,Salesforce 应该被视为一个分支,而 ETL 基础设施则是中心枢纽.

为了使 ETL 工具充分发挥数据同步功能的最大优势，请考虑以下几点:

• 将 ETL 作业进行链式和顺序处理，以提供一个连贯的过程.
• 使用两个系统的主键来匹配输入的数据.
• 使用特定的 API 方法，只获取最新的数据.
• 如果在主-从或查找关系中导入子记录，应在数据源处使用其父键对导入的数据进行分组，以避免数据锁定。例如，如果您正在导入联系人数据，请确保按父帐户 ID 对联系人数据进行分组，以便可以在一个 API 调用中加载单个帐户的最大联系人数。未能对导入的数据进行分组通常会导致第一个联系人记录被加载，而该帐户的后续联系人记录在 API 调用的上下文中失败.
• 任何导入后的数据处理，如触发器，都应该只有选择性地处理数据.
• 如果你的集成场景涉及到大数据量，请遵循《大数据量部署的最佳实践》中的最佳实践。

Error Handling and Recovery

必须考虑将错误处理和恢复策略作为整体解决方案的一部分。最好的方法取决于你选择的解决方案.

Security Considerations

任何对远程系统的调用必须保持请求的保密性、完整性和可用性。不同的安全考虑因素，取决于你选择的解决方案.

• 需要具有至少 "API Only" 用户权限的 Lightning 平台许可证，才能允许对 Salesforce API 进行经过身份验证的API访问。
• 我们建议使用标准的加密方式来保证密码访问的安全.
• 在调用 Salesforce API 时，请使用 HTTPS 协议。如果有必要，您还可以通过本地安全解决方案代理流量到 Salesforce API.

查看 Security Considerations.

Sidebars

Timeliness

及时性在这种模式下并不是非常重要的。然而，必须注意接口设计，以便所有批处理过程在指定的批处理事务内完成。

与所有批处理操作一样，我们强烈建议您在批处理窗口期间注意隔离源系统和目标系统。在工作时间加载批次可能会导致某些数据竞争，从而导致用户的更新失败，或者更重要的是，批量加载（或部分批量加载）失败。

对于有全球业务的组织来说，在同一时间运行所有的批处理程序可能是不可行的，因为系统可能一直在使用中。在这些情况下，可以使用记录类型和其他过滤标准的数据分割技术来避免数据竞争。

State Management

您可以通过在两个系统之间使用代理键(surrogate keys)来实现状态管理。如果您需要跨 Salesforce 实体进行任何类型的事务管理，则建议您使用Apex的远程调用模式(Remote Call-In pattern)。

标准的乐观记录锁在平台上执行，并且使用 API 进行的任何更新都需要正在编辑记录的用户刷新记录并启动他们的事务。在 Salesforce API 的上下文中，乐观锁是指一种流程，其中:

• Salesforce 并不维护特定用户正在编辑的记录的状态.
• 在读取时，它记录了数据被提取的时间.
• 如果用户更新了记录并保存了它，Salesforce 会检查是否有其他用户在这期间更新了该记录.
• 如果记录已被更新，系统会通知用户已进行了更新，用户应在继续进行更新前检索该记录的最新版本。

Middleware Capabilities

用来实现这种模式的最有效的外部技术是传统的 ETL 工具。重要的是，所选择的中间件工具要支持 Salesforce Bulk API。

中间件工具支持 getUpdated() 函数是有帮助的，但不是关键。这个函数提供了最接近 Salesforce 平台上标准变更数据捕获能力的实现.

下表强调了参与这种模式的中间件系统的理想属性:

Example

一个公用事业公司使用基于主机的批处理程序，将潜在客户分配给个别销售代表和团队。这些信息需要每天晚上导入Salesforce。

客户已经决定使用一个商业上可用的 ETL 工具对源表实施变更数据采集。

该解决方案的工作原理如下:

• 一个类似于cron的调度程序执行一个批处理作业，将潜在客户分配给用户和团队.
• 批处理作业运行并更新数据后，ETL工具使用 change data capture 来识别这些更改。ETL 工具对来自数据存储的变化进行整理。
• ETL 连接器使用 Salesforce SOAP API 将变化加载到 Salesforce。

远程系统请求呼入

Context

您使用 Salesforce 跟踪潜在客户, 管理销售渠道, 创建商机, 并捕捉转化潜在客户为客户的订单细节. 但是, Salesforce 并非包含或处理订单的系统. 订单由外部(远程)系统进行管理. 该远程系统需要在订单通过其处理阶段时在 Salesforce 中更新订单状态.

Problem

远程系统如何与 Salesforce 建立连接和完成认证,以便通知与 Salesforce 有的关外部事件, 比如: 创建记录和更新现有记录的情况?

Forces

应用基于这种模式的解决方案时,需要考虑各种因素.

• 远程调用 Salesforce 的目的是使用事件驱动架构将外部发生的事件通知到 Salesforce 吗?还是为了在特定记录上执行 CRUD 操作?如果您使用事件驱动架构,事件生产者(远程进程)与Salesforce 的事件消费者是解耦的.
• Salesforce 的调用是否要求远程进程在继续处理之前等待响应?远程调用 Salesforce 的请求始终是同步的请求-响应过程, 但如果不需要响应来模拟异步调用, 则远程进程可以丢弃响应.
• 每个交易是针对单个 Salesforce 对象还是多个相关对象进行操作?
• 消息的格式是什么(例如,SOAP 或 REST, 或两者都是通过 HTTP)?
• 消息的大小是较小还是较大?
• 如果远程系统支持 SOAP 协议的功能,那么远程系统能够参与以契约为先的方法吗?即 Salesforce 主导契约的方法.这里可以使用的 Salesforce 的 SOAP API,因为 Salesforce 提供了预定义的 WSDL.
• 是否需要事务处理?
• 你对 Salesforce 的定制化程度有多高容忍?

Solution

下面内容包含了这个集成问题的各种解决方案.

1. SOAP API(Fit: Best)

   Solution:

   • 可访问性: Salesforce 提供了一个 SOAP API, 远程系统可以使用它来:

     • 发布事件以通知你的 Salesforce 组织.
     • 查询你的 Org 中的数据.
     • 创建,更新和删除数据
     • 获得你的 Org 的元数据.
     • 运行实用程序执行管理任务.

   • 同步 API: 在进行 API 调用后, 远程客户端应用程序会等待, 直到它收到来自服务的响应. 不支持对 Salesforce 的异步调用.

   • 生成的WSDL: Salesforce 为远程系统提供两种 WSDL:

     • Enterprise WSDL: 提供一个强类型的 WSDL, 该 WSDL 是针对 Salesforce 组织的.
     • Partner WSDL: 包含一个松散类型的 WSDL, 该 WSDL 并不特定于 Salesforce 组织.

   • 安全性: 调用 SOAP API 的客户端必须有一个有效的登录,并获得一个会话以执行任何 API 调用.该 API 遵循 Salesforce 中根据登录用户的配置文件配置的对象级和字段级安全.

   • 事务/提交行为: 默认情况下, 每个 API 调用都允许在某些记录标记为错误时部分成功.这可以更改为 "all or nothing" 的行为, 如果发生任何错误, 则所有结果都将回滚. 无法跨多个 API 调用进行事务处理.为了克服这个限制, 单个 API 调用可以影响多个对象.

   • 批量数据: 包括超过 2,000 条记录的任何数据操作都是使用 Bulk API 2.0 的一个很好的选择,可以成功地准备,执行和管理利用 Bulk 框架的异步工作流.少于2,000条记录的作业可以在 REST(例如: Composite API)或 SOAP 中进行 "批量化" 的同步调用.

   • 事件驱动架构: 平台事件的定义与您定义 Salesforce 对象的方式相同.通过 SOAP API 发布一个事件与创建 Salesforce 记录的方式是一样的.

2. REST API(Fit: Best)

   Solution:

   • 可访问性: Salesforce 提供了一个 REST API, 远程系统可以使用它来:

     • 发布事件以通知你的 Salesforce 组织.
     • 查询你的 Org 中的数据.
     • 创建,更新和删除数据
     • 获得你的 Org 的元数据.
     • 运行实用程序执行管理任务.

   • 同步 API: 在进行 API 调用后, 远程客户端应用程序会等待, 直到它收到来自服务的响应. 不支持对 Salesforce 的异步调用.

   • REST API vs SOAP API: REST 将资源(实体/对象)暴露为 URI, 并使用 HTTP 动词来定义这些资源的 CRUD 操作. 与 SOAP 不同, REST API 不需要预定义的契约, 利用 XML 和 JSON 作为响应, 并且具有松散的类型. REST API 是轻量级的, 为与 Salesforce 交互提供了一种简单的方法. 它的优点包括易于集成和开发, 而且它是与移动应用程序和Web应用程序一起使用的绝佳选择.

   • 安全性: 调用 REST API 的客户端必须有一个有效的登录, 并获得一个会话以执行任何 API 调用. 该 API 遵循 Salesforce 中根据登录用户的配置文件配置的对象级和字段级安全.

   • 事务/提交行为: 默认情况下,每个记录被视为单独的事务,并单独提交.一个记录的更改失败不会导致其他记录更改回滚.可以将此行为修改为 "all or nothing" 的行为.使用 REST API 复合资源可以在一个 API 调用中进行一系列的更新.

   • REST Composite Resources(REST 组合资源): 使用这些 REST API 资源在单个 API 调用中执行多个操作. 还可以使用一个调用的输出作为下一个调用的输入. 所有请求的响应体和 HTTP 状态都以单个响应体返回. 整个请求被视为对 API 限制的单个调用.

   • 批量数据: 包括超过 2,000 条记录的任何数据操作都是使用 Bulk API 2.0 的一个很好的选择,可以成功地准备,执行和管理利用 Bulk 框架的异步工作流.少于2,000条记录的作业可以在 REST(例如: Composite API)或 SOAP 中进行 "批量化" 的同步调用.

   • 事件驱动架构: 平台事件的定义与您定义 Salesforce 对象的方式相同.通过 REST API 发布一个事件与创建 Salesforce 记录的方式是一样的.

3. Apex web services(Fit: Suboptimal)

   Solution:

   • Apex 类的方法可以作为网络服务方法暴露给外部应用程序.这种方法是 SOAP API 的替代品, 通常只在必须满足以下额外要求的情况下使用.

     • 需要完整的事务支持(例如: 在一个事务中创建账户,联系人和机会).
     • 在提交之前, 必须在Salesforce端自定义逻辑.

   • 使用 Apex Web服务的好处必须与在 Salesforce 中需要维护的额外代码进行权衡.

   • 不适用于平台事件, 因为在事件驱动架构中, 消费者的事务预创建逻辑不适用. 要通知 Salesforce 组织发生了一个事件,可以使用 SOAP API, REST API 或 Bulk API 2.0.

4. Apex REST services(Fit: Suboptimal)

   Solution:

   • Apex 类可以作为 REST 资源暴露出来, 映射到特定的 URI 上, 并对其定义了 HTTP 动词(例如: POST 或 GET).

   • 你可以使用 REST API 复合资源,在一个事务中执行多个更新.

   • 与 SOAP 不同,客户端无需消费服务定义/合同(WSDL)并生成客户端存根.远程系统只需要能够构建一个 HTTP 请求并处理返回的结果(XML或JSON).

   • 不适用于平台事件, 因为在事件驱动架构中, 消费者的事务预创建逻辑不适用. 要通知 Salesforce 组织发生了一个事件,可以使用 SOAP API, REST API 或 Bulk API 2.0.

5. Bulk API 2.0 (Fit: Optimal for bulk operations)

   Solution:

   • Bulk API 2.0 基于 REST 原则, 并且针对加载或删除大量数据进行了优化. 它具有与 REST API 相同的可访问性和安全行为.

   • 任何包括超过 2,000 条记录的数据操作都是使用 Bulk API 2.0 的一个很好选择, 可以成功地准备,执行和管理利用 Bulk 框架的异步工作流. 少于2,000条记录的作业可以在 REST(例如: Composite API)或 SOAP 中进行 "批量化" 的同步调用.

   • Bulk API 2.0 允许客户端应用程序通过提交多个批次异步地query, insert, update, upsert, 或删除大量记录,这些记录由 Salesforce 在后台进行处理.相比之下,SOAP API 针对实时客户端应用程序进行了优化,适用于一次更新少量记录的情况.

   • 虽然 SOAP API 也可以用来处理大量的记录,但当数据集包含几十万到几百万条记录时,它就变得不太实用了. 这是由于其相对较高的开销和较低的性能特点造成的.

     • 事件驱动架构: 平台事件的定义与您定义 Salesforce 对象的方式相同.通过 Bulk API 2.0 发布事件与创建Salesforce记录是一样的.只支持创建和插入操作.批处理中的事件在处理批处理作业时以异步方式发布到 Salesforce 事件总线(event bus)上.

Sketch

下图说明了当您使用 REST API 从外部事件发出通知或使用 SOAP API 查询 Salesforce 对象来实现此模式时的事件顺序.使用REST API时,事件的顺序是相同的.

Remote System Querying Salesforce Via SOAP API

Remote System Notifying Salesforce with Events Via REST API

Results

在事件驱动架构中,远程系统使用 SOAP API,REST API或 Bulk API 2.0 调用 Salesforce,将事件发布到Salesforce事件总线.发布事件会通知所有订阅者.事件订阅者可以是 Salesforce 平台上的,如Process Builder, Flow, 或 Lightning组件, Apex触发器. 事件订阅者也可以是 Salesforce 平台的外部人员,如 CometD 的订阅者.

当直接使用Salesforce对象进行工作时,与该模式相关的解决方案可以实现以下功能:

• 远程系统调用 Salesforce 的 API 来查询数据库并执行单对象操作(创建,更新,删除等).
• 远程系统调用 Salesforce REST API 复合资源来执行一系列的对象操作.
• 远程系统调用自定义构建的Salesforce API(服务),能够支持多对象事务操作和自定义的前/后处理逻辑.

Calling Mechanisms

调用机制取决于为实现这一模式而选择的解决方案.

Error Handling and Recovery

必须考虑将错误处理和恢复策略作为整体解决方案的一部分.

• 错误处理: 所有的远程调入方法,标准或自定义API,都需要远程系统处理任何后续的错误,如超时和重试的管理.中间件可以用来提供错误处理和恢复的逻辑.
• 恢复机制 - 如果服务质量要求决定需要创建自定义重试机制,则需要确保幂等设计特性.平台事件使订阅者能够使用 Reply ID 在发布这些消息后的一定时间内获取消息.

Idempotent Design Considerations

幂等性能确保重复调用是安全的, 不会产生负面影响. 如果没有实现幂等性, 那么对相同消息的重复调用可能会产生不同的结果, 可能导致数据完整性问题, 例如创建重复记录, 重复处理事务等.

远程系统在出现错误或超时时,必须处理多个(重复的)调用,以避免重复插入和冗余更新(尤其是如果下游触发器和工作流规则触发).虽然在Salesforce内部可以处理其中一些情况(尤其是自定义SOAP和REST服务的情况),但我们建议远程系统(或中间件)处理错误处理和幂等设计.

Security Considerations

不同的模式解决方案会涉及不同的安全考虑.在所有情况下,该平台都使用已登录用户的访问权限(例如配置文件设置,共享规则,权限集等).此外,可以使用配置文件IP限制来限制对特定IP地址范围的API访问.

参考 Security Considerations.

Sidebars

Timeliness

SOAP API和Apex web service API是同步的.以下是适用的超时时间:

• 会话超时: 如果没有任何活动, 会话就会根据 Salesforce org 的会话超时设置超时.
• 查询超时 - 每个 SOQL 查询都有 120 秒的单独超时限制.

Data Volumes

数据量的考虑取决于你选择哪种解决方案和通信类型:

Endpoint Capability and Standards Support

对 endpoint 的能力和标准支持取决于你选择的解决方案.

State Management

在整合系统时,主键对于持续状态跟踪非常重要,例如: 如果在远程系统中创建了一条记录,以支持对该记录的后续更新.这里有两个选项:

• Salesforce 为远程记录存储远程系统的主键或唯一标识符.
• 远程系统存储 Salesforce 唯一的记录ID或其他唯一的标识符.

在这种同步模式下,处理集成的唯一键有特定的考虑.

Complex Integration Scenarios

在处理复杂的集成场景,例如转换和流程编排时,此模式中的每个解决方案都有不同的考虑因素.

Governor Limits

由于 Salesforce 平台的多租户性质,在使用 API 时存在一些限制.

Reliable Messaging

可靠消息传递旨在解决保证将消息传递到可能不可靠的远程系统的问题.Salesforce SOAP API和REST API是同步的,本身并不提供任何可靠消息协议的显式支持(例如WS-ReliableMessaging).

我们建议远程系统实现一个可靠的消息传递系统,以确保错误和超时情况得到成功处理.从外部系统发布平台事件依赖于Salesforce API,因此SOAP API和REST API的相同考虑因素同样适用.

Middleware Capabilities

下表显示了构建此模式的中间件系统的理想特性.

Example

一家打印耗材和服务公司使用Salesforce作为前端来创建和管理打印机耗材和订单.销售资产记录代表打印机,这些记录会定期从客户现场的打印机管理系统(PMS)中更新打印使用统计数据(墨水状态,纸张水平).一旦达到设定的阈值值(例如,低墨水状态或低于30%的低/空纸张水平),多个对该事件感兴趣的应用程序/进程(可变)会收到通知,发送电子邮件或Chatter警报,并创建一个订单记录.PMS存储Salesforce ID(Salesforce是资产记录主控方).

以下约束条件适用:

• 酒店管理系统(PMS)可以参与基于契约的集成,Salesforce提供契约,而 PMS 作为 Salesforce 服务的客户端(使用企业或合作伙伴WSDL定义).
• 在Salesforce中不应进行自定义开发.

这个例子最好使用 Salesforce的 SOAP API 或 REST API来发布事件,并在 Salesforce 中使用声明性自动化工具.使用平台事件的主要原因是订阅者数量是可变且无限的;然而,对于有限记录列表(如订单)的简单更新,可以使用 SOAP 或 REST API 来更新记录.

在 Salesforce:

• 在 Salesforce 中定义一个平台事件,包含来自 PMS 的通知数据.
• 创建一个由打印机事件通知触发的 Process Builder 流程.该流程更新打印机资产并创建一个订单(使用一个自动启动的流程).
• 下载企业或合作伙伴WSDL,并将其提供给远程系统.

在远程系统:

• 从企业或合作伙伴的 WSDL 创建一个客户存根.
• 使用集成用户的凭据, 通过 OAuth Web服务或 bearer token flow, 对 Salesforce 进行身份验证
• 打印机状态事件发生后,PMS 调用 API 创建打印机状态平台事件(含打印机使用统计数据). Salesforce 事件总线通知 Process Builder 订阅者和所有其他订阅者.

当您使用平台事件时, 事件总线可以在高容量平台事件中回放事件长达72小时.使用中间件解决方案发布这些事件, 可以帮助将错误处理纳入发布方. 但是, 如果需要更高的可靠性,则可以在订阅方实现错误处理.

本例演示了以下内容:

• 实现 Salesforce 的同步API客户端(消费者).
• 将回调发送到 Salesforce 来发布平台事件(与之前介绍的请求/响应平台事件模式相一致).

基于数据变化的UI更新

Context

你使用 Salesforce 来管理客户的案例. 一位客户服务代表正在与一位客户通电话, 处理一个案件. 客户进行了订单支付, 客户服务代表需要在 Salesforce 中看到来自支付处理应用程序的实时更新, 表明客户已经成功地支付了订单的未付金额.

Problem

在 Salesforce 中发生事件时, 用户如何在 Salesforce 用户界面中得到通知, 而无需刷新屏幕导致有可能丢失的工作内容?

Forces

在应用基于这种模式的解决方案时, 有一些因素需要考虑:

• 被操作的数据是否需要存储在 Salesforce 中?
• 是否可以建立一个自定义的用户界面来查看这些数据?
• 用户是否有调用自定义用户界面的权限?

Solution

解决这个集成问题的推荐方案是使用Salesforce Streaming API. 该方案由以下部分组成:

• 一个带有查询定义的PushTopic, 允许你:
  • 指定哪些事件触发更新.
  • 选择在通知中包括哪些数据.
• 基于 JavaScript 的 Bayeux 协议实现(目前为 CometD ), 可供用户界面使用.
• 一个 Visualforce 页面或 Lightning 组件
• 一个作为静态资源的 JavaScript 库

Sketch

下图说明了如何通过实现 Streaming API 将通知传输到 Salesforce 用户界面. 这些通知是由 Salesforce 中的记录更改触发的.

UI Update in Salesforce Triggered by a Data Change

Results

Benefits

与此模式相关的解决方案的应用具有以下好处:

• 消除了编写自定义轮询机制的需求.
• 消除了用户发起反馈循环的需求

Unsupported Requirements

该解决方案有以下局限性:

• 通知的传递不能保证.
• 通知的顺序不能保证.
• 从 Bulk API 所做的记录更改不会生成通知.

Security Considerations

遵守标准的 Salesforce 组织级安全性.建议您使用 HTTPS 协议连接到 Streaming API.请参考 Security Considerations .

Sidebars

最佳的解决方案是在 Salesforce 中创建一个自定义的用户界面. 当务之急是, 你要考虑到一个适当的用户界面容器, 可以用来渲染自定义用户界面. 支持的浏览器在 Streaming API Developer Guide 中列出.

Example

一家电信公司使用Salesforce来管理客户案例. 客户服务经理希望在他们的一个客户服务代表成功关闭一个案例时得到通知.

按照这种模式所规定的解决方案,客户应该:

• 创建一个 PushTopic, 当一个案件被保存为状态为 "关闭" 时, 发送一个通知.
• 创建一个供客户服务经理使用的自定义用户界面. 这个用户界面订阅了 PushTopic 频道.
• 在自定义用户界面中实现逻辑, 显示由该经理的客户服务代表生成的警报.

数据可视化

Context

您使用 Salesforce 来跟踪潜在客户, 管理销售渠道, 创建商机, 并记录将潜在客户转化为客户的订单详细信息. 然而, Salesforce 并不是包含或处理订单的系统. 订单是由外部(远程)系统管理的. 但销售代表希望在不必学习或使用外部系统的情况下, 在 Salesforce 中查看和更新实时订单信息.

Problem

在 Salesforce 中,您如何查看,搜索和修改存储在 Salesforce 之外的数据,而不把数据从外部系统移到 Salesforce 中?

Forces

在应用基于这种模式的解决方案时,有一些因素需要考虑:

• 你想在Salesforce中构建一个声明式/点击式的出站集成或UI混合吗?
• 你是否有大量的数据不想复制到你的 Salesforce 组织?
• 你是否需要在任何时间访问少量的远程系统数据?
• 你需要实时获取最新数据吗?
• 您是否将数据存储在云端或后台系统中, 但想在您的 Salesforce 组织中显示或处理这些数据?
• 您是否对将某些类型的数据存储在Salesforce中有担心?

Solution

下面包含了解决这一集成问题的一些方案.

1. Salesforce Connect(Fit: Best)

   Solution:

   使用 Salesforce Connect 可以访问外部数据源, 以及您的 Salesforce 数据. 无需在 Salesforce 中复制数据, 即可实时从遗留系统(如SAP, Microsoft和 Oracle)中提取数据.

   Salesforce Connect 将外部系统中的数据表映射到您的组织中的 External objects. External objects 类似于自定义对象, 但它们映射的是 Salesforce 组织之外的数据. Salesforce Connect 使用与外部数据的实时连接, 始终保持 External objects 的最新状态. 访问 External objects 会实时从外部系统获取数据.

   Salesforce Connect可以让你:

   • 查询外部系统的数据.
   • 在外部系统中创建,更新和删除数据.
   • 通过列表视图,详细页面,记录动态,自定义标签页和页面布局访问外部对象.
   • 定义外部对象与标准或自定义对象之间的关系,以整合来自不同来源的数据.
   • 在外部对象页面上启用 Chatter feeds, 来进行协作.
   • 运行外部数据的report(有限制).
   • 在 Salesforce 移动应用上查看数据.

   要使用 Salesforce Connect 访问存储在外部系统中的数据, 您可以使用以下适配器之一:

   • OData 2.0 适配器或OData 4.0 适配器 - 连接到任何 OData 2.0 或 4.0 生产者公开的数据.
   • 跨组织适配器 — 连接到存储在另一个 Salesforce 组织中的数据.跨组织适配器使用标准的 Lightning Platform REST API. 与 OData 不同, 跨组织适配器直接连接到另一个组织,而无需中间的 Web 服务.
   • 通过 Apex 创建的自定义适配器--如果 OData 和 cross-org 适配器不适合你的需求,可以用 Apex Connector Framework 开发你自己的适配器.

2. Request and Reply(Fit: Suboptimal)

   Solution:

   使用 Salesforce web service APIs 来进行临时数据请求,以访问和更新外部系统的数据.此解决方案包括以下几种方法:

   使用Salesforce SOAP API. 自定义的 Visualforce 页面或按钮以同步方式发起 Apex SOAP 调用. 在 Salesforce 中, 您可以使用 WSDL 并生成相应的代理Apex类. 该类提供了调用远程服务所需的逻辑. 然后, Visualforce 页面上的用户发起的操作将调用一个Apex控制器, 该动作执行此代理Apex类以执行远程调用.Visualforce页面需要对Salesforce应用程序进行定制.

   使用Salesforce REST API. 自定义 Visualforce 页面或按钮以同步的方式启动 Apex HTTP 调用(REST服务). 在Salesforce中, 你可以使用标准的GET, POST, PUT和DELETE 方法来调用 HTTP 服务. 你可以使用几个HTTP类来与RESTful服务集成. Visualforce页面上的用户发起的动作会调用Apex控制器动作, 执行这些代理Apex类来执行远程调用. Visualforce页面需要对 Salesforce 应用程序进行定制.

   关于这个解决方案的更多信息,请看Remote Process Invocation—Request and Reply.

Sketch

下图说明了如何使用 Salesforce Connect 从外部系统中使用OData适配器获取数据.

在此情况下:

• 浏览器执行一个AJAX调用,进而对应的外部对象适配器执行一个操作.
• 适配器将该操作转换为OData请求,并通过集成和服务层向远程系统发送HTTP GET请求.
• 远程系统通过集成和服务层向Salesforce返回一个JSON响应.
• 该响应从OData转换为外部对象,然后呈现回浏览器.

Results

这种模式相关解决方案的应用允许用户界面发起调用,可以将交易结果显示给最终用户.

调用机制

调用机制取决于为实现这一模式而选择的解决方案.

Error Handling

将错误处理作为整体解决方案的一部分是很重要的. 当错误发生时(异常或错误代码被返回给调用者), 调用者要管理错误处理. Salesforce Connect Validator 是一个免费的工具, 可以运行一些常见的查询, 并关注错误类型和失败原因.

Benefits

使用 Salesforce Connect 解决方案的一些好处包括:

• 这个解决方案不会占用 Salesforce 的数据存储空间.
• 用户不必担心定期在外部系统和 Salesforce 之间同步数据.
• 可以通过 OData,跨组织适配器或使用自定义的 Apex 适配器以最少的代码快速实现声明式设置.
• 用户可以通过外部对象的形式以类似自定义对象的功能访问外部数据.
• 可以使用全局搜索在连接的外部系统中进行联合搜索.
• 可以运行从云端和本地源访问外部数据的报告.请参考下面的考虑事项.

Salesforce Connect Considerations

使用 Salesforce Connect解决方案需要有以下考量:

• 外部对象的行为与自定义对象相同, 但有些功能对外部对象不可用.欲了解更多信息,请参考 Salesforce Compatibility Considerations for Salesforce Connect.
• 外部对象会影响报告的性能.欲了解更多信息,请参考 Report Considerations for Salesforce Connect
• 关于使用Salesforce Connect适配器的其他注意事项, 请参考 Considerations for Salesforce Connect—All Adapters
• 如果您正在考虑使用跨 org 的适配器, 请参考 Considerations for Salesforce Connect—Cross-Org Adapter
• 如果您正在考虑使用 OData 适配器, 请参考 Considerations for Salesforce Connect—OData 2.0 and 4.0 Adapters
• 如果你考虑使用自定义 Apex 适配器, 请参考 Considerations for Salesforce Connect—Custom Adapter

Security Considerations

该模式的解决方案应符合 Salesforce org 级安全标准.建议您使用 HTTPS 协议连接到任何远程系统.有关详细信息,请参考 Security Considerations.

如果您正在使用 OData 连接器,请确保您了解 OData 外部数据源上的跨站请求伪造(CSRF)的特殊行为,限制和建议.有关更多信息,请参考 CSRF Considerations for Salesforce Connect — OData 2.0 and 4.0 Adapters.

Sidebars

Timeliness

及时性在这种模式中很重要.请记住以下几点:

• 该请求通常是从用户界面调用的,因此处理过程不能让用户等待.
• 根据外部系统的可用性和连接情况,检索外部数据可能需要很长时间.Salesforce 最大超时值为120秒,用于等待外部系统的响应.
• 远程过程的完成应该及时执行,并在 Salesforce 的超时限制和用户的期望范围内完成.

Data Volumes

这个模式主要用于小的数据容量,实时活动, 因为它的超时值较小, Apex 调用请求或响应的最大超时也有限制. 在数据有效载荷包含在消息中的批处理活动中,不要使用这种模式.

Endpoint Capability and Standards Support

端点的功能和标准支持取决于您选择的解决方案.

State Management

集成系统时,密钥对于持续状态跟踪很重要. 例如: 如果在远程系统中创建了一条记录, 通常该记录需要某种唯一标识符来支持正在进行的更新. 这里有两个选项:

• Salesforce 存储远程记录的主键或唯一标识符.
• 远程系统存储 Salesforce 唯一记录ID或其他唯一的标识符. 在这种同步模式下, 处理集成键需要特定的考虑.

Complex Integrations

在某些情况下, 这种模式所规定的解决方案可能需要实现复杂的集成场景. 这些场景通常通过中间件来解决. 这些场景包括:

• 跨多个系统的调用和调用结果的聚合
• 对传入和传出消息的转换
• 在调用多个系统时保持事务完整性
• 在 Salesforce 和外部系统之间进行其他流程编排活动

Governing Limits

不同的限制适用于不同的适配器.欲了解更多详情,请参考 General Limits for Salesforce Connect

Middleware Capabilities

下表强调了参与这种模式的中间件系统的理想属性.

External Object Relationships

外部对象支持标准的查找关系, 它使用 18 个字符的 Salesforce 记录 ID 来关联相关记录. 然而, 存储在您的 Salesforce 组织之外的数据往往不包含这些记录ID. 因此, 有两种特殊类型的查找关系可用于外部对象:外部查找和间接查找.

这个表格总结了对外部对象可用的关系类型.

High Data Volume Considerations for Salesforce Connect—OData 2.0 and 4.0 Adapters

如果你的组织在访问外部对象时遇到速率限制, 考虑在相关的外部数据源上选择高数据量选项. 这样做可以绕过大多数速率限制, 但也有一些特殊的行为和限制. 欲了解更多信息,请参考 High Data Volume Considerations for Salesforce Connect

Client-Driven and Server-Driven Paging for Salesforce Connect—OData 2.0 and 4.0 Adapters

外部数据的 Salesforce Connect 查询通常会有一个很大的结果集,该结果集被分成较小的批次或页面. 您决定是由外部系统(服务器驱动)还是由 Salesforce Connect 的 OData 2.0 或 4.0 适配器(客户端驱动)控制分页行为. 外部数据源上的 Server Driven Pagination 字段指定是使用客户端驱动的分页还是服务器驱动的分页. 如果您在外部数据源上启用服务器驱动的分页,Salesforce 将忽略请求的页面大小,包括 500 行的默认 queryMore() 批处理大小. 外部系统返回的页面决定批次,但每页不能超过2000行. 但是, Salesforce Connect 的 OData 适配器的限制仍然适用.

Example

一家制造公司使用 Salesforce 来管理客户个案. 客户服务代理希望从后台 ERP 系统访问实时订单信息,以 360 度全方位了解客户,而无需学习和手动在 ERP 中运行报告.

实施此模式规定的解决方案, 您应该:

• 使用 OData 端点配置外部数据源. 您的远程应用程序可能包含对 OData 的本机支持. 对于其他应用程序, Dell Boomi, Informatica, Jitterbit, MuleSoft 和 Progress Software 等主要集成供应商已在 Salesforce Connect 上与 Salesforce 合作构建适配器.
• 直接或通过中间件解决方案,将 Salesforce Connect 指向 OData 端点.
• 将您的外部数据库表与 Salesforce 中的外部对象同步. 当用户访问包含来自这些外部对象的数据的页面时, Salesforce Connect 会实时调用您的后端应用程序.

附录

资源-外部

1. Hohpe, Gregor, and Bobby Woolf. Enterprise Integration Patterns. Boston: Addison-Wesley Professional, 2003.
2. Microsoft Corporation. Integration Patterns (Patterns & Practices). Redmond: Microsoft Press, 2004.
3. Synchronous vs. Asynchronous Communication in Applications Integration, MuleSoft, last accessed March 18, 2019, https://www.mulesoft.com/resources/esb/applications-integration.
4. Hub and Spoke [or] Zen and the Art of Message Broker Maintenance, Enterprise Integration Patterns, last accessed March 18, 2019, http://www.eaipatterns.com/ramblings/03_hubandspoke.html.

资源-Salesforce

Developer Documentation

• Salesforce Help: Give Integration Users API Only Access
• SOAP API Developer Guide
• REST API Developer Guide
• Streaming API Developer Guide
• Bulk API 2.0 and Bulk API Developer Guide
• Apex Developer Guide
• SOQL and SOSL Reference
• Salesforce Developer Limits and Allocations Quick Reference
• Platform Events Developer Guide
• Apex Developer Guide: Salesforce Connect

Trailhead

• Large Data Volumes
• Platform Events Basics
• Change Data Capture Basics
• Salesforce Connect
• Quick Start: Salesforce Connect

安全方面的考虑

为了成为企业组合中有效的成员,所有应用都必须与相关的安全机制创建和集成.现代IT策略采用本地和基于云的服务的组合.

虽然将云对云服务整合通常侧重于Web服务和相关授权,但连接本地和云服务经常会引入更高的复杂性.本节描述了安全工具,技术和Salesforce特定考虑事项.

Reverse Proxy Server

反向代理是位于 Web 服务器前面的服务器,将客户端(例如Web浏览器)的请求转发给这些 Web 服务器.反向代理通常用于增加安全性,性能和可靠性. ¹

它是 一种代理服务器类型, 代表客户端从一个或多个服务器上检索资源. 然后将这些资源返回给客户端, 就好像它们源自代理服务器本身. 与正向代理不同, 正向代理是其相关客户端联系任何服务器的中间人, 而反向代理是其相关服务器被任何客户端联系的中间人. ²

在 Salesforce 实施中, 通常通过外部网关产品提供此类服务.例如,可以使用开源选项, 如 Apache HTTP, lighttpd 和 nginix. 商业产品包括 IBM WebSeal 和 Computer Associates SiteMinder. 这些产品可以很容易地被配置为代表内部请求者代理和管理所有出站的 Salesforce 请求.

Encryption

一些企业需要在内部部署和基于云的应用程序组合之间对选定的交易或数据字段进行加密. 如果您的组织必须遵守额外的合规性要求, 您可以实施替代方案,包括:

• 企业内部的商业加密网关服务,包括 Salesforce自己的,CipherCloud,IBM DataPower,Computer Associates. 对于每个解决方案, 在 HTTP(S) 请求执行之前, 通过发送和接收加密的有效负载或在加密或解密特定数据字段时在事务边界调用加密引擎或网关.
• 基于云的选项,例如Salesforce Shield Platform Encryption.Shield Platform Encryption为您的数据提供了一个全新的安全层,同时保留了关键的平台功能.使用先进的密钥派生系统,您选择的数据在静止状态下进行加密.您可以比以往更安全地保护数据.有关更多信息,请参考 Salesforce online help.

Specialized WS-* Protocol Support

为了满足安全协议(如WS-*)的要求,我们推荐这些替代方案.

• Security/XML 网关--将 WS-Security 凭证(IBM WebSeal或 Datapower, Layer7, TIBCO等)注入到事务流本身. 这种方法不需要改变应用程序级别的 Web 服务或来自 Salesforce 的 Web 服务调用. 你也可以在整个 Salesforce 安装中重复使用这种方法. 然而, 它需要额外的设计,配置,测试和维护, 以管理适当的 WS-Security 注入到现有的安全网关方法.

• 传输级加密——使用双向 SSL 和 IP 限制加密通信通道. 虽然这种方法本身并不直接实施 WS-* 协议, 但它可以保护本地应用程序和 Salesforce 之间的通信通道, 而无需传递用户名和密码. 它也不需要更改 Salesforce 生成的类. 但是, 可能需要对本地 Web 服务进行一些修改(在应用程序本身或中间件/ESB 层).

• Salesforce 自定义开发—通过 WSDL2Apex 工具将 WS-Security 标头添加到出站 SOAP 请求. 这会从用于调用内部服务的 WSDL 文件生成一个类 Java 的 Apex 类. 虽然此方法不需要更改后端 Web 服务或 DMZ 中的其他组件,但它确实需要:

• 增加构建和测试的工作量

• 在 Apex 代码中手工编写 WS-Security 属性(包括XML序列化)是一个相对复杂和繁琐的过程.

• 更多的长期维护工作

Note:

最后一种选项不推荐，因为它过于复杂，并且此类集成需要根据Salesforce的定期更新进行定期审查.

¹ What Is a Reverse Proxy?, Cloudflare, last accessed April 11, 2019, https://www.cloudflare.com/learning/cdn/glossary/reverse-proxy/.

² Reverse proxy, Wikipedia, last accessed April 11, 2019, http://en.wikipedia.org/wiki/Reverse_proxy

事件驱动架构

Salesforce企业消息平台(EMP)通过平台事件, Streaming API 和 Change Data Capture(CDC) 使企业能够创建基于事件驱动的架构(EDAs).

EDA将事件消息消费者(订阅者)与事件消息生产者(发布者)解耦,从而实现更大规模和灵活性, 具体的模式在本文中被作为现有模式结构的一部分, 比较和对比相关的备选方案或选项, 然而,全面了解事件驱动架构以及模式之间的相互作用有助于您选择适合您需求的正确模式.