ABAP Cloud-Tier-Konzepte in S/4
SAP teilt die ABAP-Welt in S/4HANA in drei Cloud-Tiers – Cloud-Ready (Released APIs only), Cloud-Compliant (mit Übergangs-Regeln) und Classic ABAP. Welcher Tier für welche Erweiterung passt, hängt nicht nur von der Technik ab, sondern auch vom S/4-Edition-Kontext (RISE, Private Cloud, On-Prem) und vom Lifecycle-Anspruch. Wir machen die Tier-Wahl strukturiert, nicht aus dem Bauchgefühl.
Die drei Tiers in einer Sentence
Mit ABAP Cloud führt SAP eine Tier-Struktur ein, die nicht nur in ABAP Steampunk (BTP) gilt, sondern auch innerhalb S/4HANA:
- Cloud-Ready ABAP – nur Released APIs erlaubt, kein direkter Zugriff auf Standard-Tabellen, kein Modify. Die strenge Disziplin. Erweiterungen die hier laufen, überleben S/4-Upgrades ohne Anpassung.
- Cloud-Compliant ABAP – Übergangs-Tier mit Sondergenehmigungen. Bestehender Custom-Code kann hier weiter leben, muss aber dokumentiert sein und einen Migrationspfad nach Cloud-Ready haben.
- Classic ABAP – die alte Welt mit allen Freiheiten. Direktzugriffe, Modify, beliebige FBAs. Nur noch in Bestandscustomer-Umgebungen, mit klarem Ablöse-Plan.
Die Tiers sind nicht über alle S/4-Editions gleich verfügbar:
| Edition | Cloud-Ready | Cloud-Compliant | Classic |
|---|---|---|---|
| S/4HANA Cloud Public | erzwungen | – | – |
| S/4HANA Cloud Private (RISE) | empfohlen | erlaubt | nur Bestand |
| S/4HANA On-Premise | empfohlen | erlaubt | erlaubt |
Wer auf Cloud Public unterwegs ist, hat die Wahl nicht – Cloud-Ready ist Pflicht. Wer auf RISE oder On-Prem ist, hat Spielraum, aber jeder Schritt Richtung Cloud-Ready ist eine Investition in Upgrade-Schmerzlosigkeit.
Die Wahl pro Erweiterung
Wir treffen die Tier-Wahl für jede neue Erweiterung bewusst. Die Logik:
Cloud-Ready, wenn …
- Die Erweiterung ein langes Leben haben soll (≥ 5 Jahre)
- Upgrade-Schmerzfreiheit wichtiger ist als ABAP-Bequemlichkeit
- Das Team auf die Released-API-Disziplin eingeschwenkt ist
- Sie auf Cloud Public sind (dann ist es Pflicht)
Cloud-Compliant, wenn …
- Eine kurzfristig nötige Erweiterung im Bestand-Umfeld lebt
- Migration nach Cloud-Ready in der Roadmap, aber noch nicht jetzt
- Bestehende BAdI/Enhancement-Lösungen weiterleben müssen
- Sie auf RISE oder On-Prem sind
Classic ABAP, wenn …
- Erweiterung wird mit Sicherheit innerhalb 1-2 Jahren abgelöst
- Bestandscode-Pflege ohne Ablöse-Anspruch
- Sie ausschliesslich auf On-Prem unterwegs sind und keine Cloud- Migration planen
Diese Fragen klären wir pro Erweiterung mit einem Architektur-Review (30 Min).
Übergangspfade
Wer heute Classic ABAP hat und Richtung Cloud-Ready will, hat einen mehrstufigen Pfad:
- ATC mit Released-API-Regelsatz aktivieren – als Inventur, noch nicht erzwingend. Findings landen im Backlog.
- Neuentwicklungen sofort Cloud-Compliant – alle neuen BAdIs / RAP-Apps folgen den Cloud-Compliant-Regeln.
- Tier-1-Findings im Bestand schrittweise sanieren – typischerweise direkte Standard-Tabellen-Zugriffe durch Released CDS-Views ersetzen.
- Cloud-Ready als Ziel-Tier für ein Modul oder einen Paket- Bereich ausrufen – sobald ATC sauber, ist der Tier-Wechsel konfigurations-Sache.
Dieser Übergang läuft in Quartalen, nicht in Wochen. Wir planen ihn parallel zum Custom-Code-Cleanup-Backlog.
Trade-offs ehrlich genannt
Cloud-Ready hat Schmerzen:
- Released-API-Lücken – manche Standard-Funktionen sind noch nicht als Released API verfügbar. Wir müssen dann Side-by-Side umweg über BTP nehmen oder auf SAP-API-Release warten.
- Performance – ein CDS-View statt direkt Standard-Tabellen- SELECT kann manchmal langsamer sein, wenn die View-Schicht eine Aggregation einbezieht. Performance-Tests sind Pflicht.
- Team-Disziplin – Cloud-Ready erzwingt eine Arbeits-Weise, die klassische ABAP-Entwickler erst lernen müssen. Onboarding ist Teil der Tier-Wahl.
Wir benennen diese Schmerzen früh – Cloud-Ready ist kein Selbstläufer.
