Jerry在之前的文章多次提过，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里即是所有可用的数据元素(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二次开发代码，在用Jerry之前文章 使用abapGit在ABAP系统和SAP云平台ABAP环境之间进行代码传输 介绍的办法将这些代码迁移从On-Premises系统迁移到云上之前，您期望做一次统一的“Cloud Readiness”检查，一次性把所有上云的隐患都列出来。
传统的ATC检查(ABAP Test Cockpit, 一种ABAP代码检查工具)此时再次有了用武之地。按照这篇SAP社区博客提到的note去做，在一个ATC中央检查系统上安装包含了新的ATC检查选项的实现note：
How to check your custom ABAP code for SAP Cloud Platform ABAP Environment
https://blogs.sap.com/2018/10...
这个新的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环境进行代码调整。
要获取更多Jerry的原创文章，请关注公众号"汪子熙":