Modellieren einer Web-Dynpro-Anwendung
(ABAP)
Verwendung des Prozesses
Dieser Prozess ist Bestandteil des folgenden IT-Szenarios:
IT-Szenario |
Szenariovariante |
Prozess-Schritte
Hauptziel dieses Prozesses ist die Abbildung der Anforderungen der realen Welt innerhalb der zu erstellenden IT-Anwendung. Das Modellieren der Anwendung beinhaltet mehrere Entscheidungen. Dabei legen Sie fest, wo die Backend-Geschäftslogik liegen und wie darauf zugegriffen werden soll. Sie planen, wie das Projekt aus dem Blickwinkel der Änderungsverwaltung und der Entwicklung strukturiert werden soll, um die Wiederverwendbarkeit der Anwendungskomponenten zu ermöglichen. Schließlich bestimmen Sie, wie die interne Navigation (zwischen Anwendung und Ereignissen) sowie die externe Navigation (zwischen Portal und Endbenutzer) in der Anwendung vollzogen werden kann.
Dem Modellierungsprozess für die Variante sind die nachfolgenden Prozess-Schritte zugeordnet.
Geschäftslogik-APIs bereitstellen
Web Dynpro für ABAP ist primär eine Techologie zur Erstellung von Benutzungsoberflächen. Die Geschäftslogik zur Validierung von Benutzereingaben sowie zum Abrufen und Ablegen von Geschäftsdaten befindet sich dabei auf einem Backend-AS-ABAP-System. Es kann sich hierbei entweder um dasselbe ABAP-System handeln, in dem die Web-Dynpro-Anwendung modelliert wird, oder aber um ein anderes System mit entsprechender Anbindung. Beispiele für Geschäftslogik sind: ATP-Prüfung (d.h. Verfügbarkeitsprüfung für ein Material), Validierung des vom Benutzer eingegebenen Vertriebsbereichs, Berechnung des Steuersatzes, Sicherung der Rechnung in der Datenbank, Abrufen des FI-Belegs aus der Datenbank usw.
Einer der Hauptunterschiede zwischen dem klassischen Designansatz MVC (Model-View-Controller) und der Web-Dynpro-Technologie besteht darin, dass sich das 'Model’ zur Ablage der Geschäftslogik-Funktionalität nicht innerhalb der Web-Dynpro-Anwendung befindet. Vielmehr ruft der Controller der Web-Dynpro-Anwendung das Geschäftslogik-Model auf, das in Form von BAPIs, ABAP Objects, Funktionsbausteinen / RFCs, Web Services oder einer anderen Technologie zur Bereitstellung von Geschäftslogik-APIs zur Verfügung steht. Ihre Aufgabe ist es, diese APIs zu benennen und festzulegen, wo sie liegen sollen und wie die Web-Dynpro-Anwendung auf sie zugreifen soll.
Entwicklungsprojekte in Pakete aufteilen
Die mit Web Dynpro für ABAP erstellten Components werden wie andere klassische ABAP-Entwicklungsobjekte auch (z.B. Reports, Dynpros. ABAP-Dictionary-Objekte usw) Paketen zugewiesen. Pakete sollen das Entwicklerteam dabei unterstützen, Einheiten im SAP-System zu modularisieren, zu kapseln und zu entkoppeln. Außerdem vereinfacht eine solche Struktur den Weitertransport von Entwicklungsobjekten und Änderungen in andere Systeme, wo sie dann konsolidiert, getestet oder im Produktivbetrieb eingesetzt werden können.
Mit dem Package Builder (Transaktion SE21) lassen sich die Pakete erstellen und strukturieren. Im Verlauf des Modellierungsprozesses müssen Web-Dynpro-Projekte so strukturiert werden, dass die Nutzung dieser Pakete möglich ist. Die Anzahl dieser Pakete und ihre strukturelle Zuordnung hängt wesentlich von der Größe des Entwicklerteams und der Art und Weise ab, wie die Entwicklungsobjekte verwaltet werden sollen.
(Wiederverwendbare) Web-Dynpro-Components erstellen
Das Web-Dynpro-Programmiermodell ermöglicht eine klare Trennung der drei Software-Schichten Präsentationslogik, Prozesslogik und Datenbeschaffung durch Verwendung des Konzepts Model View Controller (MVC). Dadurch wird ein hoher Grad an Wiederverwendbarkeit erzielt. Die Gliederung einer Web-Dynpro-Applikation in Components bietet noch mehr Vorteile. So können zum Beispiel ganze Anwendungsteile geschachtelt werden. Physisch werden die Components während dieses Schritts in der ABAP Workbench angelegt.
In der Regel bestehen Geschäftsanwendungen aus mehreren Web-Dynpro-Components. Bestimmte Aufgaben werden häufig wiederholt an verschiedenen Stellen in einer Anwendung verwendet. Von der Benutzungsoberfläche her können Aufgaben wie die Anzeige von Adressdaten, Positionsdetails, Einzelheiten zu Partnerrollenbeziehungen oder Nachrichten usw. wiederverwendet werden, sofern sie als separate Components entwickelt werden. Das Web-Dynpro-Programmiermodell unterstützt die Wiederverwendbarkeit inhärent, da es die Entwicklung von Components ermöglicht, die mit Hilfe des Component-Interface als Schnittstelle zu anderen Components dienen können. Außerdem lassen sich die Components in UI-Components, Model-Components usw. strukturieren, um die Wiederverwendbarkeit weiter zu erhöhen.
Benutzernavigation modellieren
In diesem Schritt wird die allgemeine Navigation innerhalb der Web-Dynpro-Components, d.h. die Navigation zwischen verschiedenen Views, entworfen und definiert. Zuerst werden die Views angelegt. Sie stellen einen Bereich der Client-Benutzungsoberfläche dar. Beachten Sie, dass es sich bei den in diesem Schritt erstellten Views um leere Hüllen handelt. Die eigentlichen UI-Elemente sowie Layout und Kontext werden im Prozess Entwickeln einer Web-Dynpro-Anwendung (ABAP) erstellt. Die anderen Container-Objekte für Views, wie Fenster, View-Sets usw., werden ebenfalls in diesem Schritt angelegt.
Um die Navigation zwischen verschiedenen Web-Dynpro-Views zu ermöglichen, wurden spezielle Navigationsereignisse sowie Navigationsereignisbehandler erstellt, die als Plugs bezeichnet werden. Wenn ein Outbound-Plug gefeuert wird, wird ein Navigationsereignis ausgelöst. Ein Inbound-Plug dient zur Behandlung des Ereignisses als Antwort auf das vom Outbound-Plug gefeuerte Ereignis. Diese Inbound- und Outbound-Plugs sollen die Navigation in diesem Schritt vereinfachen.
Benutzernavigation mit Inbound- und Outbound-Plugs
Portal-Navigation modellieren
SAP NetWeaver Portal und Web Dynpro sind die strategischen SAP NetWeaver-Technologien für die Entwicklung von Benutzungsoberflächen. Beide laufen auf dem Application Server (ABAP und Java) und sind daher eng miteinander verzahnt. Wenn Web-Dynpro-Anwendungsentwickler ihre Anwendungen im SAP NetWeaver Portal verfügbar machen, d.h. vom Portal-Administrator integrieren lassen, ermöglichen sie es den Endanwendern, die im Portal angebotenen Navigationsfunktionen zu nutzen. Eine gute Navigation zwischen den Portal-Anwendungen spart Zeit und erhöht die Produktivität der Benutzer. Die objektbasierte Navigation (OBN) ist eine dieser Portal-Funktionen. Sie erlaubt den Zugriff auf eine Portal-Anwendung, die auf einem spezifischen Backend-Business-Objekt aufsetzt. Außerdem ermöglicht diese Art der Navigation die Pflege von Echtzeit-Informationen über dieses Objekt in Abhängigkeit von der Rolle des Benutzers.