Wiederverwendbare Software

Feature | 24. November 2003 von admin 0

Die Namensähnlichkeit lässt es schon ahnen: Web Dynpro enthält viele der vertrauten Annehmlichkeiten, die Entwickler bereits bei seinem Vorgänger geschätzt haben. Gemeint ist das Dynpro-Modell, das die Entwicklung von Oberflächen für SAP-Anwendungen über Jahrzehnte hinweg bestimmt hat. Im neuen Web Dynpro finden Anwender weiterhin erprobte Funktionen wie die automatische Eingabehilfe und Fehlerbehandlung, die Datenformatierung und -prüfung auf der Basis von Data-Dictionary-Informationen sowie eine große Auswahl von Bedienelementen (Controls), die sich in der jeweiligen Benutzeroberfläche verwenden lassen.
Hinsichtlich der Client-Technologie, der Plattform und der Architektur weicht Web Dynpro jedoch erheblich vom alten Dynpro-Modell ab:

  • Benutzeroberflächen, die auf Web Dynpro basieren, sind darauf ausgelegt, im Internet-Browser zu laufen.
  • Das Web-Dynpro-Programmiermodell ist unabhängig von ABAP – das neue Web Dynpro läuft auf der Java-Plattform.
  • Dynpro ermöglicht es lediglich, Frontend und Backend in einer Anwendung zu trennen. Bei Web Dynpro hingegen ist eine solche Trennung zwingend erforderlich.

Ein zentraler Vorteil von Web Dynpro ist die Möglichkeit, Anwendungen aus Komponenten zu erstellen, die sich wieder verwenden lassen.

Das Web-Dynpro-Programmiermodell

Der Ansatz bei Web Dynpro erlaubt es dem Anwender, eine Benutzeroberfläche (User Interface, UI) zu erzeugen, davon aber verschiedene Schritte beim Erstellen, Ändern oder Erweitern einer Anwendung abzutrennen. Im Entwicklungsprozess mit Web Dynpro ist es beispielsweise möglich, zwischen der Zuweisung von Feldern auf dem Bildschirm und der Organisation des Datenflusses zu unterscheiden. Außerdem erleichtern Ähnlichkeiten verschiedener Benutzeroberflächen den Gestaltungsprozess.

Anzeige im Web Dynpro Explorer

Anzeige im Web Dynpro Explorer

Web Dynpro orientiert sich an einem generischen Metamodell für Benutzeroberflächen, das auf dem MVC-Paradigma basiert (MVC = Model-View-Controller). Dieses schreibt vor, eine Benutzeroberfläche für ihre Gestaltung in verschiedene Schichten aufzuteilen. Über den Web Dynpro Explorer erhält der Anwender nicht nur die Übersicht der Geschäftsdaten und -modelle, die einer Anwendung zu Grunde liegen. Er zeigt auch die möglichen Ansichten (Views) und Steuereinheiten (Controllers) an, die in Web-Dynpro-Komponenten enthalten sind. Und genau dies ist der Schlüssel für die Wiederverwendbarkeit der Web-Dynpro-Anwendungen.

Platzverteilung auf der Benutzeroberfläche

 Navigation im Web-Dynpro-Anwendungsmodellierer

Navigation im Web-Dynpro-Anwendungsmodellierer

Mit Web Dynpro definiert der Entwickler die Ansicht der Benutzeroberfläche. Er legt fest, welches Element der Benutzeroberfläche wo auf dem Bildschirm des Anwenders erscheint. Verschiedene Ansichten müssen gegebenenfalls über Navigationslinks miteinander verknüpft werden – beispielsweise, um dem Anwender eine bestimmte Abfolge von Ansichten zu bieten. Es lassen sich Ansichten verschachteln oder in Gruppen zusammenfassen, die die Bildschirmoberfläche in kleinere Bereiche teilen.
Beispielsweise ist es möglich, eine Anwendung an der in Bild zwei gezeigten Gestaltung zu orientieren. Sie gliedert die Bildschirmansicht in drei Bereiche. Der linke Bereich enthält immer die Ansicht einer Baumstruktur, im oberen Bereich wechselt sich die Ansicht für Standardwerkzeuge mit der Ansicht für weiterführende Werkzeuge ab. Im Zusammenspiel steuern diese drei Ansichten die Navigation im Arbeitsbereich auf der rechten Seite.
Die Zusammensetzung der Gruppe von Ansichten ist unabhängig von deren einzelnen Layouts oder Funktionalitäten. Details der Bildschirmansicht lassen sich nachträglich einfügen. Auch ist es einfacher, eine Benutzeroberfläche zusammenzustellen, indem verschiedene Ansichten neu angeordnet werden – ohne dabei in die Programmierung eingreifen zu müssen.

Organisation des Datenflusses

In den Ansichten ist festgelegt, was der Anwender auf dem Bildschirm zu sehen bekommt. Mit den Steuereinheiten wiederum werden die Aktionen koordiniert, die sich vom Bildschirm aus aufrufen lassen – ein Ausdruck etwa oder die Auswahl von Daten aus einer Tabelle und die Weitergabe dieser Daten an eine andere Steuereinheit. Allen Daten, die in einer Web-Dynpro-Benutzeroberfläche verwaltet werden, sind Steuereinheiten zugeordnet; die Datenhierarchie, die eine solche Einheit “besitzt”, ist deren Kontext.
Um Daten automatisiert zwischen Steuereinheiten hin und herzuschieben, muss die Möglichkeit bestehen, die Kontexte den verschiedenen Einheiten zuzuordnen. Bei anderen Verknüpfungen lassen sich Bindungen einrichten, um einen automatischen, bidirektionalen Datenfluss herzustellen. Diese Bindungen bestehen zwischen einem Teil eines Kontextes und

  • einigen Elementen der Benutzeroberfläche im Layout einer Ansicht, oder
  • einem Teil der Modellschicht, die das Backend kapselt.
Bindungs- und Zuordnungsbeziehungen

Bindungs- und Zuordnungsbeziehungen

Abbildung drei zeigt ID- und Beschreibungsfelder im Layout einer Ansicht. Der Entwickler bindet diese Bedienelemente an die Steuereinheit der Ansicht an. Um diese Daten dann an andere Steuereinheiten zu übergeben, lassen sie sich dort entsprechenden Elementen zuordnen. Zuordnungs- und Bindungsbeziehungen gewährleisten einen automatischen Datenfluss vom Bildschirm zu den Steuereinheiten und zurück.

Wiederverwendbarkeit von Komponenten

Bei der Programmierung von Benutzeroberflächen bieten sich dem Entwickler enorm viele Möglichkeiten, einzelne “Teile” wieder zu verwenden. Aufgabe einer Programmierumgebung und der programmierten Bausteine ist es daher, eine solche Wiederverwendbarkeit zu unterstützen. Mit Web Dynpro programmierte Komponenten bieten sich auf drei Ebenen zur Wiederverwendung an:

  • Visuelle Ebene: die Ansicht der Komponente sowie die zugehörige Navigation und Verschachtelung.
  • Funktionale Ebene: Aufbau und Abläufe in den Steuereinheiten.
  • Datenebene: Kontext der Steuereinheiten sowie deren Zuordnungen und Bindungen.

Jede Komponente lässt sich in andere Komponenten integrieren. Dabei “entscheidet” sich eine Komponente, welche der genannten drei Ebenen den anderen Komponenten zur Verfügung stehen soll. Die eingebettete Komponente bietet eine Oberflächensicht, die den visuellen Teil der Komponente darstellt, und eine spezielle Steuereinheit. Diese legt die Methoden, die Ereignisse und einen Kontext für die Zuordnung zu anderen Kontexten in der integrierenden Komponente offen und regelt deren Zusammenarbeit.
Abbildung zwei verdeutlicht diesen Zusammenhang: Bei der Suchfunktion mag es sich beispielsweise um die “normale” Suche handeln. Dann ist ein fest definierter Bildschirmaufbau zu sehen. Bei der Suchansicht könnte es sich jedoch auch um die Oberflächensicht einer eingebetteten Anwendung handeln. Wenn diese Anwendung zur Suchfunktion navigiert, wird das gesamte Navigationsszenario der zugehörigen Komponente im Arbeitsbereich sichtbar. In diesem Fall kann die Suchkomponente zwischen zwei Ansichten wechseln, die jeweils im Arbeitsbereich angezeigt werden – Suchkriterium und Suchergebnis.
Ebenso könnte es sich bei der übergeordneten Steuereinheit in Abbildung drei auch um die spezielle Steuereinheit einer eingebetteten Komponente handeln, die eigene Daten anderen Komponenten zugänglich macht. Beispielsweise könnte sie die Schnittstelle zu einer Komponente sein, die Business-Objekte aus einer Modellschicht liest, eines der Objekte in seinem Oberflächenkontext präsentiert und zudem Methoden offen legt, um zu einem anderen Objekt im Set zu gehen. Über Bindung und Zuordnung zeigt das Layout der Ansicht immer diejenigen Attribute des Objekts an, das zu diesem Zeitpunkt in der Komponente ausgewählt ist.
Wenn die gleichen Komponenten ineinander verschachtelt sind, ist die übergeordnete Steuereinheit identisch mit der speziellen Steuereinheit der Suchkomponente. Eine erweiterte Suchkomponente findet dann nicht nur Business-Objekte, sondern ermöglicht auch die Zuordnung zu einem ausgewählten Element in der Ergebnismenge. In Abbildung zwei ist ersichtlich, wie die Komponente in die Navigation der Anwendung integriert wird, Abbildung drei zeigt, wie der Datentransfer mit dem Suchergebnis der Komponente durchzuführen ist.

Komponenten im Einsatz

Bei Web Dynpro ist eine Anwendung eigentlich nur als Einstiegspunkt in eine Web-Dynpro-Komponente zu verstehen. Im einfachsten Fall existiert eine Web-Dynpro-Komponente lediglich dazu, eine einzelne Anwendung zu implementieren. Sie enthält alle Ansichten und Steuereinheiten, die dafür benötigt werden. Die Komponenten können jedoch noch viel mehr.
Komponenten erweitern die Auswahl an Bedienelementen, die dem Anwender zur Verfügung stehen:
Web Dynpro enthält eine vordefinierte Auswahl von rund 30 wesentlichen Bedienelementen – Eingabefelder, Drucktasten, Ankreuzfelder, Tabellen-Views – die sich im Layout einer Ansicht verwenden lassen. Diese Bedienelemente decken in der Regel 80 bis 90 Prozent der Anforderungen einer Benutzeroberfläche ab. Was aber ist mit kundenspezifischen Anforderungen? Etwa einem Gruppenkalender, einer speziellen Art von Eingabeformular oder einer bestimmten Kombination von Baum- und Tabellenansichten? Komponenten füllen diese Lücke. Bedienelemente, die für solche speziellen Ansichten notwendig sind, lassen sich als individuelle Komponenten entwickeln. Einmal implementiert, können die Komponenten wie Bedienelemente einfach wieder verwendet werden.
Komponenten passen ihr Verhalten dynamisch an:
Ein Anwender möchte beispielsweise eine Tabelle in seine Benutzeroberfläche integrieren. Er entwirft also seine Komponente mit einer festen Anzahl von Bedienelementen für die Tabelle. Zu diesem Zeitpunkt weiß er jedoch nicht, wie viele Spalten die Tabelle haben wird, oder welche Titel oder Datentypen diese Spalten künftig tragen. Mit Web Dynpro lassen sich diese Informationen in den Konfigurationsdaten nachliefern – Daten, die die Komponente erst zur Laufzeit erhält. Dazu ist es lediglich notwendig, bei der Gestaltung einer Anwendung einen Code zu den Steuereinheiten hinzuzufügen, der zur Laufzeit weitere Spalten erzeugt oder vorhandene ändert. Mit dieser Technik steuern Komponenten über die Konfigurationsparameter nicht nur ihr Verhalten, sondern auch ihr Erscheinungsbild und ihren Oberflächenkontext.
Implementierung von “UI-Patterns”:
Das “Pattern”-Modell folgt dem Ansatz einer aufgabenorientierten Gestaltung von Benutzeroberflächen. Ziel ist es, die Anwenderfreundlichkeit von Software zu erhöhen. Dazu beginnt die Entwicklung einer Benutzeroberfläche mit einer Analyse der Aufgaben, die der Anwender in der Praxis zu bewältigen hat. Anschließend sind UI-Patterns zu implementieren, die jeweils eine dieser Aufgaben optimal unterstützen. Schließlich sollen aus diesen UI-Patterns Anwendungen zusammengefügt werden, die den speziellen Aufgaben im Geschäftsprozess entsprechen, um den es in dieser Anwendung geht. Eine “Realitätsprüfung” für diesen Entwicklungsansatz für Benutzeroberflächen war SAP CRM 3.1 – mit enormem Erfolg. Für dieses Release wurden alle Benutzeroberflächen der wichtigsten CRM-Anwendungen im UI-Pattern-Modus implementiert. Nach Aussagen der Anwender war die Arbeit mit diesen Benutzeroberflächen, die über einen gemeinsamen “Grundriss” verfügen, viel leichter zu erlernen, da sich die Interaktionsmuster stets wiederholten. Wer eine spezielle Anwendung innerhalb der CRM-Lösung kannte, beherrschte alle!
Implementierung als “Quasi-Patterns”:
In der Realität sind jedoch nicht alle Software-Lösungen für den Ansatz der pattern-basierten Benutzeroberflächen geeignet. Eine Lösung, deren Benutzeroberfläche derzeit überarbeitet wird, ist Employee Self Services (ESS), Bestandteil des SAP Human Capital Management. Die Palette der ESS-Anwendungen folgt einem “Quasi-Pattern”-Ansatz. Aus gutem Grund werden die Anwendungen bei ESS letztendlich erheblich weniger einheitlich aussehen als die der CRM-Lösung. Schließlich dient ESS allen Mitarbeitern eines Unternehmens, während mit der CRM-Lösung in der Regel spezialisierte Anwender arbeiten. Daher benötigt der Designer bei der Gestaltung von ESS mehr Freiheiten. Die Auswahl derjenigen Komponenten, die am besten geeignet sind und deshalb für einen bestimmten Bereich des “Grundrisses” genutzt werden sollten, ist unter Umständen von Anwendung zu Anwendung sehr unterschiedlich. Darüber hinaus gibt es einige ESS-Anwendungen, wie etwa die Budgetplanung, die besondere, definitiv nicht generische Komponenten benötigen. Das Komponentenkonzept von Web Dynpro unterstützt den dynamischeren “Quasi-Pattern”-Ansatz im ESS genauso wie die statischere Pattern-Variante in CRM.

Enorme Vorteile

Unter allen Vorteilen von Web Dynpro zeichnet sich besonders die Möglichkeit aus, wieder verwendbare Teile von Benutzeroberflächen zu kapseln. Hier bietet Web Dynpro, verglichen mit seinem Vorfahren – dem Dynpro und Server-Page-Modellen wie JSP und Business Server Pages – dem Entwickler einen enormen Vorteil. Web Dynpro ist daher ein wichtiger Eckpfeiler für die Entwicklung von SAP-Standardanwendungen und benutzerdefinierten Anwendungen. Web Dynpro erleichtert nicht nur die Entwicklungsarbeit, sondern ist auch wegbereitend für vollständig auf Services basierende betriebswirtschaftliche Software-Lösungen. Dadurch unterstützt Web Dynpro die Ausrichtung der SAP auf die Enterprise Services Architecture (ESA) für die Verwendung von Web-Services auf Unternehmensebene.
Ressourcen und Verweise zu Web Dynpro

Quelle: SAP Insider

Peter Tillert

Peter Tillert

Leave a Reply