Category: ABAP

A significant portion of ABAP programming is selecting data from database tables and reconstructing them for specialized use cases. Information shown to the consumer of the program is temporary fields, calculated using persisted data as input. Since the development of the HANA database, SAP changed the approach to accessing and calculating data in their programs and advises developers to do so as well. Most notably, the “Code to Data” paradigm aims to move unnecessary data retrieval and calculations from the application server to the database server. Calculated fields – be it through arithmetic calculations, string manipulations or complex case expressions – can now be provided without even accessing the ABAP layer. This is still a relatively new concept to many developers, as most of the code they have written so far juggles the retrieved data in ABAP code. For maximum time efficiency, new methods must be learned, some of which I will briefly explain. This blog does not contain an introduction with examples of either method, but merely describes the function and its cases of use.

CDS Views Core

Data Services (CDS) is the key component of all data modeling in HANA. While widely known, some developers still treat it as a mere join on database tables, unaware that CDS is a fully-fledged SQL language, that is also relatively easy to learn. Anything previously done in Open SQL can be directly implemented in the view without the use of any ABAP. It also provides annotations a consumer can utilize. Multistep operations might require the use of several CDS views, creating a view stack that can become hard to read.

ABAP Code

In special cases, it might still be necessary to use ABAP code to retrieve and calculate data. In fact, some of the new HANA tools are made specifically for ABAP.
CDS custom entities are data definitions that do not use SQL. Unlike CDS views, they have no data source but gather the data from ABAP code (which, of course, can include data sources). It requires a dedicated class that implements the query in detail, including counting and paging. Custom entities are primarily used when SQL is incapable of retrieving the requested data, for example, from a remote data source that can only be accessed by ABAP code or when the business logic is simply too complex for SQL. The finished custom entity can then be used like any other data source. It is like a temporary data view that is calculated in the ABAP code.
In the context of RAP, CDS views can make use of virtual fields that are calculated in dedicated ABAP classes. The regular fields of the view are used as input to calculate the virtual field for each row individually. A simple example would be an adjusted price to a base price that is fetched from the database. In contrast to customs entities, they are only single fields of a view, not an entire data source.

SQLScript Code

For cases when CDS views are not sufficient to push down ABAP code to the HANA database, methods to directly program on it have been developed. The HANA database has its own version of SQL, SQLScript, which is considerably closer to a full programming language than ABAP SQL. Database developers that create HANA views are already familiar with this language, but the ABAP language also provides access to it.
Special methods called ABAP-managed database procedures (AMDP) allow the use of SQLScript code. It is written on the application layer but executed on the database layer. One dedicated use of AMDPs is table functions. They fetch and calculate data on the database through SQLScript and provide the result as a temporary table. In contrast to customs entities, all of this happens on the database. It provides more capabilities than CDS and Open SQL and even allows the use of special HANA tools like machine learning libraries. If optimal performance is desired, AMDPs should be preferred over the ABAP code. Of course, it requires learning a new language, which has a lot more depth to it than other SQL languages.

Parallelisierung von Programmen ist typischerweise kein Problem, mit dem sich ABAP-Entwickler häufig beschäftigen müssen. In den meisten Fällen haben Datenbankzugriffe durch OpenSQL einen deutlich größeren Einfluss auf die Performance eines Reports als die Verarbeitung und Ausgabe der Daten. Nichtsdestotrotz gibt es Szenarien, in denen Parallelisierung die Verarbeitungsgeschwindigkeit dramatisch beschleunigen kann. Um die prinzipielle Funktionsweise des Parallelisierungsprozesses zu demonstrieren, habe ich mir die Visualisierung des Mandelbrot-Fraktals ausgesucht. Das Mandelbrot-Fraktal ist wahrscheinlich der bekannteste Vertreter seiner Art und ein hervorragendes Beispiel für einen parallelisierbaren Prozess. Aber zuerst müssen die Grundlagen geklärt sein: Was genau ist Parallelisierung und welche Voraussetzung muss ein Prozess haben, um von Parallelisierung profitieren zu können?

Serielle und parallele Prozesse

Normalerweise werden ABAP-Programme und Reports seriell verarbeitet. Das bedeutet, das Programm wird Zeile für Zeile nacheinander abgearbeitet. Ein typischer Report liest Parameter vom Selektionsbildschirm ein, selektiert entsprechende Daten von der Datenbank, verarbeitet diese und gibt sie aus. Häufig werden Loops genutzt, um die Datenverarbeitung vieler Elemente zu realisieren. Das Programm arbeitet so alle Datenbankeinträge nacheinander ab, wie in der folgenden Grafik zu sehen ist:

Solche Loops sind ein gutes Indiz, dass Verarbeitungsschritte parallelisiert werden können. Die Voraussetzung hierfür ist, dass die Prozessschritte unabhängig voneinander sind, das heißt, ein Durchgang des Loops ändert nicht das Ergebnis eines anderen Durchgangs. Dies kann man zum Beispiel erzwingen, indem man separate Tabellen für die gelesenen Daten der Datenbank und für die Ergebnisse nutzt und dabei eine 1:1 Zuweisung macht. Der Ablauf eines parallelisierten Reports könnte wie folgt aussehen:

Da die im Bild dargestellten Verarbeitungsschritte alle zeitgleich erfolgen, wird die Programmlaufzeit dramatisch kürzer. Parallel ablaufende Programmteile werden auch Threads genannt. Leider lassen sich nicht alle Prozesse gleich gut parallelisieren. Einen Programmablauf zu konzipieren, der sich parallel verarbeiten lässt ist eine Wissenschaft für sich, aber hier sind ein paar Beispiele für besser und schlechter parallelisierbare Prozesse:

ABAP-Threads

Als nächstes stellt sich die Frage, wie man in ABAP-Prozesse parallelisieren kann. Die Programmiersprache an sich stellt keine einfache Syntax zur Verfügung, die parallele Abarbeitung von Programmteilen zu beschreiben. An dieser Stelle kommt das Framework ABAP-Threads ins Spiel. Es ermöglicht eine parallele Verarbeitung über einen Mechanismus, der für jeden Thread einen neuen Dialogprozess im Hintergrund startet. Das bedeutet, dass die maximale Anzahl tatsächlich gleichzeitig ablaufender Threads von der Maximalanzahl von Dialogprozessen des Systems abhängt. Wenn man zu viele Threads startet, kann es auch passieren, dass für andere Benutzer keine Dialogprozesse mehr übrigbleiben. Das sollte man im Hinterkopf behalten. Im Zweifelsfall kann man sich über die Transaktion RZ11 den Parameter rdisp/wp_no_dia ansehen. Dieser enthält die Information über die maximale Anzahl von Dialogprozessen des Systems. Die Threads nutzen immer einen Dialogprozess, auch wenn der Report im Hintergrund als Batchprozess gestartet wurde.

ABAP-Threads lässt sich über ABAP-Git in das System einspielen. Hier ist der Link zum GitHub Repository: ABAP-Threads

Das Programmierkonzept von ABAP-Threads basiert auf sogenannten Workern. Für jeden Thread muss ein Worker-Objekt erzeugt werden. Dieses Objekt ist die Instanz einer Worker-Klasse, in der der parallel auszuführende Programmcode implementiert ist. Die Worker Klasse erbt von der abstrakten Klasse ZCL_THREAD_RUNNER_SLUG und hat die folgenden Kernkomponenten:

• Ein einziges Attribut (Membervariable), in der sowohl alle für die Teilaufgabe erforderlichen Parameter als auch die Ergebnisse gespeichert werden. Es stellt die Daten-Schnittstelle des Workers dar und sollte eine Struktur als Datentyp haben.
• Die Methode CREATE, die die Workerinstanz erzeugt und die Parameter in das Attribut kopiert. (Der Constructor kann aus technischen Gründen nicht genutzt werden)
• Die Methode GET_STATE_REF, welche die Referenz zum Attribut zurückliefert
• Die Methode RUN, welche den parallel auszuführenden Programmcode enthält

Das Attribut der Worker-Klasse stellt die einzige Schnittstelle für den Datenaustausch zwischen dem Hauptprogramm und dem Worker dar. Dadurch wird auch implizit sichergestellt, dass es keine Kommunikation zwischen den Worker-Instanzen geben kann. Diese Einschränkung hilft dabei, typische Fallstricke von paralleler Programmierung, wie beispielsweise Race-Conditions oder Deadlocks, zu umgehen, allerdings bedeutet sie auch, dass die Teilergebnisse der Worker nach der Verarbeitung gegebenenfalls in eine lokale Variable des Hauptprogramms kopiert werden müssen, was etwas Overhead mit sich bringt.

Der Programmablauf für die parallele Verarbeitung mithilfe von ABAP-Threads sieht dann typischerweise so aus wie in der Abbildung dargestellt:

Implementierung am Beispiel des Mandelbrot-Fraktals

Parallelisierungsstrategie

Um einen Prozess parallelisieren zu können, muss man eine Strategie entwickeln, ihn auf viele kleinere Teilprozesse aufzuteilen. Als erstes sollte man sich ansehen, welche Abhängigkeiten es im Prozess gibt. Beispielsweise wäre es nicht möglich, das Nettogehalt vor dem Bruttogehalt zu berechnen, da sich der Wert des Nettogehalts aus dem Bruttowert ergibt. Im Fall des Mandelbrot-Fraktals ist praktisch jeder Pixel des Bildes unabhängig von den anderen, deshalb gibt es viel Spielraum die Arbeit auf nahezu beliebig viele Worker aufzuteilen. In diesem Beispiel wird das Bild horizontal getrennt und auf die Worker aufgeteilt.

Die Bilddaten werden über eine Hilfsklasse erzeugt, welche eine Datei im Bitmap-Format generieren kann. Dabei ist die Farbe jedes Pixels direkt steuerbar und kann im Binärformat oder als HSV (Hue, Saturation, Value) beschrieben werden. Zum Algorithmus zur Darstellung des Mandelbrot-Fraktals gibt es dutzende Quellen im Internet.

Die Worker-Klasse

Als Datentyp des Attributs der Worker-Klasse wurde die Struktur t_data_and_parameters definiert. Sie enthält sowohl die Parameter, welche für die Bildgenerierung notwendig sind, als auch die Bilddaten des horizontalen Ausschnitts des Bildes. Die Definition befindet sich in der public section, da sie auch außerhalb der Klasse gebraucht wird.

Das Attribut selbst sollte dann in der private section definiert werden:

Die Methoden CREATE und GET_STATE_REF werden nach Schema redefiniert und implementiert. In der Redefinition der Methode RUN wird der Algorithmus ausprogrammiert, der anhand der Parameter im Attribut das Teilbild erzeugt und wieder im Attribut speichert. Dabei wird durch die Pixel der Bildzeilen iteriert und die Farbe jedes Pixels über eine Mandelbrot-Helferklasse bestimmt.

Der Report

Nachdem die Worker-Klasse fertig implementiert wurde, kann sie in einem Report genutzt werden. Dafür werden als erstes die Worker-Instanzen über einen Loop erzeugt. Anschließend können sie über die Methode RUN_PARALLEL gestartet werden. Um später den Zugriff zu vereinfachen, werden die Referenzen auf die Worker in einer Tabelle gespeichert. Im Codeausschnitt wird die Worker-Klasse LCL_PARALLEL_RENDERER genannt.

Jetzt muss gewartet werden, bis alle Worker fertig sind. Ein Worker hat seine Arbeit beendet, sobald er seine Methode RUN verlassen hat. Über die Methode IS_READY kann dies überprüft werden.

Anschließend können die Teilergebnisse zu einem Gesamtbild zusammengesetzt werden. Das Ergebnis ist eine vollständige Darstellung des Mandelbrot-Fraktals, das als Bitmap im SAP-GUI angezeigt werden kann:

Performance

Jetzt zum Interessantesten Teil: Wie viel Mehrleistung lässt sich durch die Parallelisierung erreichen? Um das zu beantworten, wurden mehrere Benchmarks auf einem Testsystem durchgeführt. Für jede Threadanzahl wurden 5 Messungen gemacht und der Durchschnitt gebildet. Das System läuft in einer virtuellen Maschine mit 24 V-Cores. Die Anzahl der Dialogprozesse ist auf 8 beschränkt, wobei einer für den Report selbst gebraucht wird.
Die Ergebnisse sind in den folgenden beiden Diagrammen dargestellt. Die Standardabweichung der Messwerte ist hier so vernachlässigbar klein, dass sie in der Darstellung nicht berücksichtigt wird.

Es ist deutlich zu erkennen, dass die Verarbeitungsgeschwindigkeit durch die Parallelisierung steigt. Das Verhältnis von Threadanzahl zu Performancesteigerung ist allerding nicht linear. Das liegt daran, dass die Parallelisierungsstrategie noch Verbesserungspotential hat. Der naive Ansatz, jedem Worker gleich viele Bildzeilen zuzuteilen ist nicht optimal, da der Algorithmus für die Generierung des Bildes rekursiv ist. Bildbereiche, die die schwarzen Pixel beinhalten, haben eine deutlich höhere Berechnungsdauer als der Rest. Der Flaschenhals ist derjenige Worker, der am längsten braucht. Aus diesem Grund steigt auch die Bearbeitungsgeschwindigkeit jenseits von sieben Workern. Auch, wenn immer nur sieben Worker gleichzeitig arbeiten, können die Threads, die bereits mit ihrem Bildausschnitt fertig sind, den nächsten Teil übernehmen. Der Overhead durch die Erstellung der Worker-Instanzen und das Kopieren der Bilddaten ist in diesem Beispiel vernachlässigbar klein.

Fazit

Abschließend kann gesagt werden, dass Parallelisierung mithilfe von ABAP-Threads eine gute Möglichkeit darstellt, die Verarbeitungsgeschwindigkeit von Prozessen erheblich zu steigern. Der Performancegewinn steht und fällt allerdings mit der Parallelisierungsstrategie. Außerdem sollte man Kenntnisse über die Systemhardware und Konfiguration der maximalen Anzahl an Dialogprozessen haben, um Konflikten mit den anderen Benutzern des Systems zu vermeiden.

Die Parallelisierung ist vorrangig für Offlineszenarien sinnvoll, wenn keine Last auf dem System ist. So können beispielsweise Updates oder zeitkritische Prozesse beschleunigt werden, die ansonsten möglicherweise im verfügbaren Zeitraum nicht möglich wären. Im Normalbetrieb eines Produktivsystems kann es allerdings andere Prozesse blockieren und die verfügbare Rechenleistung für andere Nutzer reduzieren, weshalb Parallelisierung hier mit Vorsicht zu genießen ist.

Die j&s-soft startet wie alle erfolgreichen IT-Startups in einer Garage bzw. im Keller eines Privathauses. Dirk Jennerjahn und Christian Schmitt, der eine freiberuflich im Bereich SAP in der ABAP-Entwicklung tätig, der andere im Bereich Java, J2EE, lernen sich kennen. Als die SAP beginnt, Java in die SAP-Welt zu integrieren, beschließen die beiden, ihre Kompetenzen zu bündeln und gründen 2003 die j&s-soft GmbH.
Zuerst noch in den eigenen Projekten mehr als beschäftigt, stellen Dirk Jennerjahn und Christian Schmitt 2005 ihren ersten Mitarbeiter ein. Der Fokus der j&s-soft liegt bereits auf SAP-Projekten im Personal- also HCM-Bereich und die Projekte werden mehr. Zwei Jahre später ziehen die beiden j&s-soft Gründer mit drei Mitarbeitern in ein Büro in Walldorf.

Das Büro befindet sich direkt neben einer der SAP-Kantinen. Beste Lage also für ein junges Unternehmen, das Kontakte knüpfen möchte. Da die j&s-soft bereits von Anfang an auch direkt für die SAP tätig ist, entstehen viele kollegiale Freundschaften. Wenn im j&s-soft Büro freitagnachmittags das legendäre „Bier um vier“ stattfindet, kommen regelmäßig SAP-Kollegen aus den umliegenden Gebäuden vorbei. Manche von ihnen wechseln später zur j&s-soft. In der Zeit in Walldorf entsteht das erste eigene Produkt: j&s Enterprise Documents®.

Trotz der Weltfinanzkrise stellt die j&s-soft 2009 besonders viele neue Mitarbeiter ein. Eine Entscheidung, die sich in den Jahren danach noch auszahlen wird. Denn während viele Unternehmen Mitarbeiter entlassen, kann die j&s-soft mit vollem Einsatz ihre Großkunden versorgen.
Im Jahr 2013 wird eine Mitarbeitergesellschaft gegründet. Das Team ist nun mit 10 Prozent an der Firma beteiligt.

Aus persönlichen Gründen verlässt Geschäftsführer Christian Schmitt 2015 die Firma. Nun alleiniger Geschäftsführer, plant Dirk Jennerjahn die j&s-soft weiter gesund wachsen zu lassen. Projekte und Mitarbeiter werden ständig mehr. Das Büro in Walldorf wird zu eng und entspricht nicht den aktuellen Standards. Dazu kommt, dass die Suche nach neuen Mitarbeitern stärker in den Fokus rückt. Ein attraktives Büro an einem ebenso attraktiven Standort ist die logische Konsequenz. Heidelberg steht als mittelgroße Universitätsstadt mit hoher Lebensqualität bei Uni-Absolventen aus der ganzen Welt hoch im Kurs. Die Wahl fällt auf ein Gebäude in der Bahnstadt, einem neuen Stadtteil Heidelbergs, der Wissenschaft und Wirtschaft zusammenbringt. Das Büro im Sky Angle, einem nach Passivstandards gebauten, modernen Bürogebäude, wurde nach Google-Vorbild mit vielen unterschiedlichen Spaces für die Zusammenarbeit eingerichtet. Ein Ort zum Arbeiten und Wohlfühlen.

Im September 2019 zieht das Team ein. Alle sind begeistert – und dann kommt Covid. Das Büro steht fast leer. Parallel haben sich zuvor bereits Kontakte nach Magdeburg entwickelt. Die j&s-soft sucht schon länger nach einem nördlich gelegenen Standort. Mit seiner Universität, der angenehmen Größe und den bereits bestehenden Kontakten zur Otto-von-Guericke Universität, eröffnet der Standort Magdeburg 2021. Inzwischen ist das Team in der Landeshauptstadt sieben Mitarbeiter:innen stark.

Im Zuge der Internationalisierung findet die nächste Neugründung in Serbien statt: In Novi Sad, europäische Kulturhauptstadt 2022 und der zweitgrößten Stadt des Landes, sind in der j&s-soft Balkan d.o.o. aktuell vier Mitarbeiter:innen dabei, einen Kundenstamm mit serbischen Unternehmen aufzubauen. Die j&s-soft Balkan gehört als Schwesterunternehmen, wie auch die j&s-soft GmbH, zur j&s-soft Group.

Aber auch inhaltlich stellt sich die j&s-soft GmbH breiter auf. 2022 veröffentlicht das Unternehmen die Lösung enmeshed zur sicheren Verschlüsslung digitaler Kommunikationspartner mit App und Wallet als Open Source Angebot. Die Lösung mit großem Mehrwert ist für SAP-Anbindungen interessant, aber auch für alle anderen Systemlandschaften. enmeshed eröffnet der j&s-soft damit einen ganz neuen Kundenkreis, der in der Anfangszeit vor allem aus Akteuren der Bildungslandschaft besteht.

Was ist für die nächsten 20 Jahre geplant? Die j&s-soft GmbH steht für Offenheit gegenüber allen neuen technologischen Entwicklungen, um mit innovativen Lösungen den Bedürfnissen der Gesellschaft und der Märkte gerecht zu werden. Das bedeutet ständige Weiterentwicklung und stetigen Wandel. Was spannend und sinnstiftend für das Team ist, ist ebenso vorteilhaft für die Kunden: Geplant ist, weiter offen, flexibel und mit viel Know-how und Elan den Herausforderungen der Zukunft zu begegnen.

Am 7. Dezember war es wieder so weit: ABAP-Entwickler vom Anfänger bis zum ABAP-High-Sophisticate trafen sich bei der ABAPConf mit Vortragsthemen wie “ABAP Quickfixes for S4/HANA” oder “4 abapGit Use Cases That Will Blow Your Mind” (siehe Programm). Die kostenlose, online stattfindende Veranstaltung deckt in zwei parallelen Streams eine große Bandbreit an ABAP Themen ab und richtet sich in den Sprachen Deutsch und Englisch an ein Internationales Publikum. Alle Sessions sind auf dem youtube channel und über die ABAPConf-Website abrufbar.

Unser Kollege Sören Schlegel veranstaltet das ABAP-Event mit Tobias Hofmann, Dominik Bigl und Johann Fößleitner. Mehr über die Organisatoren und Hintergründe hier.