Beiträge

Halte Deinen Code mit ABAP Unit Test Framework in Eclipse sauber

Halte Deinen Code mit dem ABAP Unit Test Framework in Eclipse sauber – THEORETISCHE EINFÜHRUNG

Hast Du jemals darüber nachgedacht, wie wichtig das Testen für unser tägliches Leben ist? Stell Dir zum Beispiel vor, man baut ein Auto und setzt alle Teile zusammen, ohne auch nur ein einziges Teil davon zu testen. Und sobald die Fertigung abgeschlossen ist, will man an einem Autorennen teilnehmen und denken, dass auch alles wie erwartet funktioniert. Glaubst Du, der Motor springt überhaupt an? Ich denke, wir haben Grund genug, das zu bezweifeln.

Was kann also wichtiger sein, als unsere Produkte zu testen und die Fehler zu beheben, um die an den Kunden gelieferte Qualität sicherzustellen? Im Bereich der Softwareentwicklung wird diese Tätigkeit als Fehleranalyse bezeichnet.

Unser heutiger Artikel ist der erste aus einer zweiteiligen Serie, die sich mit der Nutzung des ABAP Unit Frameworks in Eclipse befasst. Dieser erste theoretische Teil bietet Dir das notwendige Know-how, um Unit Test Cases für Deinen Code zu erstellen.  Im zweiten Teil werden wir Dir das genaue Vorgehen dann in einem praktischen Beispiel demonstrieren.

Aber zuerst…..

Warum soll man eine Anwendung testen?

Ein Projektlebenszyklus umfasst viele Verfahren und Phasen, die methodisch verfolgt werden müssen. Als Softwareentwickler sollten wir uns bewusst sein, dass es immer notwendig ist, ein Produkt während der Entwicklungs- und Integrationsphase einer Anwendung zu testen. Unser Ziel ist es, die Anwendung über einen langen Zeitraum performant zu halten und ressourcenschonend zu arbeiten.

Das Testen ist unerlässlich und bringt mehrere Vorteile mit sich:

  • weniger Fehler, die zur Verbesserung der Gesamtkapazität und Genauigkeit führen
  • es ist kostengünstiger in Bezug auf zukünftige Entwicklungen.
  • verbessert die Qualität und sichert die Anwendungsperformance
  • fördert die Zufriedenheit und das Vertrauen der Kunden
  • verstärkt damit die Marktposition unserer Entwicklungen

Testverfahren

Computersysteme sind oft komplex und schwer zu verstehen. Infolgedessen wurden verschiedene Methoden implementiert, um das Verhalten eines Produkts zu bewerten. Im Hinblick auf das Testen unseres Softwarecodes gibt es mehrere Testverfahren, die entlang des Lebenszyklus einer Anwendung angewendet werden – wie nachfolgend dargestellt:

Testverfahren bei dem Test en des Softwarecodes

Abbildung 1: Testverfahren entlang des Lebenszyklus einer App

1.Unit Test

Der Unit Test ist die erste Stufe des Softwaretests, bei der einzelne Codeeinheiten daraufhin getestet werden, um zu prüfen, ob sie wie erwartet funktionieren. Folglich wird jedes Stück Code einer Reihe von Testfällen unterzogen. Es kann manuell durchgeführt werden, aber in der Regel sind die Tests automatisiert.

2.Integrated/Component Testing

Ist eine Technik, die sich darauf konzentriert, die Integration verschiedener Module, die zuvor Unit-Tests unterzogen wurden, zu testen, indem diese auf verschiedene Weise gruppiert werden und ihr Verhalten und ihre Datenkommunikation überprüft werden. Tests werden in einem Integrationstestplan vordefiniert und auf diese aggregierten Komponenten angewendet.

3.System-/UI-Tests

Dabei handelt es sich um eine Testtechnik, die sich auf die Designstruktur der Benutzeroberfläche (UI, User Interface) konzentriert. Sie kann manuell oder mit Hilfe von automatisierten Tools ausgeführt werden. Es ist eine Praxis, die verwendet wird, um die Eigenschaften und den Zustand der Oberflächenelemente zu bestätigen. Dies kann effektiv erreicht werden, durch die Schaffung einer Vielfalt und Kombination von Testfällen.

4.Exploratory/Acceptance Testing

Es umschreibt die Qualitätssicherungstechnik (QA), mit der untersucht und entdeckt wird, was in einer Anwendung funktioniert und was nicht. Die Tester haben dabei die Möglichkeit, die Anwendung in Echtzeit zu erkunden, zu erlernen und zu überprüfen. Testfälle sind im Vorfeld nicht notwendig, in der Regel entscheiden die Tester spontan, was als nächstes getestet wird und wie viel Zeit sie für eine bestimmte Funktionalität aufwenden.

Mit Ausnahme der Unit-Testing-Technik werden beim Testen einer Anwendung die inneren Details als „Black Box“ für den Tester betrachtet. Als Voraussetzung sollte jedoch ein grundlegendes Verständnis des Systemdesigns vorhanden sein.

Automatisiertes versus manuelles Testen

Erstens, was ist automatisiertes Testen und wie können wir das manuelle Testen definieren?

Das automatisierte Testen ist ein Prozess zum Testen des Softwarecodes, bei dem ein Minimum an geskripteten Tests ausgeführt wird. Diese Tests werden mit einem automatisierten Tool durchgeführt, das schließlich die Istwerte ausgibt und die Ergebnisse mit dem erwarteten Ergebnis vergleicht. Ziel der automatisierten Prüfung ist es, den Arbeitsaufwand und den Zeitaufwand so gering wie möglich zu halten. Diese Technik ist für große Projekte geeignet und praktisch, insbesondere wenn sie zu komplex sind, um sich nur auf manuelle Tests zu verlassen.

Das manuelle Testen hingegen eine Technik, um Fehler und Mängel in einer Softwareanwendung zu finden, indem eine Reihe von Testfällen von einer Person selbst durchgeführt wird. Es ist nicht notwendig, Kenntnisse über ein automatisiertes Zwischenwerkzeug zu haben, aber es kann sehr zeitaufwendig sein, wenn man bedenkt, dass die Tester, um die Vollständigkeit der Tests zu gewährleisten, ein geeignetes Schema erstellen müssen, das zu einem detaillierten Satz wichtiger Testfälle führt, die abgedeckt werden müssen.

Es wäre ideal den Code einer neuen Anwendung erstmal manuell zu testen oder nach einer ihrer größeren Änderung und nur danach neue automatisierte Tests zur besseren Abdeckung und zum besseren Verständnis der implementierten Funktionalitäten zu erstellen.

Dennoch besteht die Notwendigkeit, dass wir automatisierte Tests mit manuellen Tests kombinieren müssen, um einen vollständigen abgedeckten Testplan zu erstellen. Die Realität ist, es gibt kein „besseres“ oder „schlechteres“ Verfahren, sie sind einfach unterschiedlich.

Was ist Unit Testing und wann sollten wir es einsetzen?

Beginnen wir mit der Beantwortung der zweiten Frage. Die geeignete Antwort wäre: jedes einziges Mal wenn wir eine kleine Einheit und ihr Verhalten testen wollen. Du fragst dich vielleicht, was ist dann eine Einheit?

Eine „Einheit“ ist als die kleinste prüfbare Komponente einer Anwendung definiert, wie beispielsweise eine Klasse oder eine Methode, die von dem Rest des Codes isoliert und gesteuert werden kann, um zu prüfen, ob sie zur Verwendung geeignet ist.

Im Gegensatz zu den anderen Testtechniken ist bei der Verwendung von ABAP Unit Testing ein solides Verständnis der Systemarchitektur erforderlich. Daher wird Unit Testing auch als „White Box Testing“ oder „Gray Box Testing“ bezeichnet, und daher sollten Unit Tests von einem Entwickler erstellt und definiert werden.

Die meisten Programmiersprachen haben spezielle Unit-Test-Frameworks, so auch ABAP. Hier sind alle für das Testen notwendigen Hintergrundprozesse in eine IDE (Integrated Development Environment) integriert, so dass wir die Unit-Tests bei jeder Kompilierung des Testprogramms durchführen können.

Das am besten geeignete Tool in SAP for Unit Testing ist das ABAP Unit Framework in der Eclipse IDE. Dieses Framework ist Teil der ABAP Development Tools (ADT), daher muss man das Add-on nur in die Eclipse-Plattform installieren. Diejenigen, die es noch nicht installiert haben, finden weitere Informationen sowie eine Schritt-für-Schritt-Anleitung in diesem Blogbeitrag.

Unit-Tests interagieren nicht mit dem Environment oder mit externen Systemen der Codebasis. Sie laufen in den meisten Fällen immer in einem simulierten und isolierten Environment als separates Programm, in dem Komponententests als Testmethoden in lokalen Testklassen definiert sind. Wenn sich die Anwendung in dem realen, produktiven Environment ändert, wird der getestete Teil der Einheit aufgrund der Isolation vom System nicht automatisch informiert.

Um Tests effektiv zu gestalten, muss man den Code so strukturieren, dass es einfach ist, ihn zu testen. Dennoch erfordert es ein wenig Übung, gut darin zu werden und zu verstehen, was man isoliert testen soll.

Unit-Tests sollten dort durchgeführt werden, wo Tests eine klare Bedeutung haben. Der Business Layer Code ist allgemein für die Durchführung von Tests geeignet und stellt somit den Hauptfokus des Unit-Tests dar.

Unser Ziel ist es, effiziente automatisierte Tests neben testbarem Code zu schreiben. So haben wir beispielsweise bei Unit-Tests die Flexibilität, den Quellcode zu ändern und anzupassen, um die Fehler zu beheben und testbar zu machen. Der offensichtlichste Vorteil ist vor allem das Wissen, dass bei einer Änderung keine weiteren einzelnen Codeeinheiten betroffen sind.

automatisierte Tests schreiben

Abbildung 2: Schreiben von automatisierten Tests

Vorteile und Benefits

Als erste Stufe der Durchführung von Testfällen in einer Anwendung bietet der Unit-Test natürlich einige bemerkenswerte Vorteile. Nicht nur das, bei richtiger Einstellung sind Komponententests:

  • Schnell – man kann typischerweise Tausende von Tests/Sekunde durchführen
  • Einfach – Unit-Tests konzentrieren sich auf kleine Teile der Anwendung
  • Zeitnah – Tests werden alternativ mit dem Produktcode geschrieben

Aber auch Komponententests sind sehr effektiv, denn sie liefern:

  • Große Code-Coverage – in vielen Fällen bis zu 80-90% Code-Coverage
  • Einfache Fehleranalyse – Komponententests zeigen genau die Stelle an, an welcher der Code falsch läuft
  • Stabilität – die Wiederholbarkeit der Unit-Tests führt zu einem konstanten Verhalten, was sie stabil macht

Anlegen einer Testklasse

Im SAP-Umfeld wurden im Rahmen des objektorientierten Designs Komponententests eingeführt. Bei dieser Betrachtung können wir intuitiv feststellen, dass Komponententests perfekt mit Klassen zusammenarbeiten. In einem Szenario, in dem wir nicht in der Lage sind, den gesamten Berichtsfluss zu testen, sollten wir zumindest versuchen, kleine Teile davon zu testen.

Außerdem sollten wir nur die öffentliche Schnittstelle einer Anwendung testen und nicht die privaten Teile. Normalerweise ist es uns nicht erlaubt, Blöcke eines Reports direkt zu testen, wie INITIALISIERUNG oder START-OF-SELECTION, aber wir können die gleiche Logik implementieren, indem wir diese in Objektmethoden konvertieren und anschließend testen. Bemerkenswert ist es hier, dass die Modularisierung für eine bessere Programmierung sehr wichtig ist.

Die Hauptidee ist, dass wir Testklassen auf dieselbe Weise definieren und implementieren, wie wir eine reguläre ABAP Objects Klasse definieren. Was jedoch einen Unterschied macht, ist die Anweisung „FOR TESTING„, die wir der Testklassendefinition hinzufügen müssen. Beachte, dass diese Ergänzung die Anwendung grundsätzlich in zwei verschiedene Teile unterteilt: den Testcode und den Seriencode.

Auch wenn es noch keine einheitliche Namenskonvention gibt, schlägt SAP vor, den Namen der Testklassen wie in „LTC_<class_name>“ ein Präfix hinzuzufügen, um zu betonen, dass es sich um lokale Testklassen handelt und um ihren Fokus zu unterscheiden. Außerdem müssen wir für eine Testklasse auch die beiden Klassenattribute RISK LEVEL und DURATION angeben, die vom ABAP Unit Runner verwendet werden, um die Eigenschaften dieser Klasse zu interpretieren.

Das Attribut RISK LEVEL bezieht sich auf die Nebenwirkungen, die das System beeinflussen können:

  • HARMLOS – kein bestehender Prozess wird durch den Komponententest beeinflusst
  • GEFÄHRLICH – der Komponententest kann Änderungen an einer Datenbank oder persistenten Daten vornehmen
  • KRITISCH – Sowohl die Anpassung, als auch die persistenten Daten können geändert werden

Bitte beachte, dass jeder Komponententest mit dem Ziel definiert werden sollte, „harmlos“ zu sein, also das Environment in keiner Weise zu verändern.

Das Attribut DURATION bezieht sich auf die erwartete Ausführungszeit der Komponententests und kann es sein:

  • KURZ – weniger als eine Minute
  • MITTEL – weniger als fünf Minuten
  • LANG – länger als fünf Minuten, circa eine Stunde

Eventuell können diese Intervalle angepasst werden. Was wir jedoch beachten müssen, ist, dass, wenn die Ausführungszeit den angegebenen Parameter überschreitet, der ABAP Unit Runner einen Fehler auswirft.

Um dies kurz zu veranschaulichen, sollte eine Testklassendefinition letztendlich das folgende Format haben:

CLASS ltc_my_test_class DEFINITION FOR TESTING

RISK LEVEL Critical|Dangerous|Harmless

      DURATION Short|Medium|Long .

[…]

ENDCLASS.

Erwähnenswert ist es, dass der Teil des Codes in einer Anwendung, der dem Unit-Test unterzogen wird, normalerweise „CUT“ = Code Under Test genannt wird.

Wenn du mehr über Testklassen erfahren möchtest, empfehle ich dir die SAP Press E-Book-Publikation „ABAP Unit: Writing and Executing Unit Tests“, geschrieben von James Wood und Joseph Rupert.

Allerdings sind wir nun so weit gekommen, dass wir…..

Eine Testmethode anlegen

Eine Testmethode kann ausschließlich in einer Testklasse implementiert werden. Tatsächlich werden während eines Testlaufs Testmethoden als Einzeltests aufgerufen, so dass wir pro Testmethode nur eine Instanz der Testklasse haben.

Insbesondere wird hier die zu testende Methode, nämlich das Unit, gewöhnlich als „Methode im Test“ bezeichnet und ist Teil des Seriencodes.

Testmethoden haben keine Parameter, aber sie haben, ähnlich wie Testklassen, am Ende des DEFINITION-Teils den ZusatzFOR TESTING„. Ein weiterer wichtiger Punkt, der zu beachten ist, ist, dass eine Testmethode im PRIVATE SECTION der Klassendefinition deklariert wird, um zu unterstreichen, dass sie nur im Kontext ihrer Testklasse und nicht in anderen abgeleiteten Klassen wie folgt verwendet werden kann:

CLASS ltc_my_test_class DEFINITION FOR TESTING

      […] .

      PRIVATE SECTION.

      METHODS:

          test_method1 FOR TESTING.

          test_method2 FOR TESTING.

ENDCLASS.

Die einzige Situation, in der die Testmethoden in der PROTECTED SECTION deklariert werden können, ist, wenn diese Methoden Teil einer Oberklasse sind und von einer anderen Testklasse vererbt werden.

Der Implementierungsteil einer Testmethode sollte uns immer eine Geschichte darüber erzählen, was getestet werden soll, und dies sollte sich auch im Namen der Testmethode widerspiegeln. In der Regel folgt es dem ”given – when – then” Muster, das mit der Initialisierungs-, Ausführungs- und Ergebnisphase des Testfalls verbunden ist. Wir sollten uns eine Testmethode ähnlich einer logischen Geschichte wie folgt vorstellen:

„given“  -> ein bestimmtes Einvironment

Dies ist ein Initialisierungsteil, in dem unsere globale Klasse instanziiert wird.

when“  -> wir führen diesen CUT aus (Code under test)

Hier wird normalerweise die zu testende Methode zusammen mit den angegebenen Eingabewerten aufgerufen.

then“  -> dieses Ergebnis wird erwartet

Ein Prüfverfahren hat einen oder mehrere Eingänge und in der Regel einen einzigen Ausgang.

Signifikant ist es, dass im „then“ Teil der Testmethode das Ergebnis durch einen Vergleich zwischen dem tatsächlichen Wert, den die zu testende Methode zurückgibt, und dem tatsächlichen erwarteten Wert validiert wird. Wenn die Ergebnisse nicht übereinstimmen, gibt das Unit-Test-Framework einen Fehler aus. Dieser Vergleich erfolgt mit einer der Utility-Methoden der ABAP-Klasse „CL_ABAP_UNIT_ASSERT„, die „ASSERT_EQUALS“ genannt wird.

Die am häufigsten verwendeten Utility-Methoden neben der SAP-Dokumentation sind:

  • ASSERT_EQUALS – stellt die Gleichheit zweier Datenobjekte sicher
  • ASSERT_BOUND / ASSERT_NOT_BOUND – stellt die Gültigkeit / Ungültigkeit der Referenz einer Referenzvariablen sicher
  • ASSERT_INITIAL / ASSERT_NOT_INITIAL – stellt sicher, dass der Wert des Datenobjekts initial ist / nicht initial ist
  • ASSERT_TRUE / ASSERT_FALSE – stellt sicher, dass ein Boolescher gleich ABAP_TRUE / ABAP_FALSE ist
  • ASSERT_SUBRC – stellt einen bestimmten Wert des Rückgabecodes sicher
  • FAIL – Meldung der bedingungslosen Behauptung
  • ABORT – Abbruch der Testausführung wegen fehlendem Kontext

Sie werden auch als „Assertionsmethoden“ bezeichnet und dienen letztlich dazu, Nachrichten an den ABAP Unit-Runner zu übergeben.

Natürlich ist es nicht notwendig, dass eine Testmethode dem obigen Muster folgt, es ist nur ein Stil des Testsschreibens, der zum besseren Verständnis beiträgt. Aber, ist es zwingend erforderlich, dass die Logik in diese drei Teile integriert wird.

Wichtig zu wissen ist es, dass es mehrere spezielle private Methoden gibt, die in Testklassen verwendet werden und die vom ABAP Unit Framework bereitgestellt werden. Sie implementieren ein einzigartiges Testverhalten und beinhalten die Testobjekte und die für eine korrekte Ausführung notwendigen Verbindungen. Diese werden unten aufgezählt:

  • SETUP( ) – Instanzmethode, die vor jedem einzelnen Test oder vor jeder Ausführung einer Testmethode ausgeführt wird
  • Der „given“ Teil der Tests kann in der SETUP-Methode implementiert werden, nur wenn die Testmethoden den gleichen Code haben
  • TEARDOWN() – Instanzmethode, die nach jedem einzelnen Test oder nach jeder Ausführung einer Testmethode ausgeführt wird.
  • CLASS_SETUP() – Klassenmethode, die einmalig vor allen Tests der Klasse ausgeführt wird
  • CLASS_TEARDOWN() – Klassenmethode, die einmalig nach jedem Test der Klasse ausgeführt wird

Sie werden eigentlich auch „Fixture-Methoden“ genannt und haben vordefinierte Namen, damit die ABAP Unit sie erkennen kann. Diese Methoden sind optional und sollten nur verwendet werden, falls wir sie benötigen.

Es gibt bereits mehrere Softwareunternehmen, die Unit-Testing als Teil ihres Entwicklungsprozesses übernommen haben. Obwohl es schwierig sein kann, sich daran zu gewöhnen oder herauszufinden, welche Fälle abgedeckt werden sollen, führen Unit-Tests langfristig zu weniger Wartungsaufwand und Kosten. Unit-Tests werden in der Regel von Entwicklern erstellt, was der Grund ist, warum wir sie „White-Box“-Tests nennen. Und das macht Sinn, weil die Person, die den Code geschrieben hat, die qualifizierteste ist, um zu wissen, was und getestet werden kann und wie leicht zugänglich es ist. Darüber hinaus wird die Durchführung vieler Tests für die kleinen Komponenten der Anwendung insgesamt viel weniger Debugging erfordern, was auch Zeit spart. Und Zeit ist für einen Entwickler sehr wichtig, nicht wahr?

Nun, da wir den theoretischen Teil abgeschlossen haben, bist Du bereit für Praxis. Verpasse nicht den zweiten Teil dieser Serie, der Dir zeigt, wie man Unit Test Cases anhand eines praktischen Beispiels erstellt.

Quellenangabe der Bilder: https://open.sap.com

Autor dieses Beitrags
Andra Atanasoaie Associate
Tel.: +49 (0) 7031 714 660 0
E-Mail: cluj@inspiricon.de
organisiere-deine-arbeit-mit-abapgit-inspiricon

Organisiere deine Arbeit mit abapGIT

Was ist abapGit und wie funktioniert es?

Wenn du bereits mit der ABAP-Programmierung vertraut bist, aber noch nichts von abapGit gehört hast, stellen wir dir hier zunächst die Git-Welt vor.

Git ist ein Versionskontrollsystem mit dem man alle Änderungen einer Datei während ihrer Laufzeit nachverfolgen kann.

Aber was ist ein Versionskontrollsystem? Ein Auszug aus dem Buch von Scott Chacon und Ben Straub schafft Klarheit:

Was ist eine „Versionskontrolle“ und warum sollte ich mich damit beschäftigen? Versionskontrolle ist ein System, das Änderungen an einer oder mehreren Dateien registriert, um spezifische Versionen später noch abrufen zu können. Für die Beispiele in diesem Buch werden wir Software-Quellcodes verwenden, um die Änderungen nachzuverfolgen. In Wirklichkeit könnt ihr das jedoch mit nahezu jeder Datei auf einem Computer machen.

Falls du ein Grafik- oder Webdesigner bist und du jede Version eines Bildes oder eines Layouts behalten möchtest (was du wahrscheinlich nicht möchtest!), dann ist ein Versionskontrollsystem (VKS) die richtige Wahl. Damit kannst du eine Datei in einen früheren Zustand zurückversetzen, ein ganzes Projekt rückgängig machen, Änderungen zu verschiedenen Zeitpunkten vergleichen, sehen wer als letztes etwas geändert hat, das möglicherweise Probleme machen könnte, wer einen Aspekt hinzugefügt hat und vieles mehr. Wenn du ein VKS nutzt heißt das auch, dass es einfach ist, die Dateien wiederherzustellen, falls du etwas durcheinander gebracht oder Dateien verloren hast. Dies alles bekommst du für sehr geringe Kosten.

ABAP selbst liefert ebenfalls ein Versionskontrollsystem, aber dieses System gilt nur für die eigene geschlossene Arbeitsumgebung. Es ist also nicht möglich mit „Outsidern“ zusammen zu arbeiten. Code-Sharing ist immer schwierig, besonders jedoch bei Opensource Projekten.

Du möchtest mehr über Git erfahren? Dann kann ich dir das Buch „Pro Git“ von Scott Chacon und Ben Straub empfehlen.

abapGit, der GitClient in ABAP, ist ein Opensource Projekt, das von Lars Hvam unter Anwendung einer MIT Lizenz initiiert wurde.

Mehr über das abapGit selbst und andere großartige ABAP Opensource Projekte findest du in diesem wirklich sehr guten Blog von Graham Robinson, auf dem auch dieser Artikel basiert.

In diesem Artikel konzentrieren wir uns auf die Installation und Nutzung des abapGit mittels GitHub und Amazon Web Services (AWS) CodeCommit.

In den folgenden Verfahren wurde SAP NetWeaver 7.5 als Arbeitsumgebung verwendet. Lass uns jetzt starten!

Vier Schritte bis zur abapGit Erfahrung

Um die Funktionen von apabGit optimal nutzen zu können, sind vier Schritte zur Einrichtung und Anbindung an die Entwicklungsplattform und die Hosting-Dienste notwendig.

Schritt 1: Einrichtung des abapGit Servers

Als erstes müssen wir nur das abapGit-Projekt auf unserem ABAP-Entwicklungssystem laufen lassen.

Wenn du den SAP NetWeaver bereits auf deinem Rechner installiert hast, öffne nun den SAP GUI-Client und erstelle einen ABAP-Report „ZABAPGIT“ über die Transaktionen SE38 oder SE80. Dann wiederhole den Code auch im untenstehenden Link:

https://raw.githubusercontent.com/abapGit/build/master/zabapgit.abap

Aktiviere den Bericht und führe ihn aus. Danach wird die abapGit Startseite auf dem Bildschirm angezeigt.

abap-Git-berichte-abrufen

Bitte beachte, dass, wenn du dein abapGit-Projekt auf eine neuere Version aktualisieren möchtest, du nur den Code im Bericht durch die neuesten Einstellungen ersetzen musst – damit ist das Upgrade schon beendet.

Anders gesagt ist dieses Verfahren ein unkomplizierter Weg, über den du jederzeit die neueste Version des abapGit herunterladen kannst. Ziemlich einfach, oder?

Schritt 2: GitHub Root Zertifikate herunterladen

In diesem nächsten Schritt werden wir mit der SSL-Einrichtung fortfahren, die es uns ermöglicht, die Online-Funktion des Git-Servers zu nutzen. Im Gegensatz dazu arbeiten Offline-Projekte hinter Firewalls und ohne SSL. Ein SSL, „Secure Sockets Layer“ Zertifikat ist eine Textdatei mit verschlüsselten Daten, die wir auf unserem Server installieren sollten, um eine sichere, zuverlässige und reaktionsschnelle Kommunikation mit einem Webbrowser sicherzustellen.

Heutzutage ist GitHub die beliebteste webbasierte Gemeinschaft, die von Git organisiert wird. Um die Kommunikation zwischen abapGit und GitHub zu ermöglichen, ist es notwendig, einige Root-Zertifikate auf Ihrem ABAP-System zu installieren. Je nach verwendetem Webbrowser hat man verschiedene Möglichkeiten, die Dateien herunterzuladen, ansonsten kann man sie manuell herunterladen. Der Zweck dieser Root-Zertifikate ist es, die Integrität und Geheimhaltung der Kommunikationsdaten zwischen dem Server und Webbrowser zu sichern.

Wir haben Google Chrome als Standard-Webbrowser verwendet. Führe die folgenden Schritte aus, um an die erforderlichen Zertifikate zu kommen:

  • Gehe auf die Seite https://github.com.
  • Klicke auf das Schließfachsymbol neben der Adressleiste und wähle dann „Certificate“.
  • Gehe auf die Registerkarte „Details“ und klicke auf „Copy to file…“, um das Zertifikat in eine CER-Datei zu exportieren.
  • Gib den Namen der Datei an, wähle den Pfad, in dem die Datei gespeichert werden soll und drücke auf „Finish“.
  • Wähle die Registerkarte „Certification Path“ und wiederhole die beiden vorherigen Schritte vom übergeordneten Knoten bis zum Wurzelknoten.

Wenn du die Root-Zertifikate manuell herunterladen möchtest, navigieren zur GitHub-Plattform und finden heraus, welches Zertifikat sie verwendet; so wie wir es oben schon gezeigt haben. Lade diese Zertifikate unter https://www.digicert.com/digicert-root-certificates.htm im Bereich „Root Certificates“ herunter.

Weitere Informationen findest du unter http://docs.abapgit.org/.

Wir haben nun die Dateien im gewünschten Format und können so die Verbindung zum SAP-System herstellen.

Schritt 3: SSL-Einrichtung mit dem SAP Trust Manager

Damit die zuvor heruntergeladenen Zertifikate bestätigt werden können, müssen wir nun die sogenannte Trust Manager Anwendung im SAP-System installieren. Melde dich dazu an deinem SAP-GUI-System an und führe die Transaktion STRUST aus.

Wechsle zum „Change“ Modus und öffne aus der linken oberen Objektliste den Ordner „SSL Sys-tem Client SSL Client (Anonymous)“.

SSL-Einrichtung-mit-dem-SAP-Trust-Manager

Wähle „Import certificate“ unten links im Feld „Certificate“ aus und füge die Dateipfade der zuvor aus dem Webbrowser exportierten Zertifizierungsdateien ein.

abapGit-add-to-certificate

Wähle „Add to Certificate List“ für jede Zertifizierungsdatei einzeln aus, eine nach der anderen. Am Ende sollte das Feld „Certificate List“ wie folgt aussehen:

abapGit-certificate-list

Speichere die vorgenommenen Änderungen. Die Root-Zertifikate sind nun auf dem SAP-Entwicklungssystem installiert.

Um zu prüfen, ob die ABAP-Werkzeuge mit dem Git-Server kommunizieren können, ist es zwingend notwendig zu testen, ob die Verbindung zwischen ihnen funktioniert. Erstelle einen ABAP-Report „ZABAPGIT_TEST_SSL“ über die Transaktionen SE38 oder SE80, um dies zu veranschaulichen und kopiere den Code aus diesem Link.

Aktiviere dein Programm und führe es aus. Wenn die Verbindung erfolgreich hergestellt wurde, wird folgende Ausgabe erwartet:

abapGit-test-ssl

Wenn die Verbindung jedoch nicht korrekt funktioniert, achte darauf, dass du eventuell zwei Profilparameter in der Transaktion RZ10 einstellen musst (siehe auch SAP-Hinweis 510007 – Einrichten von SSL auf dem Application Server ABAP, Schritt 7).

In unserem System mussten wir zum Beispiel folgende Werte einstellen:

ssl/ciphersuites = 135:PFS:HIGH::EC_P256:EC_HIGH

ssl/client_ciphersuites=150:PFS:HIGH::EC_P256:EC_HIGH

Bitte beachte, dass du den Applikationsserver neu starten musst oder zumindest in der Transaktion ICM Monitor, SMICM, um den icman-Prozess neu zu starten!

Hier kannst du tiefer in das Thema eintauchen.

Schritt 4: Git Repositories-Verbindung

Halte deinen installierten abapGit-Code auf dem neuesten Stand und erweitere die unterstützten Objekttypen durch das Herunterladen der benötigten Plugins.

Wenn abapGit zum ersten Mal ausgeführt wird, wird die abapGit-Tutorial-Seite angezeigt, wie schon in Schritt 1 gezeigt. Auf der Unterseite der Seite findest du den Abschnitt „abapGit related repositories“.

abapGit-repositories

Klicke auf „install abapGit repo“, um den Prozess zu starten. Klicke auf „Continue“, um die aktuelle Version von abapGit in das Paket $ABAPGIT herunterzuladen, das in diesem Fall ein lokales Paket ist. Wähle „Overwrite“, um das zuvor erstellte Programm „ZABAPGIT“ zu aktualisieren und alle abapGit-Werkzeuge zu aktivieren.

Gehe genauso für „install abapGit plugins“ vor. Dann bist du bestens dafür vorbereit, die abapGit-Funktionen auszuprobieren.

abapGit-Funktionen

Wichtig dabei ist, dass nicht nur die GitHub-Plattform – ein webbasierter gehosteter Dienst zur Versionskontrolle – mit dem abapGit verbunden werden kann, sondern auch die Möglichkeit der Kommunikation über die Amazon Web Services besteht.

Wir als Inspiricon arbeiten viel mit den Amazon Web Services, daher lag es für uns nahe, den „AWS Service CodeCommit“ als Git-Server für unsere Repositories zu nutzen. Wenn dies auch deine Wahl sein sollte, musst du dein System nach der Installation zunächst mit den Amazon Web Services verbinden, damit du die Online-Funktion der abapGit-Plattform nutzen kannst.

Amazon Web Services, kurz „AWS“ genannt, bietet zuverlässige, skalierbare und sichere Cloud-Computing-Services, Datenbankspeicher und andere Funktionalitäten zur Unterstützung der Geschäftsprozesse. Um sich mit dem AWS Server zu verbinden, musst du mehrere Schritte ausführen.

Die ersten Schritte sind ähnlich wie die für die Verbindung mit dem GitHub-Server, einschließlich des Herunter- und Hochladens der Root-Zertifikate, wie in Schritt 2 und Schritt 3 beschrieben. Als nächstes müssen IAM-Benutzer im AWS angelegt werden. Es ist wichtig, dass du im IAM-Benutzerprofil „HTTPS Git credentials for AWS CodeCommit“ arbeitest.

Als Rechte solltest du mindestens die folgenden Berechtigungen vergeben:

  • AWSCodeCommitPowerUser AWS Managed Policy
  • IAMReadOnlyAccess AWS Managed Policy
  • IAMSelfManageServiceSpecificCredentials AWS Managed Policy

Weitere Informationen findest du auch hier.

Nach der Erstkonfiguration kannst du im AWS CodeCommit Dashboard eigene Repositories anlegen.

Online und Offline?

Das abapGit-Projekt kann in der SAP NetWeaver-Plattform über die Transaktion „ZABAPGIT“ gestartet werden. abapGit verfügt über Online- und Offline-Funktionen. Die Offline-Funktion bezieht sich einerseits auf die Replikation eines lokalen ABAP-Pakets aus deinem System in den abapGit-Workspace. Andererseits erlaubt uns die Online-Funktion, mit Repositories zu arbeiten. Was ist also ein Repository?

Ein Repository, häufig als „repo“ abgekürzt, ist ein Ort, an dem alle Dateien für ein einzelnes Projekt gespeichert werden. Jedes Projekt hat sein eigenes Repository und kann über eine eindeutige HTTPS-Url angesprochen werden. Wir müssen dieses Repository mit einem bestehenden ABAP-Paket aus unserem System verbinden oder ein neues anlegen.

Fazit

Immer mehr Unternehmen und Entwickler auf der ganzen Welt haben sich entschieden, Git als zentrale Steuerungssoftware einzusetzen. In der Landschaft der SAP-Branche kommt abapGit den Entwicklern in Form eines in ABAP geschriebenen ABAP-Clients zu Hilfe, der von den Git-Funktionalitäten profitiert.

abapGit ist kostenlos, schnell und bietet ein konsistentes, skalierbares Modell. Ein weiterer großer Vorteil ist, dass abapGit automatisch geänderte Objekte in das remote Git-Repository schiebt und gleichzeitig eine Umgebung ist, die Parallelentwicklungen erleichtert. Es eignet sich am besten für die gemeinsame Nutzung von Code und für die Verfolgung von Änderungen im Entwicklungsprozess.

Wenn du eine zentrale Stelle für die Organisation des Quellcodes in deinen Projekten benötigst, ist abapGit das perfekte Werkzeug.

Bist du motiviert und möchtest mehr über das Thema erfahren? Gerne informieren wir dich über die Updates und stellen dir weitere interessante Themen und Projekte vor, an denen wir ebenfalls beteiligt sind. Bleib mit uns in Kontakt – folge uns auf LinkedIn, XING oder facebook!

Autor dieses Beitrags
Andra Atanasoaie Associate
Tel.: +49 (0) 7031 714 660 0
E-Mail: cluj@inspiricon.de
Neuerungen und Weiterentwicklungen mit ABAP ab NetWeaver 7.4

Weiterentwicklungen in ABAP – diese Neuerungen gibt es ab NetWeaver 7.40

ABAP wird einfacher, direkter und benutzerfreundlicher

Hallo zusammen,

heute werden wir mal wieder sehr technisch: Wir beschäftigen uns mit Neuerungen in ABAP. Nicht nur die Applikationen und Tools der SAP entwickeln sich weiter. Nein, auch an der SAP-eigenen Programmiersprache wird ständig weiter gearbeitet.

Wir werden euch in der nächsten Zeit häufiger Einblicke über die Sprache, die neuen Tools, Test-Möglichkeiten und vor allem den Einsatz im Umfeld von SAP BW und HANA geben.

Heute beginnen wir mit einigen Neuerungen, die sich in den letzten Jahren in ABAP ergeben haben. Da diese Änderungen immer vom jeweiligen System-Stand abhängen, kann es sein, dass sie für einige unter euch noch sehr neu, für andere bereits Jahre alt und für die nächsten noch nicht einmal verfügbar sind.

Rückblick auf NetWeaver 7.40

Mit dem NetWeaver-Release 7.40 gab es einige sehr interessante Neuerungen bzw. Veränderungen innerhalb von ABAP, die durchaus Einfluss auf die tägliche Arbeit eines Entwicklers haben können. Horst Keller von der SAP hat dazu hier einen sehr guten Artikel veröffentlicht.

ABAP 7.40 ist seit 2013 verfügbar. Seit diesem Zeitpunkt gab es über die verschiedenen Support-Packages noch weitere Anpassungen. Obwohl wir jetzt das Jahr 2017 schreiben, ist es für viele unserer Kunden noch neu oder erst jetzt verfügbar, da die Sprache mit dem jeweiligen NetWeaver-Release einhergeht.

Wir selbst hatten mittlerweile aber das Vergnügen bei einigen Kunden mit dieser Version und höheren (ABAP 7.5 ist ebenfalls verfügbar) zu arbeiten. Wie immer kostet es den einen oder anderen Entwickler Überwindung, die neuen Themen zu verwenden, da sie es eben anders gewohnt sind und es sicher mehr als einen Weg nach Rom gibt.

Zwei konkrete Beispiele für die Neuerungen in ABAP

Aber gehen wir ins Detail. Hier ein paar Beispiele, wie sich die Arbeit mit der Sprache ABAP verändert hat:

Für mich eine der angenehmsten Änderungen ist die INLINE DECLARATION. Wie man es auch aus einigen anderen Sprachen kennt, kann man nun durch solch eine Syntax direkt im Befehl die benötigten Datenelemente deklarieren.

Hier als Beispiel:

Vor 7.4 sah es so aus:

Data: WA type line_of_itab.

Loop at itab into wa.

Endloop.

 

Ab 7.4:

Loop at itab into DATA(WA).

endloop

 

Das Ergebnis besteht nicht nur darin, dass eine Zeile Quellcode eingespart wird, vielmehr findet dadurch auch eine implizite Typisierung statt. Diese Art der Deklaration funktioniert übrigens auch für Field-Symbols und andere Objekte.

Ein weiteres Beispiel für nützliche Anpassung ist der Value Operator:

Vor 7.4:

DATA itab TYPE t_itab.

DATA wa LIKE LINE OF itab.

 

wa-col1 = 1.

wa-col2 = 2.

APPEND wa TO itab.

wa-col1 = 3.

wa-col2 = 4.

APPEND wa TO itab.

 

meth( itab ).

 

Ab 7.5:

DATA(itab) = VALUE t_itab(

( col1 = 1 col2 = 2 )

( col1 = 3 col2 = 4 ) ).

meth( VALUE t_itab(

( col1 = 1 col2 = 2 )

( col1 = 3 col2 = 4 ) ) ).

 

Auch das ist eine Neuerung, durch die unnötige Zeilen und auch Befehle gespart werden können und in meinen Augen den Quellcode auch lesbarer machen.

ABAP vereinfacht vieles

Als weiteres Beispiel für Vereinfachung ist die Durchsetzung von LHS = RHS. Sprich Befehle wie Move A to B werden obsolet. Vielmehr sagt man einfach B = A und ist fertig. Der große Vorteil hiervon ist, dass diese Zuweisungen auch verkettet und in Funktions- bzw. Methodenaufrufen verwendet werden können.

Weitere Veränderungen machen sich ebenfalls in deutlich lesbarerem Code bemerkbar:

result = class=>do_something(EXPORTING p1 = … p2 = … IMPORTING p3 = … p4 = … CHANGING p5 = … p6 = … ).

ABAP bewegt sich hier gefühlt immer weiter in Richtung JAVA und anderen Sprachen, die es erlauben, Methoden-Aufrufe auch mit komplexeren Parametern In-Line zu übergeben. Mit 7.4 funktioniert das jetzt auch bei Exporting- und Changing-Parametern – vorher war das nur mit Importing-Parametern möglich.

Drei neue Befehle für Transformationen

Drei neue Befehle, die ich persönlich vor allem in Transformationen gerne verwende, sind folgende:

DATA(lin) = lines( itab).

DATA(idx) = line_index( itab[ … ] ).

IF line_exists( itab[ … ] ).

ENDIF.

 

Diese Befehle vereinfachen das Prüfen von Tabellen. Sie geben die Anzahl der Lines, den Index einer Bedingung sowie das Ergebnis einer Prüfung zurück. Mit allen Werten kann direkt weiter gearbeitet werden. Vor 7.4 mussten diese Werte-Prüfungen immer erst mit READ-Befehlen ermittelt werden. Diese Befehle konnten nicht verkettet werden. Das hatte zur Folge, dass mit Hilfsvariablen und ähnlichen Konstrukten gearbeitet wurde, was den Code nur bedingt lesbarer gemacht hat.

Ihr habt Interesse an ABAP oder braucht einen Spezialisten in diesem Bereich? Wenn ihr Fragen oder Anmerkungen habt, schreibt mir gerne eine E-Mail an joerg.waldenmayer@inspiricon.de.

Autor dieses Beitrags
Jörg Waldenmayer Lead Consultant
Tel.: +49 (0) 7031 714 660 0
E-Mail: info@inspiricon.de