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 关键字，并且给出了替代方案。

标签：Premises,代码,环境,语法,关键字,ABAP,SAP,Cloud
来源： https://www.cnblogs.com/sap-jerry/p/16350192.html