Salesforce中文网

背景与应用场景 作为一名 Salesforce 开发人员，我们日常工作中不可避免地会遇到平台的 Governor Limits (管控限制) 。这些限制是为了保证多租户环境下资源的公平使用，但它们也给处理复杂业务逻辑或大量数据的任务带来了挑战。例如，单次同步事务中的 SOQL 查询数量、DML 操作行数以及 CPU 处理时间都受到严格限制。当我们尝试在一个同步事务（如 Trigger 或 Visualforce Controller）中执行一个耗时过长的操作时，系统就会抛出异常。 为了解决这个问题，Salesforce 平台提供了多种异步处理机制。 Asynchronous Apex (异步 Apex) 允许我们将某些操作推迟到后台执行，每个异步任务都会在一个新的、独立的事务中运行，并拥有自己的一套管控限制。这极大地提高了我们处理复杂任务的能力。 在 Queueable Apex 出现之前，我们主要依赖 Future Methods (未来方法) (使用 @future 注解) 和 Batch Apex (批处理 Apex) 。Future 方法简单易用，但存在一些明显的缺点： 参数类型受限：只能接受原始数据类型 (primitive data types)、原始数据类型的数组或集合。无法直接传递 sObject 对象。 无状态：无法获取任务的 ID，也难以追踪其执行状态。 无法链式调用：一个 Future 方法不能调用另一个 Future 方法。 Batch Apex 功能强大，专为处理海量数据集而设计，但其实现相对复杂，需要定义 start 、 execute 和 finish 三个方法，对于中等规模的异步任务来说，显得有些“重”。 Queueable Apex 的出现，正是为了弥补 Future 方法的不足，并提供一个比 Batch Apex 更轻量级、更灵活的异步解决方案。它最适合以下应用场景： 复杂数据处理： 当你需要在一个异步任务中传递和处理 sObject 对象或自定义 Apex 对象时。 任务链式调用： 当一个异步任务依赖于另一个任务的结果时，例如，先进行数据清洗，再进行数据同步。 获取任务 ID： 当你需要监控一个异步任务的执行状态时，Queueable ...

背景与应用场景 大家好，我是一名 Salesforce 开发人员。在我的日常工作中，无论是编写 Apex 触发器、开发 Lightning Web Components (LWC) 的后端控制器，还是构建复杂的数据集成流程，都离不开一个核心工具： SOQL (Salesforce Object Query Language) 。SOQL 是 Salesforce 平台数据操作的基石，它允许我们以一种结构化、可预测的方式从 Salesforce 数据库中精确地检索所需信息。 与通用的 SQL 语言不同，SOQL 专为 Salesforce 的多租户架构和对象模型量身定制。它不是用来修改数据（那是 DML 的工作），而是专注于“查询”这一件事，并将其做到了极致。对于开发人员而言，熟练掌握 SOQL 不仅仅是一项基本技能，更是编写高性能、可扩展且符合平台限制的应用程序的关键。 应用场景无处不在： 用户界面展示： 在 LWC 或 Aura 组件中，我们需要通过 Apex 控制器执行 SOQL 查询，获取客户列表、相关联系人或待办任务，并将这些数据显示在前端页面上。 业务逻辑处理： 在 Apex Trigger 中，我们经常需要查询相关记录以进行数据验证或级联更新。例如，在创建订单时，查询关联客户的信用状态。 数据集成与迁移： 当使用 REST API 或 SOAP API 与外部系统交互时，SOQL 是从 Salesforce 提取特定数据集以进行同步或分析的核心查询语言。 自动化流程： 在 Flow 或批处理 Apex (Batch Apex) 中，SOQL 用于定义需要处理的记录集，例如，查询所有超过90天未活动的商机进行批量处理。 因此，深入理解 SOQL 的语法、功能、性能考量和治理限制，是我们作为 Salesforce 开发人员的必修课。这篇技术文章将带你深入 SOQL 的世界，从基础原理到高级技巧，帮助你编写更优雅、更高效的代码。 原理说明 SOQL 的设计理念是简单且强大。它的语法与标准 SQL 非常相似，这使得有数据库背景的开发人员能够快速上手。一个基本的 SOQL 查询由几个关键子句组成： SELECT , FROM , WHERE 。 SELECT Field1, Field2, ... ...

背景与应用场景 在传统的 Salesforce 开发与集成中，我们主要依赖 REST API 和 SOAP API 进行数据交互。尽管这些 API 功能强大且成熟，但在某些场景下却面临着挑战。最常见的两个问题是 Over-fetching（过度获取） 和 Under-fetching（获取不足） 。 Over-fetching 指的是客户端从服务器获取了超出其需要的数据。例如，一个移动应用的用户信息卡片可能只需要显示客户（Account）的名称和电话，但标准的 REST API 端点（如 /services/data/vXX.X/sobjects/Account/{accountId} ）可能会返回该客户的所有可访问字段，这不仅浪费了带宽，也增加了客户端的处理负担。 Under-fetching 则恰恰相反，指的是一个 API 端点无法提供客户端所需的所有数据，导致客户端需要发起多次请求。想象一个复杂的 Lightning Web Component (LWC) 需要展示一个客户（Account）及其所有关联的联系人（Contacts）和进行中的业务机会（Opportunities）。使用 REST API，开发者可能需要至少发起三次独立的 API 调用：一次获取客户信息，一次获取联系人列表，再一次获取业务机会列表。这种“请求瀑布”会显著增加页面加载时间，影响用户体验。 为了解决这些痛点，Salesforce 引入了 GraphQL API 。GraphQL 是一种由 Facebook 开发并于 2015 年开源的 API 查询语言和运行时。它允许客户端精确地声明其数据需求，然后由服务器返回一个不多不少、结构完全匹配的 JSON 响应。这赋予了前端开发者前所未有的灵活性和控制力，使其成为构建现代、高性能应用程序的理想选择。 主要应用场景包括： 复杂的 LWC 或 Aura 组件： 当一个组件需要聚合来自多个关联对象的数据时，GraphQL 可以通过一次请求完成所有数据获取，极大地简化了前端逻辑并提升性能。 移动应用开发： 在网络环境不稳定的移动场景下，精确控制数据负载至关重要。GraphQL 的“按需索取”特性可以最小化网络传输量。 第三方系统集成： 当集成方的数据需求频繁变化时，GraphQL 的灵活性使其无...

背景与应用场景 在 Salesforce 平台的开发生态中，数据交互是构建任何复杂应用的核心。多年来， REST API 和 SOAP API 一直是开发者与 Salesforce 数据交互的主要方式。然而，随着前端应用（如 Lightning Web Components - LWC）和移动应用对数据需求的日益精细化，传统 API 的一些弊端也逐渐显现： 1. 数据过度获取 (Over-fetching): 当客户端只需要一个对象的少数几个字段时，标准的 REST API 端点往往会返回整个对象的全部可访问字段。这不仅浪费了网络带宽，也增加了客户端的处理负担。例如，为了显示一个客户列表（仅需名称和行业），REST API 可能会返回每个客户记录的几十个字段。 2. 数据获取不足 (Under-fetching): 当客户端需要来自多个关联对象的数据时（例如，一个客户及其所有联系人，以及每个联系人最近的三个订单），通常需要发起多次独立的 REST API 请求。这种“N+1”查询问题会导致网络延迟增加，应用响应变慢，用户体验下降。 为了解决这些痛点，Salesforce 引入了 GraphQL API 。 GraphQL 是一种由 Facebook 开发并开源的 API 查询语言和运行时。它允许客户端精确地声明其数据需求，然后由服务器返回不多不少、完全符合该需求的数据结构。这使得它成为构建高性能、数据驱动型应用，尤其是复杂前端界面的理想选择。 Salesforce GraphQL API 的典型应用场景包括： 复杂的 LWC 或 Aura 组件： 当一个组件需要同时展示来自父对象和多个子对象层级的数据时，使用 GraphQL 只需一次网络请求即可获取所有需要的数据，极大地简化了前端逻辑并提升了性能。 移动应用开发： 在移动网络环境下，带宽和延迟是关键考量因素。GraphQL 的精确数据获取能力可以最大限度地减少数据传输量，从而加快应用加载速度并节省用户流量。 第三方系统集成： 当外部系统需要从 Salesforce 中拉取特定、结构化的数据集时，GraphQL 提供了一种比组合多个 REST 请求更高效、更灵活的集成方式。 原理说明 Salesforce GraphQL ...