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

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

black_adept hat geschrieben: { Hat jemand Lust mit mir ein Prog zu schreiben, welches ABAPDoc und SE24-Dokumentation gegeneinander in beiden Richtungen abgleichen kann ? Email steht unten }

Gibt es alternativ evtl. jemanden, der schon mit eclipse arbeitet auf einem R/3 System das die SE24 (noch) nicht automatisch mit updated? Bzw. in einem gemischten Entwicklerteam ist, wo evtl. Kollegen das ABAP Doc verwenden aber eben nicht alle, so dass ein SE24-Abgleich noch gewünscht wäre?
Habe momentan eine 1. Betaversion fertig und würde gerne etwas Feedback bzw. Betatestkommentare begrüßen.

P.S. Konnte endlich mal einen ABAP-Befehl einsetzen, den ich in meinem ganzen Programmiererdasein bisher nur ein einziges Mal zu Spielzwecken überhaupt benutzt hatte - allein dafür hat es sich schon mal gelohnt das Progrämmle zu schreiben

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

black_adept hat geschrieben: Gibt es alternativ evtl. jemanden, der schon mit eclipse arbeitet auf einem R/3 System das die SE24 (noch) nicht automatisch mit updated? Bzw. in einem gemischten Entwicklerteam ist, wo evtl. Kollegen das ABAP Doc verwenden aber eben nicht alle, so dass ein SE24-Abgleich noch gewünscht wäre?
Habe momentan eine 1. Betaversion fertig und würde gerne etwas Feedback bzw. Betatestkommentare begrüßen.

Ich nutze die ADT momentan in einem 7.31-Umfeld, was die Möglichkeiten leider deutlich einschränkt. Synchronisierung von ABAP Doc findet meines Wissens auch nicht statt. Ob ich dazu komme, einen Betatest zu machen weiß ich ehrlich gesagt nicht, zumal ich erstmal schauen müsste, was die Risiken für das System sind. Eine reine "Spielwiese" habe ich leider nicht zur Verfügung.

Thema Eclipse:

In absehbarer Zeit wird unsere DB durch eine HANA abgelöst, so dass die Anwendungsgebiete für Eclipse mittelfristig da sein werden. Daher sammele ich bewusst auch Erfahrung mit Eclipse, wenn es nicht zeitkritisch ist und vom Aufgabengebiet her passt. Und mittlerweile bin ich in Eclipse recht flott unterwegs.

Ich mag mich täuschen, aber ein wesentlicher Vorteil für mich ist die wegfallende Begrenzung auf sechs Modi. Außerdem kann ich gleichzeitig in DE und EN angemeldet sein und muss meine Übersetzung nicht per Neuanmeldung prüfen.

Überhaupt hindert einen niemand daran, beides einzusetzen. Eine Benachteiligung der SE80 durch die SAP ist mittelfristig wohl leider zu erwarten, da es wenig Sinn macht, zwei parallele Entwicklungsumgebungen weiterzuentwickeln. Und Eclipse wird durch die HANA immer wichtiger werden. Irgendwann wird man sich vermutlich genauso daran stoßen, dass man keine Core Data Services in der SE80 bearbeiten kann, wie an der fehlenden Dynpro-Funktionalität in Eclipse.

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

Hallo zusammen,
ich versuche mal ein paar Fragen aus dem Beitrag aus SAP-Sicht zu kommentieren:

1.) SE80 vs. Eclipse
Neuentwicklungen bzgl. ABAP IDE finden nur noch in Eclipse statt. Die SE80 wird weiterhin gewartet aber nicht mehr weiterentwickelt.
Wir versuchen das trotz der neuen Features in AIE ein Parallelbetrieb mit der SE80 für die klassische Entwicklung jederzeit möglich ist. Das gilt natürlich nicht für neue Konzepte wie CDS und AMDP.
Dafür gibt es in SE80 keine Tools.

2.) ABAP Doc
Wir empfehlen ab Release 7.40 ABAP Doc für Sourcecode und Schnittstellen Dokumentation zu verwenden. Ab Release 7.50 ist es möglich die Kurztexte der SE24 mit den ABAP Doc Kommentaren zu synchronisieren.
Ausserdem gibt es mit 7.50 die Möglichkeit ABAP Doc als externe HTML basierte Dokumentation zu exportieren.
Ich empfehle folgenden SCN Beitrag dazu: http://scn.sap.com/community/abap/eclip ... tweaver-75

3.) Anzeige der Kurztexte in Project Explorer
Ja, das ist eine Lücke die bei manchen Objekten sehr weh tun kann. Wollen wir mit dem nächsten Release fixen.

4.) Anzeige vererbter Methoden
Ja, auch das fehlt noch. Das wollen wir in den Type Hierarchy View integrieren analog zu den Java Dev. Tools
Das Feedback hier hilft bzgl. der Prio

5.) Refactoring
Refactoring ist ein sehr wichtiges Werkzeug in der Entwicklung speziell in der agilen Softwareentwicklung. Von daher ist das bei uns ein Schwerpunktthema.
Wir haben weitere Refactoring und Quickassists in der Planung. In 7.50 kamen z.B: die Getter/Setter Methoden hinzu und die Möglichkeit das Exceptionhandling zu vereinfachen.
Am besten mal in den Blog hier reinschauen: http://scn.sap.com/community/abap/eclip ... s-abap-750

6.) Zukunft SAP GUI
Ein Punkt habe ich noch gesehen in dem es um die Zukunft des SAP GUIs ging. Hmh, was soll ich sagen. Ihr wisst doch das nur zwei Dinge einen Atomkrieg überleben. Kakerlaken und ?
Es ist nicht die Intention alle SAP GUI Transaktionen mit Fiori nachzubauen und es ist auch nicht die Idee die SE80 komplett in Eclipse nachzubauen. Somit wird man immer den SAP GUI als Fallback für einige Szenarien benötigen.

7.) Einschränkung auf Objekttypen in der CTRL-SHIFT-A Suche:
Ist über den Zusatz TYPE:<object_type> möglich. Also z.B: type:CLAS sucht nur nach Klassen. Auf die gleiche Weise kann man auf Pakete und Objektverantwortliche filtern.

8.) DDIC
Mit Release 7.50 bieten wir einen nativen Eclipse Editor für Datenelement und Strukturen an. Die noch fehlenden Editoren für Domänen, Tabellen, Suchhilfen, Tabellentypen werden in Folgereleasen nachgeliefert.
http://scn.sap.com/community/abap/eclip ... ure-editor
http://scn.sap.com/community/abap/eclip ... -based-way

9.) Anlegen von Textelementen
Ist per Quickfix ab Release 7.40 möglich


Hoffe ich habe die meisten Fragen beantwortet. Wenn nicht bitte einfach nochmal nachfragen.

Bis dann,
Gruß Thomas.

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

Hallo,
wie der Name S/4HANA ja schon sagt lösen wir uns gerade von der DB unabhängigkeit.
Dieses Produkt läuft nur auf HANA als DB. Somit ist auch dringend anzuraten dort die Features von HANA (z.B: DB Prozeduren) auch zu benutzen um die Vorteile zu nutzen.

Gruß Thomas.

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

Hallo Ralf,
das ist ein sehr gutes Beispiel. Klar wird es die Dynpros noch sehr viele Jahre geben und man wird den Screenpainter benutzen um Patches und kleine Erweiterungen vorzunehmen.
Aber die neuen UIs werden mit UI5 und nicht mit Dynpro entstehen. Von daher ist klar das wir nicht in einen Eclipse-basierten Screenpainter investieren werden.

Gruß Thomas.

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

Das ist so bei Umbrüchen. Oft sogar, wenn man von Gattin 1.0 auf Gattin 2.0 migriert, fahren viele zweigleisig -- schon weil man Kinder hat, muss man mit der furchtbaren Schnepfe, die man nichtmal mehr mit dem A... angucken will, noch halbwegs zivilisiert kommunizieren. Da spreche ich übrigens aus Erfahrung.

Wie der Lateiner sagt: Tel Aviv!

SCNR

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

Ich bin da weniger streng. Kleiner Ausflug ins Jahr 98, SAPscript-Schulung. Der Dozent meinte damals, ein R/4 werde es nie geben, die SAP müsse dafür Völkerstämme von Entwicklern engagieren. So weit, so schlüssig. Ich hätte auch nicht gedacht, dass man wirklich hingeht, und mehr oder weniger alles von Grund auf (mein Marketing sagt, das heiße "from scratch") neu aufzubauen. Umso mehr genießt die SAP meine Hochachtung (sic!), das gewagt zu haben. Man stelle sich vor, Microsoft würde Windows wegwerfen und ein unixoides OS verwenden. Apple hat das gemacht, aber auch da waren viele Dinge erstmal nicht so dolle gelöst (das Dock war anfangs echt für'n A....).

Wenn man sowas macht, hat man nicht eine, sondern tausende Baustellen und nur begrenzte Kapazitäten. Es ist ja nicht damit getan, dass "der Fiedler" sich mal zwei Tage hinsetzt und das mal eben codiert). Das ist nicht provisorisch, wir sind im Umbruch.

Oder, um an oben anzuknüpfen: Es dauert ne Weile, bis man Gattin 2.0 nicht mehr zum Geburtstag der 1.0 gratuliert, bis man nicht mehr versehentlich den falschen Vornamen sagt (das generische "Schnuckelputz" hilft!) und bis man weiß, auf was der jeweilige Partner 6uell steht und auf was nicht. Um die eine oder andere Praktik wird es einem vielleicht leid tun, weil Version 2.0 sie nicht unterstützt (fehlende Abwärtskompatibilität), dafür gibt es neue, ganz andere, die man vielleicht erst zu schätzen weiß, wenn man sie richtig kennt.

Angesichts der Aufgabe, die die SAP sich aufgegeben hat, sollten wir nicht zu ungeduldig sein.