J2EE - Warum ?

J2EE - Warum ?

Hallo zusammen,
um das vorherige Thema (Zukunft JAVA) zu vertiefen...

Habe mich ein wenig in das SAP-Java-Thema eingearbeitet (Netweaver, Jco etc.) und war auf dem letzte DSAG-Infotag. Schlauer bin ich aber immer noch nicht.

Wenn mich ein Kunde fragt, warum er Netweaver mit einer aktive J2EE-Engine fahren soll, muss ich passen.

Was kann man mit JAVA, was man nicht auch mit Abap kann ? Ich spreche hier nur Projekte im SAP-Umfeld an.
Die Java-Engine kann ja noch nicht einmal direkt auf die ERP-Tabellen zugreifen und muss dies über BAPI's (in ABAP programmiert!) machen. Warum sollte ich die Anwendung nicht direkt in ABAP schreiben ?

Oder ist das nur eine Arbeitsbeschaffungsmaßnahme für Java-Programmierer, weil es zu wenig hochwertige Abapler gibt ?

Außer einer einzigen Anwendung (POP3-Zugriff) habe ich noch nichts gefunden, das einen Java-Code benötigt. Und dieses Problem habe ich mit Perl gelöst und später auf JCo umgeschreiben.

Bitte macht mich schlau ...
Uwe

Hallo Azreal,
tatsächlich liegt mein Schwerpunkt (seit 13 Jahren) bei Abap. Aber man muss sich in unserem Job natürlich um jede neue Technologie kümmern.

Mit Drag'n'Drop hast du sicherlich recht. Das ist zur Zeit in der Webentwicklung mit Abap noch ein Problem. Ich bin aber überzeugt davon, dass SAP (oder jemand anderes) hierfür neue BSP-Extensions entwickeln wird. In reinen SAP-GUI-Screens ist dies ja bereits jetzt möglich und da SAP ja jetzt voll in die Entwicklung von WebDynpros einsteigt, wird es hierfür über kurz oder lang eine Lösung geben.

Mir stößt eigentlich haupsächlich auf, dass SAP zwei unabhängige Parallelwelten entwickelt. Die Integration dieser Welten inkl. Tranport- und Versionsverwaltung, geimeinsames DDIC, geimeinsame Entwicklungsumgebebung hätte meines Erachtens mehr Sinn ergeben.

Weiterhin noch geruhsame Ostertage
Uwe

Hallo,

ich bin zur Zeit in einem Projekt, in dem ein "Userorientiertes", "Interaktives", "Drag-And-Drop", "Grid", "Baumstruktur"-System als User-Front-End entwickelt wird.

Dies durfte ich dann über eine Schnittstelle an SAP-SD/FI etc. anknüpfen (Datenpakete, Batchverarbeitung, Bapi, Rückmeldung ...)

Das User-Front-End wird in Java Programmiert (BEA, JCO, Oracle etc.).

Die Programmierung der User-Interaktionen ist so derartig aufwändig, daß ich mittlerweile davon überzeugt bin, mit SAP-Dynpros wäre das viel schneller machbar gewesen.

Ich habe allein für die Schnittstelle jede Menge Customizing-, Pflege- und Anzeigetransaktionen schreiben müssen, das ging wie der Blitz (Ene-Mene-Mu, wir machen eine View oder mal kurz einen Modulpool mit Table-Control und anderem Schnickschnack).

Wenn ich die Klimmzüge bei Grid-Controls, User-Aktionen (Sanduhr vergessen anzuschalten, abzuschalten) sehe, wird mir schlecht. Ein neues Feld in irgend einer Struktur bring das ganze "Ding" zum schwanken ...

Dann muß das ganze Versioniert und Deploit werden, daß es nur so eine Freude ist und ewig dauert.

Aufgrund der Strukturen und Zusammehänge bei den einlaufenden Daten habe ich die Programmierung in Abap-Objects machen müssen, das ist wirklich eine feine Sache (wenn man konsequent die Klassenverwaltung der Entwicklungsumgebung nutzt!).

Ein neues Feld in meinen SAP-Strukturen kostet mich ein/zwei Klicks und schon ist es überall dort drin, wo es hingehört (natürlich steckten da etwas Vorarbeit und einige geschachtelte Includes drin). Ruck zuck transportiert mit allen geänderten Sachen, das sucht man in der Java-Welt vergebens.

Es kommt nicht nur auf modischen Schnickschnack (oder Hypes) an, sondern in Wirklichkeit ist eine Integrierte Entwicklungsumgebung viel mehr wert.

Wie ein "Vorschreiber" schon bemerkte, ist es sehr wahrscheinlich, daß bestimmte "hippe" Features noch Einzug in die ABAP-Welt halten.

Für Eigenentwicklungen würde ich immer ABAP empfehlen. Notfalls kauft man ein leeres SAP-System und legt los (wie es der WDR und andere auch schon gemacht haben!).

mfg.
babap

Das ist genau das Kernproblem. Klar ist Java mächtiger als ABAP und es gibt unendlich mehr Komponenten, Schnittestellen etc.. Aber das macht es noch nicht zur ultimativen SAP-Programmierlösung.

Hauptsächlich aus dem Grund, weil die Entwicklungs-IDE unzumutbar ist und man einen richtigen High-Tech PC (oder in meinem Fall Laptop) braucht, damit alles wirklich performant läuft. Man hat quasi ständig ein halbes SAP-System auf seinem Rechner rumtorkeln. Richtig interessant würde es in dem Moment, wo man eine wirklich integrierte IDE a la SE80 hätte, die über die SAP GUI bedienbar wäre.

Desweiteren werden so tolle Lösungen wie Web-Dynpro den Entwicklern, die von HTML & Co. mal so gar keine Ahnung haben, richtig schmackhaft gemacht. Hat sich schonmal jemand angesehen, was da "hinten" im Web/Intranet rauskommt? 100% clientseitiges Javascript! Kein Tag, nix. Da schüttelt es mich. Nur wird sowas natürlich mit keinem Wort in irgendwelchen Broschüren, PDF´s etc. erwähnt.

Ich bin mal gespannt, was die Zukunft bringt. Im Moment ist das alles bestenfalls eine Übergangslösung.

ciao,
El