一种基于事件驱动思想的 SAP 系统集成二次开发方法介绍

Posted 2022-05-16 JerryWang汪子熙

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 的方式将这些事件推送到事件监听者去，这实际是一个简单的观察者-发布者设计模式。

1. 既然这个功能基于 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 上去。

2. 在 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.

1. 在 S/4HANA 里按部就班的完成上述 Restful API 的创建与实现。
2. 在销售订单的 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 进行二次开发的一个实际案例。