salesforce Integration 概览(一) 杂篇

本篇参考：https://resources.docs.salesforce.com/sfdc/pdf/integration_patterns_and_practices.pdf

我们在做salesforce的集成的实施的时候，不可避免地要和其他系统进行交互。因为一个稍微大一点的企业也很少会将公司的所有的内容和数据都放在salesforce一个平台。所以涉及到集成的时候，如何去选，怎么去做，也变得很重要。我们在做项目的时候，不可能大项目还是小项目涉及到集成，第一件事想的就是：好啊，那我暴漏一个restful接口吧或者我写一个 http callout来访问你们吧。对于实施人员来说，按时并且高质量交付肯定是重中之重，对于自己来说，多掌握一些集成知识以及方法论可以让你在涉及到多个系统之间操作时更加游刃有余，而不是 100%的走自定义接口这个“正确”但是不一定高效的方案。

一. 通过关键要素确定官方推荐的集成模式

我们在考虑集成方案以前，通常需要评估以下几个要素（不一定全面，但是基本是做集成都需要思考,比如数据量等）

Source / Target： 这个很好理解，salesforce系统针对某个表或者某个功能是作为源系统还是目标系统。这个定义关系到数据流向性以及以哪个系统作为MDM，不同的设置也可能考虑不同的effort，比如是否需要中间件等等。

Timing： 实时性更会影响方案的选择。你的这个集成要求是同步还是异步

Type： 指定集成的样式：流程、数据或可视化。

•基于流程的集成可以定义为跨两个或多个应用程序集成功能流处理的方法。这些集成通常涉及更高级别的抽象和复杂性，尤其是事务性和回滚，涉及到编排情况下还需要引入中间件。这些类型的集成通常需要复杂的设计、测试和异常处理需求。此外，此类复合应用程序通常对底层系统的要求更高，因为它们通常支持长时间运行的事务以及报告和/或管理流程状态的能力。

•数据集成可以定义为应用程序所使用信息的集成。这些集成可以是简单的表插入或upsert，也可以是需要引用完整性和复杂转换的复杂数据更新。数据集成通常是要实现的最简单的集成类型，但需要适当的信息管理技术才能使解决方案具有可持续性和成本效益。这些技术通常包括主数据管理（MDM）、数据治理、主控、重复数据消除、数据流设计等方面；

•可视化集成可定义为Salesforce能够与驻留在外部系统中的数据交互，而无需在Salesforce内复制数据的集成。此类集成始终通过Salesforce平台的事件触发，例如，用户操作、工作流、搜索、更新记录，从而实现与外部源的实时数据集成。

针对上述三个因素可以做出来一个矩阵图来决定满足什么样的要素应该选择哪种或者哪些集成模式。

我们实际项目中用到最多的就是数据集成，其次是基于流程的集成。篇中介绍了好几种的集成模式，篇中上面的连接中包含这几种模式的所有的详细介绍，感兴趣的小伙伴可以先行理解，后续也会针对每个集成模式整理一篇博客，不过都是照本宣科了，还是建议自行查看。

二. 中间件的使用场景和介绍

先想象一下，我们在实际工作中最常用到的中间件的场景有哪些呢？我们先简单的以一个UML用例图作为引子。

我们在项目中使用到的中间件的场景通常有两个： 编排 & error handling

编排：SFDC的数据库的表和外部系统肯定有差距，而且复杂场景可能层级结构也不一样，这个时候就涉及到数据的编排，通过中间件转换成符合对端系统的结构。

errror handling：涉及到多个系统的集成，那么错误处理就是不可逃避的话题。如果两个系统相对简单，可以不用使用到中间件，但是如果这两个系统处理特别复杂，不同场景需要进行不同的处理，可能还要涉及到不断的轮询监听订阅等等操作，这个时候使用中间件作为错误处理的中转站是最好不过了。比如 SFDC端通过 push topic或者platform event去进行数据的推送，外部系统需要接收和同步。这种scenario就特别适合引入中间件。中间件负责轮询订阅，如果涉及到不同的error进行相关的记录或者二次操作或者其他操作等等。正确订阅到编排好制定的结构发送到其他下游系统即可。

当然，涉及到集成的项目，中间件除了使用在以上的常用场景以外，还可以做很多的事情，官方文档的描述如下：

• 确定事件应该转发到哪里
• 执行该转发的操作
• 接收一个转发的事件
• 采取相关的响应的操作。比如写入日志、发送错误或恢复过程，或发送额外消息。

这个中间件的特性我们通常应用于广播订阅(publish / subscription)模型下。在发布/订阅场景中，中间件将请求或者消息从事件发布服务器(publisher)路由到事件订阅服务器（subscriber）。这些具有监听器的消费者(consumer)可以在事件发布时检索这些事件。 这里举一个例子进行描述。salesforce针对 Account是 MDM，Account的数据需要接近实时的方式去同步给下游的三个系统，下游的三个系统都需要根据Salesforce的Account变化所推送的数据更新自己相关的内容。这里 salesforce使用了 PushTopic或者 Change Data Capture，这个时候就需要引入中间件。中间件的工作就是作为订阅者订阅salesforce发布的 pushtopic，然后监听检索salesforce发的事件，然后进行响应以后转发给下游的三个系统。 协议转换 协议转换 通常是一种软件应用程序，它将一个设备的标准或专有协议转换为适用于另一个设备的协议，以实现互操作性。在中间件的上下文中，到特定目标系统的连接可能受到协议的约束。在这种情况下，需要将消息格式转换为目标系统的格式或封装在目标系统的格式中，在目标系统中可以提取有效负载。 Salesforce不支持本地的协议转换，因此假定中间件层或endpoint都能满足任何此类需求。 翻译与转换 转换是将一种数据格式映射到另一种数据格式的能力，以确保集成的各种系统之间的互操作性。通常，这需要在发送途中重新格式化报文的消息，以符合发送方以及接收方的要求。在更复杂的情况下，一个应用程序可以以自己的本机格式发送消息，而另外两个或多个应用程序可能各自以自己的本机格式接收消息的副本。中间件转换和转换工具通常包括为遗留或其他非标准端点创建服务外观的能力；这使得这些端点看起来是服务可寻址的。 在Salesforce集成中，假设中间件层或endpoint满足任何此类需求。数据转换可以在Apex中进行编码，但出于维护和性能考虑，我们不建议这样做。 当然在实际的工作场景中，我们也需要去实际的case by case的分析是否需要引入中间件，如果只是为了转换格式，并且对接的上下游都高可定制化，我们也可以通过 apex进行编码处理，这样也省了中间件的成本。如果通过apex来做，我们就需要考虑到其他的隐性的成本，比如 error handling，可扩展性等等。 排队和缓冲 排队和缓冲通常依赖于异步消息传递，而不是请求-响应体系结构。在异步系统中，当目标程序繁忙或连接受损时，消息队列提供临时存储。此外，大多数异步中间件系统提供持久存储来备份消息队列。异步消息处理的主要好处是，如果接收方应用程序因任何原因失败，发送方可以继续不受影响；发送的消息只是在消息队列中累积，以便在接收方重新启动时进行后续处理。 Salesforce仅以基于workflow的outbound message的形式提供显式排队功能。如果针对其他集成场景（包括编排、流程编排、服务质量等）提供真正的消息队列，需要一个中间件解决方案。 同步传输协议 同步传输协议指的是支持以下活动的协议：“调用者中的单个线程发送请求消息，block住，等待消息返回，然后处理response…” 等待响应的请求线程意味着只有一个未完成的请求，或者此请求的回复通道对此线程是专用的。 异步传输协议 异步传输协议是指支持活动的协议，其中“调用者中的一个线程发送请求消息并为应答设置回调”。一个单独的线程侦听回复消息。当回复消息到达时，回复线程调用相应的回调，该回调重新建立调用方的上下文并处理回复。这种方法允许多个未完成的请求共享一个回复线程。 中介和路由 中介路由是从组件到组件的复杂消息“流（flow）”的规范。举个例子，许多基于中间件的解决方案依赖于消息队列系统。虽然一些实现允许由消息传递层本身提供路由逻辑，但另一些实现依赖于客户机应用程序来提供路由信息或允许这两种范例的混合。在这种复杂的情况下，中介（中间件的一部分）简化了开发、集成和验证。 流程编排和服务编排 流程编排和服务编排是“服务组合”的每一种形式，其中协调了任意数量的端点和功能。编排和服务编排的区别在于： •流程编排可以定义为“由一组相互作用的个体实体产生的行为，没有中央权威。” •服务编排可以定义为“由中央指挥协调独立执行任务的各个实体的行为而产生的行为。” 此外，“服务编排显示每个服务的完整行为，而流程编排结合了每个服务的接口行为描述。” 业务流程编排的一部分可以在Salesforce工作流中构建，也可以使用Apex。由于Salesforce超时值和Government limitation（特别是在需要真正事务处理的解决方案中），我们建议在中间件层实现所有复杂的业务流程。 事务性（加密、签名、可靠传递、事务管理） 事务性可以定义为支持全局事务的能力，该全局事务包含针对每个所需资源的所有必要操作。事务性意味着对所有四个ACID（原子性、一致性、隔离性、持久性）属性的支持，其中原子性保证工作单元（事务）的所有结果或无结果。虽然Salesforce本身是事务性的，但它不能参与分布式事务或在Salesforce之外发起的事务。因此，假设对于需要复杂、多系统事务的解决方案，事务性（以及相关的回滚/补偿机制）可以在中间件层实现。 路由 路由可以定义为指定从组件到组件的复杂消息流。现代服务、基于内容的服务、基于规则的解决方案的数量和类型。在Salesforce集成中，假设中间件层或端点（endpoint）满足任何此类需求。消息路由可以在Apex中进行编码，但出于维护和性能考虑，我们建议可以使用中间件。 ETL（提取、转换和加载） Extract, transform, and load（ETL）是指涉及以下内容的过程： •E: 从源系统提取数据。通常，涉及多个关系型系统和非关系型数据源。 •T: 转换数据以满足运营需求，包括数据质量级别。转换阶段通常将一系列规则或函数应用于从源提取的数据，以导出数据以加载到最终目标。 •L: 将数据加载到目标系统中。目标系统可能与数据库、操作数据存储、数据集市、数据仓库或其他操作系统存在很大差异。 大多数成熟的ETL工具都提供了变更数据捕获功能，但这并不是绝对必要的。此功能用于工具识别源系统中自上次提取以来已更改的记录，从而减少记录处理量。Salesforce现在还支持Change Data Capture(可看前一节)。通过CDC，客户机或外部系统几乎实时地接收Salesforce记录的变更。这允许客户端或外部系统同步外部数据存储中的相应记录。 长轮询 长轮询，也称为Comet编程，模拟从服务器到客户端的信息推送。与普通轮询类似，客户端连接服务器并从服务器请求信息。但是，如果信息不可用，服务器将保留请求并等待信息可用（事件发生），而不是发送空响应。然后，服务器向客户端发送一个完整的响应。然后，客户机立即重新请求信息。客户端持续维护与服务器的连接，因此它总是等待接收响应。如果服务器超时，客户端将再次连接并重新启动。Salesforce Streaming API使用Bayeux协议，Comet用于长轮询。 •Bayeux是一种主要通过HTTP传输异步消息的协议。 •Comet是一种可扩展的基于HTTP的事件路由总线，它使用一种称为Comet的AJAX推送技术模式。它实现了Bayeux协议。

很巧合的是，我们的新项目就是salesforce使用 Streaming API的 push topic，下游系统需要接近实时的同步数据，因为下游系统不支持长轮询，这个时候就需要中间件。考虑中间件的几个特性中就有 事件处理，翻译转换以及长轮询。不同项目不同场景不同复杂度会有不同的思考和设计。如果需要引入中间件，考虑一下官方的介绍中哪些是让你不得不或者使用以后会有很大的性能提升的原因。

三. Salesforce的几个集成模式的简单介绍

我们在图一中可以看到Salesforce建议的集成模式，那他们大概什么意思，什么场景使用呢？ 后续针对每个集成模式都会有一个博客来介绍，本篇只是基于一个high level的介绍，语言好的小伙伴可以直接查看上面的文档，里面拥有官方推荐的全量文档信息。

1. Remote Process Invocation—Request and Reply远程进程调用--请求和响应： Salesforce调用远程系统上的进程，等待该进程完成，然后根据远程系统的响应跟踪状态。

这个在实际场景中是经常用到的，salesforce call外部系统并且等待结果返回，并根据结果做相关的处理，这个过程是同步进行的，要求服务器端立刻返回信息。

举个例子：

一家公司，他使用Salesforce的 Sales Cloud进行 Opportunity的管理。当 Opportunity状态为 Close Won的时候，需要生成一条订单信息，但是这个订单信息的订单号需要由外部系统来生成，针对这种场景，我们就需要使用 请求和响应的模式，同步的等待订单号结果回来以后，生成我们的订单数据。

2. Remote Process Invocation—Fire and Forget远程进程调用-发后即弃： Salesforce调用远程系统中的进程，但不等待进程完成，而是由远程进程接收并确认请求，然后将控制权交回Salesforce。

这个在实际场景中同样经常用到的，salesforce call外部系统，区别上面的模式即为这个模式call出去获取一个call成功的状态即可，并不要求response立马返回就可以做其他的事情。举个例子：

Salesforce系统和外部系统进行交互，外部系统没法提供一个实时的 rest api,他的操作时间可能是10分钟操作一次，这样没法通过同步来搞回来，因为这个超过了 callout的 time limit，我们可能需要 call出去，外部系统如果收到了就会返回一个response,我们也可以在暴露一个 restful api,后续他们搞定以后，将response调用给salesforce系统。这种case下，结果不是及时的返回，salesforce只要保证发出去即可。

3. Batch Data Synchronization 批量数据同步：批处理的方式来实现 SF->外部或者外部->SF数据的一致性。

举个例子：

外部系统每晚通过ETL等方式将Lead批量导入到SF端。

4. Remote Call-in： 存储在Lightning Platform中的数据由远程系统创建、检索、更新或删除。

举个例子：

一个公司，他的销售都是通过手机移动端去进行相关的业务操作，比如拜访客户等等。通过IOS/Android或者企业微信等作为前台操作数据，操作的数据都是SF端的信息，通过标准的rest api即可实现 客户端作为入口。

5. UI Update Based on Data Changes：Salesforce用户界面必须由于Salesforce数据的更改而自动更新。

举个例子：业务要求当一个 end user访问某个页面时，在这个页面停留的过程中，如果salesforce的数据库关键字段更改以后，end user不需要刷新页面的情况下，也可以实时的看到最新的数据库的值，而不是最开始加载的值。

6. Data Virtualization 数据可视化： Salesforce实时访问外部数据。这样就不需要在Salesforce中保存数据，然后在Salesforce和外部系统之间协调数据。这个在实际的工作中还是很可能遇见的，比如一个系统的数据很重要也很庞大，不允许或者不需要存储在外部的系统，并且还需要展示在salesforce系统中，展示的数量不多。

举个例子：

一家制造公司使用Salesforce来管理Opportunity。客户服务代理希望访问来自后台ERP系统的实时订单信息，以获得客户的360度视图，而无需在ERP中学习和手动运行报告。因为订单信息存储在ERP系统，不想将这部分数据同步到salesforce，也想查看相关数据信息，便可以使用此种集成模式。

总结：

本篇只是杂谈，简单的写一下集成项目中中间件的特性以及什么场景下使用，集成中salesforce推荐的几种集成模式。篇中还没有详细的描述集成模式因为内容特别多，后续每个集成模式争取都抽出一个章节进行讲解。本篇只是说一下这些概念以及满足什么特点应该选择哪个集成模式。概念性内容多，实际性内容建议大家自行查看上面的官方文档先自行了解。篇中有错误欢迎指出，有不懂欢迎留言。