距2017年秋季的SAP TechEd大会上一位大佬Björn Goerke，SAP’s Chief Technology Officer宣布了SAP Cloud Platform即将支持ABAP至今，已经过去了两年的时间。
目前国内的技术媒体平台上，已经有了部分概要性介绍SAP Cloud Platform ABAP编程环境的中文文章，但涉及到具体操作细节的文章比较少。
Jerry最近会做一系列关于如何在SAP Cloud Platform上的ABAP编程环境上做开发的分享。
其实对于一个已经能够熟练使用ABAP Development Tools连接On-Premises ABAP Netweaver服务器做开发的传统开发人员而言，迁移到从On-Premises迁移到SAP云平台上的难度不大，只是需要注意一些开发理念上的转变，这个转变我们在后续具体做开发时会提到。
这种相对平缓的迁移和学习曲线，对于SAP全球庞大生态圈的企业和开发人员来说，无疑是一个好消息——这意味着SAP正在进行中的向云端数字化转型的旅程里，这些企业和个人也能够加入其中，并且他们以前在On-Premises时代积累的宝贵的技术和业务领域知识，能够继续在云时代发光发热。
我曾经在网络上了解到，很多自学SAP ABAP的朋友们，面临的第一道关卡就是在自己本地搭一台Netweaver服务器出来。作为一个写了12年代码的老开发人员，Jerry也搭过各种本地开发环境，深知这里面的水有多深。我以前的老板，也给我们分享过他当年来SAP成都研究院面试的时候，自己本地也搭过Netweaver，并且短短几天啃完几百页的Netweaver英文文档的经历。
相信每一位在本地搭建Netweaver的ABAP学习者，当成功看到Hello World输出的那一刻，成就感一定爆棚。
然而，当Jerry第一次在SAP Cloud Platform的ABAP编程环境上看到Hello World时，却没有多少成就感，因为直接按照ABAP Development Tool里的项目创建向导一步步操作就可以了，过程比较简单易懂——这也体现了云时代到来后，对传统应用开发人员工作方式的影响：无需费神去关心底层硬件或者操作系统等资源，可以把精力集中于应用程序逻辑的编写上。换言之，SAP负责管理和维护底层HANA数据库和中层的ABAP runtime，用户只需管理顶层的ABAP应用代码。
使用ABAP Development Tools的项目创建向导：
New->ABAP Cloud Project:
Service Instance Connection，选择SAP Cloud Platform CloudFoundry environment：
选择Region，输入用户名密码，前提是你得在这个region下有一个global Account。
下图是我在SAP Cloud Platform的CloudFoundry环境里的Global Account：
这个Global Account所属的space下面我创建了一个ABAP系统实例，ID为ME1：
这个ABAP运行实例具有16GB运行内存，64GB的HANA内存。
再回到ABAP Development Tools, 在项目创建向导里使用Cockpit里维护的上述属性：
点Next，在ABAP Development Tools里会看到一个嵌入的登录窗口。因为Jerry使用的是SAP社区Mentor的账号，所以登录窗口显示的标题是：Welcome to Mentors!
在向导里点Finish按钮：
点击之后，在ABAP Development Tools左侧的项目列表里就能看见创建好的ABAP Cloud项目了，接下来在这个项目里编写ABAP代码进行开发的方式，和我们用ADT连接On-Premises系统基本一致。大家可以看到下图创建好的高亮的ABAP Cloud项目(系统ID为ME1), 和其他On-Premises上的ABAP项目外观上没有区别。
这两种ABAP项目的差异在于，ABAP Cloud项目里能够使用的ABAP语言特性，只是传统ABAP语言的一个子集，比如传统ABAP语言里和Dynpro相关的关键字，即只能工作在SAPGUI中的那些关键字，因为在Cloud环境下不再适用了，所以在ABAP Development Tools的ABAP Cloud项目里禁止使用。
现在就可以进行第一行ABAP程序的编写了。
和On-Premises环境下一样，首先创建一个本地包ZJERRY(local package):
然后弹出提示要求创建Transport Request(传输请求)：
Package和Transport Request都有了之后，就可以开始编码了。
在On-Premises时代，我们想用ABAP打印Hello World，直接SE38创建一个报表(Program，如下图所示)，然后WRITE: 'Hello World’就可以了。
在SAP Cloud Platform上，新建列表的选项里已经没有了ABAP Program这一项。
所以我们只能选择新建一个ABAP Class：
指定把这个类存储到刚刚新建的Transport Request里：
接下来的操作，好比在Java class的static public void main(String[] args)方法里用System.out.println打印Hello World一样。
这个新建的ABAP类实现IF_OO_ADT_CLASSRUN接口, 进行Hello World的打印：
激活代码，可以看到和On-Premises一样，这个类的各个组成部分需要一起激活。
至于为什么Jerry在IDE里书写了一段纯文本的ABAP源码，但是激活时任务列表里产生了这么多对象，请参考Jerry的博客：General properties of ABAP Classes / Interfaces
https://blogs.sap.com/2014/03/14/general-properties-of-abap-classes-interfaces/
激活完毕后，Run As->ABAP Application(console):
Console里看到输出：
观察这个类执行的交互日志，发现我们在ABAP Development Tools里触发的执行动作，IDE发送了一个SAP Cloud Platform上endpoint为/sap/bc/adt/oo/classrun的POST请求。
这段程序在SAP云平台的ABAP实例上执行，结果再以HTTP响应的方式返回给IDE。
IDE发送请求给SAP Cloud Platform的具体Java代码，可以按照Jerry的文章：那些年我用过的SAP IDE 里介绍的方法去反编译后查看。
在SAP云平台上的ABAP编程，和传统On-Premises系统编程相比，一个显著的差异就是，出于保持简单，降低操作风险的准则，以及在提供操作的灵活性和云平台安全性等方面的折衷考虑，开发人员在SAP Cloud Platform的ABAP编程环境无法像后者一样能够任意访问Netweaver上的资源。
以传统ABAP开发人员在Netweaver上进行二次开发最常用的ABAP OPEN SQL读表的操作为例，这种直接访问数据库表的行为在SAP Cloud Platform上会引起语法错误。
即使像下图这样在ABAP代码里直接引用Netweaver的数据库表，在SAP云平台上也是不允许的。
所有对底层资源的访问都必须通过SAP定义的白名单里的API进行，即下图Released Objects里包含的API。
后续Jerry将带来SAP云平台ABAP编程环境更多开发内容的分析，敬请期待。
