SAP雲平臺和第三方CRM解決方案(火鍋)互聯

光看封面配圖，這篇文章很容易被誤認為在講成都的美食之一：火鍋。

SAP成都研究院坐落在被聯合國教科文組織授予過“美食之都”稱號的成都，所在的天府軟體園，半徑1公里左右星羅棋佈著很多聞名的火鍋美食店。

那麼火鍋和本文主題，SAP雲平臺同第三方CRM解決方案互聯有何關聯？

HubSpot是一個微型的CRM解決方案，麻雀雖小，五臟俱全。大家可以使用郵箱免費註冊然後體驗。

從登入進去後的主頁選單能看出，一個CRM系統的三大核心模組Sales，Service和Marketing，HubSpot都具備。

而Jerry寫這篇文章時，不斷地把HubSpot敲成HotPot，罪過罪過。。。

之前Jerry陸陸續續介紹過一些SAP系統同第三方解決方案整合的技術：

一些SAP Partners能夠透過二次開發實現打通C/4HANA和S/4HANA的方法介紹：透過C4C的Event Notification功能，每當C4C的銷售訂單建立時，都會透過事件通知機制，呼叫S/4HANA註冊的事件處理函式，把這個訂單同步到S/4HANA去。

WordPress，SAP Kyma和微信三者的整合
從ABAP Netweaver的SICF到SAP Kyma的Lambda Function
周伯通的空明拳，米諾斯的星塵傀儡線，SAP Kyma的Serverless
還在用ABAP進行SAP產品的二次開發？來了解下這種全新的二次開發理念吧
以上四篇文章均圍繞如何使用Kyma Lambda Function來擴充套件SAP產品或者客戶的legacy系統來介紹的。

SAP雲平臺上的ABAP程式設計環境裡如何消費第三方服務：這篇文章的標題就已經很好的詮釋了文章內容了。

給用過SAP CRM中介軟體的老哥老姐們講講SAP CPI：透過SAP Cloud Platform Integration呼叫第三方OData.

本文介紹另一種整合方式同第三方應用進行整合：SAP API Management Service + SAP Open Connector. 第三方應用選擇的是HubSpot. 我們將開發一個SAP UI5應用，透過這種新介紹的方式在UI5應用裡顯示HubSpot系統裡的Company資料。

大家也許會問，這個常規需求，我直接在UI5應用裡程式設計，直接呼叫HubSpot的Restful API，不是一樣也能實現麼？

SAP官網給出了使用Open Connector能享受到的收益，比如藉助SAP在雲平臺上預置的聯結器，能夠減少整合的開發時間，降低整合複雜度，提高開發效率等等。

而SAP雲平臺上的API Management Service，對透過Open Connector連線的API提供了企業級的API操作方式和統一的生命週期管理。

下面是整合的具體步驟。

進入SAP Open Connector首頁，點選Connectors：

這個列表裡就是SAP官網上介紹的pre-built的第三方CRM應用的聯結器。

我們從列表裡找到火鍋，哦不對，找到HubSpot：

點選Authenticate, 建立SAP Cloud Platform同HubSpot的安全連線：

建立一個HubSpot的聯結器例項，這裡需要填一個API key：

到HubSpot的settings頁面建立一個API key：

例項建立完畢後，就能在SAP雲平臺環境裡透過這個例項消費HubSpot的Restful API了。

Open Connector的控制檯裡，還有這種叫做Common Resources的模型，有什麼用處？

看幫助文件："提供了一個預先配置好對映關係的通用資料介面，能夠將透過Connector連線的不同CRM服務的資料透過簡化的模型返回"。

看具體的例子。我在HubSpot裡建立了兩個Companies:

如果直接消費HubSpot的API，請求的url如下：
<your API key>&properties=name&properties=website

儘管我們透過url引數只請求了name和website兩個欄位，從響應資料結構中可以發現，HubSpot除了返回這兩個欄位的值以外，還包含了一些控制欄位資訊，比如timestamp, source, sourceId等欄位，而我們對這些欄位不感興趣。

現在就是Common Resources派上用場的時候了：

這個Common Resources起的作用好比ABAP裡的simple transformation，可以根據預定義好的mapping規則，對HubSpot API返回的資料進行一些“變形”，移除一些我們應用不關心的欄位。

點選Send按鈕，從Transformed Response裡觀察到透過Common Resources處理後的資料：

現在這個資料看起來是不是清爽多了？這也就是我們UI5應用期望消費的資料。

如果對標準的Common Resources預置的對映處理規則不滿意，還可以把標準的Resource克隆出來，然後在上面做修改。下圖是我自己修改過的兩個Resources模型。

Connectors至此就開發完畢了，實際上我們連一行程式碼都沒寫，準確地說是配置完畢了，這也證實了SAP官網提到的Open Connector給整合開發人員帶來的便利。

有了Connectors，但我們還沒有生成可供SAP UI5應用消費的endpoint，這部分工作交由API Management Service完成。

登入API portal，將這個API tenant同之前建立的Open Connector連線起來，這個連線取名叫jerry_openconnector_provider:

需要填的Organization Secret和User Secret在Open Connector控制檯裡獲得：

回到API介面，建立一個新的API provider：

從下拉選單裡選擇剛才建立的jerry_openconnector_provider,

點選Discover按鈕：

就能自動檢測出之前建立的Open Connector例項了。

點選Deploy進行部署：

Deploy之後，可以在API portal里根據swagger風格的操作方式來瀏覽透過Open Connector連線的HubSpot API了：

現在我們已經有了一個可用的API endpoint，透過它，我們的
SAP UI5應用就可以訪問HubSpot的Restful API了：

在瀏覽器裡測試，確保透過這個url能夠返回我們期望的資料：

最後一步，就是常規操作了，新建一個SAP UI5應用，在裡面透過JSON Model訪問之前API provider暴露出來的url:

為了解決跨域問題，上面第12行使用了指向API provider的相對路徑，透過neo-app.json裡宣告的Destination指向實際的完整路徑：

在SAP Cloud Platform上建立這個名為api_portal的Destination：

一切就緒後，開啟UI5應用，就能看到透過API provider，經由Open Connector從HubSpot取回來的資料了。

這種透過Open Connector和API Management Service同第三方應用進行整合的方式，同Jerry文章開頭回顧的幾種方式，並無孰優孰劣之說。在實際的工作中，我們需要根據自己企業的實際情況，比如現有系統架構，開發部門的技術水平，專案預算等，靈活選擇適合自己企業的整合方案。如果非要尋找一些通用的最佳實踐，可以參考SAP CTO在各大會議上介紹的SAP雲端程式設計模型(Cloud Application Programming Model)技術選型的決策樹，來制定適合自己企業整合方案選型的決策樹。

感謝閱讀。

要獲取更多Jerry的原創文章，請關注公眾號"汪子熙":