昨天我转载了 ERP 大师的一篇文章：《被 SAP 弃用的十大开发技术盘点》之后，有朋友问我：
SAPUI5 Tools for Eclipse 和 ABAP Development Tool，这两个 IDE 都基于 Eclipse，但一个被 SAP 抛弃了，另一个仍然是 SAP 主推的开发工具，甚至地位还高于 SAP 自研的亲儿子 SAPGUI.
二者同源同宗，为什么 SAPUI5 Tools 被弃用，而 ABAP Development Tool 仍然是 SAP 的宠儿？
本文笔者从这个问题出发，来谈谈自己的看法。
在 SAP 官网针对 SAP UI5 开发工具的版块，SAP 明确宣布，不再提供 SAPUI5 Tools for Eclipse 的支持，也不提供下载。
https://tools.hana./#sapui5
SAP UI5 开发工具，经历了从 SAPUI5 Tools for Eclipse 到 SAP WebIDE，到现在主推的 SAP Business Application Studio/Visual Studio Code 的迁移路线。
这一演进路线背后，反映出的是 SAP 在前端开发领域，拥抱「开放与多云支持」的转型。
在 SAP UI5 发展的洪荒时代，SAPUI5 Tools for Eclipse 几乎是当时 SAP UI5 开发的唯一选择。
通过给 Eclipse 安装相应的 SAP UI5 插件，提供 SAP UI5 项目创建，本地预览，以及部署到 ABAP 服务器的基本功能。
本地开发需要解决本地启动并运行在 localhost 上的 SAP UI5 应用，连接远端 SAP ABAP 系统 OData 服务所引起的跨域问题。
SAP 为了解决这一本地开发的跨域问题，引入了 ResourceServlet，其实就是一个简单的本地代理。
我对 SAPUI5 Tools for Eclipse 的第一印象很差。
作为一个 IDE，连最基础的开箱即用的 SAP UI5 XML 视图和 JavaScript Controller 里的代码补全和提示功能都没有，需要繁琐的人工配置。并且生态圈封闭，因为除了 SAP 之外没有第二家公司用这个工具，遇到问题网上几乎查询不到任何资料。
比如我曾经遇到和 ResourceServlet 相关的问题，公司内也没找到可以问的同事，最后只能死磕它的源代码，把工作原理彻底搞透彻之后才得以解决。完事之后趁热打铁写了一篇博客，没想到阅读量很高，看来不止我一个人遇到类似的问题。
https://community./t5/technology-blog-posts-by-sap/explore-the-com-sap-ui5-resource-resourceservlet/ba-p/13116614
2014 年底时，SAP 成都 Fiori 开发团队成立，我加入了这个团队。
2015 年 1 月陆续有从外面招聘的新同事加入，我协助一位同事，花费整整一周的时间才完成他电脑上 SAPUI5 Tools for Eclipse 开发环境的搭建。期间出现各种幺蛾子，同样的配置在我电脑上运行正常，在他电脑上就无法工作。
我当时刚刚从 SAPGUI 这种服务器端开发范式迁移过来才一两个月，这种需要本地搭开发环境的做法让我一度非常不适应。
后来 SAP HANA Cloud Platform 诞生(就是今天 SAP BTP 的前身)，出现了 Neo 环境，以及运行在 Neo 环境上的 SAP WebIDE.
SAP WebIDE 的出现，是 SAP 前端开发工具演进的一个重要里程碑，因为它标志着 SAP 开发范式从「本地插件」转向「云端服务」的架构迁移。
从此，SAP UI5 开发者从浏览器即用即连，项目构建链、预览运行环境、与后端 ABAP 系统的连接通过 Neo 的 Destination 与相关服务统一承载。
这种集中式和服务器端托管的运行形态，天然避免了本地环境不一致带来的干扰，并把 SAP UI5 的多个 SDK 版本供给、内容分发与维护策略交由平台统一托管。这让我再次找回了一丝丝当初使用 SAPGUI 的爽快感觉。
由此，SAP WebIDE 在很长一段时间成为了 SAP UI5 开发当仁不让的主力，也间接将 SAPUI5 Tools for Eclipse 送进了坟墓。
随着 SAP Cloud Platform 更名为 SAP BTP，这个 SAP 重量级的 PaaS 解决方案，其发展战略也从「自建数据中心」的单一环境，转向面向主流 Hyperscaler 的多云架构(Multi-Cloud Environment).
这一战略也为 SAP BTP 上的 Neo 环境敲响了丧钟。
Neo 是 SAP BTP 早期的运行环境，主要在 SAP 自建的数据中心提供 PaaS 能力，支持 HTML5、Java 与 SAP HANA XS 等应用类型，并且天然贴合 SAPUI5 前端开发与企业集成场景。
SAP WebIDE 以及滋养其发展的土壤，SAP Neo 环境，在那个 SAP 自建数据中心的时代，称职地完成了其历史使命。
多云时代的开发范式，意味着在同一平台下自然地接入 Node.js、支持容器化工作负载、Serverless、事件驱动、以及第三方云服务的原生接入。Neo 的原生特性与服务边界决定了它无法胜任多云时代的开发需求。
图片出处：https://btp./overview/multicloud.html
笔者认为， SAP WebIDE 被弃用的最主要原因，并非其榜错了 Neo 这根大腿，而是其自身能力的缺陷。
大家不妨跟着我，简单梳理一下前端开发领域发展的时间线。
在 2009 年之前，前端主要依赖浏览器内的脚本标签与手工拼接。拐点来自 2009 年 Ryan Dahl 发布的 Node.js，它把高性能事件循环与 V8 带到命令行与服务器，给前端世界第一次提供了可编程的本地运行时。
Node.js 是后续一切前端工程化能力的地基。
2010 年，Isaac Schlueter 创建了 npm，极大降低了模块化复用与依赖分发的成本。此后 npm 成为 JavaScript 生态的事实标准包管理器。
面向浏览器的模块化尝试在 2011 年加速，Browserify 允许把 Node 风格的 require 模块打包进浏览器，由此把 Node 风格的模块与前端代码连接到了一起。
进入 2012–2014 年，前端社区的工作方式发生整体迁移：Grunt（2012）与 Gulp（2013）把任务自动化引入前端日常工作，Yeoman（2012）把脚手架规范化，Webpack（2014）确立了模块打包器的中心地位，这几件事共同宣告了基于 Node.js / npm 的工具链成为主流。
与此同时，框架层也完成现代化：AngularJS 在 2010 年发布，React 在 2013 年公开，前者验证了浏览器端应用的可行性，后者推动了组件化范式与配套工具链的成熟。
语言层面，ECMAScript 2015 在 2015 年正式定稿，Babel 在 2015 年由 6to5 正式更名，成为把新语法编译到旧环境的关键基础设施，进一步巩固了「书写现代语法 → 通过工具向下兼容」的工作方式。
2016 年 Yarn 发布，解决了安装一致性与性能问题；同年 React 团队推出 Create React App，默认就把开发者带进了 Node.js / npm + 打包 + 本地 Dev Server 的流水线。
2017 年之后，tree-shaking、code splitting 等优化在打包器中成为标配，npm v5 引入 package-lock.json 落实可复现安装；传统的 Bower 在 2017 年明确给出迁移指引，可以视为旧式前端包管理的谢幕。
2020 年，Vite 以原生 ES Modules 的开发服务器思路，让即时启动、极速热更新成为新基线，标志着现代前端工具从「重打包」走向「按需转译 + 轻打包」的新阶段。
以上啰里啰嗦说了这么多，最后一句话：所有这些都和 SAP WebIDE 无缘，它压根也无法跟上 npm 与 Node.js 主导的前端迭代节奏。
因此，SAP 才会推出基于Eclipse Theia 这个开源 IDE 框架，对多云环境开发范式支持更好更开放的 Business Application Studio.
架构基座的升级：基于行业主流开源的云端 IDE
SAP Business Application Studio 的底层技术路线采用了以 Eclipse Theia 为代表的开源 IDE 框架，带来与 Visual Studio Code 相似的交互范式与强扩展性。由此，即使是原本来自 SAP 生态圈之外的开发者，其熟悉的工程与插件生态也可以轻松自然延展到 SAP Business Application Studio，而不必被 SAP WebIDE 封闭的「私有插件体系」所束缚。
下图展示的是 SAP Business Application Studio 里可以根据实际项目需要，轻松安装生态圈丰富的各种扩展，一键扩展器功能。
面向多云的开发空间、一键即配、内置终端与 Git
SAP Business Application Studio 引入了 Dev Space 的概念，即按场景预置工具链与运行时（例如 SAP Fiori elements、移动开发、工作流等），带来「开箱即用但可按需扩展」的体验。每个 Dev Space 都包含集成终端、Git、问题视图、命令面板等现代 IDE 的标配能力，既满足可视化也不牺牲脚本化与自动化。
Fiori tools 原生整合，丰富的模板、建模器、引导式开发与适配项目
BAS 对 SAP Fiori tools 做了深度集成，包括向导式创建、页面建模器、引导式开发、模拟与部署管线等，并在 Visual Studio Code 与 BAS 双端共同提供扩展包。这使得 Fiori elements 的最佳实践可以连同工具链一起落地，显著降低团队在 OData、元数据、UI5 版本协同上的工作量。
针对企业最常见的二次开发诉求，BAS 还提供了基于 Adaptation Project 的应用变体开发与部署流程，覆盖创建、适配编辑器、以及向 ABAP 仓库或 Cloud Foundry 的交付路径。
以上 SAP Business Application Studio 对于现代前端开发工具链的原生支持，以及对于 SAP Fiori 家族开发方式的深度整合等能力，和 SAP WebIDE 来说就是妥妥的降维打击。
是时候给 SAP Neo 和 SAP WebIDE 说 farewell 了。二者将于 2028 年 12 月 31 日终止服务。
https://community./t5/technology-blog-posts-by-sap/farewell-neo-sap-btp-multi-cloud-environment-the-deployment-environment-of/ba-p/13560080
终于说到 ABAP Development Tool 了，该开发工具也基于 Eclipse，为什么命运和 SAPUI5 Tools for Eclipse 截然相反，成功挤掉了 SAP 的亲儿子 SAPGUI 的一哥地位，并且越活越滋润？
笔者认为，最主要的原因，就是二者服务的领域不同。
2015 年我和组内同事聊天时，曾经调侃前端开发领域也遵循「摩尔定律」，即每隔 18 个月，前端需要学习的新东西比之前增加一倍。大家看我前面梳理从 2009 年至今的前端开发时间线，是否能感觉到前端工程领域的快速发展？新的名词，技术，理念层出不穷。
实际上我做 SAP UI5 开发那段时间，看国内大厂开发工程师的技术博客，心里就犯嘀咕：每篇博客总有很多我没听说过的新概念新术语。而且感觉那段时间，国内的前端开发生态圈很浮躁，很多前端开发都以争先使用最新的工具和技术为荣，仿佛这样就能证明自己在开发领域的价值。
而 SAP 后端开发特别是 ABAP 这块，远远没有前端那么卷。ABAP 作为 SAP 主力的后端开发语言，其服务端编译与对象生命周期始终在 ABAP 应用服务器之内，走的是一条和 Node.js 截然不同的发展道路，也就牢牢保持了自己的特色，其发展更不会被 Node.js 生态所影响。
在很长一段时间里，SAPGUI 是 ABAP 开发者的日常入口：SE80、SE11、SE38 的蓝底灰框，承载了全球无数 SAP 客户信息系统的构建与演进。
SAPGUI 作为一个基于专有协议与传统客户端技术的经典 IDE，其通信内核建立在 NI 与 DIAG 协议之上，这是 SAP ABAP 服务器经典三层架构里连接表示层与应用层的专有通道，默认以 TCP 承载、以压缩为主而非默认加密，运维上通常还要借助 SAProuter 与特定端口开放。
https://help./docs/ABAP_PLATFORM_NEW/e245703406684d8a81812f4c6334eb2f/486ca3b66c0707dce10000000a42189d.html
这套封闭的技术体系对企业内网非常友好，但对跨互联网的云网隔离、零信任与标准 HTTP(S) 网关并不天然贴合。
SAPGUI 作为 Rich Client 的代表，不可避免的深度依赖本地操作系统控件。
例如 SAP GUI for Windows 使用 Microsoft Controls 技术，本机注册控件、集成本地浏览器控件。这种模式在跨平台开发场景下有天然的局限性，即便有 SAP GUI for Java、SAP GUI for HTML 作为补充，功能与一致性也存在差异与限制。
https://help./docs/sap_gui_for_windows/1ebe3120fd734f67afc57b979c3e2d46/78cb9f653b1c465c9f1b7009c515c94e.html
经典的 ABAP 开发围绕 SE80 里的 ABAP 对象展开：ABAP 报表、Function Group 和 Function Module、透明表、ABAP 数据字典、ABAP 类，ABAP Webdynpro / BSP 应用等等。
这些 ABAP 开发对象与 SAPGUI 的 SE80/SE11/SE38 深度绑定。
进入云开发时代，ABAP 开发模型迁移到 ABAP Cloud + RAP：用 CDS 建模、用 Behavior Definition/Implementation 定义事务语义、用 Service Definition/Binding 暴露服务、用 IAM 与 Restriction Type 做访问控制、用 ATC 做质量门禁。而这些核心开发对象的创建与维护，都选择了 ABAP Development Tool 作为唯一入口。
ADT 的架构是 Eclipse 客户端通过 HTTP(S) 访问后端 ICF 服务 /sap/bc/adt，所有开发对象的创建、编辑、激活、链接跳转都走标准 Web 通路；甚至可以直接分享一个开发对象的 HTTP 链接给同事在浏览器渲染其元数据。这种通路天生适配云端 WAF、反向代理与标准证书体系，也便于统一接入与审计。
从网络协议与客户端形态两端看，ADT 与 SAPGUI 已经走上了两条截然不同的岔路：ADT 拥抱标准 HTTP(S) 与 Eclipse 生态，而 SAPGUI 固守私有协议与 Rich 客户端。
笔者认为二者并不存在孰优孰劣之说，而是适配对象，服务领域不同。
在我心中，SAPGUI 就是传统 ERP 时代的生产力工具；ADT 则是面向多云与 ABAP Cloud 的基础开发设施。
值得一提的是，ADT 并非一夜之间上位，它和 SAPGUI 的 PK 持续了很长时间。在 ABAP NetWeaver 后期，SAP 就开始把现代 ABAP 语言的诸多特性迁移到 Eclipse，例如更强的代码导航、重构、ABAP Doc 文档、单元测试、ATC 集成、HANA 对象集成等。
笔者清楚地记得，2012 年时，我还在做 SAP CRM 的标准开发，当时 ADT 还只是 SAP 一个内部项目，名叫 「ABAP in Eclipse」，简称 AIE.
笔者也算是 SAP 成都最早试用 ADT 的开发者之一，当时只觉得很新鲜，原来 ABAP 还能在 Eclipse 里编写？但也仅仅是试用，因为多年养成的 SAPGUI 使用习惯，很难习惯 ADT 那种 Eclipse 式的使用风格。
后来 2015 年去 SAP 德国总部出差，见到了 ADT 的开发团队，和团队的很多同事闲聊了很久。对方得知我正式开发中不用 ADT 后，怂了怂肩然后问我为啥不用。
我回答「ABAP 老司机根深蒂固的使用习惯」后，他们也点头承认，说：
ADT 对于德国刚毕业入职的大学生来说更具吸引力，因为他们还是白纸一张，没有被 SAPGUI 所洗脑。
如果说此时 SAPGUI 和 ADT 还地位相当，开发者可以二选一的话，那么随着 S/4HANA Cloud 与 BTP ABAP environment 上线，ABAP Cloud 成为规范开发模型，RAP 成为事务型应用的核心，Clean Core 成为企业级可升级性的治理原则，此时 ADT 已经不再只是和 SAPGUI 相提并论的 ABAP 代码编辑器，而是云时代 ABAP 「唯一的」基础开发设施与合规工具链入口。
ABAP Cloud 是在 BTP ABAP environment 与 S/4HANA 上统一的开发模型，目标就是云就绪与升级稳定，而 ADT 就是让这一开发模型落地的唯一工具。ADT 在 HANA 对象集成、OData 服务生成、Fiori 元数据驱动开发方面提供了大量向导与视图，切实提高了 ABAP 开发者的生产率。
另一方面，SAP BTP 的多云战略决定了平台落地在多家 Hyperscaler 上，开发、运维、服务绑定、证书与接入管理都以标准 HTTP(S) 与平台控制面为核心，ADT 与之匹配。
云时代提倡 ATC 质量门禁、单元测试覆盖、Git 流程、CI/CD 等理念。这些理念如今在 ADT 里均由了完善成熟的实现：ATC 集成、ABAP Unit 一键运行与覆盖率、abapGit for ADT 插件、gCTS 与管道集成。
这一切的一切 SAPGUI 都无法做到。
一句话：SAPGUI 并没有做错什么，只是时代变了。