Webinar – RAP endlich checken

Vielen Dank für Ihre Teilnahme an unserem Webinar!

Vielen Dank an alle TeilnehmerInnen unseres Webinars zum Thema RAP endlich checken.

Unterlagen/Links zum Webinar

Hands-on Webinar

Links

LinkedIn Kontakte

ABAPConf 2024

ABAP Webinar – ABAP Cloud Teil 2

Vielen Dank für Ihre Teilnahme an unserem Webinar!

Vielen Dank an alle TeilnehmerInnen unseres Webinars zum Thema ABAP Cloud.

Unterlagen/Links zum Webinar

Links

LinkedIn Kontakte

Unser nächstes Webinar

ABAPConf 2024

ABAP Webinar – ABAP Cloud

Vielen Dank für Ihre Teilnahme an unserem Webinar!

Vielen Dank an alle TeilnehmerInnen unseres Webinars zum Thema ABAP Cloud.

Unterlagen/Links zum Webinar

ABAP Cloud Teil 2

Links

LinkedIn Kontakte

Low_NoCode Header

Low-Code / No-Code – Die Lösung für die S/4HANA® Migration?

Wer mich kennt weiß, dass ich Low-Code/No-Code Lösungen mit einer gewissen Skepsis betrachte. Nicht weil es sich dabei um schwache Lösungen handelt. Low-Code / No-Code Anwendungen können durchaus den Flaschenhals des „Fachkräftemangel“ lindern.

SAP® und Low-Code/No-Code – Eine Reise durch die Zeit

Als ich mich mit dem Blogbeitrag erstmals auseinandergesetzt hab, ist mir schnell bewusst geworden, dass ich eigentlich vor 30 Jahren als Low-Code ABAP Entwickler angefangen habe. Ich habe damals im R/2 Reports erstellt. Diese wurden mit Hilfe von logischen Datenbanken realisiert. Ein Entwickler musste lediglich ein paar wenige Kommandos wie GET, CHECK oder WRITE verwenden.

Eigentlich sehr genial, denn damals konnten wir Business-Anforderungen teilweise noch in wenigen Stunden umsetzen. Für Transaktionen konnten wir einen einfachen Screen Painter verwenden und mit PBO und PAI wurde eine sehr simple Dynprologik implementiert.

Schnittstellen wurden mit Hilfe von Batch-Input Mappen auf die Transaktionen realisiert. Eine einheitliche Schnittstellentechnologie für alle – wirklich alle – SAP-Transaktion. Genial!

Am Anfang von R/3 gab es erstmals modulspezifische Berichtsfunktionen (z.B. Report Writer/Report Painter), welche bald durch SAP Query bzw. Quick Viewer ergänzt wurden. Nur zur Verdeutlichung, wir reden hier von einer Zeit vor der 2000er Wende. GuiXT sollte man auch nicht unerwähnt lassen. Ein Tool, mit dem man SAP Gui Screens einfach adaptieren/optimieren konnte.

Und Mitte der 2000er Jahre hat SAP mit dem Visual Composer bzw. dem Composite Application Framework erstmals einen (meiner Meinung nach erfolglosen) Versuch in Richtung Low-Code/No-Code Applikation gestartet.

Aktuelle Low-Code/No-Code Tools der SAP®

Derzeit zählen Tools wie Screen Personas, Fiori Elements oder ganz aktuell SAP AppGyver zu den Low-Code/No-Code Tools der SAP. Im nachfolgenden Teil gehe ich ganz kurz auf diese Anwendungen ein und stelle wie immer weiterführende Links zur Verfügung.

Screen Personas

Ziel von Screen Personas ist es bestehende SAP Gui Transaktionen – auch Kundenentwicklungen – in ein modernes, zeitgemäßes Erscheinungsbild zu bringen. Diese können auch ganz einfach in ein Fiori Launchpad integriert werden. Die Möglichkeiten von Screen Personas sind überschaubar, können aber durch Scripts erweitert werden.

Fiori Elements

Fiori Elements kann man auch zu den Low-Code Tools zählen. Die Darstellung und das Verhalten von Fiori Elements Anwendungen wird rein durch Metadaten (lokal oder vom Backend) gesteuert. Die Daten werden mittels OData (z.B. ABAP RAP oder CAP) prozessiert. SAP selber liefert viele ihrer Fiori Anwendungen in Form von Fiori Elements aus.

Fiori Elements werden mit dem Business Application Studio oder Visual Studio Code erstellt und können bei Bedarf mit Hilfe von den Fiori Tools auch relativ einfach erweitert werden.

SAP® AppGyver

Das ist der jüngste Zukauf der SAP aus dem Jahre 2021. Der finnische Anbieter ist ein weltweit bekannter Anbieter von No-Code Tools und wird derzeit von der SAP sehr gepusht. Auf den ersten Blick sieht das Tool interessant aus. Aber da die Erweiterungsmöglichkeiten sehr, sehr eingeschränkt sind, bin ich nicht sicher ob sich dieses Tool zum Erstellen von Apps für S/4HANA eigenen kann.

Low-Code Plattformen anderer Hersteller

Natürlich bietet nicht nur SAP Low-Code Tools (für SAP) an. Ich möchte hier drei bekannte Anbieter aufzählen, die ebenfalls im Low-Code Teich fischen. Alle Anbieter gehören eher zu den Low-Code Anbietern, sprich die erstellten Anwendungen können mehr oder weniger individuell erweitert werden. Wie genau, muss man sich von Hersteller zu Hersteller speziell ansehen. Und natürlich sind hier extra Lizenzen für die Hersteller zu entrichten.

Neptune

Neptune wurde bereits 2011 von zwei erfahrenen SAP-Beratern gegründet. Von Anfang an mit dem Fokus das Leben eines SAP Developers einfacher zu gestalten. Neptune ist in über 40 Ländern im Einsatz und verfügt über 600 Kunden.

Interessant ist Neptune deshalb, da es weder Gateway noch RAP für die Erstellung von SAPUI5 Anwendungen benötigt und direkt im SAP als Transaktion verfügbar ist.

Simplifier

Simplifier bzw. die Vorgängerfirm iTiZZiMO ist seit 2012 am Markt und verfügt laut eigenen Angaben über viele produktive Referenzen. Simplifier scheint auf den ersten Blick auch für eine Pro-Entwickler interessant zu sein, da es viele Erweiterungsmöglichkeiten gibt.

Mendix

Von Mendix habe ich zuerst vor 3 oder 4 Jahren bei einer TechEd erstmals im Zusammenhang mit SAP gehört. Laut eigenen Angaben zählt Mendix zu den Weltmarktführern im Low-Code Bereich und wurde 2018 von Siemens übernommen. In letzter Zeit habe ich jedoch nicht mehr so oft von SAP & Mendix gehört.

Low-Code/No-Code – Einbahn?

Generelles Risiko von Low-Code/No-Code ist die eingeschränkte oder überhaupt unmögliche Erweiterung durch individuelles Coding. Sobald man sich für einen Low-Code/No-Code Ansatz entscheidet muss man sich diesem Risiko bewusst sein.

Beispielsweise kann ich aus eigener Erfahrung bestätigen, dass man die Fiori Elements umfangreich erweitern kann. Bei AppGyver ist dies laut meinem Kenntnisstand derzeit nicht oder nur in sehr geringem Ausmaß möglich.

SAP Community Call

SAP® Community Call – Was muss ein ABAP® Entwickler wissen um in S/4 bestehen zu können

Am 15. Dezember 2020 haben wir in einem von der SAP organisierten Community Call über ABAP und was ein Entwickler unbedingt wissen sollte um in S/4 bestehen zu können gesprochen. Natürlich gäbe es viel mehr Themen und mancher Teilnehmer sieht den einen oder anderen Punkt vielleicht anders. Jedenfalls haben wir im Call über die aus unserer Sicht wichtigsten Punkte gesprochen:

  • ABAP Syntax: ABAP Objects, Expressions
  • Code Pushdown: SQL Expressions, CTEs, CDS Views, AMDP
  • IDEs: ADT, BAS, Visual Studio Code
  • Tools in ABAP: Statische Codechecks, Analysetools in ABAP
  • Programmiermodelle: BOPF, RAP, OData, Fiori Elements, Gateway
  • Erweiterbarkeit: OnPrem, In-App, Side-by-Side
  • ABAP Steampunk
  • ABAP Open Source: dotabap.org, abapgit
  • Clean Code: Clean ABAP, Refactoring, Unit Tests

Der Community Call wurde aufgezeichnet und steht via https://www.youtube.com/watch?v=MdHwS_C7mHE&feature=youtu.be zur Verfügung.

PDF Slides mit Links: SAP Community Call S4ABAP Link

R/2 bzw. ABAP® /4 Programmierer gesucht? Echt jetzt?

Wie die vielen anderen U-Bahn Fahrgäste starre ich während dem morgendlichen Weg in die Arbeit auf mein Handy und scrolle Facebook, Instagram und Twitter durch. Vor ein paar Tagen wurde ich plötzlich auf Twitter bei einem Jobinserat stutzig:

Da sucht doch tatsächlich eine Firma aus Berlin einen ABAP /4 Entwickler. Echt? Gibt’s ja nicht! Zumal ich mich erinnere, dass ABAP als ABAP /4 nur in der R/2 und den ganz frühen R/3 Zeiten bezeichnet wurde. Sucht da tatsächlich jemand einen R/2 Entwickler? Oder einen R/3 Entwickler der nicht objektorientiert entwickeln kann? Oder meinen die vielleicht einen S/4HANA Entwickler? Der Zusatz /4 wurde jedenfalls noch vor dem Jahrtausendwechsel mit dem Einzug der objektorientierten Welt in ABAP entfernt. Da der Bewerber auch noch ABAP-OO kennen soll war mir dann doch schnell klar, dass ich leider nicht mehr als R/2 Entwickler einsteigen kann.

 

ABAP – ABAP /4 – ABAP Objects/ABAP OO – modernes ABAP

Vermutlich weiß jeder, dass ABAP für Allgmeiner Berichts Aufbereitungs Prozessor oder in der englischen Form für Advanced Business Application Programming steht.

ABAP /4 wurde die Programmiersprache bereits unter R/2 bezeichnet und in den frühen R/3 Zeiten wieder entfernt. /4 sollte zeigen, dass es sich bei ABAP um eine Programmiersprache der 4. Generation (4GL) handelt.

Als ABAP Objects/ABAP OO wird der Bestandteil von ABAP bezeichnet, der die objektorientierte Programmierung auf Basis von Klassen und Interfaces erlaubt. ABAP Objects wurde mit SAP R/3 4.6 verfügbar und sollte in der Zwischenzeit jeder ABAP Entwickler beherrschen.

Zuletzt taucht auch immer öfter der Begriff modernes ABAP. ABAP ist eine sehr lebendige Programmiersprache welche laufend weiterentwickelt. Als ABAP Entwickler sollten wir danach trachten immer den aktuellesten, möglichen ABAP Syntax – modernes ABAP – einzusetzen.

Modernes ABAP

Im Laufe der Jahre wurden viele Weiterentwicklungen an vorhandenen Spracheigenschaften vorgenommen oder gänzlich neue Funktionen hinzugefügt. ABAP Objects war sicherlich die mächtigste Erweiterung von ABAP, aber auch kleinere Erweiterungen wie z.B. die Regular Expressions (REGEX) oder zuletzt die impliziten Datendefinitionen können hier genannt werden.

SAP verfolgt im ABAP seit den ersten Anfängen die strikte Abwärtskompatibilität. Ein nicht unbedeutender Teil der nach wie vor laufenden Entwicklungen wurden vor 10, 20 Jahren oder gar noch zu R/2 Zeiten erstellt. Nachfolgend ein Beispiel aus einem ABAP 7.50 System:

Diese strikte Abwärtskompatibilität birgt aber für die ABAP Entwickler große Gefahren:

  • Ein arrivierter ABAP Entwickler kann auch mit einem etwas angegrauten Wissen nach wie vor ABAP Programme erstellen. In einem R/3 System kann er sogar ohne ABAP Objects tarnen und täuschen. Es besteht oft keine zwingende Notwendigkeit neue Konzepte einzusetzen.
  • Ein neuer ABAP Entwickler wird wegen der vielen Möglichkeiten verwirrt sein. Sehr oft werden bestehende Programme angepasst oder kopiert wodurch die alten Konzepte fortgesetzt werden.

Um dieses Verrotten der Entwicklungen zu verhindern muss man im Hinblick auf den ABAP Syntax nur zwei Regeln beachten:

Verwenden Sie keine obsoleten Sprachelemente

Informieren Sie sich regelmäßig über Neuheiten und die ABAP Releasenotes

 

Obsolte Sprachelemente

Bei ABAP Objects ist ein Großteil der obsoleten Anweisungen bereits verboten. Allein schon deshalb sollte man unbedingt ABAP Objects einsetzen. Obsolete Sprachelemente sollten in jedem Fall vermieden werden. Es gibt für alle diese Sprachelemente neuer Formen mit wesentlich mehr Möglichkeiten.

Betrachten wir das einfache Beispiel MOVE

MOVE ist schon seit einigen Jahren obsolet und wird aber nach wie vor in vielen Programmen eingesetzt. Mit MOVE kann man z.B. weder Konstrukturausdrücke oder Tabellenaustrücke verwenden noch eine Inline-Deklaration einsetzten. Statt MOVE sollte nur mehr einheitlich mit = oder ?= gearbeitet werden:

 

Übersicht über die obsoleten ABAP Sprachelemente

 

ABAP Releasenotes

Mit jedem neuen ABAP Release, aktualisiert SAP auch die ABAP Releasenotes. Ja, es gibt tatsächlich ABAP Releasenotes und ein regelmäßiger Blick lohnt sich. Meistens findet man bei neuen ABAP Releases auch unzählige Blogs auf sdn.sap.com. Hier zwei Blogs zum aktuellen ABAP Release welche einen optimalen Überblick liefern:

Links zu den ABAP Releasenotes

Unter dem nachfolgenden Link findet man alle ABAP Releasenotes seit der Version 3.0 bis zum jetzt aktuellesten System ABAP 7.52:

 

Fazit

Wir ABAP Entwickler sind dafür verantwortlich gute und wartungsfreundliche Entwicklungen vorzunehmen. Die Vermeidung von obsoleten Kommandos oder Verfahren ist ein wichtiger Bestandteil von wartungsfreundlichen Entwicklungen. Wir selbst gehen ja auch davon aus, dass sich Ärzte, Automechaniker oder sogar Politiker regelmäßig weiterbilden und „obsolete“ Verfahren nicht mehr einsetzen.