1. 程式人生 > >一些SAP Partners能夠通過二次開發實現打通C/4HANA和S/4HANA的方法介紹

一些SAP Partners能夠通過二次開發實現打通C/4HANA和S/4HANA的方法介紹

有好幾位朋友在公眾號後臺給我留言詢問SAP C/4HANA和S/4HANA整合的方案。

儘管我給這些朋友推送了一個方案:打通C/4HANA和S/4HANA的一個原型開發:智慧服務創新案例,然而我得到的反饋是:在這個創新案例裡,需要在C/4HANA裡的服務雲做一些後臺開發,即下圖紅色方框標註的C4C API endpoint。因為是雲產品,這種後臺開發只有SAP能做,並沒有對Partners開放。

因此這篇文章我會介紹一些Partners能夠進行的二次開發方式,通過這些方式也能實現C/4HANA和S/4HANA的簡單整合場景。

需要強調的是,本文的重點是思路的介紹,羅列出的程式碼僅適用於原型開發場景中,離真正用於生產環境的要求還有很大距離,比如缺少錯誤處理,缺少足夠多的場景覆蓋等等。這些需要Partners在真正做二次開發時自己去彌補。

我使用一個簡單的場景來介紹一種輕量級的整合方式:將C/4HANA中銷售雲的銷售訂單(Sales Order)同步到S/4HANA中。因為在S/4HANA裡,基於銷售訂單可以生成後續的生產訂單,那麼一旦實現這個整合場景,理論上我就可以用手機訪問C/4HANA的銷售雲,在手機上觸發S/4HANA的生產製造流程。

SAP C/4HANA銷售雲裡的C4C Cloud for Sales部分,如果需要同SAP其他On-Premises產品比如SAP ERP, SAP CRM等整合,SAP官方推薦的同步方式是採用SAP HANA Cloud Integration和SAP Netweaver PI作為中介軟體。

這兩種推薦的方式都非常成熟並且在眾多的實際專案實施過程中得到了驗證。Jerry也簡單瀏覽過這兩種方式的官方配置文件。

這個連結是PI的配置文件:

https://support.sap.com/content/dam/SAAP/Sol_Pack/Library/TestScripts/NC8_CFCALL_HowTo_Guide_EN_XX.pdf

這個連結是HCI的配置文件:

https://support.sap.com/content/dam/SAAP/Sol_Pack/Library/TestScripts/NC7_CFCALL_HowTo_Guide_EN_XX.pdf

大家從我截圖高亮的文件頁碼不難發現,使用這兩種中介軟體都存在一些配置工作量——雖然對於諸如銷售訂單,客戶主資料,產品主資料這種通用同步場景,SAP已經提供了開箱即用的解決方案,但仍需專業顧問在中介軟體上完成配置才能讓同步流程正常工作。對於這種方式的思路,Jerry的個人理解就是,配置優於編碼

,通過大量的配置來減少甚至避免Partners編碼的工作量。

Jerry將要介紹的另一種整合方式則反其道而行之,編碼優於配置。這種方式的優點就是完全避免了HCI或者PI等中介軟體的引入,因此也壓根不存在配置的工作量了。當然凡事有利就有弊,拋棄了中介軟體之後,意味著C4C Cloud for Sales採用直連的方式同S/4HANA互動,這樣C4C建立的銷售訂單傳送到S/4HANA之後,Partners需要在S/4HANA使用對應的API自行建立銷售訂單。

來看具體的步驟。

SAP C4C有個功能叫做OData Notification, 在標準的Business Object資料發生狀態變化(建立,更新,刪除)時,可以通過OData的方式將這些事件推送到事件監聽者去,這實際是一個簡單的觀察者-釋出者設計模式。

1. 既然這個功能基於OData,我們首先要建立一個OData服務,在這個OData服務裡定義C4C銷售訂單的哪些欄位需要推送到S/4HANA去。

關於SAP產品裡各種OData技術的使用,請參考Jerry的文章:SAP OData程式設計指南

SAP C4C的OData服務的建立可以直接在瀏覽器裡完成:

因為所要做的就是簡單的建模工作,把想要暴露的欄位從左邊的Business Object列表裡選中,移動到右邊即可。

我建立的OData服務名叫zjerrysalesorder

下面的UI就是事件釋出者和監聽者關鍵維護介面,裡面的設定含義是:一旦CUSTOMER_QUOTE(C4C銷售訂單基於的BO)發生了建立或者更新,則新建或者更新的銷售訂單資料會通過前一步建立的OData服務zjerrysalesorder推送到註冊的事件監聽者,即S/4HANA的一個API /sap/bc/dis_c4c上去。

2. 在S/4HANA事務碼SICF裡按照路徑/sap/bc/dis_c4c實現這個事件監聽者,這個路徑需要和第一步在C4C系統裡註冊的url一致。

在ABAP Netweaver事務碼SICF裡開發的這些類從原理上可以類比成Java裡的Servlet,在Jerry的部落格裡有詳細介紹:

ABAP ICF handler and Java Servlet

https://blogs.sap.com/2017/05/07/abap-icf-handler-and-java-servlet/

在服務dis_c4c對應的ABAP處理類裡設定一個斷點,在C4C裡新建一個銷售訂單,然後S/4HANA裡這個斷點就會觸發。

當然這裡涉及到一個內外網穿越的問題:執行在Internet網路下的C4C如何能夠和位於企業內網環境下的S/4HANA互動呢?

可以採用Jerry之前的文章 使用Java+SAP雲平臺+SAP Cloud Connector呼叫ABAP On-Premise系統裡的函式 裡介紹的SAP雲平臺加上Cloud Connector的解決方案實現內外網訪問,或者直接將S/4HANA這個url /sap/bc/dis_c4c做一個內外網地址對映後,暴露給外網直接訪問。當然後者不推薦,用來做原型開發和概念驗證沒問題,如果是正式使用,那還是用SAP雲平臺那套標準解決方案吧。

我們在斷點裡可以觀察C4C推送到S/4HANA的資料格式。

從偵錯程式裡可以看到,S/4HANA接收到的是一個JSON格式的字串,包含了觸發事件的BO名稱,發生狀態變化的BO例項的GUID,觸發的事件型別以及一個OData服務的url。這個OData服務正是我在第一步建立的zjerrysalesorder。

S/4HANA通過消費這個OData服務,就能獲取在C4C建立的銷售訂單通過OData服務暴露出來的資料,下邊這個例子發生的事件是create,通過消費紅色高亮的OData服務url,我們就能在S/4HANA裡獲得C4C新建的銷售訂單的明細,再呼叫操作銷售訂單的API在S/4HANA裡進行建立工作。

S/4HANA端完整的ABAP實現程式碼已經放到我的github上了:

https://github.com/i042416/KnowlegeRepository/tree/master/ABAP/C4_S4_replicate

核心的邏輯就是使用函式SD_SALESDOCUMENT_CREATE進行建立,這個S/4HANA函式的介面雖然和SAP CRM的CRM_ORDER_MAINTAIN有差異,但設計思路都類似,訂單的資料散落在諸如Header,Item,Party,Text等節點上,直接填充某節點對應的輸入結構即可完成相應資料的建立。

將C4C建立好的銷售訂單同步到S/4HANA的實際效果,可以參考這個騰訊視訊

這種通過觀察者-釋出者模式進行C/4HANA和S/4HANA資料同步的方式,依賴於C4C裡BO狀態的三種變化:建立,修改和刪除,顯得不夠靈活。從上面的開發我們能看出,Partners的二次開發工作量主要集中在S/4HANA,C/4HANA端沒有任何編碼工作,僅僅完成了一個OData服務的建模和事件註冊。當事件發生後,從C/4HANA端向S/4HANA發起的事件推送是由C4C系統層面的元件來完成的。

那麼Partner有沒有辦法在C/4HANA裡,通過C4C端的二次開發編碼,直接消費S/4HANA的服務呢?

當然有。假設這樣一個場景:C/4HANA的銷售訂單同步到S/4HANA後,在S/4HANA完成必要的生產流程後,可以進行後續的交貨流程。現在的需求就是:直接在C4C銷售訂單的UI上觸發S/4HANA外向交貨單(Outbound Delivery)的建立,這樣業務人員不需要登入S/4HANA系統,而只需在手機上使用C4C應用,就能完成S/4HANA交貨流程的觸發了。

這個需求Partners完全可以通過二次開發來實現。

思路是:在S/4HANA把外向交貨單建立函式BAPI_OUTB_DELIVERY_CREATE_SLS包裝成一個Restful API,然後在C4C Cloud Application Studio裡進行二次開發,使用ABSL(ABAP Scripting Language)來消費API。

1. 在S/4HANA裡按部就班的完成上述Restful API的建立與實現。詳細實現程式碼還是放在Jerry的github上:

https://github.com/i042416/KnowlegeRepository/tree/master/ABAP/C4_S4_replicate

2. 在銷售訂單的BO上建立一個新的Action triggerOutboundDelivery:

繫結到UI這個叫做Trigger Delivery的按鈕上。同時在銷售訂單擡頭區域新建一個欄位,用於存放S/4HANA建立好的交貨單ID。

最後完成這個按鈕點選後的編碼實現工作,呼叫WebServiceUtilties.ExecuteRESTService去消費S/4HANA的Restful API。

這段ABSL的完整程式碼:

https://github.com/i042416/KnowlegeRepository/blob/master/ABAP/C4_S4_replicate/triggerOutboundDelivery.absl

其中程式碼中出現的"JerryExternal", "JerryExternalService"這些,均是和Restful API的消費有關的模型的名稱。

Jerry的另一位同事宋浩曾經寫過一篇文章:SAP S4CRM 1811 服務訂單API介紹,裡面提到了S4CRM基於Netweaver技術架構的Service Integration場景裡必需的三大模型:

  • Communication Arrangment

  • Communication System

  • Communication Scenario

因為C4C後臺也基於Netweaver,所以為了消費S/4HANA的Restful API,我們同樣需要在C4C裡建立這三大模型。

簡單地說,Communication System負責維護Service Provider所在的系統,在我們這個例子裡是S/4HANA系統:

Communication Scenario負責維護Restful Service endpoint,而Communication Arrangement將兩者關聯起來。

關於這三個模型的詳細建立步驟,請參考Jerry的部落格:

Use Restful Service to consume S4 functionality in SAP Cloud for Customer

https://blogs.sap.com/2018/12/06/use-restful-service-to-consume-s4-functionality-in-sap-cloud-for-customer/

最後實現的效果是:點選按鈕之前,存放S/4HANA生成的交貨單ID的欄位是空的:

點了按鈕在S/4HANA生成交貨單之後,其ID通過S/4HANA Restful API的返回結果儲存在C4C銷售訂單BO的擴充套件欄位上,並顯示在UI擡頭區域:

還是通過這個視訊檢視執行時的效果。

對於這種同步解決方案有任何意見,歡迎留言。感謝閱讀。

更多閱讀

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