Lesson 2 of 5
Master data flows
10 min
Listen to this lesson
Once ownership is clear, master data has to reach every system that needs it, in the right shape, with the right keys, at the right time. Master data flow design covers how records are governed, how they are distributed, how identifiers are mapped and how conflicts are prevented.
Governance styles
| Style | How it works | Fits when | Contoso use |
|---|---|---|---|
| Central governance | Records are created and changed in one governed place, with workflow and validation, then distributed | Several systems need consistent master data and quality matters | Business partners and materials, governed in S/4HANA |
| Consolidation | Records from several sources are matched, de-duplicated and merged into best records | Mergers, acquisitions, data cleansing | Wave 2 customers matched against existing Contoso customers before load |
| Decentralized with rules | Each system maintains its own data under agreed standards | Low overlap between systems | Portal user preferences |
SAP's own documentation draws a useful line between governance and integration. It describes SAP Master Data Integration as a central master data hub focused exclusively on the integration aspect: initial loads and then keeping applications in sync, with control over which data goes where. Consolidation, data quality control and central governance are explicitly out of its scope and are handled by SAP Master Data Governance. Keep that separation in your own design: one capability decides what the right record is; another moves it.
Distribution patterns
| Pattern | Typical SAP technology | Strengths | Watch for |
|---|---|---|---|
| Message-based replication | IDocs (for example customer, supplier and material master messages) or SOAP services | Proven, asynchronous, monitorable per message | Mapping drift, error queues nobody watches |
| Hub-based replication | SAP Master Data Integration with the SAP One Domain Model | Common model, central distribution models and filters | Supported objects only; check coverage for each domain |
| API on demand | OData or REST read of the record when needed | Always current, no copy to manage | Availability and performance coupling |
| Bulk load | Files or migration tools for initial loads | Fast for volume | Only for initial or periodic loads, not daily change |
Master data distribution patterns. Many landscapes use more than one.
SAP Master Data Integration's documentation describes distribution models with two kinds of filters: object selection filters decide which records go to a consumer, and data scope filters decide which parts of a record go. Its example is intuitive: a production application does not need customers, and a U.S. sales organization does not need European customer sales data. Whatever your technology, design the same two filters for every flow: which records, and which fields.
Keys and identifiers
The same customer often has different numbers in different systems. A robust design keeps a key mapping: a cross-reference between global and local identifiers that every flow uses. SAP Master Data Integration stores ID maps between global and local IDs and offers lookups in both directions. In Contoso's Wave 2, the Alternadores legacy customer number is kept as a reference in the new business partner so that open items, documents and reconciliation can be traced back.
- RequestMaria's team requests a new fleet customer; the portal can submit the request
- GovernS/4HANA business partner maintenance with validation, duplicate check and approval
- Map keysThe business partner number is linked to portal and MES identifiers
- DistributeFiltered replication: the portal gets sales data; MES gets nothing; the warehouse gets all
- ConfirmEach receiver confirms; errors land in a monitored queue with an owner
In S/4HANA itself, the business partner is the single point of entry for customers and suppliers: customer and supplier data are maintained through business partner roles and synchronized with the customer and supplier records that processes use. For flows to and from other systems, that means one object to govern and replicate, but also that receivers built for classic customer or supplier messages need their mappings checked whenever business partner fields or roles change.
What would you do?
For Wave 2, the data team finds that 230 of Alternadores' customers are also existing Contoso customers under different numbers. What should the master data design do?
- Separate governance (what the right record is) from integration (moving it).
- Choose distribution patterns per flow: messages, hub, API on demand or bulk loads.
- Design filters for which records and which fields each receiver gets.
- Maintain key mapping between systems; keep flows one-way from the owner.
Check your understanding · not graded
Lesson check
1. According to SAP's documentation, which processes are outside the scope of SAP Master Data Integration?
2. What does a data scope filter control?
3. Why maintain key mapping between systems?
4. What is the safest default direction for a master data flow?