简介

跨业务应用程序的主数据集成是SAP集成智能企业战略的关键。主数据集成战略的愿景是从"意大利面"式的点对点集成转变为"星形"集线器和辐条模型，如下图所示。

信贷：SAP云平台主数据集成服务定位平台

入门式集成具有许多优势。列出一些：

大大减少了维护工作量快速部署新应用程序集中管理数据分发以确保一致性

这些优势带来了挑战。我想通过这些基于与各方（SAP内部消费者/外部客户）互动的博客文章强调一些期望和相关挑战，这些各方有着共同的兴趣

期望：跨集成应用程序调整数据模型

考虑以上图片代表客户企业具有三个SAP应用程序（即A、B和C）的环境。为了实现集成，所有三个应用程序都需要就主数据对象的通用数据模型达成一致。这由这三个应用程序的交叉点表示为"核心属性"。这需要主数据集成层的集中支持。

除了核心属性外，A和B还有进一步的重叠，淘客宝，由"A和B的共同属性"表示。由于A和B是SAP应用程序，主数据集成层也需要处理这些属性集。这就是复杂性的开始。考虑以下挑战：

对于SAP客户来说，在他们的环境中（例如管理不同的地区）有多个需要集成的S/4 HANA（或ERP）系统并不少见。客户还拥有SAP master data governance解决方案，游戏返利，用于在中心部署中跨多个ERP系统管理数据。

因此，交叉点b/w A和b可以是一个"联合体"。因此，主数据集成层应该固有地提供一种方法来解决S/4 HANA支持的完整数据模型。

a和B共享的某些属性可能不需要C。在将数据复制到C时，这些属性应该被过滤掉。由于我们仍在标准SAP领域中行走，物联网开发，因此此功能应该在外部可用box.

例如，在典型的lead to cash场景中，SAP前端应用程序创建多个潜在客户（基于IP地址、Cookie等）。这些潜在客户在后台ERP系统中可能不需要，因为没有发生交易，因此应该过滤掉。

另一个例子是，采购不需要与驱动潜在客户到现金场景的应用程序相关的产品的销售相关数据（源到付款场景）。

管理一致性带来如下所列的多种挑战：

在维恩图中，因为C只需要与集成相关的数据子集从C传入的更新只包含主数据对象的有限属性集。此处不应覆盖主数据对象的现有数据。考虑以下情况，例如为了更好地理解这一点：

系统A复制对象1到主数据集成层。对象1具有银行信息。系统C不支持银行信息。当从系统C接收到对象1更新时，先前接收到的银行信息不应在主数据集成层丢失。

现在考虑C支持另一组属性，比如地址，并已完全删除它。C的期望是覆盖主数据集成层中对象1的地址。C应该可以将此与第一个挑战中提到的操作区分开来。

继续前面的要求，让我们更进一步。考虑C向主数据集成层发送地址而不是子属性，例如街道号。这里C应该能够指定

C是否删除了街道号码，并希望覆盖现有条目C在其数据模型中没有街道号，因此它被排除在入站消息之外。在这种情况下，物联网专用卡，现有的街道号码不应被覆盖。

现在让我们设想另一种情况，其中有多个地址。一些应用程序支持多个地址，而另一些则不支持C删除了一些地址，并希望覆盖现有条目C不支持地址，现有条目不应被覆盖

先前要求的另一个变化可能是，怎么选购云服务器，尽管C支持多个地址，但是客户有目的地从复制到C中筛选出某些地址。主数据集成层必须确保它引用此类筛选器并避免数据覆盖。

简而言之，关键是使应用程序能够与数据的"补丁"通信，而不是始终对给定主数据进行全范围通信目的

结论

我想在这里为这篇博文做个总结。我希望我能够强调管理客户期望的复杂性w.r.t.一致数据模型及其带来的挑战。在下一篇文章中，我将尝试用扩展场景（在维恩图中突出显示为补充）来涵盖期望和挑战