Entwicklung mit Eclipse im klassischen R/3 - Stand Dez.2015

Entwicklung mit Eclipse im klassischen R/3 - Stand Dez.2015

Habe mir gerade für zwei Kundensysteme (7.40, SP4 und 7.40, SP8 ) mal die neuesten ADT ( ABAP Core Development Tools ) geladen ( Version 2.54.2 ) mit der aktuelle Eclipse-Version ( mars ) geladen um zu schauen, ob sich in den letzten Jahren etwas vom Handling her verbessert hat. Ich werde diesen Thread jetzt einfach starten und ergänzen, wenn mir weitere Sachen auffallen - egal ob gut oder schlecht.

1.) Installation:
Hat sich schon stark verbessert gegenüber den ersten Versionen. Inzwischen ist es absolut ausreichend sich die neueste Eclipse-Version zu laden und dann von https://tools.hana.ondemand.com/mars die neuesten ADT automatisch installieren zu lassen. All die Verrenkungen, die man anfänglich machen musste sind passé - es ist inzwischen sehr einfach und problemlos.

Was mir momentan noch fehlt ist die Möglichkeit die Sprache der ADTs umzustellen. Aktuell arbeite ich mit einem englischen Eclipse ( kein Sprachpack dazugeladen ), aber die ADT kommen alle in deutsch daher. Ich hätte das gerne einheitlich englisch, aber die zugehörigen Einstellmöglichkeiten finde ich bisher nicht.

2.) Verbinden mit dem SAP-System:
Positiv:

• Man kann aus der SAPLOGON.ini das System auswählen

Verbesserungsmöglichkeiten:

• Wenn schon SAPLOGON.ini zur Auswahl, dann doch bitte auch die evtl. vorhandene Ordnerstruktur verwenden

3.) Project Explorer , Search, Generelles Seupt
Positiv:

• Einigen DDIC-Objekttypen sind in der Zwischenzeit verschiedene Icons verpasst worden, so dass man diese auseinander halten kann trotz gleichen Namens. Leider sind noch immer viele Objekttypen mit dem selben Icon versehen
• In der Suche ist verschiedenen DDIC-Objekttypen der DDIC-Typ in Klammern hinten angestellt. Leider sind noch immer viele Objekttypen nicht mit diesem Zusatz versehen
• Ich mag ein angedocktes "ABAP-Elementinformation" angedocktes Fenster, in dem man schnell die Info zu einem Element sehen kann ohne F2 drücken zu müssen

Verbesserungsmöglichkeiten:

• Immer noch fehlt im Projectexplorer jegliche Art von Dokumentation die zu Objekten hinterlegt ist. Da ist die alte SE80 immer noch um Meilen voraus
• In der Objektsuche kann man nicht nach speziellen Arten von Objekten suchen
• Die Navigation in Nicht-Coding-Elemente ( DDIC-Objekte wie DTEL,DOMA, etc ) landet immer in einem GUI-Modus. An sich ja ok, da man dann sieht was man benötigt. Aber wenn Eclipse die gute alte SAPGUI ablösen soll, man aber ebendiese benötigt um sich DDIC-Elemente anzeigen zu lassen ist das nicht konsequent. Und schließlich - jede Navigation öffnet ein neues Fenster inkl. einer neuen Anmeldung am SAP-System. Wenn man da sowohl englisch als auch deutsch unterwegs ist, bekommt man bei jeder Navigation beim Sprachwechsel das lästige Copyright-Popup welches man dann wegklicken muss.

4.) Klassen und Reports

Positiv:

• Man kann inzwischen ABAPDoc aus den Kommentaren der SE24 in generieren lassen. ( funktionierte früher nicht )
• ABAPDoc schlägt "klassische" Dokumentation. Aber inzwischen wird bei fehlender ABAPDoc die SE24-Dokumentation angezeigt. ( funktionierte früher nicht )
• Refactoring ist deutlich! mächtiger als mit der SAPGUI Einer der Gründe, die stark für die Verwendung von Eclipse sprechen
• Schicke Features, wie z.B. "Nicht verwendete Variablen löschen ( Auswahl oder alle )", die bisher nur mühselig zu machen waren

Verbesserungsmöglichkeiten:

• Die Sprachumgebung in Eclipse ist nicht eindeutig. Wenn ich in einem Sourcecodefenster das Kontextmenü aufrufe bekomme ich eine Mischung aus deutschen und englischen Menüpunkten.
  Beispiel:
  -Link für Auswahl freiben -"Run As" -"Debug As" -"Profile As" -"Abdeckung als" -"Compare with"
  stehen so untereinander und als Untermenü von "Compare with" öffnet sich die Liste: -"Lokale Historie" -"Each other" -"Überarbeitungshistorie"...
• Vorwärtsnavigation für FORM-Routinen weiterhin nicht unterstützt, für Methoden hingegen schon.
• Methoden werden via Vorwärtsnavigation nur aus Klassen heraus angelegt aber nicht aus einem Report-Rahmenprogramm
• Vorwärtsnavigation zum Anlegen von Programmtexten ( Variable = 'Hugo'(001) ) so wie bei mehrsprachiger Programmierung benötigt ist nicht möglich ( noch kein Showstopper -aber sehr dicht dran)
• Menüeinträge, die nicht das machen was da steht. Beispiel: Quelltext->Kommentar ein-/ausblenden macht etwas anderes ( Existierende Zeile wird zwischen auskommentiert und kommentiert hin- und hergeschaltet )
• Implizite Enhancementpointunterstützung fehlt
• Modifikationsassistent fehlt. Genau genommen kann man Quelltexte aus anderen Sourcesystemen, wo in der alten GUI der Modifikationsassi anspringt einfach ändern. Es gibt aber einen Hinweis beim der 1. Änderung, dass das Coding ein anderes Originalsystem hat
• Ich habe keinen expliziten "Anzeigemodus" gefunden

Showstopper: Für mich ein Grund NICHT in Eclipse entwickeln zu wollen

• Es ist immer noch nicht möglich sich einfach alle Methoden/Attribute/Typen einer Klasse anzeigen zu lassen, wenn diese von einer Oberklasse erbt. Man bekommt es zwar hin sich in der Schnellübersicht (STRG+O) dann auch die geerbten und nicht redefinierten Member der Klasse anzeigen zu lassen ( im Popup dann noch mal STRG+O), aber das Popup selber ist nicht andockbar, nicht sinnvoll gruppier- oder filterbar ( nur A-Z Sortierung, dann aber Methoden, Typen und Attribute gemischt )

5.) DDIC-Objekte
Da die meisten DDIC-Objekte in SAPGUI-Modi geöffnet werden anstatt eigene eclipse-Views zu öffnen, gibt es nur Kommentare zu tollem oder doofen Eclipse-Zusammenspiel
5.1.) Pakete
Verbesserungsmöglichkeiten:

• Man kann keine lokalen $Z... Pakete in die Favoritenliste einfügen und diese werden auch nicht von der Suche gefunden
• Nicht alle Objekte werden gefunden: Meine Installation gibt mir kein Resultat, wenn ich nach DEMO_CDS_PROJECTION suche, obwohl dieser Report sehr wohl vorhanden ist.

Fazit: Siehe anderes Posting in diesem Thread weiter unten

Re: Entwicklung mit Eclipse - Stand Dezember 2015

Man sollte hier klar differenzieren. Eclipse ist gemacht für das Arbeiten in neuen Umgebungen. Ja, das geht auch mit R/3, sogar ganz gut, aber der eigentliche Hintergrund ist S/4, wo es dann definitiv keine SAPGUI mehr gibt und auch kein DDIC in der jetzt bekannten Form.

Für das R/3 wird es immer eine grundsätzliche GUI-Abhängigkeit geben, schon allein weil sowas wie der Screen-Painter oder der Menu Painter nicht ins Eclipse reinentwickelt werden, auch viele DDIC-Sachen nicht.

Zur SE80: Ich hab gerade mal geguckt (7.40 SP5), ich kann keinerlei solcher Refactoring-Funktionen finden.

Re: Entwicklung mit Eclipse - Stand Dezember 2015

larsi hat geschrieben:

ralf.wenzel hat geschrieben:Ja, das geht auch mit R/3, sogar ganz gut, aber der eigentliche Hintergrund ist S/4, wo es dann definitiv keine SAPGUI mehr gibt und auch kein DDIC in der jetzt bekannten Form.

Bist Du Dir bzgl. der SAP GUI da sicher? Das würde ja bedeuten, dass SAP alle Transaktionen mit Fiori nachgebaut haben müsste. So wie ich die Dokumente von SAP bislang verstanden habe, lebt die klassische SAP GUI auch unter S/4 (zunächst) weiter, wobei erste "Leuchttürme" als Fiori-Anwendung ausgeliefert werden.

Viele Grüße,
Lars

Dann hast du andere Informationen als ich. Ich halte es für ausgeschlossen, dass z. B. die Simple Finance-Transaktionen für die SAPGUI nochmal entwickelt wurden.

Re: Entwicklung mit Eclipse - Stand Dezember 2015

black_adept hat geschrieben:

a-dead-trousers hat geschrieben:Kurze Frage diesbezüglich: Wer von euch setzt 7.40 mit der alten SE80 ein? Funktioniert das Refactoring dort wirklich auch für die Verwendungen einer Methode/eines Attributs wenn man diese umbenennt?

Gerade bei einem Kunden geschaut, der 7.40 EHP8 und damit den Refactoring Assi hat. Das Einzige was geht, ist das verschieben von Methoden/Interfaceimplementierungen von einer Klasse in Sub- oder Superklassen

DAS gibt es schon seit Jahren - aber die Umbenennung von Variablen- und Methodennamen im Eclipse-Stil eben nicht.

Re: Entwicklung mit Eclipse im klassischen R/3 - Stand Dez.2

@verzweifelt & @Ralf: Guter Hinweis, dass es sich bei meiner Betrachtung um eine reine "alte-Welt"-Betrachtung handelt. Habe den Threadtitel umbenannt um dem gerechter zu werden.
Ich hoffe heute oder morgen meine Evaluation abschließen zu können um dann noch an diesem Wochenende ein persönliches Fazit abzugeben.

Re: Entwicklung mit Eclipse im klassischen R/3 - Stand Dez.2

Das Überschreiben von ABAP Doc durch SE24-Beschreibungen macht nur Sinn, wenn jemand Müll ins ABAP Doc schreibt, aber Ordentliches in die SE24 schreibt. Warum sollte man ein Programm schreiben, dass das korrigiert? So einen hängt man am nächsten Baum auf*, dann macht das so schnell keiner wieder. Alles andere geht automatisch und korrekt. Und ein bidirektionaler Abgleich erfordert immer eine Entscheidung darüber, was besser ist - für jeden einzelnen Kommentar.

*Disclaimer: Gemeint ist damit die digitale Variante: Mail mit harten Worten an ihn in Kopie an alle Entwickler, das sowas zu unterlassen ist.

Re: Entwicklung mit Eclipse im klassischen R/3 - Stand Dez.2

Wenn ich ABAP Doc schreibe und jemand öffnet die Klasse in der SE24, wird das ABAP Doc in die SE24 geschrieben. Ganz automatisch. Das ist die Vorgabe an ABAP Doc.

Du siehst: Du brauchst du ein Programm nicht.

Re: Entwicklung mit Eclipse im klassischen R/3 - Stand Dez.2

Eben. Kommt. Ganz ehrlich: Manchmal, wenn ich so höre, was manche alles wollen und dann bitte alles sofort, frage ich mich, ob die eine Ahnung haben, wie aufwendig jede kleine Erweiterung ist. Überlegt doch mal bitte, wie furchtbar SAP in Release 3.x war. Die Sachen werden nach und nach besser, das war immer so und das wird immer so bleiben.

Gemessen an dem, was die SAP alles am Start hat, ist Eclipse ein relativ kleines Loch, das die bohren.

Klar kann man sich fragen "warum waren nicht immer alle Telefone so einfach wie das iPhone?". Aber da muss man eben erstmal hinkommen...