有好幾位朋友在公衆號後臺給我留言詢問SAP C/4HANA和S/4HANA集成的方案。html
儘管我給這些朋友推送了一個方案:打通C/4HANA和S/4HANA的一個原型開發:智能服務創新案例,然而我獲得的反饋是:在這個創新案例裏,須要在C/4HANA裏的服務雲作一些後臺開發,即下圖紅色方框標註的C4C API endpoint。由於是雲產品,這種後臺開發只有SAP能作,並無對Partners開放。java
所以這篇文章我會介紹一些Partners可以進行的二次開發方式,經過這些方式也能實現C/4HANA和S/4HANA的簡單集成場景。git
須要強調的是,本文的重點是思路的介紹,羅列出的代碼僅適用於原型開發場景中,離真正用於生產環境的要求還有很大距離,好比缺乏錯誤處理,缺乏足夠多的場景覆蓋等等。這些須要Partners在真正作二次開發時本身去彌補。github
我使用一個簡單的場景來介紹一種輕量級的集成方式:將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的配置文檔:restful
這個連接是HCI的配置文檔:架構
你們從我截圖高亮的文檔頁碼不難發現,使用這兩種中間件都存在一些配置工做量——雖然對於諸如銷售訂單,客戶主數據,產品主數據這種通用同步場景,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的完整代碼:
其中代碼中出現的"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
最後實現的效果是:點擊按鈕以前,存放S/4HANA生成的交貨單ID的字段是空的:
點了按鈕在S/4HANA生成交貨單以後,其ID經過S/4HANA Restful API的返回結果存儲在C4C銷售訂單BO的擴展字段上,並顯示在UI擡頭區域:
仍是經過這個視頻查看運行時的效果。
對於這種同步解決方案有任何意見,歡迎留言。感謝閱讀。
更多閱讀
要獲取更多Jerry的原創文章,請關注公衆號"汪子熙":