随着Hyperscaler及其可用服务的出现，最明显的问题可能是哪个Hyperscaler最适合他们的环境，如何利用和无缝集成服务来构建独立的功能，涉及SAP S/4HANA与遗留系统的集成，利用谷歌云平台（GCP）服务。

客户简要背景–

客户是美国的家装零售商，提供工具、建筑产品和服务。他们积极投资新技术，以改善其在线和数字业务、前端零售业务以及库存和供应链管理等后台活动。

过去几年，公司开始了"互联"零售之旅，与"全渠道"零售相结合。他们需要一个单一的存储库，用于所有渠道销售的最细粒度事务级别，能够在任何级别实时聚合，以实现市场活动的有效性和提高客户满意度。这带来了重大的变革，同时由于现有的复杂环境和复杂的业务场景带来了许多挑战。

可能的运营效率低下的场景–

"店内"能够在一个SKU上有多个UPC，而"在线商店"只有一个SKU UPC。与店内流程相比，在线渠道当前仅支持一个项目的活动供应商。在多个系统中维护重复数据

凭借超过10年的SAP解决方案和运营经验，公司已经与SAP建立了长期持续的合作关系。公司已经拥有HANA许可证，由于BW在HANA和CAR上的成功，他们希望将HANA的使用范围扩展到其他业务领域，并提高HANA用户的采用率。与正在进行的计划并行，公司启动了商品主数据项目。

该项目侧重于供应商和产品数据，以及表示与位置的关系交叉点。我们从与业务利益相关者的设计讨论会开始，即时通讯云平台，以了解他们的现有数据、SAP支持的可用功能、整合的可能领域（数据）以及与SAP最佳实践（定制开发范围）不一致的公司特定场景。

在本项目启动之前，公司在时间表中计划了cFin和SAP客户活动存储库（CAR）的实施。当前项目的启动考虑了以下关键因素–

业务好处：

处理频繁的更改，从基本SKU复制不同的SKU；利用分组功能汇总财务报告。供应商的单一标识符，不考虑渠道渠道独立的条款和参考，以确保统一的体验，无论是在商店和网上的客户由于online不支持单个SKU上有多个UPC，因此他们必须使用两个SKU，并通过监控DC库存从旧SKU过渡到新SKU。店内库存的一次性转换；现有UPC到其新的独特SKU。这包括将104个UPC转换为独特的SKU

技术影响：

确保将DB2到SAP环境的更改"近"实时复制。正确捕获已标识主数据的所有相关属性、时间戳和用户凭据—业务伙伴、供应商折扣、装运条款、商品（SKU）。利用现有商品数据的商品相关价值丰富数据（通过并行的先前计划/项目加载/创建）将SKU UI前端构建为SKU创建或更新的单个数据输入点。更改SKU创建工具以生成族关系以处理多计量单位方案。能够利用项目数据管理（IDM）为供应商查看、设置和维护产品数据灵活的数据保留结构简化所有全渠道的数据确保使用最佳SAP功能（如OData API、OAuth2.0身份验证、GCP API管理）集成SAP S/4HANA将对正在进行的业务和并行项目的中断降至最低。

景观、技术架构–

本项目实施可大致分为两部分，即供应商和文章，大数据是干什么的，不同数据库表之间的集成，以及SAP S/4HANA系统。Google Cloud Platform（GCP）微服务在SAP中大量用于发起入站OData API接口，而出站接口则通过PI/PO作为中间件进行传输

a）供应商集成

集成包括所有与供应商相关的主数据，如业务伙伴维护等，供应商折扣维护和装运条款维护。每当用户触发对遗留应用程序db2中的供应商记录的创建/更改时（步骤1），更改都会在WMQ队列中排队（步骤2）。cloudfoundry上的侦听器（步骤3）读取队列并将更改存储在BigQuery中，以用于历史目的、分析和审计目的。更改还被发送到GCP数据存储（步骤5），在那里数据被缓存，然后由发布者获取（步骤6）。在事件发布到发布/子主题（步骤7）时，推送订阅被传递到发布者应用程序事件（步骤8），该事件反过来触发SAP OData API。随后，db2数据被转换并存储在HANA数据库中，以及所有相关的检查、验证和依赖关系。

上述微服务体系结构的优点有助于简化每个功能，淘客机器人，并在很大程度上独立于每个功能。此外，什么大数据，这种方法还为任何功能点故障时的重试/重新触发消息提供了强大的机制。

b）文章（SKU）集成

集成包括所有与文章相关的主数据，如SKU、UPC、UoM、GTIN，大数据和数据分析区别，以及集合、层次结构、分类等关系。

SKU用户界面使用React web构建框架，并使用odataapi与saps/4HANA集成。SKU UI和SAP S/4HANA系统都托管在谷歌云平台和公司的安全网络中。在不同的集成点进行了不同的检查和验证，以确保数据完整性和Article master的数据丰富性。

此集成的主要用途是–

结论–