在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上：

https://github.com/i042416/CloundFoundry_Connectivity

上圖各模塊間交互的簡單闡述：

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</a>

點擊以後，會跳轉到/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，發現是http://my-backend:80/sap/opu/odata/sap/EPM_REF_APPS_SHOP_SRV/$metadata。

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

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