alphaspirit - Fotolia

Die SAP ABAP-Programmierung muss in die Neuzeit übertragen werden

ABAP-Entwicklerwerkzeuge sind hoffnungslos veraltet. Für Firmen, die auf die SAP ABAP-Entwicklung spezialisiert sind, ist das ein reales Problem.

Die SAP-Programmiersprache ABAP wird oft als rückständig geschmäht. Das ist nur zum Teil gerechtfertigt. Als Programmiersprache hat ABAP in den letzten Jahren ziemlich viele Fortschritte gemacht. Es hat eine funktionale und konsistente Syntax bekommen, leistungsstarke Ergänzungen für Datenbankkonzepte und neue Möglichkeiten für die Definition von HTTP-Webservices.

Ein Teil von ABAP liegt allerdings meilenweit hinter dem aktuellen Stand zurück – und das sind die Entwicklerwerkzeuge. Der Basis-Workflow, dem alle ABAP-Entwickler folgen, ist seit Jahren unverändert geblieben, während der Rest der Entwicklerwelt den üblichen Entwicklungs-Workflow dramatisch überarbeitet und verbessert hat. Diese Stagnation bei der ABAP-Entwicklung stellt für Unternehmen, die sich auf die ABAP-Entwicklung spezialisiert haben, und die wettbewerbsfähig bleiben wollen, ein reales Problem dar.

Wie die SAP ABAP-Programmierung funktioniert

Die ABAP-Entwicklung findet auf einem zentralen, gemeinsamen Entwicklungssystem statt. Der Prozess der Entwicklung gestaltet sich dabei wie folgt: Entwickler melden sich an dem System an und nehmen Änderungen an Entwicklungsobjekten – wie zum Beispiel Klassen und Funktionsbausteine – vor. Sobald Änderungen vorgenommen wurden, können sie gespeichert und aktiviert werden.

Der einzige Weg, um eine Änderung zu testen, ist das Entwicklungsobjekt zu speichern und zu aktivieren – und dann zu sehen, was passiert. Im Endeffekt bedeutet das: Wenn ein Entwickler ein Objekt ändert, wird das Objekt für alle Benutzer des gemeinsamen Entwicklungssystems geändert (siehe Abbildung 1).

Abbildung 1: Der Entwicklungs-Workflow in einer ABAP-Umgebung. Entwickler führen Änderungen seriell aus.

Die Standard SAP-Systemlandschaft besteht aus dem eben erwähnten Entwicklungssystem, einem Testsystem und einem Produktionssystem. Sobald die Änderungen im Entwicklungssystem abgeschlossen sind, werden sie per Transport in das Testsystem geschoben. Ein Transport ist ein Point-in-Time-Snapshot einer Reihe von Entwicklungsobjekten. Die Änderungen werden anschließend im Testsystem weiter getestet – wobei in diesem System keine direkten Änderungen gemacht werden können. Wenn alles gut geht, werden die gleichen Transporte in das Produktionssystem geschoben.

Wie andere Entwicklungsplattformen funktionieren

Die meisten anderen Plattformen verfolgen bei der Entwicklungsarbeit einen anderen Ansatz. Dort gibt es kein zentrales, gemeinsames Entwicklungssystem. Stattdessen ist es in der Regel, aber nicht immer, so, dass ein gemeinsames verteiltes Versions Control System (Versionsverwaltungssystem, VCS) wie Git verwendet wird. Dieses speichert den Quellcode und die Konfigurationsdateien, welche die Anwendung und die Umgebungskonfiguration festlegen und für die Anwendung erforderlich ist.

Wenn ein Entwickler etwas in einer Anwendung ändern möchte, wird er eine Kopie des Quellcodes und die Konfiguration überprüfen, automatisch eine komplette lokale Version der Plattform bauen, auf der die Anwendung ausgeführt werden soll, die Anwendung lokal ausführen und Änderungen lokal ausführen und testen.

Andere Entwickler sind von den Änderungen, die dieser Entwickler macht, nicht betroffen, bis der Entwickler die Änderungen zurück an das zentrale VCS sendet. Selbst dann können andere Entwickler genau auswählen, welche Änderungen sie in ihrer lokalen Version der Anwendung verwenden möchten, oder sogar mehrere verschiedene lokale Versionen der Anwendung mit verschiedenen Gruppen von Änderungen an ihnen verwenden (siehe Abbildung 2).

Abbildung 2: Bei einem VCS-basierten Standard Entwicklungs-Workflow können Entwickler parallel arbeiten.

Diese Praxis, mehrere Versionen einer Anwendung beizubehalten, wird gemeinhin als Branching (Verzweigung) bezeichnet und ist nützlich, wenn parallel an mehreren Funktionen gearbeitet wird oder an Fehlerbehebungen oder Refaktorierungen. Entwickler können solche Verzweigungen vor Ort pflegen, oder Branches zum zentralen VCS senden, so dass mehrere Entwickler an dem gleichen Branch arbeiten können. Nur wenn die Entwickler ihre Änderungen zu einem Branch auf dem zentralen VCS zurücksenden wollen, müssen sie sich vergewissern, dass ihre Änderungen mit denen auf dem zentralen System kompatibel sind.

Die Änderungen an einem Zweig, der zum Testen bereit ist und an die Produktion gesendet wird, wird oft durch einen Tag – also einen frei wählbaren Bezeichner – gekennzeichnet. Dieser Tag wird normalerweise unverändert beibehalten, aber wenn Korrekturen erforderlich sind, kann ein neuer Tag mit einem Fix erstellt werden, der auf jeder beliebigen Version oder einem Branch im VCS basieren kann.

Wie kommt es zu diesen Unterschieden?

Der wesentliche Unterschied zwischen diesen Ansätzen ist folgender:

Im ABAP Entwicklungs-Workflow wirkt sich jede Code-Änderung von jedem Entwickler auf alle anderen Entwickler sofort aus – und es ist schwierig, zu früheren Versionen der Anwendung zurückzukehren. Transporte für Test- und Produktionssysteme basieren ausschließlich auf dem aktuellen Stand des Entwicklungssystems.

Im modernen Standard Entwicklungs-Workflow hat jeder Entwickler die Kontrolle darüber, wann Änderungen von anderen Entwicklern in ihrer Arbeitsumgebung angewendet werden. Damit ist es leicht, zu einer früheren Version der Anwendung zurückzugehen. Tags für die Test- und Produktionssysteme können auf Basis von jeder historischen Version von jedem Branch erstellt werden.

Diese Unterschiede ergeben sich aus den verschlungenen Wegen der ABAP-Welt. Betrachten wir den Fall, in dem zwei SAP ABAP-Programmentwickler jeweils Änderungen an einer Reihe von Klassen machen müssen, die miteinander in Wechselwirkung treten. Für die zwei ABAP-Entwickler ist es schwierig, mit dem gleichen Code zur gleichen Zeit zu arbeiten, so dass der beste Ansatz für einen Entwickler wäre, seine Arbeit erst zu beginnen, wenn der andere fertig ist. Wenn jeder Entwickler für seine Arbeit einen Tag braucht, ist die ganze Arbeit in zwei Tagen erledigt.

Mehr zum Thema SAP-Entwicklung:

Die Entwicklung von SAP Fiori-Apps erfordert ein designzentriertes Denken.

Git, GitHub und Co.: Open-Source-Tools für die SAP-Softwareentwicklung.

IBM SoftLayer Cloud: Test- und Entwicklungsumgebung für SAP HANA.

Mobility Strategie von SAP: Business Apps und Unterstützung bei der Entwicklung.

SAP Solution Manager: kundeneigene Entwicklungen richtig verwalten.

Gibt es allerdings bei der ersten Entwicklerarbeit ein Problem im Testsystem, ist die Arbeit des zweiten Entwicklers bereits vorhanden und Transporte sind nur möglich, basierend auf dem aktuellen Stand des Entwicklungssystems. Jetzt muss die Arbeit des zweiten Entwicklers entfernt und versucht werden, das ursprüngliche Problem zu beheben.

Aus diesem Grund ist es oft eine gute Idee, zu warten, bis die Arbeit des ersten Entwicklers reif für die Produktion ist. Das allerdings kann Wochen dauern, und damit muss der zweite Entwickler auch wochenlang warten, bis er seine Arbeit beginnen kann. Wir haben eigentlich nur zwei Personentage an Arbeit zu erledigen, und wir haben zwei Entwickler, die den Auftrag erledigen. Aber die Arbeit kann im schlimmsten Fall Wochen dauern, bis sie abgeschlossen ist, weil der Prozess der SAP ABAP-Programmentwicklung so mangelhaft ist.

In der Nicht-ABAP-Welt ist das kein Problem: Dort machen die beiden Entwickler ihre Änderungen an den Branches vor Ort und parallel. Sobald ein Entwickler mit seiner Arbeit fertig ist, sendet er sie an das zentrale Versions Control System zurück. Der zweite Entwickler macht das gleiche. Wenn es zu Inkompatibilitäten zwischen der Arbeit des zweiten und der Arbeit des ersten Entwicklers kommt, müssen sie einige Zeit mit der Lösung der Probleme verbringen. Damit dauert die Arbeit, die einen Tag dauern sollte, möglicherweise länger. Aber das ist minimal im Vergleich zu dem erhöhten Zeitaufwand mit der ABAP-Entwicklungsumgebung.

Ein Management-Problem

Der Unterschied zwischen ABAP und anderen Plattformen scheint zunächst nur ein simples Problem der Entwicklerwerkzeuge und der Unterstützung eines funktionsfähigen Versions Control System zu sein. Aber dieses Problem hat viel weitreichendere Folgen. Meiner Meinung nach ist die ABAP-Entwicklung wegen der mangelhaften Unterstützung einer modernen Versionskontrolle von Natur aus weniger parallelisierbar und macht die Entwicklungsarbeiten spröder als auf Plattformen, die Versionskontrollsysteme unterstützen.

Ist es trotzdem möglich, ABAP-Programme relativ effizient und effektiv zu entwickeln? Natürlich ist das möglich. Aber es wäre mit einer besseren Werkzeugunterstützung durch SAP sicher einfacher.

Über den Autor:
Ethan Jewett ist ein unabhängiger Berater und SAP-Mentor. Seine Arbeitsschwerpunkte liegen in den Bereichen Business Intelligence, Information Management und Performance Management. Er entwickelt zudem gemeinsam mit Kunden IT-Tools für das Daten-Management und Performance Management. Weitere Informationen gibt es auf seinem Blog.

Folgen Sie SearchEnterpriseSoftware.de auch auf Twitter, Google+ und Facebook

Artikel wurde zuletzt im November 2016 aktualisiert

Erfahren Sie mehr über Business-Software

- GOOGLE-ANZEIGEN

ComputerWeekly.de

Close