之前的文章有朋友留言:

本文就聊聊 ABAP,ABAP NetWeaver,ABAP Platform,SAP BTP 上的 ABAP 环境这几个名词的联系和区别。

ABAP 是一门编程语言的名称,笔者之前的各种文章有详细介绍。笔者和这个公众号半数以上的粉丝朋友们,都曾经、正在并将继续靠 ABAP 来谋生。

ABAP 真的会过时吗?聊聊 ABAP 的过去,现在和未来

SAP NetWeaver 平台中的 ABAP

SAP NetWeaver 是 SAP 于 2004 年推出的一体化技术平台,用于整合企业各种异构应用和技术。它将数据库、中间件、应用服务器等组件集合在一个统一架构下,使企业能够在这个平台上集成数据和业务流程。

下图是 SAP 官网于 2004 年发布 NetWeaver 的网页截图:

在 NetWeaver 架构中,最重要的部分之一就是 SAP NetWeaver Application Server (AS),它提供运行业务应用的环境。其中又细分为 AS ABAP 和 AS Java 两种运行时,分别支持 ABAP 和 Java 语言的应用开发。

简单来说,SAP NetWeaver 时代的 ABAP 就是运行在 AS ABAP 上的 ABAP 应用服务器环境。

在 NetWeaver 平台中,ABAP 继续扮演着开发 SAP 商业应用的主力角色。SAP 的大部分经典业务套件(如 ERP ECC、CRM、SRM、SCM 等等)都是基于 AS ABAP 实现,其应用逻辑由 ABAP 编写。正因为那个时代 ABAP 在 SAP 解决方案中所处的统治级地位,大家说起 NetWeaver,会习惯在其前面加上 ABAP 的前缀。 

NetWeaver 为 ABAP 提供了全面的基础设施,包括底层的 SAP Basis(提供用户管理、权限、安全等功能)以及 Open SQL 接口 和运行时框架,让 ABAP 程序可以独立于具体数据库和操作系统运行。这个经典的特性使得基于 ABAP 的应用具有良好的可移植性。

任何一个用 ABAP 开发并采用 OPEN SQL 进行底层数据读写的业务模块,可以在 Oracle、DB2 或 SAP HANA 等不同数据库上运行,而无需更改代码。

为了满足企业不断演进的需求,NetWeaver 时代的 ABAP 平台也在不断升级拓展。例如,2003 年左右引入的 Web Dynpro for ABAP 让 ABAP 可以开发基于浏览器的 Web UI;2000 年代中后期,ABAP 支持了 Enterprise Services(基于 SOAP 的 Web 服务)以实现面向服务的架构。笔者正是在那个时候,大学毕业加入了 SAP,开始从事 SAP 第一款云产品 SAP Business By Design 的研发工作,一干就是五年。

2010 年前后,随着移动应用兴起,ABAP 后台也开始为 OData 服务和 SAP UI5 前端提供支持。笔者现在正在写的 SAP UI5 开发教程和 SAP OData 开发教程里介绍的技术和经验,都是那几年时间习得的。

以上这些 NetWeaver 的不断进化,都使传统 ABAP 环境逐步适应互联网和分布式架构的趋势。

NetWeaver ABAP 在全世界企业管理软件领域取得的极大成功,其作为一个开发平台具有的强大灵活性和可扩展性可谓功不可没。在实际 SAP 实施项目中,很多 SAP 客户基于 NetWeaver ABAP 平台实施了深度的二次开发。

比如通过配置和二次开发,对 ABAP 本就复杂的定价规则进行扩展,使其符合企业自身一些个性化需求;通过 BAdI 在标准订单保存流程中嵌入自定义 ABAP 逻辑,根据商品类别和库存水平触发各种工作流。这些增强都是典型的 NetWeaver 时期 ABAP 二次开发场景,展示了 ABAP 作为企业开发语言的灵活性。

需要注意的是,SAP NetWeaver 本身是一个产品家族的统称,不仅包括 ABAP 和 Java 应用服务器,还包含诸如商务智能(BI)、企业门户 (EP)、流程集成 (PI/PO) 等多个组件。然而在 SAP ERP 等核心业务领域,ABAP 平台始终是 NetWeaver 的基石。一直到 SAP Business Suite 的最后一个版本(SAP ECC 6.0 EHP8)以及早期的 SAP S/4HANA 1511/1610,都还是运行在 SAP NetWeaver AS ABAP 之上。

SAP NetWeaver AS ABAP 7.52(对应 SAP Basis 7.52)是 NetWeaver 时代最后一个 ABAP 版本,SAP 官方已明确 7.52 之后不会再有新的 NetWeaver 发行版,新功能开发也逐步转向下一个平台。

NetWeaver 平台本身的维护将在 2030 年底结束。

从 NetWeaver 到全新的 ABAP Platform

SAP ABAP Platform 通常指代 S/4HANA 时代的 ABAP 技术平台。

SAP 在推出 SAP ERP 的继任产品,即 S/4HANA 时,对底层 ABAP 平台进行了重大升级,并赋予它「ABAP Platform」这一新名称,以区别于早期的 NetWeaver ABAP 平台。

ABAP Platform 的出现,标志着 SAP 技术基石从 NetWeaver 向新架构的演进和更替。

从 ABAP NetWeaver 到 ABAP Platform,一个里程碑式的时间节点是转折发生在 2018 年,这一年SAP S/4HANA 1809 版本发布,它并不再采用旧的 NetWeaver 7.5x 内核,而是运行在全新的 ABAP Platform 基础上,ABAP 内核版本提升到 7.7x。

这一更换使得 S/4HANA 的底层与之前 ECC 时期的 NetWeaver 7.53 内核不再兼容——意味着 SAP 借此机会「移除了一些遗留的技术和兼容层」,为未来发展清理道路。

这标志着 ABAP Platform 不再完全遵循 SAP 之前向后兼容至上(backward compatibility)的原则,而是在必要处做出不兼容改动,以充分利用新技术(特别是 SAP HANA)的优势。

那么,ABAP Platform 与过去的 ABAP NetWeaver 相比有何不同?

数据库层面的变化最显著:SAP S/4HANA 强制使用 SAP HANA 作为唯一数据库,因此 ABAP Platform 针对 HANA 做了深度优化。例如,引入基于 CDS(Core Data Service)的高级数据建模和 Code Pushdown 理念,让复杂数据计算尽量在 HANA 数据库层完成,提高性能。

这些新特性早在 NetWeaver 7.x 时代就开始酝酿(如 NetWeaver 7.40 推出了 Open SQL 的新语法和 CDS 概念),但在 ABAP Platform 上得到全面确立和增强。

运行时内核的更新:引入一系列功能提升和过时功能的移除。例如,ABAP Platform 内核进一步完善了新的锁机制 Enqueue Server 2 (ENSA2)、支持 HTTP/2 协议等,使系统更适应现代云环境;同时某些早已不推荐使用的编程模型在新平台上受到限制或不再支持,以引导开发者采用更新的技术。

举例来说,在 ABAP Platform 上 SAP 淡化了经典 Dynpro 屏幕技术,对新开发则鼓励使用基于 Fiori 的 SAPUI5/OData 架构;又如曾经用于布局界面的 GUI 控件 (例如经典 ALV Grid Control) 在 S/4HANA Cloud 中已被 Web 版的 Fiori Elements 所取代。

需要强调的是,ABAP Platform 本身并不是面向客户直接销售的独立产品。它作为 S/4HANA 的一部分交付,并没有单独的发行版本号。

通常我们以 S/4HANA 的版本年份(例如 S/4HANA 2020、2021)来间接指代其中所包含的 ABAP Platform 版本。

例如,大家会说「S/4HANA 2021 的底层 ABAP Platform 提供了新的 RESTful 应用编程模型」等等。

ABAP Platform 可以看作是 SAP 在 S/4 时代对 ABAP 技术栈的重新命名和持续创新,它继承了 ABAP 数十年的企业级稳定性,同时针对 SAP HANA 和云架构进行了优化。正因为如此,ABAP Platform 成为 S/4HANA 赖以构建的基础,在实现更高性能和更现代开发范式的同时,依然支持广大 ABAP 开发者平滑过渡他们的技能和大部分代码。

事实上,对于经历了 ECC 到 S/4 HANA 迁移的企业来说,绝大部分现有 ABAP 代码可以在 ABAP Platform 上继续运行,只是某些与底层数据模型耦合紧密或使用了不推荐技术的部分需要重构。这种延续性使得企业过渡到 S/4HANA 时可以平滑升级,保留多年积累的 ABAP 资产。

SAP BTP 上的 ABAP 编程环境

ABAP, ABAP NetWeaver, ABAP Platform, SAP BTP ABAP 环境这几个概念的联系和区别

随着云计算时代的到来,SAP 在其云平台 SAP BTP(Business Technology Platform)上推出 ABAP 编程环境,为开发者提供一种基于云的 ABAP 开发与运行平台。这一环境的内部代号称为 「Steampunk」,参考笔者另一篇文章:

从SAP社区上的一篇博客开始,聊聊SAP产品命名背后的那份情怀

而官方名称就是 SAP BTP ABAP Environment.

本质上,它是在云中托管的 ABAP Platform,以 PaaS 形式提供给用户。换言之,SAP 将多年积累的 ABAP 技术提升为云服务,让 ABAP 开发者也能在云端开展现代应用开发。

SAP BTP 上的 ABAP 环境与传统 ABAP 平台既一脉相承,又有所不同。

相承之处在于:它使用的语言还是 ABAP,底层内核与 S/4HANA 的 ABAP Platform 共享相同的代码线,运行于 SAP HANA(Cloud)数据库之上,支持开发者熟悉的 ABAP 语法和许多标准库。因此,掌握了 ABAP 的开发者可以在短时间内上手云端 ABAP 开发。

同时,不同系统之间传输 ABAP 代码也成为可能 —— 例如利用开源工具 abapGit,可以在本地 ABAP 系统和 SAP BTP 云端 ABAP 环境之间同步代码,从而实现代码版本管理与迁移。具体技术细节请参阅笔者这篇文章:

使用 abapGit 在 ABAP On-Premises 系统和 SAP 云平台 ABAP 环境之间进行代码传输

差异和限制:主要体现在云环境对开发模式和安全合规的特殊要求。SAP BTP ABAP 环境采用了「ABAP Cloud」的编程模型,也就是面向云的 ABAP 开发模型,强调与 S/4 核心解耦和云端的多租户安全。这带来了一些在传统 ABAP 里没有的规则:

👉只允许使用白名单内的代码和接口:开发者在云 ABAP 环境中不能像在本地那样调用任何 SAP 内部函数或直接访问系统表,而只能使用 SAP 正式发布的、被标记为 Released 的 API、类、接口和 CDS 视图等对象。这确保了云端扩展不会因为内部实现变化而失效,并保护了底层核心的完整性。

关于 SAP Clean Core 的更多介绍,请参阅笔者这篇文章:

SAP Clean Core 对传统 ABAP 开发人员来说意味着什么:机遇和挑战

👉禁止使用某些传统语法:例如,在云端 ABAP 编程环境中无法进行经典的 Dynpro 屏幕开发,也无法使用像 WRITE 这样的列表输出命令和 CALL TRANSACTION 这样的事务调用。这意味着云 ABAP 不支持直接在 SAP GUI 界面输出列表或调用传统事务码,取而代之的是通过 Fiori 界面、浏览器或其他服务接口与用户交互。

笔者之前的文章包含了一些详细的例子:

👉开发与运维方式云化:在 BTP ABAP 环境中,开发者不直接登录服务器安装软件,而是通过 ABAP Development Tools 或 Visual Studio Code 的 ABAP 插件远程连接到云实例进行开发。

一切 Transport 更像是 Git 模式,开发完成后通过 CI/CD pipeline 部署。基础设施如内存、CPU 由 SAP 云自动管理扩展,开发者无需操心。

笔者这篇文章包含了一个可以实操的例子:

基于 abapGit 和 abaplint 的 ABAP 持续集成的一个例子

以上这些差异可能用一个真实场景来说明更为直观。

假设一家使用 S/4HANA Public Cloud 的零售企业,需要一个额外的库存预警应用。由于公有云的 S/4HANA 不允许传统方式在系统里新增 Z 程序,该企业的开发团队决定在 SAP BTP ABAP 环境中构建这个扩展应用。

他们在云上的 ABAP 环境新建了一个 ABAP 项目,开发了若干 RESTful 服务和后台逻辑:定期从 S/4HANA 通过 OData 接口读取库存数据,在云端进行计算分析,一旦发现库存低于阈值,就触发邮件通知。整个应用的 ABAP 代码严格遵循 ABAP Cloud 模型,只使用 SAP 发布的 API 获取 S/4HANA 数据,逻辑处理后调用 SAP BTP 的邮件服务发出通知。

开发完成后,客户将应用部署在 SAP BTP 上运行,并通过 SAP Launchpad Service 提供给业务用户使用。这一过程体现出云端 ABAP 环境的工作模式:Side-by-side 在云端扩展核心系统功能,保持了 S/4HANA 核心系统的干净稳定(Clean Core),同时满足了个性化需求。

名词联系与区别总结

我们来给文章做一个总结:

ABAP、ABAP NetWeaver、ABAP Platform 和 SAP BTP 上的 ABAP 环境可以看作是 SAP ABAP 技术发展的不同侧面和阶段,它们既一脉相承又各有侧重:

  • ABAP(语言本身):指 SAP 的高级业务应用编程语言,不管其如何演变,核心不变的是为企业业务处理提供强大、高度集成的应用开发能力。

  • ABAP NetWeaver:描述 SAP NetWeaver 技术栈下 ABAP 运行环境的名称。2000 年代中期至 2010 年代中,SAP 的大部分商业应用运行在 NetWeaver 平台,该平台包含 ABAP 应用服务器。因此「ABAP NetWeaver」可以理解为「基于 NetWeaver 的 ABAP 平台」。支持多数据库、多操作系统,强调向后兼容和稳定。例如 SAP ERP ECC 6.0,很多老版本 SAP 系统(如 CRM 7.0、SRM 7.0)运行的就是 NetWeaver ABAP 平台。

  • ABAP Platform(S/4HANA 时代的 ABAP 平台):指 S/4HANA 所使用的新一代 ABAP 技术平台。从 2017–2018 年开始,SAP 逐步用 ABAP Platform 这个术语来替代原来的 NetWeaver ABAP,强调其为 S/4 量身打造。ABAP Platform 仅运行在 SAP HANA 数据库上,内核版本大幅提升(7.7+),并包含许多现代化功能(CDS、AMDP、RAP 模型等)。它不再作为独立产品提供,只能随 S/4HANA 版本交付给用户。ABAP Platform 依旧是 ABAP 语言,但在开发模式上鼓励 Clean Core 和基于云的扩展理念,是连接传统 ABAP 世界与云时代的桥梁。

  • SAP BTP ABAP 环境:这是 SAP 提供的基于云的 ABAP 开发平台,即 ABAP 作为一种 PaaS 服务。它和 ABAP Platform 共享同宗的技术内核,但运行在 SAP BTP 的 Cloud Foundry 环境中,采用租户隔离、多租户架构。它主要用于云端扩展和新应用开发,特别适合 S/4HANA Cloud 等无法直接修改的场景。由于其云属性,它有一系列使用约束(只能用白名单 API、无 GUI 支持),以确保安全和升级无影响。可以把 BTP 上的 ABAP 环境看作 ABAP 平台在云上的延伸和特殊化。这个环境常被简称为「Steampunk」,其定位是「企业级且云就绪的 ABAP 平台」。

这几个概念之间的区别可以从以下几个方面来理解。

  • 环境定位不同:NetWeaver ABAP 是本地部署环境,服务于 SAP Business Suite;ABAP Platform 服务于 S/4HANA(本地或私有云部署为主);BTP ABAP 环境则是公有云服务。

  • 基础架构要求:NetWeaver ABAP 支持多数据库(包括 Oracle、DB2 等),ABAP Platform 专属 SAP HANA 数据库,BTP ABAP 环境运行在 SAP HANA Cloud(SAP HANA 的云服务版本)上。操作系统方面,NetWeaver 时代支持 Windows/Linux/AIX 等广泛平台,而最新的 ABAP Platform 更多部署在 Linux(尤其是针对 HANA 优化的 SUSE Linux)环境上。

  • 开发模型演变:NetWeaver ABAP 允许经典 GUI、Dynpro 等技术,代码可以自由访问大部分 SAP 对象;ABAP Platform 开始引入封装与云化思想,但在本地部署时仍兼容 GUI 开发,只是提供了更新的 RAP 模型供选择;而 BTP ABAP 完全采用全新的云开发模型(只能使用 Fiori 和服务接口,与核心松耦合)。

  • 版本交付模式:NetWeaver ABAP 有独立版本号(如 NW 7.50),ABAP Platform 以 S/4HANA 版本号体现(如 S/4HANA 2022 包含 ABAP Platform 2022),BTP ABAP 则作为云服务持续更新,无固定版本概念,通常按季度发布新功能。

最后,从历史渊源来看,ABAP 的发展轨迹体现了 SAP 技术平台从大型机年代走向云时代的演进轨迹:从早期报表语言成长为 NetWeaver 集成平台中的中流砥柱,再蜕变为支持 HANA 和云架构的新平台,直到今天以云服务形式提供给开发者。

每一次演进背后,既是技术趋势的推动,也是 SAP 生态与用户需求的驱动。

例如,NetWeaver 的提出顺应了 SOA 和企业应用集成浪潮,而 ABAP Platform 的出现则源于内存计算和数字化转型的需求,BTP 云 ABAP 环境则响应了客户希望在云端安全扩展的呼声。

可以预见,ABAP 作为 SAP 核心开发语言的地位将继续保持,但承载它的平台会不断升级,以拥抱新的技术机遇。从 ABAP NetWeaver 到 ABAP Platform 再到 ABAP 云环境,这些名词的演变正是 SAP 技术革新的缩影——既保持业务连续性,又不断注入新活力,使得无数 ABAP 开发者能够在新时代继续施展才华,服务企业业务创新。