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 发后即弃的模型相关的知识,感兴趣的可以查看官方文档进行夯实。篇中有错误欢迎指出,有不懂欢迎留言。
作者:zero
博客地址:http://www.cnblogs.com/zero-zyq/
本文欢迎转载,但未经作者同意必须保留此段声明,且在文章页面明显位置给出原文连接
如果文章的内容对你有帮助,欢迎点赞~
为方便手机端查看博客,现正在将博客迁移至微信公众号:Salesforce零基础学习,欢迎各位关注。