Tag Archives: SAP

ABAPConf Learnings – Teil #2

Posted on by

Willkommen zurück zu weiteren Learnings der ABAPConf 2024! In diesem Beitrag präsentieren wir eine Zusammenfassung eines besonders wertvollen Beitrags aus der letzten Konferenz. Hier erfahrt ihr die wichtigsten Inhalte, Tipps und Tricks, die für euch von Interesse sein könnten. Wie immer findet ihr am Ende des Blogbeitrags alle relevanten Links zu weiteren Ressourcen.

Diesmal werfen wir einen Blick auf …

ABAP Tools für Clean Code

Am letzten Tag der 3tägigen CodeConnect-Veranstaltung war der Vortrag „ABAP Tools for Clean ABAP“ von Björn Jüliger und Jörg-Michael Grassau. Diesen wollen wir kurz im Folgenden Revue passieren lassen.

Warum Clean ABAP?

Zeit in Clean ABAP Code ist gut investiert, denn:

  • Code wird lesbarer, testbarer und wartbarer.
  • Wir verbringen mehr Zeit damit unseren Code zu lesen, als ihn zu schreiben.
  • ABAP gibt es schon sehr lange mit großer Rückwärtskompatibilität, weshalb man oft auch in der Zukunft nochmal damit konfrontiert ist.

Um Clean Code noch erfolgreicher umzusetzen, gibt es ein paar hilfreiche Tools, die wir gerne näher beleuchten.

Code Pal

Code Pal ist ein Clean Code Unterstützungstool und kann innerhalb des ABAP Test Cockpits (ATC) eingeschaltet werden.

Es bietet Kontrolle über einige Checks für die Umsetzung von Clean ABAP:

Dabei ist zu beachten:

  1. Code Pal steht als Open Source Projekt via Github zur Verfügung und wird vom ATC Team betreut (Links am Ende des Artikels)
  2. Integriert werden kann ATC in den ABAP development tools (ADT) von Eclipse

ABAP Cleaner

ABAP Cleaner ist ein konfigurierbares Open-Source Tool mit dem Ziel alles, was in Zusammenhang mit ABAP Code Styling automatisiert werden kann, zu automatisieren.

Sprich: Ein konfigurierbarer Pretty Printer!

Vor allem, wenn man im Team arbeitet, kann so ein Tool sehr nützlich sein, um ein gewolltes Styling schnell zu implementieren.

Der ABAP Cleaner ist auch wieder im ADT verfügbar. (Links unten.)

Danke für’s Lesen!

Du möchtest keine weiteren ABAP Tipps und Tricks verpassen?

Dann folge uns jetzt auf LinkedIn oder abonniere unseren Newsletter, um stets über die neuesten Entwicklungen in ABAP informiert zu bleiben und keine Neuigkeiten zur ABAPConf am 5. Dezember 2024 zu verpassen.

Nähere Ausführungen zum Thema Clean ABAP entnehmen Sie bitte dem PDF oder der offiziellen Website der ABAPConf.

Zum LinkedIn-Beitrag der ABAPConf South Africa am 13. November 2024 geht es hier.

Dieser Artikel wurde verfasst von: Jonathan Rumpl, SAP Consultant der Cadaxo GmbH.

Ressourcen

Code Pal

Code pal (Classic)

  • Available for on-premise: AS ABAP 7.40 SP08 (++), not remote-enabled 

NEW: Code pal (Cloud Edition)

ABAP Cleaner

Open Source repository

Updatesite for Eclipse plug-in

Demo

Webinar

Blog post

ABAPConf Learnings – Teil #1

Posted on by

Unsere nächste ABAPConf findet noch dieses Jahr statt – und zwar am 5. Dezember 2024!

Zu unserer Freude hält nun Südafrika am 13. November 2024 auch eine eigene ABAPConf 2024 South Africa ab, und das unterstützen wir natürlich! Link dazu am Ende dieses Beitrags.

Wieder erwarten uns viele spannende Themen sowie hilfreiche Tipps und Tricks rundum ABAP.

Um die Wartezeit etwas zu verkürzen und einen Vorgeschmack für jene anzubieten, die die letzte ABAPConf verpasst haben oder nicht alle Vorträge gesehen haben, gibt es hier eine kurze Zusammenfassung eines sehr relevanten Beitrags:

Neues für ABAP CDS im ABAP Cloud Development Model

Dieser Vortrag wurde live von SAP-internen Mitarbeitern gehalten.

Wie der Titel bereits verrät, geht es um die Weiterführung der ABAP Core Data Services im ABAP Cloud Development Model, welches immer zentraler wird.

Deshalb gibt es nun einen kurzen Ein- und Ausblick, welche neuen Anwendungen und Technologien da auf uns zukommen.

3 neue CDS Entity Types

Diese drei sind

  1. CDS Simple Type
  2. CDS Enumerated Type
  3. CDS Scalar Function

und erweitern somit den Katalog:

Sehen wir sie uns näher an, beginnend mit dem

CDS Simple Type

Dieser Typ erlaubt das Definieren von elementaren Datentypen, die anstelle von DDIC Elementen in ABAP CDS verwendet werden können.

Angelegt werden kann so ein Simple Type folgendermaßen:

Anstelle des built-in data types abap.char( 30 ) könnte auch ein weiterer solcher Simple Type oder auch ein Data Element verwendet werden. Die Annotation versorgt den Datentypen mit Metadaten, die man herkömmlicherweise bei DDIC Elementen in der SE11 pflegen würde.

Dieser neue User-definierte Datentyp kann ganz einfach wie gewohnt in CDS View Entities oder in ABAP-Coding zur Typisierung von Variablen genutzt werden.

CDS Enumerated Type

Dieser Typ entspricht den aus vielen Programmiersprachen bekannten Enum Datentyp, und bildet somit ein definierte Menge an Werten. Objekte dieses Datentyps können somit nur Werte, die in diesem Enumerated Type definiert sind, annehmen.

Hier ein kurzer Ausschnitt wie der Enumerated Type definiert wird:

CDS Scalar Functions

Der Begriff Skalar kommt aus dem Teilbereich der linearen Algebra der Mathematik und bezeichnet einen dimensionslose Zahl, die üblicherweise auf Vektoren oder Matrizen angewendet wird, um diese entweder zu verkleinern oder vergrößern, sprich skalieren.

Skalarfunktionen im Kontext von SQL sind Funktionen, die einen oder mehrere Parameter entgegennehmen, und einen einzelnen Wert (= Skalar) zurückgeben.

Ein typisches Beispiel hierfür ist die AVG( )-Funktion, die den Mittelwert einer Menge von Werten zurückliefert.

Die User-definierten Skalarfunktionen sind mit AMDP (= ABAP Managed Database Procedures) verknüpft und werden mittels SQLScript implementiert.

Hier ein Beispiel um Zollgebühren zu berechnen:

Fazit

Mit diesen Erweiterungen kann jetzt noch flüssiger programmiert werden und Kundenanforderungen lassen sich noch präziser und maßgeschneiderter umsetzen, ohne erhöhten Aufwand oder an Performance zu verlieren und der Code wird noch stabiler.

Top.

Du möchtest keine weiteren ABAP Tipps und Tricks verpassen?

Dann folge uns jetzt auf LinkedIn und wir halten dich am Laufenden über die neuesten Möglichkeiten in ABAP sowie die nächste ABAPConf am 5. Dezember 2024.

Weitere Ausführungen zu dem Thema der CDS Views in ABAP Cloud entnehmen Sie bitte dem PDF oder der offiziellen Website der ABAPConf.

Zum LinkedIn-Beitrag der ABAPConf South Africa am 13. November 2024 geht es hier.

Low_NoCode Header

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

Posted on by

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.

Typische Support Anfragen in SAP Systemen

Typische Support Anfragen in SAP® Systemen

Posted on by

und wie das SQL Cockpit uns das Leben vereinfachen kann

Wer kennt das nicht. Die Systeme sind aufgesetzt und eingestellt, die Erweiterungen programmiert und die Schnittstellen laufen. Die Tests waren erfolgreich und das SAP System wurde produktiv gesetzt. Dennoch kommen immer wieder Supportanfragen herein. 

Das kann natürlich verschiedenste Gründe haben. Nehmen wir mal an, dass die Entwicklungen sehr sauber waren, das System gründlich getestet wurde und wenig es kaum neue Anforderungen gibt, die umgesetzt werden, gibt. Unrealistisch? Wahrscheinlich! Aber das es in einem agilen Umfeld mit laufenden Erweiterungen an den Systemen zu Fehlern kommt, ist irgendwie nachvollziehbar. Da ist ja immer alles in Bewegung. 

Aber was sind die häufigsten Gründe für Fehlertickets abseits vom typischen Projektgeschäft? Mir fallen da spontan 2 Gründe ein. 

  1. Verständnisfragen. Gerade, wenn User Transaktionen selten aufrufen, kann es zu Fragen wie „Was muss ich hier eingeben? Warum bekomme ich da einen Fehler?“ . Das kann man meist mit guten Schulungsunterlagen in den Griff bekommen.
  2. seltene Datenkonstellationen. Da kommt auf einmal ein Kunde vom Typ X, aus dem Land Y und der VKORG Z daher. Und da funktioniert dann die Partnerfindung im Beleg plötzlich nicht. Der Grund kann sein, dass diese seltene Kombination beim Test nie abgefragt wurde. Solche Datenkonstellationen können entweder durch Benutzer eingegeben worden sein, aber auch durch Programme verursacht worden sein (zB durch eine Migration oder Schnittstelle)

Wie löst man nun diese Fälle von Datenproblemen?

Im ersten Schritt schaut man sich wohl den Beleg, die Stammdaten des Partners und dann vielleicht auch das Customizing an. Über die regulären Transaktionen im SAP System. Wann man dann gleich draufkommt, super! Fall gelöst.

Aber meistens kommt man da nicht weiter. Vor allem im Second und Third Level Support ist man eher im Programm Code und auf der Datenbank unterwegs um Fehler zu finden und auch um abzuprüfen, ob es auch mehrere ähnlich gelagerte Fälle gibt. Und genau da lässt einen das SAP System meist ordentlich im Stich.

Der übliche Weg führt einen dann in die SE16 (wer den Transaktionscode nicht kennt: da geht es zur Einzeltabellenansicht). Dort sucht man dann nach dem entsprechenden Datensatz und hantelt sich dann langsam von Tabelle zu Tabelle. Mit dem Umweg über das Notepad oder Excel, in dem man die Daten copy&paste zwischen lagert. Das ist mühsam und aufwendig. Aber noch schlimmer: ich muss beim nächsten Mal die gleichen Schritte nochmal machen. Und ganz ehrlich, bei SAP geht es um Daten. Daten, die in einer Datenbank abgelegt sind. Und seit Anbeginn (das sind auf R/2 bezogen 42 und auf R/3 gerechnet 30 Jahre) gibt es keine vernünftige Lösung, damit diese Daten schnell, flexibel und vA auch sicher durchforstet werden können.

Ein klassisches Beispiel sind wohl Inkonsistenzen bei Adressen. Wohl auch, weil die meisten SAP Berater und Kollegen den Teil der SAP Welt auch gut kennen. Geschäftspartner werden fast überall verwendet. Um Adressen zu Geschäftspartnern zu analysieren muss man zuerst vom BP Stamm (BUT000) über den Adresslink (BUT020) zu den Adressen (ADRC) springen.

Also Tabelle – Excel – Selektionsschirm – Tabelle – Excel – Selektionsschirm – Tabelle. Schon ist man am Ziel. Aber dann kommt man drauf, dass es um Personen geht und dort auch das Feld PERSNR mitspielt. Also wieder alles von vorne…

Und jetzt kommt das SQL Cockpit ins Spiel. Hier kann ich mir die Tabellen alle gleichzeitig anschauen und verknüpfen. Da sehe ich das Problem dann auch einen Blick. Und was noch besser ist, einmal ausgeführt, bleibt die Abfrage in meiner Historie bestehen und ich kann sie jederzeit wieder ausführen. Beim ersten Problem bin ich mit dem SQL Cockpit vielleicht nur geringfügig schneller als „von Hand“, aber beim zweiten Mal spar ich schon 90% der Zeit. Und wenn es dann doch öfters auftritt, dann speichere ich diese Abfragen zusätzlich ab und stelle sie sogar meinen Kollegen zur Verfügung.

Am nächsten Tag einfach das Statement von gestern genommen:

und irgendwann nach dem 3,4 Mal (ok, bei mir wahrscheinlich nach dem 20. Mal – ich bewundere die Kollegen die so strukturiert sind) wird das ganze abgespeichert damit es auch die Kollegen nutzen können:

Ich nutze das SQL Cockpit seit 10 Jahren bei meinen Kunden. Und es ist aus meiner täglichen Arbeit nicht mehr weg zu denken. Manche Kunden nutzen es noch nicht, da muss ich dann auch immer über die SE16 arbeiten 🙁

Zählt doch mal, wie oft ihr täglich die SE16 nutzt. Wenn ihr in eurem Unternehmen auf weniger als 10 Abfragen pro Tag kommt (wohlgemerkt im gesamten Unternehmen, nicht pro User!), dann ist das SQL Cockpit für euch wahrscheinlich nicht geeignet. Sobald ihr mehr Abfragen macht, dann wird es sehr nützlich sein!.