BTP - Software Komponenten

Inhaltsverzeichnis

• Einleitung
• Anlage
• Entwicklung
• Transport
• Funktionsweise
• Beispiel
• Deployment
• Verwendung
• Fazit

In diesem Artikel werden wir etwas genauer auf die Nutzung von Software Komponenten im ABAP Environment eingehen. Wie du sie anlegst, sie verwaltet werden und was es mit dem Deployment auf sich hat.

 

Einleitung

Software Komponenten gibt es schon seit Ewigkeiten in der SAP Entwicklung, als Kunde kennen wir aber eigentlich nur HOME oder LOCAL, wenn es um die Entwicklung von eigenen Objekten geht. Mit der Einführung des ABAP Environment hat sich das nun geändert und sie sind wesentlicher Bestandteil der Software Architektur in der Entwicklung. Für die Anlage und Verwaltung der Software Komponenten wird die App "Manage Software Components" (F3562) benötigt. Diese findest du im Business Katalog SAP_A4C_BC_MSCL_PC (Lifecycle Management - Software Components).

 

Hier werden neue Software Komponenten angelegt und bestehende Komponenten verwaltet. Sie ist die Schnittstelle zwischen ABAP System und angeschlossenem Git, da sie viele Aktionen zur Verfügung stellt, die auch für Release Management und Transport benötigt werden. Die App ist ebenso in Test- und Produktivsystemen vorhanden, da sie für das manuelle Deployment benötigt wird.

 

Anlage

Legen wir zum Test eine neue Software Komponente an. Dazu über den "Create" Button in der App "Manage Software Components" den Dialog aufrufen und die Informationen befüllen. Wir geben den Namen der Software Komponente, sowie eine Beschreibung ein.

 

Die URL für ein externes Git Repository lassen wir leer, da wir den internen Git-Server von SAP nutzen wollen. Den Typen lassen wir ebenfalls auf Development stehen. Grundsätzlich gibt aktuell zwei Arten:

• Development - Hier werden Entwicklungsobjekte transportiert und es können Wartung und neue Releases abgebildet werden. Ebenso kann Rollen-Customizing über die Komponente verteilt werden.
• Business Configuration - Kann genutzt werden, um Customizing aus der "Custom Business Configurations" App zu verteilen.

 

Nach der Anlage der Software Komponente erhalten wir die Details dazu, sowie den aktuellen Status der Komponente im aktuellen System.

 

Damit wir nun mit der Komponente arbeiten können, müssen wir sie ins Entwicklungssystem klonen. Beim Klonen wird der Main Branch ausgecheckt für das System, es wird ein Paket im System angelegt, welches den gleichen Namen wie die Software Komponente hat und diese auch zugeordnet wird. Gleichzeitig kannst du auch noch einstellen, wie sich das Repository im System verhält (Push/Pull oder nur Pull).

 

Wurde der Klonvorgang abgeschlossen, finden wir in der "History" die durchgeführten Aktionen, dort können wir auch in die Details navigieren. Darunter finden wir die Branches, die es im Git Repository gibt. Beim Fall der Neuanlage finden wir dort nur den "main"-Branch und dieser ist auch der aktive Branch für die weiteren Arbeiten.

 

Entwicklung

Nach der Erstellung können wir über die ABAP Development Tools unser Paket finden und zu den Favoriten übernehmen. Das Paket hat den gleichen Namen wie die Software Komponente. Jede Komponente besitzt einen eigenen Transport Layer, da dieser für die Verteilung ins entsprechende Git Repository verantwortlich ist.

 

Wie du auf dem Bild oben siehst, handelt es sich erst einmal um ein Strukturpaket. Unter diesem können wir nicht direkt Objekte anlegen, sondern müssen erst einmal Entwicklungspakete definieren. Das sorgt auch dafür, dass wir uns erst einmal Gedanken über die Struktur der Anwendung machen sollten. 

Für Demozwecke legen wir nun ein weiteres Paket an, dazu im Project Explorer auf dem Paket ZBS_DMO per Rechts-Klick über das Kontextmenü "New -> ABAP Package" den Dialog starten.

 

Dort den Namen und die Beschreibung des neuen Pakets eingeben. Das Oberpaket ist bereits zugeordnet und der neue Typ ist "Entwicklung", damit können wir die Standardeinstellungen so stehen lassen.

 

Im nächsten Schritt sehen wir noch einmal die zugeordnete Software Komponente und den Transport Layer, diese sind relevante für den Transport und die Zuordnung zum richtigen Git Repository.

 

Im letzten Schritt müssen wir einen neuen Transport anlegen, hier wird pro Software Komponente ein eigener Transport angelegt. Eine Zuordnung von Objekten unterschiedlicher Software Komponenten auf den gleichen Transport ist nicht möglich, dass System überprüft auf die korrekte Komponente. Nachdem wir das Paket angelegt haben, definieren wir noch eine neue Klasse, die mir dann transportieren wollen.

CLASS zcl_bs_dmo_hello_world DEFINITION
  PUBLIC FINAL
  CREATE PUBLIC.

  PUBLIC SECTION.
    INTERFACES if_oo_adt_classrun.
ENDCLASS.


CLASS zcl_bs_dmo_hello_world IMPLEMENTATION.
  METHOD if_oo_adt_classrun~main.
    out->write( 'Hello world' ).
  ENDMETHOD.
ENDCLASS.

 

Transport

Nun wollen wir den Transport im System freigeben und dabei die Abhängigkeiten zu Git prüfen.

 

Funktionsweise

Die Software Komponenten sind eng verbunden mit Git, den anstatt dem klassischen CTS (Change- und Transportsystem), verwenden wir für den Transport gCTS, dessen Basis ein Git Repository ist. Im ABAP Environment wird dabei grundsätzlich mit einem "versteckten" Git gearbeitet, auf das wir als Kunde keinen Einfluss oder Einblick haben. Wie funktioniert die Entwicklung in einer 3-Systemlandschaft? Im Development System werden Änderungen durchgeführt, bei Freigabe des Transports erfolgt ein Commit im Git Repository und die Änderungen werden per Pull auf die anderen Systeme verteilt:

 

 

Seit Release 2402 ist es aber auch möglich, ein Public Repository (Bring your own Git) zu verwenden und damit Einfluss auf den Code und die Ablage zu nehmen. In der SAP Help findest du weitere Beispiele und mögliche Landschaften.

 

Beispiel

Nun geben wir den Transport im System frei, dazu öffnen wir den View "Transport Organizer" und finden die Transporte gruppiert nach den Transport Layern des Systems. Öffnen wir unseren Transport Layer, dann finden wir unseren Transport mit den angehangenen Objekten (Paket und Klasse). Über das Kontextmenü können wir die Aufgabe nun freigeben.

 

Im Anschluss muss auch der Transport freigegeben werden, da sonst kein Transport und Export erfolgt. Ein Transport erzeugt jeweils einen Commit im Repository der Software Komponente, als Text wird dabei der Transporttext verwendet. Schauen wir uns nun einmal die Software Komponente an und navigieren unter "Branches" in die dazugehörigen Commits, dort ist unser Transport nun als Commit angekommen.

 

Wenn wir weiter auf den Commit navigieren, bekommen wir auch die Änderungen des Transportes zu sehen. Das ist praktisch, um weitere Auswertungen über das System machen zu können.

 

Deployment

Wollen wir nun ein Deployment durchführen, müssen wir im ersten Schritt auf das System gehen, wohin wir die Änderungen deployen wollen. Dort gehen wir wieder in die App "Manage Software Components" und navigieren in unsere Software Komponente. Diese ist im System vorhanden, weil die Software Komponenten systemübergreifend verwaltet werden. Hier wurde bisher aber noch kein "Clone" durchgeführt, damit ist die Komponente gelistet, kann aber noch nicht genutzt werden. Im ersten Schritt müssen wir daher über den Button "Clone" die Komponente im System verfügbar machen.

 

Wichtig ist hierbei die Einstellung auf "Target" zu setzen, wenn es sich um kein Entwicklungssystem handelt. Damit ist aus diesem System keine "Push" möglich und es können nur Anwendungen deployt werden. Mit dem Klonen der Software Komponente steht der aktuelle Stand im System zur Verfügung, um nun ein Delta zu sehen, ändern wir das angelegte Objekt und geben den Transport in Entwicklung noch einmal frei. Im Anschluss finden wir in der Software Komponente einen aktualisierten Stand.

 

Wenn du nun in den Branch navigierst, siehst du den neuen Commit/Transport und kannst den Import der Änderungen ins System anstoßen.

 

Verwendung

Wie möchtest du Software Komponenten nun für die Entwicklung einsetzen? Dabei solltest du die folgenden wichtigen Punkte beachten:

• Deployment - Der Release findet immer über die gesamte Software Komponente statt, du kannst einen Commit beim Import wählen, es werden aber alle anderen Commits/Transporte davor ebenfalls importiert.
• Zugriff - Alle Objekte innerhalb der Software Komponente können sich gegenseitig verwenden. Objekte anderer Software Komponenten können nur verwendet werden, wenn sie einen Release Contract (C1) besitzen.
• Struktur - Unter dem Strukturpaket musst du zuerst einmal ein Paket anlegen, um darin zu arbeiten. Es empfiehlt sich eine einheitliche Benamung von bestimmten Paketen, die Aufgaben innerhalb der Software Komponente übernehmen.
• Größe - Welche Teile einer Anwendung und wie viele Apps möchtest du in einer Software Komponente haben? Der Transport und die Änderungen erfolgen gemeinsam, deshalb sollten sich nicht alle Anwendungen deines Systems darin befinden, sondern logische kleine Gruppen gebildet werden.
• Freigaben - Freigaben von Objekten sollten nur von einer Software Komponente zu einer anderen durchgeführt werden. Da die Komponenten einzeln transportiert werden, kann es sonst zu unlöslichen Transportkonflikten kommen.

 

Hinweis: Vor allem der letzte Punkt mit der Freigabe von Objekten (C1 Contract) sollte gut überlegt sein. Software Komponenten die Objekte freigeben, sollten keine Breaking Changes enthalten und immer zuerst transportiert werden.

 

Fazit

Die Software Komponente ist ein wesentlicher Bestandteil der Entwicklung im ABAP Environment. Du solltest dir klar machen, wie du sie bei verwendest und welche Mehrwerte du damit erhalten kannst. Auch sollten dir die Grenzen der Verwendung bewusst sein. Mit Hilfe des Artikels sollte der Entwicklung im ABAP Environment aber nichts im Weg stehen.