项目背景

相信大家已经知道，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.