ABAP Cloud API-Freigabeverträge verstehen

Das ABAP Cloud Programmiermodell verändert grundlegend, wie Entwickler mit SAP-Standardfunktionalität interagieren. Anders als im klassischen ABAP, wo praktisch jedes Objekt zugänglich war, beschränkt ABAP Cloud den Zugriff auf explizit freigegebene APIs. Das Verständnis dessen, was dies bedeutet, wie das Freigabesystem funktioniert und wie man effektiv darin arbeitet, ist für jeden unerlässlich, der in modernen SAP-Umgebungen entwickelt.

Diese vertiefende Betrachtung untersucht das API-Freigabevertragssystem, das der Clean Core-Entwicklung zugrunde liegt, und erklärt nicht nur, was Sie nutzen können und was nicht, sondern auch warum diese Einschränkungen existieren und wie sie letztendlich Ihren Entwicklungsbemühungen zugutekommen.

Die Philosophie hinter freigegebenen APIs

Um effektiv mit freigegebenen APIs zu arbeiten, hilft es, die Begründung hinter diesem Ansatz zu verstehen.

Das Problem mit uneingeschränktem Zugriff

Im klassischen ABAP konnten Entwickler auf praktisch jedes SAP-Objekt zugreifen - Datenbanktabellen, Funktionsbausteine, Klassen, sogar interne Datenstrukturen. Während diese Flexibilität mächtige Anpassungen ermöglichte, schuf sie erhebliche Probleme. Die Upgrade-Fragilität bedeutete, dass SAP interne Strukturen nicht sicher modifizieren konnte, ohne potenziell Kundencode zu brechen. Unvorhersagbares Verhalten konnte auftreten, da interne APIs sich anders als erwartet verhalten könnten, wenn sie außerhalb ihres Kontextes aufgerufen werden. Sicherheitsrisiken entstanden durch direkten Zugriff auf interne Strukturen, der Sicherheitskontrollen umgehen konnte. Und Support-Herausforderungen bedeuteten, dass SAP kundenspezifischen Code, der interne APIs nutzte, nicht unterstützen konnte.

Die vertragsbasierte Lösung

Das Modell freigegebener APIs adressiert diese Probleme durch explizite Verträge. SAP verpflichtet sich, freigegebene APIs gemäß definierten Stabilitätsgarantien zu pflegen. Kunden verpflichten sich, nur freigegebene APIs in ihren Erweiterungen zu nutzen. Beide Parteien profitieren von vorhersagbaren, stabilen Schnittstellen. Dieser Vertrag ermöglicht es SAP, seine Produkte weiterzuentwickeln und dabei Kundeninvestitionen zu schützen, und ermöglicht es Kunden, Erweiterungen zu bauen, die Upgrades ohne Modifikation überstehen.

Freigabestatus und ihre Bedeutung

APIs in SAP-Systemen haben unterschiedliche Freigabestatus, die ihre Verfügbarkeit und Stabilität anzeigen.

Freigegeben (C1-Vertrag)

Freigegebene APIs tragen SAPs stärkstes Commitment. Sie sind explizit dokumentiert und für die Kundennutzung unterstützt, abwärtskompatibel innerhalb einer Produktversion, Änderungen folgen definierten Deprecation-Policies, und sie sind für die Verwendung in ABAP Cloud-Entwicklung verfügbar. Wenn Sie eine als freigegeben markierte API sehen, können Sie sie vertrauensvoll nutzen in dem Wissen, dass SAP sich zu ihrer Stabilität verpflichtet hat.

Deprecated

Deprecated APIs sind noch verfügbar, aber zur Entfernung vorgesehen. Die Funktionalität bleibt im aktuellen Release verfügbar, kann aber in zukünftigen Releases entfernt werden. Ersatz-APIs sind typischerweise dokumentiert, und es sollte migriert werden, wenn möglich. Deprecation bietet eine Übergangszeit für die Migration zu Nachfolge-APIs.

Nicht freigegeben

APIs ohne Freigabestatus sind interne SAP-Objekte. Sie sind nur für SAP-interne Nutzung gedacht, können ohne Vorankündigung geändert oder entfernt werden, haben keine garantierte Abwärtskompatibilität und sind in ABAP Cloud Code nicht verfügbar. Die Verwendung nicht freigegebener APIs im klassischen ABAP schafft technische Schulden, die letztendlich adressiert werden müssen.

Typen freigegebener Objekte

SAP gibt verschiedene Typen von Objekten für die Kundennutzung frei.

Freigegebene CDS Views

CDS Views bieten Datenzugriff in ABAP Cloud. Interface Views mit dem Präfix I_ bieten grundlegenden Datenzugriff, Consumption Views mit dem Präfix C_ sind für spezifische Anwendungsfälle optimiert. Views exponieren geschäftsrelevante Daten durch stabile Feldnamen, und Zugriffskontrollen sind in das View-Design eingebaut. Zum Beispiel bietet I_BusinessPartner Zugriff auf Geschäftspartnerdaten mit stabiler Feldsemantik, unabhängig von Änderungen der zugrundeliegenden Tabellenstruktur.

Freigegebene APIs und BAPIs

Funktionsbausteine und APIs für Geschäftsoperationen umfassen freigegebene BAPIs, die Transaktionsausführungsfähigkeiten bieten, Wrapper-Klassen, die BAPI-Aufrufe in objektorientierte Schnittstellen kapseln, APIs, die Autorisierung und Konsistenzprüfungen handhaben, und Fehlerbehandlung, die dokumentierten Mustern folgt.

Freigegebene Klassen und Interfaces

Objektorientierte Komponenten für verschiedene Zwecke umfassen Utility-Klassen für gängige Operationen, Framework-Klassen für Standardmuster, Interfaces, die Erweiterungspunkte definieren, und Exception-Klassen für die Fehlerbehandlung.

Freigegebene BAdIs

Erweiterungspunkte zur Modifikation des Standardverhaltens umfassen freigegebene BAdIs, die stabile Erweiterungspunkte bieten, Interface-Verträge, die erwartete Implementierungen definieren, die Möglichkeit, dass mehrere Implementierungen koexistieren können, und filterbasierte Aktivierung, die kontrolliert, wann Implementierungen ausgeführt werden.

Freigegebene APIs finden

Das Auffinden der richtigen freigegebenen API ist eine entscheidende Entwicklungsfähigkeit.

Released Object Browser in ADT

Das primäre Werkzeug zum Finden freigegebener Objekte ist über das Windows-Menü, Show View, ABAP, Released Objects zugänglich. Sie können nach Softwarekomponente und Objekttyp durchsuchen, nach Name oder Beschreibung suchen und Freigabestatus sowie Dokumentation einsehen.

Suchstrategien

Effektive Suchansätze umfassen die Suche nach Geschäftsbegriff, um Objekte zu finden, die Geschäftskonzepten entsprechen, die Suche nach Tabellenname, wenn Sie die klassische Tabelle kennen und Views für diese Daten suchen, die Suche nach Funktion, um Objekte zu finden, die benötigte Funktionalität implementieren, und das Durchsuchen nach Komponente, um Objekte in relevanten Softwarekomponenten zu erkunden.

SAP-Dokumentation

Zusätzliche Dokumentationsquellen umfassen den SAP API Business Hub zum Durchsuchen verfügbarer APIs nach Domäne, das SAP Help Portal für Released API-Dokumentation, die Simplification Database zur Zuordnung deprecated zu Ersatzobjekten, und die SAP Community zur Diskussion von API-Nutzungsmustern.

Mit freigegebenen APIs arbeiten

Praktische Überlegungen für die effektive Nutzung freigegebener APIs.

API-Dokumentation verstehen

Freigegebene APIs enthalten Dokumentation, die Zweck und beabsichtigte Anwendungsfälle, Ein- und Ausgabeparameter, Rückgabewerte und Exceptions, Autorisierungsanforderungen und Performance-Überlegungen erklärt. Lesen Sie die Dokumentation sorgfältig, bevor Sie eine API verwenden. Der beabsichtigte Anwendungsfall ist wichtig - die Verwendung einer API für Zwecke außerhalb ihres Designs kann zu unerwarteten Ergebnissen führen.

Umgang mit API-Versionierung

Freigegebene APIs können mehrere Versionen haben. Neuere Versionen können erweiterte Funktionalität bieten, ältere Versionen bleiben während Deprecation-Perioden verfügbar. Wählen Sie die geeignete Version für Ihre Anforderungen und planen Sie die Migration, wenn Sie deprecated Versionen verwenden.

Fehlerbehandlungsmuster

Freigegebene APIs folgen konsistenten Fehlerbehandlungsmustern. Exceptions sind dokumentiert und freigegeben, Fehlermeldungen folgen Standardformaten, Rückgabestrukturen zeigen Erfolg oder Misserfolg an, und Fehler sollten gemäß API-Dokumentation behandelt werden.

Wenn freigegebene APIs unzureichend sind

Manchmal erfüllen freigegebene APIs die Anforderungen nicht. Das Verständnis Ihrer Optionen ist wichtig.

Die Lücke bewerten

Wenn Sie keine geeignete freigegebene API finden können, verifizieren Sie, dass Ihre Suche gründlich war, da APIs unerwartete Namen oder Orte haben können. Überlegen Sie, ob die Anforderung anders erfüllt werden kann. Prüfen Sie, ob kürzliche Releases benötigte APIs hinzugefügt haben. Bewerten Sie die Geschäftskritikalität der Anforderung.

API-Freigabe anfragen

Für wirklich fehlende APIs engagieren Sie sich mit SAP. Dokumentieren Sie die Geschäftsanforderung klar, identifizieren Sie die benötigten spezifischen Objekte, reichen Sie über SAP-Influence-Programme oder Kundenengagement-Kanäle ein. SAP gibt regelmäßig zusätzliche APIs basierend auf Kundenfeedback frei.

Alternative Ansätze

Erwägen Sie architektonische Alternativen. Side-by-Side-Erweiterung auf BTP kann bei Bedarf nicht freigegebene APIs via RFC aufrufen. Wrapper-Services können nicht freigegebene Aufrufe für potenzielle zukünftige Migration kapseln. Prozess-Redesign kann die Notwendigkeit für spezifischen API-Zugriff eliminieren. Drittanbieterlösungen können benötigte Funktionalität bieten.

Das Level-Konzept für Clean Core

SAP hat ein Level-Konzept eingeführt, um nuanciertere Anleitung zur API-Nutzung zu bieten.

Level A: Volle ABAP Cloud Compliance

Code auf Level A nutzt nur freigegebene APIs und folgt allen ABAP Cloud-Einschränkungen. Dies bedeutet maximale Zukunftskompatibilität, Bereitschaft für Cloud-Deployment, minimaler erwarteter Upgrade-Aufwand und ist der Zielzustand für Neuentwicklung.

Level B: Stabile klassische APIs

Level B Code nutzt klassische APIs, die stabil sind, aber nicht für ABAP Cloud freigegeben. APIs sind unwahrscheinlich, sich signifikant zu ändern, können aber kleinere Anpassungen während Upgrades erfordern. Dies ist angemessen für Funktionalität, die noch nicht in freigegebenen APIs verfügbar ist, und sollte zu Level A migriert werden, wenn möglich.

Level C: Unklassifizierte APIs

Level C Code nutzt APIs ohne Stabilitätsklassifizierung. Sie können sich zwischen Releases ändern, haben höheres Upgrade-Risiko, sollten ersetzt werden wenn Alternativen existieren und erfordern Aufmerksamkeit während der Upgrade-Planung.

Level D: Kein API (Direktzugriff)

Level D repräsentiert direkten Zugriff ohne jede API-Schicht. Direkter Datenbanktabellenzugriff, Modifikationen am Standardcode, höchstes Upgrade-Risiko machen dies zur Priorität für Remediation.

API-Lifecycle-Management

Das Verständnis, wie APIs sich entwickeln, hilft bei der Planung Ihrer Entwicklungsstrategie.

API-Einführung

Neue APIs werden durch SAP-Releases eingeführt. Überwachen Sie Release Notes für neue APIs, bewerten Sie neue APIs gegen aktuelle Workarounds, planen Sie die Adoption vorteilhafter neuer APIs und geben Sie SAP Feedback zu API-Lücken.

API-Deprecation

Wenn APIs deprecated werden, gibt SAP Vorankündigung (typischerweise mehrere Releases), Ersatz-APIs sind dokumentiert, deprecated APIs funktionieren während des Übergangs weiter, und ATC-Prüfungen markieren deprecated API-Nutzung.

Aktuell bleiben

Halten Sie ein Bewusstsein für API-Änderungen aufrecht, indem Sie SAP Release Notes regelmäßig reviewen, ATC-Prüfungen ausführen, um deprecated Nutzung zu identifizieren, API-Migration als Teil der Wartung planen und an SAP Early Adopter-Programmen für Vorankündigung teilnehmen.

Eine API-First-Entwicklungskultur aufbauen

Erfolg mit freigegebenen APIs erfordert organisatorisches Commitment.

Entwicklungsstandards

Etablieren Sie Standards, die freigegebene APIs priorisieren. Mandatieren Sie die Nutzung freigegebener APIs für neue ABAP Cloud-Entwicklung, fordern Sie Dokumentation wenn keine freigegebene API existiert, etablieren Sie einen Genehmigungsprozess für die Nutzung nicht freigegebener APIs und verfolgen und berichten Sie über API-Compliance-Metriken.

Wissensaustausch

Bauen Sie organisatorisches Wissen über freigegebene APIs auf durch Dokumentation von Mustern für gängige Aufgaben, Teilen erfolgreicher API-Nutzungsbeispiele, Pflege eines Katalogs häufig genutzter APIs und Durchführung von Trainings zur API-Entdeckung und -Nutzung.

Fazit

Das Modell freigegebener APIs repräsentiert einen fundamentalen Wandel in der SAP-Entwicklungsphilosophie - von "alles ist möglich" zu "alles wird unterstützt". Während dies initial einschränkend wirken mag, bietet es letztendlich erhebliche Vorteile: vorhersagbares Upgrade-Verhalten, unterstützte Funktionalität und nachhaltige Erweiterungen.

Erfolg mit freigegebenen APIs erfordert Investition in das Verständnis der verfügbaren APIs, die Entwicklung von Fähigkeiten in der API-Entdeckung und den Aufbau organisatorischer Praktiken, die API-Compliance priorisieren. Die Investition zahlt sich durch reduzierte Wartungskosten, reibungslosere Upgrades und Erweiterungen aus, die über die Evolution von SAP hinweg funktional bleiben. Für Organisationen, die sich Clean Core verpflichtet haben, ist die Beherrschung des Modells freigegebener APIs nicht optional - es ist das Fundament, auf dem nachhaltige SAP-Entwicklung aufgebaut wird.