RAP 时代的 Service Binding：把 CDS 业务服务稳稳地“插”到 OData 里

在现代 SAP ABAP 开发里，大家越来越习惯用 CDS 数据模型去表达业务语义，用 RAP 来承载事务逻辑，再把能力以 OData 的方式交付给 SAP Fiori elements、集成平台或外部系统。真正把“业务对象”变成“可被消费的服务”的最后一公里，往往落在一个看似简单、却极其关键的仓库对象上：business service binding，也就是常说的 Service Binding。

Service Binding 是一个 ABAP Repository 对象，用于把 Service Definition 绑定到某种客户端-服务端通信协议（典型就是 OData）。它和其他 ABAP 仓库对象一样，天然融入 ABAP Workbench 的基础设施，比如激活、依赖分析、传输组织等能力。更重要的是，它让你把“业务逻辑”与“服务协议”拆开：业务层关注语义与行为，协议层关注如何对外开放、以什么风格开放、面向什么消费场景开放。

下面这篇内容会围绕 Service Binding 这个主题，把核心概念、关键参数、发布与运维、OData V2 与 V4 的差异、以及 On-Premise 场景下与 SAP Gateway Foundation（组件 SAP_GWFND）相关的落地方式讲透，并穿插两个真实世界的案例，帮助你把抽象对象映射到日常项目的决策中。

---

从数据模型到服务交付：三层结构为什么要分开

在 RAP 与 CDS 主导的设计里，经常能看到一条清晰的链路：

• CDS-based d