在SAP雲平臺ABAP編程環境上編寫第一段ABAP程序

距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編程環境更多開發內容的分析，敬請期待。

要獲取更多Jerry的原創文章，請關注公衆號"汪子熙":