在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文件其實就一行代碼：
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系統去。
TAG:汪子熙 |