ABAP Cloud ... ohne BTP?
In diesem Artikel gehen wir der Frage nach, ob ABAP Cloud auch ohne BTP möglich ist und was du dabei beachten solltest.
Inhaltsverzeichnis
Dieser Artikel wurde inspiriert durch Michael Keller mit der Idee, ABAP Cloud nur On-Premise zu verwenden. Möchtest du mehr von Michael lesen, findest du zum Abschluss des Artikels weiteres Material.
Einleitung
In diesem Artikel möchten wir einmal auf die Frage eingehen: Können wir Clean Core werden, wenn wir alle unsere Erweiterungen mit ABAP Cloud On-Stack umsetzen? Dabei werden wir uns verschiedene Aspekte der Entwicklung anschauen, was damit schon sehr gut funktioniert und was du aktuell nicht verwenden kannst.
ABAP Cloud ist das Entwicklungsmodell um Clean Core und Cloud Ready zu implementieren. In diesem Artikel werden wir uns auf das Thema Clean Core fokussieren, da wir davon ausgehen, dass wir ein Unternehmen sind, welches seine Prozesse nicht in die Public Cloud bringen kann (Anforderung) oder möchte (Kosten). Dabei werden wir auf die Verwendung in die Architektur eingehen.
Seit langer Zeit steht die Aussage im Raum, dass wir nur Clean Core werden können, wenn wir unsere Erweiterungen außerhalb des Systems durchführen und das Core-System nicht verändern. Dazu wurde auch die BTP zur Verfügung gestellt, die verschiedene Services zur Verfügung stellt, um die Erweiterungen Side-by-Side zu erstellen. Seit der Einführung von ABAP Cloud ist das aber nicht mehr der Fall, die BTP ist in vielen Szenarien optional.
Voraussetzung
Um mit Clean Core richtig starten zu können, benötigst du ein S/4HANA 2023 Release, da hier ABAP Cloud sehr gut unterstützt wird. Aktuell gibt es in im 2022er Release zu viele Gaps und Funktionen, die nicht verfügbar sind, daher empfehlen wir den vollständigen Einstieg ab einem 2023 Release. Ab diesem Release stehen auch sehr viele Features in RAP zur Verfügung, was die Entwicklung von RAP basierten Anwendungen erleichtert. Ab dem Release 2025 kommen sogar noch einige Funktionen mehr dazu, wie die editierbaren Bäume, sehr wahrscheinlich auch die Analytical Table (Ersatz für ALV) und in der Private Cloud auch Joule for Developers.
Umsetzung
In diesem Kapitel schauen wir uns die Umsetzung von ABAP Cloud an, die Vorbereitung zur Einführung und die Entwicklung mit der Key User und On-Stack Extensiblity.
Foto von Oscar Nilsson auf Unsplash
Konfiguration
Gehen wir also im nächsten Schritt davon aus, dass du dir die Optionen offenhalten möchtest, später einmal einige der Anwendungen in das ABAP Environment zu migrieren, dann solltest du eine gewisse Architektur bei der Erstellung von Software Komponenten einhalten. Du solltest mehrere SWCs anlegen und auf die Trennung untereinander achten. Dadurch stellst du sicher, dass einzelne Komponenten einfach ins ABAP Environment migrierbar sind. Wieso eigentlich ABAP Environment? Auf diesem kannst du deinen ABAP Code weiter betreiben und musst nicht die Programmiersprache wechseln, wie zum Beispiel bei CAP.
Wie du ABAP Cloud im System zur Verfügung stellst und die ersten Schritte machst, findest du bei uns in der Checkliste.
Erweiterung
Im ersten Schritt würdest du immer prüfen, ob du zuerst dein System über die Key User Extensibility erweitern kannst. Diese Möglichkeit gibt es auch in der Public Cloud und unterstützt viele der Szenarien zur Erweiterung eines Systems. Alle Erweiterungen, die du damit erstellst, sind allerdings nicht verschiebbar in die BTP, solche Erweiterungen gelten als eng gekoppelt und bleiben immer auf dem Core-System.
Alle klassischen Erweiterungstechniken solltest du nicht mehr verwenden, egal ob Modifikation, Enhancement (Explizit oder Implizit) oder Userexit, diese sind mittlerweile obsolet. Hier solltest du nach Standard BADIs suchen, die am besten ABAP Cloud freigegeben sind. Dies wird nach aktuellem Stand in den Randmodulen eher selten der Fall sein, trotzdem kannst du auch ein klassisches BADI sauber implementieren. Diese Form der Erweiterung bleibt in Zukunft ebenfalls auf dem System.
Eigenentwicklung
Die Erstellung eigener Datenmodelle und Anwendungen würdest du über Software Komponenten erledigen. Eine Software Komponente in ABAP Cloud gibt automatisch die Regeln vor, was du an Technologie und APIs im System nutzen kannst. Damit hast du Leitplanken für die Entwicklung von ABAP Cloud kompatiblen Anwendungen und kannst hier wenig falsch machen. Konzepte wie RAP Anwendungen, Application Jobs und Business Configuration sind hier bereits vorgegeben und bereits etabliert. Application Jobs können aktuell bereits On-Premise genutzt werden, aber erst mit Version 2 werden diese sehr gut nutzbar und die aktuellen Kinderkrankheiten behoben. Diese Neuerungen werden mit dem Release 2025 zur Verfügung stehen.
Verwendest du Funktionen aus dem Standard, solltest du darauf achten freigegebene APIs zu nutzen, aber auch APIs in Wrapper zu packen die Sinn machen.
Herausforderungen
In diesem Kapitel schauen wir uns verschiedene Herausforderungen an und wie du sie angehen kannst, um auch On-Premise fit für die BTP zu sein.
Foto von Alicia Christin Gerald auf Unsplash
Verfügbare APIs
Je nach Modul kann die Verfügbarkeit von APIs vor allem am Anfang recht ernüchternd wirken. Vor allem wenn im Bereich der Erweiterungen nicht der passende BADI in einer ABAP Cloud kompatiblen Form zur Verfügung steht. Hier solltest du im ersten Schritt prüfen, ob es nicht schon ein cloudkompatiblen Nachfolger gibt und das Modul damit ein Auslaufmodell ist. Ist dies nicht der Fall und einzelne Bestandteile stehen bereits mit Core Data Services und Fiori Anwendungen zur Verfügung kannst du mit der Modernisierung weitermachen.
Wrapper
Wrapper sind ein zentraler Bestandteil, wenn nicht alle APIs zur Verfügung stehen, du aber viele Bestandteile in ABAP Cloud umsetzen möchtest. Dazu musst du passenden Objekte des Standards verwenden und passende Wrapper zur Verfügung stellen. Für BAPIs kannst du zum Beispiel über die Transaktion ACO_PROXY einen Wrapper generieren lassen, wenn die passenden Hinweise im System eingespielt wurden. Hier eignen sich BAPIs, Klassen, Core Data Services und Tabellen, um die passenden Funktionen für TIER-1 freizugeben.
Empfehlung unsererseits ist eine enge Abstimmung in den Entwicklungsteams, damit Wrapper nur einmal erstellt werden, diese aber auch gewisse Qualitäten haben, wie Testbarkeit, Wiederverwendbarkeit und Kapselung. Damit können wichtige APIs direkt zu Anfang eines Projekts zur Verfügung gestellt werden, um die Entwicklung zu unterstützen. Ist kein Datenmodell in CDS verfügbar, ist die Empfehlung ein Datenmodell anzulegen und zentral zu nutzen.
Dateizugriff
Verwendest du noch Dateischnittstellen, dann kannst du dies erst einmal weiterhin machen, allerdings solltest du alle Zugriffe auf Lokale- oder Remotedateien in ABAP Klassen als eigene APIs in TIER-2 abbilden. Bei einer späteren Migration kannst du den Wrapper leicht austauschen, vor allem wenn du Richtung Cloud umziehst und Zugriffe auf das Dateisystem nicht mehr möglich sind. Anstatt eines OPEN DATASET, kann dann zum Beispiel ein Aufruf eines HTTP API passieren, um die Datei zum Beispiel aus dem Document Management oder über einen anderen Weg zu lesen.
Damit liefert die Klasse/API am Ende den Dateistream, egal welche Technologie im Hintergrund genutzt wird oder woher die Daten gelesen werden müssen. Für den Übergang in die neue Welt ist die Entkopplung der Technologie perfekt.
Workflow
Aktuell sind On-Premise Workflows nicht mehr Clean Core, da die Modellierung über die SAP GUI erfolgt und ebenso viele Interaktionen aktuell dort stattfinden. Die Nachfolgelösung der SAP heißt hier SAP Build Process Automation. Da wir allerdings erst einmal auf Workflows verzichten wollen, da wir alles On-Premise machen, solltest du einen Wrapper schreiben, um zum Beispiel Workflows zu starten oder Informationen zu erhalten.
Ähnlich wie beim Dateizugriff bringt dir der entkoppelte Aufruf erst einmal die Freiheit verschiedene Technologien im Hintergrund zu verwenden. Die Klasse soll einen Workflow starten, eine Aufgabe in den nächsten Status setzen und Workflows beenden, dabei sollte die Technologie im Hintergrund keine Rolle spielen.
Schnittstellen
Etwas komplizierter wird es dann aber bei Schnittstellen für Daten, vor allem im Fall der Modellierung in RAP Objekten. Erstellst du aktuelle Apps, wo du auf Assoziationen zum Standard setzt oder sogar die ganze Anwendung auf Core Data Services des Standards setzt, dann wird ein Verschieben in die BTP nicht ganz so einfach werden. Aktuell gibt es hier nur die Lösung mit der Verwendung einer Custom Entity, damit muss allerdings die Anwendung neugestaltet werden.
Sind die eingebundenen Core Data Services vor allem als Wertehilfen geplant, dann können diese auch per Custom Entity abgebildet werden und der Umstellungsaufwand ist nicht ganz so groß. Das betrifft vor allem Anwendungen, die ein eigenes Datenmodell haben.
Der Zugriff auf Daten im Standard ist im gleichen System recht einfach umsetzbar, allerdings erwachsen hier bei einem Umzug auf Side-by-Side die größten Herausforderungen. External Entities können hier in Zukunft sicherlich die Zugriffe vereinfachen und Umstellungen vermeiden, im aktuellen Zustand kannst du sie dafür aber noch nicht einsetzen.
Fazit
Grundsätzlich kannst du bereits heute mit ABAP Cloud deine Erweiterungen im System umsetzen und benötigst dafür keine BTP. Das spart aktuell einiges an Kosten, es können aber dann auch nicht alle Freiheiten genossen werden, auch die verschiedenen Cloud Services zu konsumieren. Du brauchst hier allerdings auch ein aktuelles Release, um mit Clean Core zu starten.
Weitere Inspiration:
Michael Keller Blog (SAP, Well Organized, usw.)
