测试
全部博文（931）
分类： 架构设计与优化
2019-05-05 17:02:57
有好几位朋友在公众号后台给我留言询问SAP C/4HANA和S/4HANA集成的方案。
尽管我给这些朋友推送了一个方案：打通C/4HANA和S/4HANA的一个原型开发：智能服务创新案例，然而我得到的反馈是：在这个创新案例里，需要在C/4HANA里的服务云做一些后台开发，即下图红色方框标注的C4C API endpoint。因为是云产品，这种后台开发只有SAP能做，并没有对Partners开放。
因此这篇文章我会介绍一些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的配置文档：
这个链接是HCI的配置文档：
大家从我截图高亮的文档页码不难发现，使用这两种中间件都存在一些配置工作量——虽然对于诸如销售订单，客户主数据，产品主数据这种通用同步场景，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。
下面的UI就是事件发布者和监听者关键维护界面，里面的设置含义是：一旦CUSTOMER_QUOTE(C4C销售订单基于的BO)发生了创建或者更新，则新建或者更新的销售订单数据会通过前一步创建的OData服务zjerrysalesorder推送到注册的事件监听者，即S/4HANA的一个API /sap/bc/dis_c4c上去。
2. 在S/4HANA事务码SICF里按照路径/sap/bc/dis_c4c实现这个事件监听者，这个路径需要和第一步在C4C系统里注册的url一致。
在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里这个断点就会触发。
当然这里涉及到一个内外网穿越的问题：运行在Internet网络下的C4C如何能够和位于企业内网环境下的S/4HANA交互呢？
可以采用Jerry之前的文章 使用Java+SAP云平台+SAP Cloud Connector调用ABAP On-Premise系统里的函数 里介绍的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里进行创建工作。
S/4HANA端完整的ABAP实现代码已经放到我的github上了：
核心的逻辑就是使用函数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:
绑定到UI这个叫做Trigger Delivery的按钮上。同时在销售订单抬头区域新建一个字段，用于存放S/4HANA创建好的交货单ID。
最后完成这个按钮点击后的编码实现工作，调用WebServiceUtilties.ExecuteRESTService去消费S/4HANA的Restful API。
这段ABSL的完整代码：
其中代码中出现的"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
最后实现的效果是：点击按钮之前，存放S/4HANA生成的交货单ID的字段是空的：
点了按钮在S/4HANA生成交货单之后，其ID通过S/4HANA Restful API的返回结果存储在C4C销售订单BO的扩展字段上，并显示在UI抬头区域：
还是通过这个视频查看运行时的效果。
对于这种同步解决方案有任何意见，欢迎留言。感谢阅读。
更多阅读
要获取更多Jerry的原创文章，请关注公众号"汪子熙":
