ABAP Cloud - 3-TIER Modell

Inhaltsverzeichnis

• Einleitung
• Software Komponenten
• Anlage
• Gemeinsamkeiten
• Unterschiede
• Modell
• Legende
• TIER-3 - Classic ABAP
• TIER-2 - API Layer
• TIER-1 - ABAP Cloud
• Gesamt
• Freigabe
• Berechtigung
• Fazit

Das 3-TIER Model ist ein wichtiger Baustein in der Umsetzung von ABAP Cloud. In diesem Artikel werden wir etwas näher auf die Struktur und den Aufbau eingehen. Die Umsetzung der Struktur kann von Kunde zu Kunde unterschiedlich sein, deshalb hier einmal ein Beispiel, wie wir es aktuell bei uns umsetzen.

 

Einleitung

Das 3-TIER Model soll den Übergang von Classic ABAP Richtung ABAP Cloud ermöglichen, da fast kein Kunde mit seinen Prozessen direkt und nur in ABAP Cloud starten wird. ABAP Cloud gibt vor allem SAP einen Überblick, wie Kunden das System nutzen und welche ABAP APIs noch benötigt werden, damit Clean Core umgesetzt werden kann. Die Einteilung in die drei TIERs:

• TIER-1 = ABAP Cloud (only)
• TIER-2 = APIs die wir benötigen und ein TODO für SAP
• TIER-3 = Unsere Aufgabe, die Objekte modernisieren und nach TIER-1 überführen

 

Software Komponenten

Im Artikel letzte Woche haben wir die Software Komponenten beschrieben und wie sie im ABAP Environment funktionieren. Das Konzept der Software Komponenten wird in ABAP Cloud ebenfalls eingesetzt, um die verschärften ABAP Cloud Regeln auf die Objekte anzuwenden und sich von den nicht Clean Core Komponenten zu trennen. 

 

Anlage

Anders als bei den Software Komponenten im ABAP Environment, erfolgt die Anlage einer neuen Komponenten über den Report RSMAINTAIN_SWCOMPONENTS im System. Hier wird es wahrscheinlich später einmal eine Lösung per Fiori App oder ADT View geben. Den Report starten wir einmal über die ABAP Development Tools direkt.

 

Wir erhalten direkt eine Liste aller Software Komponenten des Systems. Im unteren Teil der Liste finden wir die Z* Komponenten, die relevant für unsere Entwicklung sind. Über den "+" Button können wir eine neue Komponente erstellen.

 

 

In dem nächsten Popup können wir nun die Informationen zur Software Komponente eintragen, die im Anschluss im System angelegt wird und verwendet werden kann.

 

Die einzelnen Punkte kurz erklärt:

• Component - ID der anzulegenden Software Komponente im System, die ID muss eindeutig sein.
• Release - Frei vergebbare Version ID, hier kann sich an den bestehenden Versionen orientiert werden.
• Development Type - Unterscheidet sich in "Lokal" und "Transportierbar". Bei lokalen Paketen erfolgt keine Abfrage eines Transportauftrags und die Objekte bleiben nur im aktuellen System.
• ABAP Language Version - Für Software Komponenten die in TIER-1 genutzt werden, wird hier "ABAP for Cloud" gesetzt. Pakete mit dieser Software Komponente arbeiten nach den verschärften Regeln von ABAP Cloud. TIER-2 und 3 verwenden "Standard ABAP" als Software Komponente.
• Description - Ein beschreibender Text zur Software Komponente.

 

Gemeinsamkeiten

• Objekte in TIER-1 können nur auf andere TIER-1 Objekte in der gleichen Software Komponente zugreifen, außer des besteht ein Release Contract.

 

Unterschiede

• Pflege der Komponenten geschieht aktuell über einen Report und nicht über eine Fiori Anwendung.
• In einem Transport können verschiedene Software Komponenten im klassischen CTS transportiert werden, es erfolgt keine Unterscheidung der Objekte.
• gCTS und Git sind nicht verpflichtend bei der Verwendung von Software Komponenten.
• Ein gleichnamiges Strukturpaket kann definiert werden, es muss aber nicht.

 

Modell

Hinweis: Die folgenden Unterabschnitte beschäftigen sich mit einem Beispielaufbau des 3-TIER Modells. Hier gibt es aktuell noch keine Best Practices und hierbei handelt es sich um einen Vorschlag von uns, den wir auch bei uns im Unternehmen so umsetzen und anwenden.

 

Legende

Für die folgenden Abschnitte gilt die folgende Legende, die die verschiedenen Objekte des Modells erklärt. Wir unterschieden nach Strukturpaket (nur Pakete unterhalb) und Entwicklungspaket, wo sich alle anderen Komponenten befinden.

 

TIER-3 - Classic ABAP

Der dritte TIER beschreibt die "Classic ABAP" Welt. Hier wären alle Objekte, die bereits auf dem System existiert haben, wenn du ABAP Cloud im System einführst. Damit wird dieser Layer zum Brownfield und muss in Zukunft Stück für Stück nach ABAP Cloud überführt werden. Es können einzelne Objekte auch manuell zur Sprachversion "ABAP for Cloud" überführt werden, dies reduziert aber die Übersichtlichkeit im System und es sind externe Tools zur Auswertung notwendig.

 

Struktur:

• Strukturpaket - Wir verwenden hier ein separates Strukturpaket ZCA_TIER3 zu Reportingzwecken und um alle Objekte einem TIER zuzuordnen.
• ABAP Test Cockpit - Hier wäre später eine eigene ABAP Test Cockpit (ATC) Prüfung möglich, sodass neue Objekte immer einem Paket mit TIER-Zuordnung zugeordnet werden müssen. Aktuell gibt es dafür keine Standardprüfung.

 

 

Regeln:

• Classic ABAP - Verwendung aller Technologien und Objekte, wie bisher bekannt (BAPI, User Exits, Modifikationen, SAP GUI, Dateizugriff, Reports, etc.).
• ABAP Cloud - Zwecks Vermischung sollten keine Objekte mit der Sprachversion "ABAP for Cloud" im TIER-3 ständig bestehen bleiben.

 

TIER-2 - API Layer

Der zweite TIER wird auch als API Layer bezeichnet. Hier liegen nur Objekte, die von SAP nicht freigegeben sind, aber im Prozess von TIER-1 benötigt werden. Jedes Objekt auf diesem TIER besitzt eine Freigabe, damit es entsprechend verwendet werden kann. Im Extensibility Guide ist beschrieben, welche Objekte sich am besten dafür eigenen.

 

Struktur:

• Software Komponente - Wir verwenden nur eine Software Komponente für den gesamten TIER-2, für Reportingzwecke und zur Abgrenzung der Objekte. Möchtest du das ebenfalls tun und bist auf S/4 HANA 2022, musst du Hinweis 3319469 einspielen, da du sonst nicht mit der Komponente arbeiten kannst. Die Sprachversion der Komponente muss auf "Standard ABAP" stehen, nicht auf ABAP Cloud.
• Pakete - Die Namen der zugehörigen Pakete auf den verschiedenen TIERs wird durch das entsprechende Kürzel sichergestellt (T1, T2 oder Standard).

 

 

Regeln:

• Wrapper - Wrapper sind Objekte, die Standard Objekt in einem neuen Objekt für TIER-1 zur Verfügung stellen (Facade Pattern). Der Wrapper benötigt eine C1 Freigabe, damit er aus TIER-1 verwendet werden kann. Wie du einen Wrapper baust und zur Verfügung stellst, erfährst du auch in diesem Tutorial auf der Developers Plattform.
• SAP Objekte - Wrapper werden für TIER-1 zur Verfügung gestellt, die folgenden Objekte werden von SAP empfohlen: BAPI, Klassen, Funktionsbausteine, Core Data Services. Die folgenden Objekte sollten nicht genutzt werden: FORM Routinen, Teile von Coding, SAP GUI Funktionen.
• Cloudification Browser - SAP schlägt für TIER-2 auch bereits verschiedene Objekte vor, die du über den Cloudification Browser oder Cloudification Repository Viewer einsehen kannst.
• Influence Request - Woher weiß SAP, dass du einen Wrapper gebaut hast? Im Anschluss solltest du einen Influence Request öffnen und das gewrappte Objekt anfragen. Du wirst dann eine entsprechende Antwort bekommen, dass das Objekt freigegeben wird, es eine Alternative gibt oder es keine Freigabe geben wird.

 

TIER-1 - ABAP Cloud

Unser Ziel ist es bei ABAP Cloud, all unsere Anwendungen nur noch auf TIER-1 umzusetzen und damit den Gold-Standard zu erreichen. Dazu stehen uns als Schnittstelle die Objekte von TIER-2 zur Verfügung, wenn entsprechende APIs noch fehlen sollten.

 

Struktur:

• Software Komponenten - Wie beim ABAP Environment, verwenden wir Software Komponenten zur Unterteilung der Anwendungen und Abgrenzung untereinander. Damit erreichen wir eine saubere Entkopplung der Anwendung und können Objekt freigeben, die dann übergreifend verwendet werden können. Automatisch erhältst du damit saubere Schnittstellen zu anderen Anwendungen. 
• Mehrere Komponenten - Wieso nicht eine Komponente? Der Entwickler wird so gezwungen, die Objekte und Anwendungen sauber voneinander zu trennen und nicht ein großes Paket zu verwenden. 
• Kürzel - Alle Objekte befinden sich immer noch in einem System und einem Namensraum. Mit der Verwendung eines Kürzels (2-4 Stellen) kommst du nicht in Namenskonflikte und kannst die Objekte zu den Software Komponenten zuordnen.

 

 

Regeln:

• ABAP Cloud - Eingeschränkter Sprachumfang für ABAP zur Entwicklung von Cloud Ready und Clean Core Anwendungen.
• Konzepte - Nur noch die Verwendung der neuen Konzepte möglich: Application Jobs, Fiori Anwendungen, neues Application Log, etc. Alte Konzepte wie SAP GUI oder der Zugriff auf das Dateisystem des Servers ist nicht mehr möglich.
• APIs - Der Zugriff auf den Core findet nur noch über freigegebene APIs statt (RAP Objekte, Core Data Services, freigegebene BADIs, Klassen). Es besteht die Möglichkeit selbst freigegebene Objekte zu erstellen, solange die benötigten Schnittstellen nicht existieren. Welche APIs gibt es und was sind die Nachfolger für alte Objekte? Das kannst du über den Cloudification Browser oder Cloudification Repository Viewer einsehen.

 

Gesamt

Das Gesamtmodell noch einmal im Überblick. Mit einem Klick auf das Bild erhältst die komplette Ansicht und kannst die verschiedenen Details betrachten.

 

Freigabe

Wie oben in der Übersicht angedeutet, gibt es die Möglichkeit TIER-2 Objekt nach TIER-1 zu bringen. Wenn eine entsprechende API zur Verfügung steht (Nachfolgelösung oder Freigabe des genutzten Objekts) und somit das Objekt ABAP Cloud ist, kann es nach TIER-1 gebracht werden. Dazu muss das Objekt auf "ABAP for Cloud" umgestellt werden und kann dann per "Change Package Assignment ..." in das entsprechende TIER-1 Paket verschoben werden. Die Prüfungen und der Compiler stellen dann sicher, dass das Objekt verschoben werden kann.

 

Objekte werden deshalb nicht mit dem TIER Kürzel versehen, damit sie frei zwischen den einzelnen TIERs verschoben werden können, wenn sich der Status ändert.

 

Berechtigung

Wie sieht es eigentlich mit der Abgrenzung der Berechtigungen aus? Sollen die externen Kollegen vielleicht nur noch ABAP Cloud entwickeln und einzelne interne Kollegen kümmern sich um die Wrapper auf TIER-2? Dazu kannst du das Berechtigungsobjekt S_ABPLNGVS verwenden. Über das Feld ABP_LNG_VS kannst du auf die verschiedenen Sprachversionen einschränken, die ein Entwickler anlegen und bearbeiten kann.

 

Fazit

Heute gab es einmal einen theoretischen Überblick über das 3-TIER Modell und wie du es aufbauen kannst. Als Vorschlag kannst du es übernehmen, anpassen oder auch anders leben. Nächste Woche werden wir anhand eines Beispiels eine Migration von TIER-3 auf TIER-1 vorstellen.