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. Firefox, Opera, Safari, Chrome oder Edge, 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 Sheets 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 Frontend-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 letztlich die Daten bereitstellt oder verarbeitet. 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.

 
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!
 
Im Rahmen der Entwicklung und Nutzung von Fiori-Apps, z. B. in Form von UI5-Anwendungen, werden vielfach auch unwissentlich zusätzliche sicherheitskritische Schwachstellen erzeugt, weil die Nutzung (auch in Teilen) vom Quelltext der Anwendung, der kompilierte JavaScript-Code von Node.js oder sonstige zur Laufzeit genutzte Anwendungsbestandteile etc. aus ungeprüften externen Quellen erfolgt oder dort extern, insbesondere z. B. in Nicht-EU-Ländern, abgelegt wird. Es beginnt bereits mit der Versionsverwaltungs-Software Git, falls extern gehostete Server zum Einsatz kommen, insbesondere beim US-amerikanischen Unternehmen "GitHub, Inc.".
 
Daher sollte die Verwendung von Git, GitHub, npm (ehemals Node Package Manager), der JavaScript-Laufzeitumgebung Node.js, den (extern) eingebundenen JavaScript-Dateien der US-amerikanischen Unternehmen "Cloudflare, Inc." oder "Google, Inc." bzgl. Content Delivery Network, Reverse-Proxy oder zur CAPTCHA-Prüfung, etc. sehr große Aufmerksamkeit geschenkt werden. Neben den sicherheitskritischen Schwachstellen kommen sonst ggf. auch noch datenschutzrechtliche Probleme hinzu...