ABAP für uns Java-Programmierer Teil III

ABAP Entwicklungsumgebung

Die ABAP Entwicklungsumgebung ist für den Java Entwickler meist zunächst ein Kulturschock. Gewohnt ist man eine IDE im Eclipse Stil und die ABAP Workbench passt nicht so recht in die gelernten Sehgewohnheiten. Zum Glück sind die Zeiten des sogenannten klassischen ABAP Editors mit begrenzter Zeilenlänge aber vorbei.

Klassischer ABAP Editor 

Rund um die ABAP Workbench steht eine Vielzahl von Hilfsmitteln und Tools bereit. Einige sind für Java Entwickler durchaus überraschend -was in der Regel daran liegt, dass sie überhaupt nur in der ABAP Welt sinnvoll sind und im Java Umfeld schwer denkbar sind. Grund ist die Tatsache, dass das gesamte Coding eine ABAP-Stacks auf dem Server abgelegt ist, dort editiert wird und eine gemeinsame große Laufzeitumgebung bildet.

Das gilt interessanterweise sowohl für die von SAP ausgelieferten Teile wie auch für die selbsterstellten Anwendungen. Insofern ist SAP NetWeaver quasi quelloffen – obwohl natürlich nicht Open Source im eigentlichen Sinne.

Die Transaktion SE80 wird in der Regel zum Einstieg in die Entwicklungsumgebung verwendet. Hier greift man per Name auf die verschiedenen Objekttypen zu, z.B. Klassen, Funktionsbausteine oder Programme.

Da alles in der Datenbank liegt, ist auch die Sicht auf die verschiedenen Elemente nicht wie gewohnt Datei-orientiert, sondern in integriert in die IDE in Tabellen, Tab-Reitern und Feldern organisiert. Der eigentliche Quellcode ist beispielsweise nur ein Teil einer Klassenansicht.

Ähnlich Java packages sind alle Objekte in einer Hierachie von Paketen organisiert.

Jeder Entwickler hat noch ein spezielles Paket für sich, für sogenannte lokale Objekte. Dieses Paket verwendet man für eigene Tests und Spielereien, die nicht weiter verwendet werden sollen. Denn Entwicklungen außerhalb der lokalen Objekte dürfen nicht beliebig neu angelegt werden, sondern brauchen immer eine Referenz auf einen Transportauftrag. Man kann sich als schon mal darauf vorbereiten, dass mit dem ersten neuen Objekt eine entsprechende Abfrage erscheint und dann sollte man sich einen Transportauftrag bereits besorgt haben – oder die Berechtigung einen anlegen zu dürfen.

Die schon erwähnte Eigenschaft, dass alle Entwicklungsobjekte in einem großen Repository auf dem Server liegen, ermöglicht der Entwicklungsumgebung einige schöne Features.

Die Möglichkeiten dieser Navigation

Ungeahnte Möglichkeiten ergeben sich durch die Vorwärtsnavigation, die auf nahezu allen Objekten möglich ist. In Java kennt man dies für die Klassen und Methoden des eigenen aktuellen Entwicklungsprojektes. Der ABAP Editor erlaubt einen viele größeren Navigationsbereich: Ein Klick auf einen Tabelle in einem SQL-Statement springt zur Tabellendefinition. Von dort geht es weiter zum Datentyp einer Tabellenspalte und weiter zu deren Domäne. Kaum angekommen navigiert es sich einfach zum Paket, in dem die Domäne definiert ist und schon weiß man nicht mehr, von wo man gekommen war.

Die Navigation ist auch deshalb so stark, weil sie eben über eigene und SAP-Objekte , über Datentypdefinitionen, Datenbanktabelle, Interfaces und Klassen usw. usw. ohne Hindernisse hindurch funktioniert.

Auch der rückwärtige Weg ist möglich: Der Verwendungsnachweis zeigt, wo überall in der gesamten Laufzeitumgebung ein Typ, eine Klasse oder eine Methode verwendet wird. Vorsicht übrigens: Die Suche kann tatsächlich “über alles” laufen und daher auch zum Teil ein wenig dauern.

Alles ist auf dem Server – aus diesem Grund gibt es nach dem Kompilieren auch keinen Buld-Prozess und kein Deployment. Stattdessen kennt jeder ABAP Entwickler die drei Schritte “Sichern – prüfen – aktivieren”. Damit wird geänderter Quellcode auf den Server gespeichert und die Syntaxprüfung aufgerufen. Nur wenn diese erfolgreich ist, kann aktiviert werden, das bedeutet die aktuell aktive Version eines Stück Software in der Laufzeitumgebung wird durch die neue Version ersetzt. Dies ist quasi das Äquivalent zum Deployment, wenn auch auf sehr kleinteiligem Niveau möglich.

Ein weiteres Beispiel für nützliche Helfer ist die Unterstützung beim schnellen Testen und Ausprobieren. Für Klassen wird via Testbefehl eine Instanz erzeugt, eine Eingabemaske für die gewünschte Methode generiert und dann mit abgefragten Parametern abgeschickt.

Weitere größere und kleinere Hilfsmittel und Werkzeuge wie zum Beispiel die integrierte Dokumentation und das Handling von Mehrsprachigkeit und sprengen hier natürlich den Rahmen. Aber es lohnt sich damit einmal zu beschäftigen.

Im nächsten Teil geht es dann um den Debugger – der braucht sich ebenfalls nicht zu verstecken.