What Is Key Mapping? 

When a Business Partner is created in one system and needs to be replicated to a connected system, both systems must be able to identify and reference the same object — even though each system maintains its own internal keys. 

Key mapping is the mechanism that maintains the identity relationship between records across two systems. When a Business Partner is created in the sender system and replicated to the receiver system, the receiver registers the new record and sends back its own identifier. The key mapping mechanism captures both sides of this relationship, enabling consistent cross-system references for all future operations on that object.

In short: key mapping is what makes two systems say, “my record #1001 is your record #abc-uuid-xyz”. 

This blog is co-written with @Karunaharan 

 

1. How the Replication Flow Works 

Business Partner replication over SOAP services operates across two coordinated processes:  

• an Outbound Process on the sender side and 
• an Inbound Process on the receiver side. 

Outbound Process (Sender System) 

• Initiate Replication 
• Retrieve Key Mapping in Sender System 
• Transmit Data to Receiver System 
• After receiving confirmation from target, update Key Mapping in Source System  
• Changes to Database  

Inbound Process (Receiver System)  

• Retrieve the Business Partner in the destination system using Key Mapping 
• Create or Update Business Partner 
• Send Confirmation 
• Update Key Mapping in Destination System 
• Changes to Database  

The two processes are tightly coupled — the confirmation sent back from the receiver system triggers the key mapping update on the sender system. This means every replication cycle involves key mapping operations on both ends, across multiple services. 

 

2. How Key Mappings Are Structured 

Not all key mappings are saved in the same operation. The saving logic is grouped as follows: 

• Combined single save: Business Partner, Customer, and Supplier key mappings persisted together in one save call.
• Separate save: Address key mappings persisted independently.
• Separate save: Multiple Assignment key mappings persisted independently. 

This means every replication of a single Business Partner involves at least three distinct key mapping save operations, each capable of locking its respective database table. 

 

3. The Problem: Redundant Saves Across All Services 

This replication flow spans multiple SOAP services:  

• Business Partner Inbound, and the Confirmation Service (Customer, Supplier, Address, Multiple Assignments) and
• Relationship Inbound and confirmation Services  

  In all these services, the system was saving key mappings on every replication run, regardless of whether the Business Partner was new or already existing. 

  Receiver System: Bulk Saves on Every Run 

  On the receiver system, key mappings for Business Partner, Customer, Supplier, and Address are saved in bulk during each processing pass. While the bulk approach consolidates the operations, the problem of saving on every run — including updates where mappings already exist — introduces unnecessary database locks. 

  Confirmation in Sender System: The Bigger Problem 

  The confirmation service — running on the sender system — was saving key mappings individually for every confirmation received, one at a time. This is where the most severe performance degradation occurred. 

  Consider a realistic enterprise scenario: 

  • A source system replicates 1000 Business Partners to 10 connected receiver systems. 
  • The source receives 1000 × 10 = 10,000 confirmations — one per Business Partner per receiver system. 
  • For every confirmation, the key mapping saving logic executed individually, locking the database table each time. 
  • With three separate save operations per Business Partner , Address, Multiple Assignments and the actual lock count is a multiple of 10,000 confirmations. 

 

4. Root Cause 

The core mismatch is between what the system does and what is needed: 

• Insert scenario (new object): Saving a key mapping is essential — the mapping does not exist yet and must be established.
• Update scenario (existing object): The key mapping was already created at first insert. Re-saving it on every subsequent run serves no purpose and only generates unnecessary database locks.

This approach made no distinction between these two cases. All services — inbound, confirmation, and relationship — executed the full save logic unconditionally on every run. 

 

5. The Solution: Insert-Only Key Mapping Persistence 

The fix is applied differently on each side of the replication flow, targeting the specific problem each side had. 

Receiver System – Inbound Process

On the inbound side, key mapping saves for Business Partner, Customer, Supplier, Address and Multiple assignments are now restricted to insert scenarios only. When an existing Business Partner is being updated, all saves are skipped — the mappings already exist and need not be rewritten.

Sender System – Confirmation Process 

The confirmation side improvements: 

• Insert-only: Key mapping saves now execute only when the confirmation corresponds to a newly created object, not an update.
  

  Save Structure Summary 

  Object Group	Save Structure	Insert Scenario	Update Scenario
  Business Partner + Customer + Supplier	Combined single save	Save	Skip
  Business Partner Address	Separate save	Save	Skip
  Multiple Assignments	Separate save	Save	Skip

 

6. Impact and Benefits

• Confirmation-side lock storm eliminated — The most damaging pattern — individual key mapping saves per confirmation on the source system — now fires only for new mappings. For a sender system replicating to 10 systems, lock events drop to the count of newly created objects.
• Lock volume scales with new objects, not total volume — Previously, locks scaled with total Business Partners × connected systems × runs. After the fix, they scale only with newly created objects — a far smaller number in steady-state operations.
• Sender system stability restored — Removing the confirmation-side individual save burden means the sender system is no longer locked against itself while managing outbound replication traffic.
• Inbound saves optimized — Bulk saves on the inbound side now process only new mappings, reducing both the size of each bulk operation and table lock frequency on the receiver system.
• Scales inversely with replication maturity — As the landscape matures and updates outweigh inserts; optimization becomes increasingly effective. A fully synchronized landscape generates almost no key mapping lock contention at all.

7. How to Enable Optimization 

This optimization is controlled by a configuration activity. To enable it, locate the configuration activity “Optimize Key Mapping Table Access” (#107231) and switch it on to activate the optimization. Once enabled, the system will apply insert-only key mapping persistence across the replication flow. 

 

8. Best Practices Before Performing Mass Business Partner Replication

While the key mapping optimization significantly improves replication performance, following a few operational best practices helps ensure a smooth and successful replication, especially in high-volume enterprise landscapes.

Schedule Replication During Off-Peak Hours

For large-scale replication activities involving thousands of Business Partners, SAP recommends scheduling replication during off-peak business hours.

Running mass replication during periods of low system activity minimizes competition for system resources such as database connections, application server work processes, and network bandwidth, resulting in faster and more predictable processing.

Verify System Availability

Before initiating a mass replication, ensure that both the source and target systems are fully available and operational. A temporary system outage or scheduled maintenance on either side can interrupt the replication process, leading to retries, queue backlogs, and delayed confirmations.

Verify the following:

• Source system is available.
• Target system is available.
• Middleware (SAP Integration Suite/CPI, SAP PI/PO, or other integration middleware) is operational.
• Network connectivity between systems is stable.

Ensure Replication Queues Are Healthy

Before starting a new replication cycle, verify that there are no existing errors or blocked messages from previous replication runs. Review the following components as applicable:

• SOAP monitoring
• Message queues
• Application Interface Framework (AIF)
• Integration middleware
• Resolving existing replication errors beforehand helps prevent queue congestion and ensures that new replication requests are processed efficiently.

Verify Key Mapping Consistency

Ensure that existing key mappings are synchronized across connected systems before initiating large update replications. Incomplete or inconsistent key mappings can result in duplicate Business Partner creation, failed updates, or unnecessary error handling.

Source link