Infrastructure architecture
PreferredMDG DRF → CPI → Azure landing
Preferred FoolproofDefault Path A when MDG is live — no native DRF→ADLS sink; Azure auth lives in BTP.
Architecture diagram
Default route: MDG → DRF → CPI iFlow → Azure landing API → ADLS2
Data or evidenceIdentity or control
Callout 1
MDG hub
BP, Material, and more
Governed master data activation in MDG. Separate object tests for BP vs Material.
Need this architecture for your internal review?
Request an editable .drawio source stencil for internal architecture validation.
Detail
There is no generic native DRF-to-ADLS sink. The bridge exists because it provides authenticable, testable hops with clear support boundaries.
CPI may write via HTTP adapter conditionally — validate adapter version, HNS, token audience, and failure modes for your BTP plan.
- SAP→BTP: certificate-based sender auth preferred
- BTP→Azure: OAuth client credentials with rotation/expiry tests
- Azure writer→storage: managed identity only
- Evidence API must never accept business payloads
| Scenario | Status | Note |
|---|---|---|
| S/4 with MDG + Integration Suite | Conditional | Configure DRF + iFlow; do not invent Azure DRF add-on. |
| ECC without MDG | Not supported | Use FILE Path B instead. |
| Native DRF→ADLS | Excluded | Whiteboard fiction — not a supported path. |
- Duplicate / out-of-order messages recovered without loss
- Expired BTP credential does not silently drop activations
- Blocked Azure endpoint: durable retry with clear diagnostics