一种基于事件驱动思想的SAP系统集成二次开发方法介绍S/4HANA的两个系统的集成方案之一是在C/4HANA的服务云上做一些后台开发,如图C4C下图中红框标记的API端点。因为是云产品,只有SAP可以做这种后台开发,不对合作伙伴开放。因此,本文介绍另一种SAPPartners可以真正实现的二次开发方式。通过这些方法,也可以实现C/4HANA和S/4HANA的简单集成场景。需要强调的是,本文的重点是实现思路的介绍。列出的代码仅适用于原型开发场景,距离生产环境标准还有很长的路要走,比如缺乏错误处理,缺乏足够的场景覆盖等等。这些都需要SAP实施者在真正做二次开发的时候去弥补。本文以一个简单的场景来介绍一种轻量级的集成方式:将C/4HANA中销售云的销售订单(SalesOrder)同步到S/4HANA中。因为在S/4HANA中,可以根据销售订单生成后续的生产订单,一旦实现这个集成场景,理论上我可以用手机访问C/4HANA销售云,触发S/4HANA制造流程。手机。对于SAPC/4HANASalesCloud中的C4CCloudforSales部分,如果需要与SAPERP、SAPCRM等其他SAPOn-Premises产品集成,SAP官方推荐的同步方式是使用SAPHANACloudIntegration(简称HCI)和SAPNetweaverPI作为中间件。这两个推荐的方法非常成熟,在很多实际项目的实现中得到了验证:PI配置文档链接HCI配置文档链接:从我截图中高亮显示的文档页码不难发现,使用这两个有中间件中的一些配置工作量——虽然SAP已经为销售订单、客户主数据、产品主数据等通用同步场景提供了开箱即用的解决方案,但仍然需要专业的顾问在中间件上进行配置。同步过程才能正常工作。对于这种思路,笔者个人的理解是配置优于编码,大量的配置可以减少甚至避免Partner编码的工作量。我要介绍的另一种集成方式恰恰相反,编码优于配置。这种方式的好处是完全避免了HCI或者PI等中间件的引入,完全没有配置工作量。当然,任何事情都有优点和缺点。放弃中间件后,意味着C4CCloudforSales使用直连方式与S/4HANA交互,这样C4C创建的销售订单传输到S/4HANA后,合作伙伴需要在S/4HANA中使用对应的API自行创建销售订单。以下是具体步骤。SAPC4C有一个称为ODataNotification的功能。当标准的BusinessObject数据状态发生变化(创建、更新、删除)时,这些事件可以通过OData推送给事件监听器。这实际上是一个简单的观察者。-发布者设计模式。由于该功能是基于OData的,所以我们首先需要创建一个OData服务,在该服务中定义C4C销售订单的哪些字段需要推送到S/4HANA。SAPC4COData服务的创建可以直接在浏览器中完成:因为你需要做的只是简单的建模工作,所以从左边的BusinessObject列表中选择你想要暴露的字段,然后移动到右边。我创建的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保持一致。ABAPNetweaver事务代码SICF中开发的这些类,原理上可以类比Java中的Servlet,在作者博客中有详细介绍:ABAPICFhandlerandJavaServletsetabreakintheABAPprocessingclass对应servicedis_c4cPoint,在C4C中新建一个销售订单,然后会触发S/4HANA中的断点。当然,这涉及到一个内外网穿越的问题:运行在Internet网络下的C4C如何与企业内网环境下的S/4HANA进行交互?您可以使用本文介绍的SAP云平台+CloudConnector方案,使用Java+SAP云平台+SAPCloudConnector调用ABAPOn-Premise系统中的函数实现内外网访问,或者直接连接S/4HANAurl/sap/bc/dis_c4c经过内外网地址映射后暴露给外网直接访问。当然,不推荐后者。将其用于原型开发和概念验证是没有问题的。如果是正式使用,那就用SAP云平台的标准方案。我们可以在断点处观察到C4C向S/4HANA推送的数据格式。从调试器中我们可以看到S/4HANA接收到的是一个JSON格式的字符串,其中包含了触发事件的BO名称、状态发生变化的BO实例的GUID、触发事件的类型已触发,以及OData服务的URL。这个OData服务就是我第一步创建的zjerrysalesorder.S/4HANA。通过消费这个OData服务,可以通过OData服务获取C4C中创建的销售订单暴露的数据。下面例子中的事件是create,通过消费红色标出的OData服务url,我们可以获取S/4HANA中C4C新建的销售订单的详细信息,然后调用操作销售订单创建的API它在S/4HANA中。S/4HANA端ABAP实现代码的核心逻辑是使用函数SD_SALESDOCUMENT_CREATE创建。这个S/4HANA函数的接口虽然和SAPCRM的CRM_ORDER_MAINTAIN不一样,但是设计思路是差不多的。订单的数据分散在诸如Header、Item、Party、Text等节点上,可以直接填写某个节点对应的input结构,完成相应数据的创建。将C4C创建的销售订单同步到S/4HANA的实际效果可以参考这个腾讯视频。这种通过observer-publisher模式同步C/4HANA和S/4HANA数据的方式依赖于C4C中BO状态的三个变化:创建、修改和删除,不够灵活。从上面的开发可以看出,Partners的二次开发工作量主要集中在S/4HANA上,并没有C/4HANA端的编码工作,只完成了一个OData服务的建模和事件注册。当事件发生时,C/4HANA向S/4HANA发起的事件推送由C4C系统层面的组件完成。那么,有没有办法让Partner通过C4C端的二次开发和编码,直接在C/4HANA中消费S/4HANA服务呢?当然有。假设这样一个场景:C/4HANA的销售订单同步到S/4HANA后,S/4HANA完成必要的生产流程后,才能进行后续的发货流程。目前的需求是直接在C4C销售订单的UI上触发创建S/4HANAOutboundDelivery,这样业务人员不需要登录S/4HANA系统,只需要在C4C应用上使用手机到即可完成S/4HANA交付流程的触发。这个要求合作伙伴可以通过二次开发完全实现。思路是:在S/4HANA中将外发订单创建函数BAPI_OUTB_DELIVERY_CREATE_SLS封装成RestfulAPI,然后在C4CCloudApplicationStudio中进行二次开发,使用ABSL(ABAPScriptingLanguage)来消费API。在S/4HANA中逐步完成以上RestfulAPI的创建和实现。在销售订单的BO上创建一个新的ActiontriggerOutboundDelivery:绑定到名为TriggerDelivery的UI按钮。同时,在销售订单表头区域新建一个字段,用于存放S/4HANA创建的送货单ID。最后完成点击按钮后的编码实现工作,调用WebServiceUtilties.ExecuteRESTService来消费S/4HANA的RestfulAPI。代码中出现的JerryExternal和JerryExternalService是RestfulAPI消费相关的模型名称。S4CRM在基于Netweaver的ServiceIntegration场景中需要三大模型:CommunicationArrangmentCommunicationSystemCommunicationScenario因为C4C后台也是基于Netweaver,为了消费S/4HANA的RestfulAPI,我们也需要在C4C中创建这三个模型.简单来说,CommunicationSystem负责维护ServiceProvider所在的系统,在我们的例子中是S/4HANA系统:CommunicationScenario负责维护RestfulService端点,CommunicationArrangement连接两者。这三个模型的详细创建步骤可以参考作者的博客使用RestfulService在SAPCloudforCustomer中消费S4功能。最终效果为:点击按钮前,S/4HANA生成的发货单ID字段为空:点击按钮后,S/4HANA生成发货单,通过S/4HANA返回其ID4HANARestfulAPI存储在C4C销售订单BO的扩展字段中,显示在UI的表头区域:总结本文首先给出了SAPC/4HANA和S/4HANA集成的常规方式,即HCI和PI作为中间件来完成集成。然后分享了作者在实际项目中使用的基于事件驱动思想的轻量级集成方案,最后给出了在SAPSalesCloud中使用CloudApplicationStudio进行二次开发的实际案例。
