距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的原創文章，請關注公眾號"汪子熙":

相關推薦