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即可。话说这种错误应该只会出现在古旧的历史遗留代码上吧(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等等。
但是到了云上，大家还是老老实实使用白名单里维护的那些类型吧。
