DEX455

课程介绍

Salesforce Connect与Apex Connector Framework完全指南：外部对象Apex限制(无触发器托管共享/Batch数据临时存储/Server Driven Pagination防重复)、可写外部对象(insertAsync异步DML/BackgroundOperation监控)、External CDC打包测试(EventBus.publish+deliver)、Mock SOQL测试(SoqlStubProvider/createSoqlStub)、DataSource.Connection五方法(sync声明ExternalId列/query处理COUNT聚合+QueryUtils测试专用/search多表联合/upsertRows每行callout/deleteRows)、DataSource.Provider(认证+功能静态列表/修改Connection需重保存Provider)、OAuth令牌刷新(OAuthTokenExpiredException/refresh_token)、Callout(ConnectionParams封装OAuth/Basic Auth)、分页(Server-Driven queryMoreToken/Client-Driven LIMIT+OFFSET)、queryMore(分批500条)、过滤器(columnName+columnValue+EQUALS+AND_/OR_/NOT_复合/外部系统优先过滤)、框架限制(DML禁止/测试用动态SOQL/Double精度18位)、GitHub Issues+GitHub+Google Drive+Google Books四个完整适配器示例。

课程章节

本课程共有 3 个章节

• 1

  Salesforce Connect

  第 313 页

  同学们，今天咱们来看一个非常实用的知识点：如何用 Apex 代码去访问那些不在 Salesforce 内部，而是存放在外部系统里的数据。 你可能已经知道，Salesforce 里有一种叫做“外部对象”的东西。你可以把它想象成一张“虚拟表”，这张表对应的真实数据，其实是躺在你公司另一个数据库、或者是 SAP、或者是某个云服务里的。Salesforce 本身并不存储这些数据，只是在需要的时候，实时或按需地去外部系统里取。 那怎么去取呢？Salesforce 提供了一个叫 ，Salesforce Connect， 的服务，它就是专门干这事儿的。它通过“适配器”去连接各种外部数据源。比如最常用的 OData 适配器，可以直接对接支持 OData 协议的系统。可要是你的外部系统很特别，没有现成的适配器能用，怎么办呢？ 这时候，，Apex 连接框架， 就登场了。你可以直接用 Apex 代码开发一个自定义的适配器。也就是说，你自己动手写一个“驱动程序”，告诉 Salesforce：“嘿，你到那个系统的时候，应该这么发请求、这么处理返回的数据。” 这样一来，你就可以从任何外部系统里检索数据，甚至可以在 Apex 里对拿来的数据进行加工、合并，在本地合成出你需要的样子。 最终的结果就是：对最终用户，对 Lightning 平台来说，这些外部数据完全无缝地融入了 Salesforce。你可以像查标准 Account、Contact 一样去查外部对象，可以在报表里用，也可以在流程里用。用户根本感觉不到数据其实远在天边，他们只是在和一张看起来像是 Salesforce 原生对象的东西打交道。 所以小结一下就是：，Apex 代码可以通过 Salesforce Connect 的任何适配器去访问外部对象数据；而且我们还能用 Apex 连接框架写出自己的适配器，去连接那些五花八门的外部系统，让数据在本地整合，给用户最顺畅的体验。， 好，这一页的核心就这么多，是不是很清晰？我们接着往下看。

  ▶ 播放视频 查看详情
• 2

  External Objects & Apex Connector Framework

  第 314 页

  好，今天我们来看这一页关于Apex连接框架的内容。先记住一点：外部对象在Salesforce里，默认是只读的，也就是你只能看，不能改。但我们可以把它设置成可写，这样就能在Salesforce里对外部数据做完整的增删改查操作了。 那怎么实现这个可写的能力呢？就需要用到Apex连接框架。这个框架主要由两个类来配合工作。 第一个叫DataSource.Connection，负责身份验证和会话管理，简单说就是帮你建立和维护跟外部系统的安全连接。 第二个叫DataSource.Provider，它才是真正干活的那个，负责所有数据操作，比如查询、搜索、增删改查，还有去探查外部数据结构是什么样的。 在这个过程中，有几个关键概念你得知道。 第一是外部ID，它用来唯一标识外部系统里的每一条记录，就像身份证号一样。 第二是OAuth，这是保证连接安全的认证方式，让Salesforce安全地代表你去访问外部数据。 第三是页面策略，指的是怎么控制数据分页，避免一次捞太多数据回来。 最后还有调节器和收件箱限制管理，这是用来控制请求频率，防止对外部系统造成过大压力，也防止你超过外部的调用限额。 记住这些，你就掌握了Apex连接框架的核心思路。

  ▶ 播放视频 查看详情
• 3

  Connector Framework Examples & Thank You

  第 315 页

  同学们，咱们这节课来聊聊Apex连接器框架里非常实用的一个设计思路。你可能知道，在实际项目里，Salesforce经常要跟外部系统打交道，比如调的REST接口、OData服务，甚至传统数据库。这时候，我们能不能写出标准、可复用的集成代码呢？答案就在这个框架里。 它直接给出了六个参考示例，你完全可以拿过来学习和模仿。这些示例展示了怎么给不同种类的数据源打造自定义的适配器：有REST API类型的，有OData服务的，有关系型数据库系统的，甚至还有支持搜索功能的对象。也就是说，不管外部是哪种风格，你都能找到对应的实现范本，照着搭就行。 但是，光看示例还不够，有几件要紧事一定要留意。首先，Salesforce对调出有一系列调控器限制，比如单次事务里能发多少次HTTP请求、总共花多长时间，这些都必须遵守；否则就会触发异常。其次，数据量的管理也很关键，外部系统返回几千条记录的时候，你不能一股脑全接进来，得做好分批处理，控制好内存和调控器的消耗。身份验证更不用说，你总得安全地登录过去，OAuth、API密钥这些机制都要妥善集成。最后是错误处理，网络断了怎么办？对方返回一个500错误怎么办？这些都要提前规划，不能让一个外部异常拖垮你整个交易。 那要想把这些事情都理清楚，框架给了我们一个特别棒的思路：它把整个集成拆成两类角色，一个是连接，一个是提供者。连接，专门负责跟外部系统握手、发请求、收响应，管好底层通信那一套；提供者，则面向Salesforce这边，按需要查询、搜索或者修改数据，它不关心底层是HTTP还是数据库协议，只调用连接来完成。这种“关注点分离”的做法，让代码结构非常干净，逻辑一目了然。连接和提供者各司其职，后续维护、扩展都容易很多，也更能扛住生产环境的压力。 所以你看，用这个框架去构建外部数据集成，你既有现成的示例可以起步，又有清晰的关注点分离来保证长期质量，再加上对调控器、数据量、认证和错误处理的考量，出来的方案自然就是生产就绪的。希望大家以后做集成的时候，能把这个结构用起来。

  ▶ 播放视频 查看详情