一张图读懂 ABAP 语言的三种版本

很多 ABAP 开发者在接触 ABAP Cloud 或者 Key User Extensibility 时，都会遇到一个让人困惑的现象。

明明都是 ABAP 代码，为什么有些语句在 Standard ABAP 里能跑，换到 ABAP Cloud 环境就报错了？

为什么同样是写增强逻辑，Key User 能用的语法少得可怜？

这背后的原因，就藏在 ABAP Language Version 这个程序属性里。

每个 ABAP 程序都有一个叫做ABAP language version的属性，这个属性由一个内部版本 ID 来标识。它决定了这个程序里可以使用哪些语言元素、哪些 repository objects 可以被访问、以及适用哪套语法规则。

目前 SAP 系统里存在三个 ABAP Language Version，分别是：Standard ABAP、ABAP for Cloud Development、ABAP for Key Users。

如下图所示：

这三个版本不是简单的新旧关系，而是针对不同使用场景和约束条件设计出来的三条并行轨道。

Standard ABAP：完整语言范围，无访问限制

Standard ABAP 是一个 unrestricted ABAP language version，专门用于 classic ABAP 开发场景。

从语言元素覆盖范围来看，Standard ABAP 包含了 ABAP 语言的全部能力。

只要是在 Unicode 系统里能用的 ABAP 语法，Standard ABAP 都支持。

这种版本的 ABAP 程序可以访问系统里的所有 repository objects，没有额外的访问控制。

Standard ABAP 的 syntax check 执行的是 Unicode check，这也是 Unicode 系统对 ABAP 程序的最低要求。

这个版本的定位很清晰：如果我们在做传统的 On-Premise ABAP 开发，不需要考虑 Clean Core、不需要考虑升级安全性、不需要把代码迁移到云端，那么 Standard ABAP 就是最合适的选择。

它给了开发者最大的自由度，同时也意味着开发者需要自己承担使用非公开 API、直接访问数据库表、调用未发布对象等行为带来的风险。

ABAP for Cloud Development：受限语言范围，为升级安全而生

ABAP for Cloud Development 是一个 restricted ABAP language version，专门为 ABAP Cloud 环境设计。

它的核心设计原则是：在保证升级安全的前提下，提供尽可能完整的开发能力。

Standard ABAP 的通用规则在 ABAP for Cloud Development 里仍然适用，但语言元素的支持范围被大幅收窄，只有一个非常有限的子集可以使用。

对 repository objects 的访问也受到严格限制。

更重要的是，ABAP for Cloud Development 强制要求所有开发必须在 ABAP 类的方法内完成，并且类的语法规则会自动从更严格的模式生效。

这意味着我们不能像 Standard ABAP 那样随意写 procedural code，所有逻辑都必须封装在类的方法里。

ABAP for Cloud Development 还有一个关键约束：obsolete language elements 被完全禁用。

那些在 ABAP 演进过程中被标记为「不推荐使用」的语法，在这个版本里直接不允许出现。

对于 ABAP SQL，ABAP for Cloud Development 应用的是最严格的语法检查规则。

Client isolation 也被强制执行，这意味着跨 Client 的数据访问受到严格管控。

ABAP for Cloud Development 这个版本的设计逻辑很明确：通过语法层面的约束，把那些可能破坏升级安全性、可能依赖内部实现、可能绕过标准扩展机制的代码路径全部封死。

开发者失去了一部分自由度，但换来的是系统升级时更高的稳定性和可预测性。

ABAP for Key Users：嵌入式增强的极简版本

ABAP for Key Users 是为 Key User Extensibility 场景专门设计的一个受限版本。

它的定位更加特殊：这是一个嵌入在 SAP 标准应用里、允许业务用户或者具备基础编程能力的 Key User 做轻量级增强的开发环境。

ABAP for Key Users 基于 Standard ABAP 的通用规则，但支持的语言元素少得惊人，只有一个非常小的子集可用。

和 ABAP for Cloud Development 一样，它也强制要求所有逻辑必须在 methods 里实现，类的严格语法规则自动生效，obsolete language elements 被禁用。

更重要的是，对 repository objects 的访问限制比 ABAP for Cloud Development 还要严格，具体的限制规则在 SAP 文档里有说明。

有一个细节值得注意：ABAP for Key Users 不被 ABAP keyword documentation 支持。

这意味着如果我们在 Key User 环境里写代码，F1 帮助无法提供完整的语法参考，只能看到一些简化的说明或者 ABAP 语法图表。

ABAP for Key Users 这个版本的设计目标非常明确：让不具备完整 ABAP 开发能力的用户，也能在一个受控的、安全的边界内做一些简单的业务逻辑扩展。

它牺牲了几乎所有的灵活性，换来的是更低的使用门槛和更可控的风险。

三个版本如何选择

理解了三个版本的设计逻辑之后，选择策略就很清晰了。

Standard ABAP 适用于传统 On-Premise 开发场景。

如果我们的系统运行在客户自己的数据中心，升级节奏由客户自己控制，代码也不需要迁移到云端，那么 Standard ABAP 是最合适的选择。

它提供了完整的语言能力，开发效率最高，但代码的升级安全性需要开发者自己把控。

ABAP for Cloud Development 适用于云端开发和 Clean Core 场景。

如果我们的系统运行在 SAP BTP ABAP Environment 或者 SAP S/4HANA Cloud 这样的云环境里，或者我们希望在 On-Premise 系统里也遵循 Clean Core 原则、确保未来能平滑迁移到云端，那么必须使用 ABAP for Cloud Development。

它的语法约束看起来很多，但这些约束正是升级安全性的保障。

ABAP for Key Users 适用于 Key User Extensibility。

如果我们的扩展场景是在 SAP 标准应用的 Key User 工具里完成，比如通过 Custom Logic、Custom Fields、Custom CDS Views 这些能力做业务逻辑增强，那么自动使用的就是 ABAP for Key Users。

这个版本不是开发者主动选择的结果，而是由工具环境决定的。

另外，除了 ABAP 程序之外，其他类型的 repository objects（比如 CDS View、DDIC 对象等）也可以有自己的 ABAP language version 属性。这些对象的语言版本设置，会影响到它们能被哪些程序访问、能使用哪些特性。

SAP 官方文档里有一个叫 Released APIs 的主题，专门列出了在 restricted ABAP language versions 里可以使用的 API 清单。

如果我们要写 ABAP for Cloud Development 的代码，这个清单就是我们的「白名单」。

小结

ABAP Language Version 不是一个可有可无的技术细节，它是 SAP 在云化转型过程中，对语言本身做的一次架构级分层。

Standard ABAP 代表的是传统开发模式的完整能力和灵活性。

ABAP for Cloud Development 代表的是云原生开发对升级安全性和架构约束的坚持。

ABAP for Key Users 代表的是让更多人能参与扩展开发的普惠理念。

三个版本并存，不是历史包袱，而是对不同场景、不同约束条件的精准适配。

我们在写每一行 ABAP 代码之前，都应该先问自己一个问题：

这段代码的 Language Version 是什么？

这个问题的答案，会直接决定我们能用什么语法、能访问什么对象、以及这段代码未来的生命周期有多长。