Das Design von User Interfaces (UI) hat wesentlichen Einfluss auf die Nutzbarkeit von Software. SAP stellt dafür den Desktop-Client "SAP GUI" und eine Reihe von Werkzeugen zur effizienten Entwicklung von komplexen Oberflächen zur Verfügung. Allerdings hat das Internet einen starken Trend zu Browser-basierenden UIs geschaffen und stellt damit solche proprietären Programme in Frage.
Was sind Web Dynpros?
Auch wenn der Name Verwandtschaft zum klassischen Dynpro vermuten lässt, basiert das Web Dynpro auf einem ganz neuen Paradigma. Es handelt sich daher nicht um eine Weiterentwicklung des bewährten UI-Konzepts.
Zum Einsatz kommt das schon aus anderen UI-Entwicklungsumgebungen bewährte Entwurfsmodell Model View Controller (MVC), welches eine strikte Trennung von Präsentations- und Applikationslogik vorsieht. Erstere wird von den View- und Controller-Einheiten der Web-Dynpro-Anwendung abgebildet. Zugriff auf die Geschäftslogik sowie die zugehörigen Business-Objekte erfolgt über die Modellkomponente, welche eine Schnittstelle zum lokal oder remote angebundenen Backend darstellt. Web-Dynpro-Anwendungen fokussieren auf die UI-Erstellung. Business-Logik und -Objekte können auch von BAPI oder Web-Services bereitgestellt werden.
Im Vergleich zu anderen MVC-basierenden Ansätzen ist am Web-Dynpro-Programmiermodell neu, dass die Oberfläche weniger programmiert als in weiten Teilen durch deklarative, plattformunabhängige Metadaten beschrieben wird. Die Laufzeitumgebung von Netweaver 2004 generiert die eigentliche Oberfläche auf Basis dieser modellierenden Elemente, und zwar für .NET und Java, mit Netweaver 2004s auch für Abap. Die Runtime erlaubt zudem ein Client-spezifisches Rendering, welches den technischen Möglichkeiten des Endgeräts angepasst ist. PDAs und Mobiltelefone bedient die Plattform mit statischen Layouts, während leistungsfähigere Browser das Rendering selbst übernehmen. Das bei Web-Seiten bekannte Flackern, welches aus dem erneuten Laden des kompletten Bildschirminhaltes resultiert, entfällt damit.
Neben dem Modell der Metadaten vereint Web Dynpro die Vorteile einer Web- mit denen der Windows-basierenden Oberfläche. Hierzu stellt SAP komplexe UI-Elemente bereit, die den schon vom klassischen Dynpro bekannten Komfort wie zum Beispiel Eingabeprüfung, Sprachenabhängigkeit oder Suchhilfen durch die Anbindung der Metainformationen des Data Dictionary bieten.
Die Entwicklung begleiten grafische Werkzeuge, Controls für die Darstellung von Tabellen, die Integration von interaktiven Adobe-Formularen, die Einbettung von Office-Anwendungen sowie die nahtlose Einbindung der Web-Dynpro-Anwendungen in das "Netweaver Portal". Die in einem iView laufenden Web-Dynpro-Elemente übernehmen die Layout-Eigenschaften des zugehörigen Portal-Theme.
Dynpro-Layout konvertieren
Der "View Editor" des "Web Dynpro Explorer" im "Abap Object Navigator" bietet die Möglichkeit, Web-Dynpro-Oberflächen automatisch zu erstellen, die dem Layout von Dynpros klassischer Abap-Programme entsprechen.
Das Ergebnis ist ein auf Basis der Dynpro-Quelldaten eines Abap-Programmes erstellter Web Dynpro View, welcher die entsprechenden UI-Elemente samt Kontext-Metadaten enthält. Die meisten UI-Elemente werden automatisch in den Web Dynpro View übernommen. Ausnahmen bilden wegen der teils dynamischen Erstellung oder engen Verknüpfung zum Abap-Quellcode die folgenden Elemente:
• GUI-Controls,
• SAP-Grafiken,
• Abap-Listen,
• Auswahlbilder,
• Office- und Desktop-Integration,
• dynamisch erstellte Dynpros.
Des Weiteren stehen nach der Konvertierung Dynpro-basierende Services wie Batch-Input, GuiXT, SAP GUI Scripting und Transaktionsvarianten für das konvertierte Web-Dynpro-Objekt nicht mehr zur Verfügung.
Für weitere Elemente gibt es keine automatische Konvertierung: Da klassische Abap-Dynpros keine strikte Trennung von Anzeige- und Business-Logik besitzen, ist zu den Verarbeitungszeitpunkten PBO und PAI meist beides anzutreffen. Die Anzeigelogik aus dem Abap-Quellcode des zugrunde liegenden Dynpro muss manuell extrahiert und im Controller der Web- Dynpro-Anwendung neu implementiert werden.
Die bisherige Geschäftslogik, insoweit sie noch nicht als BAPI beziehungsweise Abap-Objektklasse vorliegt, muss analog dazu ebenfalls manuell gekapselt und vom Web-Dynpro-Modell aufgerufen werden.
Hier lesen Sie …
• worin sich Dynpros und Web Dynpros unterscheiden;
• wie Anwender bestehende Dynpros in Web-Dynpro-Oberflächen überführen können und was sie dabei beherzigen sollten;
• welche Rolle der Internet Transaction Server bei der Web-Integration spielt;
• welche Tools die Migration unterstützen.
www.computerwoche.de/go/
571613: SOA;
569656: SAP-Roadmap;
567991: R/3-Migration;
567693: SAP und BI.
Im Rahmen der Enterprise Services Architecture (ESA) will die SAP in ihre Software auch Internet-Standards einbeziehen. Erste Ansätze sind die Plattform "Netweaver 2004" und ihr momentan im Ramp-up befindliches Release "2004s". Allerdings haben die meisten Standards einen Nachteil: Sie sind der kleinste gemeinsame Nenner. Im Gegensatz zum SAP GUI, das ein umfassendes UI für SAP-Transaktionen zur Verfügung stellt, wurden HTML und Browser für die Darstellung von Informationen entwickelt, nicht aber zur Abbildung komplexer Benutzeroberflächen.
Zwei Welten verbinden
Mit dem "Web-Dynpro"-Konzept hat SAP diesen Konflikt gelöst, indem eine Web-basierende UI-Technik mit dem Komfort des klassischen "SAP GUI Dynpro" verbunden wurde (siehe Kasten "Was sind Web Dynpros?"). Es ist davon auszugehen, dass die Anwender SAP GUI langfristig nicht mehr benötigen und SAP-Systeme per Browser bedienen. Was passiert dann aber mit den alten Transaktionen, wenn es darum geht, das klassische SAP GUI abzulösen, und welche Auswirkungen hätte dies auf aktuelle Projekte?
In der Praxis kommen Web Dynpros noch selten zum Einsatz. Viele Unternehmen verwenden Netweaver noch nicht und haben daher auch bei Eigenentwicklungen keine Möglichkeit, Web Dynpros für Java zu nutzen. Zudem befindet sich das Web Dynpro für Abap noch im Ramp-up und ist daher noch nicht allgemein verfügbar. Dennoch werden sich Web Dynpros stärker verbreiten, so dass es sich lohnt, sich schon jetzt mit ihnen zu befassen.
Internet-Transaktions-Server
Um SAP-Systeme Internet-tauglich zu machen, werden oft der "Internet Transaction Server (ITS)" oder der "Netweaver Application Server" (vormals "Web Application Server") mittels Java oder Abap Business Server Pages eingesetzt.
Der ITS war der erste Schritt der SAP, um Business-Lösungen an das Internet anzupassen. Er übersetzt Dynpros ohne Anpassungsaufwand direkt in HTML- Seiten. Diese Technik ist zwar die einfachste Möglichkeit, bestehende Trans- aktionen ins Internet zu bringen, doch sie hat Nachteile. Dazu zählen Performance-Probleme sowie das für Internet-Oberflächen untypische Look and Feel der Anwendungen. Das wundert nicht, ist der ITS doch quasi nicht mehr als eine Übersetzungsmaschine für SAP-Transaktionen.
Nach anfänglichem Zögern hat SAP den ITS inzwischen in Netweaver integriert und wird ihn langfristig unterstützen. Der ITS ist für die Web-Integration alter SAP-GUI-Transaktionen die erste Wahl, wenn man mit den genannten Einschränkungen leben kann. Auch für Intranet-Anwendungen dürfte das eine gängige Option sein - bei Internet-Applikationen vermutlich eher selten. Hinzu kommt, dass die ITS-Technik nicht in das UI-Konzept Service-orientierter Architekturen passt.
Der Netweaver Application Server bietet ab der Version 6.20 die Möglichkeit, entweder mit Abap und HTML (Business Server Pages, kurz BSP) oder mit Java und HTML (Java Server Pages, kurz JSP) direkt Internet-fähige Anwendungen zu entwickeln. Die notwendigen Werkzeuge sind eng in die SAP-Entwicklungsumgebung ("Netweaver Developer Studio") integriert: Für BSP stehen damit seit der Version 6.20 alle bewährten Techniken für eine verteilte Entwicklung von großen Anwendungen zur Verfügung. Für den Java-Stack wurden das notwendige Repository und der Anschluss an die Übersetzungsumgebung nach und nach implementiert.
Keine Design-Werkzeuge
Allerdings müssen BSP- und JSP-Anwendungen von Grund auf neu entwickelt werden: Es gibt keinen Zusammenhang zwischen klassischen SAP-GUI-Transaktionen und einer BSP- oder JSP-Anwendung. Außerdem fehlt ein grafisches Entwicklungswerkzeug für das Design von Oberflächen, und die verfügbaren GUI-Elemente lassen derzeit noch zahlreiche Wünsche offen. Diese Nachteile sind mit der Einführung der Web Dynpros behoben.
Zwar werden BSP und JSP nicht verschwinden, denn Anwender werden sie auch weiterhin benötigen, um GUI- Elemente zu entwickeln, die nicht in Web Dynpro integriert sind. Es ist aber davon auszugehen, dass Web Dynpro den Ton angeben wird. SAP selbst setzt dieses Konzept bei neuen Entwicklungen intensiv ein.
Angesichts der unterschiedlichen Methoden stellt sich die Frage, welchen Weg Anwenderunternehmen für eigene Entwicklungen einschlagen sollen, wenn sie noch nicht die neueste Version von SAP Netweaver produktiv im Einsatz haben.
Keine automatische Migration
Ursprünglich wurde von SAP ein Migrationskonzept für klassische Transaktionen (Dynpros) in Web Dynpros in Aussicht gestellt. Davon ist das Unternehmen aber inzwischen wieder abgerückt. Geblieben ist ein Tool zur Übernahme des Layouts bestehender Dynpros. Damit ist das im "Screenpainter" erstellte Design in einen View einer Web-Dynpro-Anwendung übertragbar. Allerdings ist dies nur mit Einschränkungen möglich (siehe Kasten "Dynpro-Konvertierung"). Die aufwändigsten Teile der Entwicklung - der Zugriff auf die Geschäftslogik und die bestehenden Objekte (das Modell) sowie die Bearbeitungssteuerung durch den Benutzer (der Controller) - müssen neu implementiert werden. Es gibt keine Migrations-Tools. Dies ist aber nicht als Technikverliebtheit zu sehen, die nichts mit der Realität zu tun hätte.
Das mit den Web Dynpros verfolgte Konzept Model View Controller (MVC) ist komplett anders aufgebaut als das der klassischen Dynpros. Durch die strikte Trennung zwischen Layout, Kontrollfluss und Anwendungslogik ist es technisch gar nicht möglich, aus SAP-Transaktionen direkt sinnvolle Web-Dynpro-Anwendungen zu generieren.
Web-Dynpro-Konzept verinnerlichen
Allerdings kann man aus dieser Not auch eine Tugend machen. Denn die Idee hinter dem Web-Dynpro-Konzept kann sehr wohl auch für die klassische Programmierung gewinnbringend genutzt werden: Statt "set screen" und "select"-Befehle bunt zu mischen, sollten alle Kommandos für die Business-Logik und den Datenbankzugriff strikt von den Befehlen zur Benutzerführung und Bildschirmdarstellung in jeweils eigenen Abap-Objektklassen getrennt werden. Folgend können dann Controller und Modell leichter im Code wiedergefunden werden und sind somit einfacher zu extrahieren. Auf diese Weise berücksichtigen Anwender das Designkonzept von Web-Dynpro-Anwendungen. Zudem erhöht das Vorgehen die Möglichkeit, Code wiederzuverwenden. Die Re-Implementierung des Controllers lässt sich jedoch nicht vermeiden.
Eine sauber gekapselte Business-Logik ist aber nicht nur die Voraussetzung für den Einsatz von Web Dynpros, sie ist auch die Basis, um eigene Services zu entwickeln, die dann in der ESA zum Einsatz kommen. Denn für die Service-orientierte Architektur ist es notwendig, die in Transaktionen verborgenen Funktionen der Business-Logik anderen Systemen ohne Umweg über ein UI zur Verfügung zu stellen.
Programmierer müssen umdenken
Dynpros in Web Dynpros umzuwandeln ist nicht leicht. Die derzeit beste Methode, um klassische SAP-Transaktionen Web-fähig zu machen, ohne ein Re-Design vornehmen zu müssen, bietet sich mit dem ITS. In aktuellen Projekten, in denen Wert auf eine effiziente Umwandlung in Web Dynpro gelegt werden soll, empfiehlt sich die ohnehin sinnvolle strikte Trennung zwischen Anzeige- und Anwendungslogik.
Ohne manuellen Eingriff ist zwar der Umstieg auch hier nicht möglich, dennoch ist damit ein wichtiger Schritt bereits geleistet: die Änderung eines lange eingeschliffenen Programmierstils. Denn wie beim Umstieg von Abap/4 auf Abap Objects und Java ist nicht die Syntaxumstellung das Problem, sondern die konzeptionelle Änderung. (fn)