SAPs Framework

E-3 Magazin, Juli/August 09, Seite 96 Infrastruktur

SAPs Framework

Web Dynpro (WD) ist die Standardtechnologie von SAP, um webbasierte grafische Benutzeroberflächen zu entwickeln. Web Dynpro for Java arbeitet mit der plattformunabhängigen, objektorientierten Programmiersprache Java und ist ein geschlossenes Framework von SAP. Ein Erfahrungsbericht aus einem WD-Projekt der clavis Unternehmensberatung.

In einem Kundenprojekt der clavis Unternehmensberatung ging es darum, Daten aus dem SAP ERP und einem CRM-System auszulesen, überwiegend in Tabellenform darzustellen und teilweise zu verknüpfen. Im Ergebnis sollten die Daten für die Serviceabteilung des Unternehmens als Webanwendung zur Verfügung gestellt werden. Um diese Anforderungen zu realisieren, wurde auf die Web-Dynpro-Technologie zurückgegriffen.

Web Dynpro (WD) ist die Standardtechnologie von SAP, um webbasierte grafische Benutzeroberflächen zu entwickeln. Dabei wird das Entwurfmuster Model-View-Controller (MVC) genutzt, das die Bereiche Daten (= Model), Programmsteuerung (= Controller) und Darstellung (= View) voneinander trennt. Die Geschäftslogik lässt sich sowohl im Model als auch im Controller umsetzen.
Die WD-Entwicklung kann in den Programmiersprachen ABAP oder Java erfolgen. Web Dynpro for ABAP verwendet die SAP-eigene Programmiersprache ABAP und läuft auf dem SAP Web Application Server (ABAB Stack). Die Entwicklungsumgebung von WD for ABAP ist komplett in die SAP GUI integriert (Transaktion SE80).

Web Dynpro for Java (WDJ) arbeitet mit der plattformunabhängigen, objektorientierten Programmiersprache Java. WDJ ist ein geschlossenes Framework von SAP, das auf Java (genauer J2EE = Java Enterprise Edition) basiert und auf der NetWeaver J2EE Engine, also auf dem Java Stack von SAP, läuft. WDJ stellt die SAP-Standardtechnologie zur Entwicklung von webbasierten grafischen Benutzeroberflächen in der Java-Umgebung dar. Die Entwicklungsumgebung NetWeaver Developer Studio (NWDS) ist eine Erweiterung der Java IDE Eclipse 3.x und Teil der NetWeaver Development Infrastructure (NWDI), die u. a. für die Verwaltung und Verteilung des Programmcodes zuständig ist.

Neben diesen beiden Varianten können zur Bewältigung entsprechender Aufgaben zahlreiche weitere Webtechniken zur Anwendung kommen. Denn während auf der Clientseite (Browser) immer eine Kombination aus HTML und JavaScript eingesetzt wird (abgesehen von Browser Plugins wie Flash oder Java Applets), gibt es serverseitig kaum Einschränkungen. Für welche Lösung man sich am Ende entscheidet, wird in den meisten Fällen vor allem von den Anforderungen abhängen, die an die Webanwendung gestellt werden. Ein wesentliches Kriterium ist hier, dass die Website „schlank“ bleibt, das heißt es sollen bei jeder Benutzertransaktion so wenig Daten wie möglich zwischen Client und Server übertragen werden. Daneben sollte bei unabhängigen Anwendungen auch der Aufwand für die Integration in SAP berücksichtigt werden. Bei der Entwicklung auf dem Web-Applikationsserver ABAP wären folgende Optionen denkbar:

Verwendung von Web Dynpro for ABAP

Verwendung von SAP Business Server Pages (BSP) Entwicklung einer reinen ABAP-Anwendung, die über den SAP Internet Transaction Server (ITS) im Browser dargestellt wird. Der Vorteil einer Anwendung auf dem ABAP-Server besteht darin, dass die Anwendung direkt auf die SAP-Daten zugreifen kann, ohne dass eine weitere Programmschicht dazwischen liegt. Der Quellcode der Anwendung ist vollständig in das SAP-Transportsystem integriert und somit leicht zu verwalten. Auch die Entwicklungstools sind fast komplett in die SAP GUI integriert, sodass eine aufwändige Installation bzw. Konfiguration entfällt. Der Nachteil dieses Modells liegt in der Beschränkung auf die von SAP zur Verfügung gestellten Funktionen und Programmiersprachen, zumal ABAP weniger weit verbreitet ist als Java. Nutzt man den Web-Applikationsserver Java, gibt es folgende Möglichkeiten:

• Verwendung von Web Dynpro for Java

und

• Entwicklung einer nativen J2EE-Anwendung.

Bei einer reinen J2EE-Entwicklung können alle J2EE-Techniken wie Enterprise Java Beans (EJB) zum Einsatz kommen. Die Daten werden per SAP Java Connector (JCO) bezogen. Jedoch ist hier, wie bereits erwähnt, der Aufwand für die Integration in das SAP abzuwägen. Der Vorteil der Entwicklung auf dem Java-Server liegt in erster Linie in der Verwendung einer gängigen Programmiersprache, die vielen Entwicklern vertraut ist.

Neben den genannten Servertypen können auch J2EE-Anwendungen auf Applikationsservern wie Glassfish, TomCat, JBOSS zum Einsatz kommen. Daneben ist eine Entwicklung auf Plattformen denkbar, die nicht auf Java basieren. Hier ließe sich die Datenanbindung an das SAP über RFC-SDK lösen.

Im Rahmen des skizzierten Entwicklungsprojektes war aufgrund der Versionsnummer des SAP-Systems beim Kunden eine Entwicklung in Web Dynpro for ABAP nicht möglich. Daher galt es zunächst, die naheliegenden verbleibenden Optionen abzuwägen: Entwicklung mit Hilfe von Web Dynpro for Java auf dem Java-Server oder mit Hilfe von SAP Business Server Pages (BSP) auf dem ABAP-Server. Dabei ergaben sich die in der Tabelle rechts stehenden  Argumente für die jeweilige Lösung.

Nach Beratung mit dem Kunden fiel die Wahl auf den Einsatz von Web Dynpro for Java. Die einfache Anzeige einer Tabelle ist mit WDJ dank Framework, grafischer Entwicklungsumgebung und diverser Wizards schnell realisiert. Solange es fertige GUI-Elemente für die auf der Web-Oberfläche darzustellenden Elemente gibt, lässt sich mit relativ geringem Aufwand eine Anwendung realisieren. Ein großer Nachteil in unserem Projekt bestand jedoch im Fehlen des SAP List Viewers, dem sogenannten ALV (Stand NetWeaver 7.0), das heißt, nur einfache Tabellen konnten dargestellt werden. So hat die Nachprogrammierung diverser ALV-Funktionalitäten sehr viel Zeit in Anspruch genommen.

Ein Großteil der Datenbeschaffung und -aufbereitung (Businesslogik) wurde auf ABAP-Seite mit verschiedenen BAPIs realisiert. Diese BAPIs werden von WDJ per Adaptive Remote Function Call (Adaptive RFC) angesprochen. Der Import der Schnittstellendefinition der BAPIs ist weitestgehend automatisiert und erfolgte beim ersten Aufrufen auch völlig problemlos. Kompliziert wird es hingegen, wenn die BAPIs geändert werden und in der Folge auch die Schnittstellendefinition aktualisiert werden muss. Dazu ist es erforderlich, das Mapping zwischen den einzelnen Teilen des MVC-Konzeptes (also Model -> Controller -> View) per Hand durchzuführen. Dies kann sehr aufwendig werden, da ein grafisches Tool verwendet wird, das bei großen Strukturen extrem langsam läuft. Allgemein wirkte sich das zum Teil sehr träge Verhalten der IDE im Projekt negativ aus.

An die Grenzen stieß man insbesondere bei der Darstellung sehr großer Tabellen. Die darzustellenden Seiten wurden (unkomprimiert) bis zu zwei Megabyte groß, da durch das WDJ Framework automatisch ein großer Overhead an JavaScript generiert wurde. Hinzu kommt, dass bei jeder Benutzerinteraktion die komplette Seite neu übertragen wird. Aufgrund der Geschlossenheit des WDJ Framework lässt sich dies leider nicht durch Entwicklung eigener Tabellenelemente umgehen. So verringerte sich die Performance der Anwendung deutlich – und zwar nicht durch die Datenbeschaffung, sondern lediglich im Rahmen der Darstellung im verwendeten Web-Browser.

Eine weitere Problematik lag darin, dass das Beschaffen der Daten auf Seiten des Java-Servers sehr viel Speicher kostete. Es wurde bis zum Vierfachen der eigentlichen Datenmenge generiert, was den Server wiederholt zum Absturz brachte, wenn kein freier Speicher mehr verfügbar war. Dies konnte umgangen werden, indem vor jedem Aufruf eines BAPIs geprüft wurde, ob ausreichend Speicher vorhanden ist.

Vor dem Hintergrund dieser Erfahrungen lässt sich festhalten, dass auch die Datenmenge, die mit Hilfe der Web-Anwendung bearbeitet und angezeigt werden soll, einen wesentlichen Faktor für die Auswahl der Entwicklungsumgebung bzw. -anwendung darstellt. Für kleine und mittlere Datenmengen ist eine Entwicklung in Web Dynpro for Java bzw. Web Dynpro for ABAP sicher ein gangbarer Weg, wobei hier dem ABAP-Modell der Vorzug gegeben werden kann, sofern der Einsatz im Rahmen des bestehenden SAP-Systems möglich ist. Denn der direkte Zugriff auf die Daten produziert keinen zusätzlichen Overhead, was sich positiv auf die Darstellungsperformance im Browser auswirkt.

Für große Datenmengen sollte hingegen die Entwicklung einer eigenständigen Webanwendung in Erwägung gezogen werden – hier könnte die Qualität des Ergebnisses den Mehraufwand bei der Integration in das SAP am Ende aufwiegen.

www.clavis.biz