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

項(xiàng)目背景

相信大家已經(jīng)知道，2018年6月份，SAP收購(gòu)了一家專注于Field Service Management的公司Coresystem。我們SAP自己的S/4CRM也有現(xiàn)場(chǎng)服務(wù)管理，所以我們?yōu)榭蛻舳继峁┝藘蓚€(gè)系統(tǒng)之間的集成解決方案，同時(shí)包含Cloud和On-Premise版本，完成業(yè)務(wù)流程與數(shù)據(jù)的同步。

業(yè)務(wù)場(chǎng)景

在介紹業(yè)務(wù)場(chǎng)景之前，我覺(jué)得有必要簡(jiǎn)單的描述下在場(chǎng)景中的各種術(shù)語(yǔ)以及業(yè)務(wù)模型，在S/4HANA Service端我們有Service Order(服務(wù)訂單)以及對(duì)應(yīng)的Service Item（服務(wù)項(xiàng)目,這其中包含了Service Product服務(wù)產(chǎn)品Expense費(fèi)用Spare Parts備件等），在Field Service Management端我們有Service Call(服務(wù)請(qǐng)求)Activity（服務(wù)活動(dòng)）以及從屬于Activity的Expense, Time effort, Reserved Material等。由此很容易發(fā)現(xiàn)我們需要將S/4HANA端的服務(wù)訂單改造成如下的Hierarchy結(jié)構(gòu)，備件以及費(fèi)用是掛在服務(wù)產(chǎn)品下的。但是在普通的服務(wù)訂單中，我們時(shí)常是不采用這種Hierarchy結(jié)構(gòu)。

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

等到技師在現(xiàn)場(chǎng)的服務(wù)完成，他會(huì)通過(guò)手持設(shè)備上報(bào)本次服務(wù)所產(chǎn)生的實(shí)際工時(shí)，費(fèi)用，備件信息等并在現(xiàn)場(chǎng)讓客戶電子簽名確認(rèn)，在此期間可能還存在中途更換技師，或者添加技師的場(chǎng)景。
接下來(lái)在公司接到該技師上報(bào)的數(shù)據(jù)以后，審核人員會(huì)對(duì)數(shù)據(jù)進(jìn)行審核，審核通過(guò)就會(huì)再次觸發(fā)Iflow在S/4HANA端創(chuàng)建Service Confirmation（服務(wù)確認(rèn)）。在Service Confirmation的所有行項(xiàng)目都被確認(rèn)完成以后,后續(xù)就是根據(jù)成本對(duì)象計(jì)算成本和進(jìn)行對(duì)應(yīng)的開(kāi)票了。這單成本多少，收益多少一目了然。

以下我以Cloud版本為例來(lái)具體說(shuō)明整個(gè)端到端的實(shí)現(xiàn)細(xì)節(jié)。

在該方案中采用了CPI來(lái)做集成，我們提供了完整的端到端的集成，并且partner或者客戶可以復(fù)制我們提供的這個(gè)標(biāo)準(zhǔn)集成方案，進(jìn)行定制化的修改以此來(lái)滿足自身特定的需求。
以下是S/4HANA到FSM端到端的Iflow設(shè)計(jì)，是否有種workflow的既視感？

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

(1) 從S/4HANA端創(chuàng)建服務(wù)訂單通過(guò)EMS（Enterprise Messaging）向外發(fā)送請(qǐng)求調(diào)用Iflow在FSM端創(chuàng)建對(duì)應(yīng)的服務(wù)呼叫。

在此之前我們需要在SAP Cloud Platform 上進(jìn)行一些EMS的相關(guān)配置。以此來(lái)保證S/4HANA—>EMS—>Iflow之間的通信。

這里需要?jiǎng)?chuàng)建一個(gè)EMS的Instance并且生成對(duì)應(yīng)的endpoint，然后在該Instance下創(chuàng)建Webhook Subscription并且將Iflow的endpoint配在這里（Webhook URL），這樣EMS就知道去調(diào)用哪一個(gè)Iflow了。

接下來(lái)我們需要在S/4HANA Cloud端做相應(yīng)的Communication Arrangement配置，將EMS Instance生成的endpoint配在這里，這樣在S/4HANA端生成服務(wù)訂單的時(shí)候就會(huì)通過(guò)outbound service找到我們的EMS并且將服務(wù)訂單的號(hào)碼傳遞給EMS。

上述配置完成以后我們?cè)赟/4HANA端創(chuàng)建服務(wù)訂單觸發(fā)EMS發(fā)起Http請(qǐng)求調(diào)用Iflow。

(2) 將EMS發(fā)送過(guò)來(lái)的Json轉(zhuǎn)換成XML，并且調(diào)用Odata服務(wù)根據(jù)服務(wù)訂單號(hào)碼拿到我們請(qǐng)求的該訂單的信息。

(3) 對(duì)Odata服務(wù)返回的訂單狀態(tài)進(jìn)行校驗(yàn)，只有被release的訂單才會(huì)被進(jìn)一步處理。

對(duì)拿到的訂單信息使用Groovy腳本進(jìn)行加工，以便后一部的Data Mapping處理。由于S/4HANA與FSM兩端的數(shù)據(jù)模型稍微有所不同，在這里我們對(duì)原始的通過(guò)Odata拿到的payload在結(jié)構(gòu)上進(jìn)行了改造們這樣會(huì)極大方便下一步的mapping。Tips：在Iflow中我們推薦盡量使用標(biāo)準(zhǔn)控件來(lái)實(shí)現(xiàn)你的需求，如果標(biāo)準(zhǔn)控件不能滿足，可以采用Groovy或者JS來(lái)處理。

(4)在調(diào)用FSM的API創(chuàng)建服務(wù)呼叫之前需要獲取一次FSM的Token，要進(jìn)門(mén)你得有鑰匙對(duì)吧。這里我們需要將生成的message body服務(wù)訂單的Payload暫存到一個(gè)屬性里，因?yàn)樵谡麄€(gè)Iflow的生命周期中只有一個(gè)message body可用，如果不將之前的message body暫存，會(huì)被后續(xù)新生成的message body覆蓋掉，那么你就丟失了你的數(shù)據(jù)。

準(zhǔn)備創(chuàng)建服務(wù)呼叫的message header信息，并且將之前暫存在屬性里的服務(wù)訂單payload用來(lái)替換到message body里。最后將message body由XML轉(zhuǎn)換成Json。因?yàn)镕SM端API目前只接收J(rèn)son。

這里需要對(duì)最后的Json格式的payload進(jìn)行進(jìn)一步的處理，可能是邏輯處理，也可能是數(shù)據(jù)結(jié)構(gòu)上的處理，這是要根據(jù)具體需求來(lái)決定。接下來(lái)就是正式調(diào)用FSM的API創(chuàng)建服務(wù)呼叫。

(5) 在整個(gè)Iflow的生命周期中，可能會(huì)產(chǎn)生各種Application Error或者System Error。我們需要在Iflow里捕獲他們并且通過(guò)適當(dāng)?shù)姆绞椒祷亟o對(duì)應(yīng)的接收者。在這里我們使用的是發(fā)送郵件的方式，需要配置相關(guān)的郵件服務(wù)器地址，端口，發(fā)送者接收者的email地址，發(fā)送者的帳戶名密碼也得配置在Iflow里面。

至此整個(gè)Iflow的構(gòu)建完成。

下面我們來(lái)實(shí)際看下整個(gè)E2E的場(chǎng)景，我剛買(mǎi)的運(yùn)動(dòng)鞋穿了沒(méi)幾天就壞了，給該品牌售后打電話，協(xié)商以后他們準(zhǔn)備派師傅上門(mén)來(lái)幫我修鞋子。他們創(chuàng)建了一張服務(wù)訂單8000001219.

此時(shí)系統(tǒng)會(huì)根據(jù)之前的配置自動(dòng)觸發(fā)Iflow在FSM端創(chuàng)建服務(wù)呼叫。
在CPI提供的Monitor里面我們可以看到Iflow已經(jīng)成功執(zhí)行。如果在Iflow的執(zhí)行中出現(xiàn)了任何的錯(cuò)誤，那么在這個(gè)Monitor里也可以進(jìn)行查看，從而了解到具體的錯(cuò)誤信息。

這個(gè)時(shí)候FSM端的調(diào)度員在Dashboard里就能看到剛創(chuàng)建的這個(gè)服務(wù)呼叫了
并且分配給對(duì)應(yīng)的技師。同時(shí)FSM端會(huì)觸發(fā)一個(gè)我們自己設(shè)計(jì)的Iflow將被分配到的技師信息更新回S/4HANA端對(duì)應(yīng)的服務(wù)訂單的服務(wù)產(chǎn)品行項(xiàng)目的Parties里。

這個(gè)時(shí)候技師在手持設(shè)備上就可以接到通知，做好準(zhǔn)備工作前往客戶現(xiàn)場(chǎng)。

在現(xiàn)場(chǎng)維修服務(wù)完成以后，技師會(huì)在手持設(shè)備上錄入工時(shí)，費(fèi)用，備件等相關(guān)信息并且最后讓客戶電子簽字確認(rèn)。

這個(gè)時(shí)候公司的相關(guān)服務(wù)審核人員就會(huì)接到技師上報(bào)的信息，如果確認(rèn)無(wú)誤可以審批通過(guò)。自此整個(gè)服務(wù)流程完成。

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

總結(jié)

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

如果覺(jué)得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。