Praktische SAP-Entwicklung „KI macht Entwickler nicht arbeitslos!“

Anbieter zum Thema

Cloudgermany.de GmbH

Kaum ein Bereich verändert sich derzeit so schnell wie die Software-Entwicklung. Ein Gespräch mit dem Entwickler Stefan Burghardt bei der Gambit Consulting GmbH über neue Technologien im Bereich SAP-Entwicklung und die Möglichkeiten mit der SAP Public Cloud.

Wie hat sich der Bereich SAP-Entwicklung in den letzten Jahren verändert? Wo kommen wir her, wo stehen wir jetzt – und warum ist das so?

Stefan Burghardt: Wir kommen ja über die letzten Jahrzehnte aus einer sehr eindimensionalen Welt für SAP-Entwickler – mit der SAP-eigenen Entwicklungsumgebung, der SE80, mit SAP GUI als einzigem Frontend und vielen Dateischnittstellen. Für lange Zeit war’s das. In den letzten zehn Jahren aber haben sich ganz viele neue Möglichkeiten eröffnet für Entwicklerinnen und Entwickler, die nicht aus diesem Kontext kommen – ob nun im Bereich Schnittstellen oder in der Entwicklung von Applikationen für SAP-Systeme mit zum Teil komplett anderen Programmiersprachen. Auch die SAP-Programmiersprache ABAP wurde deutlich weiterentwickelt, so dass mittlerweile eine Cloud-fähige Version vorhanden ist.

Wie genau unterscheidet sich denn diese neue ABAP-Cloud-Version von der klassischen-Version?

Burghardt: Es gibt neue Sprachelemente, die das Coden einfacher, schneller und präziser machen. Außerdem gibt es Elemente, die explizit auf SAP S/4HANA abzielen, um mit der Datenbank besser zu interagieren. Die allergrößte Neuerung aber ist das neue Programmiermodell – das ABAP RESTful Application Programming Model, kurz RAP. Es ist speziell dafür ausgelegt, OData-Services zu erstellen. OData ist das Protokoll, auf dem die Fiori-Apps basieren, über das aber auch APIs angeboten werden können, um zwischen verschiedenen Systemen zu kommunizieren.

Die Veränderungen werden also vor allem durch den Wandel zur Cloud ausgelöst und vorangetrieben, richtig?

Burghardt: Ja, das ist so. Man merkt an allen Ecken und Enden, dass die Cloud die Strategie vorgibt und die Neuerungen anschließend Zeit in die On-Premises-Releases Einzug halten. Deswegen kann man sich an der Cloud-Variante strategisch immer gut orientieren. Wenn man sich an die dort geltenden Standards hält und sie auf die On-Premises-Welt portiert, bleibt der Kern des eigenen SAP-S/4HANA-Systems sauber und automatisch Cloud-ready. Damit ist man für einen späteren Umzug in die Public Cloud schon gut gerüstet!

Wie können Unternehmen Cloud-ready für die Public Cloud bleiben?

Burghardt: Da spielt uns das RAP-Modell wieder in die Karten. Man ist dabei wie vorher in einem Z-Namensraum unterwegs. Anders ist aber folgendes: Man programmiert die Anwendungen nicht mehr so, dass sie direkt auf Tabellen zugreifen, sondern nutzt eine Abstraktionsschicht – die sogenannten CDS-Views. Wenn man nun ausschließlich die von SAP freigegebenen CDS-Views nutzt, schränkt das zwar etwas in der Entwicklung ein. Aber es sichert einen auch dahingehend ab, dass die Anwendungen auch noch im nächsten Release laufen – und dann auch theoretisch in die Public Cloud portierbar sind.

Was ist denn das Interessanteste der letzten fünf Jahre hinsichtlich Erneuerungen, Entwicklungen und neuer Technologien?

Burghardt: Eine der interessantesten Lösungen ist sicherlich der Copilot zum Beispiel für Eclipse und Visual Studio Code. Das ist ein Add-on für unsere Entwicklungsumgebungen. Der Copilot unterstützt uns Entwickler beim Schreiben von Code. Während man ihn benutzt, trainiert man ihn automatisch. Er nimmt wiederkehrende Aufgaben ab, damit man mehr Zeit in das Design und für die Architektur von Anwendungen verwenden kann und sich nicht mehr mit den einfacheren Aufgaben befassen muss.

Du bist schon fast 20 Jahre als Entwickler tätig. Wie hast du dir die Begeisterungsfähigkeit und Neugier bewahrt?

Burghardt: Ich finde es einfach spannend, sich mit immer neuen Themen zu befassen und den Fortschritt hautnah mitzuerleben und zu gestalten. Es macht sehr viel vom Berufsalltag bei unseren Kunden aus, dass wir gerade weg kommen von diesem blauen GUI-Bildschirm, hin zu einer modernen Oberfläche. Auch die Architektur der SAP-Systeme ist mittlerweile komplett Service-orientiert. Das heißt, wir arbeiten überall mit Webservices. Das ist heute der IT-Standard.

Was genau bewirken diese Webservices?

Burghardt: Eine Service-Architektur kann man sich vorstellen wie einen bidirektionalen Browser. Da gibt es Services, die liefern Daten – man gibt eine Adresse ein, ein paar Parameter und bekommt Daten zurück. Und es gibt Services, die nehmen Daten entgegen und buchen Belege oder ändern Stammdaten. Das beschreibt einen Webservice. Der besteht immer aus einem Endpunkt, wo die Daten hingehen sollen, und einem sogenannten Body, wo du entweder Daten bekommst oder Daten hinschicken kannst. Da jedes moderne System inzwischen Service-basiert APIs anbietet, öffnet das auch für SAP enorm viele Möglichkeiten der Kommunikation.

Was sind denn die größten Unterschiede zwischen dem neuen und dem alten Programmiermodell?

Burghardt: Ich komme ja ursprünglich aus der ABAP-Welt. Mir macht daher – neben dem Thema Schnittstellen – das RAP-Modell besonders viel Spaß, weil ich da meine Stärken aus dem ABAP anwenden kann. Zugleich arbeite ich mit einem modernen Programmiermodell und benutze ein Fiori-Frontend. Die alte Welt funktionierte meist eher schematisch. Du hast ein Programm angelegt, das eine Datei erzeugte oder eine Tabelle mit Daten zur Ansicht brachte. Auch war es zudem nicht immer ganz einfach, andere Systeme oder andere Programmiersprachen an ein SAP-System anzudocken. Das neue Programmiermodell hingegen ist darauf ausgelegt, Webservices zu bauen, die mit anderen Systemen kommunizieren können. Das bedeutet, du legst einmal einen Service an und kannst dann zum Beispiel ganz viele unterschiedliche UIs obendrauf setzen. Das heißt, man ist da viel freier in den Möglichkeiten.

Wie sind denn die Möglichkeiten in der standardisierten Public Cloud zu beurteilen? Welche Chancen der Erweiterung haben Unternehmen hier?

Burghardt: Seit dem letzten Release von Mitte 2022 lassen sich Entwicklungen mit dem RAP-Modell in SAP S/4HANA Public Cloud umsetzen. Diese Variante wird auch als „Embedded Steampunk“ bezeichnet. Wir können also eigene Tabellen anlegen, mit dem RAP-Modell programmieren und auch Fioris entwickeln und in die Cloud deployen. Diese laufen dann in dem System selbst und haben direkten Zugriff über CDS-Views. Alternativ gibt es auch eine ABAP-Platform-Variante. Diese „Standalone“-Variante ist eine ABAP-Instanz auf der BTP, die ohne die ganzen ERP-Komponenten läuft – also eine Laufzeitumgebung, die im Auslieferungszustand komplett leer ist. Als Entwickler kannst du deine Applikationen dort komplett frei bauen. Die Kommunikation mit einem oder mehreren SAP S/4HANA Backends – ob Public Cloud, Private Cloud oder On-Premises – erfolgt dann allerdings über APIs.

Es ist nicht das Ziel, vorhandene eigene Entwicklungen aus bisherigen ERP-Systemen in die Public Cloud zu übertragen. Hier ist ja der SAP-Standard das Maß aller Dinge. Aber wäre das überhaupt so möglich?

Burghardt: Nein, in der Regel nicht ohne größere Anpassungen. Da müsste es eine relativ aktuelle Entwicklung sein, die sich schon an die Standards hält und bei der der Entwickler schon das Ziel hatte, die später mal zu portieren. Das ist aber in den wenigsten Fällen so. Wenn aber die benötigten Daten über geeignete freigegebene APIs verfügen, lassen sich Anwendungen so redesignen, dass eine Portierung möglich ist.

Mit SAP Fiori steht ja eine ganze neue Bedienoberfläche für SAP S/4HANA zur Verfügung. Wie hat sich die Entwicklung dadurch verändert, Stichwort Frontend Entwicklung?

Burghardt: In der alten Welt kam ja immer alles aus einer Hand. Der Entwickler hat das Programm geschrieben, und wenn es eine starke User-Interaktion hatte, dann hat er auch die Screens designt. Das war recht intuitiv. Man zieht Eingabe- und Ausgabefelder mit der Maus auf den Bildschirm – und hat immer eine direkte Verknüpfung zu den Daten in seinem Programm. Die Fiori-Entwicklung ist natürlich deutlich umfangreicher und bietet viel mehr Möglichkeiten. Sie basiert aber auch auf einer anderen Programmiersprache, nämlich SAP UI5. Die Logik wird in JavaScript geschrieben, das ist etwas völlig anderes als ABAP.

Könnte man dann eigentlich als Entwickler beginnen, ohne ABAP zu können?

Burghardt: Ich hätte die Frage vor dem Beginn der Cloud-Strategie mit „Nein“ beantwortet, aber mittlerweile ginge das, ja! Klar ist aber auch, dass ABAP der Kern jedes SAP-Systems bleibt. Daran wird sich auch so schnell nichts ändern. Deswegen schulen wir alle neuen Kolleginnen und Kollegen ohne ABAP-Kenntnisse auch in ABAP, um eine Basis zu schaffen. Jeder soll sich bis zu einem gewissen Grad selbst helfen können. Dafür sind ABAP-Kenntnisse ganz hilfreich – aber Einstellungsvoraussetzung ist das nicht mehr.

Ein immer wichtigeres Thema ist auch bei SAP die Künstliche Intelligenz. Die Public Cloud zum Beispiel enthält ja schon diverse integrierte KI-Services, die man automatisch nutzen kann. Wie siehst du das Thema? Wo stehen wir da in fünf Jahren?

Burghardt: Das wird enorm wachsen, das ist klar. Neben diesen integrierten Services in dem ERP-System gibt es auch auf der BTP längst eine Reihe von Tools, mit denen man noch individuellere Lösungen entwickeln kann. Das sind Werkzeuge, die gerade entstehen, wo der Kunde oder wir zusammen mit dem Kunden ganz individuelle Lösungen erschaffen können, die sich dann zum Beispiel an Data Lakes – Landschaften mit strukturierten und unstrukturierten Daten – anbinden lassen. Die KI kann man auch an Hyperscaler anbinden, um Daten berechnen zu lassen. Ich glaube, das ist ein Feld, das wird sich in den nächsten fünf Jahren noch massiv weiterentwickeln.

Für bestimmte Anforderungen entwickeln Sie auch individuelle Apps, also spezielle Anwendungen, oder?

Burghardt: Ja, wir entwickeln Fiori-Apps, die dann so beim Kunden laufen. Es kann zum Beispiel sein, dass ein Unternehmen statistische Kennzahlen vereinfacht und in großen Mengen erfassen möchte und die Standardlösung dafür nicht ausreicht. Dann erstellen wir eine App, in die er seine Daten eingeben kann oder wo er eine Datei hochladen kann mit mehreren Buchungen. Im Ergebnis kriegt er dann zum Beispiel die Verbuchung und Fehlermeldungen angezeigt und erfährt, wie viele Belege erzeugt wurden und welche Belegnummern diese haben. Das ist ein alltäglicher Anwendungsfall.

Mit welchen typischen Anforderungen kommen Kunden denn sonst zu Gambit? Welche Basis-Anforderungen gibt es, wenn es zum Beispiel um eine Cloud-Transformation geht?

Burghardt: In jedem Projekt haben wir Schnittstellen. Wir müssen also Umfeldsysteme anbinden, in welchem Format auch immer. Das ist sehr unterschiedlich. Zudem haben wir oft mit zusätzlichen Feldern an Datenobjekten zu tun, also einer zusätzlichen Logik. Das bedeutet, dass wenn irgendwo ein Beleg generiert wird, zusätzlich noch dieses und jenes passieren soll oder eine zusätzliche Prüfung stattfinden soll. Oder es geht um ganz individuelle Entwicklungen, um Cockpits beispielsweise, die mehrere Datentöpfe zusammenbringen und so das Handling der Daten erleichtern. Das sind einige typischen Anforderungen.

Gambit hat 2023 selbst als Early Adopter die SAP S/4HANA Public Cloud eingeführt. Was waren die Erfahrungen, die hieraus gezogen wurden?

Burghardt: Wir haben sehr viel dabei gelernt, was unseren Kunden jetzt zugutekommt. Eine der wichtigsten Erkenntnisse für mich war, dass die Public Cloud die Blaupause ist für alles, was man von On-Premises später in die Cloud mitnehmen kann. Die Restriktionen, sauber zu programmieren – die sind da knallhart. Wenn man in einem On-Premises-System einmal eine Warnung angezeigt bekommt, dass man als Entwickler etwas nicht nutzen soll, dann lässt sich das auch mal wegklicken. Ganz nach dem Motto: Ich habe das jetzt registriert, aber es geht schon. In der Public Cloud allerdings ist das eine Fehlermeldung, die man nicht aushebeln kann!

(ID:50238717)