Salesforce Integration 概览(二) Remote Process Invocation—Request and Reply(远程进程调用--请求和响应)

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

我们在项目中，经常会遇见一个自定义页面的按钮或者一个 quick action点击，或者页面初始化，会对外部系统做一个 callout，然后获取对方的数据以后做一些逻辑进行操作，这种场景实在是太常见了。这种场景通常有几个特点：

• 实时性
• 数据量不大
• 对端响应快

当然可能还有很多的特点，这里不多描述。salesforce针对这种我们常用的场景整理成一个集成模式，名称为： 远程进程调用--请求和响应。那么请求和响应的详细描述是什么，有哪些限制，针对这种集成模式有哪些解决方案，解决方案的适配度如何呢？我们接下来慢慢的描述。

一. 上下文

其实通过上面的描述中我们大概已经能联想到我们实际的应用的上下文。这里还是拿出来一个官方的例子去更好的进行一下描述。

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

当您实现此模式时，Salesforce调用远程系统来创建订单，然后等待成功完成。如果成功，远程系统会同步回复订单状态和订单号。作为同一个transaction的一部分，Salesforce在内部更新订单号和状态。订单号用作远程系统后续更新的外键（External Id）。

通过这个描述，我们就可以清楚了这个case是Opportunity Close Won创建订单，订单号需要维护到外部系统，需要同步的call外部系统然后作为外键更新到SF的订单的记录。

 二. 问题和考虑因素

问题： 当一个事件从salesforce触发时，如何在远程系统中启动（初始化）流程，将所需信息传递给该流程，从远程系统接收response，然后使用该响应数据在Salesforce中进行更新？

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

• 对远程系统的调用是否要求Salesforce在response回来之前等待响应？对远程系统的调用是同步请求-应答还是异步请求？
• 如果对远程系统的调用是同步的，Salesforce是否必须将response作为与初始调用相同的事务的一部分进行处理？
• 消息大小是小还是大？
• 集成是否基于特定事件的发生，例如Salesforce用户界面中的按钮点击，或基于DML的事件？
• 远程端点（endpoint）是否能够以低延迟响应请求？有多少用户可能在高峰期执行此事务？

这些考虑因素很重要，会影响我们的解决方案的使用以及影响到我们当前的模式是否适用于当前的case。所以针对上述的考虑因素一定要慎重地思考。

三. 解决方案

针对此种解决方案 Salesforce提供了5种解决方案，不同的解决方案适用于不同的考虑因素点，当然有一个列表是适配度，描述当前是最好的方案还是次优的方案，当然，这个也不一定是绝对的，我们考虑集成方案的时候，除了考虑这种 best practice以外，还需要考虑 effort以及是否拥有 resource以及很多外部的因素。

针对次优的方法我们通常不建议使用，除非针对这个case特别特殊。针对这五种解决方案，再扩展一下第二点中的异步调用方法。

先说一个我们最简单的一个 callout的demo。 下面的这个代码是最简单的一个 callout操作，通过标准的 httprequest 的get方法获取指定 endpoint的内容。

// Instantiate a new http object
Http h = new Http();

 // Instantiate a new HTTP request, specify the method (GET) as well as the endpoint
HttpRequest req = new HttpRequest();
req.setEndpoint(url);
req.setMethod('GET');

// Send the request, and return a response
HttpResponse res = h.send(req);
return res.getBody();

这种代码和我们实际的场景可能也就缺少一个OAuth的逻辑，剩下的如出一辙。那么如果远程系统的 endpoint在高峰期处理的时候没法达到低延迟响应的情况下，前端很容易假死，也很容易超时。这种情况我们就建议使用异步的 + callback方式来处理这种 高延迟的case。下面是官方推荐的代码：

public Object startRequest() {
      // Create continuation with a timeout
      Continuation con = new Continuation(40);
      // Set callback method
      con.continuationMethod='processResponse';
      
      // Create callout request
      HttpRequest req = new HttpRequest();
      req.setMethod('GET');
      req.setEndpoint(LONG_RUNNING_SERVICE_URL);
      
      // Add callout request to continuation
      this.requestLabel = con.addHttpRequest(req);
      
      // Return the continuation
      return con;  
}
    
// Callback method 
public Object processResponse() {   
      // Get the response by using the unique label
      HttpResponse response = Continuation.getResponse(this.requestLabel);
      // Set the result variable that is displayed on the Visualforce page
      this.result = response.getBody();
      
      // Return null to re-render the original Visualforce page
      return null;
}

visualforce的调用demo可参考：https://developer.salesforce.com/docs/atlas.en-us.apexcode.meta/apexcode/apex_continuation_overview.htm

lwc的调用demo可参考：Salesforce LWC学习(十四) Continuation进行异步callout获取数据 

四. 流程草图

1. 在Visualforce Page或者 Lightning中进行了某个操作，比如点击了某个按钮
2. 浏览器（如果是Lightning组件，则通过客户端控制器）执行HTTP POST，该HTTP POST反过来对相应的Apex Controller执行操作（执行某个方法）。
3. controller对远程web service进行实际的调用。
4. 来自远程系统的响应返回到Apex Controller。Controller处理response，根据需要更新Salesforce中的数据，并reRender页面操作。

 五. 其他关键点

1. Error Handling考虑： 当我们在进行整体设计时，我们需要考虑错误处理以及数据恢复的策略。

　　• Error Handling：当error发生时（异常或者错误的code），调用者管理错误处理。比如页面展示错误信息或者跳转到共用页面等等。
　　• Recovery：呼叫者接收到成功的response以后才可以将数据commit到数据库。如果失败（连接失败等）有必要可以重试连接

 2. 幂等性（Idempotent）考虑：在编程中一个幂等操作的特点是其任意多次执行所产生的影响均与一次执行的影响相同。幂等函数，或幂等方法，是指可以使用相同参数重复执行，并能获得相同结果的函数。这些函数不会影响系统状态，也不用担心重复执行会对系统造成改变。

确保所调用的远程过程是幂等的是很重要的。几乎不可能保证Salesforce只调用一次，特别是当调用是由用户界面事件触发时。即使Salesforce发出一个调用，也不能保证其他进程（例如中间件）也会这样做。构造幂等接收器的最典型方法是： 它基于使用者发送的唯一消息标识符（unique key）来跟踪重复项(duplicate records)。Apex web service或REST必须自定义去发送唯一的消息ID。此外，在远程系统中创建记录的操作必须在插入之前检查重复项，我们可以通过从Salesforce传递唯一的记录ID进行检查。如果远程系统中存在该记录，请更新该记录。在salesforce的世界里面很好理解，就是 upsert操作，我们需要创建一个外键，这个外键设置唯一即可。

 3. 安全性考虑： 当我们调用远程系统失败以后，首先需要考虑 remote site setting是否配置了这个站点的URL，其次看一下CSP 是否配置。这两个是项目中大部分场景都需要配置的。除此以外，对远程系统的任何调用都必须保持请求的机密性、完整性和可用性。当我们在这种模式中使用apexsoap和HTTP调用时，我们需要考虑以下：

　　•默认情况下启用单向SSL，但双向SSL也要被self-signed 和 CA-signed 证书支持，以保持客户端和服务器的真实性。

　　•Salesforce目前不支持WS-Security。

　　在必要时，考虑使用单向加密或数字签名，使用Apex Crypto类方法来确保请求完整性。

　　•必须通过实施适当的防火墙机制来保护远程系统。

 4. 及时性以及用户友好性：在这种模式中，及时性非常重要。通常：

　　•请求通常从用户界面调用，因此该过程不能让用户等待（用户期望时间最多不能超过10秒，否则会很烦的）。

　　•Salesforce对来自Apex的call out最多可以配置到120秒的 timeout

　　•及时完成远程流程，在Salesforce超时限制和用户期望范围内完成。

　　•外部调用受Apex synchronous transaction governor限制，因此应注意降低实例化10个以上事务（每个事务运行时间超过5秒）的风险。
　　官方的介绍：If more transactions are started while the 10 long-running transactions are still running, they’re denied. HTTP callout processing time isn’t included 　　　　　　　        when calculating this limit.
除了确保外部endpoint的性能外，减轻超时风险的选项还包括

　　–将callout的超时设置为5秒
　　–在Visualforce或Lightning组件中使用continuation来处理长时间运行的事务
补充知识：Apex Continuations是Salesforce平台提供的一种机制，允许您向外部Web服务发出异步长时间运行的请求。该服务支持对SOAP或restweb服务的调用，最大超时为120秒（而标准同步调用为10秒）。

5. 数据量考虑：此模式主要用于小容量的实时活动，因为Apex调用解决方案的超时值较小，请求或响应的大小也最大。当批处理的场景，包含数据负载的情况下不要使用此模式。

6. 远程系统的EndPoint 能力和标准支持：针对 endpoint的需要的能力和标准的服务取决于我们选择的哪种解决方案

 六. 常见考题

Question: Universal Containers is a global financial company that sells financial products and services including, bank accounts, loans, and insurance. UC uses Salesforce Service cloud to service their customer via calls, live chat. The support agents would open bank accounts on the spot for customers who are inquiring about UC bank accounts. UC Core banking system is the system of record for bank accounts and all accounts opened in salesforce have to be synced in real-time to the core banking system. Support agents need to inform the customers with the newly created bank account ID which has to be generated from the core banking system. Which integration pattern is recommended for this use case?

Answer：
Use request and reply.

Question: Universal Containers wants to gather information from a third-party application to update shipping information for an order inside Salesforce. A salesperson could trigger an update and the user interface would refresh with the current status. Which are two recommended options for this when utilizing a Remote Process Invocation-Request and Reply pattern?

Answer:
A custom Visualforce page or button that initiates an Apex REST callout in a synchronous manner.
A custom Visualforce page or button that initiates an Apex SOAP callout in a synchronous manner.

总结：篇中主要介绍了远程进程调用--请求和响应的集成模式，这个在实际项目场景是最常用到的，所以大家理解也相对方便。篇中有错误欢迎指出，有不懂欢迎留言。 

标签：Salesforce,Remote,Process,callout,Apex,调用,远程,Visualforce
来源： https://www.cnblogs.com/zero-zyq/p/15091989.html