Lesson 4 of 5
ID mapping
9 min
Listen to this lesson
Value mapping translates codes. ID mapping solves a different problem: giving a message a stable identity. In Cloud Integration, the ID Mapping flow step generates a target message ID that is uniquely tied to a source message ID and a context. Process the same combination again and you get the same target ID back. Receivers use that stable ID to recognize a message they have already processed.
How the ID Mapping step works
Add it from the palette under Mapping > ID Mapping. On the first run for a given combination of Source Message ID and Context, the step generates a GUID as the target message ID, stores the pair in the tenant database and writes the GUID into the header you name. On later runs with the same combination it returns the stored GUID. Stored mappings expire after the Expiration Period; after that, a new ID is generated even for a known combination.
| Parameter | What it means | Contoso setting |
|---|---|---|
| Source Message ID | The value that identifies the inbound message; can be read from a header or property | ${property.interchangeId} |
| Target Header Name | Header that receives the generated target ID | SapMessageId |
| Context | What the target ID is generated for, typically the receiver; must start with a letter | S4_ORDERS |
| Visibility | Global (shared by all flows on the tenant) or Integration Flow (local) | Integration Flow |
| Expiration Period (in d) | Days until the stored mapping is deleted; default 30 | 30, longer than any retry window |
ID Mapping step parameters as documented by SAP, with Contoso's settings for the inbound order flow.
Choosing the source ID: transmission or business document?
The source ID decides what counts as "the same message". SAP's example uses a purchase order number, so a receiver processes messages for the same PO only once. That is right when the business really wants one message per PO. It is dangerous when a partner can send a legitimate second message for the same PO, such as a change. For Great Lakes' inbound orders, Contoso uses the interchange control number as the source ID, which identifies a transmission: a resent file is caught, a new order for the same PO number is not. Decide this with Maria, not only with the developer.
Split and multicast messages
When a splitter turns one message into several, each split needs its own target ID. SAP's example sets the context per split from the header CamelSplitIndex, with a prefix because the context must start with a letter: SplitIndex_${header.CamelSplitIndex}. If a flow has two split-and-map sequences, SAP recommends a distinct prefix per sequence (for example Mapper1_SplitIndex_…) to avoid collisions. The same idea applies to multicast: one source ID, one context per branch. Note that the split index is only stable if the splitter runs sequentially.
The IDoc receiver's built-in option
The IDoc receiver adapter offers the same idea without an extra step. Its SAP Message ID Determination can be Generate, Reuse (default: take SapMessageId if present) or Map, which maps a source ID from a header or property to a new GUID. SAP notes that mapping entries for this option are deleted after 90 days and that only the first 120 characters of the source ID are considered. Exactly-once processing in the backend also needs the content type Application/x-sap.idoc.
What ID mapping doesn't do
ID mapping is a technical tool for recognizing the same transmission. It doesn't decide whether two different orders are business duplicates. That check belongs in the application: in sales, the sales document type can check the customer's purchase order number and warn when the same number is used again for the customer. Contoso uses both layers: ID mapping catches a resent file before it reaches S/4HANA, and the sales check catches a customer sending a new file for an order it already sent. Testing must cover both, with Maria deciding how a business duplicate should be handled.
Mapping partner identifiers
A related task is translating a partner's external identifier into the partner as Cloud Integration knows it. Don't use a value mapping for that. The Partner Directory keeps alternative partners: an agency, a scheme and the external ID point to one partner ID. A script finds it with getPartnerId(agency, scheme, alternativePartnerId) on the PartnerDirectoryService, and the flow then reads that partner's parameters. sap-pim-205 uses this for Great Lakes' and Lakeside's EDI identifiers.
What would you do?
Great Lakes' EDI provider resends an entire day of 850 files after an outage on their side. Some files were already processed by Contoso. Maria asks whether duplicate sales orders will be created.
| Need | Use | Why |
|---|---|---|
| Translate a code (PCE to EA) | Value mapping | Bidirectional code list, maintained by the business |
| Give a message a stable identity for duplicate detection | ID Mapping step or IDoc receiver Map option | Same source ID and context always yield the same target ID |
| Find the partner behind an external ID | Partner Directory alternative partners | Agency, scheme and external ID resolve to a partner ID with its parameters |
- The ID Mapping step returns the same target ID for the same source ID and context, until the expiration period ends (default 30 days).
- The source ID defines what counts as a duplicate: a transmission or a business document. Decide with the business.
- For splits and multicasts, give each target its own context, such as SplitIndex_${header.CamelSplitIndex}.
- Partner identifiers are resolved with Partner Directory alternative partners, not value mappings.
Check your understanding · not graded
Lesson check
1. What does the ID Mapping step return when the same source ID and context arrive again within the expiration period?
2. Why does SAP's split example set the context to <code>SplitIndex_${header.CamelSplitIndex}</code> instead of the index alone?
3. Using the PO number as source ID causes a problem for Great Lakes. Which one?
4. Which tool resolves Lakeside's external EDI identifier to its partner entry?