Diesen Artikel habe ich ursprünglich im SAP Community Network veröffentlicht.
Einer der Hauptgründe, warum die Eclipse-Plattform als Grundlage für die neue ABAP-Entwicklungsumgebung gewählt wurde, ist ihre Erweiterbarkeit. In fast jeder Einführung in ADT, die ich bisher gesehen habe, wird der zusätzliche Nutzen betont, der durch die Kombination von Plug-ins aus verschiedenen Quellen erzielt werden kann. Ich benutze Eclipse schon seit einiger Zeit (seit etwa Version 3.2 oder 3.3), habe meine eigenen Eclipse-basierten Tools entwickelt und bin zwar sicherlich kein Experte, kenne mich aber mit den Grundlagen der Implementierung und Erweiterung von Eclipse-Plug-ins aus.
Bisher habe ich ADT mehr oder weniger ignoriert – hauptsächlich, weil unsere ABAP-Umgebungen zu veraltet waren, um ADT zu verwenden. Dies ändert sich langsam, also nutzte ich die Gelegenheit und besuchte die Einführungs-Session DEV165 auf diesjährigen SAP TechEd && d-Code in Berlin. Zurück zu Hause wollte ich den Anspruch der Erweiterbarkeit auf die Probe stellen. Mein Ziel war es, ein Plug-in zu erstellen, das eine vorhandene Schnittstelle nimmt und eine vorgefertigte Implementierungsklasse nach bestimmten Regeln generiert. Die Details sind hier nicht von Bedeutung – ich werde wahrscheinlich später darüber schreiben, wenn es etwas zu sehen gibt.
Meine Idee war es, die Projekt-Explorer-Ansicht so zu erweitern, dass man mit der rechten Maustaste auf die Schnittstelle klicken und eine Art Assistenten starten kann, der eine Klasse für die Schnittstelle erstellt. Die Erweiterung des Projekt-Explorers ist eine häufige Aufgabe in der Eclipse-Welt, daher gibt es eine Reihe von Tutorials. Wenn Sie mitprogrammieren möchten, würde ich empfehlen, dieses Tutorial als Ausgangspunkt zu verwenden.
Der nächste Schritt wäre, die Menüerweiterung so einzuschränken, dass der Kontextmenüeintrag nur für Schnittstellen
angezeigt wird. Dies ist relativ einfach, man müsste lediglich eine Bedingung zur Erweiterung hinzufügen. In diesem Fall
dachte ich, dass eine instanceof-Bedingung ausreichen sollte, also habe ich das von der PDE bereitgestellte Plug-in
Spy verwendet, um mehr über die Schnittstelleneinträge im Projekt-Explorer zu erfahren (wählen Sie eine Schnittstelle im
Projekt-Explorer aus und drücken Sie dann Alt+Umschalt+F1).
Unter anderem können Sie sehen, dass die aktuelle Auswahl (was hier am wichtigsten ist) eine TreeSelection ist,
die einen AbapRepositoryInterfaceNode enthält. Mit diesen Informationen ist es möglich, den Eintrag im Popup-Menü auf
Schnittstellen zu beschränken:
Im Befehlshandler würde man normalerweise den zentralen Auswahlservice verwenden, um herauszufinden, auf welche Objekte der Befehl angewendet werden soll. In dem oben erwähnten Tutorial gibt es ein grundlegendes Beispiel, bei dem die Auswahl untersucht und dann das ausgewählte Objekt in eine geeignete Klassen- oder Schnittstellenvariable umgewandelt wird. Hier fängt der Ärger erst richtig an…
Wenn man versucht, die Klasse AbapRepositoryInterfaceNode“ in der [ADT SDK-Dokumentation](http://scn.sap.com/docs/DOC-40894) nachzuschlagen, hat man Pech – wie der vollqualifizierte Klassenname com.sap.adt.oo.ui.internal.interfaces.projectexplorer.AbapRepositoryInterfaceNode` andeutet, handelt es
sich hierbei um eine interne Implementierungsklasse, und die meisten objektspezifischen Klassen sind ohnehin nicht
dokumentiert. Das ist nicht gut – es ist zwar immer noch möglich, weiterzumachen, aber es macht die Dinge für
Möchtegern-Mitwirkende viel schwieriger.
Mit ein paar schmutzigen Tricks ist es möglich, eine Vererbungsstruktur von AbapRepositoryInterfaceNode
zusammenzustellen. Allerdings sieht es nicht allzu vielversprechend aus:
Mit der dokumentierten API kann man herausfinden, zu welchem Projekt die Schnittstelle gehört, und das war’s auch schon.
Bei einem durchschnittlichen Eclipse-Plug-in wäre das ärgerlich, aber nicht allzu ungewöhnlich – es gibt eine Menge
Plug-ins mit einem ähnlichen Grad an (Nicht-)Dokumentation. An diesem Punkt würde man anfangen, sich in den Quellcode zu
vertiefen, um etwas über die Struktur von AbapRepositoryInterfaceNode und seiner Oberklassen und Schnittstellen,
anderer Klassen, die es verwenden, und vielleicht einiger Service-Implementierungen zu erfahren. In der Regel würde man
sich innerhalb einer angemessenen Zeit ein Verständnis für die internen Abläufe verschaffen können. Das ist in diesem
Fall nicht möglich, einfach weil der Quellcode nicht öffentlich verfügbar ist. Wir müssen weiter raten, was in diesem
Fall einfach ist: Ein TreeNode hat eine generische Möglichkeit, einen Wert an den Knoten anzuhängen. Ein kurzer Blick
mit dem Debugger zeigt, dass der Knoten auf diese Weise tatsächlich das Objekt verfolgt, das er darstellt:
Also, ein RepositoryObjectListItem, schauen wir mal im SDK nach – hoppla, schon wieder interne Dinge. Diese Klasse
implementiert IRepositoryObject, das ebenfalls undokumentiert ist, aber zumindest grundlegende Informationen über die
ausgewählte Schnittstelle liefert:
Soweit, so gut, aber jetzt interessiert man sich vielleicht für den Inhalt der Schnittstelle. An dieser Stelle würde man wahrscheinlich die Funktion References in Workspace (Strg+Umschalt+G) verwenden, um herauszufinden, wo die Schnittstelle verwendet wird und was man damit tun könnte – aber auch dies gilt nur für Open-Source-Projekte, bei denen der Quellcode zur Verfügung steht.
Im Moment sieht es so aus, als wäre hier Endstation – wer weiterkommen will, muss einen Schutzhelm aufsetzen∑, die schweren Maschinen auspacken und dabei wahrscheinlich gegen einige Bestimmungen der Lizenzvereinbarung verstoßen.
Ich hätte heute gerne über etwas anderes gebloggt, etwas, das einer Umsetzung etwas näher kommt, aber das war nicht möglich. Ein paar wichtige Erkenntnisse aus meiner Sicht:
- Die Erweiterbarkeit ist nicht automatisch in der Plattform enthalten, sie muss in der Architektur und Implementierung jedes einzelnen Aspekts des Produkts berücksichtigt werden. Ein Eclipse-Plug-in kann genauso isoliert und schwer erweiterbar sein wie jede andere kommerzielle Anwendung.
- Die Erweiterbarkeit anderer Produkte besteht größtenteils in der Möglichkeit, die vorhandenen Inhalte zu untersuchen. Dies gilt nicht nur für Eclipse, sondern auch für die SAP NetWeaver-Plattform und die darauf aufbauenden Anwendungen. Stellen Sie sich vor, Sie müssten ein BAdI ohne Zugriff auf die umgebende Anwendung implementieren zu müssen…
- Dokumentation ist kein Ersatz für den Zugriff auf den Quellcode, es sei denn, sie ist wirklich umfassend und gut gepflegt.
- Ebenso ist der Zugriff auf den Quellcode kein wirklicher Ersatz für die Dokumentation – sie sagt Ihnen, wie die Dinge aufgebaut sind, aber nicht warum.