Für jeden das passende SAP-Frontend

28.02.2006
Von Thorsten Bingmann 
Mysap ERP und Netweaver bedeuten für viele SAP-Anwender den Wechsel auf eine serviceorientierte Architektur. "SAP-Tuning" soll Wege zeigen, diesen Umstieg praxisverträglich zu gestalten. Wir beginnen mit den Frontends.
Nicht für alle Anwender sind Browser-basierende Benutzeroberflächen geeignet. Den klassischen SAP GUI dürften weder Portal noch Mendocino verdrängen. Anders sieht das natürlich bei Sachbearbeitern, Gelegenheitsanwendern und Vertrieb aus.
Nicht für alle Anwender sind Browser-basierende Benutzeroberflächen geeignet. Den klassischen SAP GUI dürften weder Portal noch Mendocino verdrängen. Anders sieht das natürlich bei Sachbearbeitern, Gelegenheitsanwendern und Vertrieb aus.

Früher war sicher nicht alles besser, manches jedoch einfacher oder eindeutiger. Kam die Sprache beispielsweise auf Standardsoftware und deren Benutzeroberfläche, waren damit im Fall von R/3 allein das SAP GUI und das die Bildschirmanzeigen erzeugende Dynpro (Dynamisches Programm) gemeint.

Hier lesen Sie …

• von der Vielfalt der alten und neuen Benutzeroberflächen der SAP-Software;

• für welche Anwender sich welche Benutzerführung empfiehlt;

• warum das SAP GUI weiter- leben wird;

• wie sich die Gestaltung von User Interfaces im SAP-Umfeld durch Web und Internet ändert.

Mehr zum Thema

www.computerwoche.de/go/

552305 : Web-Tools und ihre Folgen;

566258 : Portale - manchmal ist weniger mehr;

561625 : Zwischen Intranet und Enterprise-Portal.

Mit dem Aufkommen von Internet-Anwendungen und den einst als "New Dimension" angepriesenen Lösungen jenseits des Kern-ERP war es mit der alleinigen Regentschaft der traditionellen Benutzerführung vorbei. Seit den ersten Schritten auf dem Markt für Portalsoftware arbeitete SAP an einem Nachfolger, der im Zuge der Grunderneuerung des R/3-Systems nach und nach die Rolle des SAP GUI übernehmen sollte.

Endgültig mit der Vorstellung von "Mendocino", der ersten gemeinsam mit Microsoft entwickelten Software, legte sich SAP darauf fest, in Zukunft verschiedene Benutzerführungen für unter-schiedliche Nutzerkreise und -bedürfnisse bereitzustellen. Jede Zugangsalter- native besitzt ihre genuinen, in der Regel technisch bedingten Vor- und Nachteile, anhand derer sich ein prototypisches Einsatzgebiet umreißen lässt. Als Kriterien für die Auswahl werden deshalb künf- tig die Informationsdichte und -fülle, Abhängigkeiten von anderen Daten oder Systemen sowie der Infrastrukturzugang und die unternehmensspezifische Rolle des Mitarbeiters angelegt. Ein Blick auf die jüngste Entwicklung der Nutzeroberflächen und des dahinter liegenden Programmiermodells offenbart die schrittweise Adaption der Internet- und Web-Techniken, aber auch den Wandel, den die neue technische Ausgestaltung mit sich bringt.

Ohne Frage weiß SAP in diesem Kontext die Chancen des mit ESA (Enterprise Services Architecture) eingeleiteten technischen Umbaus zu nutzen. Die infrastrukturellen Beschränkungen sowohl bisheriger Integrationstechniken als auch historischer Wurzeln ("Mysap Workplace", "Toptier Enterprise Portal", "Knowledge-Management-System") werden nun endgültig abgelegt, und die sich abzeichnenden neuen Möglichkeiten reichen deutlich weiter als die bisherigen Integrationstechniken. Konsequent wird die Strategie verfolgt, die bisherigen Restriktionen hinsichtlich Design und Layout auszuräumen.

Außer Frage steht auch die GUI-Strategie der SAP: Diese zielt darauf ab, das traditionelle SAP GUI durch Browser-basierende Systeme zu ersetzen und künftig für den Zugang zu Anwenderfunktionen die Portaltechnik als zentralen, benutzerorientierten Universalzugang zu nutzen. Dabei unterstützt das jetzt mit "Netweaver 2004s" auf den Markt kommende "Multitenant"-Portal so genannte Portalverbünde.

Inhalte und Abläufe zusammenführen

Die Möglichkeit, im Portal separate logische Einheiten für einzelne Tenants (Kunden) zu betreiben, verleiht Konzerneinheiten deutlich mehr Autonomie hinsichtlich ihres digitalen Auftritts, etwa durch eine Nutzung des lokal gewohnten Look and Feel. Extern bezogene Nutzerrollen lassen sich den internen zuordnen, was die Synchronisation mit den lokal vernetzten Portalen vereinfacht. Inhalte lassen sich zentral und übergreifend pflegen, Administrationsaufgaben zur Pflege verteilter Daten und Anwendungen können delegiert werden.

Den Wert von Unternehmens-Portaltechniken wie dem Netweaver Portal macht natürlich nicht allein die Browser-basierende Benutzerschnittstelle aus; er liegt vielmehr in dem Potenzial der Frontend-Integration. Inhalte werden zur Präsentation zusammengeführt und aufgabenorientiert dargeboten. Mithin handelt es sich um die Vereinheitlichung des Zugangs (uniformes Look and Feel), die Bündelung von Informationen und um Kollaborationsfunktionen. Die von SAP früher verfolgte lizenztechnische Unterteilung war Ausdruck der unterschiedlichen Aufgaben eines Portals. Die Inte- gration erfolgt für dynamische Inhalte über Portalmodule ("iViews") und bei Dokumenten (statische Inhalte) über WebDAV oder proprietäre Adapter. Einzelne iViews lassen sich auf einer Web-Seite thematisch gruppieren und mehrere Pages wiederum als Worksets zusammenfassen. Dies erlaubt, dem Benutzer aufgaben- und rollengerecht genau die Funktionen bereitzustellen, die er braucht, und ihm die anderen unzugänglich zu machen.

Mehr Flexibilität

Der entscheidende Unterschied zwischen dem SAP GUI und dem Netweaver Portal liegt in der neuen Flexibilität und Transparenz. Schließlich benötigen die wenigsten Anwender die kompletten Funktionen. Aus diesem Grund kann es nicht um die reine Einbindung des SAP GUI oder seiner HTML-Variante "WebGUI" in das als intuitive, nutzerspezifische Arbeitsumgebung gedachte Portal gehen. Stattdessen erhielt die CRM-Lösung der SAP in der Version 3.1 neben dem SAP GUI eigens eine portalbasierende Benutzeroberfläche. Weitere Anwendungen werden diesem Beispiel folgen.

Das Programmiermodell

Die grundsätzliche Idee hinter einer Portalinfrastruktur geht nur auf, wenn das User Interface einem festen Schema beziehungsweise einer einheitlichen Struktur folgt. Deshalb wurden mit der portal-basierenden Benutzerführung das auf Schemata basierende Design des User Interface (Pattern-based Design) und das neue Programmiermodell Web Dynpro eingeführt. Aus der Namensgleichheit zu Dynpro sollte jedoch kein falscher Schluss gezogen werden. Beide Programmiermodelle haben wenig miteinander gemein. Während im traditionellen Modell die Ablaufsteuerung verteilt zwischen einem Dynpro und dem zugehörigen User-Command-Modul erfolgt, bedient sich Web Dynpro des aus der Objektorientierung stammenden MVC -Konzepts (Model View Controller. Die Präsentationsschicht und Business-Logik werden folglich separiert, und Anwendungen, die auf Java/J2EE und auf Abap oder künftig Web-Services-Standards basieren, erhalten eine einheitliche Darstellungsschicht.

Web Dynpro stellt in der Grundausrichtung ein GUI-Framework dar und zieht zwischen dem genutzten Server-seitigen Scripting (JSP) und den Taglibs-Bibliotheken (zum JSP-Aufruf) eine Zwischenschicht. Bekannte Techniken wie Javascript verhindern, dass es aufgrund der dynamischen Informationsversorgung zu flackernden Bildschirmseiten kommt - wie es etwa beim Einsatz des ITS (Internet Transaction Server) für den Web-Zugang von R/3 noch der Fall ist.

Web Dynpro wie auch das Enterprise Portal sind im Unterschied zu dem bisherigen Vorgehen der SAP nicht als Erweiterungen des Abap-Stacks ausgelegt, sondern folgen dem Konzept des "Netweaver Application Server".

Das Portal als Standard

In SAP-zentrischen Umgebungen ist es empfehlenswert, das Netweaver Portal sukzessive als Standard zu etablieren. Dabei profitieren vor allem Gelegenheitsnutzer und weniger versierte Fachanwender von dem grundsätzlich einfacheren Umgang. Wer die Verlängerung von SAP-Transaktionen in das Web mit Hilfe des ITS oder des WebGUI realisiert hat, sollte sich intensiv mit der Frage der Migration auf eine neue, eher Web- und Internet-affine Umgebung auseinander setzen. Ansonsten läuft er über kurz oder lang Gefahr, die Komplexität seiner Betriebsumgebung ohne jeglichen Produktivitätsgewinn zu steigern.

Ein Umstieg hier muss nicht zwingend auf das SAP-Portal hinauslaufen. Ebenso lassen sich die Portal-Infrastrukturen von IBM und Microsoft nutzen. Gerade Gelegenheitsanwender können künftig mit "Mendocino" aus Office heraus zum Self-Service greifen. Eine weitere Wahlmöglichkeit ergibt sich aus der Kooperation zwischen SAP und Macromedia. Hier geht es um die Integration der Präsentations-Server-Software "Flex" von Macromedia in den Visual Composer. Dadurch lassen sich die mit dem SAP-Tool erstellten Oberflächen auch in Flash-Player-Plug-ins anzeigen, was für komplexe und dynamische Internet-gestützte Anwendungen (Rich Internet Applications) sinnvoll sein kann.

Wer intensiv mit SAP-Lösungen arbeitet, wird hingegen die vielfältigen Möglichkeiten des SAP GUI nicht missen wollen. Dies gilt vor allem für die mächtigen internen Dialogfunktionen, den Zugriff auf beliebige Objekttypen und die komplexen Auswahlkriterien der Abap-Programme - etwa beim Monitoring in der Administration und beim Customizing durch Berater beziehungsweise technisch orientierte Fachleute aus den betriebswirtschaftlichen Bereichen. Ob das SAP GUI an dieser Stelle in der "Portal Framework Page" oder in einem eigenen Fenster zur Verfügung steht, ist für die Nutzung sekundär. Es muss in jedem Fall lokal installiert sein. (fn)