有好幾位朋友在公衆号背景給我留言詢問SAP C/4HANA和S/4HANA內建的方案。
是以這篇文章我會介紹一些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 大家從我截圖高亮的文檔頁碼不難發現，使用這兩種中間件都存在一些配置工作量——雖然對于諸如銷售訂單，客戶主資料，産品主資料這種通用同步場景，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。
在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裡這個斷點就會觸發。 裡介紹的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裡進行建立工作。
核心的邏輯就是使用函數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上：
2. 在銷售訂單的BO上建立一個新的Action triggerOutboundDelivery: 其中代碼中出現的"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擡頭區域：
還是通過這個
視訊檢視運作時的效果。
對于這種同步解決方案有任何意見，歡迎留言。感謝閱讀。
更多閱讀
本文來自雲栖社群合作夥伴“汪子熙”，了解相關資訊可以關注微信公衆号"汪子熙"。