共计 4104 个字符，预计需要花费 11 分钟才能阅读完成。
SAP C/4HANA 软件套件和 SAP S/4HANA 的关系如下图所示：
以 C/4HANA 的服务云为例，买通其与 SAP S/4HANA 两个零碎的集成计划之一，就是在 C/4HANA 的服务云做一些后盾开发，即下图红色方框标注的 C4C API endpoint 所示。因为是云产品，这种后盾开发只有 SAP 能做，并没有对 Partners 凋谢。
因而本文介绍另一种 SAP Partners 可能理论施行的二次开发形式，通过这些形式，同样能实现 C/4HANA 和 S/4HANA 的简略集成场景。
须要强调的是，本文的重点是实现思路的介绍，列举出的代码仅实用于原型开发场景中，离真正实现在生产环境的规范还有很大间隔，比方短少错误处理，短少足够多的场景笼罩等等。这些须要 SAP 施行商在真正做二次开发时本人去补救。
本文应用一个简略的场景来介绍一种轻量级的集成形式：将 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(简称 HCI) 和 SAP Netweaver PI 作为中间件。
这两种举荐的形式都十分成熟，并且在泛滥的理论我的项目施行过程中失去了验证：
PI 的配置文档链接
HCI 的配置文档链接：
从我截图高亮的文档页码不难发现，应用这两种中间件都存在一些配置工作量——尽管对于诸如销售订单，客户主数据，产品主数据这种通用同步场景，SAP 曾经提供了开箱即用的解决方案，但仍需业余参谋在中间件上实现配置能力让同步流程失常工作。对于这种形式的思路，笔者集体了解就是，配置优于编码，通过大量的配置来缩小甚至防止 Partners 编码的工作量。
笔者将要介绍的另一种集成形式则反其道而行之，编码优于配置。这种形式的长处就是完全避免了 HCI 或者 PI 等中间件的引入，因而也压根不存在配置的工作量了。当然凡事无利就有弊，摈弃了中间件之后，意味着 C4C Cloud for Sales 采纳直连的形式同 S/4HANA 交互，这样 C4C 创立的销售订单传送到 S/4HANA 之后，Partners 须要在 S /4HANA 应用对应的 API 自行创立销售订单。
上面是具体的步骤。
SAP C4C 有个性能叫做 OData Notification, 在规范的 Business Object 数据产生状态变动 (创立，更新，删除) 时，能够通过 OData 的形式将这些事件推送到事件监听者去，这理论是一个简略的观察者 - 发布者设计模式。
- 既然这个性能基于 OData，咱们首先要创立一个 OData 服务，在这个 OData 服务里定义 C4C 销售订单的哪些字段，须要推送到 S/4HANA 去。
SAP C4C OData 服务的创立能够间接在浏览器里实现：
因为所要做的就是简略的建模工作，把想要裸露的字段从右边的 Business Object 列表里选中，挪动到左边即可。
我创立的 OData 服务名叫 zjerrysalesorder.
上面的 UI 就是事件发布者和监听者要害保护界面，外面的设置含意是：一旦 CUSTOMER_QUOTE(C4C 销售订单基于的 BO)产生了创立或者更新，则新建或者更新的销售订单数据会通过前一步创立的 OData 服务 zjerrysalesorder 推送到注册的事件监听者，即 S /4HANA 的 一个 API /sap/bc/dis_c4c 下来。
- 在 S/4HANA 事务码 SICF 里依照门路
/sap/bc/dis_c4c实现这个事件监听者，这个门路须要和第一步在 C4C 零碎里注册的 url 统一。
在 ABAP Netweaver 事务码 SICF 里开发的这些类从原理上能够类比成 Java 里的 Servlet，在笔者这篇博客里有具体介绍:
ABAP ICF handler and Java Servlet
在服务 dis_c4c 对应的 ABAP 解决类里设置一个断点，在 C4C 里新建一个销售订单，而后 S /4HANA 里这个断点就会触发。
当然这里波及到一个内外网穿梭的问题：运行在 Internet 网络下的 C4C 如何可能和位于企业内网环境下的 S/4HANA 交互呢？
能够采纳笔者这篇文章应用 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 实现代码，外围的逻辑就是应用函数 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.
- 在 S/4HANA 里循序渐进的实现上述 Restful API 的创立与实现。
- 在销售订单的 BO 上创立一个新的 Action triggerOutboundDelivery:
绑定到 UI 这个叫做 Trigger Delivery 的按钮上。同时在销售订单低头区域新建一个字段，用于寄存 S/4HANA 创立好的交货单 ID。
最初实现这个按钮点击后的编码实现工作，调用 WebServiceUtilties.ExecuteRESTService 去生产 S/4HANA 的 Restful API。
其中代码中呈现的 JerryExternal, JerryExternalService 这些，均是和 Restful 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 将两者关联起来。
对于这三个模型的具体创立步骤，请参考笔者的博客 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 低头区域：
总结
本文首先给出了 SAP C/4HANA 与 S/4HANA 集成的惯例形式，即采取 HCI 和 PI 作为中间件实现集成。接着分享了笔者在理论我的项目中已经应用过的一种基于事件驱动思维的轻量级集成解决方案，最初给出了 SAP 销售云里采纳 Cloud Application Studio 进行二次开发的一个理论案例。