Salesforce External Services:管理员的无代码 API 集成利器

背景与应用场景

作为一名 Salesforce 管理员,我们日常工作的核心是利用 Salesforce 平台的强大功能来优化业务流程、提升用户效率。在现代企业复杂的 IT 生态中,Salesforce 往往不是一个孤岛,它需要与各种外部系统进行数据交换,例如 ERP 系统、物流供应商的 API、金融服务系统、市场营销自动化工具等。传统上,实现这些集成通常需要求助于 Salesforce 开发人员编写复杂的 Apex Callouts,这不仅开发周期长、成本高,而且后续的维护和迭代也对管理员不够友好。

然而,随着 Salesforce 平台“低代码”和“无代码”能力的不断增强,我们管理员也迎来了自己的集成神器——External Services (外部服务)。External Services 是一个强大的声明式框架,它允许我们通过简单地提供一个 API 规范,就能将外部的 REST API 操作转化为可以在 Flow Builder (流生成器) 或其他自动化工具中直接调用的“积木块”。

这为我们打开了全新的可能性。想象一下以下场景,现在完全可以由我们管理员独立完成:

  • 订单发货状态查询:在“订单”页面添加一个按钮,点击后触发一个 Flow,通过 External Services 调用外部物流公司的 API,实时获取最新的物流信息并更新到订单记录上。
  • - 信用评级验证:在“客户”或“业务机会”进入审批流程时,自动触发一个 Flow,调用外部征信机构的 API,获取客户的信用评分,并根据评分结果决定流程走向。 - 数据自动丰富:当一个新“潜在客户”创建时,利用其邮箱或公司名称,通过 External Services 调用数据服务商(如 Clearbit)的 API,自动填充公司的行业、规模、地址等详细信息。 - 跨系统操作:当一个“业务机会”关闭并赢得时,自动在外部财务系统中创建一个对应的发票草稿。

在这些场景中,External Services 扮演了桥梁的角色,它让我们管理员能够专注于业务逻辑的设计,而将复杂的 API 调用、认证、数据解析等技术细节交给平台去处理。这不仅极大地提高了我们的工作效率,也赋予了我们快速响应业务需求变化的能力。


原理说明

External Services 的核心魔法在于它对 OpenAPI Specification (开放 API 规范) 的原生支持。OpenAPI(以前称为 Swagger)是一个行业标准,它使用 JSON 或 YAML 格式来定义和描述一个 REST API 的所有细节,包括:

  • 端点 (Endpoints):API 的可用 URL 路径,例如 `/users/{userId}`。
  • 操作 (Operations):每个端点支持的 HTTP 方法,如 `GET`, `POST`, `PUT`, `DELETE`。
  • 参数 (Parameters):调用 API 需要传入的输入,包括路径参数、查询参数、请求头或请求体。
  • 响应 (Responses):API 调用成功或失败时返回的数据结构和 HTTP 状态码。
  • 数据模型 (Schemas):API 中使用的复杂数据对象的结构定义。

整个工作流程非常直观,可以分为以下几个步骤:

1. 获取 API 规范:首先,你需要从外部服务的提供商那里获取其 API 的 OpenAPI 规范文件。这个文件通常是 `openapi.json` 或 `openapi.yaml`。

2. 注册外部服务:在 Salesforce 的“设置”菜单中,找到“外部服务”,点击“新建外部服务”。在这里,你需要选择“来自 API 规范”,然后上传你获取到的 OpenAPI 文件。同时,你还需要关联一个 Named Credential (命名凭据),这是 Salesforce 中管理外部服务端点 URL 和认证信息的最佳实践,它可以避免将敏感信息(如密码或 API 密钥)硬编码在你的配置中。

3. Salesforce 自动生成操作:在你保存之后,Salesforce 会在后台解析这个 OpenAPI 文件。对于规范中定义的每一个 API 操作(例如,一个 `POST /accounts` 操作),Salesforce 会自动生成一个对应的 Invocable Action (可调用操作)。这些 Action 会以你注册的外部服务名称为前缀,清晰地组织起来。

4. 在 Flow 中使用:现在,当你打开 Flow Builder 并创建一个新的 Flow 时,在“操作”元素中,你就可以搜索到刚刚生成的 Invocable Actions。你可以像使用任何标准 Flow 操作一样,将它拖拽到画布上,为其配置输入参数(来自屏幕输入、记录变量等),并处理它的输出结果,将其赋值给变量或更新到 Salesforce 记录中。

从本质上讲,External Services 是一个代码生成器,它将一个标准的、机器可读的 API 描述文件,转换成了 Salesforce 平台内部可以识别和执行的声明式组件,从而为我们管理员搭建了一座通往外部世界的、无需编码的桥梁。


示例代码

以下示例代码并非 Apex,而是 External Services 所依赖的 OpenAPI 2.0 规范(JSON 格式)。此示例来自 Salesforce 官方文档,描述了一个虚构的银行服务 API,其中包含获取账户信息和添加账户的操作。

{
  "swagger": "2.0",
  "info": {
    "title": "Bank Service",
    "description": "API for a simple bank service.",
    "version": "1.0"
  },
  "host": "my-bank.com",
  "schemes": [
    "https"
  ],
  "paths": {
    "/accounts": {
      "get": {
        "summary": "Get Accounts",
        "description": "Fetches all accounts.",
        "produces": [
          "application/json"
        ],
        "responses": {
          "200": {
            "description": "successful operation",
            "schema": {
              "type": "array",
              "items": {
                "$ref": "#/definitions/Account"
              }
            }
          }
        }
      },
      "post": {
        "summary": "Add Account",
        "description": "Adds a new account.",
        "consumes": [
          "application/json"
        ],
        "parameters": [
          {
            "in": "body",
            "name": "body",
            "description": "The account to be added.",
            "required": true,
            "schema": {
              "$ref": "#/definitions/Account"
            }
          }
        ],
        "responses": {
          "200": {
            "description": "successful operation"
          }
        }
      }
    }
  },
  "definitions": {
    "Account": {
      "type": "object",
      "properties": {
        "name": {
          "type": "string"
        },
        "balance": {
          "type": "number"
        }
      }
    }
  }
}

代码注释:

  • swagger: "2.0": 声明了该文件遵循 OpenAPI 2.0 规范。
  • info: 包含了 API 的元数据,如标题、描述和版本。
  • host / schemes: 定义了 API 的基础 URL (https://my-bank.com)。在 Salesforce 中,这部分通常会被 Named Credential 中的 URL 覆盖,这是一种更安全、更灵活的做法。
  • paths: 这是 API 的核心,定义了所有的资源路径。
    • /accounts: 定义了一个名为 "accounts" 的资源路径。
      • get: 定义了对此路径的 HTTP GET 请求。它没有参数,成功时 (responses "200") 会返回一个 Account 对象的数组。
      • post: 定义了 HTTP POST 请求。它有一个名为 "body" 的参数 (parameters),其数据结构由 definitions/Account 定义。这个操作用于创建一个新账户。
  • definitions: 定义了 API 中使用的数据模型。
    • Account: 定义了一个名为 "Account" 的对象,它有两个属性:`name` (字符串类型) 和 `balance` (数字类型)。当 Salesforce 解析这个文件时,它会自动创建一个名为 `Account` 的 Apex 定义的复杂数据类型,以便在 Flow 中进行数据传递。

当我们把这个 JSON 文件上传到 Salesforce External Services 后,系统会自动创建两个可调用的操作,可能命名为 `bankService.getAccounts` 和 `bankService.addAccount`,我们就可以在 Flow 中直接使用它们了。


注意事项

虽然 External Services 非常强大,但在实际使用中,我们必须注意以下几点:

1. 规范兼容性:Salesforce External Services 目前主要支持 OpenAPI 2.0 和部分 OpenAPI 3.0 的特性。一些非常复杂的规范,例如使用了 `oneOf`, `anyOf`, `allOf` (多态) 或者递归定义的 schema,可能不被完全支持。在注册一个复杂的 API 之前,请务必查阅 Salesforce 官方文档中关于支持的 schema 的最新列表。

2. 必须使用 Named Credentials:这是安全和维护的最佳实践。Named Credentials 将端点 URL 和认证细节(如用户名密码、OAuth 2.0、API Key 等)从 External Service 的定义中解耦。这使得我们可以在不同环境(沙盒、生产)之间轻松切换,而无需修改 Flow 或 External Service 的定义,只需更新 Named Credential 即可。

3. Governor 限制:虽然我们是在用声明式工具,但底层的执行依然是 Apex Callout。因此,每一次通过 Flow 调用外部服务的操作,都会计入 Salesforce 的 Governor 限制,例如:每个事务中的 Callout 总数(100次)、累计 Callout 超时时间(120秒)等。在设计高频调用的 Flow 时,必须考虑到这些限制。

4. 错误处理:API 调用不是永远成功的。网络问题、外部服务宕机、无效的输入都可能导致失败。在 Flow Builder 中,对于每一个“操作”元素,都有一条“故障路径” (Fault Path)。我们必须为调用外部服务的操作配置故障路径,以定义当 API 调用失败时系统应如何响应,例如:向管理员发送邮件、在界面上显示友好的错误提示、将记录标记为处理失败等。没有故障处理的集成是脆弱且不可靠的。

5. 同步与异步:External Services 发起的调用是同步的。这意味着 Flow 会等待外部服务的响应。如果外部服务响应非常慢,可能会导致用户界面卡顿,甚至触发 Salesforce 的 CPU time limit。对于需要长时间处理的请求,不应直接在触发器流或屏幕流中进行同步调用。可以考虑使用异步模式,例如,Flow 先创建一个平台事件 (Platform Event),然后由一个订阅该事件的异步 Apex 触发器或平台事件触发的 Flow 来执行耗时的 Callout。


总结与最佳实践

External Services 无疑是 Salesforce 管理员工具箱中一颗璀璨的明珠。它打破了声明式配置与外部世界之间的壁垒,让我们能够以更低的成本、更快的速度来交付复杂的集成需求,真正实现了“配置而非编码”的理念。

为了最大化地发挥其价值并构建稳定、可维护的集成,以下是一些最佳实践建议:

  1. 优先选择标准:尽可能与提供标准 OpenAPI 规范的外部服务进行集成。这会大大简化注册和维护过程。
  2. 先验证再注册:在将 OpenAPI 规范上传到 Salesforce 之前,可以使用一些在线的 OpenAPI 验证工具来检查其语法和结构的正确性。
  3. 命名规范:为你的 External Service 和 Named Credential 设置清晰、一致的命名,以便于未来的识别和管理。
  4. 设计可重用的 Flow:如果一个外部服务操作需要在多个地方被调用,可以将其封装在一个可由其他流程调用的子流 (Subflow) 中,提高复用性。
  5. 充分测试:在沙盒环境中,针对各种成功和失败的场景进行充分测试。模拟外部服务返回错误或超时的情景,确保你的故障路径按预期工作。
  6. 持续关注版本更新:Salesforce 每个版本都会对 External Services 的功能进行增强,包括支持更多的 OpenAPI 特性。定期查阅版本说明,了解最新的功能和限制。

作为管理员,掌握 External Services 意味着我们不再仅仅是 Salesforce 内部流程的优化者,更是连接企业内外部数据和流程的架构师。现在就开始探索这个强大的功能,将你的 Salesforce 实例与更广阔的数字世界无缝连接起来吧!

评论

此博客中的热门博文

Salesforce 登录取证:深入解析用户访问监控与安全

Salesforce Experience Cloud 技术深度解析:构建社区站点 (Community Sites)

精通 Salesforce Email Studio:咨询顾问指南之 AMPscript 与数据扩展实现动态个性化邮件