本文作者是我的同事，Song Hao(宋浩），SAP成都研究院S/4HANA Service Management的開發人員。

項目背景

相信大家已經知道，2018年6月份，SAP收購了一家專注于Field Service Management的公司Coresystem。我們SAP自己的S/4CRM也有現場服務管理，所以我們為客戶都提供了兩個系統之間的集成解決方案，同時包含Cloud和On-Premise版本，完成業務流程與數據的同步。

業務場景

在介紹業務場景之前，我覺得有必要簡單的描述下在場景中的各種術語以及業務模型，在S/4HANA Service端我們有Service Order(服務訂單)以及對應的Service Item（服務項目,這其中包含了Service Product服務產品Expense費用Spare Parts備件等），在Field Service Management端我們有Service Call(服務請求)Activity（服務活動）以及從屬于Activity的Expense, Time effort, Reserved Material等。由此很容易發現我們需要將S/4HANA端的服務訂單改造成如下的Hierarchy結構，備件以及費用是掛在服務產品下的。但是在普通的服務訂單中，我們時常是不采用這種Hierarchy結構。

假設，我們的一個客戶實施了S/4HANA Service Management（以下簡稱S/4HANA）和SAP Field Service Management（以下簡稱FSM）.現在該客戶的呼叫中心接到其客戶的報修電話，需要維修一臺空調，呼叫中心根據實際情況創建服務訂單，在該訂單被release再保存完畢的時候觸發我們的Iflow，通過CPI在Iflow里面我們對S/4HANA端傳送過來的數據根據兩端的業務邏輯和字段含義等進行了進一步的處理和映射，最終發給FSM端，調用FSM提供的API創建Service Call with activities (服務請求以及相應的活動)，創建好Service Call以后調度員會將這個Service Call下的activity分配給對應的技師并進行release assignment操作，到此技師就會在手持設備上接到通知帶上相應的工具備件開開心心地去客戶現場了，好像跟現在的外賣服務有點像？

等到技師在現場的服務完成，他會通過手持設備上報本次服務所產生的實際工時，費用，備件信息等并在現場讓客戶電子簽名確認，在此期間可能還存在中途更換技師，或者添加技師的場景。
接下來在公司接到該技師上報的數據以后，審核人員會對數據進行審核，審核通過就會再次觸發Iflow在S/4HANA端創建Service Confirmation（服務確認）。在Service Confirmation的所有行項目都被確認完成以后,后續就是根據成本對象計算成本和進行對應的開票了。這單成本多少，收益多少一目了然。

以下我以Cloud版本為例來具體說明整個端到端的實現細節。

在該方案中采用了CPI來做集成，我們提供了完整的端到端的集成，并且partner或者客戶可以復制我們提供的這個標準集成方案，進行定制化的修改以此來滿足自身特定的需求。
以下是S/4HANA到FSM端到端的Iflow設計，是否有種workflow的既視感？

下面我將分步介紹Iflow中每一塊的相關功能以及所涉及到的相關配置。

(1) 從S/4HANA端創建服務訂單通過EMS（Enterprise Messaging）向外發送請求調用Iflow在FSM端創建對應的服務呼叫。

在此之前我們需要在SAP Cloud Platform 上進行一些EMS的相關配置。以此來保證S/4HANA—>EMS—>Iflow之間的通信。

這里需要創建一個EMS的Instance并且生成對應的endpoint，然后在該Instance下創建Webhook Subscription并且將Iflow的endpoint配在這里（Webhook URL），這樣EMS就知道去調用哪一個Iflow了。

接下來我們需要在S/4HANA Cloud端做相應的Communication Arrangement配置，將EMS Instance生成的endpoint配在這里，這樣在S/4HANA端生成服務訂單的時候就會通過outbound service找到我們的EMS并且將服務訂單的號碼傳遞給EMS。

上述配置完成以后我們在S/4HANA端創建服務訂單觸發EMS發起Http請求調用Iflow。

(2) 將EMS發送過來的Json轉換成XML，并且調用Odata服務根據服務訂單號碼拿到我們請求的該訂單的信息。

(3) 對Odata服務返回的訂單狀態進行校驗，只有被release的訂單才會被進一步處理。

對拿到的訂單信息使用Groovy腳本進行加工，以便后一部的Data Mapping處理。由于S/4HANA與FSM兩端的數據模型稍微有所不同，在這里我們對原始的通過Odata拿到的payload在結構上進行了改造們這樣會極大方便下一步的mapping。Tips：在Iflow中我們推薦盡量使用標準控件來實現你的需求，如果標準控件不能滿足，可以采用Groovy或者JS來處理。

(4)在調用FSM的API創建服務呼叫之前需要獲取一次FSM的Token，要進門你得有鑰匙對吧。這里我們需要將生成的message body服務訂單的Payload暫存到一個屬性里，因為在整個Iflow的生命周期中只有一個message body可用，如果不將之前的message body暫存，會被后續新生成的message body覆蓋掉，那么你就丟失了你的數據。

準備創建服務呼叫的message header信息，并且將之前暫存在屬性里的服務訂單payload用來替換到message body里。最后將message body由XML轉換成Json。因為FSM端API目前只接收Json。

這里需要對最后的Json格式的payload進行進一步的處理，可能是邏輯處理，也可能是數據結構上的處理，這是要根據具體需求來決定。接下來就是正式調用FSM的API創建服務呼叫。

(5) 在整個Iflow的生命周期中，可能會產生各種Application Error或者System Error。我們需要在Iflow里捕獲他們并且通過適當的方式返回給對應的接收者。在這里我們使用的是發送郵件的方式，需要配置相關的郵件服務器地址，端口，發送者接收者的email地址，發送者的帳戶名密碼也得配置在Iflow里面。

至此整個Iflow的構建完成。

下面我們來實際看下整個E2E的場景，我剛買的運動鞋穿了沒幾天就壞了，給該品牌售后打電話，協商以后他們準備派師傅上門來幫我修鞋子。他們創建了一張服務訂單8000001219.

此時系統會根據之前的配置自動觸發Iflow在FSM端創建服務呼叫。
在CPI提供的Monitor里面我們可以看到Iflow已經成功執行。如果在Iflow的執行中出現了任何的錯誤，那么在這個Monitor里也可以進行查看，從而了解到具體的錯誤信息。

這個時候FSM端的調度員在Dashboard里就能看到剛創建的這個服務呼叫了
并且分配給對應的技師。同時FSM端會觸發一個我們自己設計的Iflow將被分配到的技師信息更新回S/4HANA端對應的服務訂單的服務產品行項目的Parties里。

這個時候技師在手持設備上就可以接到通知，做好準備工作前往客戶現場。

在現場維修服務完成以后，技師會在手持設備上錄入工時，費用，備件等相關信息并且最后讓客戶電子簽字確認。

這個時候公司的相關服務審核人員就會接到技師上報的信息，如果確認無誤可以審批通過。自此整個服務流程完成。

上面只是1908版本中一個具有代表性的場景，我們正在不斷完善整個集成場 景并將在后續版本中持續發布更新，最終打通從C4HANA----->S/4HANA----->FSM的服務場景。

總結

以上是生活随笔為你收集整理的SAP S/4HANA Service Management和SAP FSM基于CPI的集成场景介绍的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。