SAP Business Partner Key Mapping 详解

简介

在通过 Web Service（SOAP）进行SAP Business Partner集成的上下文中，数据分发过程会使用目标系统中定义的编号范围来创建业务伙伴及其相关对象，例如客户、供应商、地址等。需要注意的是，这些对象的创建可能并不一定使用与源系统相同的编号范围。为了实现这种编码的灵活性，SAP利用了名为**“键值映射”（Key Mapping）**的功能，这一功能对确保系统内每个对象都能得到准确识别至关重要。由于标准SAP BP Webservice必须依赖于键值映射，且很多数据集成问题都是由于Key Mapping设置不当所致，因此要识别并解决此类问题需要具备一定的专业技术知识。

本文的目的是让你全面了解SAP BP集成场景中的“键值映射”概念。文章将带你一起探讨如何识别键值映射中的特定问题，并讲解如何修正这些问题。

文章受众：负责SAP Web Service集成的相关技术人员

相关系统：MDG 和 S/4HANA 系统

常见问题

在下面的表格中，你可以看到在入站处理过程中因数据报文中的键值映射问题而返回的一些最常见的错误信息：

除了以上这些常见报错外，错误的Key Mapping也会导致一些数据问题出现：

• 合作伙伴功能没有正确创建或更新
• 在同一个报文中多次出现相同的业务伙伴

什么是键值映射（Key Mapping）？

简单来说，键值映射是一张用于获取相关系统中特定对象对应编号的映射表。在该映射表中，每个业务伙伴及其关联对象都将被分配到一个唯一的映射组（Map Group），与该业务伙伴相关的所有编号都必须属于同一个映射组。下面是一个映射组的例子：

当系统 A 尝试将 BP 1000082741 分发到系统 B 时，它会检查“键值映射”表，以确定目标系统中对应的编号是什么。为了找到键值映射关系，源系统会将以下4个值作为搜索条件进行检索：

1. 自身业务系统：系统_A
2. 自身业务伙伴编号：1000082741
3. 自身业务伙伴UUID：0d17a4a2-b86d-4038-a709-118d3203c779
4. 目标业务系统：系统_B

通过自身业务系统、业务伙伴编号和 UUID，它首先找到了映射组 1000。然后，它会检查在同一个映射组下，目标业务系统是否有对应的编号。在此示例中，将会找到以下条目：

1. 目标业务伙伴编号：9999921374
2. 目标业务伙伴UUID：a5b13f62-4948-4053-a57a-d209cf9ce87f

此处需要特别注意对象标识符
一个对象可以同时存在多个标识符，比如“业务伙伴”对象下，它们可以通过一个 10 位编号和一个 UUID（通用唯一标识符）来加以识别。由于这两个标识符在同一个系统中都指向同一个对象，所以它们必须具有相同的对象标识符。这就是为什么对象标识符在“编号”和“UUID”中会出现重复的情况。

如何使用键值映射（Key Mapping）？

在生成数据报文时，源系统会使用“键值映射”（如果存在的话）在 XML 文件中设置目标对象编号。这些编号将被放置在名称以“接收方”（Receiver）开头的标签中，例如：

<BusinessPartner actionCode="04" ...>
    <!-- Source system BP UUID: -->
    <UUID>0d17a4a2-b86d-4038-a709-118d3203c779</UUID> 
    <!-- Source system BP Number: -->
    <InternalID>1000082741</InternalID> 
    <!-- Target system BP UUID: -->
    <ReceiverUUID>a5b13f62-4948-4053-a57a-d209cf9ce87f</ReceiverUUID> 
    <!-- Target system BP Number: -->
    <ReceiverInternalID>9999921374</ReceiverInternalID> 
    ...
</BusinessPartner>

如果键值映射不存在，那么数据报文将不会包含接收方标签：

<BusinessPartner actionCode="04" ...>
    <!-- Source system BP UUID: -->
    <UUID>0d17a4a2-b86d-4038-a709-118d3203c779</UUID> 
    <!-- Source system BP Number: -->
    <InternalID>1000082741</InternalID> 
    ...
</BusinessPartner>

目标系统会对数据报文进行处理，并利用接收方标签来判断这些对象是需要创建还是需要修改：

• 如果接收方标签存在，其值将被用于查找相关对象并对其进行更新。
• 如果接收方标签不存在，目标系统将尝试创建相关对象。

特殊事项

当业务伙伴的接收方标签不存在时，目标系统将使用源系统的业务合作伙伴唯一标识符（BP UUID）来确定是否已存在对应的业务伙伴。如果目标系统找到了与源系统具有相同 UUID 的业务伙伴，则该业务伙伴将得到更新。否则，将创建一个新的业务伙伴。

需要强调的是，键值映射仅适用于其所代表的特定对象。一个对象的键值映射的存在并不意味着会自动识别与其相关的对象。例如，如果业务伙伴具有“键值映射”内容，但关联的客户没有，那么只有业务伙伴的数据将会被更新。如果客户主数据没有设置“键值映射”内容，目标系统将会尝试为其创建该条目。如果目标系统中已存在该客户，则会返回错误消息“对已存在的客户执行插入任务操作不支持”。

何时创建键值映射（Key Mapping）？

理想情况下，键值映射应由目标系统在创建数据对象时自动生成。通过Web Service实现的业务伙伴数据集成涉及 4 个业务伙伴服务和 4 个业务伙伴关系服务：

对于每个业务伙伴，都会有一条确认消息，其中包含在目标系统中创建的对象的编号。在源系统中，当处理这些确认消息时，会自动创建键值映射：

• BusinessPartnerSUITEBulkReplicateConfirmation_In
• BusinessPartnerRelationshipSUITEBulkReplicateConfirmation_In

在目标系统中，也应该创建键值映射。这一操作会在请求消息成功处理完业务伙伴数据后进行：

• BusinessPartnerSUITEBulkReplicateRequest_In
• BusinessPartnerRelationshipSUITEBulkReplicateRequest_In

这里需要特别注意的是，如果确认消息配置不当，那么在源系统中将永远无法创建键值映射，从而导致上述至少一种问题的发生。如果在正式上线BP集成之前不能迅速发现这一问题，那么可能会有成千上万的业务伙伴被重复分发，而不会生成键值映射。下次同样的业务伙伴再次被分发时，源系统将无法告知目标系统哪些业务伙伴需要更新。结果，目标系统将再次尝试创建相同的对象。

在何处维护键值映射（Key Mapping）？

出于某些原因，可能需要手动调整键值映射内容。例如，假设你使用 BP 事务码在两个不同的系统中创建了相同的业务伙伴，而现在你希望通过Web Service进行的数据集成将该业务伙伴从一个系统分发到另一个系统。由于该业务合作伙伴并非最初由分发过程创建的，因此键值映射将不可用。这样一来，就必须手动创建键值映射。

在这种情况下可以使用两个相关事务码：

• MDG_ANALYSE_IDM
• MDG_KM_MAINTAIN

MDG_ANALYSE_IDM 可用于搜索并显示键值映射信息。如果你的目的仅仅是查看键值映射情况，那么此选项非常合适，因为它具有灵活的搜索条件设定。

MDG_KM_MAINTAIN 是一个基于网页界面的应用，它能够显示、更改和创建键值映射。

键值映射的相关对象

BP标准集成方案不仅分发“业务伙伴”这一对象，还涵盖了其他相关对象，包括“客户”、“供应商”、“联系人”和“关系”。这些对象都有各自的编号范围，因此需要进行“键值映射”。

接下来，我将通过一些示例展示如何为这些对象中的在数据集成中手工维护好键值映射内容：

• 源系统：MDGCLIENT （蓝色）
• 目标系统：S4H_100（红色）

业务伙伴的键值映射

在源系统中，使用BP事务码创建一个业务伙伴。业务伙伴 9000020 通过内部给号在源系统 MDGCLIENT 中创建。

在目标系统中，使用BP事务码创建一个相同的业务伙伴。这次，在系统 S4H_100 中它的编号为 6100022。

由于该业务伙伴在两个系统中都是手动创建的，因此不存在键值映射信息。如果我现在尝试分发此业务伙伴，目标系统将接收到没有接收方标签的报文，从而导致创建一个新的业务伙伴，而不是更新业务伙伴 6100022。

为了维护键值映射内容，我将使用源系统中的“MDG_KM_MAINTAIN”事务码来进行操作。首先，我进行查找以确认业务伙伴 9000020 没有键值映射：

在确认不存在键值映射后，我现在可以进行键值映射的维护。在这种情况下，需要维护4条信息：

1. 源系统的业务伙伴编号
2. 源系统的业务伙伴UUID
3. 目标系统的业务伙伴编号
4. 目标系统的业务伙伴UUID

如何获取业务伙伴UUID？

业务伙伴信息存储在表 BUT000 中。在该表中，PARTNER_GUID 字段保存着业务合作伙伴的 GUID。通过对 GUID 进行简单的格式化处理，即可获得 UUID。

• GUID格式：C3F528B5F28F1FD192EC03F90E419CC8
• UUID格式：c3f528b5-f28f-1fd1-92ec-03f90e419cc8

要创建新的键值映射，我点击“添加行”并添加了4行新内容：

请注意，第一列“编号”，同一对象的业务伙伴编号和业务伙伴 UUID 的编号值需保持一致。

你还会注意到这里没有“映射组”的相关信息。实际上，MDG_KM_MAINTAIN 不会显示这一列。不过，你必须假定屏幕上显示的所有行都属于同一个映射组。当你使用 MDG_KM_MAINTAIN 查找某个对象时，它会将找到的该对象的所有条目归入同一映射组中。要查看映射组，我们可以使用 MDG_ANALYSE_IDM 事务。

在“对象的映射组”部分，可以看到之前使用 MDG_KM_MAINTAIN 保存的4个关键映射。它们都属于同一个映射组，即 C3F528B5F28F1FE192EC50EC3330401C。

另一个在此处显示，但在 MDG_KM_MAINTAIN 中未显示的信息是“Object_ID”列。与 MDG_KM_MAINTAIN 一样，对于指向同一对象的标识符（例如业务伙伴编号和业务伙伴 UUID），其值会重复出现。为了使用户使用起来更方便，MDG_KM_MAINTAIN 会将“对象 ID”中的庞大数字转换为较小的整数形式。

既然业务伙伴的键值映射已得到维护，那么分发操作应该能够正常进行。当为该业务伙伴触发分发操作时，接收方的标签会被放入数据报文中：

<BusinessPartner ...>
    <UUID>c3f528b5-f28f-1fd1-92ec-03f90e419cc8</UUID> 
    <InternalID>9000020</InternalID> 
    <ReceiverUUID>c3f528b5-f28f-1fd1-92ec-13e8405f5d68</ReceiverUUID> 
    <ReceiverInternalID>6100022</ReceiverInternalID> 
    ...
</BusinessPartner>

结论

希望本文能够以某种方式帮助你理解在业务伙伴集成过程中涉及的每个对象的键值映射是如何保持一致的，以及其重要性所在。