本文作者是我的同事,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的集成场景介绍相关推荐

  1. SAP S/4HANA Cloud 上 in-app 和 side-by-side 两种扩展方式的介绍

    我们可以使用 SAP 提供的一个工具: SAP Extensibility Explorer for SAP S/4HANA Cloud 可扩展性涵盖了广泛的主题,使客户和合作伙伴能够使标准业务软件适 ...

  2. SAP S/4HANA Customer Management(CRM)模块的扩展性设计

    标题:One order extensibility in S4HANA for Customer Management In SAP CRM we use Application Enhanceme ...

  3. SAP Field Service Management 和微信集成的案例分享和实现介绍

    SAP FSM(Field Service Management), 属于SAP C/4HANA五朵云里的Service Cloud. 本文介绍笔者在工作中经历过的一个项目,包含 SAP Field ...

  4. SAP S/4HANA OData Mock Service 介绍

    官网 OData Mock Service 此存储库还包含一个简单的基于 Node.js 的服务器,它代表分支模拟服务器中的 OData 模拟服务器. 该服务器可以在不访问 SAP S/4HANA 系 ...

  5. SAP BW/4HANA学习笔记2

    2.Data Modeling BW/4HANA Data Modeling简介 Data Quality:数据质量问题: silos(桶仓):大量重复冗余的主数据,独立计算统计: 数据silos缺点 ...

  6. SAP S/4HANA Cloud 系统集成的一些场景介绍

    如下图所示:SAP S/4HANA 集成有下列这些类型: 用户移动设备同 SAP 云的集成 SAP 云系统之间的集成 SAP 云系统同物联网解决方案的集成 SAP On-Premises 解决方案同 ...

  7. SAP现金管理(Cash Management)的基本概念

    在本篇博客中,我将介绍SAP现金管理的基本概念,并兼顾ECC上和S/4HANA上现金管理配置的异同. 1. 业务背景与工具 在博客SAP与三大财务报表之 "现金流量表"中,我对企业 ...

  8. SAP C/4HANA到底包含哪些产品?

    2018年6月的SAPPHIRE(蓝宝石大会)上, SAP发布了新的商务软件套件:C/4HANA,意在通过SAP C/4HANA将前台应用和SAP Digital Core(数字化核心)S/4HANA ...

  9. SAP S/4HANA现金管理之变

    SAP S/4HANA现金管理之变 http://mp.weixin.qq.com/s/42zD6Hh1k5mV-73zRMh8ZA SAP S/4 HANA的现金管理包括现金头寸,流动性管理和银行账 ...

最新文章

  1. OpenCASCADE:OCCT应用框架OCAF之形状属性
  2. 买卖股票的最佳时机含手续费
  3. dataframe两个表合并_R语言读取多个excel文件后合并:rbind/merge/cmd合并
  4. Windows中常用的函数调用规范
  5. C语言sql参数化查询,使用LIKE的sql参数化查询
  6. nginx 和 php超时设置
  7. kali字典_Web渗透测试——暴力破解字典制作工具的使用2
  8. xshell免费版下载安装及使用
  9. js 手机号码正则
  10. 照片放大模糊怎么变清晰,图片无损放大
  11. 创客使用Fusion 360 - 草绘
  12. GhostScript 沙箱绕过(命令执行)漏洞 CVE-2019-6116 漏洞复现
  13. pyTest官方手册(Release 4.2)之蹩脚翻译(1)
  14. CVPR 2018值得一看的25篇论文,都在这里了 | 源码 解读
  15. Autovue 问答
  16. 一个屌丝程序猿的人生(六十九)
  17. 骁龙8gen1Plus和骁龙8gen1区别
  18. Richard Matthew Stallman和GNU
  19. MySQL Error 1236处理
  20. 《周志华机器学习详细公式推导版》完整PDF首发!1.1w+标星开源项目pumpkin-book...

热门文章

  1. POJ 3225 线段树+lazy标记
  2. 设置隐藏文件的显示与隐藏方法
  3. 在什么时候需要使用“常引用”?
  4. 第十八章 12判断string类型字符串是否为空
  5. TCP/IP 2.5浮动静态路由
  6. 数据库连接出错,请检查连接字串"的多种问题解决办法
  7. 获取某个日期是一年中的第几周
  8. 创建型模式:抽象工厂
  9. iOS-MVVM架构优化
  10. Entity Framework 实体框架的形成之旅--基于泛型的仓储模式的实体框架(1)