在SAP雲平臺的CloudFoundry環境下消費ABAP On-Premise OData服務

我的前一篇文章 使用Java+SAP雲平臺+SAP Cloud Connector呼叫ABAP On-Premise系統裡的函式介紹了在SAP雲平臺的Neo環境下如何透過SAP Cloud Connector消費ABAP On-Premise系統裡的函式。在那篇文章demo程式的Java程式碼裡，我們實際是透過JCO(Java Connector)來遠端呼叫ABAP On-Premise系統裡的函式。

今天我們換個環境，試試SAP雲平臺的CloudFoundry環境。

同時我們也試試換一種方式來消費ABAP On-Premise系統的服務。讓我們開發一個Web應用，透過OData的方式顯示ABAP On-Premise系統裡的產品列表及價格資訊。

該例子執行效果如下圖所示。

同前一篇文章提到的在SAP雲平臺的Neo環境裡消費ABAP On-Premise函式相比，在CloudFoundry環境裡實現同樣的需求，所需的步驟要複雜一些。

同Neo環境的部署相比，在CloudFoundry環境下最顯著的架構區別就是多了個App Router。為什麼CloudFoundry環境下需要這個東西？我的同事李貝南在他的文章 SAP成都研究院李三郎：SCP Application Router簡介 裡做過詳細闡述。

為了完成這個例子，我們需要部署兩個應用到SAP雲平臺的CloudFoundry環境去，即App Router和Web應用本身。兩個例子的完整程式碼在我的github上：

上圖各模組間互動的簡單闡述：

1. App Router作為使用者訪問Web應用的入口。

2. App Router將請求重定向到XSUAA例項，彈出登入介面。該例項負責完成登入認證，稍後會建立它。下圖是登入介面在我手機上開啟的效果。

3. 登入完成後，App Router將請求重定向到Web應用。

4. Web應用向XSUAA發起兩個並行的請求，如圖4a和4b所示，獲取用於訪問接下來第5，第6步的JSON Web Token。

5. Web應用訪問Destination例項獲取對應配置資訊。

6. Web應用將請求傳送給Connectivity例項。

7. Connectivity例項將請求透過Secure tunnel（安全隧道）轉發給Cloud Connector。

8. Cloud Connector和On-Premise系統都位於Corporate Network裡，直接呼叫其服務。

明白了原理，下面跟著Jerry一起做一做吧。

1. 我前一篇文章 使用Java+SAP雲平臺+SAP Cloud Connector呼叫ABAP On-Premise系統裡的函式介紹了Cloud Connector的下載與安裝，因此現在我們可以重用之前安裝好的Cloud Connector。

點選Add Subaccount按鈕，基於CloudFoundry Subaccount建立一個新的配置：

最重要的是維護CloudFoundry Subaccount的ID和使用者名稱(登入郵箱)。

建立一個從Virtual Host到Internal Host的對映關係。Virtual Host的名稱可以隨便維護，我維護的是my-backend, 記住這個名稱，以後會用到。Internal Host我維護的是提供OData服務的On-Premise系統的主機名和埠號。點選Check按鈕，確保Cloud Connector能夠成功連線On-Premise系統，狀態為Reachable。

將On-Premise系統的下列4個ICF服務路徑暴露出來：

• /sap/bc/lrep

• /sap/iwbep

• /sap/opu/odata

• /sap/public

至此Cloud Connector上的配置完成了。

2. 回顧我們之前介紹的模組互動圖，Cloud Connector上的配置無法直接被部署在CloudFoundry上的應用消費。我們還需要在SAP雲平臺上建立三個不同型別的例項。

首先在SAP雲平臺Cockpit裡建立一個新的Destination，URL欄位指向前一步Cloud Connector裡建立的Virtual Host。這個Destination的名稱也得記錄下來，後面會用到。

進入Service Marketplace，建立一個新的XSUAA例項：

這個connectivity-jerry-demo就是稍後我要部署到SAP雲平臺上的Web應用名稱。

建立好的XSUAA例項：

connectivity和destination的例項建立的方式相同，不再贅述。下圖是為了完成本文介紹的場景所需的三個不同型別的例項建立好之後的狀態截圖。

至此SAP雲平臺上的配置也全部完成。

3. 現在開始Web應用的開發。先看App Router的xs-app.json: 入口檔案是index.html, 這個html檔案其實就一行程式碼：

<a href="/app/">Go to App

點選之後，會跳轉到/app/, 而/app/的route配置如下，指向destination "dest-to-app":

而這個destination對應的真實url維護在App Router的manifest.yml檔案中。同樣需要在該yml檔案的services欄位裡維護前一步建立的XSUAA例項：

再看Web應用的manifest.yml檔案：需要將前一步驟依次建立的三種型別的例項名稱分別維護如下圖所示：

接下來我們需要進行Web應用裡UI5部分的開發，指定產品列表的資料來源基於哪一個OData服務。在UI5的controller檔案裡，指定OData模型的路徑為相對路徑data-eu。

針對這個相對路徑data-eu，在neo-app.json裡定義了一個路由，會被重定向到On-Premise系統的標準OData服務EPM_REF_APPS_SHOP_SRV。具體重定向到哪個On-Premise系統是由路由的target欄位決定的。在我這個例子裡是jerry-abap-backend, 它就是我們之前在SAP雲平臺Cockpit裡建立的Destination。

這個Destination的URL欄位指向Cloud Connector的Virtual host，該host又對映到On-Premise系統的主機名和埠號。至此大功告成了，SAP Cloud Connector上的配置，App Router，Web應用，SAP雲平臺上的connectivity，XSUAA和destination三個例項，這一系列模型猶如一臺機器上的一個個零件，協同工作，實現了從Internet Network到Corporate Network的訪問場景。

將兩個應用部署到SAP雲平臺的CloudFoundry環境去，點選App Router作為訪問的入口，能看到文章開頭的產品列表頁面。

並且Chrome開發者工具裡觀察到的網路請求的路徑裡僅僅包含前文提到的UI5應用的neo-app.json裡配置的路由data-eu, 而On-Premise系統的主機名和埠號並未暴露到Cloud環境中。

當然，為了跑這個demo，您需要在On-Premise系統使用事務碼/iwfnd/maint_service，為EPM_REF_APPS_SHOP_SRV這個標準的OData服務指定一個後臺系統。在我下圖的例子裡，該服務的後臺實現系統我指定成了AG3。

在Java程式碼裡列印實際的url，發現是。

該url裡的my-backend:80會被Cloud Connector替換成實際的On-Premise系統的地址併傳送到On-Premise系統去。

要獲取更多Jerry的原創技術文章，請關注公眾號"汪子熙"或者掃描下面二維碼: