SAPUI5 ist kein ABAP

SAPUI5 (SAP User Interface 5) ist nichts anderes als ein Development Toolkit für SAP-Anwendungen für die neue Benutzeroberfläche von S/4HANA-Systemen, die dem SAP Fiori Designprinzip folgen. Diese Webanwendungen sind sowohl für den Desktop als auch für mobile Endgeräte, wie z. B. Smartphones oder Tablets geeignet, weil für die Nutzung lediglich ein beliebiger, aktueller HTML-fähiger Browser, wie z. B. Edge, Chrome, Safari oder Firefox, benötigt wird und Web-Entwickler Fiori-Apps einfacher erstellen können. SAPUI5-Anwendungen sind daher auch nicht direkt im SAPGUI ausführbar.
 
SAPUI5 verwendet hierzu aktuelle Webstandards:

• für die Gestaltung der Ausgabe und die Verarbeitungslogik:
  • Hypertext Markup Language 5 (HTML5)
  • JavaScript
  • Cascading Style Sheet 3 (CSS3)
 

• für die eigentlichen Daten und zur Definition der Datenstrukturen:
  • JavaScript Object Notation (JSON)
  • Extensible Markup Language (XML)

 
Eine typische SAPUI5-Anwendung enthält z. B. folgendes HTML-Coding:

Die eigentliche Oberflächenentwicklung einer SAPUI5-Anwendung erledigt ein Web-Entwickler, jetzt vielfach auch SAP-Entwickler genannt, um bereitgestellte WebServices konsumieren zu können, die zuvor von einem ABAP-Entwickler bereitgestellt wurden. Der Web-Entwickler muss hohe Ansprüche bei der SAPUI5-Anwendungsentwicklung erfüllen, da bereits im Frondend-Server eingegebene Daten auf Gültigkeit und Sinnhaftigkeit geprüft werden sollten, bevor diese vom Frontend-Server über den SAP Gateway Server an den Backend-Server zur weiteren Verarbeitung gesendet werden. Im Fehlerfall werden sonst vom Backend ggf. alle Daten inkl. aller aufgelaufenen Meldungen vom Typ Fehler, Warnung, Information etc. wieder zum Frontend über das Netzwerk gesendet (Stichwort: Performanz!).
 
Beim SAPGUI nennt sich die Implementierung der Ausgabe- und Verarbeitungslogik auch heute noch Dialogentwicklung, die tatsächlich durch einen ABAP-Entwickler mittels Dynpro (neudeutsch Screen) erfolgt, u. a. auch deshalb weil die Datenbeschaffung vor der Ausgabe und die Validierung und Verarbeitung nach der Eingabe im Persistence Layer im Backend-Server, genauer dem SAP-System, stattfindet.

Im Hintergrund werden hierfür aus dem Client, dem Web-Browser, auf dem (neuen) Frontend-Server über den SAP Gateway Server im Persistence Layer im Backend-Server, dem SAP-System, die im WebService definierte ABAP-Anwendung ausgeführt, die letzlich die Daten bereitstellt oder verarbietet. Sofern der erforderliche WebService bereits definiert aber nicht aktiviert ist, kann dieser auch durch einen SAP-Basisadministrator, einen Power User oder einen ABAP-Entwickler etc. einfach aktiviert werden, fertig! Erst wenn eine neue oder geänderte Verarbeitungslogik gewünscht ist, kommt der ABAP-Entwickler ins Spiel, aber auch nur, um z. B. über einen Core Data Service (CDS) View mittels Open Data Protocol (OData) die gewünschte Datenverarbeitung für einen WebService zur Verfügung zu stellen.
 

Was sind OData Services?

OData ist ein auf Representational State Transfer (REST) basierendes Protokoll, das speziell entwickelt wurde, um den Zugriff auf Datenquellen wie Datenbanken oder WebServices zu standardisieren. Mit OData können Daten über einfache HTTP-Anfragen abgefragt, erstellt, aktualisiert oder gelöscht werden. Es basiert auf offenen Standards wie HTTP, JSON und XML, was eine hohe Interoperabilität zwischen verschiedenen Plattformen gewährleistet.
 
In einer SAP-Systemlandschaft wird OData hauptsächlich über das SAP Gateway bereitgestellt und dient als Brücke zwischen der Backend-Logik und dem neuen Frontend-Server, über die die UI5-Anwendungen ausgeführt werden.

"... SAP GUI for Windows 8.00 was shipped on 27th of January 2023 and will be supported until 12th of January 2027. ..."
 
Das mittlerweile auch schon 12 Jahre alte SAPUI5, soll der offizielle Ersatz für den in die Jahre gekommenen guten alten SAPGUI sein, der (geplant) ab 2027 keinen Support mehr erhalten soll, jedoch auch in einem SAP S/4HANA-System in vielen Bereichen sogar heute immer deutlich schneller ist, als das "neue" SAPUI5.
 
Dies ist seitens der SAP jetzt übrigens der dritte Anlauf, sich vom SAPGUI zu verabschieden. Die bisherigen Versuche, den SAPGUI vollständig durch Webanwendungen zu ersetzen, scheiterten unter anderem wegen der schlechten Performanz und der damit einhergehenden fehlenden Akzeptanz durch die Endanwender, also durch die SAP-Kunden:

• Business Server Pages (BSP)
• WebDynpro (for Java)

Zwischenzeitlich sind die Geschwindigkeiten der heute genutzten Datenverbindungen, vormals Telefon jetzt Breitbandinternet, allerdings deutlich schneller geworden, so dass es diesmal tatsächlich klappen könnte ...
 
... aber auch nur dann, wenn es die SAP SE tatsächlich schafft, alle Funktionalitäten über SAPUI5 erreichbar zu machen. Speziell im Entwicklungsbereich gibt es noch sehr viele Bereiche, für die ein SAPGUI benötigt wird, weil die neuen Entwicklungsumgebungen, wie z. B. dem ABAP Development Tools (ADT), also Eclipse mit zahlreichen Erweiterungen, etc., dies (noch) nicht abdecken. Ferner gibt es im normalen Benutzerbetrieb ggf. auch noch Schwachstellen, wie z. B. bei der Massendatenerfassung, bei der im SAPGUI untereinander und/oder nebeneinander stehende Felder einfach mittels Copy-And-Paste bestückt wurden. In einem Web-Browser funktioniert dass so leider nicht mehr...

 
Mit SAPUI5 gibt es leider auch wieder die altbekannten sicherheitskritischen Schwachstellen der Business Server Pages (BSP) vom Typ Cross-Site Scripting (CSS/XSS), weil SAPUI5 ja auch nur eine HTML-Webseite ist und SAPUI5-Anwendungen auch im SAP-System als BSP-Anwendungen, allerdings jetzt mit weiteren Zusatzdaten, abgelegt werden können, aber nicht müssen.
 
Die Web-Entwickler sind daher auch in diesem Punkt gefordert, sich dieser Schwachstelle bewusst anzunehmen, und alle über die SAPUI5-Anwendung eingegebenen Daten erst nach entsprechender und erfolgreicher Prüfung weiter zu verarbeiten!