Was ist Web Dynpro ABAP?

Dynpro, Web Dynpro, Fiori: drei Generationen von SAP-Oberflächen

Dynpro steht für „dynamisches Programm“ und bezeichnet ursprünglich die Bildschirmbilder im SAP GUI, also die klassische Oberfläche, die viele aus Transaktionen wie VA01 oder ME21N kennen. Web Dynpro hat den Namen übernommen, ist aber eine eigenständige Technik für den Browser. Wer nach „ABAP Dynpro“ sucht, meint meist das klassische Bildschirmbild, nicht Web Dynpro.

Die drei Oberflächentechniken bestehen heute nebeneinander:

Wie eine Web-Dynpro-Anwendung aufgebaut ist

Eine Web-Dynpro-Anwendung besteht aus wenigen, klar getrennten Bausteinen:

• Komponente

  Die Klammer um alles. Sie bündelt Views, Windows und Controller und kann andere Komponenten wiederverwenden.

• View

  Ein Bildbereich mit UI-Elementen wie Eingabefeldern, Tabellen und Schaltflächen, angeordnet im Layout-Editor.

• Window

  Legt fest, welche Views angezeigt werden und wie zwischen ihnen navigiert wird.

• Controller

  Jeder View hat einen eigenen Controller mit Methoden wie der Initialisierung und den Aktionsbehandlern. Der Component Controller enthält, was mehrere Views gemeinsam brauchen.

• Context

  Eine baumartige Datenstruktur aus Knoten und Attributen. UI-Elemente werden daran gebunden, statt Werte in Variablen zu schreiben.

• Plugs

  Ein- und Ausgänge der Views. Ein Outbound-Plug löst die Navigation aus, der Inbound-Plug des Ziel-Views nimmt sie entgegen.

• Web-Dynpro-Anwendung

  Der Einstiegspunkt mit eigener URL, der festlegt, welche Komponente und welches Window beim Aufruf starten.

Zwischen View-Context und Component-Context wird gemappt, sodass zwei Views auf denselben Datenknoten schauen, ohne dass jemand Werte hin und her kopiert. Diese Trennung ist der Grund, warum sich Web-Dynpro-Anwendungen gut zerlegen lassen: Eine Komponente kann eine andere über Interface Views einbinden, so entstehen wiederverwendbare Bausteine statt eines einzigen überladenen Bildschirmbilds.

Aufruf im Browser

Jede Web-Dynpro-Anwendung ist über eine URL erreichbar, die sich aus dem Server und dem Namen der Anwendung zusammensetzt. Hinter dem Pfad steht ein Service im Internet Communication Framework (ICF), den du in der Transaktion SICF verwaltest:

https://<server>:<port>/sap/bc/webdynpro/sap/<name_der_anwendung>?sap-client=100&sap-language=DE

Mit den Parametern sap-client und sap-language steuerst du Mandant und Sprache. In SAP S/4HANA lassen sich Web-Dynpro-Anwendungen auch als Kachel ins Fiori Launchpad einbinden. Viele Standardanwendungen, die im Launchpad stehen, sind tatsächlich Web-Dynpro-Anwendungen, erkennbar am App-Typ in der Fiori Apps Library.

Was der Wechsel vom klassischen Dynpro bedeutet

Wer aus der Welt der Bildschirmbilder mit PBO und PAI kommt, sucht anfangs den Moment, in dem man Felder befüllt. Den gibt es so nicht mehr. Statt Feldwerte zu setzen, änderst du den Context, und das Framework entscheidet, was neu gezeichnet wird. Auch die Ablaufsteuerung liegt nicht mehr in der Ablauflogik eines Bildes, sondern in Plugs, die von einem View zum nächsten navigieren.

Der praktische Gewinn ist die Ausgabe im Browser, für die auf dem Arbeitsplatz kein SAP GUI installiert sein muss, dazu die eingebaute Barrierefreiheit der Standard-UI-Elemente und mehrere Anpassungsebenen: Konfiguration durch Entwickler, Customizing für alle Anwender eines Mandanten und Personalisierung durch die einzelne Person. Der Preis ist ein starrer Rahmen, denn eigenes HTML und JavaScript sind nur in engen Grenzen vorgesehen. Wer eine Oberfläche pixelgenau nach Designvorlage bauen soll, arbeitet mit Web Dynpro gegen das Framework.

Einordnung neben Fiori

SAP setzt bei neuen Anwendungen auf SAP Fiori mit SAPUI5 im Browser und OData-Services im Backend, im ABAP-Cloud-Modell gebaut mit CDS und RAP. Web Dynpro ABAP gehört nicht zu den für ABAP Cloud freigegebenen Techniken, ist im klassischen ABAP von S/4HANA aber weiter vorhanden und unterstützt. Viele produktive Anwendungen laufen darauf, unter anderem Oberflächen, die über den Floorplan Manager konfiguriert wurden.

Für Entwicklerteams heißt das meist Bestandspflege statt Neubau. Du musst Web Dynpro lesen und ändern können, weil die Anwendung im Haus läuft, während neue Anforderungen als Fiori-App entstehen. Beide Welten teilen sich das Backend, die Geschäftslogik gehört deshalb in Klassen und nicht in den Controller, dann lässt sie sich bei einer späteren Umstellung weiterverwenden.