现代 ABAP 编程模型的演进史

笔者 2021 年曾经写过一篇文章，介绍了 ABAP 从诞生到今天的发展历史。

ABAP 真的会过时吗？聊聊 ABAP 的过去，现在和未来

本文重点介绍现代 ABAP 编程模型的演进历史，图片来自这篇 SAP 社区博客：

1. 经典 ABAP 编程模型

目前国内很多 SAP 客户仍然在使用基于 ABAP 版本 7.40 或更低版本的 SAP 软件。

在这些 ABAP 版本中，有多种用户界面技术可用于构建应用程序，例如经典的 Dynpro、Web Dynpro ABAP、Floorplan Manager 和 WebClient UI 框架。

从 ABAP 7.40 这个里程碑的版本开始，SAP 大力优化了 ABAP 平台，以更好地支发挥内存数据库 SAP HANA 的运算能力。

在此背景下，SAP 推出了 ABAP Core Data Service，提供了新一代的数据建模基础设施和数据访问方式。

同传统的 ABAP DDIC 数据模型相比，基于 CDS 的数据模型是一种语义丰富(Semantically Rich)的数据模型，适用于所有应用领域。

所谓语义丰富，是指 CDS View 源代码中数可以添加各种 Annotations 作为元数据注释，这些注解既包含与业务对象相关的详细信息，如性别代码、地址类型、货币单位等业务层面的元数据，也提供被 Fiori Elements 等技术框架解析并生成对应处理逻辑等技术层面的元数据。

此外，从 ABAP 7.40 版本起，SAP Gateway 成为 ABAP 应用服务器的组成部分，BOPF 开发工具也在 ABAP 7.5 版本集成到平台中。

2. ABAP Programming Model for SAP Fiori

为了应对现代 Web 应用程序的用户体验需求，提供更好的对移动设备的支持，以及配合公司向云端转型的产品战略，SAP 决定支持前端与后端之间的 RESTful 通信方式。

同时，SAP 采用了全新的基于角色的用户体验设计原则，推出了现代化的 SAP Fiori 开发栈，主要包括以下内容：

• SAPUI5 作为 SAP HTML5 UI 开发工具包，通过 SAP Fiori Elements 提供可复用的构件和完整的页面布局，大幅提升常见应用模式的 UI 开发效率。

• OData 作为基于 REST 的协议，包含元数据支持，允许采用模型驱动的方法进行开发，并支持基于 SAP Fiori Elements 的 UI 开发。

• 用于实现业务逻辑的 ABAP 平台。

• 基于 Eclipse 的 ABAP Development Tool 和用于前端开发的 SAP Web IDE.

SAPUI5 和 OData 成为了 SAP Fiori 开发栈的核心技术。

为此，SAP ABAP 平台团队，致力于开发一种新的编程模型，提供一种高效且标准化的方法，用于构建各种类型的应用程序，包括事务型(Transactional)和分析型(Analytical).

这些应用程序不仅针对 SAP HANA 进行了优化，还具备优良的用户体验，比如适配各种移动设备、可扩展性和支持在云端运行。

同时，该模型还需要保留 ABAP 平台的核心资产，如生命周期管理和升级支持能力。

该模型的另一个目标是，现有的 ABAP 开发人员能够快速上手。

这个模型就是 ABAP Programming Model for SAP Fiori：

随着 7.50 版本的发布，面向 SAP Fiori 的 ABAP 编程模型首次出现在 ABAP 开发人员的视野里，并在后续版本中进一步增强。

面向 SAP Fiori 的 ABAP 编程模型提供了一种标准化的方法，用于高效开发现代化的基于 Web 的应用程序，涵盖搜索、事务型和分析型应用程序。ABAP Programming Model for SAP Fiori 也是当时 SAP S/4HANA 应用程序开发采用的最佳实践。

该编程模型基于现代且经过验证的技术，包括 CDS、BOPF 和 SAP Gateway.

如下图所示，通过 SEGW 工具中的 Reference 功能，可以迅速将 CDS 模型的内容导入到正在开发的 OData 项目中。

关于这个功能更详细的介绍，请参考笔者的文章：

添加了 @OData.publish 注解的 SAP CDS view 发布的 OData 服务，为何不支持修改和创建功能？

为了支持事务处理，在此过程中还引入了基于 CDS 的轻量级 BOPF 框架。

在 ABAP 7.51 版本中，引入了草稿处理功能(Draft-Handling)，用于设置独占锁并支持临时数据的持久化存储。

所谓 Draft-Handling，用于在 SAP 业务数据的编辑过程中，实时保存未提交的更改。

该机制允许用户在多个会话或者繁琐的表单填写步骤中，逐渐构建和修改数据，并在需要时将其提交。

在实际应用中，Draft Handling 可以显著提高用户体验，因为它允许用户在输入数据时不必一次性完成所有步骤，而是可以分阶段进行。这不仅提高了工作效率，还减少了因意外中断而导致的数据丢失风险。

这也就是 SAP 官方文档中 Continuous Work 的含义。

Draft Handling 技术实现的核心思想是，在后台 ABAP 数据库中创建一个未提交的版本（草稿），并在用户完成编辑和确认无误后，再将该草稿版本提交为最终数据版本。在此过程中，Fiori 应用会对用户的操作进行跟踪，并确保不同用户之间的编辑不会相互干扰。

如下图 SAP S/4HANA Material 产品主数据的 Fiori 应用为例，尽管这个产品存在 Validation 校验错误，但是当前的编辑仍然可以通过 Draft 的形式保存。

在离开当前编辑页面时，系统会询问用户，有三种选择：

1. Save：提交当前 Draft 修改，如果校验通过，当前 Draft 版本变成正式保存版本。

2. Keep Draft：保留当前 Draft 版本，不做进一步处理。

3. Discard Draft：丢弃当前 Draft 版本，数据回滚到最近一次成功提交保存的正式版本。

如果一条数据包含 Draft 版本，会在 Fiori Elements List Report 的 Smart Table 区域显式注明。

既然 ABAP Programming Model for SAP Fiori 这套编程模型已经提供了如此多的便利，为什么还会有接下来的 Restful ABAP Programming Model 呢？笔者下一篇文章会继续介绍。