Indu Learning Platform
Course/Unit 1 · MDG from the engine room
Lesson 1-1

Hub, co-deployed and the two areas

Where MDG runs, how data moves from the staging area to the active area, and why reuse and flex mode change what a developer has to touch.

Watch firstWhat Is SAP MDG? · SAP PRESSOpen on YouTube ↗

Same system, one level down

A functional consultant sees MDG through its screens. A technical consultant sees storage, generated objects, framework classes and enhancement spots. Most hard tickets are storage or code-path questions: "the approver sees the new address, the sales order doesn't" is staging versus active. Name the layer first, then you know which log, table or BAdI to open.

UI layerFiori / FPM Web Dynpro appsGovernance layerChange requests, workflow, BRFplusStaging areagenerated /1MD/ tablesActive areaMARA, BUT000 … or generated tablesDistribution layerDRF, key & value mapping
Edit in the UI, govern the draft, activate, then distribute.

Hub versus co-deployed

MDG is an application inside S/4HANA; the question is which S/4HANA. A hub runs in its own instance, holds the golden record and replicates to every receiver, so many incidents are replication incidents. Co-deployed MDG runs in the system that uses the data: activation writes straight into the operational tables, and incidents lean towards locking and timing.

S/4HANA FinanceIDoc / SOAPECC plantsIDocCRMSOAPAribavia integrationData lakeextractLegacy WMSIDocMDG hub (S/4HANA)
One golden record, replicated to each receiver through DRF.

Choosing a deployment

Real projects are often mixed. Use this as a starting point, and write down your reason.

SituationLeans towardsWhyMany ERPs and non-SAP receiversHubOne golden record, many targetsOne S/4HANA, few receiversCo-deployedNo self-replication neededSeparate governance teamHubOwn release cycle and authorizationsTight budget, fast go-liveCo-deployedOne system to run and patchMixed: BP central, finance localBothHub for BP, co-deployed for 0G
No row is a rule.

Staging area and active area

Every change request writes to the staging area first: tables MDG generates from the data model in the /1MD/ namespace. Operational programs never read staging. Activation re-runs the checks, copies the record to the active area and only then starts replication. That is why a draft can be rejected twice without touching production data.

Step through · 1 of 6
Requester editsFiori / FPM UIStaging area/1MD/ tablesChecks & approvalsBRFplus, BAdIsActivationsystem stepActive areaBUT000, LFA1 …ReplicationDRF
The requester creates a supplier. The UI writes through the MDG framework, never straight to the database.
Click through one supplier change request.

Try it: one supplier change, end to end

Try it · Put in order

Put the life of a supplier change in a hub into the right order.

  1. 1Approver approves the change request
  2. 2A CREMAS IDoc is sent to the legacy AP system
  3. 3Activation writes the supplier to LFA1 / BUT000
  4. 4DRF picks the receivers and applies filters
  5. 5Requester saves the draft in a change request

Try it: the old address in the payment run

Try it · What would you do?

Co-deployed MDG. On Monday the buyer sees a new remit-to address in the supplier's change request. Tuesday's payment run still uses the old address. Most likely cause?

Reuse mode and flex mode

Each entity type has an active area mode. Reuse mode writes into the existing S/4HANA tables through an access class that calls the application APIs, so standard checks apply (BP, supplier, material). Flex mode writes to tables MDG generates; custom objects and most of 0G use it, and reaching application tables such as CSKS needs replication, even into the same system.

Reuse active areaWrites to existing S/4 tables (BUT000,MARA)Access class calls application APIsStandard BP / material checks applyTypical for BP, customer, supplier,materialFlex modeWrites to tables MDG generates (/1MD/)You own the model and its tablesReaching S/4 tables needs replicationTypical for custom objects and most 0Gvs
Same governance process, different final storage.

Where a record lands

Typical reuse-mode targets. Field mapping lives in the data model's mapping configuration; always check your system.

MDG entity (reuse)S/4HANA tableBP_HEADERBP_CENTRLADDRESSBP_BKDTLMATERIALMARCBASICBUT000BUT020 / ADRCBUT0BKMARAMARCBP keycentral dataaddressbank detailsclient levelplant level
Illustrative entity names. Check yours before quoting them.

Try it: reuse or flex?

Try it · Sort

Sort each statement into the active area mode it describes.

Reuse mode
Flex mode
Click an item, then a bucket (or drag it).

Give the assistant the architecture

Assistants answer far better when you state the architecture facts instead of letting them guess. Keep a short context block per project.

text
You are helping me debug SAP MDG on S/4HANA [release].
Deployment: hub. MDG system [MDH] replicates to [S4P, ECC1, CRM].
Data model: BP (reuse mode). Custom flex entity ZZ_CERT.
Facts:
- Change request data lives in staging until activation.
- Activation writes BP data to BUT000 / LFA1 via the access class.
- After activation, DRF replicates with IDoc CREMAS and BP SOAP services.
Question: a supplier CR is in status "Final check to be performed"
but the buyer already sees the new bank account in [S4P].
List likely causes in order and the transaction or log to check each.

Replace the bracketed parts with your project facts.

Remember

  • Hub means govern centrally and replicate out; co-deployed means govern where the data is used.
  • Staging holds unapproved data in generated /1MD/ tables; only activation writes to the active area.
  • Reuse mode writes to S/4 application tables via an access class; flex mode writes to tables MDG generates.

Check yourself

A change request was approved at step 2 but not yet activated. Where is the data?
Which mode writes material changes straight into MARA on activation?
In a hub landscape, the most common class of incident after activation succeeded is…
A custom flex-mode entity must also appear in an S/4HANA application table. What moves it there?