2026 年，SAP ABAP 开发工具的发展方向

笔者之前发布了关于 SAP ABAP 开发工具现状的一篇文章和音频：

ABAP 开发工具已经进入战国时代！

以及相关的一篇视频报道：ABAP 开发工具的碎片化困境

还有这篇 15 分钟时长的音频：

深度解读 SAP ABAP 登录 Visual Studio Code 的技术内幕

其实我上下班地铁通勤，更喜欢阅读图文类型的内容，因为地铁里比较嘈杂，听音频的体验并不好。

今天给大家解读 2026 年 SAP ABAP 开发工具领域的一个大的动作：ABAP 即将正式登录 Visual Studio Code.

SAP 其实早已意识到，现在的开发者，尤其是年轻一代，更倾向于使用轻量级、响应速度快、插件生态极其丰富的 IDE，比如 Visual Studio Code. 

根据 SAP 的用户调研，VS Code 是呼声最高的开发环境，紧随其后的是 IntelliJ IDEA (JetBrains)、Neovim 甚至新兴的 Zed.

但是，把一个像 ABAP 这样历史悠久、功能复杂的语言移植到新的 IDE，绝非简单的“搬运”工作。这背后横亘着两座难以逾越的大山。

挑战一：290 万行代码的“冰山”

很多人可能觉得，开发工具不就是个代码编辑器吗？把语法高亮做出来不就行了？其实，我们看到的界面只是冰山一角。

ADT 采用的是经典的 Client/Server 架构。虽然代码存储在 ABAP 服务器上，但在客户端（Eclipse 端），SAP 积累了极其庞大的业务逻辑。这些逻辑包括：

从通信层来看，这一层需要处理与 ABAP 后端的 REST API 交互，而且必须兼容到非常古老的版本，比如需要一直兼容到 SAP NetWeaver 7.3 EHP1 SP04）。

从工具逻辑曾来看，ADT 需要实现作为一款 IDE 必须实现的调试器 (Debugger)、单元测试运行器 (ABAP Unit)、静态代码检查 (ATC)、性能分析 (Trace) 等基础功能。 

SAP 统计了一下，这部分 与 UI 无关的客户端逻辑代码高达 290 万行！

把这 290 万代码从 ABAP Development Tool 直接搬到 Visual Studio Code 上，是怎样的工作量？

这就好比你有一辆经过十几年改装的重型卡车（Eclipse 版 ADT），里面装配了最精密的导航系统、动力分配系统和安全系统（那 290 万行代码）。现在，用户说：“我想要骑摩托车（VS Code），因为摩托车更灵活。” 

如果你为了满足用户，决定重新造一辆摩托车，意味着你必须把卡车里那套复杂的导航和动力系统，用摩托车的零件（TypeScript/JavaScript）从头到尾重新造一遍。

这不仅工程量浩大，而且未来你必须同时维护“卡车”和“摩托车”两套完全不同的引擎。一旦 ABAP 后端有了新特性，你得在两边都写一遍代码。这对任何软件工程团队来说，都是不可持续的噩梦。

挑战二：对象编辑器的“寒武纪大爆发”

ABAP 的另一个特点是对象类型（Object Types）极其丰富。在 SAP BTP ABAP Environment 中，SAP 需要支持的编辑器数量高达 88 种！

相比之下，CAP (Cloud Application Programming model) 只需要一个 CDS 编辑器；Java 开发工具通常也只需要处理类、接口和枚举这几种。

但 ABAP 不一样，我们有 Data Definition、Service Definition、Behavior Definition、Transformation、Class、Interface、Function Group、Package 等等，每一种都有自己的特性和编辑规则。

如果每适配一个新的 IDE，都要为这 88 种对象重新写一遍编辑器插件，那工作量简直是天方夜谭。

面对这两座大山，SAP 的架构师们没有选择硬抗，而是选择了“智取”。他们从 2018 年开始探索，最终确定了两条核心的架构演进路线。

方案一：LSP 与“特洛伊木马”战术

现代 IDE 架构中，有一个伟大的发明叫做 LSP (Language Server Protocol)。

在 LSP 出现之前，如果你想在一个 IDE（比如 VS Code）里支持一种语言（比如 ABAP），你需要按照该 IDE 的私有 API 编写全套插件。如果想在 IntelliJ 里支持 ABAP，又得按 IntelliJ 的规则重写一遍。

LSP 定义了一套标准协议。IDE（客户端）不需要知道语言的细节，它只需要通过 LSP 协议告诉语言服务器：

• “用户在第 10 行第 5 个字符处停顿了。”

• “用户按下了‘转到定义’。”

语言服务器处理完逻辑后，通过协议返回结果：

• “这是一个变量，类型是 String。”

• “定义的具体位置在文件 B 的第 20 行。”

SAP 最初想过用 TypeScript 重写一个 ABAP Language Server，但很快发现这就是前面说的“重造卡车引擎”，行不通。

转机出现在 Java VS Code 扩展上。

SAP 的工程师发现，Red Hat 开发的 VS Code Java 扩展非常有意思。它并没有用 JavaScript 重写 Java 的编译逻辑，而是用了一个巧妙的办法：它在后台运行了一个「无头」的 Eclipse (Headless Eclipse)！

这简直就是一个天才的“特洛伊木马”。

VS Code 表面上看起来轻盈，实际上它通过 LSP 协议，在后台调用了那个在这个星球上最成熟的 Java 开发工具——Eclipse JDT。

SAP 决定研究这个方案的可行性。

SAP 的工程师们，将那 290 万行现有的 Java 客户端代码打包，通过一个轻量级的 LSP 适配层暴露给 VS Code。

对于 VS Code 来说，它面对的是一个标准的 LSP Server. 

对于 ABAP 后端来说，它面对的依然是那个熟悉的、成熟的 Eclipse 客户端。

这一招“移花接木”，完美保留了过去十几年积累的调试、重构和测试逻辑，同时实现了对 NetWeaver 老版本的兼容。

方案二：服务端驱动 UI (Server-Driven UI) 

解决了核心逻辑复用的问题之后，还要解决那“88 种编辑器”的 UI 渲染问题。

在早期的 Eclipse 插件开发中，编辑器的实现模式通常是后端 (ABAP)提供数据持久化，而前端 (Java/SWT)负责编写 UI 界面和交互逻辑。

这种模式导致每次出新对象类型（比如 SAP BTP 刚推出时），都需要 Java 开发人员和 ABAP 开发人员紧密配合，开发效率低且难以扩展。

SAP 的架构师们回顾了历史，发现了一个有趣的现象。

无论是古老的 Web Dynpro，还是现代的 SAP Fiori Elements，它们都有一个共同点：元数据驱动 (Metadata Driven)。

在 Fiori Elements 中，开发者主要在 CDS View 中写注解（Annotations），前端 UI 是根据这些元数据自动生成的。开发者不需要写一行 JavaScript 代码来画页面。

于是，SAP 的工程师们决定将这一理念引入 ADT 开发。

他们重构了编辑器的架构，不再为每种对象写特定的 Java UI 代码。现在的架构变成了：

• 后端 (ABAP)：不仅负责数据，还负责定义 UI 模型。

• 前端 (IDE)：只保留两个通用的“渲染引擎”。 

具体哪两个渲染引擎？一个是基于表单的渲染器 (Form-based Renderer)，用于显示像 Project Explorer、Properties 这种结构化数据。

另一个是基于源码的渲染器 (Source-based Renderer)，用于代码编辑器。 

想象一下浏览器的原理。浏览器本身并不针对“新浪新闻”或“淘宝商品页”写特定的代码。浏览器只认识 HTML 和 CSS 标准。服务器发过来什么样的 HTML，浏览器就渲染成什么样。

新的 ADT 架构也是如此。现在，当我们在 ADT 里打开一个 Number Range Object（这是第一个采用新架构的对象）时，ABAP 后端发送给 IDE 的不是原始数据，而是一套描述界面的“指令”。

IDE 里的通用渲染器读取这些指令，画出界面。

这一变革意味着，以后无论 ABAP 环境增加多少种新的对象类型（比如新的 RAP 定义文件），IDE 端都不需要升级插件代码。

只要后端发出的 UI 描述符合标准，IDE 就能直接显示。这极大地解耦了前后端，让新特性的交付速度飞了起来。

通过这两大架构变革，复用核心逻辑的 LSP 适配层和服务端驱动的通用 UI 渲染，SAP 终于打通了 ABAP IDE 的任督二脉。

这意味着什么？

首先是真正的跨平台。

除了 VS Code，未来理论上支持任何兼容 LSP 的编辑器（如 Vim, Sublime Text 等）都变得轻而易举。

其次是维护性的提升。SAP 只需要维护一套核心 Java 代码库，就可以同时服务 Eclipse 和 VS Code 用户。

当然，最重要的一点就是拥抱 AI，这也是我最看重的一点。

Visual Studio Code 目前拥有这个星球上最强的 AI 编程助手生态，GitHub Copilot 和 Cursor 等等。

一旦 ABAP 原生支持 Visual Studio Code，我们就能无缝享受到这些 AI 工具带来的效率红利。

想象一下，配合 SAP 自家的 Joule 或者 Copilot，直接在 IDE 里解释复杂的遗留代码，或者一键生成 RAP BO 定义，那画面真的是美如画。

根据 SAP 的路线图，这一全新的架构将在 2026 年第二季度正式为 Visual Studio Code 带来官方的 ABAP 工具支持。

虽然还需要等待一点时间，但考虑到这背后的工程难度和带来的长远价值，还是值得我们期待的。

作为一名 ABAP 开发者，我们正在经历这门语言诞生以来最大的变革。

从 On-Premise 到 Cloud，从 SE80 到 Visual Studio Code，工具在变，架构在变，但我们用 ABAP 养家糊口，用技术驱动业务价值的初心从未改变。

文章作者：汪子熙

文章来源：https://mp.weixin.qq.com/s/ZxTUvGfY67IqVRBLVSgPfg