ABAP Cloud - Software Komponenten und Beziehungen

Inhaltsverzeichnis

• Einleitung
• Struktur
• Trennung
• SWC Beziehungen
• Weitere Punkte
• Namespace
• Übergreifende Objekte
• Transport
• Viele Komponenten
• Fazit

Wie gehen wir eigentlich richtig mit Software Komponenten um und wie können wir sie sinnvoll in der Entwicklung nutzen und strukturieren? In diesem Artikel gehen wir die verschiedenen Konzepte einmal genauer durch und schauen uns die verschiedenen Facetten der SWC an.

 

Einleitung

Was Software Komponenten (SWC) sind und wie du sie in der BTP nutzen kannst, hatten wir bereits in diesem Artikel besprochen. In diesem Artikel schauen wir uns einmal die Nutzung und Möglichkeiten in der On-Premise Entwicklung mit ABAP Cloud an. Dabei werden wir diese Legende für die folgenden Grafiken verwenden:

 

Ein Entwicklungspaket kennst du bereits, da du dieses in deiner tagtäglichen Entwicklung einsetzt und alle möglichen Arten von Objekten darunter anlegen kannst. Ein Strukturpaket ist etwas anderes, da du nur Pakete unter diesem Paket anlegen kannst und nicht direkt Objekte. In vielen Fällen sorgt das für mehr Ordnung im System, da die Pakete eine Art Struktur vorgeben.

 

Struktur

Wenn du das 3-TIER Modell im System einführst, stehst du vor der Möglichkeit, für TIER-1 eine Software Komponente anzulegen oder ähnlich dem ABAP Environment viele SWCs. In diesem Abschnitt schauen wir uns einmal die Struktur an, wenn wir auf viele Software Komponenten setzen. Entsprechend hat sich bei der Arbeit im ABAP Environment eine Best-Practice für die Struktur entwickelt. Hier einmal die schematische Darstellung einer SWC mit Strukturpaket und den entsprechenden Entwicklungspaketen darunter.

 

Dazu eine kurze Erklärung zu den einzelnen Schichten:

• FIORI - Hier befinden sich die Deployments der Fiori Freestyle und Fiori Elements Anwendungen (BSP), sowie das Descriptor Item. Weitere Objekte sind die IAM App, der Business Katalog oder der Launchpad Space. Im Grunde können hier alle Artefakte für die Launchpad Integration liegen.
• INTF - Hier würden alle Schnittstellen zu anderen Systemen liegen, wenn wir zum Beispiel ein Consumption Model, einen Proxy oder HTTP Zugriff erstellen. Damit weiß der Entwickler das auf andere Systeme zugegriffen wird und hierüber Daten kommen. Meist hilft es auch, die Pakete nach System und Schnittstelle zu benennen.
• APP - In diesem Paket befinden sich alle Anwendungen der SWC. Früher bestanden Anwendungen aus einem Report, einer Transaktion und vielleicht noch aus einer Klasse. Mit RAP kann eine Anwendung schnell mal aus 15-20 Objekten bestehen und diese möchte man ungern in einem Paket mit anderen Anwendungen mischen. Damit kann jede App ihr eigenes Paket erhalten und die Objekte sind sauber zugeordnet.
• TEST - Separate Test Komponenten für Unit oder Integrationstests können in diesem Paket abgelegt werden. Dies ist aber eher selten der Fall, da die Unit  Tests meist an den Objekten angelegt werden, die sie auch Testen.
• REUSE - Verschiedene Anwendungen nutzen die gleichen Komponenten und Hilfsklassen? Solche Re-Use Komponenten können wir in ein eigenes Paket ablegen. Im Gegensatz zu den Shared Komponenten nutzen wir solche Komponenten aber nur innerhalb der SWC.
• SHARE - Hier liegen Komponenten die wir auch für andere Software Komponenten freigeben wollen und die immer einen C1-Contract haben. Mit dem Vertrag gehen sie eine gewisse Stabilität ein und wir können steuern, welche Komponenten im System genutzt werden können.

 

Nicht jedes Paket wird zwingend in jeder Software Komponente angelegt, eher soll die Struktur helfen, sich in den Komponenten schnell wieder zu finden.

 

Trennung

Ein Vorteil von vielen Software Komponenten ist die strikte Trennung der verschiedenen Anwendungen mit Möglichkeiten zur Freigabe von spezifischen Funktionen. Wie bereits in der Struktur oben beschrieben, gibt es gewisse Komponenten innerhalb der SWC die wir freigeben. Schauen wir uns dazu die folgende Grafik an:

 

Dabei unterteilt sich die Nutzung in die drei Bereiche:

• Innerhalb - Die Nutzung von Objekten innerhalb der Software Komponente ist ohne Probleme möglich. Du kannst alle Objekte aufrufen und verwenden, so wie du es bereits heute On-Premise tust.
• Übergreifend - Eine Nutzung von Komponenten einer anderen Software Komponente ist nicht möglich, du bekommst bereits vom Compiler die Fehlermeldung, dass die Funktion nicht genutzt werden kann. Damit sind diese Komponenten "geschützt".
• Contract - Ein freigegebenes Objekt kann frei im System und von anderen SWCs genutzt werden. Der Entwickler sichert Stabilität bei der Nutzung zu und wird auch bei Stabilitätsverletzungen vom System gewarnt.

 

Damit nutzt jede Anwendung ihre eigenen Komponenten, ohne das wir Gefahr laufen, dass Datenelemente oder Strukturen angepasst werden, was vielleicht in einer Anwendung Sinn macht, aber auch Einfluss auf unsere Anwendung hat. Die Kontrolle bleibt damit komplett in der SWC. Nachteil wäre, dass wir ein ähnliches Objekt in mehreren SWC haben, hier helfen aber auch geteilte Komponenten, die solche Objekte zur Nutzung freigeben (C1-Contract).

 

SWC Beziehungen

Neu ist das Thema Software Component Relations welches in der BTP auf dem ABAP Environment verfügbar ist und wahrscheinlich mit dem S/4 HANA 2025 Release oder einem Downport On-Premise verfügbar sein wird. Damit kannst du alle Objekte und Komponenten deiner Software Komponente einer anderen SWC freigeben. Das Objekt "Software Component Relations" wird direkt unter dem Strukturpaket der SWC angelegt und muss den gleichen Namen haben wie die Software Komponente.

 

In der Beziehung kannst du einstellen, welche SWC die Objekte der aktuellen Komponente nutzen können. Die Einstellung findest du im oberen Bereich. Im unteren Bereich kannst du angeben, welche anderen Software Komponenten du in der aktuellen SWC nutzt. Damit sind Beziehungen zwischen den Komponenten leichter einsehbar, solange du sie auch richtig pflegst.

 

Schauen wir uns die Funktionsweise einmal an der folgenden Grafik an:

 

Nachdem wir die Beziehung angelegt haben und auch ZBC_NXT hinterlegt wurde, können die Komponenten der Software Komponente auf die Komponenten von ZBC_SWC zugreifen. Dies klappt aber nur einseitig, da Komponenten von ZBC_SWC nicht auf Komponenten von ZBC_NXT zugreifen können. Die Software Component Relations bieten dir damit die Möglichkeit die Freigaben noch genauer zu steuern und du musst keinen C1-Contract mehr definieren, damit eine andere SWC Objekte nutzen kann. Dies hat aber auch zur Folge, dass alle Objekte deiner Software Komponente genutzt und aufgerufen werden können, auch wenn sie vielleicht nicht dafür beabsichtigt waren.

 

Weitere Punkte

In diesem Abschnitt schauen wir uns verschiedene kleinere Punkte noch einmal genauer an und beleuchten die Details zu weiteren Konzepten.

 

Namespace

Leider bringen Software Komponenten keinen eigenen Namespace mit, wie es in anderen Programmiersprachen der Fall ist. Die einzelnen Komponenten innerhalb unserer SWC sind zwar vor Zugriff von außen geschützt, wir können den gleichen Namen allerdings trotzdem nur einmal im System verwenden. Genau so trifft das auch auf Anwendungen, Hilfsklassen, Core Data Services, etc. zu. Als Best-Practice verwenden wir daher das Kürzel der Software Komponente und bringen es in jedem Objekt unter, ähnlich den Gruppennummern bei SAP Schulungen.

In den Beispielen oben, haben wir bereits versucht die Verwendung darzustellen. EXA (Example), SWC (Software Komponente) oder NXT (Next) sind solche Abkürzungen. Mit dem Vorschlag kannst du die Objekte und Anwendungen den einzelnen Software Komponenten zuweisen. Mit einer Länge von zwei bis maximal fünf Zeichen, sollten sie in die meisten Objekte passen und geben dem Objekt einen eigenen "Namespace". Wo das Kürzel im Objekt steht, bleibt am Ende dir überlassen. Über die Suche können wir dann die Objekte eingrenzen oder wissen direkt zu welcher SWC ein Objekt gehört.

 

Übergreifende Objekte

In vielen Entwicklungen gibt es Hilfsklassen und -funktionen im System, die viele Anwendungen verwenden. So wie ein Logging, ein Mailversand mit Templates, Konfigurationen und Einstellungen. Solche Hilfsobjekte würden in eigenen Software Komponenten einen Platz finden und können dann einfach per C1-Contract im System freigegeben werden. Solche Komponenten müssen auf jeden Fall stabil sein und werden sehr wahrscheinlich in vielen Anwendungen zum Einsatz kommen. 

 

Transport

In der BTP werden Software Komponenten einzeln transportiert, da pro SWC ein eigenes Git-Repository angelegt wird. Dies kann beim Release von abhängigen SWC zu Problemen führen und es sollten daher Kreuzbeziehungen vermieden werden. In On-Premise ist das aktuell weniger ein Problem, da du verschiedenen SWCs die gleiche Transportschicht zuweisen und diese damit auf einem Transport über das klassische CTS ins nächste System bringen kannst. Damit sollten Kreuzbeziehungen von Komponenten kein Problem sein, als Tipp empfehlen wir dir es trotzdem möglichst zu vermeiden.

 

Viele Komponenten

Aktuell gibt der ABAP Extensibility Guide keine Empfehlung zur Nutzung von mehr als einer Software Komponente. Lediglich wird beschrieben, dass eine SWC für TIER-1 angelegt werden sollte, um die ABAP Cloud Regeln als Standard unterhalb des Pakets zu setzen.

Aus den folgenden Gründen geben wir unsere Empfehlung für mehr SWCs ab:

• Trennung - Die Aufteilung in verschiedene Software Komponenten trennt auch die Nutzung der verschiedenen Komponenten voneinander. Als Entwickler kannst du selbst entscheiden, welche Anwendung deine Klassen und Objekte verwenden. Datentypen und Hilfsklassen gehören deiner Anwendung, bis du dich entschließt, sie allgemein auch zur Verfügung zu stellen und damit Abhängigkeiten deutlicher erkennbar werden.
• Größe - Durch die Trennung in verschiedene Software Komponenten bilden sich sinnvolle Gruppen von Anwendungen im System. Du als Entwickler machst dir mehr Gedanken über die Struktur und Abgrenzung der Komponenten und es entstehen keine "Monsterpakete", unter denen jeder Entwickler einfach neue Anwendungen hinzufügt und die Suche nach zusammenhängenden Komponenten zur Qual wird.
• Struktur - Eine einheitliche Struktur On-Premise und im ABAP Environment kann auch dafür sorgen, dass zusammenhängende Anwendungen leicht zwischen den Systemen verschoben werden können (Migration). Als Entwickler findest du dich in beiden Systemen zurecht und verstehst sofort die verwendeten Strukturen und Muster.

 

Fazit

Die Strukturierung und Nutzung von Software Komponenten im On-Premise System kann noch einmal eine eigene Wissenschaft für sich sein. Mit unseren Informationen solltest du nun die SWC besser verstehen und effektiver in deiner Entwicklung einsetzen können.