給用過SAP CRM中介軟體的老哥老姐們講講SAP CPI

注销發表於2019-12-11

最近Jerry由於專案需要,又得學習一個新工具:SAP Cloud Platform Integration,簡稱CPI,以前又叫做HCI - HANA Cloud Platform Integration Service.

clipboard1,1

儘管距離Jerry開始接觸CPI還不到48小時,我仍然想把我剛使用這個工具的第一手體會分享給曾經用過SAP CRM中介軟體,但尚未有機會接觸到CPI的朋友們。

之所以文章標題裡把SAP CRM中介軟體和SAP CPI關聯在一起,是因為二者同廣義上說,扮演的都是系統整合裡中介軟體的角色。

SAP ERP和CRM透過qRFC進行業務資料同步,而中介軟體能夠提供佇列機制,錯誤處理,重試,傳輸監控等功能。關於Jerry在SAP CRM中介軟體上的工作經驗分享,請參考我的文章 Jerry的CRM Middleware(中介軟體)文章合集。

clipboard2,2

而SAP CPI顧名思義,則是雲時代下SAP推薦的SAP產品同第三方雲產品進行整合的雲端中介軟體解決方案。Jerry的S4CRM同事童丹之前文章 S/4HANA Service Management和SAP Field Service Management的整合 裡提到的場景就是SAP CPI的一個典型整合應用。

clipboard3,3

作為學習筆記,Jerry這裡把我學習SAP CPI時做的一個Hello World級別的練習步驟記錄下來。

這個練習的場景是,假設有一個部署在第三方雲平臺上的OData服務,提供了產品主資料查詢的功能。我們需要在SAP系統裡消費這個OData服務。SAP開發人員不希望直接去消費第三方雲平臺上的OData服務,而是期望SAP CPI能暴露一個更加容易訪問的API endpoint出來,例如透過postman傳一個Product ID給CPI,CPI拿到這個ID後,由CPI向第三方雲平臺發起OData請求,拿到請求響應後,CPI把結果返回給位於SAP產品的消費端。

clipboard4,4

用於這個場景的OData服務地址:https://espmrefapps.hana.onde...$metadata

clipboard5,5

SAP CPI是一個SaaS應用,在SAP雲平臺控制檯的Subscriptions皮膚裡訂閱和訪問。點選Go to Applications進入主操作頁面。

clipboard6,6

我們為了實現這個整合場景需要在CPI裡開發一個整合流 - integration flow(下文簡寫為iFlow), 用於定義當其收到消費者傳入的product ID後,應該進行何種處理。

和ABAP裡的程式需要儲存在一個開發包裡一樣,iFlow也需要儲存在一個包裡,稱為Content package.

進入CPI後在此處建立一個Content package:

clipboard7,7
clipboard8,8

然後點選上圖的Artifacts進入iFlow建立介面:

clipboard9,9

取名Jerry first integration flow, 再點選就能進入iFlow的圖形化編輯介面了。

clipboard10,10

一個新的iFlow建立之後的預設介面如下:

clipboard11,11

點選上圖最左邊的Sender圖示,將其拖拽到上圖中間integration process矩形框內的Start圖示內,這個動作會幫助我們建立一個inbound adapter,型別我們選擇HTTPS,意思是這個iFlow期望其被消費的方式是HTTPS.

clipboard12,12

在Adapter的Address裡維護一個url片段/CloudIntegrationTrials, 等到最後該iFlow正式部署後,生成的endpoint就是以該片段結尾,屆時我們可以在postman等工具裡使用該endpoint消費這個iFlow.

clipboard13,13

考慮到現在流行的Restful API實現都期望其消費者以JSON格式傳輸請求內容,我們也沿用這個最佳實踐,因此首先拖拽一個JSON to XML Converter到iFlow integration process建模區域的矩形框裡,將JSON
格式的使用者輸入轉換成XML格式:

clipboard14,14

然後再使用Content Modifier,將XML格式裡的product ID的值提取出來。

clipboard15,15

下圖展示了Content Modifier透過XPath將XML格式的輸入裡的productIdentifier這個欄位的值提取出來。

clipboard16,16

有了product ID,可以進行OData呼叫了。從iFlow建模的工具箱裡拖拽一個External Call出來:

clipboard17,17

型別選擇成OData V2:

clipboard18,18

指定前面提過的OData服務的url:

clipboard19,19

選擇該OData服務的Products節點作為消費的物件:

clipboard20,20

將OData Product節點的ProductId欄位繫結到前一步驟透過Content Modifier解析出來的包含了使用者輸入的productIdentifier欄位。

clipboard21,21

就像小朋友們搭積木一樣,我們把iFlow工具箱裡提供的元素,透過拖拽的方式組合成了一個圖形化的流程。點選Deploy進行部署:

clipboard22,22

部署成功之後,抄下這個生成的endpoint:

clipboard23,23

在Postman裡向這個endpoint傳送一個GET請求:

clipboard24,24

部署在SAP Cloud Platform上的CPI iFlow接收到了請求後,就會按照我們維護好的邏輯,解析出Product ID,呼叫OData服務,將該ID對應的Product明細資料作為結果返回給消費端。

clipboard25,25

和SAP CRM中介軟體有各種透過事務碼比如SMW01訪問的監控應用一樣,SAP CPI也有類似的監控程式:

clipboard26,26
clipboard27,27

希望這個最簡單的例子能讓還沒有接觸過SAP CPI的朋友對其作用有個最直觀的瞭解,感謝閱讀。

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

相關文章