SAP BTP ABAP 环境是用于 ABAP 开发的 SAP 平台即服务 (PaaS) 产品，使开发人员能够利用其传统的本地 ABAP 专业知识，在 SAP 业务技术平台中开发和运行 ABAP 应用程序，或者作为 SAP 软件的扩展或作为独立应用程序。

在我们进入 云端 ABAP 技术细节的讨论之前，不知道大家是否思考过一个问题：为什么 SAP 要把 ABAP 编程环境引入 SAP Cloud Platform?

SAP 安装的客户群将其现有的内部部署 SAP Business Suite 和 SAP NetWeaver 等产品，部署迁移到 SAP S/4HANA，包括 On-Premises 和云部署。客户将利用这个机会从根本上简化其在过去几十年中发展起来的系统 landscape. 现有的商务套件系统将尽可能整合到单一的 S/4HANA 实例中。客户希望将其核心业务流程的复杂性缩小到一个智能的数字核心(Intelligent Digital Core)，从而形成智能企业的支柱。

在传统的商务套件系统中，客户定制话内容无疑是复杂度极高的模块。经过企业的多年使用，自定义代码堆积如山。对 SAP 标准 ABAP 代码的直接修改，会给客户转向更高级别的版本或增强包的实施，带来极大的障碍。在这种情况下，当客户试图实施新的增强包到系统时，不得不投入大量的时间和精力花费在确保自定义代码在增强包实施后仍然能够正常工作。

如果客户的 ABAP 解决方案，部署在云端后，那么这些定制化代码又何去何从呢？

通过将 ABAP 开发和执行转移到 SAP Cloud Platform，客户和合作伙伴可以将所有基础架构、生命周期管理和系统运营任务委托给 SAP 的 DevOps 团队。 客户和合作伙伴可以立即受益于并采用由 SAP HANA 提供支持的 ABAP 堆栈的最新创新，从而可以在云中更快地使用创新，因为每个季度都会交付新的创新。

因此，区分哪些传统的 ABAP 语法，在云端 ABAP 编程环境里仍然可用，就成为 ABAP 开发人员必须掌握的知识之一。

SAP Cloud Platform ABAP 编程环境上的 ABAP 语法，只是广大 SAP 顾问们在 On-Premises 环境上使用的 ABAP 的一个子集。换句话说，On-Premises 环境下能正常工作的 ABAP 代码，单纯地复制粘贴到云环境上之后，可能就无法通过编译了。

看一些例子：

MOVE

修复这个语法错误很简单，直接用赋值操作“=”替换 MOVE 即可。话说这种错误应该只会出现在古旧的历史遗留代码上吧(Legacy Code), 大家现在写代码应该都不会用 MOVE 进行单纯的赋值操作了。

没有 Released for Cloud 的 Data Elements

每个 ABAP Development Tool 里创建的 ABAP Cloud 项目里都有一个 Released Objects 文件夹，里面维护着一个 ABAP 开发人员在云环境里能使用的对象清单，在 Data Elements 子文件夹里即是所有可用的数据元素。排在第一位的就是描述布尔类型的 ABAP_BOOLEAN.

同样是因为历史原因，大家知道在 On-Premises 环境里要定义一个布尔变量，我们可以有许多种类型定义的选择：boole_d, abap_bool, boolean 等等。

但是到了云上，大家还是老老实实使用白名单里维护的那些类型吧。

不是所有的 SYST 结构字段都能直接访问

结构体 SYST 里包含了很多系统字段，能让 ABAP 开发人员方便地获得一个 ABAP 应用执行时的各种维度的信息。

在 ABAP 云环境上，使用这些字段需要特别小心，以免遇到形如 Access to the field "SY-DATUM" is not permitted in the restricted language scope 这种语法错误：

正确的方式，应该用 CL_ABAP_CONTEXT_INFO=>GET_SYSTEM_DATE 这种工具类提供的方法。

下面是一些其他例子。

幸运的是，因为我们是在 ABAP Development Tool 这个 IDE 里编程，所以不用硬记这些 On-Premises 到 ABAP Cloud 上的语法转换规则。大多数时候，依靠 IDE 的语法报错或者 Quick Fix 功能都不难找到修复语法错误的线索。

当然如果嫌这种一条条修复的方式速度较慢，或者想象这样一个场景：您的 ABAP On-Premises 系统上有一个开发包，里面包含了很多 ABAP 二次开发代码，在将这些代码从 On-Premises 系统迁移到云上之前，我们可能会期望做一次统一的“Cloud Readiness”检查，一次性把所有上云的隐患都列出来。

传统的 ATC 检查(ABAP Test Cockpit, 一种 ABAP 代码检查工具)此时再次有了用武之地。按照这篇 SAP 社区博客How to check your custom ABAP code for SAP Cloud Platform ABAP Environment提到的 note 去做，在一个 ATC 中央检查系统上安装包含了新的 ATC 检查选项的实现 note：

这个新的 ATC 检查选项名称为 SAP_CP_READINESS_REMOTE，能帮助我们早在 ABAP 代码迁移到云环境之前，在 On-Premises 环境里就能够找出所有阻止当前被检查的 ABAP 代码上云的障碍。

当然这种检查反方向执行也是可以的，即在 SAP Cloud Platform ABAP 环境里，触发连接的 ABAP On-Premises 环境里的 ATC 检查。由于是云环境访问 On-Premises 环境，所以需要 SAP Cloud Connector 完成内外网穿越：

从 Fiori Launchpad 里进入 Custom Code Migration 这个应用，创建一个新的迁移项目：

迁移目标当然是 SAP Cloud Platform ABAP 环境，而迁移的源头是 ABAP On-Premises 环境，所以需要维护一个指向后者的 Destination，这个 Destination 在 SAP 云平台上创建。

此时我们就可以在 Fiori UI 上触发 ABAP On-Premises 系统上的 ATC 检查，并监控其进度。

检查完毕后，可以根据提示返回 On-Premises 环境进行代码调整。

总结

本文首先对 SAP 云平台 ABAP 编程环境做了概要介绍，阐述了 SAP 云平台引入 ABAP 编程环境的动机以及客户从中能够获取的收益。接着从 ABAP 二次开发这个领域里，所有 ABAP 开发人员都关心的 ABAP 语法兼容问题出发，列举了典型的无法在 ABAP 云端编程环境下继续工作的 ABAP 关键字，并且给出了替代方案。