Salesforce Integration 概览(三) Remote Process Invocation—Fire and Forget（远程进程调用-发后即弃）

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

咱们在上一篇讲了远程进程调用--请求和响应模式，这种模式用于处理同步的场景。固然这个场景不仅是对salesforce有要求，同时对对方的系统有很大的要求，好比并发性，实时性等等。咱们在项目中除了这种同步的场景之外，异步的场景一样常用。今天咱们就讲一下针对salesforce callout外部系统，不须要对方实时返回消息的场景。

一. 上下文

其实经过上面的描述中咱们大概已经能联想到咱们实际的应用的上下文。这里变动一下上一篇的场景

您可使用Salesforce跟踪销售线索、管理销售渠道、建立销售机会，并捕获将销售线索转换为客户的订单详细信息。可是，Salesforce系统不包含或处理订单。在Salesforce中捕获订单详细信息后，将在远程系统中建立订单，该系统将管理订单直至结束。

当您实现此模式时，Salesforce调用远程系统来建立订单，salesforce只要确保报文发送过去，而且对端系统返回一个response OK了，就能够，至于具体的订单号，salesforce的系统不存储也不care，不影响后续的流程性。

经过这个描述，咱们就能够清楚了这个case是Opportunity Close Won建立订单，订单发送到外部系统之后，不用管外部系统怎么处理，咱们只须要保证发出去对方收到就行了。

二. 问题和考虑因素

问题： 当一个事件从salesforce触发时，如何在远程系统中启动流程并将所需信息传递给该流程，而无需等待远程系统的响应？

考虑因素：在基于此模式应用解决方案时须要考虑如下因素。

　　•对远程系统的调用是否要求Salesforce在继续处理以前等待响应？对远程系统的调用是同步的仍是异步的？

　　•若是对远程系统的调用是同步的，那么Salesforce是否须要将响应做为调用的同一事务的一部分进行处理？

　　•消息大小是否较小？

　　•集成是否基于特定事件的发生，例如Salesforce用户界面中的按钮点击，或基于DML的事件？

　　•保证Salesforce向远程系统发送消息是一项要求吗？

　　•远程系统是否可以参与Salesforce指定合同的合同优先集成？在某些解决方案变体（例如，出站消息传递）中，Salesforce指定远程系统端点实现的约定。

　　•端点(endpoint)或企业服务总线（ESB）是否支持长轮询？

　　•声明性配置方法是否优于定制Apex开发？在这种状况下，平台事件等解决方案优先于Apex标注。

三. 解决方案

针对此种模型salesforce给咱们推荐了相关的解决方案，适配度是一方面，还要考虑公司预算，对端系统的支持能力以及resource等等。

解决方案	适配度	详细介绍
基于流程驱动的Platform Event	Best	此种方式不须要额外的自定义工做。Platform Event是应用程序发送和接收的事件消息（或通知），以采起进一步的操做。Platform Event简化了传递更改和响应更改的过程，而无需编写复杂的逻辑，咱们能够经过 Process 或者 Flow去发布事件。一个或多个订阅端能够侦听同一事件并执行操做。
基于自定义驱动的 platform events	Good	和基于流程驱动的 Platform Event相似，区别就是Event须要由Apex或者 Trigger进行触发
Workflow驱动的 outbound messaging	Goods	Salesforce中不须要定制就能够实现出站消息传递。对于这种类型的集成，建议的解决方案是从insert或update事件调用远程进程。Salesforce提供了工做流驱动的出站消息传递功能，容许将SOAP消息发送到由Salesforce中的插入或更新操做触发的远程系统。这些消息是异步发送的，而且独立于Salesforce用户界面。   Outbound message被发送到特定的远程端点。远程服务必须可以参与Salesforce提供契约的contract-first集成。在收到消息后，若是远程服务没有以确定的确认作出响应，Salesforce将重试发送消息，从而提供一种保证传递的形式。outbound message发送的消息的顺序是按照顺序的。 详情能够参看：https://developer.salesforce.com/docs/atlas.en-us.api.meta/api/sforce_api_om_outboundmessaging_understanding.htm
Outbound messaging and callbacks	Goods	回调提供了一种减轻无序消息传递影响的方法。此外，它们处理这些场景。   •幂等性—若是未及时接收到确认，则出站消息将执行重试。能够向目标系统发送多条消息。使用回调能够确保检索到的数据是在特定的时间点，而不是在发送消息时。 •检索更多数据—单个出站消息只能发送单个对象的数据。回调可用于从其余相关记录（如与父对象关联的相关列表）检索数据。出站消息提供了一个惟一的SessionId，您能够将其用做身份验证令牌，用soapapi或restapi对回调进行身份验证和受权。执行回调的系统不须要单独向Salesforce进行身份验证。而后可使用任一API的标准方法来执行所需的业务功能。此变体的典型用法是Salesforce向远程系统发送出站消息以建立记录。回调使用在远程系统中建立的记录的惟一键更新原始Salesforce记录。
自定义Lightning组件或Visualforce页启动Apex SOAP或HTTP异步调用	Suboptimal	此解决方案一般用于基于用户界面的场景，但须要定制。此外，解决方案必须处理代码中消息的有保证传递。相似于远程进程调用请求和应答模式解决方案，该解决方案指定使用Visualforce页面或Lightning组件以及Apex callout。不一样之处在于，在这种模式中，Salesforce不会等到请求完成后才将控制权交给用户。   接收到消息后，远程系统响应并指示接收到消息，而后异步处理消息。远程系统在开始处理消息以前将控制权交回Salesforce；所以，Salesforce没必要等待处理完成。（实际项目中可能采用最多的状况）
从Salesforce数据更改调用的Trigger执行Apex SOAP或HTTP异步调用	Suboptimal	可使用Apex Trigger根据记录数据更改执行自动化。 Apex代理类能够经过使用Apex Trigger做为DML操做的结果来执行。可是，从触发器上下文中发出的全部调用都必须异步执行。
Batch apex来执行Apex SOAP或HTTP异步	Suboptimal	能够从batch apex中对远程系统调用。此解决方案容许批处理远程进程执行和批处理Apex做业，这些做业执行Apex SOAP次优调用或HTTP异步调用，以处理Salesforce中远程系统的响应。可是，对于给定的批处理上下文，调用的次数是有限制的。

 四. 流程草图

1.远程系统订阅了这个 Platform Event
2.salesforce一组记录新增或者修改
3.trigger触发
4. 这个process触发了platform event
5.远程系统侦听器接收事件消息，并将消息放在本地队列中
6.排队应用程序将消息转发给远程应用程序进行处理。

在远程系统必须对Salesforce执行操做的状况下，能够实现可选的回调操做。

五. 其余关键点

1. 调用机制

调用机制取决于为实现此模式而选择的解决方案。应用与此模式相关的解决方案能够：

•用户界面–启动的远程进程调用，其中事务的结果能够显示给最终用户

•DML事件启动的远程进程调用，调用进程能够处理事务的结果

 针对这两个实际的方式咱们能够选择如下的调用场景

调用机制	描述
Process Builder	用于流程驱动和定制驱动的解决方案。事件触发Salesforce进程，而后该进程能够发布平台事件以供远程系统订阅。
Lightning组件或Visualforce和Apex Controller	用于使用Apex callout异步调用远程进程。
Workflow rules	仅用于outbound message解决方案。建立和更新DML事件触发Salesforce工做流规则，而后该规则能够向远程系统发送消息。
Apex triggers	用于trigger驱动的Platform Event和远程进程调用，由DML来启动事件的Apex调用。
Apex batch classes	用于在批处理模式下调用远程进程。

 2.Error处理和恢复。针对一个集成项目， error handling & recovery是特别核心的须要考虑的点。针对选择的解决方案列出了推荐的处理方式。

解决方案	Error处理和恢复战略
Apex Callout	错误处理—远程系统不处理对结束进程的调用，所以callout只处理远程服务初始调用中的异常。例如，若是没有收到来自远程调出的确定确认，则会触发超时事件。当初始调用被传递给异步处理时，远程系统必须处理随后的错误。 恢复处理—在这种状况下，恢复更为复杂。若是服务质量要求要求，则必须建立自定义重试机制。
Outbound messaging	错误处理—因为此模式是异步的，因此远程系统将处理错误处理。对于出站消息传递，Salesforce会在超时时间内（最多24小时）未收到确定的确认时启动重试操做。必须在远程服务中执行错误处理，由于消息以“Fire And Forget”的方式有效地传递给远程系统。 恢复—因为此模式是异步的，系统必须根据服务的服务质量要求启动重试。对于出站消息传递，若是在超时时间内（最多24小时）未收到来自出站侦听器的确定确认，Salesforce将启动重试。重试间隔随时间呈指数增加，从15秒间隔开始，到60分钟间隔结束。经过向Salesforce支持部门提出请求，能够将超时时间延长到7天，但自动重试时间限制为24小时。24小时后全部失败的邮件都将放入队列中，管理员必须监视此队列中超过24小时传递期限的任何邮件，并在必要时手动重试。
Platform Events	错误处理—必须由远程服务执行错误处理，由于事件被有效地传递给远程系统进行进一步处理。由于此模式是异步的，因此远程系统处理消息队列、处理和错误处理。此外，平台事件不会在数据库事务中处理。所以，已发布的平台事件没法在事务中回滚。 恢复—因为此模式是异步的，远程系统必须根据服务的服务质量要求启动重试。与每一个事件关联的 replay ID是原子的，而且随着每一个已发布事件的增长而增长。此ID可用于重放特定事件的流（例如，基于上次成功捕获的事件）。高容量平台事件消息存储72小时（三天）。使用CometD客户端订阅通道时，能够检索过去的事件消息。

 3.安全注意事项： 对远程系统的任何调用都必须保持请求的机密性、完整性和可用性。根据您选择的解决方案，应用不一样的安全考虑。

解决方案	安全考虑
Apex callouts	•对远程系统的调用必须保持请求的机密性、完整性和可用性。如下是在这种模式中使用apexsoap和HTTP调用的安全注意事项。   •默认状况下启用单向SSL，但自签名和CA签名证书都支持双向SSL，以保持客户端和服务器的真实性。 •Salesforce在生成Apex代理类时不支持WS-Security。在必要时，考虑使用APEX密码类方法使用单向散列或数字签名，以确保请求的完整性。 •必须经过实施适当的防火墙机制来保护远程系统。
Outbound Messaging	对于出站消息传递，默认状况下启用单向SSL。可是，双向SSL能够与Salesforce出站消息传递证书一块儿使用。如下是一些额外的安全注意事项。   •用于远程集成服务器的Salesforce服务器IP范围白名单。   •经过实施适当的防火墙机制来保护远程系统
Platform Events	对于平台事件，订阅的外部系统必须可以对Salesforce流式API进行身份验证。 平台事件符合Salesforce组织中配置的现有安全模型。要订阅事件，用户须要对事件实体的读取权限。要发布事件，用户须要对事件实体具备建立权限。

总结：篇中主要介绍了 Fire and Forget 发后即弃的模型相关的知识，感兴趣的能够查看官方文档进行夯实。篇中有错误欢迎指出，有不懂欢迎留言。