我的前一篇文章?使用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文件其實就一行代碼：

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，發現是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的原創技術文章，請關注公眾號"汪子熙"或者掃描下面二維碼:

總結

以上是生活随笔為你收集整理的在SAP云平台的CloudFoundry环境下消费ABAP On-Premise OData服务的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。