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
ABAP-Eclipse

So profitierst du von den ABAP Development Tools in Eclipse

Wann hat alles angefangen?

ABAP-Anfang-1992

Über die Jahre wurden die Lösungen immer besser, so auch die ABAP Development Tools.

Unabhängig von der klassischen SAP-GUI-basierten Entwicklungsumgebung besteht auch die Möglichkeit zur Entwicklung von ABAP-Anwendungen in Eclipse.

ABAP-Anfang-2009

Durch die Bereitstellung der ABAP Development Tools innerhalb einer integrierten Entwicklungsumgebung wird die Arbeit von Entwicklern erheblich erleichtert.

ABAP-Eclipse-2011

In Eclipse lassen sich gleich mehrere Tools in einem Programm nutzen.

Add-ons wie SAP HANA Database Studio, ABAP Development, SAPUI5, BW Modeling Tools und viele mehr wurden zur Freude jedes SAP-Beraters eingebunden.

In diesem Artikel beschäftigen wir uns daher mit der Installation und richtigen Nutzung der ABAP Development Tools (ADT) in Eclipse.

Bevor wir aber mit der Einführung loslegen, möchte ich euch schnell noch ein paar Hintergrundinformationen zu unseren Umgebungen geben.

Voraussetzungen:

  • Eclipse IDE – ihr benötigt eine geeignete Installation, die die gewünschten Tools unterstützt.

Bitte beachtet, dass die Mars-Version nicht mehr unterstützt wird. Wir empfehlen die Nutzung von Oxygen oder Neon.

  • Ab JRE (Java Runtime Environment) 1.6
  • Ab SAP GUI 7.2
  • Betriebssystem: Windows 7, Mac, Linux

Nützliche Links:

Für die im Folgenden beschriebenen Verfahren kamen bei uns Eclipse Neon.3 Release (4.6.3) sowie SAP GUI 7.4 auf Windows 7 Professional, 64-Bit zum Einsatz.

Einrichten der ABAP Development Tools (ADT)

Für die nächsten Schritte gehen wir davon aus, dass SAP GUI und Eclipse bei dir bereits installiert sind. Tauchen wir also ein in die Welt von ABAP.

Rufe zur Installation des für die ABAP-Entwicklung benötigten Plug-ins im Eclipse-Startbildschirm das Hilfe-Menü auf und klicke auf „Install New Software“.

Install-new-software-eclipse

Nun müssen wir angeben, wo die ABAP Development Tools (ADT) zu finden sind. Klicke dazu auf „Add“ und gib den Pfad der gewünschten Pakete ein.

select-site-location-eclipse

browsed-location-eclipse

Da Eclipse eine Plattform für die Integration einer Vielzahl von Add-ons bietet, nutzen wir das zu unserem Vorteil und laden gleich alle benötigten Komponenten herunter, um in den Genuss der ABAP-on-Hana-Entwicklung zu kommen.

filter-text-eclipse

Du musst dazu nur der Lizenzvereinbarung zustimmen. Mit einem Klick auf „Finish“ wird die Installation gestartet. Wenn bei dir bereits einige dieser Komponenten installiert sind, wird stattdessen ein Update durchgeführt.

installing-software-eclipse

Nach dem Download und der Installation der Pakete muss Eclipse zunächst neu gestartet werden.

restart-eclipse

Nach Abschluss des Neustarts sollte nun das „Welcome“-Fenster in Eclipse angezeigt werden.

Keine Sorge, falls sich hier einige Inhalte von deiner Installation unterscheiden sollten. Zwischen den einzelnen Produkten sind gewisse Unterschiede ganz normal und hier wird nur eine Übersicht des Produktes und seiner Funktionen angezeigt.

overview-eclipse

Jetzt, wo die Installation abgeschlossen ist, müssen wir im nächsten Schritt nur noch zur ABAP-Perspektive wechseln. Klicke dazu im „Window“-Menü auf „Perspective“ → „Open Perspective“ → „Other“.

open-abap-option

Wähle die ABAP-Option aus und schließe das „Welcome“-Fenster.

select-abap-option-eclipse

Wie sieht die ABAP-Perspektive in Eclipse aus?

Die ABAP-Tools sind auf dem Bildschirm übersichtlich angeordnet, um dir die Entwicklungsarbeit zu erleichtern. Du kann die Ansichten aber auch jederzeit ganz individuell an deine Anforderungen anpassen.

views-adaptation-abap

Bevor wir jetzt mit der eigentlichen Programmierung loslegen, müssen wir sicherstellen, dass alle Services im ABAP-Backend-System aktiviert sind.

Melde dich dazu am SAP GUI an und rufe die Transaktion SICF auf. Gib im Feld „Virtual Host“ „DEFAULT_HOST“ ein und klicke auf „Execute“.

activated-services-abap

Dabei müssen die folgenden zwei Punkte überprüft werden:

1. Services:

Erweitere dazu den Knoten „default_host“ und klicke danach auf „sap“ → „bc“ → „abap“. Öffne nun für „docu“ und „toolsdocu“ jeweils per Rechtsklick das Kontextmenü und klicke auf „Activate Service“.

check-services-abap2. Links:

Als nächstes müssen wir noch sicherstellen, dass die Pfade für einige bestimmte ABAP-Links für die Entwicklung hinterlegt sind.

Erweitere dazu den Knoten „default_host“ und klicke danach auf „sap“ → „public“ →  „abap“. Auch hier öffnest du für die Einträge „docu“ und „toolsdocu“ jeweils per Rechtsklick das Kontextmenü und klickst auf „Activate Link“.

check-links-abap

Jetzt kann die Verbindung mit dem SAP-System hergestellt werden.

Und schon können wir mit der ABAP-Entwicklung in Eclipse loslegen

Für eure ersten Schritte bei der Entwicklung von ABAP-Programmen in Eclipse möchte ich euch nahelegen, erst einmal mit einem einfachen Programm einzusteigen. Zu diesem Zwecke erstellen wir im Folgenden ein „Hello World“-Projekt.

Klicke zum Anlegen eines neuen Projekts auf „File“ → „New“ →  „ABAP Project“.

new-project-abap

Das ABAP-Backend muss für Entwicklungszwecke konfiguriert werden. An dieser Stelle müssen wir die Details für die Systemverbindung definieren.

Hier gibt es für uns zwei Optionen:

1. Erstellen einer neuen Verbindung

Ein Dialogfenster wird angezeigt. Klicke hier auf „new system connection“.

create-new-connection-abap

Gib im Anschluss deine System-ID, den Namen des Anwendungsservers und die Instanznummer ein.

server-name-abap

2. Auswahl einer bestehenden Systemverbindung

Wenn du in der Vergangenheit bereits eine Systemverbindung angelegt hast, musst du diese nur aus der Liste der verfügbaren Verbindungen auswählen.

existing-system-connection-eclipse

Gib die Anmeldedaten ein, die auch für das SAP GUI verwendest, und klicke danach auf „Next“, um dich anzumelden und die Kompatibilitätsinformationen aus dem Backend-System abzurufen.

retrieve-compatibility-eclipse

Sobald die Verbindung erfolgreich hergestellt wurde, gib einen sprechenden Namen für dein Projekt ein und klicke auf „Finish“.

project-naming-eclipse

Dein neu angelegtes Projekt sollte jetzt in der „Project Explorer“-Ansicht angezeigt werden.

appearance-new-project-eclipse

Um die Programmierungsbarriere zu durchbrechen, brauchen wir jetzt ein Programm. Öffne mit einem Rechtsklick auf ein Paket unter dem Knoten mit dem Projektnamen das Kontextmenü und klicke danach auf „New“ → „ABAP Program“.

break-coding-abap

Wähle einen technischen Namen für dein Programm aus, gib eine entsprechende Beschreibung ein und klicke auf „Next“, um zum nächsten Schritt zu gelangen.

technical-name-abap-project

Hier musst du einen Transport auswählen, über den das Programm gespeichert werden soll, andernfalls muss ein neuer Auftrag angelegt werden.

In unserem Fall muss für das $TMP-Paket kein Transportauftrag ausgewählt werden.

$TMP-package

Der ABAP Editor wird angezeigt. Gib den ABAP-Code aus dem Screenshot unten oder deinen eigenen anzuzeigenden Text ein.

type-message-display

Jetzt musst du dein Programm nur noch speichern und aktivieren. Führe es jetzt als eine ABAP-Anwendung aus.

run-abap-application

Das war’s schon! Wir haben erfolgreich unser ABAP-“Hello World“-Projekt angelegt. War ganz einfach, oder?

Fazit

Wir können uns glücklich schätzen, dass IT-Experten Hand in Hand arbeiten und eine kontinuierliche Optimierung des ABAP-Stacks für HANA anstreben und gemeinsam ABAP-Code in einer zeitgemäßen integrierten Entwicklungsumgebung entwickeln und sich untereinander austauschen. Dabei wird stets berücksichtigt, dass mit SAP HANA ein neues Technologiekapitel aufgeschlagen wurde.

Schon bald werde ich für euch an dieser Stelle einige der speziellen Funktionen in Eclipse und NetWeaver im Vergleich zur klassischen SAP-GUI-basierten Programmierung vorstellen und deren Aufbau erklären.

Also bleibt dran für weitere Einblicke und neueste Entwicklungen aus der Welt der ABAP-Programmierung. Ich freue mich schon auf eure Fragen und Kommentare.

Quellenangabe der Bilder: SAP SE, Inspiricon AG

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