Erfahrungen mit Eclipse

Erfahrungen mit Eclipse

Hallo zusammen,

ich bin gerade dabei mich mal ein wenig mit Eclipse für ABAP-Entwicklung auseinanderzusetzen.
In Topic https://www.abapforum.com/forum/viewtop ... 18&t=20904 habe ich auch schon viele Erfahrungen lesen können, da das Thema jedoch schon recht alt ist (letzter Beitrag > 1,5 Jahre alt) und sich seitdem sicher einiges geändert hat, hab ich ein neues Thema eröffnet. (Wenn das nicht gewünscht ist bitte schließen)

Mich interessieren eure Erfahrungen mit Eclipse, was sind Stärken / Schwächen was hat euch den Umstieg erleichtert / was vom Umstieg abgehalten etc.
Zudem habe ich ein, zwei konkrete Fragen zu Eclipse.

Grundsätzlich ist mir klar, dass klassische Dynpros nicht mit Eclipse funktionieren (werden) und andererseits CDS-Views wohl nicht in der SAP-Gui, auf diese Themen möchte ich gar nicht weiter eingehen.
Mir persönlich sind bisher folgende Dinge negativ aufgefallen:
- Anlage von DDIC-Objekten springt in die SAP-GUI, ist jetzt kein Drama aber wirkt für mich nicht "rund"
- Keine Möglichkeit Parametertexte zu pflegen
- Keine Unterstützung von impliziten Enhancements

Als positiv empfinde ich bisher:
- Quick Assist & Quick Fix
- mehr als sechs Modi parallel
- Funktionen wie "ALT + U" (delete unused variables)

Was mir aktuell noch Probleme bereitet, sind die von der SE80 abweichenden Tastaturbelegungen.
Die Navigation mit STRG+Klick statt per Doppelklick ist so ein Beispiel an das ich mich erst gewöhnen muss...
Mal sehen, wie lange es dauert, bis ich damit zurecht komme...

Re: Erfahrungen mit Eclipse

Also, das mit den Parametertexten - dazu gibt es Abgleichfunktionen zwischen ABAPDoc und SAPGUI. In der Tat ist die schlechte Dokumentationsfähigkeit (es gibt kein Pendant zur SAPscript-Doku in der SE80) einer meiner größten Kritikpunkte. Dafür gibt es Funktionalitäten (die hast du ja erwähnt), die SAPGUI nicht bietet.


Ralf

Re: Erfahrungen mit Eclipse

Daniel hat geschrieben:Ich sitze hier vor einem S/4 und alles ist wie gewohnt (minimale Änderungen).

Naja, das ist immer die Frage, wie tief man im S/4 arbeitet. Wie arbeitest du denn in der SAPGUI mit CDS-Views? Wie schreibst du Fiori-Apps in der SAPGUI? Kann sein, dass das irgendwie geht, ich wüsste halt nicht, wie. Wenn ich natürlich "nur" auf der Kompatibilitätsschicht herumhämmere (wofür es gute Gründe geben kann) und eine Menge S/4-Vorteile nicht nutze, dann ist die Umgebung natürlich egal. Dann kann ich auch die Bestände konventionell lesen, wie ich das seit 20 Jahren mache. Dann weiß ich aber nicht, warum ich ein S/4 einsetze. Das ist dann "nur" ein schnelleres SAP.

Die Bedeutung von S/4 ist strategischer Natur. Die SAP denkt nicht in Zeiträumen von 2, 3 oder 5 Jahren, die sind mit ihren strategischen Planungen deutlich weiter. Wenn man sich mit Leuten von der SAP unterhält, wird das schnell klar. Und "SAP in der Cloud" zum Beispiel ist aus verschiedenen Gründen von erheblicher Wichtigkeit, auch für unser aktuelles Projekt.

Die Landschaften werden heterogener, die Annäherung von ABAP an andere Programmiersprachen, was die Schreibweisen angeht, kommt ja nicht von ungefähr. Da sind dann Insellösungen immer eine schlechte Idee.

Daniel hat geschrieben:Sowohl SAPGUI als auch DDIC sind noch lange unverzichtbar.

Auch das hängt sehr von der Umgebung ab. Klar, wenn man beim Anwender sitzt, der im Wesentlichen dasselbe macht wie vor dem Wechsel zu S/4, dann ist das richtig.

Aber je heterogener und moderner man in der Entwicklung arbeiten muss, umso verzichtbarer wird die SAPGUI (ein konkretes Beispiel bringe ich weiter unten). Wenn du ein Softwareunternehmen hast, das sich auf Eclipse-Basis eine eigene Entwicklungsumgebung baut, die verschiedene Umgebungen in sich vereint, willst du keine Insellösungen mehr.

Das DDIC will ja gar keiner abschaffen, die SE11 ist nicht das DDIC, sondern die UI für das DDIC. Und dass sich sowas nicht in zwei Wochen programmiert, sollte klar sein.

Daniel hat geschrieben:Das ist alles nur in Ansätzen zusammengebastelt und wird auch nie mehr rund werden. Eigentlich schade.

Naja, "nie" würde ich nicht sagen, das ist alles noch sehr neu. Es gibt eine ganze Reihe von Gründen, warum zumindest auf Anwenderseite der Trend weggeht von der SAPGUI. Und auch wenn nicht alles in UI5 so rund ist wie es sein sollte, dann ist es eine Frage der Zeit, bis das zunehmend besser wird. Ob man nun die Entwicklungswerkzeuge in der SAPGUI baut oder mit Eclipse oder sonstwie ist eigentlich egal. Denn der ABAP entsteht letztlich immer auf dem Server, egal wie der Editor heißt. Lokal wird man nie entwickeln können.

Ein Blick zurück veranschaulicht das: Ich hab 96 ganz schön geflucht, dass sich eine SAPGUI sehr veraltet anfühlt im Vergleich zu Anwendungen, die ich damals schon kannte. Inzwischen ist die SAPGUI moderner, aber es gibt Umgebungen, wo SAPGUI-Anwendungen einfach nicht gewünscht sind. Ich hab hier einen Produktionsleiter, der auf dem Handy eine Notification sehen will, von der aus er eine Produktionsfreigabe direkt am Telefon machen kann.

Da kannst du noch so viele schöne SAPGUI-Anwendungen schreiben, der Anwender wird nicht zufrieden sein.



Ralf

Re: Erfahrungen mit Eclipse

zzcpak hat geschrieben:Die Idee ist sicherlich nicht ganz schlecht, aber die Umsetzung erscheint mir halbherzig, auch weil man GUI vermutlich noch lange weiterverwenden wird.

Man muss unterscheiden zwischen der strategischen Entscheidung und der Frage, ob man alle Kapazitäten da reinsteckt. Das sind unterschiedliche Zeithorizonte. So wie SAPscript bis heute nicht tot ist, obwohl es bereits den Nachfolger des Nachfolgers gibt.


Ralf

Nachtrag: Noch ein Beispiel: Im Moment wünschen wir uns ein S/4, weil wir konkurrierende Warenbewegungen haben, die sich ihre Materialstämme gegenseitig sperren. Ein Problem, das es unter S/4 nicht mehr gibt....

Re: Erfahrungen mit Eclipse

ralf.wenzel hat geschrieben:Noch ein Beispiel: Im Moment wünschen wir uns ein S/4, weil wir konkurrierende Warenbewegungen haben, die sich ihre Materialstämme gegenseitig sperren. Ein Problem, das es unter S/4 nicht mehr gibt....

Ein Problem daß es schon unter R/2 nicht gab,
es sei denn man macht sehr viel falsch ...
Wie sonst könnten Firmen mit 30.000 oder 40.000
Usern mit so einem System arbeiten?
Da wäre ja "immer alles" gesperrt. Es hilft wenn man
sich mit der Architektur des Systems mal wirklich
befasst und nicht nur Blogs von Journalisten liest.

Re: Erfahrungen mit Eclipse

schick hat geschrieben:...
Andererseits kann ich mir auch gut vorstellen, dass man mit einigen Unwägbarkeiten (nach gewisser "Anlaufphase") schon zurecht kommen wird. Es muss letzten Endes jeder für sich entscheiden ob die Vor- oder Nachteile überwiegen. Ich kann mir jedenfalls gut vorstellen einige Funktionen schnell nicht mehr missen zu wollen.

Dazu kann ich mich direkt selbst zitieren, da sich im Tenor noch nichts genändert hat.

black_adept im anderen Thread hat geschrieben:Und so gerne ich auch Eclipse verwenden würde um mit der Zeit zu gehen - meine Kunden bezahlen mich i.A. dafür Lösungen in akzeptabler Zeit anzubieten. Und momentan sehe ich nicht, dass mich - auch nach einer Einarbeitungszeit um die Mankos auszugleichen, die mir momentan mangels Eclipse-Erfahrung in die Quere kommen- Eclipse besseren Code oder gleich guten Code mindestens ebenso schnell erstellen lässt. Wenn allerdings umfangreichere Umbennennungen oder anderes Refactoring anstehen scheint es mir opportun dafür kurz Eclipse zu starten um die hier vorhandenen Möglichkeiten gewinnbringend zu nutzen.

Re: Erfahrungen mit Eclipse

[quote="ralf.wenzelDann erkläre mir doch mal, wie ich 1000 Warenbewegungen buche (desselben Materials), ohne dass jede Warenbewegung warten muss bis die vorherige abgeschlossen ist.[/quote]
Der Verbucher arbeitet aus gutem Grund streng sequentiell.

Re: Erfahrungen mit Eclipse

Daniel hat geschrieben:[quote="ralf.wenzelDann erkläre mir doch mal, wie ich 1000 Warenbewegungen buche (desselben Materials), ohne dass jede Warenbewegung warten muss bis die vorherige abgeschlossen ist.

Der Verbucher arbeitet aus gutem Grund streng sequentiell.[/quote]

Ich dachte, das sei kein Problem. Das Problem ist, dass eine Warenbewegung den Materialstamm sperrt, weil der Bestand geändert werden muss (der eben blöderweise im Materialstamm steht). Wenn dann keine Materialstämme mehr gesperrt werden müssen für Warenbewegungen (weil man nur noch MSEGs schreibt), gibt es das Problem nicht mehr, weil man eben auch parallel buchen kann.


Ralf