在本地部署环境即 On-Premises 环境下，如果想将 ABAP Netweaver 里的资源以 Restful API 的方式暴露出来，SICF这个事务码绝对是一大利器。
我们只需要在SICF里合适的路径下创建节点，为该节点创建一个ABAP类，就可以专注于实现接口定义的方法IF_HTTP_EXTENSION~HANDLE_REQUEST, 在里面编写应用逻辑了。应用开发人员无需关注和操心这些ABAP类什么时候被实例化和调用，可以把这个HANDLE_REQUEST方法看作是一个回调函数，当请求到来时，由Netweaver的ICF框架(Internet Communication Framework)负责把请求路由到对应的ICF节点并创建ABAP类，调用HANDLE_REQUEST方法。
每个SICF节点会根据其路径被分配一个url, 如果是Corporate网络里，用浏览器或者编程语言直接访问该url，就能消费SICF暴露的资源了。
如果想让这个位于Corporate网络内的url被Internet网络访问，就得借助SAP Cloud Connector，实现内外网穿透，将内网的资源通过 Cloud Connector 暴露给外网消费。
对于ABAP开发人员来说，一个好消息是，SAP Cloud Platform 如今也支持ABAP运行环境了。本文我们通过在SAP云平台 ABAP运行环境里完成类似之前在On-Premises ABAP系统的SICF事务码里的开发任务，来感受ABAP到了云端之后，给ABAP开发者带来的巨大便利。
通过ABAP Development Tools连接SAP云平台 ABAP运行环境的一个实例，完成登录后，后续的操作步骤，同使用ABAP Development Tools连接一个On-Premises ABAP系统，几乎没有差别。
下图是在云上的ABAP环境里，允许我们创建的ABAP对象列表，既有ABAP开发人员感到亲切的ABAP字段对象，ABAP开发包，ABAP消息类等等，也有上了云端之后的新面孔，比如Cloud Communication Management和Cloud IAM等。
为了完成在On-Premises的SICF事务码里的开发工作，现在我们要在云上的ABAP环境里创建一个新的HTTP Service：
新建一个名为ZHELLOWORLD的service，创建完毕之后界面如下：
ABAP老司机们看到这界面，立即知道下一步怎么做了吧。点击Handler class，就可以进入ABAP类的编辑界面，实现这个HTTP服务的业务逻辑。而通过url字段里维护的值，我们可以在PC或移动设备里，浏览器或代码里访问这个服务。
该服务实现类和On-Premises的区别，不过是接口名称从IF_HTTP_EXTENSION换成了IF_HTTP_SERVICE_EXTENSION.
当然，前者因为是直接在云端编写的ABAP代码，所以还要遵循Jerry之前的文章 在SAP云平台ABAP编程环境上编写第一段ABAP程序 里提到的那些限制。
上述的ABAP代码只是简单地返回给消费者一个Hello World的文本信息，保存激活之后，把url贴到浏览器里，就能看到期望的Hello World：
我们从url里，容易得出这样的结论，SAP Cloud Platform ABAP运行环境里支持创建的HTTP服务，其实现原理，其实就是在Netweaver服务器的SICF路径/sap/bc/http/sap/下面增加一个新的节点罢了，只是这个操作，在云端不再需要由ABAP开发人员手动完成，云端的ABAP环境，会自动创建这一底层设施。
在云端的 ABAP 环境里完成了 Restful 服务的开发之后，如何将这个服务传输到其他系统呢？
SAP ABAP顾问朋友们，应该都使用过SAPLink这个工具。如果两个ABAP Netweaver系统没有建立起传输路径时，我们无法使用标准的SE10事务码创建传输请求的方式进行这两个系统间的代码传输。此时，SAPLink就有了用武之地。
SAPLink简单地说就是一个报表和一系列插件的集合。如果我们期望在系统A和B之间传输代码，步骤为：
(1) 在系统A和B上都安装SAPLink，其实也就是手动创建报表，然后从SAPLink的github上把源代码拷贝过来，激活即可：
https://github.com/sapmentors/SAPlink
(2) 在系统A上执行SAPLink，把想传输的代码导出成一个本地文件。
(3) 在系统B上执行SAPLink，将前一步生成的本地文件导入。
SAPLink的介绍文章，网络上太多了，本文不再赘述。
到了云时代之后，SAP云平台ABAP编程环境的代码版本管理，选择了基于abapGit这个开源项目的GIT来进行。
