SAP-Entwicklungsprozesse digitalisieren: Realisierung (Teil 2)
In Teil 1 der Realisierungsphase der Serie „SAP-Entwicklungsprozesse digitalisieren“ habe ich laut über Richtlinien und Code-Qualität nachgedacht. In Teil 2 widme ich mich nun echter „Digitalisierung“: Prozessschritte automatisieren.
Ein großes Vorhaben der Digitalisierung ist neben dem sehr pathetischen Ziel der „Disruption von Märkten“ auch ein hoher Automatisierungsgrad. Je weniger Zeit Menschen nämlich mit Fleißarbeit verbringen, desto mehr Zeit bleibt für wichtige Dinge und desto weniger Fehler aufgrund von Flüchtigkeitsfehlern treten auf. „Alles, was automatisiert werden kann, wird automatisiert werden“ – dieses Zitat ist mittlerweile in aller Munde.
Geschwindigkeit durch Programmiermodelle
Diese Tendenz ist auch in der ABAP-Entwicklung an verschiedenen Stellen erkennbar. SAP hat vor einiger Zeit das erste ABAP-Programmiermodell angekündigt, das sogenannte „ABAP Programming Model for SAP Fiori“. Zum Aufbau an sich möchte ich hier nicht ins Detail gehen. Auf dem ersten Blick sieht es aus wie eine lose Vorgabe von Entwicklungstechnologien, die doch bitte zukünftig genutzt werden sollen. In Wahrheit ist es ein Schritt zur Automatisierung in der ABAP-Entwicklung. Das Programmiermodell baut darauf, aus einem gut durchdachten Datenmodell möglichst viel automatisch generieren zu können: das Business-Objekt, die OData-Services und im Idealfall über Fiori Elements auch gleich die Oberfläche im Stile von SAP Fiori. Auch die Weiterentwicklung in Form des „ABAP RESTful Programming Models“ nutzt viele Automatismen, um die sich der Entwickler nicht mehr zu kümmern braucht. Es ist lediglich eine flexiblere und optimierte Version des vorherigen Modells.
Abbildung 1: Die ABAP-Entwicklungsmodelle der SAP
Automatisierungspotenziale aufdecken und nutzen
Die spannende Frage ist nun: welche automatisierbaren Schritte und Tätigkeiten führen Sie oder Ihre Kollegen in der SAP-Entwicklung regelmäßig durch? Nur zur Erinnerung: Das Ziel ist nicht, jemanden überflüssig zu machen. Stattdessen wollen wir Zeit schaffen und Fehler vermeiden. So können wir mehr in Wichtiges investieren. Ich nenne Ihnen automatisierbare Schritte, die mir sofort in den Kopf schießen. Für einige davon verlinke ich auch gleich Lösungsideen, die wir auch in eigenen Projekten nutzen. Für andere sind es nur Gedankenimpulse:
Übersetzungstool
Alle Texte einer Entwicklung müssen einzeln und in verschiedenen Transaktionen übersetzt werden: SO10, Textelemente/Selektionstexte direkt in der SE80, Datenelemente in der SE11 usw. Dabei vergisst man oft etwas und es geht viel Zeit ins Land. Warum übersetzen Sie nicht alles in einem Schwung, in einer Transaktion? Aus diesem Schmerz heraus haben meine Kollegen ein Übersetzungstool gebaut, das die Arbeit mit Übersetzungen enorm erleichtert. Die logische nächste Überlegung: Über angebundene Dictionaries oder sogar KI die Übersetzungen vorschlagen oder automatisieren lassen! Wir arbeiten dran ;-).
Dokumentationsgenerator
In vielen Unternehmen gibt es die Vorgabe, nach einer Entwicklung auch eine Entwicklungsdokumentation zu erstellen. Die Regel ist dabei oft, die Zusammenarbeit verschiedener Komponenten zu beschreiben und die einzelnen Entwicklungsobjekte zu dokumentieren = aufzulisten. Das betrifft Pakete, Klassen, Reports, Transaktionen bis hin zu DDIC-Objekten wie Strukturen, Datenbanktabellen etc. Haben Sie das schon für eine größere Entwicklung mit 20 Klassen und 50 DDIC-Elementen machen dürfen? Ich schon. Und deshalb war ich begeistert, als die Idee des Dokumentationsgenerators aufkam. Mit dem Generator können Sie automatisch aus einem Transport oder einem Paket eine Vorlage für die Entwicklungsdokumentation erzeugen. Darin werden alle Objekte aus dem System gezogen und mit ihren Kurztexten, Methoden und Attributen bereits eingetragen. Das spart Zeit und Nerven. Bei Ihnen ein Thema? Sprechen Sie uns auf den Dokugenerator an.
DAC-Generator
Bei einem meiner Kunden wurde zu jeder Datenbanktabelle verpflichtend eine sogenannte „Data Access Class“ (kurz DAC) erstellt. Nur über diese Klasse durfte mit der Datenbanktabelle interagiert werden, was das Lesen oder Schreiben von Daten anging. Die DACs sahen dabei von der Struktur her immer gleich aus, lediglich die Datenbanktabelle und deren Attribute unterschieden sich. Da lag es auf der Hand, diese Klassen automatisiert erzeugen zu lassen mit Hilfe eines DAC-Generators. Neue Features aus Kundenprojekten sind in Planung.
Warum viele neue DDIC-Objekte anlegen?
Was mich persönlich ziemlich nervt bei der SAP-Entwicklung? Wenn ich viele neue DDIC-Objekte anlegen muss. Ich brauche fünf neue Strukturen, zum Beispiel für die Arbeit mit REST-Webservices. In jeder Struktur habe ich auch Tabellen. Zu jeder Tabelle brauche ich wieder eine Struktur als Zeilentyp und einen Tabellentyp. Im Worstcase brauche ich für die Strukturfelder eigene Datenelemente und eigene Domänen, um die erlaubten Werte des Webservices technisch abzubilden. Und schon ist ein halber Tag im DDIC für fünf Strukturen draufgegangen. Wäre es nicht fantastisch, wenn ich in einer einzigen Oberfläche oder über einen Upload-Mechanismus eine Struktur mit verschachtelten Strukturen/Tabellen, Datenelementen und Domänen definieren und von dort aus alles automatisiert anlegen könnte? Zugegeben – eine Lösung habe ich dafür noch nicht. Aber wo das Problem jetzt hier beschrieben steht, fällt mir bestimmt zeitnah etwas Gutes dafür ein!
Sicher gibt es noch viele, viele, viele weitere zeit- und nervenraubende Arbeiten, die ABAP-Entwickler regelmäßig durchführen. Was ist es bei Ihnen? Was machen Sie ständig, vielleicht sogar, ohne dass es Ihnen noch auffällt? Ich freue mich über jeden Austausch, sprechen Sie mich gerne an!
Überblick über die Artikel der Serie „SAP-Entwicklungsprozesse digitalisieren“
- Einführung und Motivation
- Anforderungsmanagement
- Konzeption
- Realisierung (Teil 1) – Richtlinien & Code-Qualität
- Realisierung (Teil 2) – Automatisierung
