SAP云平臺和第三方CRM解決方案(火鍋)互聯
光看封面配圖，這篇文章很容易被誤認為在講成都的美食之一：火鍋。
SAP成都研究院坐落在被聯合國教科文組織授予過“美食之都”稱號的成都，所在的天府軟件園，半徑1公里左右星羅棋布著很多聞名的火鍋美食店。
那么火鍋和本文主題，SAP云平臺同第三方CRM解決方案互聯有何關聯？
HubSpot是一個微型的CRM解決方案，麻雀雖小，五臟俱全。大家可以使用郵箱免費注冊然后體驗。
從登錄進去后的主頁菜單能看出，一個CRM系統(tǒng)的三大核心模塊Sales，Service和Marketing，HubSpot都具備。
而Jerry寫這篇文章時，不斷地把HubSpot敲成HotPot，罪過罪過。。。
[外鏈圖片轉存失敗,源站可能有防盜鏈機制,建議將圖片保存下來直接上傳(img-VXUEpfVA-1576510387022)(https://user-images.githubusercontent.com/5669954/70860924-59ad3100-1f62-11ea-92f5-470c71c12982.png)]
之前Jerry陸陸續(xù)續(xù)介紹過一些SAP系統(tǒng)同第三方解決方案集成的技術：
一些SAP Partners能夠通過二次開發(fā)實現打通C/4HANA和S/4HANA的方法介紹：通過C4C的Event Notification功能，每當C4C的銷售訂單創(chuàng)建時，都會通過事件通知機制，調用S/4HANA注冊的事件處理函數，把這個訂單同步到S/4HANA去。
WordPress，SAP Kyma和微信三者的集成
從ABAP Netweaver的SICF到SAP Kyma的Lambda Function
周伯通的空明拳，米諾斯的星塵傀儡線，SAP Kyma的Serverless
還在用ABAP進行SAP產品的二次開發(fā)？來了解下這種全新的二次開發(fā)理念吧
以上四篇文章均圍繞如何使用Kyma Lambda Function來擴展SAP產品或者客戶的legacy系統(tǒng)來介紹的。
SAP云平臺上的ABAP編程環(huán)境里如何消費第三方服務：這篇文章的標題就已經很好的詮釋了文章內容了。
給用過SAP CRM中間件的老哥老姐們講講SAP CPI：通過SAP Cloud Platform Integration調用第三方OData.
本文介紹另一種集成方式同第三方應用進行集成：SAP API Management Service + SAP Open Connector. 第三方應用選擇的是HubSpot. 我們將開發(fā)一個SAP UI5應用，通過這種新介紹的方式在UI5應用里顯示HubSpot系統(tǒng)里的Company數據。
大家也許會問，這個常規(guī)需求，我直接在UI5應用里編程，直接調用HubSpot的Restful API，不是一樣也能實現么？
SAP官網給出了使用Open Connector能享受到的收益，比如借助SAP在云平臺上預置的連接器，能夠減少集成的開發(fā)時間，降低集成復雜度，提高開發(fā)效率等等。
而SAP云平臺上的API Management Service，對通過Open Connector連接的API提供了企業(yè)級的API操作方式和統(tǒng)一的生命周期管理。
下面是集成的具體步驟。
進入SAP Open Connector首頁，點擊Connectors：
這個列表里就是SAP官網上介紹的pre-built的第三方CRM應用的連接器。
我們從列表里找到火鍋，哦不對，找到HubSpot：
點擊Authenticate, 建立SAP Cloud Platform同HubSpot的安全連接：
[外鏈圖片轉存失敗,源站可能有防盜鏈機制,建議將圖片保存下來直接上傳(img-0266ONL4-1576510387025)(https://user-images.githubusercontent.com/5669954/70860890-5023c900-1f62-11ea-9190-a52020b7104f.png)]
創(chuàng)建一個HubSpot的連接器實例，這里需要填一個API key：
到HubSpot的settings頁面創(chuàng)建一個API key：
實例創(chuàng)建完畢后，就能在SAP云平臺環(huán)境里通過這個實例消費HubSpot的Restful API了。
Open Connector的控制臺里，還有這種叫做Common Resources的模型，有什么用處？
看幫助文檔：“提供了一個預先配置好映射關系的通用數據接口，能夠將通過Connector連接的不同CRM服務的數據通過簡化的模型返回”。
看具體的例子。我在HubSpot里創(chuàng)建了兩個Companies:
如果直接消費HubSpot的API，請求的url如下：
https://api.hubapi.com/companies/v2/companies/paged?hapikey=&properties=name&properties=website
盡管我們通過url參數只請求了name和website兩個字段，從響應數據結構中可以發(fā)現，HubSpot除了返回這兩個字段的值以外，還包含了一些控制字段信息，比如timestamp, source, sourceId等字段，而我們對這些字段不感興趣。
現在就是Common Resources派上用場的時候了：
這個Common Resources起的作用好比ABAP里的simple transformation，可以根據預定義好的mapping規(guī)則，對HubSpot API返回的數據進行一些“變形”，移除一些我們應用不關心的字段。
點擊Send按鈕，從Transformed Response里觀察到通過Common Resources處理后的數據：
現在這個數據看起來是不是清爽多了？這也就是我們UI5應用期望消費的數據。
如果對標準的Common Resources預置的映射處理規(guī)則不滿意，還可以把標準的Resource克隆出來，然后在上面做修改。下圖是我自己修改過的兩個Resources模型。
Connectors至此就開發(fā)完畢了，實際上我們連一行代碼都沒寫，準確地說是配置完畢了，這也證實了SAP官網提到的Open Connector給集成開發(fā)人員帶來的便利。
有了Connectors，但我們還沒有生成可供SAP UI5應用消費的endpoint，這部分工作交由API Management Service完成。
登錄API portal，將這個API tenant同之前創(chuàng)建的Open Connector連接起來，這個連接取名叫jerry_openconnector_provider:
需要填的Organization Secret和User Secret在Open Connector控制臺里獲得：
回到API界面，創(chuàng)建一個新的API provider：
從下拉菜單里選擇剛才創(chuàng)建的jerry_openconnector_provider,
點擊Discover按鈕：
就能自動檢測出之前創(chuàng)建的Open Connector實例了。
點擊Deploy進行部署：
Deploy之后，可以在API portal里根據swagger風格的操作方式來瀏覽通過Open Connector連接的HubSpot API了：
現在我們已經有了一個可用的API endpoint，通過它，我們的
SAP UI5應用就可以訪問HubSpot的Restful API了：
在瀏覽器里測試，確保通過這個url能夠返回我們期望的數據：
最后一步，就是常規(guī)操作了，新建一個SAP UI5應用，在里面通過JSON Model訪問之前API provider暴露出來的url:
為了解決跨域問題，上面第12行使用了指向API provider的相對路徑，通過neo-app.json里聲明的Destination指向實際的完整路徑：
在SAP Cloud Platform上創(chuàng)建這個名為api_portal的Destination：
一切就緒后，打開UI5應用，就能看到通過API provider，經由Open Connector從HubSpot取回來的數據了。
這種通過Open Connector和API Management Service同第三方應用進行集成的方式，同Jerry文章開頭回顧的幾種方式，并無孰優(yōu)孰劣之說。在實際的工作中，我們需要根據自己企業(yè)的實際情況，比如現有系統(tǒng)架構，開發(fā)部門的技術水平，項目預算等，靈活選擇適合自己企業(yè)的集成方案。如果非要尋找一些通用的最佳實踐，可以參考SAP CTO在各大會議上介紹的SAP云端編程模型(Cloud Application Programming Model)技術選型的決策樹，來制定適合自己企業(yè)集成方案選型的決策樹。
[外鏈圖片轉存失敗,源站可能有防盜鏈機制,建議將圖片保存下來直接上傳(img-eoc6qG7J-1576510387044)(https://user-images.githubusercontent.com/5669954/70860920-59149a80-1f62-11ea-96b3-facba06517b6.png)]
感謝閱讀。