Blog

Hat Sie die Frage verwirrt? Gut so, danke für die Aufmerksamkeit. Zugegeben, es ist schwer Äpfel mit Birnen zu vergleichen, beschreibt doch OData ein Protokoll, während hinter SAP GUI ein Programm zum Arbeiten mit SAP-Systemen steckt. Hinkt der Vergleich oder steckt mehr dahinter?

OData, kurz für Open Data Protocol, und SAP GUI, kurz für SAP Graphical User Interface, gegenüberzustellen und zu vergleichen, ist ungewöhnlich. Aber es gibt Gründe dafür. Gründe, die vor allem von SAP GUI und Herausforderungen damit herrühren. So haben klassische SAP-GUI-Programme den „Beigeschmack“, oft unübersichtlich und unflexibel zu sein. Meistens sind auch die Routinen zum Beschaffen von Daten bzw. zum Speichern derselben derart eng an das Programm gekoppelt, dass diese nicht wiederverwendet werden können.

Wird beispielsweise eine vereinfachte Version eines Programms benötigt, müssen oftmals bestehende Quellcodes kopiert und in späterer Folge an mehreren Stellen gewartet werden. Außerdem können Funktionen, die das Programm bietet, nur schwer automatisiert, an andere Tools oder an Workflows angebunden werden.

OData nimmt sich SAP-GUI-Herausforderungen an

Genau an diesem Punkt kommt OData ins Spiel. Das Protokoll, das auf HTTP aufsetzt, kann für einen einheitlichen Zugriff auf das Backend, in diesem Fall das SAP-System, verwendet werden. Mit Hilfe von Metadaten können automatisiert die zur Verfügung gestellten „Funktionen“ ausgelesen werden. Und basierend auf diesen Metadaten und den gebotenen Möglichkeiten können dann neue Fiori- bzw. UI5-Apps für Anwender:innen umgesetzt werden.

Greift man an diesem Punkt also den Vergleich mit dem SAP GUI erneut auf, stehen nun zwei Anwendungen gegenüber: Anwendungen im SAP GUI und UI5-Apps im Browser. Mit beiden Programmen lässt sich arbeiten, die „OData-UI5-Browser“-Variante bringt aber gleich mehrere Vorteile mit sich: Durch das Verwenden einer klar definierten Schnittstelle wird das Datenmodell vom User Interface entkoppelt. Frontend- und Backendentwicklungen können voneinander unabhängig durchgeführt werden. Die zugehörigen Tests ebenfalls und im Idealfall automatisiert. Außerdem ermöglicht die Trennung zwischen Backend und Frontend, dass die Backendfunktionen von verschiedenen Apps verwendet werden können, ohne am Backend weitere Anpassungen durchführen zu müssen.

OData im Einsatz

Soweit die Theorie. Wie sieht das Ganze aber nun tatsächlich in der Praxis aus? Wir bei SRB verwenden SAP CATS, kurz für Cross-Application Time Sheet, für die Erfassung unserer Tätigkeiten. Die Standardtransaktion CAT2 wird bei uns aber nur mehr selten verwendet, da wir mittels ABAP RAP die Zeiterfassung per OData-Service zur Verfügung stellen.

Mit Hilfe einer selbst entwickelten UI5-App, die an das Service angebunden ist, steht die App auf verschiedenen Geräteklassen praktisch betriebssystemunabhängig zur Verfügung, kann dadurch also genauso auf klassischen Desktopcomputern wie auf Smartphones und Tablets verwendet werden.

Aber ich wäre ja kein richtiger Entwickler, wenn ich nicht noch eine „nerdige“ Variante präsentieren würde. Daher habe ich eine kleine „Anwendung“ mit graphischen UI für Linux entwickelt, mit der Zeitbuchungen über das OData-Service getätigt werden können. Entstanden ist dabei das Programm `andDogs`, genau genommen ein Bash-Skript, das weniger als 100 Zeilen benötigt. Das Skript findet sich auf GitHub im Repository srb/srb_anddogs.

Allein das zeigt: Durch vernünftige Schnittstellen zum Backend können neue oder zusätzliche Programme relativ schnell umgesetzt werden. Vielleicht mag der initiale Aufwand im Vergleich zu einer SAP-GUI-Entwicklung höher sein, zukunftssicherer ist man aber mit offenen OData-Schnittstellen allemal.

So bieten Apps in Browsern viele Möglichkeiten, die im klassischem GUI nur schwer oder gar nicht umgesetzt werden können wie beispielsweise die interaktive Anzeige von Maschinen oder Bluetooth-Integration. Mit Hilfe von Webtechniken wie HTML5, WebGPU und WebAssembly kann weiters die User Experience auf das nächste Level katapultiert werden. Und doch ist man damit nicht auf Webanwendungen beschränkt, denn mit nativen Anwendungen für Android oder iOS ist ebenso ein Zugriff auf die OData-Services möglich. Kurz gesagt: Offene Schnittstellen führen zu einem bunten Ökosystem an neuen Anwendungen, die sich an verschiedensten Anwendertypen orientieren.

Warum sich der Blick auf OData und SAP GUI im Zusammenspiel lohnt

In der stetig voranschreitenden Welt der Technologie werden die Werkzeuge, die wir nutzen, oft von neuen Ansätzen und Möglichkeiten herausgefordert. Der scheinbare Vergleich von OData und SAP GUI mag anfangs ungewöhnlich erscheinen, doch er bringt den Status-Quo der heutigen SAP-Entwicklungslandschaft treffend auf den Punkt: Während klassische SAP-GUI-Anwendungen zweifellos ihren Platz haben und ihre Rolle erfüllen, eröffnet OData als fortschrittliches Protokoll eine Welt voller (neuer) Potenziale.

Die Erfahrung lehrt uns, dass flexible Schnittstellen wie OData den Weg für Innovationen ebnen. Ihre Fähigkeit, Backend-Funktionen von verschiedenen Apps zu entkoppeln, ermöglicht es, Entwicklungsprozesse agiler zu gestalten und Anwendungen plattformübergreifend verfügbar zu machen. Dies verleiht nicht nur der Entwicklung, sondern auch der Benutzererfahrung eine neue Dimension und öffnet die Tür zu neuen, kreativen Anwendungsmöglichkeiten, die die vielfältigen Bedürfnisse der User adressieren.

Praktische Beispiele zeigen eindrucksvoll, wie die Verwendung von OData und UI5-Apps in der Zeiterfassung und darüber hinaus das Tor zu einem vielfältigen Ökosystem von Anwendungen öffnet. Von betriebssystemunabhängigen UI5-Apps bis hin zu „nerdigen“ Linux-Anwendungen beweisen Sie, wie durchdachte Schnittstellen neue Horizonte eröffnen.

In der Wahl zwischen OData und SAP GUI geht es also nicht darum, das eine gegen das andere auszuspielen, sondern darum, die vielfältigen Möglichkeiten, die moderne Technologien bieten, zu erkennen und zu nutzen. Mit OData und seinen Vorteilen steht uns ein Werkzeug zur Verfügung, das uns ermutigt, über traditionelle Grenzen hinauszugehen und eine neue Ära der Anwendungsentwicklung einzuleiten. Es liegt an uns, diese Möglichkeiten zu ergreifen und die Zukunft der Technologie aktiv zu gestalten.