Dieser Leitfaden befindet sich aktuell in der Erstellung durch das Autorenteam und wurde bisher noch keinem Review unterzogen. Daher ist dieser Leitfaden zum aktuellen Zeitpunkt noch nicht vollständig. Es können daher fehlerhafte, lückenhafte oder unvollständige Informationen enthalten sein.

    # DSAG ABAP Leitfaden

Wenn Sie einen Beitrag leisten möchten, besuchen Sie das GitHub Repository: DSAG’s ABAP Leitfaden

Der DSAG ABAP Leitfaden ist ein lebendiges Dokument 👨‍💻 - es lebt von und mit seiner Community 🥳.

{% capture disclaimer %}{% include wip-disclaimer.md %}{% endcapture %} {{ disclaimer | markdownify }}

    <h1 class="no_toc" id="einleitung">Einleitung</h1>

Aufbau und Zielgruppe
Positionierung
Motivation
Disclaimer

Die Software der SAP zeichnet sich als Standardsoftware durch ein hohes Maß an Flexibilität und Erweiterbarkeit aus. In nahezu allen Unternehmen, die SAP-Software einsetzen, finden sich kundenspezifische Anpassungen und Erweiterungen. Die SAP-Software unterliegt damit sowohl auf Hersteller- als auch auf Kundenseite der kontinuierlichen Anpassung und Erweiterung durch sich ändernde Kundenbedürfnisse. Das hohe Maß an Flexibilität und Erweiterbarkeit von SAP-Software bringt Vor- und Nachteile mit sich:

Die Software kann optimal an kundenspezifische Anforderungen angepasst und damit die Wertschöpfung durch den Einsatz deutlich gesteigert werden.
Zeitgleich birgt die Erweiterbarkeit das Risiko kundenspezifischer Entwicklungen, die komplex, aufwendig wartbar und fehleranfällig sind.

Das Dokument erschien bereits in zwei Auflagen, jeweils 2012 und 2016. Hierbei handelt es sich um die dritte Auflage.

Seither hat sich im Bereich der SAP-Entwicklung sehr viel getan, die Einführung von S/4HANA, die ABAP Development Tools, CDS, RAP und die rasante Weiterentwicklung der Programmiersprache ABAP um hier die offensichtlichsten Punkte zu nennen.

Die Anwendungsentwicklung in SAP ist deutlich komplexer geworden und während früher der Großteil der Entwicklung in ABAP und GUI-basierten Tools erfolgte, ist es heute erforderlich verschiedene Technologien und Tools einzusetzen und zu beherrschen.

Es gibt zahlreiche Dokumentationen und mittlerweile sind auch zahlreiche Schulungsangebote in der Form von Learning Journeys frei zu den verschiedenen Themen verfügbar. Dennoch ist es nicht einfach, sich im Dschungel der Tools und Techniken zurechtzufinden.

Daher hat sich auch im Jahr 2024 nach Aufruf der DSAG wieder ein neues Team von Experten im SAP-Umfeld zusammengefunden um eine neue und aktuelle Version eines SAP-Entwicklungsleitfadens bereitzustellen, der sowohl Verantwortlichen in Unternehmen, als auch Entwicklern und Beratern Orientierung, Hinweise und Tipps aus der Praxis zu geben und helfen, bewährte und neue Technologien für die Anwendungsentwicklung erfolgreich und zielgerichtet einzusetzen.

Aufbau und Zielgruppe

Wie das Dokument aufgebaut ist und wie Sie es effektiv nutzen können, erfahren Sie in diesem Abschnitt. Das Dokument unterteilt sich in spezifische Kapitel und Abschnitte:

Am Anfang des Kapitels finden Sie einleitende Informationen und einen Überblick über das Thema. Dieser Teil ist vor allem für Manager und Entscheider im Unternehmen gedacht, die sich einen Überblick über den Bereich machen wollen.
Je Tiefer Sie in das Kapitel einsteigen, desto detailiertere Informationen erhalten Sie. Diese Abschnitte sind vor allem für Architekten und Entwickler geeignet, die einen tieferen Einblick in das Thema erhalten wollen.

Positionierung

Von der SAP und einer ganzen Reihe von Fachverlagen existieren bereits sehr gute Publikationen zur Anwendungsentwicklung und Erweiterung der SAP-Plattform. Im Verlauf dieses Leitfadens weisen wir auf aus unserer Sicht lesenswerte Literatur hin.

Der Mehrwert dieses Dokuments liegt in der Zusammenfassung bewährter Vorgehensweisen, Praxistipps und erprobter Regelwerke aus den Anwenderunternehmen. Diese Guideline soll Ihnen als Anwender, Entwickler, Entwicklungs-, Projekt- oder IT-Leiter Anregungen und Hilfestellung geben, um „das Rad nicht immer wieder neu erfinden zu müssen“ und auf die Erfahrungen anderer aufbauen zu können. Dabei erheben die in dieser Guideline vorgestellten Empfehlungen nicht den Anspruch auf Vollständigkeit oder absolute Gültigkeit, sondern stellen eine Auswahl von Praxistipps dar.

Als Autorenteam haben wir uns darum bemüht, im Spannungsfeld zwischen Überblickswissen und Detailtiefe den richtigen Mix zu finden. Daher verweisen wir an entsprechenden Stellen auf weiterführende Quellen, um bereits ausführlich diskutierte Themen nicht redundant wiederzugeben.

Motivation

Manche der neueren Technologien und Tools sind in der Breite noch nicht vollumfänglich im Einsatz, obwohl diese schon seit Jahren zur Verfügung stehen. Daher ist es dem Autorenteam auch ein Anliegen, anhand von Vorteilen und Möglichkeiten darzustellen, warum es sich lohnt in die neueren und neuen Methoden zu investieren und neue Wege einzuschlagen. Denn müssen für den Einsatz dieser Methoden auch die Rahmenbedingungen im SAP-Entwicklungsumfeld angepasst oder sogar verändert werden. Um die Hemmschwelle abzubauen soll dieser Leitfaden auch den Einstieg erleichtern. Daher behandelt dieser Leitfaden vorrangig die Themen aus einem etwas höheren Blickwinkel, zu Dokumentationen oder weiteren Dokumenten, die Details erläutern wird nach Möglichkeit verwiesen.

Dieser Leitfaden dient nicht als Dokumentation und ist auch keine detaillierte Anleitung zu einzelnen Themen. Mit diesem Leitfaden möchten wir auf Basis von Praxiserfahrungen und gesammeltem Wissen der Autoren den Einstieg in neue Techniken erleichtern, eine Bewertung des Stands der SAP-Entwicklung im Unternehmen ermöglichen und Handlungsfelder aufzeigen, wie eine effiziente und gute SAP-Entwicklung ermöglicht wird.

Disclaimer

Das Dokument entsteht aus dem gesammelten Wissen der DSAG Mitglieder in den verschiedenen Bereichen und wird durch die Community weiterentwickelt. Es kann daher zu Abweichungen zum Standardvorgehen oder Best-Practices von SAP kommen, wenn in einem Unternehmen andere Erfahrungen gemacht wurden.

    <h1 class="no_toc" id="organisation">Organisation</h1>

Einleitung
Bausteine einer effektiven Entwicklungsorganisation
Prozesse und Methodik
Status Quo in gewachsenen Landschaften
Erfahrungsbericht aus der Praxis: Brownfield in S/4HANA
1. Vision
2. Umsetzung
Schlusswort

Einleitung

Wieso sollte das Management in Softwarequalität und eine gut aufgestellte Entwicklungsorganisation investieren? Softwarequalität als Basis wird in der Regel implizit von Stakeholdern automatisch erwartet, dafür notwendige Maßnahmen aber oft wenig unterstützt, denn „Es liegt kein Ruhm in Prävention“.

Aus Managementsicht ist ein solcher Invest (Zeit, Ressourcen, Tooling) mit einem Business Case zu hinterlegen, der sich am einfachsten für ihr Unternehmen individuell erarbeiten lässt, wenn Sie einen Blick auf die aktuellen Probleme ihres Unternehmens und ihrer IT werfen. Falls sie einige dieser bei sich wiederfinden, kann eine Optimierung ihrer Entwicklungsabteilung und Kultur mit Fokus auf Qualität und Technologien ein Lösungsansatz sein:

(zu) langsame Umsetzung von Innovationen und gesetzlichen Anforderungen im Vergleich zu ihren Konkurrenten
Unzufriedene Endkunden aufgrund von IT-Themen, Fehlern, Prozessen oder nicht eingehaltene SLAs etc.
Fehlerhafte Prozesse und Daten in ihren Systemen mit entsprechenden Aufwänden für Korrekturen
Dauerhafte Überlastung der IT-Abteilung, Tendenz zu Burnout, Personalfluktuation, Wissenssilos, Wissensverlust
Schwierige Kooperation zwischen Fachabteilungen und IT
Implementierungen erfüllen nicht die fachlichen Anforderungen der Fachbereiche
Lange Projektlaufzeiten und Feedbackprozesse, hoher Bedarf an Nacharbeit
Historisch gewachsene komplexe Systemkonstellationen und Code-Basen

Die Lösungen dieser Probleme sind in der Regel in zwei Kategorien einzuteilen, für die dieser DSAG Leitfaden sowie weitere Leitfäden mögliche Lösungsoptionen aufzeigen:

Kulturell-Organisatorisch: Querschnittliche Teams, Auflösung von Silos, klare Rollenverteilungen und Verantwortlichkeiten, Vertrauen, Kommunikationsstrukturen, gemeinsames Ziel und Vision, Förderung von Kooperation statt Konkurrenz etc.
Software-Qualität: Automatisierung, professionelles Testen, Entwicklungsrichtlinien, Software-Architekturmanagement, Enterprise Architecture Management (EAM), gezielte Trainings, Pair-Programming, Code Reviews, Community of Practice etc.

Teile dieser Lösungen können für sie als Unternehmen Quick Wins sein oder sich mit kleinen Keimzellen evaluieren und nachhaltig gestalten. Es lohnt sich hierbei einen Blick darauf zu werfen, was seit viele Jahren außerhalb der SAP-Welt im Bereich Software-Engineering betrieben wird und dies zu adaptieren. Einen Ausblick hierzu gibt ihnen das folgende Kapitel.

Bausteine einer effektiven Entwicklungsorganisation

Die Transformation zu einem erfolgreichen S/4HANA Technologie-Team stellt aus Unternehmenssicht eine komplexe und oft unterschätzte Herausforderung dar. Abhängig vom Reifegrad und der Ausrichtung ihrer IT Organisation, ist für das Erreichen des strategischen Zielbilds eine Anpassung von kulturellen und organisatorischen Stellschrauben notwendig.

Je größer der Anteil an kundenindividueller Anpassung und Erweiterung ihrer vorhandenen SAP Software ist bzw. strategisch werden soll Kapitel Clean Core, desto wichtiger ist der unternehmerischer Fokus auf die Effizienz und Effektivität ihrer Entwicklungsorganisation. Der nachfolgende Auszug streift die aus unserer Sicht wichtigsten Themenfelder, die sie auf dem Weg zu einer erfolgreichen Entwicklungsorganisation unterstützen werden.

Definition der passenden Aufbau- und Ablauforganisation

Die Ausrichtung ihrer Entwicklungsorganisation ist von der Menge, Komplexität und Häufigkeit an Kundenanpassungen in ihren SAP Systemen abhängig (Make-or-Buy bzw. „Do nothing“ Entscheidung). Gehören Sie zu den Kunden, die SAP Software im Rahmen einer Standard-Software ohne größere Anpassungen nutzen können, lohnt sich die Investition in eine eigene SAP Entwicklungsabteilung aus wirtschaftlicher Sicht in der Regel nicht. Für den Fall empfiehlt es sich, auf externe Spezialisten mit entsprechender Kernkompetenz und Reputation zurückzugreifen und die geringe Menge von Kundenanpassungen im SAP System unter dem Schirm von definierten Dokumentationsrichtlinien (Änderungsdokumentation, Betriebshandbücher, etc.) und klar definierter Service Level / KPIs abzuwickeln. Die genaue Ausprägung der Entscheidung ist vom individuellen Einzelfall in Ihrem Unternehmen abhängig und kann von geringfügigen Änderungen, bis hin zu einem kompletten Plattformbetrieb durch ein eigenes Team oder einen externen Service Partner variieren.

Besteht die Notwendigkeit Ihre SAP-Systeme auf Grund von fehlender Funktionalität in Ihren Kerngeschäftsprozessen, bzw. der notwendigen Integration von Alleinstellungsmerkmalen, die Ihnen zu Wettbewerbsvorteilen verhelfen mittels Kundenindividualentwicklung häufig anzupassen, lohnt sich die Investitionsprüfung in eine eigene SAP Entwicklungsorganisation. Der Aufbau einer erfolgreichen Entwicklungsorganisation ist ein komplexes Vorhaben und muss neben den technologischen Themen besonders auf sozioökonomische Aspekte Rücksicht nehmen. Nutzen Sie die nachfolgenden Punkte, um die Stellschrauben in Ihrem Unternehmen auf Ihre Bedürfnisse anzupassen.

Teamorganisation und Teamzusammensetzung

Softwareentwicklungs-Teams sind das Schlüsselelement für die erfolgreiche Umsetzung und Implementierung Ihrer Entwicklungsvorhaben. Hier spielt die Musik, wenn es darum geht, die fachlichen Anforderungen in Technologie zu gießen und die Lösung über Jahrzehnte hinweg kostengünstig und wartbar zu halten. Damit das Team dieser Anforderung gerecht werden kann, muss es mit entsprechenden Kompetenzen, Mitteln und Prozessen ausgestattet und unterstützt werden. Wenn Sie z.B. feststellen, dass Ihre Teams erhebliche Zeit und Energie darauf verwenden, sich gegen Schuldzuweisungen anderer Teams abzusichern, oder dass es zu langen Wartezeiten zwischen den einzelnen Schritten in ihrem Softwareentwicklungsprozess kommt, könnte dies ein Hinweis auf einen suboptimalen Teamschnitt sein, der dringend optimiert werden sollte. Beigefügte finden sie einige Handlungsempfehlungen um Probleme bei der Teamorganisation zu vermeiden.

Die richtige Teamzusammensetzung ist essentiell für die effektive Bewältigung der an das Team herangetragenen Aufgaben. Hierbei spielen die Teamgröße, kultureller Hintergrund, fachliche und technische Kompetenz und die Hilfsmittelausstattung eine wesentliche Rolle. Achten Sie darauf, dass das Team alle Tätigkeiten zur Aufgabenerfüllung und Ergebnislieferung nach Möglichkeit eigenständig durchführen kann und Abhängigkeiten zu vor- bzw. nachgelagerten Prozessen so gering wie möglich sind.
Berücksichtigen Sie bei der Teamzusammenstellung die fachliche und technische Komplexität. Gerade im SAP Umfeld stellt die Komplexitätsbewältigung in den unterschiedlichen Anwendungsbereichen oft eine Herausforderung dar. Neben dem fachlichen Kontext muss sich das Team zusätzlich mit anwendungsspezifischen Frameworks, kundenseitigem Bestandscode, Technologietrends und unterschiedlichen Technologie Stacks auseinandersetzen. Achten Sie darauf, dass das Team nicht in zu viel unterschiedlichen Aufgabenbereichen arbeitet und stattdessen Fokus auf einen beherrschbaren Bereich, wie z.B. auf ein fachliches Modul, setzen kann. Nehmen Sie Ihr Team ernst, wenn es über eine zu hohe Komplexitätsbewältigung klagt. Anderenfalls riskieren Sie durch zu häufigen Kontextwechsel und kognitive Überforderung des Teams langfristige Gesundheitsschäden und negative Produktivität.
Achten Sie besonders darauf, dass sich die Entwickler auf ihre Kernkompetenz, das Designen und Erstellen von qualitativ angemessener Software, konzentrieren können und sich nicht zusätzlich um Themen wie Anforderungsmanagement oder Prozessdokumentationen kümmern müssen. Eine Ausnahme bildet hier die zeitlich begrenzte Durchführung dieser Aktivitäten, um die fachliche Problemdomäne präziser zu erfassen und die zugrunde liegenden Konzepte besser zu verstehen. In der Regel führt ein vertieftes Verständnis der Problemdomäne zu einem effizienteren Softwaredesign und bildet somit einen Mehrwert für den Entwickler.
Stellen Sie Ihren Softwareentwicklungsteams den angemessenen Freiraum für Experimente, Weiterbildung und zur Produktoptimierung bereit. Vermeiden Sie es Ihre Entwickler dauerhaft mit einer 100% Auslastung zu verheizen. Ermöglichen Sie den Entwicklern, durch Maßnahmen wie die Einrichtung einer Community of Practice, voneinander zu lernen. Experimentieren Sie z.B. mit Pair-Programming und profitieren Sie von den damit verbundenen Vorteilen, wie einer potentiell höheren Code Qualität und besserem Software Design.
Geben sie den Teams die Mittel und Tools in die Hand, um Transparenz über ihr Arbeitsgebiet zu erlangen. Eine effektive Optimierung lässt sich nur auf Grundlage von Zahlen, Daten und Fakten siehe Kapitel ALM durchführen. Sind die Informationen über Custom Code und Prozess-Metriken nicht vorhanden, ist eine betriebswirtschaftlich sinnvolle Entscheidung über eine lohnenswerte Investition in ein Optimierungsprojekt nahezu unmöglich.

Weiterführende Internetquellen und Literaturempfehlung

Artikel & Blogposts

Inverse Conway Maneuver – ThoughtWorks

Webseiten & Ressourcen

Bücher

Lean Software Development – An Agile Toolkit
Pearson Verlag

Definition der passenden Custom Code Strategie

Eine klar definierte Custom-Code-Strategie unterstützt Sie bei der transparenten Kommunikation ihrer technologiebasierten Investitionen. Anhand der definierten Strategie lassen sich gezielt Investitionsentscheidungen wie z.B. in Personalplanung- und Fortbildungsmaßnahmen, sowie in In- oder Outsourcing Aktivitäten treffen und der konkrete Umgang mit Entwicklungsaktivitäten festlegen.

Erstellen Sie ein Technologieradar und nutzen Sie es um den Auswahlprozess für bestimmten Technologien und Werkzeuge zu vereinheitlichen. Legen Sie über das Radar fest, in welche Technologien sie strategisch investieren möchten, welche lediglich gewartet, aber nicht weiterentwickelt werden, und aus welchen Technologien ein geplanter Rückzug erfolgen soll. Konzentrieren Sie sich auf eine überschaubare Auswahl an Schlüsseltechnologien, um die Handhabbarkeit (Wartungszyklen, Lifecycle-Management-Tools, interne Expertise etc.) sicherzustellen und die damit verbundene Komplexität nachhaltig zu steuern. Beispiel: SAP Tech Radar
Identifizieren Sie die kritischen Geschäftsfelder, die ihrem Unternehmen einen Wettbewerbsvorteil verschaffen, oder von existentieller Bedeutung sind, und richten Sie den Schwerpunkt ihrer Technologie-, Personal- und Software-Entwicklungsstrategie darauf hin aus. Beispielsweise ist es sinnvoll als Spezialist für die Materialanarbeitung, das Wissen über die kundeneigene Erweiterung in der Variantenkonfiguration auf ein internes Entwicklungsteam zu verteilen, als im kritischen Bedarfsfall von einem externen Dienstleister abhängig zu sein. Konzepte wie das Core Domain Pattern (Domain Driven Design), oder Praktiken aus der Disziplin des Enterprise Architecture Managements können Sie bei Ihren Entscheidungen unterstützen.
Nutzen Sie bei der Entscheidung über die Erstellung von Individualentwicklungen das Vermeidungsprinzip:
1. Bevor Sie die Entwicklung einer neuen Funktionalität beginnen, prüfen Sie, ob sich ihre Anforderung durch einen bestehenden Workaround lösen lässt.
2. Ist das nicht der Fall, oder verursacht der Workaround zu hohe Kosten, prüfen Sie, ob eine Standardlösung von einem Drittanbieter ihre Anforderung erfüllt und profitieren Sie davon, dass sich der Anbieter um die Wartung und Weiterentwicklung (idealerweise außerhalb ihrer Systemlandschaft) kümmert.
3. Erst nach Prüfung der oben genannten Optionen sollten Sie eine Individualentwicklung in Betracht ziehen. Beachten Sie dabei, dass jede zusätzliche Codezeile in ihrem Namensraum laufende Unterstützung erfordert: Neben der initialen Entwicklung ihrer neuen Lösung muss diese langfristig von ihren Mitarbeitern gelesen, debuggt und gewartet werden, was zusätzliche Ressourcen und Kosten bedeutet.
Folgen Sie offiziellen Coding Standards wie den SAP ABAP Programmierrichtlinien, SAP Code Style Guides und natürlich den Empfehlungen aus dem aktuell vorliegenden Dokument. Sorgen sie dafür, dass die Überprüfung der Regeln nach Möglichkeit automatisch erfolgt, die Entwickler Werkzeuge mit kurzen Feedback-Zyklen und Korrekturvorschlägen verwenden und neben der automatischen Regelüberprüfung auch ein manuelles Code Review stattfindet.
Definieren sie konkrete Entwicklungstypen und legen sie Entwicklungstyp-spezifische Qualitätsstandards und Vorgehensweisen fest. Beispielsweise ist ein einmalig auszuführendes Korrekturprogramm kurzfristig und zweckgebunden, wodurch Effizienz, Zeitersparnis und geringe Kosten im Fokus stehen. Eine Developer-On-Stack-Applikation für kundenindividuelle Anarbeitungsprozesse hingegen erfordert höhere Qualitätsstandards, da sie langfristig genutzt, regelmäßig erweitert und gewartet wird. Hier sind Wartbarkeit, Skalierbarkeit sowie die Minimierung langfristiger Kosten entscheidend. Die unterschiedlichen Standards helfen den Entwicklern dabei, sich auf die Kernaufgabe zu konzentrieren und ihre begrenzte Zeit effektiv einzusetzen. Zusätzlich empfehlen wir als Leitlinie einen abstrakten Makro-Qualitätsstandard zu definieren, auf dessen Grundlage sich die Entwicklungstyp spezifischen Szenarien ableiten lassen.
Siehe Beispiel „Was ist guter ABAP-Code?“
Regeln Sie die Zuordnung der Code Ownership auf Team-Ebene. Zwei Rollen sind bei der Code Ownership ausschlaggebend: Auf der fachlichen Seite steht der Product Owner, der für die Priorisierung von Änderungen verantwortlich ist und Aussagen über den Lebenszyklus und die Angemessenheit der technischen Qualität für die Kundenentwicklung treffen kann. Dieser wird auf der technischen Seite von einem Architekten / Lead-Developer, der die Verantwortung für die konzeptionelle Integrität technischer Konzepte und das Kommunizieren von notwendigen Aufräumarbeiten in der zu verantwortenden Softwarearchitektur übernimmt, ergänzt. Als Hilfsmittel für die klare Zuordnung der technischen Artefakte zu einer Rolle steht ihnen das Paket- und Softwarekomponentenkonzept zur Verfügung.
Erlangen Sie das Mandat für die kontinuierliche Verbesserung ihrer Kundenindividualsoftware. Gewährleisten sie, dass sich ihre Entwickler mit der Strukturoptimierung zur besseren Wartbarkeit mittels Refactorings, oder mit dem Tidy First Ansatz, auseinandersetzen können. Achten Sie dabei auf ein ausgewogenes Verhältnis zwischen funktionalen Erweiterungen und struktureller Optimierung. Überzeugen Sie die Stakeholder mit Zahlen, Daten und Fakten aus dem Application Lifecycle und Custom Code Management und zeigen Sie die Kausalzusammenhänge auf, warum es Sinn macht, in die Code Qualität zu investieren.

Der erste Entwurf einer Softwarelösung ist selten von langlebigen Bestand. In Unternehmen mit einem hohen Reifegrad in der Softwareentwicklung basiert die erste Auslieferung oft auf einer bewusst getroffenen Entscheidung, in kurzer Zeit mit einem reduzierten Funktionsumfang und geringer Softwarequalität live zu gehen, um strategische, marktorientierte oder operationelle Ziele zu erreichen (s. Lean Startup / MVP). Nach der Zielerreichung konzentrieren sich die Unternehmen in der Regel darauf, die Softwarequalität auf ein angemessenes Level zu bringen, um die negative Auswirkungen auf die Benutzererfahrung und die langfristige Stabilität des Produkts zu minimieren. Gegebenenfalls wird die erste Auslieferung komplett verworfen und von Grund auf mit der gesammelten Erfahrung neu und in, von Beginn an, angemessener Qualität entwickelt.

Unternehmen mit einem geringen Reifegrad in der Softwareentwicklung fahren oft einen ähnlichen Ansatz, mit dem fatalen Unterschied, dass sie ihre Entscheidung zur Aufnahme von technischen Schulden unbewusst treffen und über kurz oder lang im sogenannten C.R.A.P. Cycle landen. Häufig wird das Problem durch fehlendes Knowhow im Umgang mit langlebiger Softwarearchitektur verstärkt und durch einen rein auf Funktionserweiterung ausgerichteten Change Prozess unter hohem Zeitdruck und geringer Investitionsbereitschaft ad absurdum geführt. Vermeiden Sie diesen Fehler für ein ERP System mit einem Lebenszyklus von 10 - 20 Jahren unbedingt!

Stellen sie klare Regeln für den Umgang mit dem Versionskontrollsystem auf. Definieren sie, wie lange ein Transport im Entwicklungssystem verweilen darf, bis die Entwicklung zurückgebaut werden muss und richten Sie dafür ein entsprechendes Monitoring ein. Legen Sie für Systemlandschaften mit mehreren Produktiv-Systemen und einem zentralen Entwicklungssystem fest, dass der Quellcode in allen Produktivsystemen identisch seien muss. Definieren Sie, wie mit Quellcode umgegangen werden soll, der über mehrere Systemlandschaften hinweg genutzt wird, wie die Abwärtskompatibilität zu unterschiedlichen Release-Ständen gewährleistet wird und wie man mit Namespaces und Forks umgehen soll.

Weiterführende Internetquellen und Literaturempfehlung

Webseiten & Ressourcen

Prozesse und Methodik

Wenn Sie eine Entwicklungsabteilung haben, dann sollten Sie auch in Prozesse und Methodik investieren.
Neben kulturellen und technologischen Themen, ist ein wichtiger Aspekt das Vorgehen der Organisation vom Punkt der Idee bzw. Anforderung bis hin zum go live der entsprechenden Lösung. Das „WIE“, d.h. der gelebte Entwicklungsprozess, ist im Markt vielfältig und stark geprägt von Größe der Organisation, Branche, gesetzliche Rahmenbedingungen durch einen Regulator, zentrale Vorgaben von Muttergesellschaften und KnowHow.

Eine allgemeingültige Empfehlung lässt sich daher nicht geben, wir möchten allerdings einige Punkte aus unseren Erfahrungen teilen, die eine Einordnung für ein individuelles Vorgehen ermöglichen:

Viele Organisationen machen seit Jahren klassisches Projektmanagement mit klar definierten Rollen, Konzepten, Artefakten. Eine Änderung dieser Vorgehensmodelle an sich ist ein großes Change Projekt, dass viel Nachdenken, Zeit und Know-How bedarf. Konsistent und über Jahre hinweg.
Oft ist ein Vorschlag, „agiler zu werden“. Letztendlich sind Stakeholder oft unzufrieden mit der Innovationskraft oder Umsetzungsgeschwindigkeit von Anforderungen und sehen agile Methoden als geeignetes Instrument. Teils kommen diese Vorschläge auch aus der Entwicklungsorganisation selbst, da Mitarbeitende dort mit dem aktuellen Abläufen unzufrieden sind.
Vorgehensmodelle, Methoden, Prozesse und Strategien sind kontextabhängig – nicht jede Organisation, jedes Team oder jedes Projekt ist für jedes Modell sinnvoll. Daher bietet sich es an, nicht zu starten mit dem Statement „Wir sind jetzt agil!“ oder „Wir machen jetzt Scrum!“, sondern zu prüfen, wo Herausforderungen und Probleme sind, wo man als Unternehmen besser werden möchte, wie KnowHow und Ressourcen verteilt sind – und auf dieser Basis mit dem Problem zu starten und nicht mit einer potentiellen Lösung. Beziehen Sie die Menschen mit ein, die die wertschöpfende Arbeit machen und die Probleme lösen müssen.
In Unternehmen gibt es teils gescheiterte Implementierung von „agile“, so dass dieses Wort einen negativen Beigeschmack hat. Die Ursachen hierfür sind mannigfaltig und multifaktoriell: zu wenig Coaching, zu viel Load in Kombination mit einem komplexen Projekt, zu wenig Ausbildung, schlechtes Tooling, kein Grund oder Wille zum Change, Big Bangs etc. Wenn sie agile Methoden nutzen möchten, müssen sie diesen Kontext bzw. die Historie ihres Unternehmens und Mitarbeitenden beachten.
Die erwünschten Ergebnisse eines Weg hin zur Agilität, lässt sich nicht isoliert erzielen: Es nutzt wenig, wenn eine Entwicklungsabteilung agil arbeitet, aber vor- und nachgelagerte Teams und Prozesse weiter wie zuvor arbeiten. Wenn beispielsweise ein Change Advisory Board zur Freigabe von Entwicklungen nur alle 2 Monate tagt, kann die Entwicklungsabteilung nicht flexibler sein, als diese gegebene Rahmenbedingung es ermöglicht.
Eine Hoffnung, die an agile Methoden geknüpft ist, ist dass sie schneller Ergebnisse liefern. Dies ist nicht zwangsweise der Fall: Agile Methoden zielen auf Flexibilität, d.h. sich ändernde Anforderungen und Priorisierungen ab sowie auf schnelles Feedback – das Wissen, das Richtige umzusetzen, da Anforderungen oft nicht vorab ausreichend ermittelbar sind. Damit werden drei zentrale Probleme adressiert: Der stetige Wandel, Ungewissheit und Kommunikation.
Methoden bedürfen eine technische Basis und Unterstützung – wenn heute noch aufwendige manuelle Prozesse existieren, sollten sie diese optimieren.
Es existieren viele Strategien und Methoden, die sich in ihrem Ansatz, ihren Ideen und ihrem Freiheitsgrad unterscheiden. Auszugsweise sind dies beispielsweise:
Auf Team-Ebene: Scrum, Kanban, Extreme Programming, Scrumban
Teamübergreifend / organisationsweit: LeSS, Nexus, SAFe, Scaled Kanban

Darüber hinaus ist „agile“ definiert durch Werte und Prinzipien, so dass kein Framework notwendig ist, sondern jede Organisation sich an daran ausgerichtet einen eigenen Prozess erschaffen kann.

Innerhalb dieser gibt es zusätzlich verschiedene Level und Reifegrade, an denen entlang sich eine Organisation entwickeln kann. Das Kanban Maturity Modell ist hierfür ein Beispiel

Welche Änderung auch immer für ihr Unternehmen gut ist – bedenken sie, dass es letztendlich und Menschen und Kommunikation geht. Versuchen sie ein gemeinsames Ziel, einen „Unity of Puprose“ zu schaffen, an dem sie ihr Vorgehen messen können und Konflikte auflösen können. Ansonsten besteht die Gefahr, dass ihre Initiative unter verschiedenen Richtungen („weniger Regeln und Struktur“ vs „mehr Vorgaben“) oder Interessen (z.B. Gegenläufigen Jahreszielen von Führungskräften) zerrieben wird. Oft gibt es auch die Aufstellung, dass ein agiles Team dennoch einen Projektmanager oder Projektleiter hat und somit hybride entstehen. Hier empfiehlt es sich im Kontext der Organisation zu prüfen, ob ein Wechsel „from projects to products“ hilfreich sein kann.

Status Quo in gewachsenen Landschaften

Aus unserer Erfahrung im DSAG-Netzwerk wissen wir: Die Qualität der Softwareentwicklung hängt stark von der Kompetenz und Motivation der Entwicklungsteams und den Bedingungen innerhalb des Unternehmens ab. Oft fehlt dem Management das technische Verständnis. Vorgaben von außen oder oben wirken selten motivierend. Die Folge: mangelhafte Umsetzung von Qualitätsmaßnahmen oder deren bewusste Umgehung. Kurzfristige Anreize, wie z.B. der Einsatz von Gamification-Elementen oder ein direktes Coaching mit Experten können helfen, aber langfristige organisatorische Veränderungen sind notwendig, um Entwickler zu motivieren, hohe Qualitäts- und Entwicklungsstandards zu setzen. Oft beginnt dieser Prozess damit ein Bewusstsein zu schaffen, dass hohe Softwarequalität und deren positive Effekte nicht ein implizit oder explizit existierender Anspruch von verschiedenen Stakeholdern ist, sondern vor allem auch den Entwicklern selbst hilft.

Best Practice

Es gibt eine breite Möglichkeit von Entwicklungsstandards, die beispielsweise im ABAP Leitfaden 2016 dsag_handlungsempfehlung_abap_2016_0.pdf, Clean ABAP sowie diversen Büchern zu entnehmen sind. Aus unserer Sicht sind grobe Pfeiler zu denen ein Konsens besteht:

Empfehlungen

Namenskonventionen für die kundeneigene Entwicklungen, optional im separaten Namensraum

Strukturiertes Paketkonzeptes, optional mit klaren Paketschnittstellen

Statische Codeprüfung (z.B. ATC Checks) als Teil des Transportwesens mit der Prüfung nach den folgenden Code-Kriterien: Performance, Sicherheit, Compliance, Robustheit, Wartbarkeit, Erweiterbarkeit (ABAP Cloud). Siehe hierzu auch den DSAG ATC Leitfaden dsag_leitfaden_atc_2020_06.pdf

Dokumentation von öffentlichen Methoden/Funktionsbausteinen

Dokumentation von angemessener Dokumentation .

Der Einsatz von ABAP Unit und Code Coverage

Genehmigungsverfahren für Classical Extensibility – der Erweiterungs-Programmierung, welche nicht ABAP Cloud konform ist.

Anpassung der Geschäftsprozess- und technischen Dokumentation nach einer Programmänderung

Warum sollte sich etwas ändern?

Die SAP-Entwicklungskultur bei Bestandskunden ist oft gewachsen und heterogen. Es gibt viele Implementierungen mit verschiedenen ABAP-Varianten und Entwicklerpräferenzen. Im Gegensatz dazu basieren die neuen S/4 HANA-Technologien wie On-Stack Extensibility auf objektorientiertem ABAP, Modern ABAP (Syntax 7.4+), ABAP Unit, CDS Views und dem RESTful Application Programming Model. Diese neueren Teile der ABAP-Sprache müssen in einem S/4 HANA-System verwendet werden, um Standardanwendungen, Fiori-Apps und Standard-Services nutzen zu können.

Moderne ABAP-Entwicklung erfordert Entwicklungsrichtlinien als gemeinsame Basis. Die “Technologie-Stacks” werden immer umfangreicher und ein Entwickler kann nicht alle Technologien in der Tiefe beherrschen. Richtlinien allein reichen aber nicht aus.

Erst durch organisatorische Änderungen, wie z.B. eine Development Factory, Community Of Practice oder ein interdisziplinäres Team, beginnt der eigentliche Veränderungsprozess. Wenn Sie eine Clean-Core-Strategie verfolgen, dann ist es umso wichtiger, das Sie das Change Management richtig angehen. Eine Umschulung bestehender Entwickler wird nicht ausreichen um Veränderung zu leben.

Der nächste Schritt

Ohne Schlüsselpersonen, die Qualität vorantreiben, neigen Teams unter dem andauernden Druck von Projektarbeit und Fachbereich dazu, Funktionalität über Qualität zu stellen. Kontrolle und Qualitätsprüfungen sind auch für externe Mitwirkende entscheidend. Die Initiative benötigt engagierte Hauptentwickler, die intrinsisch motiviert sind, Veränderungen über Jahre hinweg zu unterstützen und zu managen (= Change Management).

Es muss eine klare Vision, Strategie und definierte Ziele geben, die vom Management unterstützt werden, oder am besten explizit von der Geschäftsleitung gefordert werden. Die strikte Trennung von SAP-Standardcode und Eigenentwicklungen - die sogenannte Clean-Core-Strategie - wird verfolgt, um das System langfristig wartbar, erweiterbar und entwicklungsfähig zu halten siehe Kapitel Clean Core. Wir konzentrieren uns daher auf die Vision und die Umsetzung der Strategie.

Erfahrungsbericht aus der Praxis: Brownfield in S/4HANA

Das nachfolgende Beispiel soll die Umsetzung der Clean Core Strategie anhand eines SAP-Kunden im gewachsenen Brownfield aufzeigen. Hier wurde der Bottom-Up Ansatz im Change Management gewählt; Die globalen Entwicklerteams definieren durch Repräsentanten in einem Clean-Core-Governance Gremium, die Entwicklungslandschaft und die Richtlinien in der SAP Entwicklung.

Vision

Wir wollen die ABAP Cloud-Technologien und den SAP-Standard effektiv nutzen. Wir setzen Custom Code richtig, sauber und gezielt ein um Wettwerbevorteile zu erhalten. Dadurch reduzieren wir die Fehler und den Wartungsaufwands um 90%!

Umsetzung

Jahr 1: „Strategie finden“

Definition einer Clean-Core-Strategie, unter Abwägung diverser SAP und Non-SAP Software
Aufbau einer Community of Practice: Senior ABAP Coaches
Aktivierung der ersten ATC-Checks (z.B. Fokus Security, HANA Readiness) auf Basis der “Low hanging fruits”
Schulung der ABAP-Entwickler, wo benötigt.
Einführung eines Paketkonzepts mit Benennung von Verantwortlichkeiten für alle Pakethierarchien.

Jahr 2 „Strategie umsetzen“

Eine gestaffelte Einführung der Clean-Core-Entwicklung
Definition und Implementierung von Rollen für das Change Management: Lead Developer (nach SAFe: Product Architect), Verantwortlich für: Richtlinien im Team vermitteln, Code Reviews siehe Kapitel ALM, Pair-Programming, ATC Checks - Code Findings für Ihre Team-Pakete verteilen, ABAP Unit in die Entwicklungslandschaft bringen.
Beschaffung von Werkzeugen für die Qualitätssicherung
Einführung von Code Reviews und statischen Code Checks als obligatorische Elemente des Entwicklungsprozesses
Weitere Schulung aller ABAP-Entwickler, teilweise durch Train-the-Trainer

Schlusswort

Die effektive Ausrichtung der SAP-Entwicklungsteams an den Unternehmenszielen sowie der organisatorischen Struktur ist eine anspruchsvolle Aufgabe, die aufgrund ihrer Komplexität eine erhebliche Herausforderung darstellen kann. Wir glauben, dass in einer hochgradig maschinellen und technologieorientierten Welt der Faktor Mensch weiterhin eine wesentliche Rolle spielt. Für die sich die Investition in ein sozioökonomisches System mit gut ausgebildeten und intrinsisch motivierten Mitarbeitern lohnt. Die Zeiten der Chuck-Norris-Entwickler und Cowboy-Coder sollten endlich der Vergangenheit angehören und durch professionelle Teams, deren Mitglieder voneinander lernen können, ersetzt worden sein. Wir hoffen, dass wir ihnen mit den Inhalten dieses Leitfadens hilfreiche Ideen und genug Argumentationsmaterial an die Hand geben konnten, mit denen Sie die Herausforderungen in Ihrem aktuellen Arbeitsumfeld lösungsorientiert angehen können.

Denken Sie daran: Ein System ist nur so gut wie das schwächste Glied in seiner Kette. Die lokal begrenzten Optimierungsmaßnahmen in Ihrem Entwicklungsteam lindern vielleicht nur Symptome und einen kleinen, aber wesentlichen Teil in ihrem Softwareentwicklungsprozess. Schauen sie über Ihre Team-Grenzen hinweg und suchen Sie den Engpass, der das gesamte System negativ beeinflusst. Oft sind es langatmige Governance- oder Freigabeprozesse die Verzögerungskosten (Cost of Delay) verursachen. Sprechen Sie offen mit den verantwortlichen Stellen und unterstützen Sie diese mit Zahlen, Daten und Fakten, um den Gesamtprozess zu verbessern. Eine durchgängige Abstimmung über alle beteiligten Prozesse hinweg ist der Schlüssel, um das volle Potenzial Ihrer Entwicklungsabteilung – und darüber hinaus – zu entfalten.

    <h1 id="clean-core">Clean Core</h1>

In diesem Kapitel erhalten Sie einen Überblick über das Thema Clean Core aus den verschiedenen Blickwinkeln der Migration, der Struktur, der Architektur und als Ziel im Unternehmen.

          {: .no_toc} # Was ist Clean Core

Clean Core auf den ersten Blick
Clean Core Definition
1. Datenmodelle
2. Anwendungslogik
3. Applikationen
4. Schnittstellen
Zielgruppe
1. Private/Public Cloud/BTP
Unterschiede zwischen den Modellen
1. Public Cloud
2. Private Cloud
3. On-Premise
4. Anwendbarkeit von Clean Core:
S/4 HANA Transformation
1. Greenfield-Ansatz
2. Brownfield-Ansatz
3. Bluefield-Ansatz
Abgrenzung im Überblick
Modifikationen in SAP Code
1. Grundsätze für Modifikationen
2. Wichtige Hinweise
3. “NIEMALS SAP CODE KOPIEREN”
  1. Rechtfertigung für Modifikationen
  2. Mögliche Rechtfertigungen:
Saubere Modifikationen
1. DO
2. DON’T
Clean ABAP - Abgrenzung
Eine Management-freundliche Zusammenfassung
Gründe für die Nutzung von SAP-Standard-Prozessen und Erweiterungsmöglichkeiten
1. Zukunftssicherheit und Innovation
2. Reduzierung technischer Schulden
3. Verbesserung der Upgrade-Fähigkeit
4. Förderung von Digitalisierung und Innovation
5. Effiziente Nutzung und Erweiterung von SAP-Lösungen
6. Vorbereitung auf die Cloud-Transformation
7. Einfache Integration von Drittanbieter-Tools
Nachteile des Clean Core Ansatzes
1. Wirtschaftlichkeit
2. Know How
Kundencode
Technologien
Organisation
(Geschäfts-)Prozesse
Add-Ons
Definieren Sie Ihren Lösungsweg
Entscheidungshilfen
ABAP Cloud
1. Freigegebene APIs
2. 3-TIER Modell
3. Migration von Reports
4. Neue Konzepte
Moderne Geschäftsanwendungen erfordern moderne Softwareentwicklungsmethoden
Grundlagen und einfache Anwendung von Objektorientierung im ABAP Kontext
Merkmale Objektorientierter Entwicklung in ABAP-Klassen
Grundprinzipien der Objektorientierung (SOLID)
Entwurfsmuster
1. Singleton-Pattern
2. Factory-Pattern
3. Facade-Pattern
4. MVC-Pattern
Vergleich Vorgehen prozedurale vs. objektorientierter Entwicklung
1. Ablauf Prozedurale Entwicklung
2. Ablauf bei Objektorientiertem Ansatz
Konzepte in der Objektorientierung
1. Erstellung eines Konstruktors pro Klasse
2. Beispiel: Verschalung des Customizing in der Factory-Methode (s.Issue #117 - Klärung Pattern)
3. Vollständiger Einsatz von klasssenbasierten Ausnahmen zur Fehlerbehandlung.
4. Interfaces
Siehe
1. Vererbung
Objektorientierung in Funktionsbausteinen und Form Routinen
Verwendung von SAP Code
Testbarkeit durch gutes Design
TODO before Review ?
Einleitung
Empfehlungen / Best Practices
Managed Entwicklungen mit RAP
1. Datenbankebene
2. Virtuelles Datenmodell
3. Behavior Definition & Pool
4. Behavior Projection
5. OData Veröffentlichung
Weitergehende RAP-Funktionalitäten
1. RAP Unit Testing
2. Erweiterbarkeit
3. Unmanaged Szenario
4. Entity Manipulation Language (EML)
5. RAP Feature Showcase App
6. Migration von CDS-generiertem BOPF
Verfügbarkeitsübersicht der Features
Weiterführende Quellen
Notizen TODOS
Empfehlungen für Testwerkzeuge
1. Testwerkzeuge im SAP Solution Manager
2. Testwerkzeuge in SAP Cloud ALM
3. Tricentis Test Automation
  1. Mögliche Einsatzszenarien für automatisierte Testfälle
    1. Tägliche Smoke-Tests
    2. Regressionstests
Empfehlungen
1. Konsens
2. Verantwortlichkeiten
3. Am Anfang war das Konzept
4. Einfach anfangen
5. Management
6. Weiterbildung
7. Code - Test - Repeat
8. Fazit
Überblick
Dokumentation zur Versionsverwaltung
Transportauftrag
Git-Client
1. Nachrichtensteuerung (NAST)
2. Post Processing Framework (PPF)
3. Druck-Workbench
4. Applikationsspezifische Lösungen
5. S/4HANA Output Control
6. Chancen
7. Risiken
8. Wer stellt Open-Source-Software bereit?
9. Wer nutzt Open-Source-Software?
10. Bewertung und Lebenszyklus einer externen Abhängigkeit
11. Sicherheitsaspekte
12. Verhalten bei Upgrades
13. Lizenzen
14. Support
15. Auslieferung von Open-Source-Abhängigkeiten in eigenen Produkten
Vorstellung ausgewählter Projekte
1. Übersicht
2. Projekte zur Unterstützung des Entwicklungsprozesses
3. Projekte als Bestandteil eigener Erweiterungen oder Produkte
  1. abap2ui5
  2. abap2xlsx
    1. Anwendungsfälle
Überblick
1. ABAP Security: Warum sichere Programmierung in SAP entscheidend ist
2. Warum Security von Anfang an mitgedacht werden muss
  1. Wirtschaftliche Gründe sprechen klar für “Security by Design”:
  2. Technische Vorteile sicherer Programmierung:
3. Ihr Beitrag zur Unternehmenssicherheit
Grundlagen
1. Die häufigsten ABAP-Sicherheitslücken im Überblick
  1. Die Top 5 der ABAP-Sicherheitslücken
  2. Warum entstehen diese Schwachstellen immer wieder?
2. Security-Mindset: Vom reaktiven zum proaktiven Denken
Bedrohungen
1. SQL-Injection in ABAP: Angriffsvektoren und Abwehrmaßnahmen
  1. Angriffsvektoren in ABAP
  2. Effektive Abwehrmaßnahmen
2. Cross-Site Scripting (XSS) in SAP-Webanwendungen
  1. XSS-Angriffsvektoren in SAP
  2. Schutzmaßnahmen gegen XSS
3. Unsichere Direktzugriffe auf Objekte und Autorisierungsumgehung
  1. Typische Angriffsmuster
  2. Effektive Autorisierungsprüfungen
4. Code-Injection und Dynamic Programming Risiken
Sichere Entwicklung
1. Input-Validierung: Der erste Schutzwall
2. Output-Encoding: Daten sicher ausgeben
  1. HTML-Encoding für Webanwendungen
3. Sichere Datenbankzugriffe: OpenSQL Best Practices
  1. Dynamische WHERE-Klauseln absichern
4. Berechtigungsprüfungen richtig implementieren
5. Mandantensicherheit: Datentrennungen garantieren
6. Sichere Dateizugriffe und Pfadtraversal-Schutz
7. Generelles
Entwicklungsprozess
1. Secure Code Reviews: Systematische Sicherheitsprüfungen
  1. Struktur eines Security-fokussierten Code Reviews
  2. Best Practices für ABAP Secure Code Reviews
2. Automatisierte Sicherheitstests in der ABAP-Entwicklung
  1. Static Application Security Testing für ABAP
  2. Integration in den Entwicklungsprozess
3. Security-Checklisten für ABAP-Entwickler
Entwicklung
1. Wieso Sicherheit in ABAP Programmierung wichtig ist?
2. Sicheres Programmieren
3. Einführung ABAP Cleaner
  1. Installation und Funktion
  2. Funktionsweise
4. Regelwerk
5. Hintergrundinformationen/Linksammlung
ABAP Test Cockpit
1. Überblick
2. Zentrales ATC
3. abapGIT
4. Prüfungen - ABAP Checks
5. Prüfungen - Sicherheit
  1. Standard-Sicherheitsprüfungen
  2. CVA - Code Vulnerability Analyzer
SAP Screen Personas 3.0
1. Allgemein
2. Spezielle Sicherheitsaspekte
  1. SSL Verschlüsselung der Verbindung
  2. Schutz vor Cross Site Request Forgery für ITS
3. Allgemeine Empfehlungen für ITS und SAP GUI for HTML
  1. Abmeldung für SAP GUI for HTML aktivieren
  2. Domain Relaxing deaktivieren (falls notwendig)
4. SAP Berechtigungen

Clean Core auf den ersten Blick

Clean Core ist ein Konzept und für einige SAP-Kunden eine Philosophie - Clean Core wird unterschiedlich verstanden, interpretiert und gelebt. Ein gemeinsames Verständnis der DSAG-Community wäre folgendes:

“Clean Core” - Streng genommen ist das Konzept so zu interpretieren: System-Upgrades sollen keinen Einfluss auf Kundenerweiterungen haben. Daher dürfen SAP-Kunden nur freigegebene Schnittstellen für Geschäftsprozesserweiterungen verwenden.
“Keep the core clean” - Bedeutet, dass ein Unternehmen Neuentwicklungen nach Clean-Core-Prinzipien - definierten Richtlinien in einem Unternehmen - durchführt.
“Make the core clean” - Bezieht sich auf die Unternehmenstransformation und die iterative Reise zu einem Clean Core.

Clean Core hat fünf Schwerpunkte: S/4 HANA Software Versionen, Geschäftsprozesse, Kundenerweiterungen, Geschäftsdaten, Betrieb und Integration. Vor allem die neuen Wege der Kundenerweiterungen stehen im Mittelpunkt diesem Kapitel.

„Die Erweiterbarkeitsfunktionen umfassen viele Optionen, die Kunden und Partner dabei unterstützen, Standard-Business-Software an ihre Geschäftsanforderungen anzupassen.“

Quelle: SAP Help Portal

Clean Core

Das Clean Core-Konzept mit seinen verschiedenen Facetten wird von SAP in der TechEd2023 - Clean Core: What It Is, Why to Do It, and How to Get There klar kommuniziert. Die Schritt-für-Schritt-Anleitung ist jedoch für etablierte Kunden, die verschiedene “Legacy”-Technologien in ihren SAP-Systemen einsetzen, unklar. Es gibt zahlreiche Bestandskunden und SAP-Partner, die durch Eigenentwicklungen und Systemerweiterungen Mehrwerte in ihren Systemen geschaffen haben. Diese Mehrwerte gehören per Definition nicht zum Clean Core - die Erweiterungen basieren fast immer auf nicht freigegebenen Schnittstellen. Für die sogenannten RICEFW-Objekte gibt es verschiedene Nachfolgetechnologie-Matrizen. Intern stellen sich vor allem die Fragen: “Wie können wir den Technologiewechsel gegenüber unseren Kunden vertreten? Und warum soll ich gut funktionierende Prozesse, die z.B. auf IDocs, Messages, RFCs und ALV-Transaktionen basieren, jetzt umstellen?”

Clean Core Definition

Im Kern dreht sich das Clean Core-Konzept um die Trennung der Kerngeschäftslogik von der Nicht-Kernfunktionalität innerhalb der SAP-Software-Suite. Durch die Isolierung von Kerngeschäftsprozessen und Datenstrukturen strebt SAP eine schlankere und agilere Basis an, die sich an veränderte Geschäftsanforderungen anpassen kann. Die neuen Wege der Kundenerweiterung heißen: ABAP Cloud und Side-by-Side Extensibility.

ABAP Cloud oder auch “On-Stack Extensibility” - Das sind zwei unterschiedliche Technologien: “Developer Extensibility” und “Key-User Extensibility”.
Side-by-Side Extensibility - Ist die Auslagerung von Kundenerweiterungen in die Business Technology Platform - BTP.

Ein Beispiel: Anstatt das MATMAS IDoc in heterogener Form an verschiedene Systeme zu senden, sollten Sie die standardisierte Schnittstelle Product Master API verwenden. Zur Versorgung der SAP- und Non-SAP-Systeme dient dann eine Schnittstelle, die homogen ausgeprägt werden kann.

Das Datenmodell darunter wird durch Key-User-Extensibility erweitert und auch in generischen Reports wie Embedded Analytics oder auch der SAP Analytic Cloud (SAC) verwendet. Bei komplexer Kundenlogik muss der Entwickler diese Kundenlogik mit Developer Extensibility und dem ABAP RESTful Application Programming Model (RAP) erweitern.

Grundsätzlich ist Clean Core so, wie es der Hersteller beschreibt:

Erweiterungen sind klar vom SAP-Code getrennt und Erweiterungen verändern keine SAP-Objekte.
Nutzen Sie die neuen Erweiterungstechnologien und den SAP-Standard. Erweiterungen verwenden die neuen Erweiterungsmethoden wie Key-User, Developer und Side-by-Side Extensibility.
Erweiterungen verwenden nur stabile, freigegebene SAP APIs und Erweiterungspunkte. Classical Extensibility sollte nur in freigegebenen Business Add-Ins (BADI) mit freigegebenen Entwicklungsobjekten stattfinden.
Legacy Technologien wie RFCs, IDocs und kundeneigene Dynprotransaktionen oder SAP SEGW Projekte sollten nicht mehr für Neuentwicklungen verwendet werden.
Alte kundeneigene Entwicklungen und Erweiterungen sollen auf neue Technologien migriert werden oder die Geschäftsprozessanforderung wird im SAP Standard wiedergefunden.

Aus den Herstellerangaben ergeben sich vier Anwendungsbereiche und die Fakten zur Erreichung eines Clean Core sehen wie folgt aus:

Datenmodelle

Unabhängig davon, ob einfache oder komplexe Anwendungsfälle implementiert werden sollen, ist eine Datenmodellierung mit dem Virtual Data Model (VDM) erforderlich.
Es sollte kein direkter Zugriff auf SAP Standardtabellen erfolgen.
SAP konzentriert sich auf Standarddatenprodukte (z.B. Kundenauftrag). Kundenprozesse und Datenmodelle außerhalb des SAP-Standards bleiben in der Verantwortung des SAP-Kunden.

Anwendungslogik

SAP Standard Coding soll nicht mehr klassisch erweitert werden.
Erweiterungen am Standard sollen in definierte und freigegebene BADIs migriert werden.
Eigenentwicklungen müssen Clean Core konforme Entwicklungsobjekte verwenden (Stichwort: Release Contracts).

Applikationen

Grundsätzlich sollen Kunden die Standard Fiori Apps oder SAP GUI for HTML mit Screen Personas verwenden, um bestehende SAP Standardtransaktionen zu nutzen.
Die Standard Fiori Apps und die dahinterliegenden Standard APIs sollen erweitert werden.
Für Custom Apps sollten zunächst Fiori Elements und Standard APIs (basierend auf RAP) verwendet werden. Die App kann dann über das Flexbile Programming Model (FPM) erweitert werden. Der letzte Schritt wären dann Freestyle Fiori Apps.
Weitere Lösungswege: Cloud Native Applikationen in einem Cloud-Umgebung (Side-by-Side Extensibility). Low-/No-Code Plattformen und das SAP Build Portfolio bieten weitere Lösungsansätze.

Schnittstellen

Es werden nur Clean Core konforme, freigegebene Schnittstellen verwendet.
Erweiterungen werden an APIs und Microservices vorgenommen, um die Funktionalität von SAP zu erweitern, ohne die Integrität des Kernsystems zu beeinträchtigen.
Die Integration nach außen muss klar geregelt sein, Prozessintegration und Middleware für das API-Management müssen vorhanden sein.
Legacy-Technologien wie IDocs, RFCs und SAP SEGW-Projekte müssen sukzessive abgelöst werden.

Zusammenfassend stellt das Clean Core-Konzept der SAP einen Paradigmenwechsel im Design von Unternehmenssoftware dar. SAP setzt darauf, neue Services nur noch in der Cloud anzubieten und die Schnittstellen zum Core weiter auszubauen. Der Mehrwert, gut laufende Lösungen auf eine neue Plattform zu bringen, ist vorerst nicht gegeben. Neue Lösungen sollte ein Unternehmen mit den neuen Erweiterungsarten gehen, um für die Zukunft gerüstet zu sein. So profitiert ein SAP-Kunde von den Innovationen rund um den Standard. Zum Paradigmenwechsel gehört auch die digitale Transformation: weg vom SAP GUI und Dynpros hin zum Fiori Launchpad, die Endanwender sollen primär im Browser arbeiten. Zu einem Clean Core gehört auch ein massives Change Management durch die IT und die Fachbereiche.

Durch die Umsetzung der Prinzipien des Clean Core und strategischer Initiativen können sich Organisationen auf zukünftige SAP-Strategien, insbesondere Cloud-Technologien, vorbereiten.

Laut SAP geht es bei Clean Core vor allem, dass die Kunden sich die Zukunft nicht versperren und standardisiert Schnittstellen aufbauen. Durch die Standardisierung von Geschäftsprozessen und den Einsatz der SAP BTP können SAP Services oder auch Lösungen von SAP Partnern komplett verwendet werden. Die Clean Core Strategie ist für viele Bestandskunden eine Philosophie, bis interne Richtlinien die Nutzungen der Nachfolge-Technologien regeln. Basierend auf den Richtlinien werden Entwickler organisatorisch ausgerichtet, und geschult. Ein Gremium um die “Clean Core Governance” einzuhalten ist Pflicht, mit dem Mandat die Richtlinien zu pflegen, zu erweitern und zu forcieren. Research und Development sollte häufig betrieben werden, um die Mehrwerte durch SAP-Service herauszuarbeiten.

Zielgruppe

Im Wesentlichen sind im DSAG-Netzwerk zwei große Kundengruppen sichtbar: Die erste Gruppe entscheidet sich für eine große Investition in ihre SAP-Landschaft und arbeitet mit SAP und ihren Partnern zusammen, um auf einen Clean Core im Sinne der SAP-Definition zu gehen. Die andere Gruppe entscheidet sich für einen skalierten Ansatz, bei dem die Investitionen über mehrere Jahre verteilt werden.

Hier einige Beispiele für mögliche SAP Kunden:

Neue SAP-Kunden, die auf S/4 HANA migrieren. Hier sollte der Greenfield-Ansatz und das strikte Clean Core laut SAP angewendet werden.
Brownfield to Bluefield: Bestandskunden von SAP, die seit Jahrzehnten mit SAP arbeiten und auf S/4 HANA migrieren. Je nach Investitionsbereitschaft kann schrittweise der Clean Core definiert und die Neuentwicklung konform dazu gehalten werden. Bestehende Kundenerweiterungen werden in Großprojekten auf eine Clean Core konforme Entwicklung umgestellt.
Brownfield to Greenfield: Bestands SAP Kunden, welche seit Jahrzenten mit SAP zusammenarbeiten und auf S/4 HANA migrieren. Hier kann eine Abbildung der Kundenerweiterungen mit sehr hohem Investitionsvolumen erfolgen.
Brownfield im S/4 HANA: Ist identisch mit Szenario zwei.

Private/Public Cloud/BTP

Die digitale Transformation eines jeden SAP-Kunden hängt von der im Unternehmen vorhandenen Expertise, den Partnern, den Investitionsmöglichkeiten und vielen weiteren Faktoren ab. Das DSAG-Netzwerk kann empfehlen, beim Hersteller nachzufragen und zu evaluieren, für welche SAP-Systeme eine Transformation in die Cloud möglich ist. Die Analysetools und die Beratungsbereitschaft der Firma SAP sind sehr hoch. Danach sind die Schritte vielfältig. Nur die Frage muss irgendwann beantwortet werden: Soll das Unternehmen mit seinen SAP-Systemen in die Public Cloud? Hier einige Tipps zu Cloud-Szenarien.

Unterschiede zwischen den Modellen

Public Cloud

Die SAP S/4HANA Cloud, public edition (GROW) ist per Definition “clean”. Starten Sie als Kunde mit GROW oder migrieren Sie ihr System auf ein S/4HANA Public Cloud System, dann können Sie nur noch Clean Core entwickeln und haben keine Möglichkeit auf nicht freigegebene Objekte im Standard zurückzugreifen.

Möchten Sie mit bestehendem Kundencode auf ein Public Cloud System, muss dieser ABAP-Cloud-fähig sein und ihr Prozesse müssen sich mit dem Standard der SAP abbilden lassen.

Private Cloud

Die SAP S/4HANA Cloud, private edition (RISE) ist ein durch SAP betriebenes On-Premise System. Hier müssen Sie kein striktes Clean Core einhalten und haben alle Freiheiten der klassischen On-Premise Entwicklung. Der Fokus liegt hier auf der Vereinfachung der Industry Solutions-Entwicklungen, ohne alle Prozesse vollständig neu zu gestalten. Allerdings kann es sein, dass nicht mehr alle Modifikationen am System durch SAP erlaubt werden.

On-Premise

Sie möchten Ihr System im eigenen Rechenzentrum oder durch einen Dienstleister betreiben lassen, dann sind Sie im klassischen On-Premise Umfeld. Für die Upgrades sind Sie verantwortlich und haben alle Freiheiten bei der Modifikation Ihres Systems.

Anwendbarkeit von Clean Core:

Relevante Szenarien:
- SAP S/4HANA on-premise
- SAP S/4HANA Cloud, private edition (RISE)
Public Cloud ist clean by default:
- Die SAP S/4HANA Cloud, public edition (GROW) ist von Grund auf auf Clean-Core-Prinzipien aufgebaut.

S/4 HANA Transformation

Diese Abgrenzung hilft bei der Entscheidungsfindung, welcher Ansatz am besten zu den Zielen, Ressourcen und Gegebenheiten eines Unternehmens passt.

Greenfield-Ansatz

Der Greenfield-Ansatz beschreibt eine vollständige Neuimplementierung eines SAP-Systems. Dabei wird das bestehende System nicht migriert, sondern ein komplett neues System auf der „grünen Wiese“ aufgebaut.

Merkmale:

Neustart: Vollständige Neuimplementierung ohne Altlasten.
Flexibilität: Möglichkeit, Prozesse, Strukturen und Architekturen komplett neu zu gestalten.
Aufwand: Erfordert intensive Vorbereitungen, Schulungen und hohe Investitionen.
Vorteil: Ideale Lösung für Unternehmen, die ihre Geschäftsprozesse grundlegend überarbeiten und optimieren möchten.
Risiko: Höherer Implementierungsaufwand, längere Projektlaufzeiten.

Brownfield-Ansatz

Der Brownfield-Ansatz bezeichnet die Umstellung eines bestehenden SAP-Systems auf ein neues SAP-System (z. B. SAP S/4HANA) durch Migration. Im Gegensatz zum Greenfield-Ansatz werden hier bestehende Systeme, Daten und Prozesse weitgehend übernommen.

Merkmale:

Bestandserhaltung: Nutzung vorhandener Systeme und Prozesse.
Effizienz: Schnellere Implementierung durch Nutzung bestehender Infrastruktur.
Aufwand: Geringerer Aufwand im Vergleich zum Greenfield-Ansatz.
Vorteil: Minimale Unterbrechung des Geschäftsbetriebs; geringere Risiken.
Risiko: Übernahme von Altlasten (z. B. veraltete Prozesse oder schlechte Datenqualität).

Bluefield-Ansatz

Der Bluefield-Ansatz stellt einen hybriden Ansatz zwischen Greenfield und Brownfield dar. Dabei wird eine selektive Daten- und Prozessmigration durchgeführt, wodurch sowohl Altlasten eliminiert als auch bestehende Systeme genutzt werden können.

Merkmale:

Selektivität: Unternehmen können entscheiden, welche Daten und Prozesse übernommen oder neu gestaltet werden.
Flexibilität und Kontrolle: Optimierung bestehender Prozesse ohne vollständige Neuimplementierung.
Aufwand: Zwischen Greenfield und Brownfield.
Vorteil: Optimale Balance zwischen Innovation und Effizienz.
Risiko: Komplexität in der Planung und Durchführung, da sowohl alte als auch neue Komponenten integriert werden müssen.

Abgrenzung im Überblick

Merkmal	Greenfield	Brownfield	Bluefield
Ansatz	Vollständiger Neubeginn	Systemmigration	Selektive Migration
Datenübernahme	Keine	Vollständig	Teilweise
Prozessübernahme	Neu	Bestehend	Selektiv
Aufwand	Hoch	Mittel	Mittel bis hoch
Flexibilität	Sehr hoch	Gering	Hoch
Risiken	Lange Implementierungszeit	Übernahme von Altlasten	Hohe Komplexität
Geeignet für	Unternehmen mit radikalem Neugestaltungsbedarf	Unternehmen mit bewährten Prozessen	Unternehmen mit gemischten Anforderungen

Siehe auch den folgenden SAP Leitpfaden für weitere S/4HANA und Cloud-Themengebiete Mapping your journey to SAP S/4HANA Cloud Private Edition - A practical guide for senior IT leadership

Modifikationen in SAP Code

Hier wären ein paar Hilfestellungen für SAP Kunden, welche mittelfristig noch nicht in die Public Cloud migrieren können.

Grundsätze für Modifikationen

Definition laut SAP Help:
Eine Modifikation bezeichnet das direkte Ändern des SAP-Standardcodes. Dies ist eine Maßnahme, die von SAP ausdrücklich nicht empfohlen wird, da sie zukünftige Updates und Wartungszyklen erschwert. Mit jedem System-Upgrade wird eine Abarbeitung mit der Transaktion SPAU zwingend duchzuführen sein. Definition laut dem Dokument “Extend SAP S/4HANA in the cloud and on premise with ABAP based extensions”: Sie sollten auch die verbleibenden klassischen Standard-Erweiterungstypen kritisch betrachten und die Verwendung von BADIs bevorzugen. Siehe: “5.3.2 Using classical business logic extension techniques”
Empfohlener Umgang:
Modifikationen und Erweiterungen (Enhancements) gehören zu den klassischen Erweiterungsmethoden und sollten nur dann vorgenommen werden, wenn alle anderen Möglichkeiten, wie die neuen Erweiterungsarten, die Verwendung von BADIs oder Anpassungen durch kundeneigene Objekte ausgeschöpft sind.

Wichtige Hinweise

Vor der Durchführung einer Modifikation ist immer eine Auswirkungsanalyse durchzuführen, um potenzielle Konflikte mit künftigen Updates zu minimieren.
Der Einsatz von kundenspezifischen Erweiterungen sollte bevorzugt werden. SAP Help bietet zahlreiche Möglichkeiten für Erweiterungen, einschließlich:
- User Exits: Vorgesehen für kundenindividuelle Logik.
- BAdIs (Business Add-Ins): Flexible Erweiterungspunkte im SAP-Standard.
- Enhancements (Erweiterungen): Technologien wie Enhancement Framework und Switch Framework für gezielte Änderungen.

“NIEMALS SAP CODE KOPIEREN”

SAP-Help-Grundsatz:
Das Kopieren von SAP-Standardcode birgt das Risiko von Inkonsistenzen und erschwert sowohl die Nachvollziehbarkeit als auch die Wartung. Änderungen sollten ausschließlich über die bereitgestellten SAP-Erweiterungsoptionen wie User-Exits, BAdIs oder Enhancements Points vorgenommen werden.
Ausnahmeregelung:
- In spezifischen Fällen, beispielsweise im Bereich FI (Financial Accounting), kann es notwendig sein, Ausnahmen zu definieren. Diese betreffen Szenarien, in denen Wirtschaftsprüfer spezifische Anforderungen haben oder hohe Audit-Komplexität besteht.
- Eine Modifikations-Implementierung auf Grund von OSS Notes oder Third Party Add-Ons ist meistens der Grund für die Mehrzahl an Modifikationen.
In solchen Fällen gilt:
- Dokumentation und Rechtfertigung der Maßnahme ist zwingend.
- Der betroffene Code muss klar kommentiert und als modifizierter Code gekennzeichnet werden.

Rechtfertigung für Modifikationen

Modifikationen dürfen nur nach gründlicher Abwägung vorgenommen werden. Die Gründe dafür müssen klar dokumentiert und nachvollziehbar sein.

Mögliche Rechtfertigungen:

Implementierung von Alleinstellungsmerkmalen (USPs):
Schaffung oder Anpassung von Funktionen, die eine Differenzierung des Unternehmens ermöglichen.
Prozessoptimierung:
Abbildung kundeneigenere Geschäftsprozesse oder Automatisierung der Standardprozesse und interner Abläufe.
Kosteneinsparungen:
Reduktion von operativen oder langfristigen Aufwänden durch gezielte Anpassungen.

Saubere Modifikationen

Wenn Sie den SAP-Standard verändern möchten, beachten Sie die folgenden Regeln und Best Practices. Die Einhaltung dieser Richtlinien sorgt für wartbaren, nachvollziehbaren und zukunftssicheren Code, der SAP-Upgrades und Patches standhält.

DO

SAP-Code öffnen und einen Enhancement-Spot anlegen:
- Legen Sie in der Modifikation einen Enhancement-Spot an.
- Nutzen Sie alle Vorteile der Enhancements, z. B. die Trennung von Standard- und kundeneigenem Code, sowie die Speicherung im Z-Paket.
Klare Trennung der Logik:
- Geschäftsprozesslogik in separate Klassen oder Methoden auslagern.
- Verwenden Sie dabei eigenständige Testmethoden, um die Logik unabhängig testen zu können.
Dokumentation nicht vergessen:
- Jede Modifikation muss umfassend dokumentiert sein, einschließlich:
  - Zweck der Änderung.
  - Auswirkungen auf zukünftige Updates.
  - Getestete Szenarien.

DON’T

Geschäftsprozesslogik direkt in der Modifikation schreiben:
- Derartige Änderungen erschweren zukünftige Wartungen und Tests.
Kopieren von SAP-Standardcode:
- Vermeiden Sie das Kopieren von Code, da dies zu Inkonsistenzen und technischen Schulden führen kann.
Unübersichtliche Änderungen:
- Vermischen Sie nicht Standardcode und kundenspezifischen Code.

Clean ABAP - Abgrenzung

Bei Clean ABAP geht um das Schreiben von ABAP Code dessen Fokus auf Verständlichkeit und Wartbarkeit liegt. Bei Clean Core der SAP geht es um die Behandlung der Grenzen von kundenindividuellen Programen im SAP Standard. Nur weil eine Umsetzung der Clean Core Stategie enspricht ist diese nicht automatisch Clean ABAP und umgedreht. Mehr dazu im Kapitel ABAP.

          {: .no_toc} # Warum Clean Core

Eine Management-freundliche Zusammenfassung

Die Nutzung von SAP-Standardprozessen und Erweiterungsmöglichkeiten bietet Unternehmen eine zukunftssichere, wartbare und agile Basis für Innovation, Digitalisierung und Transformation. Mit einem klaren Fokus auf Standardlösungen minimieren Sie technische Schulden, fördern effiziente Upgrades und sind optimal auf die Herausforderungen des Cloud-Zeitalters vorbereitet. Wägen Sie immer ab, wann Sie kundenspezifische Erweiterungen erstellen und wann Sie eine andere Plattform für die Erweiterung oder den Geschäftsprozess verwenden sollten.

Gründe für die Nutzung von SAP-Standard-Prozessen und Erweiterungsmöglichkeiten

Zukunftssicherheit und Innovation

SAP Standardtransaktionen und -anwendungen werden mit jedem S/4 HANA Release verbessert und erweitert. SAP bietet neue Innovationen ausschließlich auf Standardprozessen an, insbesondere in der Public Cloud. Die Nutzung dieser Prozesse stellt sicher, dass Unternehmen von zukünftigen Updates und Weiterentwicklungen profitieren können. Eine Entwicklung auf Basis von Standard-APIs und damit Standard-Datenprodukten ist zukunftssicher.

Reduzierung technischer Schulden

Die Reduzierung der technischen Schulden erleichtert die Einführung von Audit/Compliance-konformen und Security-by-Default-Techniken. Beispiel: Kundenspezifische APIs auf Basis von RAP im Managed Szenario ermöglichen einen sicheren Datenaktualisierungsprozess. Langfristig wird der Aufwand für Wartung und Anpassungen reduziert, was eine agile und sichere IT-Landschaft unterstützt. Entweder bei einer Bestandsaufnahme oder bei jeder neuen Anforderung können Sie mit dem 4R-Ansatz: Reuse, Retire, Refactor und Replatform eine Bewertung Ihres kundenspezifischen Codes durchführen. Durch die Definition Ihrer Clean Core Richtlinien können Sie ein aktives Refactoring (Get Clean Phase) durch Projekte durchführen. Danach oder davor sollten alle Neuentwicklungen nach den Richtlinien durchgeführt werden (Stay Clean Phase).

Verbesserung der Upgrade-Fähigkeit

Ein großer Vorteil des Clean Core-Konzepts ist die Möglichkeit schneller und reibungsloser Upgrades. Standardprozesse ermöglichen Upgrades ohne umfangreiche Anpassungen und Tests. Unternehmen können so schneller von neuen Technologien und SAP-Innovationen profitieren.

Förderung von Digitalisierung und Innovation

Bitte beachten Sie zwei Aspekte für zukünftige Geschäftsprozessverbesserungen:

SAP-Innovationen nahtlos nutzen: Durch die Nutzung des SAP-Standards können Unternehmen neue Technologien nahtlos integrieren und Innovationen in ihre Geschäftsprozesse integrieren.
Digitalisierung von Geschäftsprozessen: Standardlösungen, wie z.B. Standard Fiori Apps, können in SAP BTP um künstliche Intelligenz erweitert werden und bilden die Grundlage für eine durchgängige Digitalisierung und Automatisierung.

Effiziente Nutzung und Erweiterung von SAP-Lösungen

SAP-Standardlösungen und -Schnittstellen (z.B. Business Accelerator Hub) ermöglichen die Nutzung einer einzigen Quelle, anstatt mehrere isolierte Nicht-Standardlösungen zu unterhalten. Die Anpassungen basieren auf den bewährten SAP-Erweiterungsmechanismen, die eine zukunftssichere Architektur fördern und auch in Zukunft von SAP erweitert und genutzt werden.

Vorbereitung auf die Cloud-Transformation

Durch das Clean Core-Konzept und die Nutzung von SAP-Standardtransaktionen und -anwendungen können Unternehmen ihre Geschäftsprozesse in die Cloud verlagern, sobald dies sinnvoll ist. Mit SAP-Tools, aber auch mit Nicht-SAP-Systemen und -Plattformen kann die Transformation flexibel und bedarfsgerecht gestaltet werden.

Einfache Integration von Drittanbieter-Tools

Erfinden Sie das Rad nicht neu, insbesondere nicht mit ABAP Legacy Tools. Evaluieren Sie andere Lösungen, auch von Drittanbietern, siehe SAP Store. Denken Sie daran, dass die SAP-Standardprozesse und -Schnittstellen die Integration von Drittlösungen vereinfachen, so dass Unternehmen ihre IT-Landschaft schnell erweitern können.

Nachteile des Clean Core Ansatzes

Siehe auch Kapitel Organisation

Wirtschaftlichkeit

Ist die Umstellung auf Clean Core für Ihr Unternehmen überhaupt wirtschaftlich? Teilweise sind Lösungen über Jahrzehnte hinweg entwickelt worden und bringen einen hohen Mehrwert im Unternehmen. Eine Umstellung zu Clean Core bedeutet eine hohe Investition und teilweise einen kompletten Neubau dieser Lösungen.

Know How

Besitzen Sie bereits im Unternehmen das nötige Know How für die Transformation? Die Entwicklung, aber auch die Beratung, benötigen für den Umstieg auf Clean Core eine Menge an neuem Wissen für aktuelle Technologien und Best Practices auf einem S/4 HANA System.

          {: .no_toc} # Problemfelder und Herausforderungen

Für etablierte Brownfield-Kunden oder SAP-AddOn Hersteller (Partner), die auf Legacy-Technologien basieren, ist die konsequente Umsetzung eines Clean Core-Konzeptes ohne ein Redesign der Prozesse nicht realisierbar.

Kundencode

Der Großteil des über Jahrzehnte gewachsenen Kundencodes muss überarbeitet werden. Grund dafür ist, das bestehende Entwicklung häufig auf nicht freigegebenen APIs oder Entwicklungskomponenten aus dem SAP-Standard basiert. Dabei sollten Sie im ersten Schritt analysieren, ob sie ihr System Cloud-Ready machen wollen. Dabei sollten sie auch prüfen, welche Lösungen vielleicht bereits veraltete Technologien verwenden, wie zum Beispiel BOPF, die komplexe Variantenkonfiguration-Einstellungen oder den klassischen Report.

Neben den Kundenerweiterungen im SAP Standard, gibt es in jedem SAP-System die Thematik der Custom SAP Applications, das sind Eigenentwicklungen, welche neben den SAP Standard parallel laufen. Die Ablösung solcher Anwendungen Bedarf eigener Großprojekte und muss weiterhin von Prozessexperten betreut werden. Die Dissonanz zwischen der Sichtweise von SAP zum Clean Core und den lang-jährigen Kundenstamm ist die Anwendung der Clean Core Prinzipien/Konzepte.

Die Standardtransaktionen, Standard BADIs und Standard Fiori Apps reichen oftmals nicht mehr aus, um die Geschäftsprozessanforderungen abzudecken. Die klassischen Erweiterungen / RICEFW Objekte haben Mehrwerte geschaffen, welche erst in S/4 HANA - dem Clean Core – wiedergefunden werden müssen. Um die neuen Technologien, beispielsweise SAP Build, vor allem auf der BTP zu benutzen, erfordert es an Investitionen in Organisation, Technologien und Prozessen.

Technologien

Von der Verhandlung der Lizenzen, Aufbau der Infrastruktur, Schulung der SAP Basis und Schulung der Entwickler der neuen Technologien bis zum Einkauf von Consulting Services, Betrachtung und Bewertung der Alternativen muss alles in der Evaluierung der Entwicklungslandschaft definiert werden.

Vor allem alternative Technologien, welche mit vorhandenen ABAP-Entwicklern benutzbar sind, werden gebraucht, da existierende Kundenerweiterungen/ RICEFW Objekte weiterhin gepflegt werden müssen.

Organisation

Der klassische Berater und Entwickler entwickelt sich durch die neuen Technologien zu einem Vollzeit-Entwickler mit breiten Entwicklungskenntnissen, hier ist massives Change-Management angesagt. Mehr dazu erfahren Sie im Kapitel Organisation.

Durch die No-Code und Low-Code Optionen, vor allem bei SAP Build, aber auch Key-User Extensibility können nicht-Entwickler in Fusion Teams mitarbeiten. Das erfordert auch eine moderne Arbeitsweise, welche agiler Natur sein sollte.

(Geschäfts-)Prozesse

Organisatorische Prozesse können bspw. im Reporting enorm verschlankt werden. Wenn Standard CDS Views, und Standard APIs genommen werden, dann ziehen die Berechtigungsprüfung in der CDS View. So können Sie Datenprodukte anbieten und die Fachbereichs Kollegen können ohne die IT Reporting betreiben. Ein mögliches Problem: Das bringt die Gefahr das un-performante CDS Views (Stichwort: Compatibility-Views) die Systemlast enorm beeinträchtigen.

Standardprozesse werden von der SAP unterstützt und Standard Fiori Apps kann auch ein Nicht-Entwockler recht simpel im UI anpassen. Kunden mit langer SAP Historie haben oftmals Geschäftsprozessanforderungen, welche weit über die Standard Apps hinaus gehen. Auch ein mögliches Thema sind die SAP SEGW Projekt-basierten Apps: wenn die Standard Fiori App erstmal auf den SAP SEGW-Projekte aufgebaut wird und dann nach einem Systemupgrade diese App auf das RAP-Model im Backend umzieht, so ist die Eigenentwicklung erstmal nachzubauen im neuen RAP-Modell.

Add-Ons

Clean Core hat weiterhin Auswirkungen auf Add-Ons, die im ABAP System eingesetzt werden können. Damit ein Partner zukünftig die Clean Core Strategie Ihrer Kunden unterstützen kann, hat SAP die Bedingungen, eine Zertifizierung von Add-Ons zu erhalten, geändert. Somit ist es nicht mehr möglich eine Zertifizierung eines Add-Ons zu erhalten, wenn die Implementierung der Erweitung nicht den Vorgaben von Clean Core (erstellt in ABAP Cloud oder der BTP) entspricht. Eine Ausnahme hiervon ist nur innerhalb eines SAP S/4HANA Cloud, private edition Add-Ons bis Q3/25 möglich.

Bei Add-Ons ohne SAP Zertifizierung in SAP S/4HANA (on premise) oder SAP S/4HANA Cloud, private edition empfehlen wir daher, rechtzeitig mit dem Add-On Partner zu prüfen, ob dieser sein Produkt nach Clean Core entwickelt hat, bzw. dass rechtzeitig ein kompatibles Add-On für einen bevorstehenden Upgrade geliefert werden.

          <h1 class="no_toc" id="architekturkonzepte">Architekturkonzepte</h1>

Einstieg
Szenarien
1. On-Stack
2. Side-by-Side
Strategie
1. Modelle
2. Kopplung
Make the Core clean

Einstieg

Dieser Abschnitt befasst sich mit den möglichen Architekturen im Bereich Clean Core, wobei Sie mehr über On-Stack und Side-by-Side erfahren und wie Sie diese in Ihrer Architektur implementieren können. Die Extensibility und ihre Implementierung ist die Schlüsselkomponente für Ihr Unternehmen, um Clean Core zu erreichen. Dabei beschreibt Extensibility alle Kundenerweiterungen in einem SAP-Standardsystem sowie Partner-AddOns.

Szenarien

Grundsätzlich haben Sie die Möglichkeit, Ihr System über On-Stack und/oder Side-by-Side Extensibility zu erweitern. Hier finden Sie eine schematische Darstellung der Möglichkeiten.

Extensibility Szenarien

On-Stack

Auf der linken Seite finden Sie die On-Stack Extensibility, unterteilt in Pro Code und Low Code. Im Bereich Pro Code finden Sie die klassische ABAP Cloud Entwicklung mit dem 3-TIER Modell, der Verwendung von Shared APIs und der Erweiterung von Objekten (C0-Objekte). Mehr zum Thema ABAP Cloud finden Sie im entsprechenden Abschnitt von Clean Core.

Im Low Code Bereich gibt es vor allem die Key-User Extensibility, das sind einige Fiori Anwendungen, mit denen man das System erweitern kann. Die häufigsten Szenarien in diesem Bereich sind

Field Extension - Erstellen Sie neue Z-Felder von der Datenbank bis zur UI über die Anwendung.
Anpassung der Benutzeroberfläche - Passen Sie Fiori-Anwendungen an, benennen Sie Elemente um oder zeigen Sie die neuen Z-Felder an. Erstellen Sie Varianten und stellen Sie diese Ihren Fachabteilungen zur Verfügung.
Eigene Logik - Implementieren Sie eigene BADIs und erweitern Sie den Prozess um eigene Prüfungen.
Eigene Core Data Services - Erstellen Sie auf Basis der freigegebenen Views eigene Core Data Services und stellen Sie diese als APIs nach außen zur Verfügung.
uvm.

Die Apps sind in erster Linie für Ihre Key-User gedacht, da sie einfache Änderungen im System ermöglichen. Die Änderungen werden über das Standard Change Management (z.B. CTS) produktiv gesetzt.

Side-by-Side

Auf der rechten Seite finden Sie die Side-by-Side Extensibility, hier geht es um die entkoppelte Entwicklung außerhalb des Kernsystems. In diesem Beispiel handelt es sich um die Business Technology Platform, kurz BTP. Hier finden Sie verschiedene Werkzeuge und Systeme, mit denen Sie Anwendungen zur Erweiterung des Systems erstellen können.

SAP BTP ABAP Environment - Erweiterungen auf Basis von ABAP in der Cloud entwickeln.
SAP Build Code - Erweiterungen auf Basis von Java oder JavaScript entwickeln.

Neben den Pro Code Lösungen finden Sie hier auch Low Code und No Code Lösungen aus dem SAP Build Portfolio. Hier ein kleiner Überblick über die gängigen Tools und deren Einsatz.

SAP Build Apps - Erstellen Sie hier Fiori und Mobile Apps per Drag’n Drop und einfachen Skripten. Die Apps werden dann im BTP zur Verfügung gestellt.
SAP Build Process Automation - Wenn Sie einen Workflow oder eine Automatisierung benötigen, können Sie diese mit der Process Automation erstellen und sowohl SAP- als auch Non-SAP-Systeme anbinden.
SAP Build Work Zone - Wenn Sie einen zentralen Zugriff auf alle SAP Anwendungen benötigen, egal ob On-Stack oder Side-by-Side, dann kann die Work Zone eine Alternative sein. Neben der Standard Edition gibt es auch eine Advanced Edition mit kollaborativen Funktionen.

Strategie

Bevor Sie mit der Arbeit beginnen, sollten Sie sich Gedanken um die Erweiterungsstrategie machen. Das heißt, welche Tools und Umgebungen wollen Sie für die Erweiterungen einsetzen.

Modelle

Dabei sind einige Faktoren des Unternehmens zu berücksichtigen:

Plattform - Welches Erweiterungsmodell möchten Sie im Unternehmen einsetzen (CAP oder RAP). Damit verbunden, wie viele Entwickler benötigen Sie in den Bereichen.
Know-how - Ist das entsprechende Know-how für die Umgebung vorhanden oder muss es erst aufgebaut werden? Im Bereich ABAP wären dies CDS, RAP und Fiori Elements. Im Bereich CAP JavaScript oder Java, Build Pipelines, Git und BTP.

Dazu die folgende Detailgrafik mit den verschiedenen Szenarien.

Tools und Strategie

Ihnen steht das gesamte Produktportfolio der SAP zur Verfügung, wobei jedes Produkt eigene Kompetenzen und Voraussetzungen erfordert. Wir empfehlen daher dringend, eine Strategie zu entwickeln.

Kopplung

Bei der Kopplung geht es um die unterschiedlichen Anforderungen, die eine Anwendung mit sich bringt. Soll die Anwendung On-Premise oder Side-by-Side entwickelt werden? In diesem Artikel finden Sie verschiedene Kriterien, wann sich welche Umgebung lohnt. Grundsätzlich sollten Sie aber verstehen, dass Sie Clean Core auch On-Premise auf Ihrem eigenen System erreichen können und nicht zwingend die Side-by-Side Entwicklung benötigen.

Die beiden Kopplungsszenarien sind:

Eng gekoppelt - Die Anwendung sollte On-Premise erstellt werden.
Lose gekoppelt - Die Anwendung kann auch in der Cloud entwickelt werden.

Make the Core clean

Wenn Sie den Brownfield-Ansatz gewählt und Ihr System auf S/4HANA migriert haben und sich für Clean Core entscheiden, empfiehlt sich eine schrittweise Migration Ihrer Anwendungen. Dabei lohnen sich vor allem häufig genutzte Anwendungen, um schnell von SAP Fiori zu profitieren. So können Sie Anwendung für Anwendung prüfen, welche Sie modernisieren oder vielleicht sogar stilllegen können, weil sie nicht mehr benötigt werden. Ein erster Überblick mit einer Inventarisierung ist daher sinnvoll.

          {: .no_toc} # Lösungsansatz

Definieren Sie Ihren Lösungsweg

Jedes Unternehmen muss für sich intern entscheiden, wie es die neuen Technologien anwendet. Und eine rationale Entscheidung beruht auf wirtschaftlichen Aspekten – Mehrwerte für die Fachbereiche, Zufriedenheit der Kunden, direkte (Lizenzkosten, Betriebskosten) und indirekte Kosten (Mitarbeiter Einstellung, Ausbildung, und Auslaufen des alten Know-hows).

Eine gesamthafte Analyse erfordert auch die Betrachtung von Alterativen zu SAP-Produkten. Bspw. Cloud Native Applikationen kann ein Entwickler nicht nur auf der SAP BTP erstellen. Die anderen Cloud-Anbieter müssen für eine ganzheitliche Bewertung mitbetrachtet werden. Genauso müssen die Tools für API-Management auch definiert und entschieden werden. Die organisatorischen Aspekte von „Fusion Teams“ sollten mit in die Bewertung hineinfließen; Sogenannte Citizen Developer können teilweise IT-Aufgaben, wie Front-End Design übernehmen. Neben SAP und non-SAP Produkten, gibt es auch openSource Projekte, welche diverse Anwendungsfälle, vor allem im Reporting lösen.

Die Umsetzung des Clean Core-Konzepts erfordert einen strategischen Ansatz und eine sorgfältige Planung. Organisationen können den folgenden Ansatz anwenden, um das Clean Core-Konzept von SAP effektiv zu nutzen.

API-First-Ansatz: Begrüßen einen API-First-Ansatz für die Entwicklung, indem Sie Kernfunktionalitäten als wiederverwendbare APIs freigeben, die von internen und externen Anwendungen genutzt werden können. Dies fördert Agilität, Skalierbarkeit und Innovation und gewährleistet gleichzeitig Sicherheit und Governance. Stichwort: SOA - Service Oriented Architecture, oder auch Microservices.
- Neue Schnittstellen, werden nur mit Standard APIs der SAP angelegt.
- Oder eigene Z* REST APIs werden intern geschaffen.
Modularisierung und Standardisierung: Zerlegen Sie monolithische Systeme in modulare Komponenten und standardisieren Sie Datenstrukturen und Schnittstellen, wo möglich. Dies ermöglichten eine größere Flexibilität, Wiederverwendbarkeit und Interoperabilität im gesamten Unternehmen.
- Entscheiden Sie, wo die kundenspezifischen Daten gespeichert werden sollen. Wenn Sie zusätzliche Daten für Ihre Geschäftsprozesse benötigen, dann am besten integriert in ein Standarddatenprodukt, vermeiden Sie parallele Datenmodelle zur Standardtabellen.
- Harmonisieren Sie Ihre Geschäftsprozesse und starten Sie Projekte um Z-Transaktionen auf Standard Fiori Apps zu kommen.
- Entscheiden Sie welche Kundenerweiterung bestehen bleiben.
Bewertung und Rationalisierung: Führen Sie eine gründliche Bewertung der bestehenden SAP-Landschaften durch, um Bereiche der Komplexität und Redundanz zu identifizieren. Rationalisieren Sie Systeme und Prozesse, um sie mit den Prinzipien des Clean Core in Einklang zu bringen und Prioritäten für Vereinfachungsmaßnahmen zu setzen.
- Führen Sie Fit-Gap-Workshops durch und starten Sie Bereinigungsprojekte von performanten, unsicheren, oder ungenutzten Code.
- Bilden Sie Ihre Architekten aus, um anhand Richtlinien bewusst neue Technologien zu nutzen.

Entscheidungshilfen

Hier finden Sie ein paar Referenzen und mögliche Entscheidungshilfen:

Eine Methodik für Unternehmensarchitekten SAP Application Extension Methodology - SAP AEM
Der vollständige Leitfaden von SAP, wie Kunden Clean Core-Erweiterungen durchführen können Extend SAP S/4HANA in the cloud and on premise with ABAP based extensions
Schauen Sie auch Beispiele mit dem Erweiterungsszenarien-Explorer an
Was ist das freigegebene Nachfolge-Entwicklungsobjekt? Cloudification Repository Viewer
Weitere Überlegungen finden Sie auch im Kapitel: Integration

ABAP Cloud

ABAP Cloud ist das neue Entwicklungsmodell für alle Systemlandschaften, egal ob SAP BTP ABAP Environment, S/4HANA Cloud Public Edition und Private Edition oder S/4HANA On-Premise, können Sie das selbe Modell für die Entwicklung von Clean Core und Cloud Ready Anwendungen verwenden. Die Verwendung wird Ihnen im Extensibility Guide für S/4HANA genauer beschrieben. In den folgenden Abschnitten werden Sie einige Details erhalten. ABAP Cloud ist fundamentaler Bestandteil, wenn Sie Clean Core erreichen möchten.

ABAP Cloud

ABAP Cloud - Verfügbarkeit

Freigegebene APIs

Die Verwendung von freigegebenen APIs (Entwicklungsobjekte mit C1-Freigabe) ist zentraler Bestandteil von ABAP Cloud. SAP gibt Ihnen als Kunde die Zusage, dass diese API stabil ist und für eigene Entwicklungen genutzt werden kann. Damit können in ABAP Cloud nur SAP Objekt verwendet werden, die SAP auch explizit freigegeben hat.

3-TIER Modell

Das 3-TIER Modell ist zentraler Bestandteil, wenn Sie einen Übergang von klassischer ABAP Entwicklung in Richtung ABAP Cloud gehen. Dabei sind erst einmal alle Objekte, die außerhalb einer Software Komponente, kurz SWC, mit ABAP Cloud sind, nicht Clean Core. Die Aufgabe besteht für Sie nun darin, die Entwicklungen ABAP Cloud Ready zu migrieren. Dabei werden Objekte von TIER-3 auf TIER-1 verschoben und nicht freigegebene APIs ersetzt.

Sind die APIs aktuell nicht freigegeben, könnne Sie auf TIER-2 soganannte Wrapper erstellen, die SAP Funktionalität kapseln und für Ihre Entwicklung in TIER-1 freigeben. Im Zuge dessen sollten Sie einen Influence Request bei SAP erstellen, um die Freigabe oder eine alternative API zu erhalten. Weitere Informationen zur Erstellung von Wrappern und welche Objekte sich eignen, finden sie im SAP Guide: ABAP Cloud API Enablement.

Migration von Reports

Reports/Programme sind heute zentraler Bestandteil zur Ausführung von Logik in einem SAP System, egal ob im Dialog oder im Hintergrund per Batch-Job. Allerdings sollten Sie bei der Migration beachten, dass Reports nicht mehr Teil von ABAP Cloud sind.

Aktuell gibt es die folgenden Nachfolger:

Fiori App - Erstellung einer Anwendung auf SAP Fiori Basis mit dem ABAP RESTful Programming Model, kurz RAP. Weitere Informationen zu RAP finden Sie im Kapitel für Entwicklung. Die App ist der Einstiegspunkt für den Anwender.
Application Job - Diese neue Art von Job basiert in der Entwicklung auf einer Klasse, die durch eine zentrale Routine im System gestartet wird. Der Start erfolgt über eine Fiori Anwendung. Jobs sind vor allem zur Automatisierung von Tätigkeiten im Hintergrund.

Neue Konzepte

Mit der Einführung von ABAP Cloud, wurden verschiedene Entwicklungskonzepte überarbeitet und Nachfolger zur Verfügung gestellt. Sie sollten daher beachten, dass die alten Konzepte teilweise nicht mehr gültig sind. Dazu einige Beispiele:

Bereich	Alt (TIER-3)	Neu (TIER-1)
Application Log	SLG0, SLG1	CL_BALI_OBJECT_HANDLER, ABAP API
Job	SM36, SM37, Report	Application Job
E-Mail	CL_BCS	CL_BCS_MAIL_MESSAGE
E-Mail	SOST	Monitor Email Transmissions (F5442)
Programmiermodell	BOPF	RAP
Tabellenpflege	SM30	Business Configuration
Übersetzung	SE63	Maintain Translations (F4950)

Die vollständige Liste finden Sie hier.

    <h1 class="no_toc" id="alles-über-core-data-services">Alles über Core Data Services</h1>

Core Data Services Views (CDS Views)
Aufbau von dem VDM
View-Typen, Namenskonventionen und Einsatzmöglichkeiten
Unterstützte Funktionen und Modellierungsmuster
1. Unterstützte Funktionen
2. Modellierungsmuster
CDS View Modellierungsmöglichkeiten
1. Typ-Definitionen
  1. Simple Types
  2. Enumerated Types
Function Definitions
Annotations
Data Definitions
Access Control
1. Eigenschaften
Associations
Erweiterbarkeit
1. Stabilitätsverträge
2. Erweiterungen von SAP Standard CDS Views
BW-Integration, embedded Analytics und ODP
Tipps und Trick

Core Data Services Views (CDS Views)

Was sind CDS Views und warum sind sie wichtig? In S/4 HANA soll der Entwickler nicht mehr direkt auf die Datenbanken zugreifen, sondern das Virtuelle Datenmodell (VDM) nutzen, um auf die Daten in SAP S/4HANA zuzugreifen, z.B. für Analysen oder Schnittstellen. Das VDM wird in SAP S/4HANA durch CDS-Views repräsentiert. Diese CDS-Views folgen festen Regeln für die Modellierung und Benennung. Sie stellen Geschäftsdaten aus Datenbanktabellen auf Basis der Geschäftslogik dar und machen die Daten so einfacher nutzbar. CDS Views sind die Schlüsselelemente für On-Stack Extensibility oder auch ABAP Cloud - siehe Kapitel Clean Core. Die Nutzung und Erweiterung eines Datenmodells ist der Schlüssel zum VDM-Konzept. CDS Views werden für viele Zwecke verwendet, z.B. als Schnittstelle zwischen verschiedenen Anwendungen und Add-Ons im selben System sowie zu externen Systemen und Anwendungen. Sie können auch eigene Views erstellen, indem Sie, nach dem Clean Core Gedanken, die von SAP bereitgestellten und freigegebenen Views verwenden.

Aufbau von dem VDM

CDS_Ueberblick

Quelle: SAP Help Darstellung des VDMs{: .img-caption}

Vor die Datenbanktabellen werden verschiedene CDS-View-Layer gelegt. Die VDM sorgt z.B. dafür, dass die Datenbankfelder verständlich sind und der Benutzer leichter auf die Inhalte zugreifen kann. Der Basic Interface Layer greift auf die Datenbank zu. Die Composite Interface Views fassen Logik und Basic Interface Views zusammen; das VDM kann verschiedene Abstraktionsschichten enthalten. Die Consumption-Views geben das Datenmodell für den Anwendungsfall frei.
Im Rahmen des ABAP RESTful Application Programming Model (RAP) werden von SAP auch weitere Begriffsdefinitionen, z.B. Business Object Projection Layer, vorgegeben.

Hier wäre die folgenden Aufstellung der View Arten. Alle Standard Views beinhalten auch die Kennung / Annotation:

@VDM.viewType:[..]

View-Typen, Namenskonventionen und Einsatzmöglichkeiten

View-Typ / Suffix	Beschreibung	Annotation
I_*	Basic- und Composite-Interface-Views: Diese CDS-Views dienen dem Lesen von Daten und können für Erweiterungen genutzt werden.	`@VDM.viewType: #BASIC` `@VDM.viewType: #COMPOSITE`
C_*	Consumption-Views: Eingeschränkte Wiederverwendungsviews.	`@VDM.viewType: #CONSUMPTION`
P_*	Private Views: Diese Views dürfen nicht verwendet werden, da SAP sie bei System-Upgrades verändern kann.	`@VDM.private: true`
R_*	Views für transaktionale Verarbeitung: Diese CDS-Views ermöglichen nicht nur das Lesen von Daten, sondern auch Aktionen wie das Anlegen, Ändern oder Löschen von Instanzen eines RAP-Business-Objekts im Kontext des ABAP-RESTful-Anwendungsprogrammiermodells (RAP).
A_*	Remote-API-Views: Diese CDS-Views bilden die Grundlage für externe APIs. Weitere Informationen über APIs finden Sie im SAP Business Accelerator Hub.	`@VDM.viewType: #CONSUMPTION` `@VDM.lifecycle.contract.type: #PUBLIC_REMOTE_API`
X_*	View-Erweiterungen: Diese CDS-Views können Daten nur indirekt im Kontext einer anderen CDS-View lesen. Sie bieten Zugriff auf branchen- oder länder-/regionsspezifische Felder, die von SAP definiert wurden.	`@VDM.viewExtension: true`
E_*	Extension-Include-Views: Diese CDS-Views können Daten nur indirekt im Kontext einer anderen CDS-View lesen. Sie bieten Zugriff auf benutzerdefinierte Felder, die in der App „Benutzerdefinierte Felder“ angelegt wurden.	`@VDM.viewType: #EXTENSION`
F_*	Ableitungsfunktionen: Leiten kontextspezifische Werte ab, mit denen Daten in analytischen Queries eingeschränkt werden können. Weitere Informationen finden Sie unter Ableitungsfunktionen für Finance
D_*	Abstrakte Entitäten: Bilden die Grundlage für die Modellierung von Ereignissignaturen und Aktionsparameter-/Ergebnisstrukturen.

Desweiten, gibt es die Kennung als Suffix je nach Einsatzbereich des CDS Views.

Suffix	View-Typ	Annotation
Query, Qry, Q	Analytische Query-View	`@VDM.viewType: #CONSUMPTION` `@Analytics.query: true`
Cube, C	Analytische Cube-View	`@Analytics.dataCategory: #CUBE`
Text, Txt, T	Provider für sprachabhängigen Text	`@ObjectModel.dataCategory: #TEXT`
TP	View für transaktionale Verarbeitung	`@VDM.usage.type: [ #TRANSACTIONAL_PROCESSING_SERVICE ]`
VH, StdVH	(Standardmäßig) View für Wertehilfe	`@ObjectModel.dataCategory: #VALUE_HELP`

CDS-Views können für viele verschiedene Zwecke verwendet werden, z. B. zum Erstellen von Fiori-Anwendungen oder zum Analysieren von Daten. Sie können eigene CDS-Views erstellen und dabei auf viele von SAP freigegebene Views zurückgreifen. Um Ihnen die Suche nach der passenden CDS-View zu erleichtern, hat SAP zwei Funktionen eingeführt: Unterstützte Funktionen und Modellierungsmuster. Diese Merkmale werden als Annotationen spezifiziert und können für jede CDS-View definiert werden. Sie können die unterstützten Funktionen und Modellierungsmuster von CDS-Views im View-Browser App sehen. In den ABAP Development Tools finden Sie diese Informationen als Annotation am Anfang jeder CDS-View.

Open Source Tipp Die folgende SAP Community Seite ZSCV_SEARCH_CDS_VIEWS bietet eine Open-Source-Lösung zur Suche von CDS-Views an.

Unterstützte Funktionen und Modellierungsmuster

Unterstützte Funktionen

Die unterstützten Funktionen geben an, so die SAP, wofür eine CDS-View am besten verwendet werden kann. Eine CDS-View kann mehrere unterstützte Funktionen haben, da sie für verschiedene Zwecke geeignet sein kann.

Diese Funktionen beschreiben die beste Verwendung einer CDS-View. Sie können beispielsweise die Verwendung einer CDS-View als:

Datenquelle
Ziel für Verknüpfungen in der CDS-Modellierung
Datenlieferant für analytische Abfragen

Die unterstützten Funktionen einer CDS-View werden in einer einzigen Annotation angegeben:

@ObjectModel.supportedCapabilities: [ ..., ... ].

Modellierungsmuster

Ein Modellierungsmuster beschreibt den Hauptzweck einer CDS-View. Eine CDS-View kann nur ein Modellierungsmuster haben. Der Wert des Modellierungsmusters kann gleich dem Wert einer unterstützten Funktion sein, muss es aber nicht.

Die Annotation für ein Modellierungsmuster sieht so aus:

@ObjectModel.modelingPattern: ...

CDS View Modellierungsmöglichkeiten

Dieser Abschnitt beschreibt die verschiedenen Typ-Definitionen, Funktionsdefinitionen und Datenmodelle innerhalb von SAP Core Data Services. Dabei werden einfache und enumerierte Typen, SQL-basierte Funktionen sowie verschiedene View-Typen wie DDIC-basierte Views, View Entities und Projection Views erläutert. Ergänzt wird dies durch fortgeschrittene Konzepte wie Table Functions, Hierarchien, Custom und Abstract Entities sowie Tuning-Objekte zur Optimierung von CDS-Modellen.

Typ-Definitionen

Simple Types

Hiermit definieren Sie elementare Datentypen, welche Sie in CDS Objekten oder in ABAP verwenden können.

Beispiel

define type myDate : abap.dats

Details finden Sie unter SAP Help (CDS Simple Types)

Enumerated Types

Definieren Sie einen enumerierten Typ mit Konstanten. Sie können den Typ und die Konstanten in CDS Objekten verwenden.

Beispiel

Definition

define type Weekdays : abap.int1 enum
{
    Monday = initial;
    Tuesday = 1;
    Wednesday = 2;
    Thursday = 3;
    Friday = 4;
    Saturday = 5;
    Sunday = 6;
}

Verwendung

define ... as select from ...
{
    ...
}
where
  weekday = Weekdays.#Friday

Details finden Sie unter SAP Help (CDS Enum Types)

Function Definitions

Aktuell bietet SAP nur die Definition einer Scalar Function an. Dabei gibt es zwei verschiedene Arten von Funktionen.

Analytical scalar function
- Diese Art der Funktionen ist aktuell nur SAP intern definierbar. Sie können die von SAP ausgelieferten Funktionen aber nutzen.
SQL-based scalar function
- Sie können eigene Funktionen dieser Art definieren und implementieren. Die Verwendung ist wie bei den eingebauten SQL Funktionen (wie z.B. CONCAT()). Eine Scalar Function kann mehrere Parameter haben und hat immer einen einzigen Rückgabewert.
- Sie benötigen drei Entwicklungsobjekte für eine Scalar Function:
  - Eine Scalar Function Definition (CDS Objekt)
  - Eine Scalar Function Implementation Reference, als Verknüpfung zwischen der Definition und der Implementierung
  - Eine AMDP Function, welche die Implementierung der Scalar Function darstellt

Details finden Sie unter SAP Help (CDS Scalar Functions)

Annotations

TODO Armin

Data Definitions

DDIC-based views

DDIC basierte Views sind ab Release 7.55 ersetzt worden durch View Entities, welche nicht mehr von DDIC Objekten abhängig sind

Ein DDIC basierter View kann für DDIC Datenbanktabellen, DDIC Views und andere CDS Views erstellt werden. Bei der Definition müssen Sie über eine Annotation ein SQL-View-Name angeben, der im ABAP Dictionary als DDIC View erzeugt wird. Bei der Aktivierung des CDS Views werden ein CDS Entity und der annotierte DDIC View erzeugt bzw. aktualisiert. Per SQL greifen Sie auf die Daten der referenzierten Objekte zu.

Beispiel

@AbapCatalog.sqlViewName: 'CDS_DB_VIEW'
define view ddic_based_view as select from ...
{
  field,
  ...
}
where
  field = 'ABC'

Details finden Sie unter SAP Help (CDS DDIC-Based Views)

View Entities

Mit einem CDS View Entity können Sie auf Felder einer Datenquelle (Datenbanktabellen, andere CDS Entitäten) zugreifen. Die View Entities dienen als Basis für die ABAP Data Models und werden vom ABAP RESTful Application Programming Model verwendet. Sie sind also ein wichtiger Bestandteil für eine moderne ABAP Entwicklung.

Beispiel

view entity view_entity as select from ...
{
  field,
  ...
}
where
  field = 'ABC'

Details finden Sie unter SAP Help (CDS View Entities)

Projection Views

Ein Projection View basiert auf einem anderen CDS View Entity und wird für service-spezifische Anwendungsfälle genutzt. Dazu zählen:

Transaktionale Abfragen (relevant für ABAP RESTful Application Programming Model)
Transaktionales Interface (relevant für ABAP RESTful Application Programming Model)
Analytical Abfragen

Details finden Sie unter SAP Help (CDS Projection Views)

Table Functions

Eine Table Function besteht aus zwei Teilen. Einem CDS Entity, welches z.B. bei den CDS View Entities oder Projection Views verwendet werden kann, und einer AMDP Function, welche die Implementierung der Funktion darstellt. Das Ergebnis einer Table Function sind Datensätze. Eine AMDP Function ist nur in einer Umgebung nutzbar, deren Datenbanksystem AMDP unterstützt (z.B. SAP HANA). Mit der AMDP Function können Sie plattform-spezifische SQL-Befehle anwenden. Der Vorteil liegt darin, dass Sie spezielle Abfragen durchführen auf die Datenbank und die Ergebnisse als Datenquelle für andere CDS Entities bereitstellen können.

Details finden Sie unter SAP Help (CDS Table Functions)

Hierarchies

Mit dieser Art von CDS-View können Sie hierarchische Daten bereitstellen. Als Grundlage muss ein CDS View Entity angegeben werden, welches eine Association auf sich selbst besitzt. Diese Association beschreibt die Beziehung zum Eltern-Knoten. In der Feldliste können Sie Felder der CDS View Entity angeben und spezielle Hierarchie-Attribute, z.B. das Level des Eintrags in der Hierarchie.

Details finden Sie unter SAP Help (CDS Hierarchies)

Custom Entities

CDS Custom Entities gehören zu den Non-SQL-Entitäten. Sie können sie nutzen, um auf Daten zuzugreifen, auf die nicht per SQL zugegriffen werden kann. Zum Beispiel Daten in einer Datei, einem BLOB oder von einem Web-Service. Für den tatsächlichen Zugriff müssen Sie eine ABAP Klasse erstellen, welche ein bestimmtes Interface implementiert. In der Definition des CDS Custom Entity müssen Sie die Klasse per Annotation angeben. Außerdem definieren Sie dort mögliche Eingabeparameter und die resultierende Feldliste.

Die Nutzung der CDS Custom Entities ist aber eingeschränkt. Sie können sie nicht im Zusammenhang mit SELECTs verwenden, d.h. weder in einem anderen CDS View noch per ABAP-SQL. Sie können allerdings Associations darauf definieren und diese in der Feldliste anbieten. Diese Associations können dann von der RAP Query Engine verarbeitet und eine Abfrage ausgeführt werden, z.B. im Zusammenhang mit einem OData-Service.

Details finden Sie unter SAP Help (CDS Custom Entities)

Abstract Entities

CDS Abstract Entities gehören zu den Non-SQL-Entitäten. Sie können sie als komplexe Datenstrukturen für RAP Actions, RAP Functions und RAP Business Events nutzen. In anderen CDS Views ist es nur möglich Associations auf diese Entities zu definieren. Ein Zugriff per SQL oder auf Inhalte ist aber nicht möglich.

Details finden Sie unter SAP Help (CDS Abstract Entities)

Tuning objects

Aktuell bietet SAP nur einen Konfigurationstyp an: Define View Entity Buffer. Damit kann eine Pufferung der Daten definiert werden (keine Pufferung, Einzelsatz, Bereiche, Vollständig). Diese Einstellung kann sich auf die Performance auswirken.

Details zur Performance finden sie auch hier: Siehe SAP Help Seiten SQL Hint und Tuning Objects

Access Control

Über die Access Controls können Sie durch Angabe von Rollen, Regeln und Bedingungen definieren, welche Nutzer bzw. welcher Nutzerkreis Zugriff auf bestimmte Daten erhält. CDS-Views bieten Zugriffskontrollen über Data Access Controls (DAC), ähnlich dem klassischen Authority Check.

Eigenschaften

Zugriffskontrollen in CDS ermöglichen es Ihnen, präzise zu definieren, welche Datensätze für jeden Benutzer zugänglich sind.

Diese Zugriffskontrollen arbeiten zusammen mit den üblichen SAP-Berechtigungsobjekten.
SAP-Berechtigungsobjekte beziehen sich immer auf ein bestimmtes Feld in einer Tabelle und eine Aktivität, wie z.B. das Anlegen, Ändern oder Anzeigen von Daten.
Der Zugriff auf eine CDS-Sicht wird über die sogenannte Data Control Language (DCL) gesteuert.

Ob eine Zugriffskontrolle angewendet wird, wird durch die folgende Annotation entschieden:

@AccessControl.authorizationCheck: []

Das Standard VDM beinhaltet immer Zugriffskontrollen. Eine gängige Vorgehensweise ist, die Zugriffskontrollen von den unterliegenden CDS Views auf Ihre kundenspezifischen CDS Views zu vererben.

Beispiel

define role ZC_BusinesspartnerAddress_DAC {
    grant select on ZC_BusinesspartnerAddress_Custom  
        where inheriting conditions from entity C_BusinesspartnerAddresstp_2;
}

Es gibt noch weitere Funktionen, die Sie sich hier ansehen können: SAP ABAP CDS - Access Control Documentation

Tipp Mit der Transaktion SACMSEL können Berechtigungsprüfergebnisse vereinfacht angezeigt werden.

Associations

TODO

Erweiterbarkeit

Stabilitätsverträge

Um die zuverlässige Nutzung von CDS-Views zu gewährleisten, hat SAP drei Stabilitätsverträge (Englisch: Release Contracts) eingeführt. Diese Verträge definieren, wie CDS-Views in verschiedenen Nutzungsszenarien verwendet werden können:

Vertrag für Erweiterungen (C0): Für die Nutzung und Anpassung vorhandener Views.
Vertrag für den systeminternen Gebrauch (C1): Für Views innerhalb des gleichen Systems.
Vertrag für Remote-API-Verwendung (C2): Für die Nutzung von Views durch externe Systeme und Anwendungen.

Weitere Informationen finden Sie im Stabilitätskontrakte für CDS-Views.

Erweiterungen von SAP Standard CDS Views

Ein großer Vorteil ist die Möglichkeit, beliebige CDS Views mit dem Vertrag für Erweiterungen (C0) und höher zu erweitern. Dies birgt aber auch eine Gefahr! Wenn Sie z.B. Felder aus einer bestehende CDS Views in Ihrer erweiterten CDS View ( ZE_* ) verwenden, dann können diese bei S/4 HANA Upgrades verändert werden. Achten Sie darauf nur in den vorgesehenen E_* CDS Views, CDS Views “hinzufügen”. Wir empfehlen diese Learning Journey von SAP, hier wird der Sachverhalt erläutert.

BW-Integration, embedded Analytics und ODP

Das Operational Data Provisioning Framework (ODP) ermöglicht die Übertragung von Daten aus verschiedenen SAP-Repositories nach SAP BW, SAP BW/4HANA und anderen Systemen oder Servicen. CDS Views können als Quelle für die Datenextraktion dienen.

Voraussetzungen für den Transfer zu SAP BW/4HANA

Der klassische CDS View oder CDS View Entity sollte folgende Annotationen besitzen:

@Analytics.dataCategory
@Analytics.dataExtraction.enabled

Voraussetzungen für embedded Analytics

Embedded Analytics funktioniert nicht nur in den Analytical Fiori Apps oder über die Key-User Extensibility Apps. Ein direkter Konsum eines CDS Views, durch die Online Analytical Processing (OLAP) Engine, ist auch direkt in den Buiness Intelligence (BI) Tools möglich. Insbesondere die SAP Analytic Cloud (SAC), aber auch Analyse for Office (AO).

Weitere Informationen finden Sie in diesem Blog-Eintrag.

Hier wäre die Struktur, um z.B. einen CDS View direkt aus der SAC zu konsumieren. Dazu müssen zwei zusätzliche CDS Views erstellt und mit der Annotation versehen werden.

Composite CDS View (Entity) @Analytics.dataCategory: #CUBE / '#FACT / #DIMENSION
Consumption CDS View (Entity) @Analytics.query: true

CDS_Ueberblick Musteraufbau: Direkter Zugriff vom SAC{: .img-caption}

Dabei ist zu beachten, dass für den Consumption CDS View einen Vertrag für den systeminternen Gebrauch (C1) vergeben werden muss. Zusätlich werden noch die folgenden Authorisierungs-Objekte in den Rollen der Anwender benötigt.

S_RS_COMP
		RSINFOAREA   *
		RSINFOCUBE   *
		RSZCOMPTP		REP (for analytical reporting) / SOB (for planning functions)
		RSZCOMPID		2C<SQLViewName of Analytical Query>
		ACTVT				03, 16

S_RS_COMP1
		RSZCOMPID		2C<SQLViewName of Analytical Query>
		RSZCOMPTP		REP (for analytical reporting) / SOB (for planning functions)
		RSZOWNER		 * (Only in the catalog role not in authorization default)
		ACTVT				03,16
  
S_RS_AUTH
		BIAUTH		  0BI_ALL

Weitere Informationen finden Sie im SAP Help Portal.

Funktionsweise ODP

Die ODP-Schnittstelle ermöglicht den Zugriff auf Bewegungsdaten und Stammdaten (Attribute, Texte, Hierarchien). Das SAP BW/4HANA-System abonniert operative Delta-Queues und repliziert die Daten. Die Datenänderungsquellen unterstützen ebenfalls Deltaverfahren.

Weitere Informationen finden Sie im SAP Help Portal.

Tipps und Trick

Empfehlungen

Performance Tracing - Untersuchen Sie immer jeden CDS-View! Egal ob SAP Standard oder selbst erstellt. Über einen SQL Trace in ST05 können Sie die SQL Ausführung nachvollziehen, dazu müssen Sie die .PLV Datei extrahieren und in Eclipse anzeigen. So können Sie Zeitverteilungen und Ausführungspläne analysieren. Achten Sie darauf, die Gesamtzahl der zurückgegebenen Datensätze zu überprüfen, um Designprobleme zu erkennen. Siehe DSAG Eclipse ADT Guides - Performance “Auswahl einer konkreten Selektion”

Massive JOINs und komplexe Abfragen - Für massive JOINs (z.B. 7-14 Tabellen) können CDS Views effizienter sein, indem sie in Schichten mit Assoziationen aufgeteilt werden, um die Performance zu verbessern. Für komplexe Abfragen ermöglichen CDS Views Code Pushdown, aber Vorsicht bei AMDPs auf großen Tabellen (> 1 Million Einträge), da dies die Performance beeinträchtigen kann. Bitte beachten Sie, dass AMDPs pro Tabellenzeile selektieren. Mit welcher Selektion gehen Sie in die AMDP?
Schnelle Abfragen - Halten Sie Selektionen klein und spezifisch, um die Leistung zu optimieren, und vermeiden Sie AMDPs auf großen Tabellen, um den Datenbankzugriff zu beschleunigen. Wir empfehlen den Hinweis 2000002 - FAQ: SAP HANA SQL Optimization. Falls die Optimierung am SQL Engine selbst stattfinden soll nutzen Sie gerne dann diese Seite HINT Details.
Potenzial für eine SAC Query prüfen - Für wiederholte, benutzerdefinierte Datenabfragen sind BAPIs, Funktionsbausteine oder ABAP SQL oft besser geeignet, da CDS Views für standardisierte, wiederverwendbare Modelle gedacht sind. Für SAC-Berichte sind CDS Views besonders nützlich, da sie direkt von SAC konsumiert werden können.
Bereitstellung von Daten für Subsysteme - RAP kann verwendet werden, um CDS Views als OData Services zu exponieren, was ideal für die Bereitstellung von Daten für Subsysteme ist. Dies bietet modifikationsfreie Erweiterbarkeit, insbesondere in Cloud-Umgebungen. Siehe Kapitel ABAP - RAP

    <h1 class="no_toc" id="moderne-abap-entwicklung">Moderne ABAP Entwicklung</h1>

Einführung ins Thema und Inhalte des Kapitels
Anwendungsgebiete der Empfehlungen und Methoden
Die Rolle der Organisation
Zielgruppe des Kapitels

Einführung ins Thema und Inhalte des Kapitels

Willkommen im ABAP Kapitel. Hier geht es um den Kern der modernen SAP Entwicklung - um ABAP. In diesem Kapitel möchten wir Empfehlungen und Hinweise aus der Praxis geben, wie ABAP in modernen Anwendungen sinnvoll angewendet wird, welche Vorteile und Möglichkeiten die Nutzung von modernem ABAP bietet und dass es sich der Umstieg und die Transformation von der klassischen ABAP-Entwicklung hin zu moderner Anwendungsentwicklung lohnt und der Invest hierin sich mittelfristig auszahlt. Wir können hierbei nicht alle Grundkenntnisse erläutern, daher werden für die folgenden Ausführungen solide Grundkenntnisse in Programmierung vorausgesetzt. SAP hat schon vor vielen Jahren die ABAP-Programmierrichtlinien herausgebracht in denen grundlegende Prinzipien genannt und erläutert werden. Deren Prinzipien gelten auch weiterhin, werden aber durch weitere Empfehlungen wie Clean ABAP ergänzt und erweitert.

Dieses Kapitel ist keine Beschreibung oder Dokumentation wie ABAP-Entwicklung im Generellen durchgeführt wird, dazu gibt es gute Online Schulungen, die inzwischen sogar kostenlos angeboten werden, die SAP Dokumentation und gute Bücher dazu.
Detaillierte Beschreibungen einzelner Sprachelemente und Entwicklungsartefakte finden Sie in der SAP Dokumentation. In diesem Dokument werden aber einzelne Beispiele zur Veranschaulichung detaillierter erläutert.

ABAP ist die Programmiersprache im SAP Umfeld und wird von zahlreichen Entwicklern seit langem umfangreich eingesetzt. Seit den Anfängen von ABAP als Berichtsprogrammiersprache hat sich, wie generell in der IT, sehr viel getan und insbesondere in den letzten Jahren hat sich auch ABAP umfassend weiterentwickelt, insbesondere durch die Einführung von S/4HANA.

ABAP hat den Vorteil, dass mit geringen Aufwand und ohne tiefgreifende Kenntnisse in Programmierung schnell Anforderungen umgesetzt werden können, sofern sie nicht komplexerer Natur sind. Somit kann sich die Umsetzung von Anforderungen in ABAP ohne zahlreiche Zwischenschritte an den Geschäftsanforderungen orientieren. Dieser Geschäftsprozessorientierte Einsatz von ABAP findet sich mannigfaltig im Unternehmen und viele ABAP-Programmierer sind über den Weg von Customizing, Erstellung einfacher Reports, Debugging, Implementierung von User-Exits usw. in die ABAP-Welt eingestiegen.
Im Jahr 2025, wo viele Unternehmen den Sprung auf S/4HANA bereits angehen oder angehen werden, sind die neuen Technologien, Methoden und Tools noch nicht in dem Umfang im Einsatz wie es beim klassischen ABAP der Fall ist. Hier steht für die ABAP-Entwicklung” eine Transformation an, die sowohl für den Entwickler als auch für das Unternehmen herausfordernd ist.

Der Leitfaden im Generellen und dieses Kapitel in Bezug zu ABAP möchte hier Hilfestellung geben und den Weg erleichtern. Der Weg zur Erstellung moderner Anwendungen ist kein Leichter und es ist eine Investition, deren Ertrag nicht sofort anfällt. Weshalb es sich aber lohnt diese Reise anzugehen und Reisetipps finden sie auf den folgenden Seiten. Dieses Kapitel teilt sich in folgende Abschnitte auf:

Architektur und Design moderner ABAP Entwicklungen
Hier erfahren Sie warum es wichtig ist und viele Vorteile bringt, ABAP Entwicklungen in Paketen zu strukturieren, die Paketfunktionalitäten zu nutzen und was Sie wissen müssen um unsere Empfehlungen umzusetzen.
Design und Erstellung von ABAP Entwicklungen mit ABAP OO
Die Anwendung von Objektorientierung ist ein essentieller Faktor eine moderne, robuste und Anpassungsfähige Software zu erstellen. In diesem Kapitel finden Sie unsere Empfehlungen OO gut und effizient umzusetzen und warum die Anwendung von Objektorientierung und gute Strukturierung der Funktionalitäten in Klassen sich auszahlt.
Sauberer und moderner Code
Neben den übergeordneten Strukturen in Form vom Paketdesigns und der Strukturierung der Anwendung in Objekten, bildet der ABAP-Code die Funktion der Anwendung her. Der Code wird einmal erstellt, im Laufe des Lebenszyklus vielmals gelesen, erweitert, geändert und überprüft. Daher zahlt sich die Investition in gut lesbaren, verständlichen und übersichtlichen Code aus. Die Anwendung der Clean Code Prinzipien und Anwendung moderner ABAP-Statements und Funktionen ist essentiell um zukunftsfähige Anwendungen zu erstellen und effizient zu betreiben.
RESTful Application Programming Model - RAP
Mit dem RESTful Application Programming Model hat SAP nach einigen Evolutionsschritten nun ein stabiles und ausgereiftes Programmiermodell veröffentlicht, das viele Möglichkeiten bietet, viele Vorteile mit sich bringt und Entwicklern einen guten Rahmen bietet, moderne Anwendungen zu bauen.
Die Empfehlungen der vorigen Abschnitte gelten für alle Entwicklungen in SAP, deren Umsetzung sind aber eine gute Grundlage, um für die Anwendungsentwicklung mit RAP gerüstet zu sein.
Empfehlungen zu RAP und das Vorgehen bei Entwicklung von RAP Applikationen finden Sie in diesem Kapitel.

Anwendungsgebiete der Empfehlungen und Methoden

Die in den folgenden Abschnitten beschriebenen Empfehlungen, technischen Methodiken und Programmiertechniken lassen natürlich sehr gut bei der Erstellung neuer Anwendungen einplanen, einsetzen und anwenden. Alles hier Beschriebene kann und soll auch verwendet werden, um bestehende Entwicklungen zu verbessern. Dies fällt unter das Stichwort Refactoring.
Refactoring beschreibt die qualitative und strukturelle Verbesserung von Software durch technische Überarbeitung bestehender Funktionen und das Abbauen von technischen Schulden.
Beispielsweise ist die Aufteilung einer sehr umfangreichen Methode in überschaubare kleine private Methoden ein derartiges Refactoring. Des Weiteren fallen Umbenennungen von Modularisationseinheiten, oder das Zusammenfassen gleichen Codes an verschiedenen Stellen in eine zentrale Methode zum Refactoring.

Refactoring sollte immer dann vorgenommen werden, wenn bestehende Anwendungen geändert oder erweitert werden müssen. Dafür muss Zeit eingeplant werden. Gute Hinweise für ein sinnvolles Vorgehen zum Refactoring ist z.B. im Clean-ABAP-Styleguide beschrieben.

Refactoring beschreibt aber nicht nur die Verbesserung des Codes, sondern kann im übertragenen Sinne auch auf die Struktur in Form der Pakete angewendet werden. Objekte können sinnvoll in neue Unterpakete verteilt werden. Falls eine hauptpaketbasierte Struktur bisher nicht umgesetzt wurde, können Hauptpakete erstellt werden und bisherige Pakete diesen Paketen zugeordnet werden. Eine Aufteilung zu grosser Pakete in kleinere Pakete ist möglich, allerdings sind hier die Abhängigkeiten zu prüfen, zu klären und ggf. zu eliminieren. Dabei hilft aber die Paketkapselung und die Paketprüfung. Die Verbesserung an bestehender Software sollte kontinuierlich und in kleinen Schritten erfolgen und durch Tests abgesichert werden. Wenn dies im Entwicklungsprozess integriert ist und zum Tagesgeschäft der Entwicklung gehört, wird sich das mit besser wartbarer und weniger Fehleranfälligen Software auszahlen.

Die Rolle der Organisation

Wie Sie an den folgenden Ausführungen sehen werden, ist es unabdingbar für moderne und flexible Softwareanwendungen, neben einem guten Paketdesign auch ein gutes Design der einzelnen Softwarekomponenten unter Anwendung moderner Softwareentwicklungsmethodiken einzufordern und umzusetzen.
Die Objektorientierung ist ein grosses und komplexes Thema, dass sich nicht kurzfristig erschliessen lässt, sondern einiges an Erfahrung benötigt um gute objektorientierte Software zu erstellen.
Für eine effiziente Transformation der Organisation und der Entwickler zu moderner SAP Entwicklung braucht es Rahmenbedingungen und ein Enabling der Entwicklungsteams.
Entwicklungsvorgaben, Richtlinien, Prinzipien, Handbücher und Kontrollmechanismen alleine sind nicht ausreichend, um die Techniken und Methoden moderner Softwareentwicklung im ABAP-Umfeld in den Entwicklungsalltag und somit “auf die Straße” zu bringen.
Es wichtig, dass die Entwicklungsorganisation sich intensiv darum kümmert, die Entwickler gut aus- und weiterzubilden, Anreize zu schaffen neues Auszuprobieren und auch anzuwenden. Dafür müssen Rahmenbedingungen geschaffen werden und manche Vorgehensweisen überdacht werden.
Ein Upskilling und die Motivation der Entwickler ist ein unabdingbarer Erfolgsfaktor. Dafür braucht es Rahmenbedingungen die im Unternehmen und in der täglichen Arbeit der Entwickler gegeben sein müssen.
Und es muss Instanzen geben, die diese Aspekte definieren, verantworten und auch für die Umsetzung in der täglichen Arbeit sorgen. Andernfalls fungieren die o.g. organisatorischen Maßnahmen als “zahnloser Tiger”, die Organisationsvorgaben und die reale Arbeit weichen signifikant voneinander ab.

Ein wichtiges Element dabei ist auch die Wertschätzung Entwicklern gegenüber dafür, dass Anwendungen mit neuer Technologie umgesetzt werden, auch wenn dies zu Beginn oftmals mit längerer Entwicklungszeit einhergeht oder nicht immer reibungslos klappt. Nur wenn es in der Organisation anerkannt und wertgeschätzt wird, dass Entwickler- oder Entwicklerteams sich weiterbilden, sich in neue Technologien und Methoden einarbeiten und diese Umsetzen, findet eine nachhaltige Veränderung statt und es kann ein Mehrwert von den neuen Technologien entstehen.

Wertvolle und ausführliche Informationen zu dem Themenkomplex Organisation und Rahmenbedingungen finden Sie im Kapitel Organisation.

Zielgruppe des Kapitels

Wir sprechen in erster Linie den Personenkreis der ABAP Entwickler und in die ABAP-Entwicklung Involvierte an. Wir möchten aber auch Entscheider und Vorgesetzte von Entwicklungsteams ansprechen, da für die ABAP-Transformation Rahmenbedingungen gegeben sein müssen um auf dieser Reise erfolgreich zu sein. Und dafür möchten wir die Motivation im Unternehmen schaffen indem wir die Vorteile und Praxisempfehlungen hier aufzeigen.

          <h1 class="no_toc" id="architektur-und-strukturierung-in-der-abap-entwicklung">Architektur und Strukturierung in der ABAP Entwicklung</h1>

Architektur und Struktur als Fundament und Rahmen einer guten SAP Anwendung
Strukturierung von Software in Paketen
Anwendung des Paketkonzepts in der Praxis
Vorteile und Nutzen durch Nutzung des Paketkonzeptes
Weitere Aspekte
Von der Architektur zum Design

Architektur und Struktur als Fundament und Rahmen einer guten SAP Anwendung

In vielen SAP ERP Systemen finden sich zahlreiche und umfangreiche Eigenentwicklungen die im Laufe der Lebenszeit des Systems entstanden sind und kontinuierlich erweitert wurden. Je komplexer ein System ist, desto wichtiger ist es, dass die darin enthaltenen Applikationen und Komponenten in einer wohldefinierten Struktur geordnet sind, die gängigen Softwarearchitekturprinzipien folgen. In SAP ERP Systemen ist dies im Bereich der Eigenentwicklungen nicht immer gegeben. Dies hat unter anderem folgende Gründe:

Entwicklungsklassen
Die Entwicklungen wurden begonnen, als das SAP-Paketkonzept noch nicht vorhanden war und dessen Vorgänger, die Entwicklungsklassen, verwendet wurden. Diese ermöglichten nur eine flache Strukturierung und somit folgte auch die Struktur sehr groben Kriterien, z.B. pro Entwicklungsteam oder Modul. Dieses Prinzip wurde nach Einführung des Paketkonzepts beibehalten und weitergeführt.
Wissen
Das Wissen über das Paketkonzept und die Anwendung von Softwarearchitekturprinzipien ist im ABAP-Umfeld bis heute nicht hinreichend vorhanden.
Änderung und Erweiterung an bestehender Software Viele Entwicklungen betreffen die Weiterentwicklung bestehender Funktionalitäten. Ein Redesign und eine damit verbundene Paketstrukturierung wird selten eingeplant und vorgenommen.
Zeit- und Termindruck
Letztlich finden die meisten Entwicklungen unter Zeitdruck statt. Die Frage, wie eine Anwendung sinnvoll in Paketen strukturiert werden kann, wird oft nicht gestellt oder vernachlässigt, da die Lieferung der Funktionalität im Vordergrund steht.

Als Folge dieser Rahmenbedingungen können sich folgende Probleme ergeben:

Mangelnde Transparenz und Verständlichkeit:
Sowohl die Aufgaben und deren Verantwortlichkeiten einzelner Artefakte, als auch deren Abhängigkeiten zueinander sind nicht aus der Struktur der Pakete ersichtlich.
Hohe Anpassungsaufwände
Änderungen an bestehender Software erfordern hohe Aufwände verursacht durch aufwändige Analyse, die zu ändernden Artefakte zu finden und die Änderung korrekt umzusetzen. Da die Korrektheit von Änderungen schwer vorhergesagt werden kann, enstehen hohe Test- und Fehlerkorrekturaufwände.
Seiteneffekte und Fehler bei Änderungen bestehender Anwendungen: Änderungen können zu nicht vorhersehbaren Seiteneffekten in der Produktion führen und damit zu erhöhten Entwicklungs- und Fehlerbereinigungsaufwänden.
Probleme bei Verteilung und Import von Änderungen Es kann zu Problemen bei Transporten kommen, wenn nicht alle notwendigen Objekte korrekt transportiert wurden oder nicht alle Abhängigkeiten berücksichtigt wurden (z.B. RC8).

Software wird in der Komplexität sehr gern unterschätzt und nur wer von Anfang an sich Gedanken über eine gute Softwarearchitektur gemacht hat und die Anwendung laufend technisch und strukturell auf dem aktuellen Stand hält, wird mit der oben beschriebenen Problematik weniger konfrontiert sein.
Daher ist es essentiell sich zuallererst Gedanken zu machen, welche Funktionen und Zuständigkeiten eine zu erstellende Anwendung haben soll, wie die Verantwortlichkeiten geregelt sind und wie sich dies letztendlich in der Paketstruktur widerspiegelt.
Mit dem SAP Paketkonzept haben Sie das Werkzeug, um die Grundlagen für eine saubere und zukunftsfähige Anwendungsarchitektur zu legen.

Strukturierung von Software in Paketen

Das SAP Paketkonzept und die Aufgabe von Paketen

SAP hat, wie in anderen Programmiersprachen wie z.B. JAVA üblich, auch in ABAP ein Paketkonzept implementiert, mit dem es Möglich ist, die Software auf verschiedenen Ebenen zu strukturieren. Vor der Verfügbarkeit des Paketkonzepts waren Entwicklungsobjekte in Entwicklungsklassen als flache Struktur organisiert.
Mit der Einführung des Paketkonzepts ergeben sich deutlich erweiterte Möglichkeiten der Softwarestrukturierung, die zwar nicht direkt auf die Funktionalität an sich wirken, aber spätestens bei der Wartung, Pflege und Erweiterung der Eigenentwicklung deutliche Vorteile mit sich bringen. Da es seitens SAP eine ausführliche und gut verständliche Dokumentation des Paketkonzeptes gibt, werden wir hier nicht auf das Paketkonzept im Detail eingehen, einen praxisnahen Überblick und Empfehlungen geben, wie bei Erstellung von Eigenentwicklungen, im Weiteren “Software” genannt, vorgegangen werden kann, um Pakete in ABAP sinnvoll und nutzbringend einzusetzen. SAP Dokumentation ABAP Workbench - Package Builder

In den folgenden Abschnitten wird auf die Anwendung des Paketkonzepts eingegangen, welches auf On-Premise Systemen ab [ab SAP Web Application Server 6.2 bzw. deren Erweiterung ab Netweaver 7.3 EHP1] eingesetzt werden kann.

Empfehlungen

Nutzen Sie das Paketkonzept:

Schalten Sie auf Ihren SAP-Systemen die Paketprüfung ein.

Erstellen Sie für Ihre Eigenentwicklungen Hauptpakete, die sich an architektonischen Erfordernissen (Single Responsibility) orientieren.

Schalten Sie pro Paket die Paketkapselung ein.

Gruppieren und strukturieren Sie das Paket mit Unterpaketen anhand den Zuständigkeiten und nicht nach Objekttyp.

Machen Sie während des Entwicklungsprozesses regelmäßig Paketchecks, um Abhängigkeiten zu erkennen.

Prüfen Sie bei nicht sichtbaren Objekten Alternativen (z.B. vergleichbares Objekt mit Sichtbarkeit aus anderem Paket, Eigendefintion im Paket …).

Nehmen Sie gewünschte Abhängigkeiten in den Verwendungsnachweis auf.

Vermeiden Sie die Erstellung sehr grosser Pakete oder “Sammelpakete” die zahlreiche unabhängige Funktionen bündeln.

Schulen Sie Ihre Entwickler bzgl. der Paketdefinition und Strukturierung im Unternehmen

Grundlagen und Begriffserklärungen zum Paketkonzept

Ein Paket dient der Strukturierung von Software. In einem Paket werden Softwareartefakte zusammengefasst, die für einen bestimmten Zweck zuständig sind. Pakete können (und sollten auch) gekapselt sein. Das bedeutet, dass ein Objekt eines Paketes ein Objekt eines anderen Pakets nicht verwenden kann bzw. von einem Objekt eines anderen Pakets nicht verwendet werden kann, sofern diese nicht über eine Paketschnittstelle öffentlich gemacht werden und beim Verwender im Verwendungsnachweis deklariert werden.
Um unsere Empfehlung für Sie umsetzbar zu machen, werden im Folgenden ein paar Grundlagen genannt, um dann den Nutzen und die Vorteile zu erläutern.

Im SAP Paketkonzept gibt es das Hauptpaket, welches Unterpakete, aber keine Entwicklungsobjekte enthält. Das Hauptpaket repräsentiert im Regelfall die Anwendung, die alleine lauffähig ist. Weitere Fälle werden weiter unten beschrieben.

Ein Unterpaket definiert sich dadurch, dass es nicht als Hauptpaket gekennzeichnet ist und einem Hauptpaket zugeordnet ist. Die Unterpakete dienen der internen Strukturierung der Artefakte des Hauptpaketes.
Das Hauptpaket definiert die Struktur nach außen und stellt die verschiedenen Anwendungen dar. Die Unterpakete definieren die innere Struktur einer Anwendung.

Die Paketschnittstellen werden pro Paket definiert und definieren die Sichtbarkeit der in der Paketschnittstelle enthaltenen Objekten nach außen.

Als letzten hier zu erklärendem Begriff kommt die Verwendungserklärung, die in einem Paket gepflegt wird. In die Verwendungserklärung werden Paketschnittstellen aufgenommen, deren Objekte vom aktuellen Paket verwendet werden.
Verwendet ein Paket A ein Artefakt aus einem Paket B, wird in der Verwendungserklärung des Paketes A, die entsprechende Paketschnittstelle B aufgenommen. Somit ist auf Paketebene sofort ersichtlich, welche Abhängigkeiten das Paket A besitzt (nämlich zu Paket B). Dazu ist die Verwendungserklärung auch im Verwendungsnachweis auswertbar. Somit ist es möglich herauszufinden, wie die Verwendungsbeziehungen gestaltet sind.

Den Hauptpaketen übergeordnet finden sich die Strukturpakete, die Hauptpakete auf höchster Ebene zusammenfassen. Diese machen vor allem bei grossen Softwareprojekten Sinn, bei denen es eine große Anzahl von Hauptpaketen gibt. In Sinne der Komplexitätsreduzierung wird in diesem Leitfaden allerdings auf die Strukturpakete nicht weiter eingegangen. Details finden Sie hierzu in der SAP Dokumentation.
Strukturpakete einzusetzen, kann sinnvoll sein, wenn im Unternehmen das Paketkonzept bereits umfänglich mit Haupt- und Unterpaketen angewendet wird und eine übergeordnete Struktur sinnvoll abbildbar ist. Strukturpakete werden von SAP selbst verwendet um eine technische gesicherte Entkopplung von Paketen sicherzustellen und dies nicht auf Hauptpaketebene definiert werden soll SAP Dokumentation: Von Paketen zu Strukturpaketen.
Die Paketschnittstellen der Strukturpakete können keine Entwicklungsobjekte enthalten, sondern definieren die Beziehungen zu anderen Strukturpaketen. Damit kann die Deklaration und Pflege von Verwendungsbeziehungen reduziert werden und die technische Entkopplung von Applikationen (wie bei SAP_APPL und SAP_HR) sichergestellt werden.
Im Rahmen von Cloud werden Strukturpakete als Wurzelpakete der Softwarecomponents benötigt und sind daher dort notwendig.

Das “Paketkonzept” in ABAP Cloud - Softwarecomponents

Die ABAP Entwicklung ist stark im Wandel, insbesondere der Weg der SAP in die Cloud wird auch die ABAP Entwicklung mit deren Tools und Methoden in naher Zukunft weiterhin maßgeblich beeinflussen.
Im Kontext von ABAP Cloud, ist das hier beschriebene Paketkonzept nicht mehr 1:1 anwendbar, da Paketschnittstellen in der Cloud nicht mehr unterstützt werden.
Das Prinzip der Trennung von Komponenten und der Definition von Abhängigkeitsbeziehungen zwischen Paketen wird in ABAP Cloud über Softwarecomponents und Softwarerelations behandelt. Die Pakete darunter dienen nur zur Strukturierung der Anwendungen.
Des Weiteren können einzelne Objekte für die Verwendung aus anderen Softwarekomponenten über die Release Status freigegeben werden.
SAP Dokumentation SWC

Die Umsetzung und Anwendung des klassischen oben beschriebenen Konzepte ist dennoch in allen Versionen von SAP ERP sinnvoll, das es Entwicklungen strukturiert, Abhängigkeiten und Sichtbarkeit deklariert und damit hilft gute Anwendungen zu erstellen.
Des Weiteren bereitet es sowohl die Entwickler, als auch die Entwicklerorganisation auf die Entwicklung in der Cloud vor, da bezüglich der Strukturierung von Software dann nicht mehr die allgemeinen Prinzipien erlernt werden müssen, sondern die bestehenden Konzepte nur noch auf die neuen Strukturartefakte übertragen werden.

Anwendung des Paketkonzepts in der Praxis

Definition des Hauptpakets

In den folgenden Ausführungen beschreiben wir die Aspekte des Paketkonzepts für die Erstellung einer größeren Eigenentwicklung. Auf andere Fälle wird später eingegangen. Am Anfang der Umsetzung einer Eigenentwicklung muss klar definiert sein, welche Funktion die Software erfüllen soll und welchen SAP Applikationsbereich die Software betrifft. Damit kann nun der Name der Eigenentwicklung als Komponente definiert werden. Dabei müssen Vorgaben der Entwicklungsrichtlinien im Unternehmen wie Namenskonventionen und Präfixe beachtet werden. Die Namensgebung spielt hier eine wichtige Rolle und sollte gut bedacht werden, unter Berücksichtigung anderer Komponenten. So sollte im Namen ersichtlich sein, um welches SAP Objekt es sich handelt (z.B. Belegtyp, Formulare …) und welche Funktion die Komponente erfüllt. Da Eigenwicklungen meistens in Bezug zu SAP Funktionen stehen, sollte dieser Bezug auch über den Namensbezug erkennbar sein. Meistens muss der Name noch sinnvoll gekürzt werden, da durch Namensräume und Präfixe die Anzahl der verfügbaren Zeichen begrenzt ist.
Wenn Sie beispielsweise eine abgegrenzte und wiederverwendbare Erweiterung bzw. Eigenentwicklung im Bereich EWM umsetzen möchten, die Funktionen in der Be- und Verarbeitung von Handling Units behandelt, sollte sich sowohl der Bereich EWM, das Objekt HU, als auch die Aufgabe im Namen wiederfinden. Der Name könnte sich z.B. wie folgt zusammensetzen: Z_EWM_HU_PROCESSING.
Dieses Paket kann dann mehrere Funktionen in EWM beinhalten, die HU’s betreffen.

Damit steht der Name des Hauptpaketes, das nun in SAP erstellt werden kann und sowohl als Hauptpaket als auch als gekapselt eingestellt wird. Bei der Erstellung des Pakets wird nun noch die SAP Applikationskomponente zugeordnet, hierbei sollte dieselbe Komponente verwendet werden, die auch der zugehörigen SAP Standardkomponente zugeordnet ist. Dies kann dem Paket der zugehörigen SAP Objekte, die in Beziehung zur Eigenentwicklung stehen, entnommen werden.

Innerhalb dieses Hauptpaketes sind nun die Unterpakete zu erstellen, die sich im Namen an dem Hauptpaket orientieren, als Postfix aber die Funktion des Unterpaketes ausdrücken. Ein Unterpaket zum EWM-HU Paket, welches das Verpacken betrifft, könnte z.B. wie folgt abgeleitet werden: Z_EWM_HU_PRC_PACKING.

Erstellung der Unterpakete - Unterteilung nach Funktion der enthaltenen Objekte

Die Unterteilung des Hauptpaketes in Unterpakete sollte nicht nach Objekttyp erfolgen (z.B: DDIC, Forms, Klassen), sondern nach logischer Funktion. Je nach Art der Software können folgende Unterpakete erstellt werden:

.._CORE oder …_ENG (für Engine) Basispaket In diesem Paket werden Objekte erstellt, die von den anderen Unterpaketen verwendet werden und die zentralen Funktionen wie Geschäftsprozesslogik und gemeinsam genutzte Funktionen enthalten.
.._UI - Alle Artefakte für Anwendungsoberflächen.
.._API oder ..IF - z.B: für ODATA services, Klassen oder RAP-BO Interfaces, die von anderen Paketen verwendet werden können und entsprechend in der Paketschnittstelle propagiert werden.
.._DATA- Objekte die Datenbankabfragen kapseln oder anderweitig Daten beschaffen (CDS Artefakte).
.._TEST - Objekte für Unit Tests und Testhelper wie auch Mock-Objekte - alles was zur Testinfrastruktur zugehörig ist.
.._HLP oder ..SHARED - Unterpaket für Hilfsobjekte oder Funktionen, die in mehreren Unterpaketen verwendet werden, z.B. Nachrichtenklassen oder Logging Funktionen.

Einsatz von Paketen bei der Implementierung von BAdIs und bei kleinen Erweiterungen

Die oben beschriebene Struktur ist sinnvoll für größere Entwicklungen, bei denen zahlreiche Objekte erstellt werden, und schafft Ordnung und Übersicht. Die gleiche Vorgehensweise in reduzierter Form macht aber auch für kleine Erweiterungen, wie bei BAdI-Implementierungen, durchaus Sinn. Hierbei erstellt man ein Hauptpaket als Entsprechung des Paketes des SAP Enhancement Spots, orientiert sich an der Namensgebung und vergibt dieselbe Applikationskomponente.
Die Unterpakete kann man hier entsprechend den Teilbereichen der einzelnen BADIs strukturieren, je nach Umfang der einzelnen BADIs des Enhancement Spots. Für Funktionen, die in mehreren BADIs wiederverwendet werden, können wie oben beschrieben Objekte in Helper und Core Unterpaketen erstellt und in den BADIs entsprechend aufgerufen werden.

Manchmal sind Entwicklungen sehr kleine Objekte wie Hilfsreports, oder einzelne Klassen die mehrfach über Pakete verteilte Funktionen bereitstellen. Hierfür jeweils eigene Hauptpakete mit Unterpaketen bereitzustellen, wäre überdimensioniert.
Für diesen Fall empfehlen wir die Anlage von Hauptpaketen, die funktionsorientiert gemeinsame Funktionen bereitstellen (z.B. ‘Bereich’_UTILS). Die Unterpakete können dann weiter die einzelnen Aufgabenbereiche gliedern und zentrale Funktionen werden im Core Unterpaket gesammelt.

Idealerweise werden die nach außen sichtbaren Funktionen in den Paketschnittstellen propagiert, so dass die Verwender diese Pakete im Verwendungsnachweis deklarieren können.

Vermeidung grosser / unspezifischer Sammlerpakete

Wir empfehlen die Erstellung großer Sammlerpakete (z.B. auf Basis Modulebene) nicht zu erlauben, da dies zu Problemen mit der Übersichtlichkeit und zu ungewünschten Abhängigkeiten führen kann und das Prinzip der Single Responsibility verletzt.

Das Risiko ist groß, dass Klassen und Funktionen in solchen Paketen landen, anstatt solide architektonische Überlegungen vorzunehmen, was die Anstrengungen, eine geordnete Systemarchitektur einzuhalten, konterkarieren kann.
Es kann aber durchaus Sinn machen, kleine, wohldefinierte und Domänenspezifische Hilfspakete zu erstellen, die grundlegende und oft benötigte Hilfsfunktionen bereitstellen.

Paketschnittstellen

Mit den bisher genannten Ausführungen sind zwar unsere Entwicklungen besser geordnet, wir bekommen eine bessere Übersicht und durch den Zwang der Strukturierung werden automatisch architektonische Überlegungen der Entwicklung vorangestellt.
Maßgebliche Vorteile und Verbesserung im Softwaremanagement ergeben sich aber erst durch die Nutzung der Paketschnittstellen.

Ist ein Paket in sich geschlossen und die Verwendung von Objekten des Paketes durch andere Pakete ist nicht erforderlich oder gewünscht, benötigt das Paket keine Paketschnittstelle. Handelt es sich aber um ein Paket, das Funktionalitäten nach außen propagieren und somit von anderen Paketen genutzt werden soll, werden Paketschnittstellen benötigt. In einer Schnittstelle werden die Objekte aufgenommen, die von anderen Paketen verwendet werden können. Dabei sind die Paketschnittstellen in derselben Weise hierarchisch wie die Pakete selbst. Details wie Paketschnittstellen aufgebaut und Objekte aus Unterpaketen über das Hauptpaket propagiert werden, findet sich in der [SAP Dokumentation].

Ein gut designtes Paket sollte ein eigenes API- oder Interface Unterpaket besitzen, das Interfaces, Klassen und Artefakte enthält, die von außen verwendet werden können. Diese Objekte und das Paket verschalen damit die Implementierung und die Komplexität der Anwendung. Mittels Paketinterface und Propagierung werden diese Artefakte nach außen sichtbar. Somit können innerhalb des Paketes jederzeit Änderungen vorgenommen werden, solange das Interface nach außen stabil bleibt. Bzw. besteht die Möglichkeit, neue Interfaces aufzunehmen, die eine neue Version darstellen.

Verwendungserklärung

Auf Paketebene gibt es neben den Schnittstellen, die die Propagierung nach außen deklariert, noch die Verwendungserklärung. Mit dieser wird aufgelistet, welche Paketschnittstellen ein Paket verwendet. So kann in der Verwendungserklärung geprüft werden, ob die aufgelistete Verwendung und somit die Erzeugung von Abhängigkeiten von Paket xy wirklich gewünscht und vorgesehen ist. Damit werden diese Abhängigkeiten technisch dokumentiert und sind auswertbar bzw. ablesbar.
Dies gilt bedingt für SAP-Pakete. Sofern SAP-Objekte in Paketschnittstellen deklariert wurden, können diese auch über den Paketcheck und die Vorschlagfunktion automatisiert in den Verwendungsnachweis aufgenommen werden. Allerdings sind seitens SAP die Paketschnittstellen nicht für die Kommunikation zu den Kunden bzgl. Objektfreigabe vorgesehen und nicht vollständig gepflegt [PRÜFEN SAP.TF ob so formulierbar?].
Zumindest hilft die Verwendungserklärung hier einen Überblick über sichtbare (über die Verwendungserklärung) und unsichtbare (Fehler im Paketcheck) SAP-Objekte zu bekommen.

Paketprüfung

Eine zentrale Rolle zur sinnvollen Umsetzung des Paketkonzepts in Eigenentwicklungen ist die Paketprüfung. In den ABAP Developments Tools, kann diese direkt in den Einstellungen aktiviert werden, oder über den ATC ausgeführt werden. Im SAP GUI in der SE80 ist dies über das Kontextmenü möglich.
Bei der Paketprüfung wird angezeigt, ob Objekte eines anderen Paketes verwendet werden, die Verwendungserklärung aber noch nicht deklariert wurde. In dem Fall kann dies automatisiert durchgeführt werden, wobei die gesamte Hierarchie berücksichtigt wird. Dies ist bei den komplexen SAP-Paketen hilfreich und zeitsparend.
Die Paketprüfung zeigt als Fehler auch die Verwendung von nicht sichtbaren Objekten aus anderen Paketen an. Dies sind Objekte, die nicht mittels einer Paketschnittstelle als sichtbar deklariert wurden. Diese können zwar technisch verwendet werden und der Code ist lauffähig, allerdings besteht das Risiko, dass SAP derartige Objekte jederzeit ändern kann. Zur Verwendung von SAP Objekten in Eigenentwicklung sind die Ausführungen zu Clean Core in diesem Leitfaden zu beachten. Die Verwendung eines SAP Objekts, welches nicht sichtbar ist, sollte als technische Schuld dokumentiert werden bzw. entsprechend dem 3-Tier Modell behandelt werden.
Bei Verwendung von nicht sichtbaren Objekten aus anderen eigenen Paketen ist zu prüfen ob die Verwendung sinnvoll ist. Ist dies der Fall, dann ist das Objekt in einer Paketschnittstelle aufzunehmen. Andernfalls sollte eine Funktion entweder im eigenen Paket implementiert werden oder eine sichtbare vergleichbare Funktion in einem anderen Paket gefunden werden.
Derartige Funde können auch ein Hinweis sein, die unsichtbare Funktion in ein neues Paket zu verschieben, das ähnliche Funktionen bereits als Hilfsfunktionen enthält, oder ein neues Paket dafür zu erstellen.
Damit die Paketprüfung wie beschrieben funktioniert, müssen die Pakete gekapselt sein und die Systemeinstellung müssen gemäß Dokumentation entsprechend vorgenommen werden.

Paketkapselung und Paketschnittstellen von Unterpaketen innerhalb des Hauptpaketes

Das Kapseln der Hauptpakete dient der Dokumentation der Abhängigkeiten über die Paketprüfung. Die Kapselung ist allerdings auch für Unterpakete sinnvoll. Dazu sollte pro Unterpaket eine Paketschnittstelle angelegt werden und darin die Objekte aufgenommen werden, die von anderen Unterpaketen verwendet werden. Dementsprechend wird dann auch die Verwendungserklärung gepflegt. Dies bringt einen Verwaltungsaufwand bei der Erstellung einher, bringt aber den Vorteil mit sich, dass die Abhängigkeiten der Unterpakete dokumentiert sind und hier eine gezielte Steuerung und Überwachung möglich ist. Pro Hauptpaket muss eine klare Verwendungsbeziehung definiert sein und eine gemischte Wiederverwendung innerhalb der Unterpakete vermieden werden.
Gerade bei Sammlerpaketen kann es sinnvoll sein, bei entsprechender Größe, einzelne Pakete herauszulösen und als eigenständige Komponenten bereitzustellen. Dabei ist es hilfreich, hier bereits klare und geordnete Verwendungsbeziehungen zu haben.

Pakethierarchien

Mit den oben genannten Methoden und Werkzeugen kann eine gute Softwarearchitektur in SAP über die Pakete mit den Abhängigkeiten dargestellt werden. Die Überlegungen die für ein gutes Paketdesign angestellt werden müssen führen letztlich zu einer guten Anwendungsarchitektur, wenn die Designprinzipien für sauberer Architektur eingehalten werden. Hinweise zu Prinzipien moderner Softwarearchitektur finden Sie in einschlägiger Fachliteratur z.B. “Clean Architecture” von Robert C. Martin. Bei der Gestaltung der Pakete sollte auch immer der Blick auf die Entwicklungen paketübergreifend erfolgen und bei der Anlage neuer bzw. Erweiterung bestehender Pakete geprüft werden, inwieweit die Pakete zueinander passen und zu prüfen ob Eigenentwicklungen eigener Funktionen in verschiedene Pakete getrennt werden soll. Bei komplexeren Systemlandschaften kann es sinnvoll sein, Framework Pakete zu definieren, die Basisfunktionen anbieten, dann Grundfunktionspakete, die die Geschäftslogik abbilden und optionale Add-On Pakete zu erstellen, die unterschiedliche Oberflächentechnologien oder Ausprägungen der Funktionalitäten abbilden. Dadurch entsteht eine Hierarchie von Hauptpaketen, deren Abhängigkeiten über die Paketschnittstellen gut abgebildet und dokumentiert werden können. Wichtig ist hierbei zu achten, dass die Abhängigkeit immer nur in eine Richtung definiert sein darf.

Ein anderer Anwendungsfall wäre z.B. dieselbe Funktionalität für verschiedene Releases bereitzustellen, wobei die Kernfunktion in einem Paket und die Differenzierungen, die sich durch das Release (ERP / S/4HANA) ergeben, in unterschiedlichen Hauptpaketen implementiert sind.

Schulung der Entwickler

Wenn die Unternehmensinternen Richtlinien bezüglich des Paketkonzepts definiert sind und Strukturen vorhanden sind, ist es wichtig die Entwickler auch hinreichend bezüglich des umzusetzenden Paketkonzepts zu schulen und die Einhaltung und ordnungsgemäße Umsetzung zu prüfen. Insbesondere wenn externe Entwickler eingesetzt werden ist darauf zu achten, dass hier ein entsprechendes Onboarding erfolgt.
Die Aufgabe der Definition der Pakete und deren Strukturierung, sowie die Einordnung in die Paketlandschaft sollte durch den Lead-Developer oder Softwarearchitekt erfolgen um eine Konsistenz über Pakete hinweg sicherzustellen.

Vorteile und Nutzen durch Nutzung des Paketkonzeptes

Nach den hier beschriebenen Ausführungen wird deutlich, dass die Umsetzung des Paketkonzepts einiges an Überlegung und Aufwand bedarf. Dieser Aufwand zahlt sich aber durch zahlreiche Vorteile aus, die hier im Folgenden aufgeführt werden:

Eindeutig deklarierte Abhängigkeiten

Wie bereits beschrieben, sind die Abhängigkeiten von SAP-Paketen bzw. zwischen eigenentwickelten Paketen bei korrekter Umsetzung des Paketkonzepts klar ersichtlich. Entweder ist eine Abhängigkeit in der Verwendungserklärung aufgeführt, damit handelt es sich um bewusst definierte Abhängigkeit, oder die Abhängigkeit wird durch eine Fehlermeldung in der Paketprüfung ersichtlich, im Falle von nicht sichtbaren Objekten oder bei fehlender Verwendungserklärung. Die hieraus gewonnenen Informationen können für die Dokumentation und Beschreibung verwendet werden. Bevor ein Paket in ein System importiert wird, kann somit geprüft werden, ob im System die Voraussetzungen gegeben sind, das Paket fehlerfrei zu importieren, oder ob andere Pakete benötigt werden.

Bessere Übersicht und Erklärbarkeit

Bei komplexeren Entwicklungen hilft die Strukturierung schneller relevante Objekte zu finden. Die Struktur kann bereits als Teil der Dokumentation betrachtet werden. Stehen Korrekturen, Erweiterungen oder Ergänzungen einer Eigenentwicklung an, helfen eine gute Paketstruktur dem Entwickler sich schneller in der Anwendung zurecht zu finden und Erweiterungen umzusetzen.
Durch die Strukturüberlegungen ist die Software besser strukturiert und folgende Arbeiten können zielgerichteter durchgeführt werden. [#TODO]

Wir empfehlen, das Hauptpaket als kleinste zu transportierende Einheit zu verwenden:
1 Hauptpaket = 1 Transport.

Soll Software systemübergreifend transportiert werdem, sollte das Erstellen der Transporte auf Hauptpaketebene erfolgen. Ein Hauptpaket sollte eine Funktion bereitstellen, werden alle Objekte die sich innerhalb des Hauptpakets (in Unterpaketen enthalten) befinden in einen Transport aufgenommen und entsprechend deklarierte Voraussetzungen sind im Zielsystem erfüllt, ist der Transport über Systemlinien unproblematisch und ein Try-and-Error Transport packen und importieren bis kein RC8 auftritt wird nicht erforderlich sein. [Satzbau??]

Flexibilität

Ist eine Softwarekomponente gut strukturiert, lassen sich Ergänzungen, Änderungen, Erweiterungen und Korrekturen besser durchführen als in dem Fall wenn eine Anwendung sich aus lose zusammengestellten und in einem großen ungeordneten Paket befindlichen Objekten besteht, in dem andere Objekte für andere Funktionen enthalten sind. Somit ergibt sich bei guter Strukturierung auch eine erhöhte Flexibilität. Insbesondere wenn Funktionalitäten im Laufe des Lebenszyklus wachsen und der Umfang wächst, kann es erforderlich sein, die Struktur anzupassen und ggf. Funktionalitäten in globalere Pakete auszulagern um Wiederverwendbarkeit zu erlangen oder im umgekehrten Fall, mehrere kleinere Anwendungen in ein Hauptpaket zusammenzufassen.

Zukunftsfähigkeit

Die Erstellung von Software in gut strukturierten Paketen beinhaltet neben den offensichtlichen Vorteilen auch weitere Vorteile, die nicht sofort wirksam werden, im Rahmen des Softwarelebenszyklus aber durchaus relevant werden können.
Sind die Eigenentwicklungen im System bereits in Paketen geordnet, sind schon wichtige Voraussetzungen erfüllt, um moderne Versionsverwaltungssysteme wie ABAPGIT oder gCTS zu nutzen, die Pakete bedingen. Somit sind dann Transporte mittels git-basierter Methoden in andere System über oder gar in die Cloud möglich s. Versionsverwaltung.

Weitere Aspekte

Wir haben hier grundlegende Aspekte der Nutzung des Paketkonzepts beschrieben, die Ihnen helfen sollen, die Vorteile gut strukturierter Pakete zu erkennen, aber auch sehr konkret Hilfestellung gegeben, wie ein Paketkonzept praxisorientiert umgesetzt werden kann.
Dies ist nur der Anfang und es gibt einige Aspekte auf die in dieser Version nicht eingegangen werden kann, da dies den Umfang des Leitfadens übersteigen würde. Folgende Aspekte sind relevant und sollten im Unternehmen definiert und in den Handbüchern beschrieben werden:

Vermeidung statischer Abhängigkeiten - verschiedene Lösungsansätze (Definition BAdIs / Aufrufe über Funktionsbausteine)
Größe von Paketen - Architektonische Grenzen - Abgrenzung - Kosten (Clean Architecture)
Paket Refactoring - Splitting - Kombination einzelner Pakete - Kontinuierliche Paketpflege bei Änderungen und Erweiterungen
Gründe für die Umsetzung des Paketkonzepts auch in einfachen Systemlandschaften mit einem Entwicklungssystem

Wenn Sie Interesse an diesen Themen haben, erstellen Sie Issues in unserem Github oder melden Sie sich an die DSAG, damit dies bei der Überarbeitung des Leitfadens berücksichtigt werden kann.

Von der Architektur zum Design

Nachdem mit den hier genannten Ausführungen die Voraussetzung für eine gute Architektur geschaffen wurden, die sich in der Paketstruktur wiederfindet, muss nun anschließend in den einzelnen Unterpaketen die Anwendungsarchitektur in konkreter Form von Klassen definiert/designed werden. Die Ausführungen hierzu finden Sie im folgenden Abschnitt: Design von ABAP Anwendungen mit OO.

          {: .no_toc} # Design und Erstellung von SAP-Anwendungen

Moderne Geschäftsanwendungen erfordern moderne Softwareentwicklungsmethoden

Geschäftsanwendungen in der klassischen ABAP Entwicklung wurden oft mit Reports erstellt, die durch komplexe, prozedurale Kontrollstrukturen geprägt waren. Modularisierung erfolgte mittels Form-Routinen oder für Wiederverwendung mit Funktionsbausteinen. Bei guter Planung waren Funktionsgruppen nicht überladen, sondern bestanden aus zusammengehörigen spezifischen Funktionen. Vielleicht kennen Sie aber auch die eine oder andere Funktionsgruppe, die zahlreiche Funktionsbausteine mit unterschiedlichen Aufgaben enthält und beim einen oder anderen Transport auch mal das eine oder andere Problem verursacht hat.
Mit der Anzahl der vorgenommenen Änderungen wurden diese Anwendung immer komplexer, fehleranfälliger und immer schwerer zu warten.

Die moderne ABAP-Entwicklungswelt ist ungleich komplexer und heterogener geworden als sie es zu früheren R/3 Zeiten war. An moderne Anwendungen werden heute hohe Anforderungen gestellt.

Anwendungen müssen die Anforderungen bestens erfüllen.
Anwendungen müssen fehlerfrei, robust, performant und fehlertolerant betrieben werden können.
Änderungen sollen schnell, effizient, fehlerfrei und mit wenig Testaufwand durchführbar sein und keine neuen Fehler erzeugen.

Somit müssen auch Anforderungen an den ABAP-Code gestellt werden.

ABAP-Code muss die funktionalen Anforderungen korrekt erfüllen und hat keine negativen Auswirkungen auf Sicherheitsthemen oder andere Entwicklungen.
ABAP-Code soll fachlich präzise strukturiert sein. Er wird in kleinen, semantisch zusammenpassenden und modularen Einheiten entwickelt. Diese Einheiten sind gut lesbar und für andere Entwickler leicht verständlich. Externe Zugriffe und modulübergreifende Abhängigkeiten sind über klar definierte Schnittstellen geregelt.
ABAP-Code soll moderne Programmiertechniken verwenden. Er enthält keine veralteten oder nicht unterstützten Anweisungen.

Mit langen, tief verschachtelten und eng verwobenen Modularisationseinheiten wie Reports, Forms und Funktionsbausteinen sind diese Anforderungen nur schwer zu erfüllen, da diese eine hohe Abwärtskompabilität aufweisen und vieles möglich ist, was mit ABAP-OO bereits technisch geprüft oder teilweise sogar verhindert wird.

Schon seit vielen Jahren gibt es in ABAP die Möglichkeit objektorientiert zu programmieren. Auch wenn dies anfangs noch nicht erforderlich war, ist es heute einerseits technisch notwendig, wenn neue Möglichkeiten genutzt werden sollen, andererseits bietet die Methodik der Objektorientierung sehr viele gute Ansätze Geschäftsanwendung so zu entwickeln, dass sie flexibel, wartbar, erweiterbar und robust umgesetzt werden können. Und durch die Nutzung von ABAP-Unit und eines guten Designs, können zahlreiche Tests bereits als UNIT Tests abgedeckt werden womit das Testen durch den Endanwender auf die Testung des Prozesses und der Funktion reduziert werden kann.

Und obwohl die oben genannten Nachteile der prozeduralen und Vorteile der Objektorientierten Programmierung bekannt sind, werden auch in aktuellen Projekten weiterhin Funktionalitäten nicht objektorientiert umgesetzt bzw. nicht das volle Potenzial moderner Entwicklungsmethoden genutzt. Dies können z.B. Programme sein, die prozedural implementiert werden, Klassen die objektorientierte Prinzipien nicht umsetzen oder Implementierung von Funktionsbausteinen oder direkte Implementierung von komplexen Code in BAdI-Implementierung direkt ohne weitere Strukturierung.

Empfehlungen

Fordern Sie bei allen Entwicklungen die Umsetzung in ABAP Objects unter Einsatz objektorientierter Methoden ein

Achten Sie auf die Anwendung der SOLID Prinzipien der Objektorientierung

Wenden Sie beim Anwendungsdesign die gängigen objektorientierten Designpatterns an.

Trennen Sie die unterschiedlichen Belange der Geschäftsanwendungen in Klassen auf (z.B. Controller Klasse, Datenzugriff, Geschäftslogiken, Prüfungen etc.)

Halten Sie die Schnittstellen klein und nutzen Sie die Factory für Übergabe wichtiger Daten an das Objekt

Verschalen und konzentrieren Sie Aufrufe von SAP-Code bzw. Paketfremden Code in eigenen privaten Methoden.

Verwenden Sie klassenbasierte Ausnahmen für das komplette Fehlerhandling inklusive Nachrichtenabwicklung in der Anwendung

Die detaillierte Erläuterung der Objektorientierung und die zahlreichen Möglichkeiten des modernen ABAP können wir in diesem Leitfaden nicht umfänglich abhandeln, möchten Ihnen aber bezüglich des Vorgehens Empfehlungen, Hinweise und Hilfen geben, die den Einstieg erleichtern und einen Überblick über Handlungsfelder geben, die schnell zu Verbesserungen führen können.

Grundlagen und einfache Anwendung von Objektorientierung im ABAP Kontext

Das Thema Objektorientierung ist komplex und viele existierende Funktionalitäten in SAP folgen nicht den Designprinzipien der Objektorientierung, auch dann nicht wenn diese in ABAP-Klassen implementiert sind. Für dieses Kapitel sollten die Grundprinzipien der Objektorientierung bereits bekannt sein.
Die Hinweise und Tipps erfolgen hier in sehr vereinfachter Form. Es soll ein Vorgehen aufzeigen um die Objektorientierung nutzbringend anzuwenden und unsere Empfehlungen praxisorientiert untermauern.
Dies ist ein Anfang und kann helfen das Verständnis für ABAP-OO in den Entwicklerteams zu schaffen, erste Erfolgserlebnisse zu erzielen und mittels weitere Unterstützung durch Trainings, Dokumentation und Literatur und Coachings das Thema nachhaltig in der Organisation gewinnbringend zu nutzen.

Merkmale Objektorientierter Entwicklung in ABAP-Klassen

Eine Klasse bildet eine spezielle (Teil-)Aufgabe ab, die in überschaubaren Methoden implementiert wird.
Eine ABAP-Klasse besteht aus Attributen, die Werte speichern können oder Konstanten sein können.
Es es gibt Methoden, die Funktionen implementieren und in Public, Protected und Private Methoden unterteilt sind. Man kann auch Klassenspezifische Typen definieren, die in der Klasse aber auch von Aufrufern verwendet werden können (wenn in Public Section definiert).
Darüber hinaus definieren Klassen weitergehende Eigenschaften wie Paketzugehörigkeit und die Art der Instanziierbarkeit und ggf. Vererbungsinformationen.
Oft werden ABAP-Klassen als eine moderne Form von Funktionsbausteinen betrachtet, dieser Vergleich wird den Möglichkeiten einer Klasse nicht gerecht. Der entscheidende Unterschied ist die Instanziierbarkeit, d.h. es können für Klassen mehrere Objekte im gleichen Programmkontext erzeugt werden.

Bei einer Klasse, die nur statische Methoden beinhaltet und in der Verwendung nicht instanziiert wird, handelt es sich somit nicht um eine Klasse die objektorientierten Prinzipien folgt.

Klassen sollten eher übersichtlich gestaltet werden und Methoden mit einer Länge von bis max ~150 Zeilen besitzen. Ebenso sollten die Klassen nicht zu viele Methoden besitzen. Die Größenbeschränkung zwingt dazu, Aufgaben in verschiedene Klassen zu delegieren. Damit sind die einzelnen Klassen weniger Komplex, die Komplexität verschiebt sich damit je nach Anwendung in das Klassengeflecht und dem Zusammenspiel der einzelnen Klassen. Dieses Zusammenspiel und die übergeordnete Logik wird in einem Controller gebündelt.
Um hier nicht einfach eine Komplexitätsverschiebung zu erhalten, bedarf es guter Überlegung und eines entsprechenden Paketdesigns und guter Grobplanung der Anwendung. Dass während der Entwicklung Methoden und Attribute verschoben und umbenannt werden und Objekte umstrukturiert = Refactored werden, gehört zum Softwareentwicklungsprozess dazu und ist Dank moderner Softwareentwicklungswerkzeuge in den ABAP-Development Tools in Eclipse und zusätzlichen AddOns einfach und sicher durchzuführen.

Weitere Erkennnungsmerkmale einer Klasse, die objektorientierten Prinzipien folgt sind:

Größe der Klasse - ein zu große Klasse zeigt vermutlich auf dass das Single Responsibility Prinzip verletzt wurde
Größe der Methoden - zu große Methoden weisen auf Strukturdefizite und redundanten Code hin. Die maximale Zielgröße liegt bei ca. 150 Zeilen.
Umfangreiche Parameterschnittstellen - Objekte arbeiten mit Objekten und nicht mit Parametern, dies geht meistens mit zu großen Methoden einher
…. any other - to be discussed. - check Clean Core Kapitel bzw. clean ABAP Styleguide

Grundprinzipien der Objektorientierung (SOLID)

Beim Einstieg in ABAP Objects geschieht es schnell, dass aus einer Funktionsgruppe mit mehreren Funktionsbausteinen einfach eine Klasse mit mehreren statischen Methoden wird. So können jedoch die Vorteile der Objektorientierung nicht genutzt werden. Die Nutzung von statischen Methoden verhindert etwa, dass Abhängigkeiten in Unit Tests durch Mocks ersetzt werden können. Mehr Informationen dazu im Clean ABAP-Guide.

Ein Hilfsmittel für objektorientierte Entwürfe sind die SOLID-Prinzipien. Jeder Buchstabe gibt ein Prinzip für objektorientierte Entwicklung vor. Hier geben wir nur eine kurze Übersicht der Prinzipien, eine ausführliche Erklärung findet sich z.B. im Blog von Uncle Bob, dem Autor von Clean Code.

Single Responsibility Principle: Eine Codeeinheit (Klasse, Methode, ...) sollte immer einen Zweck und damit einen Grund für Anpassungen haben. Eine Methode, die etwa Customizing-Einträge liest, anhand derer Daten aufbereitet, und anschließend ein Formular ausgibt, hat drei Zwecke und auch mögliche Gründe für Anpassungen (nämlich immer, wenn sich etwas an Customizing/Daten/Formular) ändern soll. Diese Methode sollte also aufgeteilt werden.
Open/Closed Principle: Ein Modul sollte offen für Erweiterungen und geschlossen für Veränderungen sein. Das heißt, das Anpassungen vorgenommen werden können, ohne dazu z.B. die ursprünglich genutzte Klasse zu bearbeiten. Eine Klasse `Drucker`, die etwa im Konstruktor die zu druckenden Daten beschafft, kann ohne Anpassung des ursprünglichen Codes nichts anderes drucken. Bekommt diese Klasse hingegen eine Instanz des Interfaces `Datenbeschaffung` im Konstruktor übergeben und ruft passende Methoden dieser auf, kann zur Anpassung einfach eine zweite Datenbeschaffungsklasse entwickelt werden.
Liskov Substitution Principle: Code, der mit einer Klasse oder einem Interface arbeitet, sollte immer mit implementierenden oder erbenden Klassen funktionieren. Eine erbende Klasse sollte also beispielsweise nicht in einer der implementierten Methoden eine unerwartete Exception werfen und somit einen Dump auslösen.
Interface Segregation Principle: Interfaces sollten so aufgeteilt sein, dass Nutzer nur notwendige Abhängigkeiten erhalten. Eine Datenbankzugriffsklasse, die in einer Anwendung verwendete Daten lesen und schreiben kann, könnte etwa ein Interface `Datenleser` und ein Interface `Datenschreiber` implementieren, so dass nur lesende Nutzer keine Abhängigkeit zu schreibenden Methoden haben.
Dependency Inversion Principle: Abhängigkeiten wie z.B. die Instanz einer Klasse, die das Interface `Datenbeschaffung` implementiert, sollten nicht durch eine verwendende Klasse `Anzeiger` erzeugt werden, sondern dieser stattdessen im Konstruktor oder einer Methode übergeben werden. So kann für den Test von `Anzeiger` einfach eine andere Implementierung für die Datenbeschaffung übergeben werden.

Entwurfsmuster

In der Objektorientierung gibt es zahlreiche Entwurfsmuster (Design Pattern), die für verschiedene Problemstellungen und Anwendungsfälle bereits vorgefertigte und erprobte softwaretechnische Mechanismen bieten, die auch in ABAP umgesetzt werden können. So sind in ABAP folgende Pattern direkt und sinnvoll anwendbar, diese werden im folgenden näher erläutert:

Singleton
Factory
Facade
MVC (Model-View-Controller)

Singleton-Pattern

Das Singleton-Pattern zielt darauf ab, dass zu einer Klasse nur eine einzige Objektinstanz zur Laufzeit existiert bzw. existieren kann. Dazu wird die erste durch den Konstruktor erzeugte Instanz in eine Klassenvariable (CLASS-DATA) geschrieben und bei den folgenden Aufrufen des Klassenkonstruktors zur Erzeugung eines neuen Objektes wird ebendiese gespeicherte Instanz aus der Klassenvariable gelesen und zurückgegeben. So kann man kontrollieren, dass zu jeder Zeit nur eine Instanz einer Klasse existiert. Hier ein Beispiel, wie dies umgesetzt werden könnte:

CLASS zcl_singleton DEFINITION.
  PUBLIC SECTION.
    CLASS-METHODS:
      get_instance RETURNING VALUE(ro_instance) TYPE REF TO zcl_singleton.
    METHODS:
      do_something.
  PRIVATE SECTION.
    CLASS-DATA:
      mo_instance TYPE REF TO zcl_singleton.
    METHODS:
      constructor.
ENDCLASS.

CLASS zcl_singleton IMPLEMENTATION.
  METHOD constructor.
    " Konstruktor ist privat, um direkte Instanziierung zu verhindern
  ENDMETHOD.
  METHOD get_instance.
    IF mo_instance IS INITIAL.
      CREATE OBJECT mo_instance.
    ENDIF.
    ro_instance = mo_instance.
  ENDMETHOD.
  METHOD do_something.
    WRITE: / 'Singleton-Methode wurde aufgerufen'.
  ENDMETHOD.
ENDCLASS.

* Verwendung
DATA(lo_singleton) = zcl_singleton=>get_instance( ).
lo_singleton->do_something( ).

Factory-Pattern

Das Factory-Pattern ist ein Entwurfsmuster, das die Erstellung von Objekten kapselt. In ABAP wird es häufig verwendet, um die Instanziierung von Objekten zu zentralisieren und zu vereinfachen – besonders bei polymorphen Objekten oder wenn die Erzeugung komplex ist. Das Pattern bietet mehrere Vorteile: Änderungen an der Erzeugungslogik müssen nur an einer Stelle erfolgen, die Rückgabe eines Interfaces oder einer abstrakten Klasse (Polymorphismus) ist möglich und neue Typen können leicht ergänzt werden. Dies könnte beispielhaft folgendermaßen umgesetzt werden:

* Abstrakte Basisklasse oder Interface
INTERFACE lif_vehicle.
  METHODS drive.
ENDINTERFACE.

* Konkrete Implementierungen
CLASS zcl_car DEFINITION.
  PUBLIC SECTION.
    INTERFACES lif_vehicle.
ENDCLASS.

CLASS zcl_car IMPLEMENTATION.
  METHOD lif_vehicle~drive.
    WRITE: / 'Das Auto fährt los!'.
  ENDMETHOD.
ENDCLASS.

CLASS zcl_bike DEFINITION.
  PUBLIC SECTION.
    INTERFACES lif_vehicle.
ENDCLASS.

CLASS zcl_bike IMPLEMENTATION.
  METHOD lif_vehicle~drive.
    WRITE: / 'Das Fahrrad fährt los!'.
  ENDMETHOD.
ENDCLASS.

* Factory-Klasse
CLASS zcl_vehicle_factory DEFINITION.
  PUBLIC SECTION.
    CLASS-METHODS:
      create_vehicle
        IMPORTING iv_type TYPE string
        RETURNING VALUE(ro_vehicle) TYPE REF TO lif_vehicle.
ENDCLASS.

CLASS zcl_vehicle_factory IMPLEMENTATION.
  METHOD create_vehicle.
    CASE iv_type.
      WHEN 'CAR'.
        CREATE OBJECT ro_vehicle TYPE zcl_car.
      WHEN 'BIKE'.
        CREATE OBJECT ro_vehicle TYPE zcl_bike.
      WHEN OTHERS.
        ro_vehicle = NULL.
    ENDCASE.
  ENDMETHOD.
ENDCLASS.

* Verwendung
DATA(lo_vehicle) = zcl_vehicle_factory=>create_vehicle( iv_type = 'CAR' ).
IF lo_vehicle IS BOUND.
  lo_vehicle->drive( ).
ENDIF.

Facade-Pattern

Das Facade-Pattern wird in ABAP verwendet, um eine vereinfachte Schnittstelle zu einem komplexen Subsystem bereitzustellen. Es kapselt die Komplexität mehrerer Klassen oder Prozesse hinter einer einzigen, leicht zu verwendenden Klasse – der „Fassade“. Dies bietet folgende Vorteile: Der Aufrufer muss sich nicht mit Details der Subsysteme beschäftigen, Änderungen in den Subsystemen wirken ich nicht direkt auf den Aufrufe aus und die Fassade kann in verschiedenen Kontexten wiederverwendet werden. Dies könnte beispielhaft folgendermaßen umgesetzt werden:

* Subsystem-Klassen
CLASS zcl_order_processor DEFINITION.
  PUBLIC SECTION.
    METHODS process_order.
ENDCLASS.

CLASS zcl_order_processor IMPLEMENTATION.
  METHOD process_order.
    WRITE: / 'Bestellung verarbeitet'.
  ENDMETHOD.
ENDCLASS.

CLASS zcl_invoice_generator DEFINITION.
  PUBLIC SECTION.
    METHODS generate_invoice.
ENDCLASS.

CLASS zcl_invoice_generator IMPLEMENTATION.
  METHOD generate_invoice.
    WRITE: / 'Rechnung erstellt'.
  ENDMETHOD.
ENDCLASS.

CLASS zcl_shipping_service DEFINITION.
  PUBLIC SECTION.
    METHODS ship_order.
ENDCLASS.

CLASS zcl_shipping_service IMPLEMENTATION.
  METHOD ship_order.
    WRITE: / 'Versand durchgeführt'.
  ENDMETHOD.
ENDCLASS.

* Facade-Klasse
CLASS zcl_order_facade DEFINITION.
  PUBLIC SECTION.
    METHODS complete_order_process.
ENDCLASS.

CLASS zcl_order_facade IMPLEMENTATION.
  METHOD complete_order_process.
    DATA(lo_processor) = NEW zcl_order_processor( ).
    DATA(lo_invoice)   = NEW zcl_invoice_generator( ).
    DATA(lo_shipping)  = NEW zcl_shipping_service( ).

    lo_processor->process_order( ).
    lo_invoice->generate_invoice( ).
    lo_shipping->ship_order( ).
  ENDMETHOD.
ENDCLASS.

* Verwendung
DATA(lo_facade) = NEW zcl_order_facade( ).
lo_facade->complete_order_process( ).

MVC-Pattern

Das MVC-Pattern wird verwendet, um die Programmierlogik in die 3 Bereiche Model (Datenmodell), View (Präsentationslogik) und Controller (Businesslogik) zu unterteilen. Das Model-View-Controller (MVC) Pattern ist ein bewährtes Architekturmodell, das auch in ABAP – insbesondere im Kontext von SAP Web Dynpro, SAPUI5 oder klassischen Dynpros – eingesetzt werden kann. Es trennt die Anwendung in die drei Hauptkomponenten “Model” (Geschäftslogik und Datenzugriff), “View” (Darstellung der Daten / UI) und “Controller” (Vermittlung zwischen Model und View). Der Einsatz von MVC bietet folgende Vorteile: Bessere Wartbarkeit und Testbarkeit aufgrund der Trennung von Anliegen (“Separation of concerns”), Wiederverwendbarkeit von Views und Models, Skalierbarkeit für komplexe Anwendungen (z.B. SAPUI5, Web Dynpro).

* Model Klasse
CLASS zcl_model DEFINITION.
  PUBLIC SECTION.
    METHODS:
      get_customer_name IMPORTING iv_id TYPE i RETURNING VALUE(rv_name) TYPE string.
ENDCLASS.

CLASS zcl_model IMPLEMENTATION.
  METHOD get_customer_name.
    CASE iv_id.
      WHEN 1. rv_name = 'Max Mustermann'.
      WHEN 2. rv_name = 'Erika Musterfrau'.
      WHEN OTHERS. rv_name = 'Unbekannt'.
    ENDCASE.
  ENDMETHOD.
ENDCLASS.

* View Klasse
CLASS zcl_view DEFINITION.
  PUBLIC SECTION.
    METHODS:
      display_customer_name IMPORTING iv_name TYPE string.
ENDCLASS.

CLASS zcl_view IMPLEMENTATION.
  METHOD display_customer_name.
    WRITE: / 'Kundenname:', iv_name.  "hier könnte auch eine ALV-Ausgabe o.ä. stehen
  ENDMETHOD.
ENDCLASS.

* Controller Klasse
CLASS zcl_controller DEFINITION.
  PUBLIC SECTION.
    METHODS:
      show_customer IMPORTING iv_id TYPE i.
  PRIVATE SECTION.
    DATA:
      mo_model TYPE REF TO zcl_model,
      mo_view  TYPE REF TO zcl_view.
ENDCLASS.

CLASS zcl_controller IMPLEMENTATION.
  METHOD show_customer.
    CREATE OBJECT mo_model.
    CREATE OBJECT mo_view.

    DATA(lv_name) = mo_model->get_customer_name( iv_id ).
    mo_view->display_customer_name( lv_name ).
  ENDMETHOD.
ENDCLASS.

Auch hier können wir leider nicht im Detail auf alle Entwurfsmuster eingehen, im Internet und der Fachliteratur finden sie zahlreiche Möglichkeiten, sich dem Thema anzunähern und in die Organisation zu bringen. Ein guter Startpunkt für die eigene Recherche ist z.B. ABAP-OO Design Patterns m. Beispielen.

Vergleich Vorgehen prozedurale vs. objektorientierter Entwicklung

Ablauf Prozedurale Entwicklung

Beim Umsetzen einer Anforderung z.B. in einem Report oder eines Funktionbausteins würde das Design gemäß der Spezifikation klassischerweise wie folgt sich gestalten:

Übernahme der Eingangsdaten aus Import Parametern
Lesen des Customizings aus der Datenbank (z.B. Z-Tabelle)
Lesen der Daten aus den Datenbanktabellen
Verarbeiten der Daten mit Loops, Read Tables und diversen IF-Endif Kontrollstrukturen: z.B. Prüfen, Berechnen, sortieren, abmischen …
Übergabe des Ergebnisses and Export Parameter Damit wird die Anforderung in imperativer Form in Programmcode dargestellt, ggf. werden Teilfunktionen modularisiert.

Ablauf bei Objektorientiertem Ansatz

Wenn die Anforderungen bekannt sind und analysiert wurden, sind zuerst die unterschiedlichen Aufgaben zu definieren und zu gruppieren. Anhand der Aufgaben können die Klassen und abgeleiteten sinnvollen Klassennamen definiert werden. Basierend auf diesem Vorgehen kann die OO Implementierung wie folgt aussehen:

Definition Objekt zum Lesen und Auswerten des Customizings auf Basis Organisationsdaten = Customizing Objekt
Definition Objekt zum Lesen der Datenbank, ggf. je nach Komplexität Aufteilung nach Geschäftsobjekt = Datenobjekt(e).
Definition Objekt welches die Datenprüfungen und Validierungen durchführt = Check Objekt
Definition Objekt welches die Datenprozessierung durchführt und für die Erstellung des Ergebnisses zuständig ist Geschäftslogik.
Definition Objekt welches die Geschäftsfunktionalität abbildet und das Zusammenwirken der einzelnen Objekte orchestriert und verwaltet = Controller.
Erstellung einer Factory Klasse, die die einzelnen Objektinstanzen erzeugt.
Definition einer Injektorklasse, mittels der das Mocking einzelner Funktionen ermöglicht wird.

Die Details zum ABAP UNIT und wie man Unit Tests erstellt finden Sie im Kapitel Testing)

Konzepte in der Objektorientierung

Neben den Grundlagen, gibt es weitere Konzepte und Techniken, durch deren Einsatz erst der volle Mehrwert der Objektorientierung zum Einsatz kommt und auch komplexe Problemstellungen elegant gelöst werden können, was mit klassischen Technologien deutlich aufwändiger oder gar nicht möglich war. Auch hier können wir in der ersten Version des neuen Leitfadens nur in sehr kurzer Form hinweisen. In der ABAP Dokumentation und in Trainings und Büchern finden Sie weitere Informationen.

Erstellung eines Konstruktors pro Klasse

Jedes Objekt sollte eine Factory methode haben und die Übergabe nötiger parameter erfolgt über den Konstruktur in die Klasse. Erfolgt die Instanziierung der Klassen der Anwendung über eine zentrale Factory, wird die Factory Methode der Klasse in der Factory Klasse gerufen.

Beispiel: Verschalung des Customizing in der Factory-Methode (s.Issue #117 - Klärung Pattern)

Die Customizing Klasse kann nun so gestaltet werden, dass in der Factory Methode die Customizing Tabelle geprüft wird, in der die Steuerung der Funktion hinterlegt ist. Nur wenn sich ein Eintrag in dieser Tabelle zu den Parametern der Factory-Methode (z.B. Werk oder Buchungskreis etc.) befindet, wird eine Instanz an den Aufrufer übergeben. Falls kein Eintrag oder ein Problem vorliegt, sollte eine Ausnahme ausgelöst werden, die vom Aufrufer abgefangen wird. Somit muss der Aufrufer nicht mehr die Prüfung der Tabelle übernehmen, sondern die Instanz ist nur dann vorhanden, wenn die Funktion auch aktiv ist. Im Positivfall können dann über die zurückgegebene Instanz die entsprechenden Methoden aufgerufen werden.
Damit vereinfacht sich der Code der Geschäftslogik und die Komplexität des Customizing wird verschalt bzw. automatisiert. Einzelne Parameter des Customizings können in Attributen der Customizing Klasse vorgehalten werden und mittels sog. Getter-Methoden bei Bedarf in anderen zugehörigen Klassen abgefragt werden.
Da dem Objektkonstrukt mittels der Factory die Customizing Instanz bekannt ist und bei Bedarf diese in anderen Objekten als Attribut abgelegt werden kann, ist der Zugriff auf das Customizing standardisiert im gesamten Konstrukt ohne redundanten Code möglich.
Dies bedeutet einen initialen Erstellungsaufwand, der sich aber bei Änderungen und Ergänzungen auszahlt, da auf vorhandene Services effizient und aufwandslos zugegriffen werden kann und fehleranfällige Coderedundanzen nicht mehr erforderlich sind.

Die Erstellung der zahlreichen Objekte erscheint deutlich aufwändiger als der Top-Down Ansatz beim prozeduralen Vorgehen. Man gewinnt hier aber durch die Aufteilung der Funktionen gemäß der Verantwortlichkeiten eine deutlich höhere Flexibilität und Robustheit und durch die Mechanismen eine Form der Automatisierung.
Ist dieses Muster erst einmal eingeübt, übertreffen die Vorteile dieses Verfahrens den Nachtteil des vermeintlich erhöhten initialen Aufwands bei weitem.

Die Effizienz kann ergibt sich allerdings nur durch den Einsatz der ABAP Development Tools in Eclipse (ADT). Mittels Autovervollständigung, Nutzung von Code Templates und Quickfixes kann viel Code sehr schnell und einfach erstellt werden, wodurch sich der Mehraufwand sehr in Grenzen hält.
Natürlich muss dass Vorgehen auch eingeübt werden um eine gewisse Entwicklungsperformanz und -effizienz zu entwickeln.
Bitte beachten Sie hierzu den ADT-Leitfaden der DSAG, der Sie unterstützt, ADT effizient und flächendeckend im Unternehmen einzusetzen.

Vollständiger Einsatz von klasssenbasierten Ausnahmen zur Fehlerbehandlung.

Verwenden Sie für die Behandlung von Fehlern ausschließlich klassenbasierte Ausnahmen. Diese sollen auch nur für den Fall von Fehlern eingesetzt werden und nicht für Erfolgs- oder Statusmeldungen aus der Anwendung missbraucht werden. Lediglich technische Einschränkungen von Seiten SAP zwingen Sie an einigen wenigen Stellen dazu klassische Exceptions einzusetzen.
Von der Verwendung von Returncodes raten wir ihnen ebenso ab wie von der alleinigen Rückgabe von Message Tabellen wie z.B. BAPIRET2, wie Sie dies z.B. in BAPI-Funktionsbausteinen oft vorfinden. diese Konzepte erzeugen das Problem, dass im aufrufenden Programm innerhalb des Ablaufs der Geschäftslogik geprüft werden muss, ob ein Fehlerfall vorliegt und somit eine saubere Trennung von technischen Belangen und Geschäftslogik nicht gegeben ist. Der Einsatz von Ausnahmeklassen ermöglicht hier eine deutlich bessere Trennung, Des Weiteren können Sie die Fehlerbehandlung aufgrund der Propagierung von Ausnahmen an zentralen Stellen bündeln. Bitte beachtens Sie hierzu auch die Empfehlungen des Clean-ABAP Styleguide

Ein in ABAP-OO geübter Entwickler definiert in der Konzeptionsphase die auftretenden Fehlersituationen, die in einem (Unter)Paket auftreten können und erstellt darauf basierend die entsprechenden Ausnahmeklassen mit den Fehlermeldungen (als Text-ID oder Nachrichtenbasiert). Wenn der Code der Geschäftslogik implementiert wird und die Fehler behandelt werden müssen, wird an der betreffenden Stelle die Exception aufgerufen. Die Behandlung muss nun nicht wie bei Funktionsbausteinen in jeweils jeder Aufrufschicht erfolgen, sondern kann zentral an einer Stelle erfolgen. Dies gewährleistet eine konsistente Behandlung und vermindert den Aufwand wenn Fehler an mehreren Stellen auftreten können.

Interfaces

Durch den Einsatz von Interfaces wird die Definition von Methoden und deren Implementierung voneinander entkoppelt. Wird ein Interface verwendet, kann die Implementierung der Klasse geändert, bzw. flexibilisiert werden. Das Interface definiert sozusagen den Vertrag zwischen Verwender und implementierender Klasse. Interfaces werden bei UNIT-Tests benötigt, da z.B. Datenbankzugriffe in Unit Tests durch programmierte Testdaten ersetzt werden müssen. Die Datenbankklasse implementiert ein Interface, das im Produktcode aufgerufen wird. Wird der Unit-Test ausgeführt, wird statt der Datenbankklasse, eine sog. Mockingklasse aufgerufen, die statisch hinterlegte Daten beinhaltet und zurückliefert oder Das OSQL Framework nutzt um die Datenbankabfragen im Test zu simulieren.
Die Ausführungen dazu finden Sie im Kapitel Testing.

An @ABAP-Pete25 von @TimoJohn “ ich würde gerne noch dazu schreiben das grundsätzlich immer Iinterfaces zu verwenden sind für die Lose Kopplung. Das Unit Test das nutzen ist gut. Klingt hier aber so als würde man dies nur für unit test machen. Und dann kommen wieder Leute auf creative Gründe “ich brauche das nicht weil …” Vorschlag:

Sie sollten grundsätzlich Methoden die Funktionen für andere Klassen bereitstellen in Interfaces defineren und dafür sorgen, dass die Verwender nur mit diesen Intetrfaces Arbeiten. Das Erzeugen von konkreten Obkjekten über nimmt eine separate Factory Klasse oder in besonders einfachen Fällen eine Factory Methode der Klasse. ZCL_BUSINESS_LOGIC=>GET_INSTANCE( ConpanyCode )

Siehe

Vererbung

Ein wichtiges Konzept in der Objektorientierung ist die Vererbung. Dabei kann eine Klasse von einer anderen Klasse abgeleitet werden und somit die Eigenschaften der übergeordneten Klasse erben. So hat eine erbende Klasse die Attribute und Methoden der übergeordneten Klasse, kann aber weitere spezifische Methoden ergänzen oder ererbte Methoden redefinieren, d.h. eine Ergänzung der vererbten Implementierung oder gar eine eigene Implementierung der Methode erhalten.
Bei der Vererbung ist das Liskovsche Substitutionsprinzip zu beachten und genau zu prüfen, ob im vorgesehenen Kontext Vererbung Sinn macht. Oft ist es besser statt Vererbung Interfaces zu verwenden oder die Methode der Delegation zu verwenden und verschiedene Aspekte einer Klasse auf verschiedene Klassen zu verteilen und das Zusammenspiel über einen Controller und die Instanzen über eine Factory zu regeln.

Objektorientierung in Funktionsbausteinen und Form Routinen

Manchmal ist es erforderlich, dass Funktionalitäten in vorgegebenen Artefakten umgesetzt werden müssen. Z.B. Funktionsbausteine in AIF, Remote Funktionsbausteine, Form Interface Routinen bei Adobe Forms usw. In diesem Fall dienen diese Entwicklungsobjekte als Verschalung und rufen die eigentliche Funktionalität nur auf, die dann in ABAP-Klassen und deren Methoden implementiert ist. Der Code in diesen Entwicklungsobjekten sollte sich nur auf technisches Coding beschränken wie z.B. Datenzuordnungen, Objektinstanziierung oder minimale Prüfungen. Dies bietet wiederum den Vorteil von möglicher Wiederverwendung und Implementierung von Unit Test.

Verwendung von SAP Code

Die Verwendung von SAP-Code (CDS Views, Klassen, Funktionsbausteinen, BAPIs, etc.) oder auch paketfremder Code, sollte immer in einer eigenen Zugriffsschicht liegen. Dies entspricht dann auch einer sauberen Trennung der Belange (S - Separation of Concerns). Der Einsatz von ABAP Cloud forciert dies durch das 3-Tier Konzept ebenso s. Kapitel Clean Core.
Auch wenn es sich um freigegebene Elemente handelt, sollten diese stets mit einer Klasse gekapselt werden, damit es nur einen Ort des Übergangs von Eigen- an Fremdcode gibt. Erstellen Sie Klassen, deren Aufgabe es ist, den Programmcode der Anwendung frei von jeglichen Abhängigkeiten zum SAP Code oder zu paketfremden Code zu halten. Dies wird auch die Wiederverwendung fördern.
Falls die Erstellung eigener Klassen überdimensioniert ist, kann in Sonderfällen die Trennung auch durch den Aufruf des fremden Codes in eigens dafür erstellten privaten Methoden erfolgen. Die Schnittstellendefinition sollte sich dabei eher an den Aufrufer und nicht am aufgerufenen Objekt orientieren. Somit ist später ein Austausch des verwendeten Fremdcodes einfacher. Je nach Komplexität kann das Mapping zwischen Eigen- und Fremdcodeschnittstellen in eigene Methoden ausgelagert werden.

Eine hilfreiche Erweiterung dieser Klassen ist die Transformation der klassischen Ausnahmen, oder Return Codes, die von SAP Code zur Fehlerbehandlung verwendet werden, hin zu Ausnahmeklassen.
Diese Trennung ist auch eine wichtige Voraussetzung für die Testbarkeit einer Anwendung.

Testbarkeit durch gutes Design

Gute Strukturierung in den Paketen, als auch in den Objekten sind grundlegende Voraussetzungen um die Testbarkeit der Software zu erhöhen. Sind die Verantwortlichkeiten der Komponenten im Rahmen einer guten Architektur geklärt und die Aufgaben auf verschiedene Objekte sinnvoll verteilt, erleichtert dies den Einsatz von ABAP-Unit massgeblich. Im Rahmen der vorgenannten Architektur- und Designentscheidungen müssen bereits testrelevante Aspekte miteinbezogen werden, um effizient ABAP-UNIT umsetzen zu können, da die Struktur sich unmittelbar auf die Testbarkeit auswirkt.

Sind Datenbankzugriffe und Zugriffe auf SAP Funktionsbausteine oder Klassen bereits in einer eigenen Softwareschicht gekapselt und werden die Instanzen über eine Factory erzeugt, die eine Injection vorsieht, ist es für einen erfahrenen Entwickler sehr unproblematisch, den eigenen Code über ABAP-UNIT Tests zu testen und Datenbankzugriffe sowie SAP-Funktionen über Test-Mocks-Objekte zu entkoppeln.
ies verringert den Aufwand für die Unit-Test Erstellung deutlich gegenüber einem Vorgehen, bei dem der Testentwickler im Code Techniken wie Test-seams anwenden muss oder den Code umbauen muss, um die Entkopplung der Eigenentwicklung von SAP-Bausteinen in Tests sicherzustellen.

Das Vorgehen, Empfehlungen und Hinweise zu ABAP-UNIT finden Sie im Kapitel Testen von SAP-Anwendungen.

TODO before Review ?

CHECKPOINT -> Empfehlungen prüfen - was fehlt?

          <h1 class="no_toc" id="sauberen-und-modernen-abap-code-schreiben">Sauberen und modernen ABAP Code schreiben</h1>

Clean ABAP
Grundlagen sauberer Entwicklung
1. Ausdrucksstarke Namen
Kommentare
Moderne Sprachmittel
Beispiele für modernes ABAP
Namenskonventionen - Empfehlungen NCs vs. Clean Code
1. Namen für Repository-Objekte
2. Ungarische Notation
ABAP Cleaner

ABAP gibt es seit 1983, und der Sprachumfang ist seitdem stetig gewachsen. Dadurch bildet die Sprache verschiedene Paradigmen ab, und es gibt häufig verschiedene Alternativen für ähnliche Zwecke. Als Beispiel können Funktionsgruppen und -bausteine etwa als imperativer Vorläufer ähnlich wie Klassen in ABAP OO genutzt werden. Daneben gibt es auch viele als obsolet gekennzeichnete Befehle, die häufig in bereits entwickelten Programmen oder Beispielcode im Internet zu finden sind und damit auch weiterhin für neue Entwicklungen genutzt werden.

Die SAP hat dieses Problem selbst erkannt und als eine Unterstützung für Entwickler die Clean ABAP Guidelines erstellt. Diese basieren auf dem Buch Clean Code von Robert C. Martin und adaptieren verschiedene Best Practices für ABAP. Die Guidelines liefern Vorgaben für viele Bereiche, etwa zur Benennung von Objekten und Variablen, über die Wahl der richtigen Sprachmittel, bis hin zur Formatierung und Kommentierung von Code.

Empfehlungen aus den Clean ABAP Guidelines werden in diesem Abschnitt so hervorgehoben. Dabei wird immer auf den entsprechenden Abschnitt der Guidelines verlinkt.

Daneben entwickelt die SAP ABAP auch stetig weiter. Eine Übersicht über neue Entwicklungen liefert etwa die ABAP Feature Matrix.

Die folgenden Abschnitte zeigen Beispiele für modernen ABAP Code, erhebt jedoch keinen Anspruch auf Vollständigkeit. Eine grundlegende Kenntnis von ABAP und insbesondere ABAP Objects wird vorausgesetzt.

Clean ABAP

Clean ABAP stellt die Anpassung der Prinzipien aus dem Buch von Robert C. Martin auf ABAP dar. Das offizielle, im Repository der SAP freigegebene Dokument wurde von Florian Hoffmann und Klaus Häuptle 2019 auf den Weg gebracht und wird seitdem als open source durch die ABAP Community erweitert.

Beispielregel mit Erläuterung:

Clean ABAP Excample Rule Prefer inline to up-front declarations

Der Gedanke von Clean ABAP ist, dass es nicht eine Version von Clean ABAP gibt, mit einem festen unveränderlichen Set an Regeln. Teams sind eingeladen, die Regeln anzupassen und zu verändern so wie sie für ihren spezifischen Fall am besten passen. Die öffentliche Version von Clean ABAP stellt eine exzellente Grundlage hierfür dar. Wichtig ist hier nur, dass diese Regeln verbindlich und für alle Teams eines Unternehmens hinweg gültig sein sollten. Der Grundgedanken von Clean ABAP - einheitliche Code Reviews - würde gebrochen wenn das Financials Team andere ABAP Regeln hat als das Sales Team. Alle Regeln von Clean ABAP sind heute und sollten immer begründet und erläutert werden.

Clean ABAP kann generell auf jede Sprachversion von ABAP angewendet werden von R2 bis hin zu ABAP Cloud.

DSAG Empfehlung

Die Regeln im öffentlichen Repository sind anerkannt unter den meisten ABAP-Experten. Die Autoren des DSAG Leitfaden empfehlen Ihnen den Einsatz der Clean ABAP Regeln für Ihr Coding und als Grundlage für Code Reviews. Diskussionen über Code unter Entwicklern können nicht selten mit einer Clean ABAP Regel gelöst werden.

Clean ABAP & Entwicklungsrichtlinien

Die auf das Unternehmen angepasste Form von Clean ABAP sollte ein ergänzendes Dokument der gültigen Entwicklungsrichtlinien sein, sodass es überall Anwendung findet. Prüfen Sie die Anwendung der Regeln mit einem automatischen Tool wie Code Pal for ABAP im ABAP Test Cockpit (https://github.com/SAP/code-pal-for-abap).

Clean ABAP owner

In jedem Entwicklungsteam sollte es - gerne auch rollierend - einen Clean ABAP Owner geben, der Ansprechpatner und Verantwortlicher für Änderungen ist. Änderungen und Erweiterungen müssen separat in den Teams kommuniziert und abgestimmt werden. Clean ABAP funktioniert am besten, wenn alle Beteiligten hinter den Regeln stehen, hierfür sind immer wieder Kompromisse und Abstimmungen im Team nötig.

Clean ABAP ist ein Prozess

Die Anwendung bzw. das Erlernen von Clean ABAP ist kein einmaliger Workshop oder eine Managementdirektive. Es braucht Zeit, Übung, Motivation und den konstanten Willen um bessere ABAP Programme zu schreiben.

Die Tätigkeiten, die das Anwenden von Clean ABAP sicherstellen, heißen Pair-Programming, Code Reviews, Refactoring und Schulung. Hierfür müssen von der Organisation entsprechende Bedingungen geschaffen werden.

Grundlagen sauberer Entwicklung

Prinzipien von Clean Code und Clean ABAP
Ein paar Clean ABAP Regeln zum Einstieg
Nutzung des ABAP Cleaners in ADT

Dieser Abschnitt gibt eine kurze Auswahl wichtiger Regeln für saubere Entwicklung mit Verweis auf Quellen mit weiteren Informationen wieder.

Ziel von Clean ABAP ist es, sauberen und für Menschen leicht verständlichen Code zu schreiben. Dies zeigt sich etwa in kurzen Methoden und ausdrucksstarken Namen.

Ausdrucksstarke Namen

Ein wichtiges Element von Clean ABAP ist die richtige Benennung von Entwicklungsobjekten. Gute Namen sind lesbar und verständlich, und machen direkt klar, worum es geht. In der alltäglichen ABAP-Entwicklung ist die Versuchung groß, technische Namen der SAP wiederzuverwenden; dies kann jedoch die Lesbarkeit erschweren, z.B. ist tj02_list schwerer verständlich als active_status oder erfordert wenigstens mehr ABAP-Kenntnisse.

Kommentare

“Drücke dich durch Code aus - nicht durch Kommentare” Dieses sollte einer der Leitsätze beim Scheiben von ABAP sein. Prüfen Sie jeden Kommentar, ob dieser nicht ein Ersatz für eine zu verbessernde Namensgebung bzw. Modularisierung ist. Eine lange Codestrecke, die mit dem Kommentar “Positionen verarbeiten” beginnt, deutet darauf, dass hier eine Methode über einen entsprechenden Namen genau dies aussagen und erledigen könnte. Ein Kommentar soll vielmehr Hinweise geben, warum etwas wie gemacht wird und ggf. den Kontext knapp erläutern anstatt zu beschreiben was gemacht wird.
Zur Code Dokumentation ist ABAPDoc zu verwenden, somit sind Code Kommentare nur noch für spezifische, zeilenbezogene Erläuterungen zu verwenden. Z.B. wenn Funktionen und Fehlerbehandlungsblöcke nicht ausprogrammiert wurden, noch TODOs oder offene Fragen bestehen, die im Laufe des Lebenszyklus behoben werden müssen.

Stark veraltete ABAP Richtlinien mit Aussagen wie: “Logisch zusammenhängende Einheiten sollten kommentiert werden, wobei der Kommentar vor dem jeweiligen Block steht.” “Das Erkennen solcher Blöcke wird bei langen und tief verschachtelten Kontrollstrukturen dadurch erleichtert, dass man am Ende einen auf den Beginn referenzierenden Kommentar einfügt”

Hier nehmen die ABAP-Guidelines bereits an, dass so genanter (Spaghetti Code)[https://en.wikipedia.org/wiki/Spaghetti_code] geschrieben wird. Kommentare können nie die Lösung für fehlende Modularisierung und Aufbrechen von tiefen Schachtelungen sein. Diese Probleme in der Lesbarkeit sollten durch konsequente Modularisierung und nicht durch Kommentare gelöst werden.

Clean ABAP rät zur (Erklärung über Code nicht Kommentare)[https://github.com/SAP/styleguides/blob/main/clean-abap/CleanABAP.md#use-methods-instead-of-comments-to-segment-your-code]

Im Leitfaden von Clean ABAP steht alles was Sie zu Kommentaren beachten sollten, (Siehe)[https://github.com/SAP/styleguides/blob/main/clean-abap/CleanABAP.md#express-yourself-in-code-not-in-comments].

Moderne Sprachmittel

Dieser Abschnitt zeigt eine kurze Übersicht moderner Sprachmittel von ABAP.

TODO bisherige Abschnitte zu Deklarationen etc. hier lassen oder in Anhang verschieben? Checkliste nochmal prüfen

moderne SQL Syntax
Stil von modernem ABAP
SAP SAMPLES als Referenz bibliothek
Todo check SAP Samples (ABap OO Basics)– und clean code bzgl. patterns -

Deklarationen

In der klassischen Deklaration von Variablen werden alle Deklarationen im Kopf einer Methode vorangestellt, und anschließend arbeitet die Methode mit diesen Variablen:

DATA mein_string TYPE string.
DATA mein_int    TYPE i.

" hier wird jetzt mit den Variablen gearbeitet
mein_string = `hello world`.
mein_int = strlen( mein_string ).

Clean ABAP empfiehlt, Inline-Deklarationen den klassischen Deklarationen vorzuziehen.

Mithilfe von Inline-Deklarationen können stattdessen überall in der Methode Variablen deklariert und direkt zugewiesen werden:

DATA(mein_string) = `hello worlddd`.

Deklaration mit FINAL

Version 7.57: Inline-Deklaration mit FINAL(var) statt DATA(var)

Mit FINAL können in ABAP unveränderbare Variablen deklariert werden. Diese können einmalig gesetzt, danach jedoch nicht mehr geändert werden:

FINAL(var) = 1.
var = var + 1. " Fehler - Variable darf nicht geändert werden

Der Vorteil einer FINAL-Deklaration ist, dass ein den Code lesender Entwickler nun weiß, dass er nicht weiter darauf achten muss, ob der Wert der Variable möglicherweise später im Code noch geändert wird.

Funktionale Aufrufe

Schon seit Version 7.5 werden Methoden in ABAP nicht mehr via CALL METHOD objekt->methode ... aufgerufen, sondern via objekt->methode( ... ). Das verkürzt ABAP-Code und erleichtert Entwicklern mit anderen Hintergründen das Codeverständnis.

Im Rahmen dieser Änderung wurden auch weitere Aufruf ähnlich gestaltet wie in anderen Programmiersprachen. So können Prädikatsmethoden, d.h. Methoden die einen der abap_bool-Wahrheitswerte abap_true oder abap_false zurückliefern, verkürzt in einem IF aufgerufen werden: Statt IF is_predicate( ) = abap_true. kann so einfach IF is_predicate( ). geschrieben werden.

Auch wurden für viele imperative ABAP-Anweisungen moderne Alternativen geschaffen.

Clean ABAP empfiehlt, funktionale Sprachelemente immer vorzuziehen.

Ein Beispiel ist die alte und neue Syntax, um einen String in Großbuchstaben umzuwandeln:

TRANSLATE string1 TO UPPER CASE. " alte, imperative Variante
string2 = to_upper( string2 ).   " neue Variante mit Funktionsaufruf

Ein anderes Beispiel ist die Bestimmung der Zeilenanzahl in einer internen Tabelle:

DESCRIBE TABLE itab LINES zeilen. " alte, imperative Variante
zeilen = lines( itab ).           " neue Variante mit Funktionsaufruf

Zuweisungen von logischen Ausdrücken

Ein weiteres Beispiel ist die Funktion xsdbool. Ursprünglich für die Verarbeitung mit XML konzipiert, ist sie mittlerweile trotz ihres Namens die bevorzugte Variante, um das Ergebnis eines logischen Ausdrucks an eine Variable zuzuweisen:

" Direkte Zuweisung mittels xsdbool
DATA(is_true) = xsdbool( len > 10 ).

" Klassische Auswertung mit IF
IF len > 10.
    is_true = abap_true.
ELSE.
    is_true = abap_false.
ENDIF.

Clean ABAP empfiehlt, die obere Variante zu bevorzugen.

Funktionen in der ABAP-Hilfe

Die ABAP-Hilfe bietet Listen von Funktionen für

ABAP Doc

ABAP Doc ist die moderne Variante, Dokumentation für Entwicklungsobjekte anzulegen.

Die Dokumentation für eine Klasse wird z.B. so angegeben:

"! Description of what the class does
CLASS demo DEFINITION.

Weitere Informationen finden sich im Abschnitt Dokumentation.

Konstruktoroperatoren

TODO Feedback zu viel Basics, Teile in Anhang schieben

Konstruktoroperatoren sind ein recht neues ABAP-Sprachmittel und bestehen aus dem Operator selbst, einer Typangabe, und Parameter innerhalb von Klammern. So ist bei data(instance) = new class( number = 1 ). der Operator NEW, der Typ class, und number = 1 ist die Parameterangabe. Mit einem Konstruktoroperator wird grundsätzlich ein neuer Wert erzeugt, im voranstehenden Beispiel wird etwa eine neue Instanz einer Klasse erzeugt.

Mit Konstruktoroperatoren können viele typische Programmieraufgaben kürzer und präziser gelöst werden. Dieser Abschnitt zeigt die Nutzung verschiedener Konstruktoroperatoren.

Eine Besonderheit ist dabei die Typangabe #. Damit weist der Entwickler ABAP an, den passenden Typen aus dem Kontext herzuleiten. Wird etwa mittels Konstruktoroperation eine zuvor deklarierte Variable gesetzt, bedeutet die Typangabe #, dass ein Wert vom Typ der Variable erzeugt wird.

DATA table TYPE table_type.
table = VALUE #( ). " Erzeugen einer leeren Tabelle vom Typ table_type

Referenzen mit NEW erzeugen

Wie im vorigen Abschnitt gezeigt, können mit NEW neue Instanzen einer Klasse erzeugt werden.

" Moderne Variante
DATA(object) = NEW lcl_configuration( number = 1 ).

" Alte, obsolete Variante
CREATE OBJECT object TYPE lcl_configuration.

Nutzung neuer Befehlsvarianten (CALL TRANSACTION WITH AUTHORITY-CHECK)

TODO Beispiel aufnehmen

Beispiele für modernes ABAP

Dieser Abschnitt zeigt einige Beispiele für moderne Alternativen zu alter und veralteter ABAP-Syntax.

TODO Template entfernen

Die Beispiele der folgenden Abschnitte verwenden teilweise die folgende Struktur- und Tabellendefinition

TYPES: BEGIN OF person,
            age  TYPE i,
            name TYPE string,
        END OF person.

TYPES persons TYPE STANDARD TABLE OF person WITH EMPTY KEY.

Strukturen und Tabellen erzeugen

" Alte Variante
DATA old_person  TYPE person.
DATA old_persons TYPE persons.

old_person-age  = 30.
old_person-name = `Max Mustermann`.

INSERT old_person INTO TABLE old_persons.


" Moderne Syntax
DATA(new_persons) = VALUE persons( ( age = 30 name = `Max Mustermann` ) ).

Werte aus Tabellen auslesen

Zum Lesen von Tabellen kann anstelle des alten READ TABLE-Befehls auch die neue Syntax von Tabellenausdrücken bzw. Table Expressions verwendet werden:

" Alte Variante
READ TABLE persons INDEX 1 INTO DATA(first_person_old).

" Moderne Syntax
DATA(first_person_new) = persons[ 1 ].

Tabellenausdrücke können auch zusammengesetzt sein, mit nested_tables[1][2] wird die zweite Zeile der Tabelle gelesen, die wiederum in der ersten Zeile von nested_tables liegt.

Der Vorteil der neuen Syntax zeigt sich beispielsweise, wenn direkt auf eine bestimmte Spalte zugegriffen werden soll:

" Alte Variante
READ TABLE persons WITH KEY name = `Maria Musterfrau` INTO DATA(maria_old).
DATA(age_maria_old) = maria_old-age.

" Moderne Syntax
DATA(age_maria_new) = persons[ name = `Maria Musterfrau` ]-age.

Wichtig ist die unterschiedliche Fehlerbehandlung: Findet READ TABLE eine Zeile nicht, zeigt ein Wert von sy-subrc ungleich 0 (oder 2) dies an. Ein Tabellenausdruck hingegen wirft die Exception cx_sy_itab_line_not_found. Statt diese Exception abzufangen, existieren jedoch zwei kurze Varianten für den typischen Umgang mit nicht gefunden Werten, nämlich das Zurückgeben eines initialen Werts oder eines vorgegebenen Standardwerts:

" Alte Variante
READ TABLE persons WITH KEY name = `unbekannt` INTO DATA(unknown_person_old).
IF sy-subrc <> 0.
    " tue etwas anderes
ENDIF.

" Moderne Syntax
" Variante 1: Ergebnis ist initial, wenn Zeile nicht gefunden
DATA(unknown_person_new_optional) = VALUE #( persons[ name = `unbekannt` ] OPTIONAL ).
" Variante 2: Ergebnis entspricht Default-Fall, wenn Zeile nicht gefunden
DATA(unknown_person_new_default) = VALUE #( persons[ name = `unbekannt` ]
                                            DEFAULT VALUE #( name = `Standardergebnis`
                                                                age  = 99 ) ).

Tabellen umwandeln

Häufig muss aus einer Tabelle eines Typs eine Tabelle eines anderen Typs bestimmt werden. In anderen Programmiersprachen steht dafür häufig eine map-Methode bereit.

In ABAP hingegen kann dies auch mithilfe eines VALUE-Statements umgesetzt werden. Wenn z.B. die Methode read_person zu der genutzten person-Struktur ein Objekt lädt, sieht das Umwandeln der Tabelle wie folgt aus:

" Alte Variante
DATA(person_objects_old) = VALUE person_objects( ).

LOOP AT persons INTO DATA(loop_person).
    INSERT read_person_info( loop_person ) INTO TABLE person_objects_old.
ENDLOOP.

" Moderne Syntax
DATA(person_objects_new) = VALUE person_objects( FOR p IN persons
                                                    ( read_person_info( p ) ) ).

Die folgenden Beispiele zeigen, wie nur bestimmte Zeilen einer Tabelle übernommen werden können:

Übernahme von Zeilen anhand des Index:

" Alte Syntax
DATA(shorter_table_old) = VALUE persons( ).

LOOP AT persons INTO DATA(loop_person).
    IF sy-tabix >= 2.
    INSERT loop_person INTO TABLE shorter_table_old.
    ENDIF.
ENDLOOP.

" Moderne Syntax                                                         
DATA(shorter_table_new) = VALUE persons( ( LINES OF persons FROM 2 ) ).

Sollen Zeilen anhand einer Bedingung gefiltert werden, sieht die moderne Syntax so aus:

DATA(younger_persons) = VALUE persons( FOR p IN persons WHERE ( age < 20 )
                                           ( p ) ).

Für viele Möglichkeiten, die LOOP AT bietet, gibt es auch in der VALUE-Variante Entsprechungen.

TODO Beispiele für alles?

Zwischenberechnungen mit LET
GROUP
BASE
FOR i = 1 UNTIL i > 3

String Templates und Konvertierungsexits

In klassischer Syntax mussten Strings

Bestimmung von Werten aus Tabellen, z.B. Minimum

" Alte Variante
DATA(youngest_person_old) = VALUE #( persons[ 1 ] OPTIONAL ).

LOOP AT persons INTO DATA(loop_person).
    IF loop_person-age < youngest_person_old-age.
    youngest_person_old = loop_person.
    ENDIF.
ENDLOOP.

" Moderne Syntax
DATA(youngest_person_new) = REDUCE #( INIT youngest = VALUE person( persons[ 1 ] OPTIONAL )
                                        FOR p IN persons
                                        NEXT youngest = COND #( WHEN p-age < youngest-age
                                                                THEN p
                                                                ELSE youngest ) ).

TODO andere Beispiele

fancy line_exists
GROUP
BASE
FOR i = 1 UNTIL i > 3

Namenskonventionen - Empfehlungen NCs vs. Clean Code

Namen für Repository-Objekte

Für Repository-Objekte wie beispielsweise Klassen sollte im Unternehmen immer ein Namensschema vorgegeben werden, da sich alle Objekte eines Typs den selben Namensraum teilen. Wird etwa für Instandhaltungsaufträge eine Klasse ZCL_AUFTRAG angelegt, steht dieser Name nicht mehr für Serviceaufträge zur Verfügung, und ein Entwickler der den Namen der Klasse liest weiß nicht direkt, um was für einen Auftrag es sich handelt. Nicht ausdrucksstarke Namen wie ZCL_DATA oder ZCL_FORMULAR3 erschweren ebenso das Verständnis beim Lesen des Quellcodes.

Ungarische Notation

Clean ABAP empfiehlt, bei Variablenbenennung auf die ungarische Notation oder andere Encodings zu verzichten.

Gemäß den Clean ABAP-Richtlinien entwickelter Code wird aus vielen, kurzen Methoden bestehen. In diesen ist es unnötig, Informationen wie z.B. die Gültigkeit oder den Typ einer Variable in ihrem Namen anzugeben. Diese Informationen sollten direkt auf einen Blick sichtbar sein, oder stehen in Eclipse z.B. mittels Druck auf F2 direkt zur Verfügung. Stattdessen sollten ausdrucksstarke Namen verwendet werden.

In altem Coding, das noch nicht modernisiert wurde, kann die Weiternutzung ungarischer Notation hingegen hilfreich sein. Beide Varianten sollten jedoch nicht gemischt in einem Entwicklungsobjekt eingesetzt werden.

ABAP Cleaner

Der 2023 öffentlich erschienene ABAP Cleaner ist eine Erweiterung für ADT, welche die Anwendung von mehr als 90 Regeln zur Formatierung und Gestaltung von ABAP Code ermöglicht. ABAP Cleaner Link ABAP Code wird nicht nur wie bei Pretty Printer formatiert, es werden auch, basierend auf den eingestellen Regeln, Optimierungen des ABAP Codes vorgenommen. Nicht verwendete Methoden-Parameter werden durch Kommentare kenntlich gemacht und es können - je nach Einstellung - nicht verwendete Variablen automatisch gelöscht werden. Das Ergebnis der Anwendung ist einheitlicher, besser lesbarer Code und eine effektive Beschleunigung der Entwicklung, da der Cleaner Aufgaben des Programmierers übernimmt.

Der Einsatz des ABAP Cleaners bringt eine Vielzahl von Vorteilen für das moderene Entwickeln von ABAP Code. Aus Sicht der Autoren dieses Leitfadens ist der Einsatz vom ABAP Cleaner unbedingt nötig.

          {: .no_toc} # ABAP RESTful Application Programming Model (RAP)

Einleitung

Das ABAP RESTful Application Programming Model, kurz RAP, wurde seitens der SAP 2019 erstmalig vorgestellt und ist seit dem S/4 Release 2019 nutzbar. Konzeptuell weist es viele Parallelen zum ABAP-Programming Model for SAP Fiori auf und kann daher als dessen spiritueller Nachfolger gesehen werden.

Beide Programmiermodelle geben die nötigen Entwicklungsobjekte und deren Zusammenspiel vor um in einem S/4 System Applikationen und Schnittstellen mit eigener Datenhaltung aufzubauen. Die Weiterentwicklung zu RAP hat die Entwicklung nochmals deutlich vereinfacht und kommt gänzlich ohne SAP GUI Transaktionen oder SEGW Services aus. Auch bei RAP dreht sich die gesamte Anwendungslogik um ein sogenanntes Business Objekt, das Datenhaltung und vorhandene Businesslogik definiert und Konsumenten anbietet. Erste Wahl sollte RAP sein, wenn transaktionale Fiori Elements Applikationen zu entwickeln sind (List Report & Object Page). Aber auch rein lesende APIs, SAPUI5 Freestyle Apps oder SAP-fremde UI-Technologien lassen sich mit RAP umsetzen durch die Nutzung der resultierenden OData-Services.

RAP bildet dabei das komplette E2E-Szenario von der Datenbankschicht bis hin zum veröffentlichten OData-Service ab. Das Business Objekt (BO) wird einerseits durch das virtuelle Datenmodell (VDM) sowie andererseits durch das (optional) verfügbare Verhalten definiert. Im VDM werden durch die Anlage von CDS-Views die Felder aus der Datenbank selektiert und über Beziehungen zwischen den CDS-Views der BO Composition Tree festgelegt. Dieser besteht immer aus einer Wurzel-Entität (Root, beispielsweise eine Reise mit entsprechend möglichen Instanzen) und beliebig vielen Kind-Entitäten (etwa eine oder mehrere Instanzen von Flugbuchungen unterhalb der Reise). Dieser Kompositionsbaum kann beliebig tief aufgebaut werden. Jede Kind-Entität kann dabei lediglich gemeinsam mit ihrem direkten Elter exististieren und dessen Schlüssel ist Teil des eigenen.

Empfehlungen / Best Practices

RAP sollte frühestens ab Release 2020 produktiv genutzt werden. Setzen Sie sich bei Bedarf detailliert mit dem eingeschränkten Funktionsumfang im Release 2019 (wie das Fehlen von Validations, Determinations, Draft, …) auseinander!

In der Regel sollten Sie für Neuentwicklungen das integrierte Draft-Konzept nutzen und lediglich bei triftigen Gründen darauf verzichten.

Da RAP als Technologie relativ neu ist gibt es teils eklatante Unterschiede je nach S/4 Release. Machen Sie sich mit den Einschränkungen ihres Systems vorab vertraut!

Wann immer möglich sollten neue Applikationen mit Fiori Elements umgesetzt werden. SAPUI5 Freestyle-Apps verlocken gerne dazu, sich durch zusätzliche Freiheiten in erhöhte Komplexität locken zu lassen und führen in der Regel zu deutlichem Mehraufwand.

Managed Entwicklungen mit RAP

Per Definition trennt das RAP-Framework die einzelnen Entwicklungsobjekte ohnehin und gibt dadurch die Softwarearchitektur und eine saubere Trennung ohnehin vor. Die tatsächliche Anwendungslogik wird dabei strikt von der Datenhaltung getrennt. Diese strikten Vorgaben des Framework erleichtern Entwickler:innen das Orientieren und Implementieren von Anwendungen und nimmt viel Arbeit diesbezüglich ab. Das nachstehende Bild zeigt das grobe Zusammenspiel der Teilelemente in RAP Programmierungen.

RAP Big Picture, © SAP

Datenbankebene

Bei Neuentwicklungen sollte stets das Managed Szenario genutzt werden um möglichst viele Funktionalitäten (CRUD-Handlung, Draft, …) automatisiert vom Framework zu nutzen und manuellen Entwicklungsaufwand zu reduzieren. Einige Unterschiede im Unmanaged Szenario finden Sie unten. Auf unterster Ebene wird das Datenmodell für das RAP Business Objekt klassisch via DDIC Tabellen oder auf neueren Systemen mit CDS Tabellenentitäten erstellt. Jeder Knoten, der später über RAP als eigenes EntitySet veröffentlicht werden soll, erhält eine eigene Datenhaltung. Es ist darauf zu achten, UUIDs als Schlüssel zu verwenden und den UUID-Schlüssel aller hierarchisch obergeordneten Knoten mit einzubeziehen.

Virtuelles Datenmodell

Basierend auf den Tabellen wird nun das Virtuelle Datenmodell (VDM) via CDS Views aufgebaut - mehr Informationen zu diesem Entwicklungsobjekt finden Sie im Kapitel Core Data Services. Gemäß der SAP-Empfehlungen sollten hierfür mehrere Ebenen oder Layer aufgebaut werden (von unten nach oben):

I_ Interface Layer (Umbenennung der Felder, Definition der Annotationen, entfällt ggf. bei Nutzung von CDS Table Entities)
R_ Reuse Layer (Composition Tree für RAP)
C_ Consumption Layer (Projektion mit App-spezifischen UI-Annotationen)

Pro Business Objekt gibt es genau einen gültigen Reuse Layer, zu dem auch das BO Verhalten definiert wird. Verwenden dieses BO jedoch mehrere, separate Applikationen haben Sie die Möglichkeit, später mehrere Consumption Layer anzulegen und können dort App-spezifische Virtuelle Felder im CDS an dieser Stelle ergänzen oder überflüssige Felder für den jeweiligen Use-Case aus der Selektion entfernen. Sind virtuelle Felder aber für das gesamte RAP BO relevant und gültig sollten sie entsprechend bereits tiefer im Reuse Layer eingeführt werden. Selbiges gilt für die Verknüpfung von Wertehilfen oder sprachspezifischen Texten, die im BO global genutzt werden sollen.

Behavior Definition & Pool

Aufbauen auf dem Root Reuse CDS View wird in der nächsten RAP-Schicht eine zentrale Behavior Definition angelegt. Diese definiert das verfügbare transaktionale Verhalten zum Business Objekt und enthält zentrale Konfigurationen dafür. Sie ist einmalig und es können nicht mehrere Behavior Definitions zu einem gegebenen CDS Composition Tree existieren. Jeder Knoten des Baumes ist einzeln in der Behavior Definition aufgeführt und kann mit einem Alias versehen werden und kann im Anschluss via EML unter diesem angesprochen werden.

Behavior Projection

Bezieht sich auf die Root Consumption CDS View.

OData Veröffentlichung

Der eigentliche OData Service wird im RAP Framework nicht mehr wie zuvor üblich über die Transaktion SEGW veröffentlicht. Vielmehr übernimmt die Generierung und Bereitstellung das Framework automatisiert und mit lediglich wenigen Konfigurationen ihrerseits.

Zunächst müssen Sie aufbauen auf Ihrem Root Consumption CDS View eine Service Definition erstellen. Diese listet all zu veröffentlichenden Consumption CDS Views auf und ermöglicht die Vergabe eines Alias pro Quelle. Unter diesem Alias ist die Entität im OData-Service später als EntitySet verfügbar. Andere, verknüpfte CDS Views beispielsweise als Stammdatenquellen müssen nicht explizit aufgenommen werden, diese werden bei Referenzierung aus veröffentlichten CDS-Views automatisch Teil des Services.

Aufbauend auf der Service Definition wird im nächsten Schritt ein Service Binding angelegt. Hier können Sie festlegen ob der OData Service zur Nutzung von Fiori Oberflächen, für analytische Szenarien oder einfach als Web-API gedacht ist. Außerdem entscheiden Sie sich für OData V2 oder V4. Nach dem Pulishen können Sie für UI Services direkt die Fiori Preview aufrufen oder andernfalls beispielsweise via /IWFND/GW_CLIENT den OData-Service konsumieren und gelieferte Daten testen.

Weitergehende RAP-Funktionalitäten

RAP Unit Testing

Erweiterbarkeit

Beachten Sie, sämtliche Entwicklungsobjekte für die Erweiterung freizugeben, falls dies gewünscht ist.

Unmanaged Szenario

Unterschiede zum oben beschriebenen Managed Szenario sollten hier ergänzt werden

Entity Manipulation Language (EML)

Für mehr Infos siehe EML Cheat Sheet

RAP Feature Showcase App

Die SAP stellt ein zentrales Repository bereit, das als Beispielapplikation in ihrem S/4 System installiert werden kann. Diese RAP Feature Showcase App zeigt Ihnen interaktiv, welche Funktionalitäten mit RAP und Fiori Elements generell umgesetzt werden können und hilft Ihnen dabei, die nötigen Entwicklungen direkt im System nachzuvollziehen. Nach der Installation können Sie die App auf Ihrem S/4 System ausführen und alle verfügbaren Möglichkeiten erkunden. Die App gibt auch konkrete Auskunft dazu, wie bestimmte Funktionen umgesetzt werden können.

Migration von CDS-generiertem BOPF

Sie haben die Möglichkeit, bestehende BOPF-Anwendungen in das modernere RAP Framework zu migrieren, wenn diese nicht mit der BOBX-Transaktion sondern über @ObjectModel-Annotationen aus CDS heraus generiert wurden. Weitere Informationen zur Vorgehensweise finden Sie im offiziellen Migration Guide Migration von CDS-generiertem BOPF zu RAP.

Verfügbarkeitsübersicht der Features

Wie oben erwähnt machte das RAP-Framework insbesondere direkt nach Release große Sprünge von S/4 Version zu S/4 Version. Welche Features Sie daher nutzen können hängt stark von Ihrem Systemstand ab. Vor dem Release 2020 ist in den meisten Fällen von der Nutzung abzuraten. Die folgende Auflistung soll Ihnen eine erste Orientierung ermöglichen, welche Features ab wann unterstützt werden und was künftig erwartet werden kann.

1909

Erstes Release von RAP, EML in ABAP Syntax
Nur Unterstützung von Queries (read-only) und unmanaged transaktionalen Apps mit Legacy-Coding.
Nur OData v2

2020

Virtuelle Elemente im CDS-View fürs RAP-BO (vgl. Transiente Felder im BOPF)
Managed Scenario, Unmanaged/Additional Save (Custom Save Handler), Unmanaged Lock
Draft Scenario (total eTag)
OData v4
Type & Control MappingOData Navigation über mehr als zwei BO-Hierarchie-Ebenen
Dokumentation via Knowledge Transfer Document für Behavior Definition, Service Binding
Actions/Functions erlauben andere Entitäten / Strukturen als Result-Rückgabeparameter
Control-Struktur für Create liefert Information, welche Felder nicht vom Client befüllt wurden
Dynamisches Operation/Feature Control
Einführung der DVM (Determinations-Validations-Machine) mit Trigger Operationen + Feldern

2021

Zusätzliche Implementierung für Draft Actions
Simulationsmodus für COMMIT ENTITIES (EML)
Singleton-Root-Instanz für Multi-Line Editierung mehrerer Haupt-Entitäten (Customizing-Einträge, etc.)
Zusätzliche Actions, Functions in Behavior Projection
InA Service für CDS Analytische Queries

2022

Erweiterbarkeit von RAP Business Objekten
Business Events (Define & Raise)
Abstraktions-Ebene via Business Object Interface
Large Objects (Binärdateien, Datei-Upload)
ADT-Wizard: Generate ABAP Repository Objects (RAP-Generierung auf Basis einer Datenbanktabelle)
Instance Factory Actions zur Erzeugung von Entitäten
Read Access Logging für RAP BOs

2023

Side Effects zum Triggern von Feld-Aktualisierungen
Erweiterbarkeit von Service Definitions
Initiales Release des Background Processing Framework
Migrations-Tool für bestehende BOPF BOs (siehe unten)
Consumption von Business Events

2025, verfügbar ab Herbst

Ausschließlich CDS-basiertes Datenmodell (CDS Table Entities als Persistenz, CDS Simple Types, CDS Exact Cardinalities, CDS Scalar Functions, CDS Aspects)
RAP-Modellierung von Hierarchien
Kollaborativer Draft (Parallele Zusammenarbeit an einer BO-Instanz)
Fiori Elements Tabellen zur Anzeige und Änderung von RAP-Hierarchien

Weiterführende Quellen

Notizen TODOS

Mehr zum Flex Model schreiben
Peter Bescheidgeben & um Feedback fragen

Fiori Elements Feature Map

        <h2 id="vorschlag-reihenfolge-und-strukturierung-der-kapitel">Vorschlag: Reihenfolge und Strukturierung der Kapitel:</h2>

Mein Vorschlag für die generelle Struktur:

Einleitung - klar was sonst

Strategie Blocks

Organisation - Rahmenbedingungen und Grundsätze, die in den einzelnen Kapiteln wieder aufgegriffen werden Unterteilung in subfiles sinnvoll - Inhaltlich top !
Clean Core - Basis Strategie - wie und mit welchen Prinzipien will man entwicklen (wie clean)

Moderne SAP Entwicklung - Technologien

Core Data Service (vor ABAP, weil benötigt in ABAP zum Datenzugriff und anderes Programmiermodell)
ABAP - Basis der Programmierung - Unterteilung in weitere Files wegen größe
UI
Testen - Software tests - braucht wiederum ABAP wegen OO und so
Formulare
Dokumentation - Doku der Entwicklung - ABAP DOC nich ausführlicher

Übergreifende Themen

Software Lifecycle Management
- ALM (alm und VW mergen in Softwaremanagment)
- Versionsverwaltung
Open Source
Integration
Sicherheit
KI

Parkplatz

* TEXTSAVER - **

Dynamic Logpoints mit ADT

Mit dynamischen Logpoints können Sie ohne Änderung der Programme LogPoints erstellen, die wertvolle Informationen zum Ablauf von Programmen liefern.

Lop-Points helfen ihnen bei der Analye fon Prozessen die mit anderen Benutzer ausgeführt werdne und wo ein Debugging nicht / schwer möglich ist. Sie Erhalten die Möglichkeit auf einfache Weise den Inhalt von Variablen auf zu zeichnen und zu prüfen wann und wie oft eine Funktion aufgerufen wird.

Folgende Fragestellungen können einfach beantwortet werden:

von welchen Benutzern wurde eine stück Code duchlaufen
mit welchen Parametern wurde diese Funktion aufgerufen
Wie war die Aufrufhierarchie?
vieles mehr

Tipp: Verwenden und üben sie den Einsatz von dynamischen Logpoints sie werden Ihnen sehr nützlich sein.

Don’t: seit der Möglichkeit Logpoints dynamisch zu definieren, verzichten sie auf die Erstellung von LOG-POINTs im ABAP Code und nutzen sie die Dynamische Variante. Dies gilt nicht für Dynamische Break-Points oder ASSERTIONS.

Die SAP Hilfe bietet erweiterte Informationen

ABGLEICH TEST Kapitel ob dort was fehlt

Moderne Softwareentwicklung bietet die Möglichkeit mittels moderner Softwarearchitektur das Testing in die frühe Phase der Softwareerstellung zu verschieben und Fehler frühzeitig zu finden. potenzielle Fehler werden bereits in der Designphase betrachtet, das gewünschte Programmverhalten definiert und evtl. Problematiken im Vorfeld mit dem Anforderer besprochen. Ziel einer modernen Anwendungsarchitektur ist es, eine Anwendung in kleine, abgrenzbare und testbare Komponenten aufzuteilen. Diese werden in entsprechenden Unterpaketen des Anwendungspaketes gekapselt. Da diese Komponenten kaum manuell testbar sind, ist hier UNIT Testing mit ABAP UNIT einzusetzen. Dies erfordert aber eine gute Strukturierung und weitere Hilfspakete, die Testfunktionalitäten bereitstellen.

Im klassischen ABAP-Umfeld besteht die Vorgehensweise klassischerweise darin, dass zeitnah eine Entwicklung durch die Entwickler bereitgestellt werden und sobald als möglich die Tests durch die Entwickler und die Fachabteilung erfolgt.
Beim Auftreten eines Fehlers oder Defekts wird dann die Entwicklung korrigiert und weitere Anpassungen vorgenommen. Dies kann dann zu zahlreichen Zyklen von Entwicklung - Test - Korrektur - Test usw. führen. Tests einzelner Komponenten ist entweder schwierig oder bedingt durch die monolithische Anwendungsstruktur nicht möglich. Daher können hier auch nur vollständige Funktions- oder gar Prozesstests mit entsprechend hohem Aufwand durchgeführt werden.
Dabei kann nicht ausgeschlossen werden, dass einige Fehler erst im Rahmen des Produktivbetriebes erkannt werden, da auf Testsystem weder die kompletten Prozessdaten vorhanden sind, weder die Masse an Transaktionen durchgeführt wird, noch die Varianz an Transaktionsausführung vorhanden ist. Daher sollte dieses Vorgehen vermieden werden.

Das Schreiben der UNIT-Tests und der benötigten Mocks und Testdaten erfordert einiges an Aufwand. Die Bereitstellung einer testbaren Version verzögert sich durch den Aufwand der sich durch die Erstellung des Objektgeflechts und der Testartefakte ergeben.

Im Gegenzug entsteht der sogenannte Produktcode, der die Logik enthält anschließend fast von selbst. Die Erkenntnisse, die sich beim Design der Testdaten und der Tests ergeben, führen dazu, dass viele Situationen und Fragestellungen der Anwendung sich schon frühzeitig ergeben und vorab geklärt werden und über die automatisieren Tests abgedeckt werden können. Viele Fehler werden frühzeitig während der Entwicklung entdeckt und behoben und müssen nicht erst durch die Fachabteilung entdeckt werden. Die Anwendung wird damit robuster und ausgereifter als sie es ohne die Unit Test Erstellung wäre und somit entfallen auch zahlreiche Transportzyklen von Entwicklungs- in Test- oder gar Produktivsysteme.

    <h1 class="no_toc" id="softwaretest-mit-abap-unit">Softwaretest mit ABAP Unit</h1>

Inhalt des Kapitels
Zielgruppe
Motivation
Herausforderungen die den Einsatz von ABAP Unit beeinflussen
Rahmenbedingungen für den Einsatz von ABAP Unit
Die Rolle des DSAG ABAP-Leitfadens für die Umsetzung Ihrer Test Strategie

Inhalt des Kapitels

Wenn Software entwickelt wird, muss diese während der Entwicklung und vor der Inbetriebnahme ausgiebig getestet werden. Zum Testen von Software gibt es zahlreiche und vielfältige Methoden und Techniken. Testen ist aufwändig und wenn Software nicht sorgfältig und umfassend getestet wird, kann dies im besten Fall zu kleinen Störungen bis hin zu massiven Auswirkungen auf den Produktivsystem eines Systems führen. Dies führt mitunter zu hohen Kosten im Betrieb und der Weiterentwicklung von SAP-Systemen.

Effizientes und effektives Testen muss im Softwareentwicklungsprozess so früh wie möglich erfolgen um Fehler und Probleme so früh wie möglich erkennen zu können. Mit ABAP Unit werden Tests in die frühe Phase der Softwareentwicklung integriert. In diesem Kapitel gehen wir darauf ein warum der Einsatz von ABAP Unit erforderlich und gewinnbringend ist, welche Herausforderungen sich ergeben und welche Rahmenbedingungen gegeben sein müssen um ABAP Unit Tests effektiv einzusetzen.

Ergänzend finden Sie noch ein paar Hinweise zu weiteren Testtools und Methoden, diese werden aber nur kurz angesprochen.
Wenn im Folgenden von Unit Tests die Rede ist, dann sind ABAP Unit Tests mit Hilfe des ABAP Unit Frameworks gemeint. Das ABAP bezieht sich lediglich auf die Besonderheiten von Unit Tests im ABAP Unit Framework.

Begriffsabgrenzung Unit Test
Unter Unit Tests werden oft verschiedene Definitionen von Tests verstanden.
Wenn wir hier von Unit Tests schreiben, handelt es sich um programmierte Tests mit dem ABAP Unit Framework, die automatisiert ausgeführt werden können.
Die manuelle Ausführen einzelner Code Einheiten z.B. mittels SE37 / SE24 / Reports ist kein Testen, sondern das Ausprobieren von Funktionalitäten.

Zielgruppe

In diesem Kapitel möchten wir einerseits den Entscheidern und Verantwortlichen Empfehlungen und Hinweise geben, warum ABAP Unit Tests für die heutige Form der modernen ABAP Programmierung sehr wichtig ist und welchen Nutzen Sie für dieses Investment erhalten können.
Dieser Leitfaden dient aber auch Entwicklern und Entwicklungsverantwortlichen oder vgl. Rollen dazu, ABAP Unit Testing sinnvoll einzusetzen, oder falls es noch nicht umfangreich im Einsatz ist, den Einstieg zu erleichtern.
Vielleicht hilft dieser Leitfaden auch dabei sowohl Entwickler als auch Entscheider zu motivieren, ABAP Unit Tests umfangreich im Entwicklungsprozess einzusetzen und die Rahmenbedingungen dafür zu schaffen.

Motivation

Ein wichtiger Faktor in SAP-Projekten ist die zur Verfügung stehende Zeit. Und meistens herrscht hoher Zeitdruck wenn um die Erstellung von SAP-Anwendungen und Anpassungen geht. Die Erstellung von ABAP Unit Tests und die dazu erforderlichen softwaretechnischen Maßnahmen benötigen Zeit und Wissen. Hier entsteht ein Spannungsfeld da dies auf den ersten Blick Zielkonflikte aufwirft. Die Software soll schnell und im Projektzeitplan erstellt werden. Die Software soll aber auch allen Anforderungen entsprechen, robust und fehlertolerant, also von hoher Qualität sein.

Der Mitbegründer des agilen Manifests und Buchautor mehrerer Bücher zur Softwareentwicklung, Robert C. Martin sagte:
“The only way to go fast is, to go well.”

Warum soll man Aufwand und Zeit in die Erstellung von Unit Tests investieren? Übersetzt in den ABAP-Kontext bedeutet diese Aussage, dass wer schnell sein will, gut vorgehen muss.
In ABAP Unit erfahrene Entwickler wissen, dass die Erstellung von Software, die mit ABAP Unit Tests abgedeckt ist, neben der höheren Qualität auch Effizienz- und Geschwindigkeitsvorteile mit sich bringt.
Wir möchten zu Beginn des Kapitels Ihnen die Vorteile aufzeigen und gehen im Weiteren auf die ABAP Unit Test Technik und die erforderlichen Maßnahmen und Vorgehensweisen ein.

Vorteile die sich durch den Einsatz von Unit Tests ergeben:

Die Erstellung von Software, die mit Unit Tests unterlegt ist, beinhaltet, bedingt durch die erforderliche Massnahmen zur Testbarkeit, eine klare Struktur, die objektorientierten Designprinzipien folgt.
Software, die ABAP Unit Tests enthält hat aufgrund der architektonischen Erfordernisse wie Separation of Concerns eine bessere Struktur und Trennung der Belange (Fachliche Logik und technisches Coding). Damit ist die Software flexibler und besser anpassbar.
Die Entwicklung enthält ein Sicherheitsnetz, dass von Entwicklern genutzt werden kann wenn Software weiterentwickelt wird.
Fehler werden bereits während der Entwicklung auf dem Entwicklungssystem erkannt, dies spart Aufand in Integrations- und Anwendertest.
Durch die erforderliche Erstellung der Testfälle und programmatische Testdatenerstellung, werden Unklarheiten in der Anforderungsspezifikation in einer frühen Phase der Entwicklung festgestellt.
eine Testabdeckung durch Unit Test ermöglicht die ständige Verbesserung und das Refaktoring der Software, was den Aufbau von technischen Schulden vermeidet.
Wissensverteilung in Team. Durch Unit Tests werden Funktionalitäten dokumentiert, was es anderen Teammitgliedern einfacher macht, sich mit dem Coding vertraut zu machen und es anzupassen, da Unit Tests programmierte Spezifikation des Verhaltens darstellen und dazu auch ausführbar sind.
Sobald eine in der Produktion befindliche Anwendung erweitert oder angepasst werden muss, sind die Vorteile von ABAP Unit Tests feststellbar, da bereits während der Entwicklung über die Tests getestet werden kann. Fehler können zum frühesten Zeitpunkt erkannt werden. Durch die Tests liegen bereits Testdaten und technische Spezifikationen vor, welche die Änderung oder Erweiterung des Codes vereinfacht.

Die oben genannten Punkte führen im Ergebnis dazu, dass der Testaufwand der Anwendung durch die Fachabteilung deutlich reduziert wird. Anpassungen und Erweiterungen der Anwendungen werden durch die Implementierung von Unit Tests deutlich vereinfacht und vor allem sicherer, da neue Fehler bereits durch die bestehenden Unit Tests während der Entwicklung entdeckt werden und somit in den Anwendertests auf dem Testsystem auftreten. Dies sind vor allem Fehler in der Struktur oder Flüchtigkeitsfehler, die unvermeidlich sind.

Neben den generellen Vorteilen die sich positiv auf den Aufwand und die Organisation auswirken, bringt der Einsatz von Unit Tests aber auch Vorteile für den Entwickler, der zuerst Aufwand und Energie in die Erstellung von Unit Tests stecken muss und ggf. auch deswegen gegen Widerstände ankämpfen muss.

Vorteile für den Entwickler:

Durch die Notwendigkeit Testdaten zu programmieren, erhält der Entwickler gute Einblicke in die zu verarbeitenden Daten und bekommt damit auch verwertbare Informationen über die zu erstellende Anwendung die helfen, die Anforderungen besser zu verstehen und damit besser umzusetzen.
Um Tests zu implementieren muss von Grund auf eine gute Struktur erstellt werden. Dies verhindert die Erstellung von Code der verschiedene Belange vermischt und spätere Anpassungen erschwert.
Sobald die ersten Tests geschrieben sind, können auf dem Entwicklungssystem die Komponenten der Anwendung ausgeführt und debugged werden und damit auch wertvolle Hinweise über das Laufzeitverhalten frühzeitig ermittelt werden und Fehlannahmen vermieden werden, die sonst aufwändig behoben werden müssten.
Der initiale Mehraufwand wird durch spätere Effizienzgewinne ausgeglichen. Verbunden damit, dass der Entwickler über UNIT TEST abgesicherte Software bessere Qualität liefert, schneller funktionierende Software auf den Testsystemen zur Verfügung gestellt werden kann und weniger Fehler in späteren Testphasen auftreten, verringert sich der Gesamtaufwand, es gibt weniger Testzyklen und dies steigert letztlich die Zufriedenheit sowohl auf Entwicklungs- als auch auf Anwenderseite.

Herausforderungen die den Einsatz von ABAP Unit beeinflussen

Mangelndes Wissen und Qualifikation

Auch im Jahr 2025 bleibt die Herausforderung für Unternehmen bestehen, dass ein signifikanter Anteil der ABAP-Entwickler nicht über das Wissen und Erfahrung verfügt, um effizient automatisierte Tests mit ABAP Unit zu erstellen. Denn dies erfordert einerseits hinreichende Kenntnisse in moderner objektorientierter Programmierung, Trennung der Belange, guter Strukturierung der Software in testbare Einheiten und letztlich Kenntnisse der Unit-Test Methodiken. Dies kann u.a. in der Ausbildung begründet sein und ergibt sich auch daraus, dass Anwendungsentwicklung gute Geschäftsprozesskenntnisse erfordert. Daher ist bei vielen ABAP-Entwicklern die Kenntnistiefe im Bereich der Programmierung sehr gut in Bezug auf prozedurale Techniken und Umsetzungen von Reports und klassischen Anwendungen. Im Bereich des modernen ABAP mit Techniken und Methoden, die in anderen Programmiersprachen lange Standard sind, aber durchaus noch ausbaubar.

Erfahrungsdefizit als Umsetzungshürde

“Ohne Tests keine Tests”

Techniken und Methoden, die ein Entwickler nicht beherrscht, nicht regelmässig anwendet und auch nicht zwingend anwenden muss, werden unter Zeitdruck nicht zum Einsatz kommen. Unter derartigen Rahmenbedingungen wird sich der flächendeckende Einsatz von Unit Tests schwierig umsetzen lassen. Die oben genannten Vorteile werden nicht genutzt und die sich daraus ergebenden Nachteile. Dies führt zu hohen Testaufwänden, Fehlern im Produktivsystem, schwierigen und aufwändigen Anpassungen der Software.

Zeitdruck und die “Definition of Done”

In SAP-Projekten besteht oftmals hoher Zeit- und Erfolgsdruck. Die Zeit für die Umsetzung der Anforderungen ist für Entwickler knapp bemessen und es wird erwartet dass frühzeitig testbare Versionen der Anwendung bereitgestellt werden. Die Definition wann ein Artefakt geliefert wurde, besteht meistens daraus, dass die geforderte Funktionalität erfolgreich im Anwendertest abgenommen werden kann. Die Erstellung von Unit-Tests findet sich idealerweise in Handbüchern und Entwicklungsrichtlinien, ist aber nicht Teil der Abnahme. Eventuell wird das Fehlen von Unit-Tests akzeptiert, da die Funktionalität auch ohne Unit Tests produktiv gesetzt werden kann. Die dadurch entstehenden technischen Schulden sind nicht offensichtlich und werden bewusst oder unbewusst in Kauf genommen.

Rahmenbedingungen für den Einsatz von ABAP Unit

Damit sich ABAP Unit Tests in der Anwendungsentwicklung durchsetzen und effektiv eingesetzt werden kann, ist ein Umdenken bei Entscheidern und Verantwortlichen für den Betrieb von SAP-Software nötig.
Kenntnisse und Wissen zu ABAP Unit muss sich zu einem geforderten und geprüften Skill von ABAP-Entwicklern etablieren. Die Erstellung von ABAP Unit Tests muss in die Definition of Done und den Lieferumfang von Software aufgenommen werden und nicht als optionales To-Do betrachtet werden.

Der Einsatz von ABAP Unit muss einerseits in den Entwicklungsrichtlinien und Handbüchern definiert und vorgeschrieben werden, um eine Verbindlichkeit zu erzeugen. Wie oben beschrieben, wird die formale Definition allein den flächendeckenden Einsatz von Unit Tests nicht hervorbringen.
Um dies zu erreichen müssen neben formalen Voraussetzungen auch Rahmenbedingungen geschaffen werden, die sowohl die oben beschriebenen Herausforderungen als auch die Herausforderungen im moderen ABAP-Entwicklungsumfeld aufgreifen und die Entwicklungsteams befähigen, ABAP Unit Tests in den Entwickleralltag zu integrieren.
Eine ausführliche Beschreibung der nötigen Rahmenbedingungen und in der Praxis bewährte Vorgehensweisen finden Sie im Kapitel
Organisation: Teamorganisation

Die Rolle des DSAG ABAP-Leitfadens für die Umsetzung Ihrer Test Strategie

ABAP Unit erfordert die Berücksichtigung zahlreicher Aspekte von Seiten der Entwicklungsorganisation, der verantwortlichen Personen und der Entwickler. Um ABAP Unit sinnvoll und effektiv anwenden und einsetzen zu können, erfordert es auf Seiten der Entwickler ein gutes Wissen über Softwareentwicklung und moderne Programmierung in ABAP und das Beherrschen von Objektorientierung.
Auf Seiten der Organisation müssen sowohl im Entwicklungsprozess als auch in den Rahmenbedingungen Voraussetzungen geschaffen werden, die die Erstellung von Unit-Tests unterstützen und fördern. Dieser Leitfaden behandelt alle diese Aspekte und vermittelt auf technischer Seite Wissen. Das kann Ihnen helfen, die Maßnahmen in Ihrem Unternehmen abzuleiten und den Entwicklern eine Motivation und Einstiegshilfe sein, in die Welt der ABAP Unit Tests einzutauchen.

Im Folgenden Abschnitt werden die technischen Grundlagen zu ABAP Unit Tests erläutert, Test- und Entwicklungstechniken vorgestellt und auch auf fortgeschrittene Techniken eingegangen, so dass mit den Ausführungen ein gutes Verständnis geschaffen und so die Grundlage gelegt werden kann, dass Unit Tests Teil des Softwareentwicklungsprozess werden.

          <h1 class="no_toc" id="grundlagen-zu-abap-unit-tests">Grundlagen zu ABAP Unit Tests</h1>

Voraussetzungen für ABAP Unit Tests
Allgemeines zu Unit Tests - Begriffsdefinitionen und Erläuterungen
Vorgehen und Methodiken
Weiterführende Links

Voraussetzungen für ABAP Unit Tests

Nachdem im vorigen Abschnitt Herausforderungen und Voraussetzungen vor allem organisatorischer Art angesprochen wurden, gehen wir Im Folgenden Abschnitt auf technische Aspekte und Belange ein, die zu berücksichtigen sind um erfolgreich ABAP Unit Tests zum Einsatz zu bringen.

Trennung von Datenmodell, Geschäftslogik und Präsentationsschicht

Im SAP-Umfeld hat es sich leider etabliert, dass alles, was für den Programmablauf benötigt wird, dort passiert, wo es gerade passt. Die Daten werden mit zusätzlichen SELECTS angereichert, aufbereitet und ausgegeben. Bei einem Doppelklick werden weitere Daten gelesen und es wird ein Popup ausgegeben, das den Anwender über irgendetwas informiert. All dies passiert in einem Stück Software, welches als Business Funktion gemäß der beschriebenen Geschäftsanforderung erstellt wurde und diese mit all dem was nötig ist umsetzt.
So entsteht Code, in der beispielsweise eine Methode create_sales_order einen BAPI aufruft, der Daten verbucht und damit eine Auftragsnummer erstellt. In dieser klassischen, am Geschäftsprozess orientierten Entwicklung, wie sie viele Jahre üblich war und auch heute noch im Einsatz ist, findet keine Trennung verschiedener Belange gemäß dem “Separation of Concerns”-Prinzips statt.

Eine grundlegende Regel von fachkompetenter Arbeit ist, dass Datenbeschaffung, Geschäftslogik und Datenausgabe (Präsentationsschicht) in der Anwendung technisch getrennt sind und sich im Code nicht vermischen. In einem Unit Test gibt es keinen Anwender, der eine Info-Meldung wegklicken kann, was die automatisierte Testbarkeit von solchen All-in-one Programmteilen stark erschwert.

Es gibt Programmbereiche, die nicht mittels Unit Tests überprüft werden können. Dazu gehören alle Programmteile, die von einem Dialog oder anderen Präsentationsfunktionen, wie z.B. ALV-Grid, abhängig sind. Ebenso sollten SAP Funktionen nicht durch eigene Unit Tests getestet werden. Eine Trennung von Datenbeschaffung, Geschäftslogik und Anzeige ist in jedem Fall eine Verbesserung für die Softwarequalität. Unit Tests können einfacher umgesetzt werden, wenn vorhandenen Programmen neu strukturiert (refactored) und nach den Regeln von Clean-ABAP geschrieben werden und den Designprinzipien der Objektorientierung (SOLID) folgen.

Um ein umfangreiches Überarbeiten erstellter Software zu vermeiden, ist daher ein gutes Design der Anwendung essentiell für die Umsetzung von Unit-Tests. Erläuterungen finden Sie hierzu im Kapitel Moderne ABAP Entwicklung und Abschnitt Testbarkeit durch gutes Design.

Unit Tests sind nicht optional - Unit Tests als Teil der Definition of Done

“Erst die Funktion implementieren - dann machen wir die Unit Tests (wenn dann noch Zeit ist).”

Leider ist dieser Satz noch sehr häufig in ABAP Entwicklungsprojekten im Alltag zu finden. Im Vordergrund steht bei Zeitdruck eben die Lieferung der Funktionalität. Erweitern sie Ihre “Definition of Done” und nehmen sie Unit Tests darin auf.
Es wird langfristig äußerst hilfreich sein das frühzeitige Erstellen von Unit Test in den Entwicklungsprozess zu integrieren. Das spätere Erstellen von Tests wird aufgrund von (Projekt-)Zeitdruck kaum funktionieren. Jeder Softwareentwickler sollte stets die Möglichkeit haben, qualitativ hochwertige Software zu erstellen. Hiervon sind automatische Tests ein wichtiger Bestandteil, auch wenn diese Tests länger und umfassender als das eigentliche Programm sein können. Dies ist ein Ausdruck der geschäftlichen Anforderung und Komplexität der Funktion.

TDD (Test-Driven-Development)

Wenn das Stichwort “Unit Tests” fällt, kommt es fast unweigerlich auch zu dem Thema Test Driven Development, kurz TDD. TDD ist ein Programmiervorgehen, bei dem - vereinfacht - zuerst definiert wird, welche Eingaben einer Funktion zu welchen Ergebnissen führen soll. Erst danach wird die Implementierung der Funktion realisiert. Durch das zuvor definierte Verhalten kann überprüft werden, ob die gewünschte Funktionalität gegeben ist.

Es geht an dieser Stelle explizit nicht um die Methode des Test Driven Development. Unit Tests können auch dann sinnvoll eingesetzt werden, wenn nicht nach dieser Methode vorgegangen wurde. Das Wichtigste ist aus unserer Sicht das Verständnis, wie Unit Tests funktionieren und welche Wichtigkeit sie haben.

Als wichtigste Eckpfeiler des TDD sind folgende Fragen vorab zu klären, bevor die Umsetzung der Funktionalität erfolgt:

in welche Funktionen wird die Gesamtfunktion aufgeteilt
welche Schnittstellen haben diese Funktionen
welche Daten werden benötigt um die Tests durchzuführen
welche Funktionen werden nicht mitgetestet und benötigen entsprechenden Testersatz (Mocks, Stubs …)

Der Einsatz von TDD nach reiner Lehre ist nicht einfach und erfordert einige Erfahrung. Aber zumindest die Vorgehensweise sich als Entwickler über die o.g. Punkte Gedanken zu machen führt dazu, dass sich viele Fragestellungen bereits in einer frühen Phase der Entwicklung ergeben und somit später aufwändige (Konzept-)Änderungen und Nacharbeiten mit Nachtests ausbleiben.

Allgemeines zu Unit Tests - Begriffsdefinitionen und Erläuterungen

Einstieg

Unit Tests sind wichtig. Das Erstellen, Verwalten und Entwickeln von Unit Tests erfordert umfangreiche Kenntnisse, die über das reine Schreiben von ABAP hinaus gehen. Das widerspricht der Aussage, dass sich dieses Kapitel an alle Programmierende richtet, unabhängig vom Wissensstand. Das ist jedoch nur auf den ersten Blick widersprüchlich, denn wir wollen mit diesem Kapitel alle erreichen. Wenn jemand noch nicht gut oder gar nicht objektorientiert programmieren kann, sich nicht mit Entwurfsmustern und anderen Programmierparadigmen auskennt, dann sollte das gelernt werden. Unit Test können eine gute Umgebung darstellen Techniken zu erlernen und diese anschließend auf den produktiven Code zu übertragen. Wir wollen Anregungen und Hilfestellungen dazu geben. Gleichwohl können wir an dieser Stelle nur begrenzt Informationen zu diesem Thema bereitstellen.

Empfehlungen

Wir empfehlen Unit Tests

Skills, die beim Arbeiten mit Unit Tests trainiert werden

Objektorientiertes Design z.B. lose Kopplung
Erstellen von testbaren Designs (Inversion of Control & Dependency Injection)
Agile Prinzipien und Methoden der Software Entwicklung z.B. ( S.O.L.I.D )
Test Prinzipien ( F.I.R.S.T )
Erstellen von kleinen Einheiten

Was sind Unit Tests genau?

Unit Tests sind Funktionen, die modularisierte Einheiten (Methoden, Funktionsbausteine) oder ganze Prozesse mit vorgegebenen Funktionen aufrufen und das Ergebnis mit den erwarteten Vorgaben abgleichen.

Folgendes Beispiel demonstriert die Vorgehensweise: Es gibt eine Klasse mit einer Methode, die aus einem Text die Straße und die Hausnummer ermitteln soll. Es werden nun Unit Tests erstellt, die aus bereits bekannten Fehlern testen, ob das erwartete Ergebnis ermittelt wird.

Rufe die Methode ZCL_ADDRESS->SEPARATE_HOUSENO_FROM_STREET mit der Eingabe ABC-Straße 13 auf und prüfe, ob das Ergebnis 13 ist. Sollte das Ergebnis vom erwarteten Wert abweichen, dann schlägt der Unit Test fehlt und erzeugt eine Fehlermeldung in der Testumgebung.

Für die Prüfung des Ergebnisses gibt es eine Reihe von Methoden der Klasse CL_ABAP_UNIT_ASSERT. Die bekannteste Methode ist EQUALS. Sie prüft, ob der vorgegebene Wert gleich dem erwarteten Wert ist. Es gibt noch andere Methoden, auf die wir im weiteren Kapitel eingehen.

Unit Tests werden in der Regel als lokale Testklassen zu einer globalen Klasse definiert. Die Unit Tests werden nur im Entwicklungssystem durchgeführt.

Wann sind Unit Tests sinnvoll?

Beim Thema Unit Tests gibt es in der Regel zwei Lager: Die einen sagen, dass jegliches Coding mit Unit Tests geprüft werden muss (100% Code-Abdeckung). Die anderen sind der Meinung, dass Unit Tests überbewertet werden. Wir sind der Meinung, dass Unit Tests zum Programmieralltag dazugehören und dort eingesetzt werden sollten, wo sie sinnvoll sind.

Was unter “sinnvoll” zu verstehen ist, sollte jedes Team für sich selbst herausfinden. Ebenso sollte bewertet werden, ob eine Funktionalität als “kritisch” eingestuft werden kann. Wenn es eine kritische Geschäftsfunktion gibt, dann sollte die Funktionalität auf jeden Fall über Unit Tests abgedeckt werden.

Besonders prädestiniert für Unit Tests sind Methoden, die eine komplexe Logik haben und/ oder geschäftskritisch sind.

Mocking

Ein sehr wichtiger und hier oft erwähnter Begriff ist das sogenannte Mocking. Generell versteht man unter Mocking, dass Objekte wie z.B: Funktionsbausteine oder Klassen von SAP, die nicht Teil des Unit-Tests sind, durch Stellvertreterobjekte ersetzt werden. Wie ein Mocking erreicht wird, wird in einschlägen Kursen zu ABAP oder auch Fachbüchern vermittelt, daher gehen wir wegen der technischen Detailtiefe hier nicht weiter darauf ein.
Es gibt auch verschiedene Formen des Mockings was im Abschnitt Testtechniken kurz erläutert wird.

Testlevel

Methoden Tests

Tests einzelner Methoden mit dem Fokus die korrekte Arbeitsweise der Methoden sicher zu stellen. Die Tests sollten unbedingt unabhägig von der Datenbank ausgeführt werden.
Aus dieser Definition ergeben sich bereits oft die ersten Grundlagen für ein Refactoring, da viele Methoden mehrere Aufgaben ausführen. Eine große Anzahl oder sehr umfangreiche Unit Tests deuten oft darauf hin, dass Sie eine Methode zerlegen sollten.

Komponententests

Tests ganzer Klassen oder zusammenhängender Komponenten wie eine Klasse und ein BAPI zur Verbuchung. Diese Test sind häufig von der Datenbank abhängig. Hier sollte mit entsprechenden Techniken gearbeitet werden um einen konsistenten Datenbankzustand für jeden Test herzustellen.
Hierzu eignen sich die entsprechenden Frameworks der SAP:

CDS Test Double Framework (Read Access)
ABAP SQL Test Double Framework (Read and Write Access)
siehe Managing Dependencies with ABAP Unit

Integrationstests

Bei Integrationtests werden Teile von oder ganze Prozessen getestet, um das Zusammenspiel der Komponenten abzusichern. Diese Tests sind oft davon gekennzeichnet, dass die Vorbereitung der Ausgangslage an Daten aufwändig ist. Es wird benötigt: Kunde mit Liefersperre, Material ohne bestand, aber mit eingehender Bestellung usw. Hier wird man einen Großteil der Tests auf eine effiziente Bereitstellung dieser Testdaten verwenden müssen.

Vorgehen und Methodiken

Clean Islands

Um zu vermitteln wie eine gute Umsetzung von Unit Tests aussehen kann, können so genannte Clean Islands helfen. Es handelt sich dabei um Pakete oder Klassen die in Bezug auf die Softwarequalität - und auch Unit-Tests - einen Vorzeigestatus haben. Somit dienen sie als Referenz für Teams, Externe und neue Kollegen um analog neue Software zu erstellen.

Unit Tests modularisieren

Unit Tests bestehen aus Code, der ebenso wie Produktcode, modularisiert, gewartet und erweitert werden muss. Es ist fast immer ratsam, einen Unit Test in kleine Methoden zu modularisieren, da es in der Natur der Tests liegt, dass mehrere Fälle identische Ausgangsdaten oder Absicherungen verwenden. Das Ziel muss sein, die Unit Tests übersichtlicher und besser wartbar zu machen.

Vorgehen und Empfehlungen zur Modularisierung von Testcode:

Erstellen Sie für jede Methode ihrer Klasse eine eigene neue Testmethode.
Gibt es verschiedene Testfälle für eine Methode, erstellen Sie pro Fall eine eigene Testmethode (z.B. Erfolgsfall und Fehlerfall)
Kopieren Sie keine Methode. Wenn sie Code benötigen, den Sie bereits geschrieben haben, extrahieren Sie diesen in eine neue Testmethode um diesen wiederverwenden zu können.
Überprüfen Sie dabei immer wieder die bisherigen Tests. Eine Engine die in der Lage ist, Testdaten in verschiedenen benötigten fachlichen Konstellationen zu erstellen, wird Ihnen beim Erstellen von Tests gute Dienste leisten.

Es gibt folgende zusätzliche Möglichkeiten, nach denen ebenfalls modularisiert werden kann:

Methoden zur Zusammenstellung von abhängigen Klassen
Methoden zum Aufbau von Testdaten
Methoden zur Modularisierung von Tests

Code-Abdeckung (coverage)

In den Entwicklungstools kann nachvollzogen werden, welche Code-Strecken beim Ausführen der Unit Tests durchlaufen wurden. Eine 100%-ige Codeabdeckung sollte dabei das Ziel sein.

Bei vorhandenen Klassen, bei denen nicht auf die Trennung geachtet wurde, ist eine 100%-ige Testabdeckung kaum zu erreichen. Man muss den Aufwand eines Refactorings dem Nutzen entgegenstellen. Wenn eine Klasse keine 100%-ige Testabdeckung hat, ist es sicherlich nicht schlimm, aber es erleichtert die Bewertung, wie vertrauenswürdig Unit Tests zu einem Modul einzustufen sind. Wenn es eine Klasse gibt, die zu 100% Geschäftslogik enthält, dann können Sie bei einer Testabdeckung von 100% relativ sicher sein, dass diese Klasse so funktioniert, wie sie funktionieren soll. Wenn eine Klasse jedoch aus einem Mix von Geschäftslogik und Datenpräsentation besteht, dann ist es schwer festzustellen, ob Code-Teile nicht gut per Unit Test getestet werden konnten oder ob sie einfach vergessen wurden.

Weiterführende Links

          <h1 class="no_toc" id="abap-unit-testtechniken">ABAP Unit: Testtechniken</h1>

Was ist mittels ABAP Unit testbar?
Behandlung von Daten in Unit Tests
Testumgebung
Testmethodiken und Prinzipien
Do’s & Dont’s

Technische Grundlagen Objektebene

Was ist mittels ABAP Unit testbar?

“Das kann man nicht testen”

Grundsätzlich ist fast alles mit ABAP Unit testbar. Es gibt Programmbereiche, die nicht mittels ABAP Unit Tests überprüft werden können. Dazu gehören alle Programmteile, die auf einen Dialog angewiesen sind oder Daten darstellen (z.B. ALV-Grid). Für alles Andere gibt es Möglichkeiten diese Programme mit ABAP Unit Tests abzusichern. Anfänglich wird dies aufwändig und mühsam sein. Die Mühe wird sich aber lohnen und schnell auszahlen. Es is definitiv möglich BAPIs, BAdIs, RFCs und IDOCs mit Unitests abzusichern.

Behandlung von Daten in Unit Tests

Die klassische Systemkonfiguration im Entwicklungssystem mit einen Entwicklungs- und einem Testmandanten stellt eine Hürde für den reibungslosen Ablauf von Komponenten- oder Integrationstests dar, da diese meist von Daten der Datenbank abhängig sind, wenn gängige Unit Test Methodiken nicht angewendet werden.
Dies gilt analog für Szenarien bei denen auf dem Entwicklungssystem sich keine Daten in der Datenbank befinden.

Empfehlung
Erstellen Sie ihre ABAP Unit Tests unabhängig von der Datenbank, so dass sie mit Hilfe von Dependency-Injection und Mocks in jedem Mandanten lauffähig sind und das gleiche Ergebnis liefern.
Wird dieses Vorgehen nicht angewendet, die Tests im Mandant x entwickelt, in Mandant y ausgeführt, würden die Tests keine belastbare Aussage liefern und somit seltener oder gar nicht ausgeführt. Analog verhält es sich mit Unit Tests, die abhängig von einer Datenkonstellation auf dem Testsystem sind. Gemäß Unit Test Methodik sind daher direkte Datenbankabfragen mittels Mocking oder Injection-Framework zu vermeiden. Welche Techniken Sie beim Erreichten dieser Unabhängigkeit unterstützen finden sie hier im Abschnitt Erweiterte Techniken

Testumgebung

Die ABAP Unit-Tests können aus den ABAP-Development-Tools heraus oder der SAP-GUI Entwicklungsumgebung (SE80, SE24) erstellt und verwendet werden. Die Vorgehensweise unterscheidet sich nur in Kleinigkeiten. Empfohlen wird hier klar ADT, da hier auch die Verwendung von Test Relations möglich ist.
Die Techniken, die zur Erstellung notwendig sind, ähneln sich jedoch stark. Unit Tests, die in der SE80 erstellt wurden, können auch in Eclipse gewartet und getestet werden und umgekehrt. Die Tastenkombination zum Ausführen der Unit Tests ist in beiden Tools STRG + SHIFT + F10. Andere Funktionen sind in der ABAP Workbench teilweise nur durch das Menü erreichbar während es im ADT eine Tastenkombination dafür gibt.

Im folgenden Abschnitt werden diese Themen behandelt:

Erstellen von Unit Tests
Ausführen von Unit Tests
Ergebnisanzeige
Codeabdeckung (Code Coverage)

Wir gehen davon aus, dass Sie Erfahrung mit dem jeweiligen Tool haben. Aus diesem Grund erfolgt keine Schritt-für-Schritt-Anleitung, sondern lediglich eine kurze Übersicht der wichtigsten Befehle.

Erstellen einer lokalen Testklasse in ADT

Öffnen Globale Klasse
Springen zur View “Test Classes”
Template “testClass”

Tastenkombinationen in ADT

Ctrl + Shift + F9: Unit Test Preview anzeigen
Ctrl + Shift + F10: Unit Tests ausführen
Ctrl + Shift + F11: Unit Tests mit Coverage ausführen
Ctrl + Shift + F12: Unit Test Ausführungsdialog aufrufen
Ctrl + Shift + F2: ATC-Prüfung mit Standardvariante ausführen

Tastenkombinationen in der Workbench

Ctrl + Shift + F10: Unit Tests ausführen
Ctrl + Shift + F11: Lokale Testklassen anzeigen (nur formularbasierter Editor)
Ctrl + F11: Lokale Testklassen anzeigen (nur Quelltext-basierter Editor)

Testmethodiken und Prinzipien

GIVEN - WHEN - THEN

GIVEN-WHEN-THEN ist ein Stil, um Unit Tests zu formulieren. Mit GIVEN wird eine Bedingung angegeben, unter denen der Test stattfinden soll. WHEN beschreibt die Aktion, die durchgeführt wird und THEN beschreibt das erwartete Ergebnis.

Bezogen auf unser Beispiel mit der Hausnummer könnte die Formulierung heißen:
GIVEN ist der Straßenname “ABC-Straße 13”
WHEN die Hausnummer aus diesem String ermittelt wird
THEN sollte die Hausnummer “13” sein

Clean Code in Unit Tests

Oft trifft man auf die Einstellung, dass es in Unit Tests nicht nötig ist sich an Regeln der Code Qualität zu halten (CleanABAP, Namenskonventionen, Modularisierung, …). Schlechte Wartbarkeit und Qualität in Unit Tests wird dazu führen, dass die Tests nicht weiterentwickelt und nutzlos werden. Doppelter Code und fehlende Modularisierung ist hier ebenso zu vermeiden wie in produktivem code.

Unit Test sauber halten

Ebenso ist es zwingend nötig, alle Unit Tests Erfolgreich durchzuführen. Seien Sie hier nicht nachlässig und priorisieren Sie Aufgaben, die es bedürfen den Geschäfts-Code oder den Unit Test zu reparieren, bis wieder alle Tests fehlerfrei ausgeführt werden.

Behandlung von Ausnahmen

SAP empfiehlt: Wenn der zu testende Code in der Lage ist, eine Ausnahme auszulösen, sollte die Testmethode selbst diese nicht behandeln, sondern sie in ihrer Signatur deklarieren (abgesehen von provozierten Ausnahmen), so dass der Testfall fehlschlägt, wenn er zur Laufzeit auftritt.

Aufbau einer Unit Test Klasse

Eine Unit-Test-Klasse hat - im Gengensatz zu einer gängigen ABAP-Klasse - ein paar Besonderheiten. In diesem Kapitel beschreiben wir, wie die Unit-Test-Klasse aufgebaut ist und welche Eigenschaften sie hat.

genereller Ablauf
Risklevel
Duration
Anlage in
- Eclipse
- SE80
SETUP
TEARDOWN
FOR TESTING

Genereller Ablauf

Jede Klasse hat ein Include in dem mehrere lokale Klassen und Text-Klassen definiert werden können. Eine Testklasse beseitzt Attribute, die etwas über die Gefährlichkeit (Risk level) und die Dauer (Duration) der Tests aussagen. Jede Testklasse hat Testmethoden, die mit dem Zusatz FOR TESTING als solche kenntlich gemacht werden. Testmethoden werden in zufälliger Reihenfolge ausgeführt und dürfen nicht voneinander abhängen.

In einer Testmethode wird eine (öffentliche) Methode der zu testenden Klasse ausgeführt und mit einem erwarteteten Ergebnis verglichen. Stimmt die Erwartung überein, dann ist der Test erfolgreich. Die Instanz der zu testenden Klasse wird F_CUT oder CUT genannt. CUT steht für Code Under Test. Vor Ausführung der Tests kann optional die Methode SETUP ausgeführt werden, in der Vorbereitungen zum Testfall vorgenommen werden können (z.B. die Erzeugung der Instanz CUT). Nach Ausführung einer Testmethode können in der Methode TEARDOWN Aufräumarbeiten durchgeführt werden. Es können beliebig viele andere Methoden oder Klassen definiert werden, die zur Unterstützung der Tests dienen.

Risikostufe/ Risk Level

Mit dem Zusatz RSIK LEVEL definieren Sie die Risikostufe der Testfälle

Folgen sie den Vorgaben der SAP zum Risiko Level:

CRITICAL - a test changes system settings or customizing data (default)
DANGEROUS - a test changes persistent data
HARMLESS - a test does not change system settings or persistent data

Grundsätzlich sollten Sie es vermeiden, Tests zu schreiben, die wirkliche Änderungen an der Datenbank vornehmen. Dies ist oft ein Indikator für fehlendes Management von Abhängigkeiten bzw. deren Austausch. Ihr Ziel muss sein, möglichst alle Tests als Harmless definieren zu können. Mit Hilfe der von SAP bereitgestellten Frameworks zum Mocken von Datenbanktabellen und CDS-Views ist dies möglich. Siehe Abschnitt Mocking..

Dauer/ Duration

Mit dem Zusatz DURATION definieren Sie die voraussichtliche Laufzeit der Testfälle. Folgende Kategorien sind möglich. In den Klammen steht die voreingestelle Dauer in Sekunden:

LONG (3600 sec)
MEDIUM (300 sec)
SHORT (60 sec)

Überschreitet ein Test den im System definierten Wert, dann wird der Test abgebrochen und als “fehlgeschlagen” interpretiert.

Die Einstellung der verschiedenen Laufzeiten können sie mit Transaktion SAUNIT_CLIENT_SETUP vornehmen. Auch hier gilt das klare Ziel, dass ihre Tests schnell sein müssen, damit sie immer wieder ausgeführt werden können.

ASSERT

Innerhalb einer Testmethode kann das Ergebnis einer Testmethode mit den Methoden der Klasse CL_ABAP_UNIT_ASSERT geprüft werden. Die Klasse hat viele Methoden, die für entsprechende Vergleiche genutzt werden können. Die wohl am häufigsten gebrauchten Methoden sind:

ASSERT_EQUALS
ASSERT_FALSE
ASSERT_BOUND

Ein ASSERT wird durchgeführt, um den ermittelten Wert mit dem erwarteten Wert abzugleichen. Sie rufen also eine Methode der zu testenden Klasse auf und vergleichen das Ergebnis mit dem, was Sie als Ausgabe erwarten. Die Parameter der entsprechenden ASSERT-Methode heißen dabei immer gleich:

EXP ist der zu erwartende Wert (EXPECTED VALUE)
ACT ist der im Test ermittelte Wert (ACTUAL VALUE)
Die Erwartung kann sein, dass das Ergebnis einen bestimmten Wert hat, eine bestimmte Tabellenzeile in der Ergebnistabelle vorhanden ist oder ein Objekt instaziiert wurde. Das Ergebnis muss dabei nicht direkt aus einer Methode kommen. Sie können auch mehrere Methoden der Testklasse ausführen und am Ende den Wert eines globalen Attributs prüfen.

Beispiel Testklasse

Das folgende Beispiel zeigt die Testklasse LTCL_VERIFY_ADDRESSES zu der globalen Klasse ZCL_ADDRESS. Die die Methode SPLIT_ADDRESS ist dafür zuständig, einen String, der Adresse und Hausnummer enthält, in die Bestandteile Straße und Hausnummer aufzuteilen.

CLASS ltcl_verify_addresses DEFINITION FINAL FOR TESTING
  DURATION SHORT
  RISK LEVEL HARMLESS.

  PRIVATE SECTION.
    DATA cut TYPE REF TO zcl_address.
    METHODS:
      setup,
      strasse_17_juni FOR TESTING,
      abc_strasse FOR TESTING,
      parkallee FOR TESTING.
ENDCLASS.


CLASS ltcl_verify_addresses IMPLEMENTATION.

  METHOD strasse_17_juni.
    DATA(address) = cut->split_address( |Straße des 17. Juni 134| ).
    cl_abap_unit_assert=>assert_equals(
      exp = |Straße des 17. Juni|
      act = address-street ).
    cl_abap_unit_assert=>assert_equals(
      exp = |134|
      act = address-house_no ).
  ENDMETHOD.

  METHOD abc_strasse.
    DATA(address) = cut->split_address( |ABC-Straße 89| ).
    cl_abap_unit_assert=>assert_equals(
      exp = |ABC-Straße|
      act = address-street ).
    cl_abap_unit_assert=>assert_equals(
      exp = |89|
      act = address-house_no ).
  ENDMETHOD.

  METHOD parkallee.
    DATA(address) = cut->split_address( |Parkallee 11 a-f| ).
    cl_abap_unit_assert=>assert_equals(
      exp = |Parkallee|
      act = address-street ).
    cl_abap_unit_assert=>assert_equals(
      exp = |11 a-f|
      act = address-house_no ).
  ENDMETHOD.

  METHOD setup.
    cut = NEW #( ).
  ENDMETHOD.

ENDCLASS.

Methoden zur Zusammenstellung von abhängigen Klassen

Bei komplizierten Testfällen müssen eventuell umfangreiche Vorarbeiten getan werden, damit die eigentlichen Tests durchgeführt werden können. Es sollten zwar so wenig Abhängigkeiten wie möglich vorhanden sein, aber gänzlich vermeiden lassen sich Abhängigkeiten leider nicht immer. Hilfsmethoden können helfen, das notwendige Setup für einen Test vorzubereiten.

Beispiel:

Die Methode prepare_setup( ). erstellt zwei Instanzen, die zur Verifizierung der Adresse notwendig sind:

Strassenverzeichnis
Postleitzahlenkatalog

Hilfsmethoden zum Aufbau von Testdaten

Wenn Testdaten aus vielen Komponenten bestehen (Kopfdaten, Positionsdaten, Partner, Materialien usw.), dann kann das Zusammenstellen dieser Daten umfangreich werden. Entsprechende Hilfsmethoden sind hier unbedingt erforderlich um die Zusammenstellung erleichtern.

Beispiel:

Die Methode get_setup_for_document( doc_id = c_nice_docuemt_id ). stellt alle notwendigen Daten zur Verfügung, die zu dem geforderten Dokument gehören.

Wenn Sie auf Dokumente der Datenbank zurückgreifen müssen, pflegen Sie zentrale Konstanten mit sprechenden Namen und Erläuterungen. Sie werden ansonsten irgendwann nicht mehr wissen welche Eigenarten Beleg 564 hatte.

CONSTANTS:  "! Sales order that has one item, Material ..., not released ... 
             c_order_one_iten_ok

Hilfsmethoden zur Modularisierung von Tests

Bei Tests kann es notwendig sein, dass nicht nur ein Aspekt des Ergebnisses getestet wird, sondern viele. Solche Programmierungen können in der Regel gut in Methoden ausgelagert werden.

Beispiel:

Die Methode verify_address_is_valid( address = data ) prüft nicht nur, ob Straßenname und Hausnummer erfolgreich extrahiert werden konnten, sondern auch, ob die Postleitzahl aus fünf Zahlen besteht und mit dem Ortsnamen übereinstimmt.

Testen von privaten, geschützten und öffentlichen Methoden

Es gibt die Meinung, dass nur öffentliche Methoden getestet werden sollten. Über die Codeabdeckung kann analysiert werden, ob alle Codestrecken durchlaufen wurden. Allerdings kann das Bereitstellen der notwendigen Daten sehr aufwändig sein, so dass es sinnvoll sein kann, die kleineren Einheiten (private und geschützte Methoden) zu testen. Zudem “verwässern” umfangreiche Datenkonstellationen den Zweck eines Unit Tests. Tests für private Methoden können ebenfalls helfen, den Ursprung eines Fehlers schneller zu lokalisieren.

Beispiel Adressaufbereitung:
Nehmen wir an, wir haben eine Klasse, die Adressen entgegen nimmt und analysiert. Die eine Methode SEPARATE_HOUSENO_FROM_STREET haben wir bereits kennengelernt. Zusätzlich gibt es eine Methode CHECK_POST_CODE, die sicherstellen soll, dass die Postleitzahl 5-stellig ist und nur aus Zahlen besteht. Wenn beide privaten Methoden von der öffentlichen Methode CHECK_ADDRESS aufgerufen werden, müssen wir zum Testen immer eine komplette Adresse übergeben. Einfacher und auch deutlicher ist es, wenn wir die privaten Methoden separat testen. Sie können so die eigentliche Funktion der Methode SEPARATE_HOUSENO_FROM_STREET testen.

Unit Tests erweitern

Wenn wir uns das Beispiel mit dem Ermitteln der Hausnummer ansehen, dann gibt es viele Fallstricke, die ein unerwartetes Ergebnis hervorrufen können. Die Eingaben, die zu einem fehlerhaften Ergebnis führen, kennen wir im Vorfeld jedoch nicht. Wir lernen sie erst kennen, wenn sich Anwender beschweren, die ein falsches Ergebnis erhalten. In diesem Fall können die Eingaben, die zu fehlerhaften Ausgaben geführt haben, in einen Unit Test aufgenommen werden. Nach der Änderung des Codings werden alle bereits definierten Unit Tests durchgeführt und der Entwickelnde kann sicher sein, dass alles wie zuvor funktioniert.

Beispiel Testklasse mit Hilfsmethode

In diesem Beispiel wird die Demoklasse aus dem vorherigen Kapitel, die eine Adresse in ihre Bestandteile Straße und Hausnummer aufteilt, aufgegriffen. Diese Klasse hat drei Testmethoden für einzelne Varianten. Da das Schema immer das gleiche ist, wäre es einfacher, wenn die Straßennamen und Hausnummern zusammengesetzt und dann in einer Methode getestet würden.

Also zum Beispiel:

verify_address( strasse = 'Beispielstraße' house_number = '23' ).

Die Testklasse könnte dann wie folgt aussehen:

CLASS ltcl_verify_addresses_helper DEFINITION FINAL FOR TESTING
  DURATION SHORT
  RISK LEVEL HARMLESS.

  PRIVATE SECTION.
    DATA cut TYPE REF TO zcl_address.
    METHODS:
      setup,
      verify_address
        IMPORTING
          street   TYPE string
          house_no TYPE string,

      test_german_standards FOR TESTING.
ENDCLASS.


CLASS ltcl_verify_addresses_helper IMPLEMENTATION.

  METHOD test_german_standards.

    verify_address( street = |Straße des 17. Juni| house_no = |134| ).
    verify_address( street = |ABC-Straße| house_no = |89| ).
    verify_address( street = |Parkallee| house_no = |11 a-f| ).
  ENDMETHOD.

  METHOD setup.
    cut = NEW #( ).
  ENDMETHOD.

  METHOD verify_address.

    DATA(address_string) = |{ street } { house_no }|.
    DATA(address_result) = cut->split_address( address_string ).
    cl_abap_unit_assert=>assert_equals(
      exp = street
      act = address_result-street
      msg = |Streetname should be { street }| ).
    cl_abap_unit_assert=>assert_equals(
      exp = house_no
      act = address_result-house_no
      msg = |House number should be { house_no }| ).

  ENDMETHOD.

ENDCLASS.

Die Testklasse enthält nun nur noch die eine Testmethode TEST_GERMAN_STANDARDS, in der alle Tests durchgeführt werden.

Es gibt eine Hilfsmethode VERIFY_ADDRESS, die einen Straßennamen und eine Hausnummer entgegennimmt, diese zusammensetzt und durch die zu testende Methode SPLIT_ADDRESS wieder aufteilen lässt. Da ein Testfall nun nicht mehr 1:1 einer Testmethode entspricht, wurde der Parameter MSG von CL_ABAP_UNIT_ASSERT=>ASSERT_EQUALS verwendet, um direkt auf den fehlerhaften Testfall hinzuweisen.

Die Testklasse ist nun deutlich übersichtlicher und die Testfälle sind auf einen Blick gut erkennbar.

Diese Variante erlaubt es, auch weiterhin Tests durchzuführen, die nach einem anderen Schema funktionieren.

Hinweis: Dies ist keine Empfehlung, alle Tests in einer Testmethode unterzubringen. Das Beispiel soll lediglich aufzeigen, dass Hilfsmethoden genutzt werden können, um die Unit Tests kompakter, besser wartbar und lesbarer zu gestalten.

Aufteilen von lokalen & globalen Testklassen

Testumgebung

ABAP Unit test können in ADT als auch im SAP GUI ausgeführt und ihre Ergebnisse analysiert werden. Empfohlen wird hier klar ADT, da hier auch die Verwendung von Test Relations möglich ist.

Auflösen von Abhängigkeiten mit Mocking, Faking, Stubbing und Spying

Eine wichtige Eigenschaft von testbarem Code ist, dass (Geschäfts-)Logik, Datenbeschaffung und Präsentation strikt getrennt sind. Wenn dies gewährleistet ist, dann können abhängige Klassen durch nicht-produktive Objekte ersetzt werden. Diese Objekte können unterschiedliche Aufgaben haben und werden dementsprechend benannt. Die folgenden Arten sind möglich:

Mock
Stub
Faker
Spy

Ein Mock-Objekt ist ein Objekt, das dynamisch auf die Eingaben der Aufrufers reagieren kann. Ein Mock-Objekt kann zum Beispiel eine Abfrage in einem externen System oder der Datenbank imitieren und testfallabhängig die gewünschten Daten liefern.

Ein Stub ist ein Objekt mit minimaler Implementierung der zum Testen notwendigen Methoden. Dieses Objekt ist nur dazu da, um den fehlerfreien Aufruf der zu testenden Methoden zu gewährleisten.

Ein Fake-Objekt liefert notwendige Daten nach einem vereinfachten Algorithmus. Beispielsweise könnte das Echte Objekt eine umfangreiche Postleitzahlenprüfung vornehmen, bei der Geodaten, Ortsteile und Postleitzahlen auf Grundlage verschiedener Dienste verifiziert werden. Der entsprechende Faker könnte einfache Prüfungen machen, die für die Durchführung der Tests ausreichend sind.

Ein Spion-Objekt kann Eigenschaften von Stubs, Fakes und Mocks enthalten, übernimmt jedoch zusätzlich noch die Funktion, Zugriffe zu protokollieren. So könnte ein Spy zum Beispiel beim Testen aufgerufen werden; es wird jedoch nicht direkt das Ergebnis geprüft, sondern nur, ob diese Methode aufgerufen wurde. Dieser Typ wird gerne verwendet, um sicherzustellen, dass bei bestimmten Aktionen E-Mails oder andere Nachrichten verschickt worden wären.

Martin Fowler - Mocks Aren’t Stubs

Test-Doubles

Die Verwendung von Test-Doubles ist notwendig, wenn Abhängigkeiten bestehen, die nicht ausreichend aufgelöst wurden oder aufgelöst werden konnten. Mit entsprechenden Test-Double-Frameworks kann das Ergebnis von Datenbankzugriffe oder Funktionsbausteinaufrufen gefälscht werden.

Test-Double-Frameworks sind in der Regel umständlich zu bedienen und sehr unübersichtlich. Mit vielen Definitionen und Methoden müssen Eingabeparameter und die gewünschten Ergebnisse vorgegeben werden. Wenn möglich sollten Sie die Abhängigkeiten eliminieren um auf die Verwendung von Test-Doubles verzichten zu können. Dies ist jedoch nicht immer möglich. Weiterführende Informationen zu den Test-Double-Frameworks stellen wir Ihnen im Abschnitt Erweiterte Techniken vor.

Automatisierte regelmäßige Läufe von Unit Tests

Es gibt mehrere Möglichkeiten Unit Test regelmäßig laufen zu lassen.

Programm RS_AUCV_RUNNER
ATC Läufte
Rest Service ( Communication scenario SAP_COM_0735 )

Empfehlung
Planen Sie die Unit Test eines Systems regelmäßig ein und erstellen Sie Benachrichtigungen hierfür. Für jeden Enwickler sollte es zur Morgenroutine gehören zu prüfen ob alle Test fehlerfrei sind, damit dies gegebenenfalls Daily besprochen werden kann.

Do’s & Dont’s

Im Zweifel einen Unit Test mehr anlegen
weniger in einem Test prüfen
Klasse CL_AUNIT_ASSERT nicht mehr benutzen bzw ersetzen, da sie obsolet ist. Es muss die Klasse CL_ABAP_UNIT_ASSERT verwendet werden.

          <h1 class="no_toc" id="abap-unit-erweiterte-techniken">ABAP Unit: erweiterte Techniken</h1>

Erweiterte Testtechniken mit ABAP Unit

Erweiterte Testtechniken mit ABAP Unit

In diesem Abschnitt finden Sie Erläuterungen und Hinweise zu erweiterten Testtechniken und Frameworks, die im Rahmen von ABAP Unit zur Verfügung gestellt werden. Jede der hier beschriebenen Techniken hat spezifische Einsatzzwecke und bietet Vor- und Nachteile. Bevor diese Techniken eingesetzt werden, müssen die Grundlagen von Unit Tests gut beherrscht werden. Der Einsatz der erweiterten Techniken muss gut gegenüber Standard Unit Test Techniken abgewogen werden.

Test-Double-Frameworks

Sie können Test-Double-Frameworks (TDF) verwenden, um Aufrufe von Methoden, Funktionsbausteinen oder Datenbankabfragen (SELECT) auf Ihre Bedürfnisse anzupassen. Generell funktionieren die TDFs so, dass Sie das Objekt definieren, deren Funktion Sie manipulieren möchten und dann festlegen, bei welchen Eingabeparametern welche Ergebnisse zu liefern sind.

Wenn Sie ein Test-Double-Framework einsetzen müssen, spricht das bereits dafür, dass die Architektur nicht für Unit Tests optimiert wurde. Test-Double-Frameworks sollten erst dann eingesetzt werden, wenn es zu aufwändig oder zu risikoreich ist, die vorhandene Architektur zu ändern.

Ein Grund für die Vermeidung der TDFs ist die umständliche Verwendung. Sie benötigen ein umfangreiches Setup, das bei Änderung oder Erweiterung der Unit Tests ebenfalls angepasst werden muss.

Test-Double-Framework für ABAP Datenbankzugriffe/ CDS Views/ AMDP

SAP stellt Ihnen verschiedenen Frameworks zur Seite um Abhängigkeiten von verschiedenen Datenbankartefakten zu lösen. Diese Frameworks basieren auf Techniken womit die echten Daten in den Tabellen durch vorkonfigurierte MOCK Daten ersetzt werden können.

Ziel ist es hierbei eine stabile wiederholbare Umgebung aufzubauen in der sich Tests beliebig oft wiederholen lassen ohne dass Belege neu erstellt werden müssen.

Eine Übersicht der vorhandenen Möglichkeiten finden Sie in der SAP-Hilfe.

Die Herausforderung liegt in der Identifizierung der Tabellen/ Views und dem Befüllen der Mock-Datenbank. Planen Sie hierfür Zeit in der Entwicklung ein. Schaffen Sie eine Infrastruktur, die es Ihnen für viele Tests ermöglicht auf die Mock Datenbank zuzugreifen. Auf diese Weise profitieren auch andere Geschäftsbereiche von den Daten.

Test-Double-Framework für Funktionsbausteine

Analog zu anderen Mocking Frameworks ermöglicht Ihnen das Test-Double-Framework für Funktionsbausteine die Aufrufe an konfigurierbare Doubles umzuleiten (Klasse CL_FUNCTION_TEST_ENVIRONMENT). Sie sind somit in der Lage für den Unit Test zu bestimmen, wie sich der Funktionsbaustein verhalten soll. Sie sind also nicht auf die Parameter angewiesen, die der Funktionsbaustein ermitteln würde. Somit ist es z.B. einfach möglich die möglichen Fehlerfälle zu provozieren und den Business Code auf korrekte Behandlung derer zu prüfen.

Test-Double-Framewortk für Klassen

Für Klassen stellt SAP ebenfalls ein Test-Double-Framework (Klasse CL_ABAP_TESTDOUBLE) zur Verfügung. Methodenaufrufe von Klassen, die nicht durch anderen Techniken ersetzt werden können, können Sie mit dem Test-Double-Framework steuern. Genau wie bei Funktionsbausteinen können Sie vorgeben, welche Ergebnisse bei welchen Eingabeparametern zurückgeliefert werden sollen.

Test-Seams

Ein Test-Seam ist ein Code-Fragment, das bei der Ausführung von Unit Tests anstelle eines produktiven Codes ausgeführt wird. Die Verwendung von Test-Seams bedingt - im Gegensatz zu Test-Double-Frameworks - die Änderung von produktivem Code. Der im Unit Test zu ersetzende Code wird im produktiven Code von den Schlüsselwörtern TEST-SEAM und END-TEST-SEAM eingeschlossen. Während der Ausführung der Unit Tests können Sie mit dem Block TEST-INJECTION und END-TEST-INJECTION definieren, was dort anstelle des produktiven Codes passieren soll.

Test-Seams eignen sich zum Beispiel, um Benutzerabfragen oder Aufrufe in Remote-Systemen zu umgehen.

Die Technik der Test-Seams ist keine bevorzugte Technik für Unit Tests. Sie sollte nur temporär eingesetzt werden. Test-Seams ersetzen nicht eine sauber gestaltete Softwarearchitektur, die Testbarkeit als Merkmal besitzt. Testseams können gut eingesetzt werden, wenn in bestehende Software oder Legacy Software Unit Tests integriert werden sollen und ein Mocken von Bestandteilen oder Funktionen erforderlich ist. Die Änderung ist minimal und kann deswegen relativ risikolos eingesetzt werden. Mittelfristig sollte die Software jedoch modernisiert und Testseams beseitigt werden.
Siehe Clean ABAP Test Seams

SAP Komponenten wie BAPIs & Funktionsbausteine in Unit Test

Sollten Sie in Ihren Komponenten- oder Integrationstests darauf angewiesen sein, dass ein Funktionsbaustein oder eine Klasse von SAP einen Schritt ausführt, der Teil Ihres Tests sein soll, ist es meist nötig, wiederholbare und stabile Testdaten in den relevanten Tabellen zu haben. siehe Mocking von Datenbanktabellen.

VALUE-Anweisung für Mockdaten automatisch generieren

tbd

Erzeugen von VALUE-Anweisungen aus aktuellen Daten während des Debuggens

-> ADT: Standard -> SAPGUI: [Debugger Data View Extension]https://github.com/objective-partner/abap_debugger_data_view_extension

Erzeugen in ADT aus der Data-Preview für ausgewählte Zeilen und Spalten https://community.sap.com/t5/application-development-and-automation-blog-posts/abap-unit-tests-generate-a-value-statement-for-the-contents-of-an-internal/ba-p/13543137

Mockdaten aus DB-Tabelle erstellen in ADT

tbd ???

Testdatenverwaltung in ECATT-Containern

Die Erzeugung und Verwaltung von vielen verschiedenen Testdaten zu vielen verschiedenen Objekten ist umständlich und aufwändig. Das Tool ECATT (Extended Computer Aided Test Tool, Transaktion SECATT) bietet Ihnen komfortablere Möglichkeiten zur Verwaltung dieser Daten. In den ECATT-Containern können Daten strukturiert verwaltet werden. Sie können auf diese Daten manuell zugreifen oder auch per Programm. Unter Verwendung der ECATT-Container können Sie Testfälle manuell pflegen und einsehen. Wenn ein neuer Testfall hinzukommt, reicht es also eventuell, weitere Werte in die entsprechenden Container einzufügen.

tbd: Achtung: bei Systemkopie sind die Daten verloren! Daten Sichern!

Manuelle Verwaltung

Mit Transaktion SECATT können Sie die ECATT-Container definieren, einsehen und ändern.

Programmatischer Zugriff

Zur Erstellung stabiler Testdaten können ECATT-Testdaten-Container verwendet werden.

Zugriff auf die ECATT Test Daten:

 DATA(lo_tdc_api) = cl_apl_ecatt_tdc_api=>get_instance( 
   i_testdatacontainer         = get_tdc_name( )
   i_testdatacontainer_version = get_tdc_version( ) ).

Diese Testdaten aus den ECATT-Containern können dann in die Mock-Datenbank eingefügt werden.

ABAP sql_environment = cl_osql_test_environment=>create( change_dependencies( tables_to_be_mocked ) ).

!Achtung! “ For reference 2024 the insert from tdc was ~12 seconds / 5 times slower than the manual insert. data tdc_data_description type if_osql_test_environment=>tty_double_tdc_info. sql_environment->insert_from_tdc( tdc_data_description ).

Schneller: sql_environment->insert_test_data

Noch offen und ggf, hier erwähnen Open Source projekte für Unit Testing verschiedene DB Mockiung techniken - Vorteile nachteile FM Mocking etc.

          {: .no_toc} # Weitere Testwerkzeuge

Ergänzend zu den Ausführungen zu ABAP Unit möchten wir Ihnen noch weitere Testwerkzeuge aufzeigen, die im Kontext von Testing in SAP eingesetzt werden können. Diese dienen zur Unterstützung des Testens der Applikationen im Geschäftsprozess Kontext. Diese Werkzeuge sind nicht ABAP-spezifisch, sondern generell im Rahmen der (SAP)-Softwareentwicklung zu sehen.
Dies bedeutet, dass von Seiten der ABAP-Entwicklung keine besonderen Vorkehrungen bezgl. der Tools vorgenommen werden müssen.
Allerdings ist ABAP Unit als Grundlage und Testunterstützung ist Voraussetzung, um grundlegende Fehler in der Entwicklungsphase zu vermeiden, zu entdecken und eine angemessene Softwarequalität sicherzustellen. Ist ABAP Unit umfangreich im Einsatz, können Sie sich beim Testen der Anwendungen mit den hier genannten Tools auf Fehler konzentrieren, die sich aus der Integration und das Zusammenspiel der Anwendungen ergeben. Die Tests werden nicht mehr durch Fehler in tieferen Softwareschichten unterbrochen und somit wird die Anzahl der Testzyklen und damit der Testaufwand signifikant reduziert.

Empfehlungen für Testwerkzeuge

Die Auswahl in diesem Leitfaden beschränkt sich auf die von SAP präferierten und teilweise schon im Lizenzumfang enthaltenen Produkte. Daneben gibt es noch viele weitere Testmanagement-Lösungen auf dem Markt, die zur Unterstützung der ABAP-Entwicklung verwendet werden können.

Testwerkzeuge im SAP Solution Manager

Der SAP Solution Manager ist ein ausgereiftes System für das Application Lifecycle Management, das unter anderem verschiedene Testwerkzeuge enthält.

Test-Suite

Die Test-Suite des SAP Solution Managers besteht im Wesentlichen aus dem Testplan-Management zur Vorbereitung der Tests und einer Tester-App, mit der die Anwender, d.h. die Tester, die vorbereiteten und freigegebenen Testfälle durchführen. Weiterhin stehen für den Testmanager verschiedene Funktionen zur Auswertung und Analyse zur Verfügung.

Im Testplan-Management werden Testpläne angelegt und verwaltet. Das Herzstück ist die Auswahl der Testfälle, die als solche in der Struktur der Lösungsdokumentation (engl. Solution Doumentation, kurz “SolDoc”) abgelegt sind. Diese können dann in kleinere Einheiten, die sogenannten Testpakete, aufgeteilt und den entsprechenden Testern bzw. Testergruppen zugewiesen werden. Auf diese Weise können passgenaue Testpläne, zum Beispiel für Funktionstests, Integrationstests, Regressionstests, Komponententests (engl. “Unit Tests”) oder Akzeptanz- bzw. Abnahmetests (eng. “User Acceptance Tests”) erstellt werden.

Darstellung: Testmanagement im SAP Solution Manager Schematische Darstellung: Testplan mit Testpaketen und Testfällen (Quelle: eigene Darstellung)

Manuelle Testfälle werden oft in Testdokumenten (mit Microsoft Word, Microsoft Excel etc.) beschrieben, in denen die durchzuführenden Testschritte detailliert aufgeführt sind. Außerdem besteht die Möglichkeit, URLs zu hinterlegen, die zu Testfällen führen, welche an einem anderen Ort liegen. Der dritte Testfalltyp im Standard des SAP Solution Managers sind sogenannte Testkonfigurationen, die automatisierte Testfälle ansteuern, die zum Beispiel mittels CBTA, eCATT (!!! falls es den dann noch gibt…) oder mit Tricentis Test Automation erstellt wurden (siehe dazu das Kapitel zu den Testfällen im SAP Help Portal). Als weitere Variante für manuelle Testfälle wurden von SAP Testschritte eingeführt, die allerdings nur nach Installation des Add-on “Focused Build” zur Verfügung stehen.

Die Tester, welche die vom Testmanager bereitgestellten und freigegebenen Testfälle ausführen, bekommen diese in der App “Meine Aufgaben / Tester-Arbeitsvorrat” aufgelistet, mit allen für sie relevanten Informationen. Dort können die Testfälle abgarbeitet werden. Im Falle eines Fehlers kann dieser als sogenannter Testfallfehler (engl. “Test defect”) gemeldet werden, der dann an das jeweilige Support-Team ausgesteuert wird und - nach Behebung des Fehlers - zum erneuten Testen ansteht.

Die Analysefunktionen der Test Suite bestehen aus verschiedenen Reports, die auf vielfältige Weise die Aktivitäten der Tester aufbereiten und teils grafisch darstellen. Der Testmanager hat damit jederzeit die Übersicht über den Stand und den Fortschritt der Tests.

Testschritt-Designer

Aus dem Solution Manager Add-on “Focused Build” (Softwarekomponente ST-OST), das von SAP in erster Linie für die agile Softwareentwicklung konzipiert wurde und seit dem Jahr 2020 kostenlos zur Verfügung gestellt wird, ist beim Testmanagement speziell der Testschritt-Designer hervorzuheben, der auch in Kombination mit dokumentenbasierten Testfällen verwendet kann, so dass sich in einem Testpaket gleichzeitig klassische Testdokumente und Testschritte befinden können. Testschritte sind eine moderne, elegante Möglichkeit um manuelle Testfälle abzubilden, die im Gegensatz zu herkömmlichen Testdokumenten allerdings etwas mehr an Vorarbeit bei der Erstellung verlangen. Andererseits können aus gut dokumentierten Prozessen mit detaillierten Prozessschritten durch wenige Klicks Testschritt-Designer-Testfälle generiert werden.

Mit Focused Build wird eine weitere Tester-App namens “Meine Testausführungen” ausgeliefert, die für Testschritt-Designer-Testfälle optimiert und sehr einfach zu bedienen ist. Diese App beschränkt sich auf die für den Tester absolut notwendigen Funktionen. Sie kann auch für rein dokumentenbasierte Testfälle oder für Testpakete mit gemischten Testfällen verwendet werden und macht die Testfallausführung sehr angenehm. Die “klassische” App “Meine Aufgaben / Tester-Arbeitsvorrat” ist etwas mächtiger, dafür allerdings auch schwieriger zu handhaben. Sie kann ebenso für beide Testfalltypen genutzt werden, wobei beim Aufruf eines Testschritt-Designer-Testfalls in “Meine Testausführungen” abgesprungen wird, was anfangs eventuell verwirrend sein kann.

Darstellung: Möglichkeiten der SAP Solution Manager Test Suite und der Ergänzung aus Focused Build Möglichkeiten der SAP Solution Manager Test Suite (unten) und der Ergänzung aus Focused Build (oben) (Quelle: SAP)

Tipp: Sofern Ihre Anwender ein SAP Fiori-Launchpad als Einstiegspunkt in die SAP-Welt nutzen, betten Sie die Kachel “Meine Testausführungen” als iFrame ein, auf der die Anzahl der offenen Testpakete dargestellt wird, die dem jeweiligen Nutzer zugeordnet sind.

Komponentenbasierte Testautomatisierung (Component-Based Test Automation, kurz CBTA)

Die komponentenbasierten Testautomatisierung ist das Bordwerkzeug des SAP Solution Managers zur Automatisierung von Testfällen und im Standardlieferumfang enthalten.

Mit CBTA können Testfälle für unterschiedliche Technologien wie etwa SAP GUI, SAP CRM Web Client, Web Dynpro ABAP, Business Server Pages (BSP), SAP UI5/FIORI und viele mehr automatisiert werden. Die Erstellung erfolgt mittels eines Testrecorders, der ein Testskript mit den auszuführenden Schritten generiert. Die einzelnen modularen Komponenten (das “C” in CBTA), die bei der Aufzeichnung eines Testskripts erzeugt werden, können wiederverwendet und als zusammengesetzte Testskripte für Ende-zu-Ende-Tests verwendet werden.

Die Testskripts werden in sogenannte Testkonfigurationen gepackt und können darüber in der Lösungsdokumentation - neben manuellen Testfällen und URLs - abgelegt werden.

Tipp: Mit dem Wartungsende des SAP Solution Managers rückt auch das Ende von CBTA näher. Daher ist es ratsam zu überlegen, ob eine zukunftsfähige Drittanbieter-Lösung wie Tricentis Test Automation zur Testautomatiserung vielleicht jetzt schon die bessere Alternative ist.

!!!Kann-ich-den-Link-hier-brauchen??? https://help.sap.com/docs/SUPPORT_CONTENT/sm/3530264810.html

Testwerkzeuge in SAP Cloud ALM

Als Nachfolgeprodukt des SAP Solution Managers, dessen Mainstream-Wartungsende seitens SAP auf Ende 2027 datiert ist, wurde SAP Cloud ALM für die Umsetzung des Application Lifecycle Management entwickelt. Das Cloud-Produkt beinhaltet - wie schon der Solution Manager - unter anderem ein integriertes Testmanagement, das sowohl eigenständig (für manuelle Testfälle) als auch in Verbindung mit einer Testautomatisierungslösung wie Tricentis Test Automation eingesetzt werden kann. SAP Cloud ALM und damit auch dessen Testmanagement-Funktionen werden von SAP kontinuierlich weiterentwickelt.

Ähnlich wie im SAP Solution Manager gliedert sich das Testmangement in SAP Cloud ALM in eine App für die Testvorbereitung von manuellen und automatisierten Testfällen, eine App für die Verwaltung von Testplänen, eine für die Testausführung, eine Analytics-App für die Testausführungsanalyse (!!!ist-das-so???) sowie eine zur Übersicht über Testfallfehler, hier Defekte genannt.

Eine (Stand: Mai 2025) in SAP Cloud ALM noch fehlende Funktion, die von vielen Anwendern im Solution Manager intensiv genutzt wird, ist de Gruppierung von Testfällen innerhalb eines Testplans in Testpakete, mit der Möglichkeit zur passgenauen Zuordnung von Testergruppen inklusive Wiederverwendung (!!!ist-das-noch-so???), wie im Abschnitt Test-Suite dargestellt.

SAP liefert eine große Anzahl an Standardprozessen inklusive Prozessablauf-Diagrammen und der zugehörigen Testaktivitäten aus (!!!nochmal checken!!!), die sehr leicht in SAP Cloud ALM verwendet und bei Bedarf angepasst werden können, ähnlich wie beim Testschritt-Designer aus dem Focused Build-Paket.

Tricentis Test Automation

–> Harald

Tricentis ist ein eigenständiges Unternehmen, das nicht zu SAP gehört, aber durch eine strategische Partnerschaft sehr gut in die SAP-Welt integriert und daher im SAP-Kontext die empfohlene Lösung zur Testautomatisierung ist.

Eine Schnittstelle zwischen dem SAP Solution Manager und Tricentis Tosca existiert schon seit 2017. Im Jahr 2020 wurde die strategische Partnerschaft zwischen SAP und Tricentis weiter vertieft. Seitdem ist die Automatisierungsfunktionalität von Tricentis Tosca im SAP Solution Manager und inzwischen auch in SAP Cloud ALM integriert. Alle SAP Kunden mit einem SAP Enterprise Support Vertrag sind berechtigt, Tricentis Test Automation für SAP (“TTA for SAP”) als Laufzeitlizenz zu nutzen. Darüber hinaus wird die Plattform von Tricentis über den SAP-Vertrieb als SAP Solution Extensions verkauft.

“TTA for SAP” ist eine Untermenge von Tricentis Tosca. Es verwendet die gleichen Konzepte für automatisierte Testfälle wie Tosca selbst, ist aber auf SAP-Anwendungen beschränkt. Weiterhin gibt es Funktionalitäten aus Tosca, die in “TTA for SAP” nicht vorhanden sind, wie z.B. die Testfallentwurfsfunktionen oder das Anforderungs- und Problem-Management.

“TTA for SAP” ist für die Verwendung mit der Test Suite des SAP Solution Manager gedacht. Dabei dient die Test Suite als Testmanagement-Tool (für Tests, Planung, Reporting und mehr) und TTA als Automatisierungs-Tool. Dazu wird in der Test Suite eine Testkonfiguration angelegt, die als Hülle für den automatischen Test dient. Der automatische Testfall kann direkt aus der Test Suite aufgerufen werden. Nach Ablauf des Testfalls wird der Status dann wieder an die Test Suite zurückgemeldet. Dies gilt analog für das Zusammenspiel des Solution Managers mit dem eigenständigen Automatisierungs-Tool Tricentis Tosca.

Tricentis Tosca wird von der SAP als “SAP Enterprise Continuous Testing by Tricentis” (ECT) angeboten.

Auch für Cloud ALM gibt es eine integrierte Lösung zur Testautomatisierung. “Tricentis Test Automation for SAP Cloud ALM” ist ein gemeinsames cloudbasiertes Angebot von SAP und Tricentis. Es kombiniert die Application-Lifecycle-Management-Fähigkeiten von SAP Cloud ALM mit den Testautomatisierungsfunktionen von Tricentis. So werden automatisierte, funktionale und durchgängige Softwaretests für alle browserbasierten SAP Produkte und Anwendungen ermöglicht. Tricentis liefert dazu auch Möglichkeiten zur Testorchestrierung, Ausführungsüberwachung und zum Testreporting. Um diese Funktionalität zu verwenden muss ein Tricentis-Tenant eingerichtet und mit SAP Cloud ALM verbunden werden. Allerdings gibt es wie bei TTA Einschränkungen bzgl. Usern und Speicher. Für die volle Funktionalität muss auch hier ein eigenständiges Tricentis-Tool erworben werden, die “SAP Test Automation by Tricentis”.

Auch für Cloud ALM gibt es eine Schnittstelle zu Drittanbieter-Werkzeugen, das öffentliche “Test Automation API” (Link dazu: https://api.sap.com/api/CALM_TEST_AUTOMATION/overview). Über diese Schnittstelle kann neben Produkten anderer Anbieter auch das umfassende Tricentis-Testautomatisierungstool “SAP Test Automation by Tricentis” angeschlossen werden. Damit sind integrierte Tests mit SAP und Drittanbieter-Software möglich. Auch dieses Produkt von Tricentis kann über den SAP-Vertrieb erworben werden.

…verschiedene Ausprägungen…Lizenzen teilweise schon dabei… · Tosca: Integration in SAP SolMan – Link zu https://documentation.tricentis.com/tosca/2310/de/content/sap_solutionmanager/concept.htm · TTA: Integration in SAP Cloud ALM – Link zu https://support.sap.com/en/alm/partners/test-automation.html

§	Tool für automatische GUI-Tests über sämtliche Technologien (Webseiten, SAP GUI etc.)

(Grafik selber machen auf deutsch, welches Tricentis-Tool für welches ALM-System etc., in Anlehnung an die Darstellung von SAP –> “Quelle…in Anlehnung an…”?) und die einzelnen Punkte kurz beschreiben Optionaler Alternativtext, falls sich das Bild nicht laden lässt

Mögliche Einsatzszenarien für automatisierte Testfälle

Tägliche Smoke-Tests

–> Harald Daily Smoke Tests in Testumgebungen…

Regressionstests

–> Harald Automatisierte Testfälle können hervorragend für Regressionstests in Prä-Produktionssystemen eingesetzt werden… was muss da beachtet werden???
Testdaten etc.?

Quellen (brauchen wir die irgendwo?): SAP Cloud ALM for Implementation: Test Management https://support.sap.com/en/alm/sap-cloud-alm/implementation/sap-cloud-alm-implementation-expert-portal/testmanagement.html?anchorId=section_1012737862 SAP Application Lifecycle Management: Test Automation https://support.sap.com/en/alm/partners/test-automation.html (englisch, abgerufen am …) Tricentis: Die empfohlene Testlösung von SAP https://www.tricentis.com/de/sap

          {: .no_toc} # Empfehlungen

Empfehlungen

Folgend möchten wir versuchen, Ihnen aus den vielen Informationen eine Empfehlung zusammenzustellen, die Ihnen und Ihrem Team einen schnellen und nachhaltigen Start ermöglichen.

Konsens

Unit Tests und damit Code-Qualität sind kein Selbstzweck, sondern ein wichtiger Bestandteil für Ihre produktiven Softwareprodukte. Deswegen gibt es aus unserer Sicht keine Ausrede, Unit Tests nicht zu verwenden.

Es gibt zwei verschiedene Perspektiven, die zusammenpassen müssen:

Entwickelnde müssen Unit Tests erstellen wollen
Das Management muss die Verwendung von Unit Tests unterstützen

Wenn Entwickelnde gezwungen werden, Unit Tests zu erstellen, dies jedoch aus unterschiedlichen Gründen verweigern, dann wird es keine oder unnütze Unit Tests geben. Wenn das Management die Entwickelnden nicht unterstützt und keine Rückendeckung gibt (Schulung, Zeit, etc.), dann wird es ein paar Unit Tests geben, die jedoch nicht ausreichend sein werden.

Verantwortlichkeiten

Wir haben in dem Kapitel ABAP Unit versucht, die Notwendigkeit und die Vorteile von Unit Tests klarzumachen. In welcher Form und in welchem Umfang Sie dies in Ihrer Firma, in Ihrem Team einsetzen, müssen Sie erarbeiten. Aus diesem Grund sollte es eine verantwortliche Person geben, die in der Entwicklungsabteilung als auch auf Managementebene die Weichen stellt und Dinge vorantreibt.

Am Anfang war das Konzept

Ein wichtiger Punkt bei Neuentwicklungen ist, dass ein gutes technisches Konzept erstellt wird. In diesem Konzept sollten Unit Tests berücksichtigt werden. Eventuell ist Test-Driven-Design eine Möglichkeit zur Entwicklung der Applikation. Aber auch hierfür ist es wichtig, dass ein vernünftiges Konzept vorhanden ist. An einem Konzept können erfahrene Personen bereits erkennen, ob Unit Tests möglich sein werden oder nicht.

Einfach anfangen

Wenn wir Ihnen nahelegen, Unit Tests zu verwenden, dann sind wir uns bewusst, dass dies leichter gesagt ist, als getan. Wenn es nur wenig Erfahrungen mit dieser Technik gibt, dann müssen diese vom Entwicklungsteam gesammelt werden. Nur wenn man weiß, welche Voraussetzungen notwendig sind, kann man das Management für die notwendigen Maßnahmen gewinnen.

Aber: Sie müssen anfangen! Am einfachsten ist es bei Methoden, bei denen man denkt: “Die ist ja so simpel, da brauche ich doch keinen Unit Test für!” Aber gerade das sind die Methoden, die den Einstieg einfach machen. Achten Sie darauf, dass keine Datenselektionen vorgenommen oder Benutzerabfragen im Dialog gemacht werden. Machen Sie den ersten Unit Test eventuell mit Kollegen zusammen und teilen Sie Ihre Erfahrungen.

Automatisierte Tests mit Hilfe von ABAP Unit sind ein sehr weites Feld. Es gibt unzählige Methoden, Techniken und Anwendungsgebiete. Deswegen möchten wir an dieser Stelle keine weitere Empfehlung, keinen “Fahrplan” geben, wie es nach Ihren ersten Gehversuchen weitergehen sollte. Wenn Sie sich mit ABAP Unit beschäftigen, werden Sie die Schwachstellen und die Potentiale kennenlernen. Sie werden für sich und Ihr Team einen Weg finden. Lassen Sie sich nach anfänglichen Fehlversuchen nicht entmutigen, sondern bleiben Sie am Ball. In diesem Leitfaden geben wir Ihnen ein Dokument an die Hand, mit dem Sie Hilfe zu vielen Bereichen der automatisierten Tests finden. Es gibt jedoch nie eine Universallösung. Erfahrung ist der sicherste Weg, um Ihre Software qualitativ zu verbessern.

Management

Das Erstellen und Verwalten von Unit Tests ist ein zeitlicher Mehraufwand. Dieser wird durch eine höhrere Softwarequalität und damit geringere Anwendertests oder gar Produktionsausfälle jedoch wett gemacht. Entwickelnde benötigen - gerade in der Anfangszeit - deutlich mehr Zeit für die Erstellung der Unit Tests. Dies muss durch das Management gewollt sein und muss unterstützt werden. Definieren Sie, was Sie vom Management erwarten, aber auch, was das Management dafür bekommt. Suchen Sie sich einen Bereich, eine Applikation oder ein Team, das Erfahrungen mit automatisiertem Testing sammelt. Setzen Sie sich Ziele, was Sie in einem betsimmten Zeitraum erreicht haben wollen.

Weiterbildung

Gerade bei Unit Tests ist es wichtig, dass Sie sich weiterbilden und mehr und mehr Erfahrung sammeln. Die Lernkurve ist sehr steil, aber danach gibt es unglaublich viele Möglichkeiten, Varianten und Techniken. Besuchen Sie Workshops, lesen Sie Bücher und vor allen Dingen: Tauschen Sie sich im Team aus.

Code - Test - Repeat

Unit Tests sind ein wichtiger Bestandteil der Softwareentwicklung. Es ist wichtig, sich damit zu beschäftigen und diese Technik kennenzulernen. Am allerwichtigsten ist es jedoch, dass Unit Tests zu einem unabdingbaren Teil Ihrer Arbeit werden. Unit Tests müssen gewartet, dokumentiert und weiterentwickelt werden. Lassen Sie die Unit Tests nicht in Vergessenheit geraten.

Fazit

Als Fazit zu Unit Tests möchten wir mit dem Zitat von Kapitän Kirk schließen: “Die Vorurteile, die man gegeneinander hegt, verschwinden, wenn man sich kennenlernt.”

    <h1 class="no_toc" id="user-interface-ui">User Interface (UI)</h1>

Einleitung
Empfehlungen / Best Practices
Fiori & SAPUI5
Legacy Technologien

Einleitung

Dieses Kapitel gibt einen Überblick über verschiedene UI-Technologien, die im Kontext von ABAP-System zum Einsatz kommen. Der Hauptfokus liegt relevanzbedingt auf Fiori (SAPUI5). Im späteren Verlauf wird jedoch auch ein Überblick auf ältere und teils weiterhin relevante Technologien gegeben.

Empfehlungen / Best Practices

Für Neuentwicklungen sollte in den allermeisten Fällen eine Fiori-konforme Oberfläche zum Einsatz kommen.

Wann immer möglich sollten neue Applikationen mit Fiori Elements umgesetzt werden. SAPUI5 Freestyle-Apps verlocken gerne dazu, sich durch zusätzliche Freiheiten in erhöhte Komplexität locken zu lassen und führen in der Regel zu deutlichem Mehraufwand.

Fiori & SAPUI5

SAP Fiori bezeichnet die neue User Experience aktueller Lösungen der SAP, die auf Basis moderner Design-Prinzipien entstanden sind. Fiori ist die strategische Oberflächentechnologie der SAP und sollte in den meisten Fällen von Neuentwicklungen als gesetzte Technologie angesehen werden. Der Begriff Fiori meint dabei jedoch teils unterschiedliche Themen:

Fiori als Designsprache moderner Oberflächen
Fiori-Empfehlungen zu guter User Experience
Fiori Elements Technologie zur annotationsgestützten Generierung von Applikationen
Entwicklung von Fiori-Apps mit SAPUI5

Die reinen Design- und UX-Empfehlungen der SAP lassen sich theoretisch auch mit anderen Technologien umsetzen. Damit sich neu entworfene Anwendungen jedoch nativ in die SAP-Umgebung einbinden und für Nutzende ähnlich aussehen und sich ähnlich bedienen lassen ist es wichtig, sich an eben diese Empfehlungen zu halten. Dies sollte im Prozess bereits frühzeitig beachtet werden und je nach Situation auch mit Design Thinking oder Mockup-Erstellungen mit SAP’s Fiori Design Stencils beispielsweise für Figma sichergestellt werden. Sowohl Entwickelnde als auch Fachberater:innen sollten daher mit den Fiori Design Guidelines vertraut sein.

Abgesehen von der rein optischen und interaktiven Betrachtung der Fiori Guidelines wird unter Fiori im Allgemeinen auch die tatsächliche Entwicklung und Technologie hinter den Fiori-Apps bezeichnet. Hier lässt sich zwischen den generierten Fiori Elements Apps ohne FrontEnd-Coding und Freestyle-Applikationen entscheiden, die mit SAPUI5 (also Type- bzw. JavaScript) entwickelt werden. Das Flexible Programming Model bietet eine Mischform aus beiden. Diese verschiedenen Möglichkeiten werden später im Kapitel näher erleutert. Allgemein lässt sich jedoch sagen, dass Fiori-Applikationen als Browser-Website von Anwender:innen konsumiert werden. Daher ist die Nutzung auch nicht mehr auf Endgeräte eingeschränkt, auf denen die SAP GUI installierbar ist - ein moderner Webbrowser ist ausreichend. Somit können Fiori Apps auch auf mobilen Geräten wie Smartphones, Tablets oder AR-Headsets genutzt werden.

Einhergehend mit dieser Trennung geht auch die stärkere Unterscheidung von Front- und BackEnd-Entwicklung als Sie dies vielleicht aus bisherigen SAP-Entwicklungen kennen. Das S/4 System liefert als BackEnd die Datenhaltung, Prüfung von Berechtigungen und den Großteil der Transaktionslogik für Apps. Nach außen hin wird dies als OData Service veröffentlicht. Dieser dient als Schnittstelle für die tatsächliche FrontEnd-App (die im Browser ausgeführte Fiori-App) um Daten zu lesen, schreiben oder Aktionen ausführen zu können. Diese Kommunikation über OData ist per Definition stateless, das BackEnd ist also die Single Source of Truth zum Datenstand und verwaltet den Großteil der Datenlogik. In bestimmten Szenarien kann diese Zweiteilung die Entwicklung verkomplizieren. Beispielsweise entstand dadurch auch die Notwendigkeit des Draft-Konzeptes um die Vorhaltung von Zwischenständen zu Datensätzen zu ermöglichen.

Wenn auch mittlerweile archiviert sei an dieser Stelle dennoch auf den (englischsprachigen) DSAG UI5 Best Practice Guide hingewiesen. In der folgenden Tabelle werden die Vor- und Nachteile von SAPUI5 gegenübergestellt:

Vorteile SAPUI5	Nachteile SAPUI5
Umfassende SAmmlung von Standard-UI-Elementen, die die Implementierung stark vereinfachen.	JavaScript erforderlich (ABAP nur im BackEnd). Daher Skill-Aufbau notwendig.
Modernstes Aussehen	SAP Gateway erforderlich (bei der separaten Installation zusätzliche Kosten)
Theoretisch ist alles möglich, was HTML5 in Verbindung mit JavaScript erlaubt.	In Spezialfällen u.U. fehlende Features und schlechtere Performance gegenüber SAP GUI / ALV.
Nutzung auf Tablets und Smartphones.	Komplexe Apps erfordern mehr Aufwand (Stateless Apps)
Responsive UI (Automatische Anpassung an das jeweilige Endgerät)
Nutzung der Endgerätefähigkeiten wie z.B. Kameras
Native SAP-Fiori-Launchpad-Integration
Relativ neue, ständig weiterentwickelte Technologie. Daher optimale Integration in aktuelle Web-Browser

Fiori Elements

Das Fiori Elements Framework ermöglicht es, größtenteils ohne FrontEnd-Erfahrungen (JavaScript, XML) vollwertige Fiori-Unternehmensanwendungen umzusetzen. Dazu gibt es einige vorgefertigte Floorplans (App-Typen) der SAP, die basierend auf einem OData-Service generiert werden. Der am weitesten verbreitete UseCase ist die Kombination aus List Report und Object Page. Mit diesen Typen lassen sich transaktionale Szenarien umsetzen, in der einzelne Business Datensätze in einer durchsuchbaren Tabelle aufgelistet und in der Object Page übersichtlich angelegt oder geändert werden können. Die Analytical List Page ermöglicht eine standardisierte Anzeige zur Auswertung analytischer Datensätze.

Grundsätzlich ist es für die Erstellung ausreichend, den OData-Service mit UI-Annotationen anzureichern. Hierfür werden im CDS Consumption View beziehungsweise Metadata Extensions die gewünschten Konfigurationen hinterlegt. Über den OData-Service veröffentlicht wertet das Fiori Elements Framework die Annotationen zur Laufzeit aus und generiert die Fiori App dementsprechend. Für die Entwicklung transaktionaler Fiori Elements Applikationen bietet sich insbesondere das ABAP RESTful Application Programming Model (RAP) an. Zur Entwicklung wird auf den DSAG ADT Leitfaden verwiesen, da die nötigen UI Annotationen zur Generierung von Fiori Elements Apps nur in der Entwicklungsumgebung Eclipse angelegt werden können.

Im UI5 Demo Kit finden sich einige offizielle Tutorials und Kurse der SAP zum Einstieg in die Fiori Elements Entwicklung. Grundsätzlich ist auch die Entwicklung mit dem Cloud Application Programming Model (CAP) möglich - im Kontext dieses ABAP Leitfadens jedoch nicht weiter im Fokus.

Fiori Freestyle

Wenn für eine zu entwickelnde Anwendung die von der SAP zur Verfügung gestellten Floorplans nicht ausreichend sind muss die UI-Oberfläche manuell entwickelt werden. Hierfür kommt eine Fiori Freestyle Entwicklung zum Einsatz. Die Fiori-Entwicklung wird mit dem SAPUI5-Framework umgesetzt, hierfür sind Kenntnisse zu JavaScript, XML-Views sowie dem MVC-Konzept notwendig.

Über Fiori Tools lässt sich eine leere Applikations-Hülle mit Anbindung an einen OData-Service erstellen. Die restliche Applikations-Logik muss dann jedoch selbst implementiert werden. Die Darstellung der tatsächlichen Oberfläche wird über XML-Views definiert. Hierfür stellt SAP eine breite Auswahl an Controls zur Verfügung, die bereits viel Implementierungsaufwand ersparen und ein Fiori-konformes Design unterstützen. Diese sind in der SAPUI5 API Referenz nach Version aufgeschlüsselt einsehbar.

Unter dem Namen OpenUI5 wird SAPUI5 auch unter einer Open-Source-Lizenz vertrieben. Hierbei sind allerdings einige Komponenten nicht in der Distribution enthalten. Grundsätzlich lassen sich damit aber nach Bedarf auch ohne Nutzung eines SAP-BackEnds Fiori-Applikationen umsetzen.

Flexible Programming Model

Das Flexible Programmiermodell (FPM) bietet eine Mischform aus generierten Fiori Elements- und manuell entwickelten SAPUI5 Freestyle-Oberflächen. Es steht ab SAPUI5 v1.94 und nur mit OData V4 zur Verfügung. Das FPM ermöglicht es dabei, über eigenständige Container Freestyle-Elemente in einer Fiori Elements Applikation einzubinden. Andererseits können auch Fiori Elements-Bausteine in einer Freestyle-App eingebaut werden. Um einen Eindruck zu den Vorteilen des FPM zu gewinnen bietet sich dieser CodeJam an.

Flexible Programming Model als Mischform von Fiori Elements und Freestyle SAPUI5, © SAP

Legacy Technologien

Dieses Kapitel soll einen kurzen Überblick über bisher nicht genannte Oberflächentechnologien geben. Da diese im Laufe der Zeit immer mehr an Relevanz verlieren wird an dieser Stelle nicht näher auf einzelne Technologien eingegangen.

UI-Technologie	SAP-Roadmap	Kommentar	Empfehlung für Neuentwicklungen
Dynpro (klassisch)	nur noch Support	SAP rät von Neuentwicklungen ab. Geringerer Entwicklungsaufwand, vor allem bei einfachen Reports mit generiertem Selektionsbild. Bei Power-Usern beliebt.	Für kleinere Entwicklungen in vielen Fällen weiterhin sinnvoll, in S/4 Cloud jedoch nicht unterstützt.
Business Server Pages (BSP)	nur noch Support	Durch Web Dynpro abgelöst	Nicht sinnvoll
Webclient UIF	nur noch Support	Im CRM auf Basis der BSP-Technologie entwicklet und im Einsatz	Für klassische CRM-Apps weiterhin relevant. SAP Hybris C4C setzt hier auf SAPUI5 / SAP Fiori
Web Dynpro Java	nur noch Support	Sollte nicht mehr verwendet werden	Nicht sinnvoll
Web Dynpro ABAP inkl. Floorplan Manager	Kleinere Erweiterungen	In Kombination mit Floorplan Manager weniger aufwändig als Standalone.	Stattdessen SAPUI5 in Erwägung ziehen.
SAP Screen Personas	Kleinere Erweiterungen	Konfiguration und Scripting (Java-Script), um existierende Anwendungen auf Basis klassischer Dynpros attraktiver und besser bedienbar zu machen.	Für UI-Überarbeitung existeriender Dynpro-Programme sinnvoll.
CRM Web UI	n/a	Aus SAP Change Request Management bekannte Oberflächentechnologie.	Stattdessen SAPUI5 in Erwägung ziehen.

    <h1 class="no_toc" id="dokumentation-von-abap-entwicklungen">Dokumentation von ABAP Entwicklungen</h1>

Zielgruppe
Inhalt des Kapitels

Zielgruppe

Dieses Kapitel ist an ABAP Entwickler, Software Architekten, technische Schreiber und Entwicklungsleiter gerichtet und basiert auf dem Inhalt der DSAG Handlungsempfehlung Best Practice Leitfaden Development - Praxistipps rund um das Thema ABAP Development”. Das Kapitel wurde an entsprechender Stelle modernisiert und um Inhalt erweitert.

Wir möchten sie mit den Inhalten des Kapitels bei der Einführung und Optimierung ihrer technischen Dokumentationsaufgaben von ABAP Entwicklungen unterstützen und ihnen nach Möglichkeit pragmatische Lösungen anbieten, die sie und ihre Kollegen langfristig bei der Wissensvermittlung über ihre Individualsoftware unterstützt.

Inhalt des Kapitels

Technische Dokumentation dient der Wissensvermittlung und soll dem Leser einen schnellen Einstieg in die Architektur und die Funktionsweise eines Softwaresystems vermitteln, ohne dass man sich auf Quellcode-Ebene mit den Details des Systems auseinandersetzen muss. Fehlt die Dokumentation oder ist sie nicht in ausreichendem Maß vorhanden, führt dies spätestens bei der Weiterentwicklung oder dem Wechsel von Entwicklern zu erhöhten Aufwänden.

Allgemein ist es bei jeder Dokumentation wichtig, das richtige Maß zu finden und die beiden Extreme einer zu umfangreichen und oft veralteten Dokumentation, oder gar keiner Dokumentation zu vermeiden. Abhilfe schafft die Definition klarer, leicht verständlicher, mit Beispielen angereicherte Dokumentationsrichtlinien. Sind die offiziellen Anforderungen an die Dokumentation zu hoch oder zu abstrakt, führt dies in der Regel dazu, dass die Dokumentation entweder gar nicht, oder mit schlechter Qualität erst wird.

Die Dokumentation sollte während der Entwicklung, unbedingt aber vor der Produktivsetzung bzw. Bereitstellung erstellt werden und es sollte keine Produktivsetzung ohne fertige Dokumentation geben. Ansonsten ergibt sich in der Regel ein Mehraufwand oder letztlich eine fehlende Dokumentation.

In nachfolgenden Unterkapiteln finden sie weitere Details und Tipps zu den verschiedenen Dokumentationsobjekten:

Sind sie daran interessiert, wie Künstliche Intelligenz ihre Dokumentationsvorhaben unterstützen kann? Dann schauen sie doch einfach in nachfolgendem Kapitel vorbei:

AI als Werkzeug bei Dokumentationserstellung

          <h1 class="no_toc" id="dokumentation-von-entwicklungsobjekten">Dokumentation von Entwicklungsobjekten</h1>

Überblick
1. Kurztexte
2. Knowledge Transfer Documents (KTD)
Dokumentation im Quellcode

Überblick

Neben Methoden, Funktionsbausteinen und Reports, die Dokumentation im Quellcode enthalten können, existieren weitere Entwicklungsobjekte im ABAP-System, die keinen Quellcode besitzen und daher auf anderem Weg dokumentiert werden müssen. Beispiele dafür sind:

DDIC-Objekte
Transaktionen

Da die Workbench-Dokumentation auch an das Transportwesen angeschlossen ist, steht sie in allen Einzelsystemen einer Systemlandschaft zur Verfügung. Weiterhin kann diese Dokumentation von allen Benutzern eingesehen werden und wird für Reports vom ABAP-System automatisch in die Benutzeroberfläche eingebunden. Ein weiterer Vorteil kann darin bestehen, dass die Dokumentation mehrsprachig geführt werden kann. Auf SAP-Systemen mit SAP_BASIS >= 7.40 können im Quellcode ABAP-Doc-Kommentare verwendet werden. Dies kann als Alternative zur Dokumentation in der ABAP-Workbench verwendet werden. Der volle Funktionsumfang von ABAP-Doc-Kommentaren lässt sich derzeit allerdings nur mit den ABAP-Development-Tools für Eclipse ausschöpfen. Bei Verwendung von Core Data Services zur Definition von DDIC-Objekten können wesentlich mehr Entwicklungsobjekte im Quellcode dokumentiert werden und die Notwendigkeit externer Dokumentation entfällt. Beginnend mit SAP NetWeaver 7.50 lassen sich die ABAP-Doc-Kommentare von Klassen und Schnittstellen als HTML-Dateien exportieren. Die SAP erweitert ihr Repertoire ab ABAP Plattform 7.55 um eine weitere Technologie zur Dokumentation von ABAP-Entwicklungsobjekten. Das Knowledge Transfer Document fokussiert sich auf die neuen Objekttypen, die primär aus dem ABAP RESTful Application Programming Model (RAP) Kontext entstammen. Dieses umfasst unter anderem: CDS Views, Behavior Definitions, Service Definitions, Service Bindings, Annotation Definitions und Paket

Kurztexte

Zu vielen Objekte können Kurztexte angelegt werden, wie eine Beschreibung zu einem Datenelement oder einer Methode.

Knowledge Transfer Documents (KTD)

Seit ABAP Plattform 7.55 gibt es das Knowledge Transfer Document. KTD kann für jedes Element eines Objekts die Dokumentation einzeln erstellt werden. Es basiert auf Markdown-Sprache mit einfacher Textformatierungssyntax.

KTD müssen im selben Paket wie das Entwicklungsobjekt sein. Es wird nicht automatisch mit dem Entwicklungsobjekt transportiert, aber wenn das Entwicklungsobjekt gelöscht wird, wird auch das dazugehörige KTD gelöscht.

BEST PRACTICE
Wir empfehlen, für alle Entwicklungsobjekte und unabhängig vom Quellcode die Dokumentationsfunktion der ABAP-Workbench zu nutzen. Die Dokumentationsfunktion sollte in folgender Reihenfolge angewendet werden, je nachdem für welches Objekt welche Art von Dokumentationsobjekt verfügbar ist: 1. Knowledge Transfer Documents 2. abapDoc 3. Kurztexte Hierbei sollte ausschließlich der Ist-Stand dokumentiert werden, gegebenenfalls angereichert um kurze Verweise auf die Änderungsdokumentation (Transportdokumentation, Defekt-Nummern).

BEST PRACTICE

Wir empfehlen, für alle Entwicklungsobjekte und unabhängig vom Quellcode die Dokumentationsfunktion der ABAP-Workbench zu nutzen. Die Dokumentationsfunktion sollte in folgender Reihenfolge angewendet werden, je nachdem für welches Objekt welche Art von Dokumentationsobjekt verfügbar ist: 1. Knowledge Transfer Documents 2. abapDoc 3. Kurztexte Hierbei sollte ausschließlich der Ist-Stand dokumentiert werden, gegebenenfalls angereichert um kurze Verweise auf die Änderungsdokumentation (Transportdokumentation, Defekt-Nummern).

Dokumentation im Quellcode

Dokumentationssprache

Entwicklungsteams arbeiten heutzutage überwiegend international zusammen. Auch wenn Sie derzeit rein deutschsprachig entwickeln, kann Ihr Projekt im Laufe der Zeit internationalisiert werden. Der Aufwand, der dann durch Koordinationsprobleme oder sogar nachträgliches Übersetzen entsteht, steht in keinem Verhältnis zu dem vielleicht größeren Aufwand durch englische Dokumentation. Es hat sich außerdem gezeigt, dass die Lesbarkeit von Quellcode und Kommentaren durch englischsprachige Kommentare erhöht wird. Denn die ABAP-Befehle selbst sind englisch und im Stil von Sätzen aufgebaut. Der Leser des Quellcodes muss bei englischer Dokumentation also nicht ständig die Sprache wechseln.

BEST PRACTICE
Es sollte im Unternehmen geklärt, was die Kommentierungssprache ist. Die Empfehlung ist in englisch zu kommentieren.

Dokumentation von Änderungen

Ab dem Zeitpunkt der Produktivsetzung eines Programms sollte darauf geachtet werden, dass Änderungen in Programmen angemessen dokumentiert werden. Hier ist das richtige Maß wesentlich: Eine vollständige Versionshistorie aller Änderungen und auskommentierter Quellcode reduzieren die Lesbarkeit des Quellcodes. Trotz dieses Nachteils dokumentieren einige Entwicklungsteams bewusst alle Änderungen im Quellcode, um die Fehlersuche auf Produktiv- oder Testsystemen zu vereinfachen, in denen die Versionshistorie nicht zur Verfügung steht.

BEST PRACTICE
Nachträgliche Änderungen am Quellcode sollten - von Headerkommentaren abgesehen - nur in Ausnahmefällen direkt im Quellcode dokumentiert werden.

Kommentare im Quellcode

Kommentare im Quellcode sollen dazu dienen, Entwicklern das Verstehen des Quellcodes zu erleichtern, sofern dies nicht durch geschickte Gestaltung des Quellcodes allein (Modularisierung, Namenswahl von Methoden und Variablen) erreichbar ist.

Kommentare sind für andere Entwickler und mit zunehmendem zeitlichen Abstand auch für den ursprünglichen Entwickler gedacht.

Stern-Kommentare sollten nur im Programmkopf oder für das temporäre Auskommentieren von altem Quellcode verwendet werden.

Für alle anderen Kommentare empfiehlt SAP, Inline-Kommentare zu verwenden. Diese sollten jeweils vor dem Quellcode stehen, den sie dokumentieren, und genauso eingerückt sein wie dieser Quellcode. Letzteres wird (nur) für Inline-Kommentare auch vom Pretty Printer korrekt durchgeführt.

BEST PRACTICE
Sie sollten die Frage beantworten, „Warum” etwas programmiert wurde und nicht „Was”. Letzteres ergibt sich aus dem Quellcode ohnehin, während die Beweggründe oft nicht klar erkennbar sind. Gerade sie helfen beim Verständnis aber wesentlich weiter. Dabei gilt der Grundsatz: So wenig Kommentar wie möglich, so viel Kommentar wie nötig.

WEITERE QUELLEN

Horst Keller, Wolf Hagen Thümmel: ABAP-Programmierrichtlinien. SAP Press, 2009. ISBN: 978-3-8362-1286-1
Klaus Haeuptle, Florian Hoffmann, Rodrigo Jordão, Michel Martin, Anagha Ravinarayan, Kai Westerholz: Clean ABAP. SAP PRESS, 2022. ISBN: 978-3-8362-8659-6

ABAP Doc

ABAP Doc ermöglicht es Klassen, Interfaces und Funktionsbausteine zu dokumentieren. Die Kommentare bestehen aus einer oder mehrerer kommentierte Zeilen.
ABAP Doc beginnt mit dem Präfix "!. .
ABAP Doc kann verwendet werden um grundsätzliche Informationen zur Klasse, Methode oder Interface direkt im Quellcode zu dokumentieren. Des Weiteren können die Parameter einer Methode über ABAP Doc im Einzelnen mit Dokumentation versehen werden. Diese ABAP Doc Kommentare werden direkt vor deklarative Statements platziert.
In ABAP Doc können zudem HTML Tags zur Formatierung verwendet werden, was die Lesbarkeit und Struktur der Dokumentation erhöht und verschönert.
Bei der empfohlenen Nutzung von ADT ist die Erstellung von ABAP Doc durch Nutzung von Quickfix sehr einfach und effizient durchzuführen DSAG AG ADT Leitfaden: Was sind ABAP Doc

Der Vorteil der Nutzung von ABAP Doc besteht darin, dass diese Kommentare in folgenden Funktionen der ADT angezeigt werden und damit dem Entwickler wertvolle Informationen direkt bei der Code Erstellung zur Verfügung stehen.

ABAP Element Info view
Element Information Popup
Code Completion Liste.

Und diese ABAP Doc Kommentare können aus ADT in eine HTML Datei extrahiert und somit für eine weitere Verwendung ausserhalb des Codes z.B. auf internen Seiten, verwendet werden. Wird der Code und die dazu bestehende ABAP Doc Dokumentation gleichzeitig gepflegt und nach jeder Änderung ABAP Doc extrahiert, ist auch die externe Dokumentation ohne Mehraufwand aktuell. Wird die ABAP Doc Dokumentation strukturiert erstellt, kann diese ausserdem für die Verwendung mit unterstützender generativer AI zur Erstellung von weiteren Dokumentationen verwendet werden (s.Kapitel Künstliche Intelligenz).

          {: .no_toc} # Entwicklungsobjektübergreifende Dokumentation

Überblick

Neben der Beschreibung der vielen Entwicklungsobjekte, die einzelne, sehr spezielle Funktionen im ABAP-System übernehmen, gibt es auch den Bedarf, die größeren Zusammenhänge innerhalb eines Moduls und modulübergreifend darzustellen. Dazu gehören z.B. Antworten auf Fragen wie:

Welche Abhängigkeiten gibt es zwischen den Modulen?
Welche Anwendungen werden bei welchen Geschäftsprozessen verwendet?
Welche Hintergrundjobs laufen wann am Tag / im Monat / im Jahr und welche Entwicklungsobjekte sind davon betroffen?

Für die Beantwortung dieser Fragen findet sich unserer Meinung nach kein geeignetes Ablagemedium innerhalb der SAP-Entwicklungsumgebung, das insbesondere Grafiken gut integriert. Wir empfehlen daher, für die Dokumentation dieser übergreifenden Zusammenhänge auf andere Medien zurückzugreifen. Beispiele dafür sind:

SAP Solution Manager / SAP Cloud ALM
SAP LeanIX für Enterprise Architecture Management
SAP Signavio für Business Prozess Management
Interne (Produkt-)Wikis
Dokumente in gepflegten öffentlichen Verzeichnissen (Portalablage, SharePoint, Fileshare …)

Die Erfahrung zeigt, dass die Herausforderung in diesem Bereich primär in der Frage der Disziplin liegt. Diese Herausforderung kann kein Tool lösen, sondern nur das Entwicklungsteam und die zugehörige Entwicklungsleitung.

Zur Dokumentation der System- und Softwarearchitektur inklusive Entwurfsentscheidungen bietet sich die Verwendung einer Vorlage an, wie z.B. das arc42-Template. Dies kann verhindern, dass wesentliche Aspekte in der Dokumentation vergessen werden und beschleunigt - bei Verwendung einer Vorlage über mehrere Projekte hinweg - die Suche nach spezifischen Informationen. Zudem erleichtert die Festlegung von Vorlagen das Erstellen der Dokumentation parallel zur Entwicklung und die Einhaltung eines angemessenen Abstraktionsniveaus.

Dokumentenvorlagen wie das arc42-Template müssen nicht immer vollständig “ausgefüllt” werden, sondern relevante Teile sollen je nach Art und Umfang des Entwicklungsprojekts identifiziert und der Rest gelöscht werden.

Darüber hinaus kann eine veraltete Dokumentation irreführend sein. Deshalb sollte in allen Dokumenten der Stand und eine Versionierung enthalten sein, um die Aktualität bewerten zu können.

BEST PRACTICE
Es sollte im Unternehmen geklärt werden, wie Dokumentation von Software erfolgen soll.
Es sollte eine einheitliche Plattform genutzt werden, entweder eine strukturierte Ablage, Ticketsystem oder auch ein Prozessdokument mit fortgeführter Dokumentation (versioniert)
Der Aufbau der Dokumente sollte immer gleichartig sein, auch von extern zugekaufter Software, das ermöglicht der Supportorganisation auch dort helfen zu können

Innerhalb einer SAP-Systemlandschaft bietet zum Beispiel der SAP Solution Manager Möglichkeiten zur Projektdokumentation.

Die nachfolgenden Links bieten weitere Informationen dazu.

WEITERE QUELLEN

Das arc42-Template zur Architekturdokumentation, Arc42-Template (aufgerufen am: 19.09.2024)
Stefan Zörner: Softwarearchitekturen dokumentieren und kommunizieren. Carl Hanser Verlag GmbH Co KG, 2021. ISBN: 978-3446469280
Master Guide SAP Solution Manager - Solution Documentation (aufgerufen am: 26.01.2025)
ABAP Development Tools: User Guide - Documentation of Development Objects (aufgerufen am: 26.01.2025)

Dokumentation zur Versionsverwaltung

Transportauftrag

Oftmals hilft es zum Transportauftrag zu dokumentieren

Ticketnummer und Titel des Tickets
Wichtigste Entwicklungsobjekte im Transport
Abhängigkeiten zu anderen Transporten (sofern vorhanden)
Kurzbeschreibung zu Änderungen im Transport Die Dokumentation zu jeder Aufgabe und zu jedem Auftrag lässt sich während der Auftragsbearbeitung innerhalb des Transport Request Editors im Reiter “Dokumentation” erfassen. Die Dokumentation kann bis zur Freigabe laufend erweitert werden. Beachten sie, dass nach der Freigabe des Auftrags die Bearbeitung nicht mehr möglich ist.

Diese Dokumentation auf dem Reiter “Dokumentation” kann man für jeden Transportauftrag erstellen, der in das Produktivsysteme geht. Vermeiden sie redundante Dokumentation und dokumentieren sie keine Transporte von Kopien. Letztlich interessieren nur die Transporte, die ins Produktiv System gehen sollen, bzw. bereits gegangen sind.

WEITERE QUELLEN

SAP Help: Change and Transport System - Request Editor - Writing Documentation (aufgerufen am: 26.01.2025)

Git-Client

Die Verwendung eines Git-Clients wie abapGit oder gCTS protokolliert Code-Änderungen automatisch bei jedem Commit. Zusätzlich werden bei dem Commit Metadaten gespeichert, die eine kurze Beschreibung, sogenannte Commit-Nachricht, den Autor und das Datum enthalten. Die so entstehende Commit-Historie ermöglicht, vergangene Commits zu sehen und die Code-Änderungen nachzuvollziehen. Wird ein Ticket-System, wie zum Beispiel Jira oder Azure DevOps, für die Erfassung der Anforderungen benutzt, hat jede Anforderung an die Entwicklung eine eindeutige ID. Viele Teams haben die Vorgabe oder die interne Vereinbarung, diese ID in den Commit-Nachrichten einzutragen, damit sich die Commits den Aufgaben zuordnen lassen. Wird das konsistent gemacht, lassen sich mittels Freitextsuche in den Commit-Nachrichten alle Commits identifizieren, die zu einer bestimmten Aufgabe gehören. Das erleichtert wesentlich das Wiederfinden und die Überprüfung der Umsetzung im Fall von Bugs. Gleichzeitig lassen sich dadurch ähnliche Aufgaben sehr schnell umsetzen, weil die Entwickler das bereits funktionierende Beispiel finden und verfolgen können.

BEST PRACTICE
Steigern sie die Nachverfolgbarkeit und Transparenz von Änderungen an Entwicklungsobjekten, indem sie im Transportauftrag oder Git-Client die Änderungen dokumentieren - idealerweise mit Bezug zu dem auslösenden Vorgang im Ticketsystem.

          <h1 class="no_toc" id="allgemeine-dokumentations-tipps">Allgemeine Dokumentations-Tipps</h1>

Übersicht

Übersicht

Nachfolgender Abschnitt liefert ihnen leicht anwendbare und nützlichen Tipps, wie sie einen effektiven Umgang mit Dokumentationsaufgaben erreichen können. Die Tipps beschränken sich nicht nur auf die Technische Dokumentation, sondern lassen sich universell auf Dokumentationsaufgaben anwenden.

Goldene Dokumentationsregeln

1. Dokumentation muss einfach zu verstehen sein

Schreiben sie in aktiver Form und verwenden sie kurze Sätze.

Nutzen sie leicht verständliche und einfache Sprache.

Schreiben sie oberflächlich und überfrachten sie den Leser nicht mit zu vielen Details.

Gehen sie auf Details nur dann ein, wenn sie der Zielgruppe einen Mehrwert bieten.

Visualisieren sie Informationen durch den Einsatz von Tabellen und Grafiken.

2. Dokumentation muss einfach zu nutzen sein

Schreiben sie zielgruppenorientiert und setzen sie die domänenspezifische Fachsprache ein.

Verwenden sie einen lösungsorientierten Schreibstil, die den Leser bei seiner Aufgabenbewältigung unterstützen.

Nutzen sie moderne Dokumentationsmittel wie Hyperlinks zur semantischen Kontextnavigation oder wiederverwendbare Textcontainer.

Stellen sie eine einfache Auffindbarkeit und leichte Zugänglichkeit zu der Dokumentation für die Zielgruppe sicher.

Achten sie bei der Verwendung von Informationen und Bildmaterial auf die Vermeidung von Datenschutz- oder Compliance-Verstöße.

Verwenden Sie Dokumentationsvorlagen und stellen sie Referenzdokumentationen zur Verfügung.

Löschen Sie leere Kapitel und Vorlage-Texte, die aus einem Template-Dokument stammen (Diese sind nach der nächsten Aktualisierung der Vorlage veraltet, Sie brauchen sie also nicht mehr!)

3. Dokumentation muss spezifisch und nachvollziehbar sein

Trennen sie die Dokumentation je nach Zielgruppe und Nutzen in unterschiedliche Dokumentationsartefakte, wie z.B. Administrationshandbuch, Anforderungsdokumente, Technische Dokumentation, etc. auf.

Nutzen sie ein Versionsverwaltungssystem für die Dokumentationsartefakte um über die Versionshistorie vorgenommene Dokumentationsänderungen einfach nachzuvollziehen.

4. Dokumentation muss einen sinnvollen Wertebeitrag liefern

Der Dokumentationsnutzen muss größer sein als die Kosten das Dokument zu erstellen und aktuell zu halten.

Binden Sie die Autoren und die Leser, für die die Dokumentation geschrieben wird, in den Definitionsprozess der Dokumentationsrichtlinien mit ein.

    <h1 id="formulare">Formulare</h1>

In diesem Kapitel erfahren Sie mehr über die Fomulartechnologien, welche noch relevant sind und wo die Zukunft der Formulare liegt.

          <h1 class="no_toc" id="formulartechnologien">Formulartechnologien</h1>

SAPscript (1992 R/3)
SmartForms (2001)
Adobe Forms
1. SAP Interactive Forms by Adobe (2005)
2. SAP S/4HANA Forms (2015 S/4HANA)

Im Laufe der Jahre hat SAP verschiedene Formulartechnologien herausgebracht. Inzwischen gibt es drei verschiedene Technologien, welche in S/4HANA verfügbar sind. Dadurch herrscht bei vielen Unternehmen z.T. eine große Mischung was die Verwendung der verschiedenen Formulartechnologien angeht. Dementsprechend müssen die zuständigen Entwickler das entsprechende Knowhow für die verwendeten Formulartechnologien vorhalten.

Allgemein ist noch auf das Ende der Unterstützungsdauer für die Formulartechnologien SAPscript und SmartForms hinzuweisen, welche im Jahr 2040 liegt (siehe auch die Hinweise 2791338 und 2900377).

SAPscript (1992 R/3)

Auch im Jahr 2025 haben sehr viele Unternehmen weiterhin SAPscript Formulare im Einsatz. Häufig sind dies seit Jahren oder z.T. Jahrzehnten bestehende Formulare. Deshalb müssen ABAP Entwickler sich auch weiterhin mit dieser Technologie auskennen um ggf. Anpassungen an den Formularen vornehmen zu können.

Die Übertragung der Daten vom Druckprogramm an das Formular erfolgt per globaler Variablen. Die Variablen müssen exakt gleich im Druckprogramm und im Formular benannt werden, um eine automatische Datenübertragung zu gewährleisten.

Wird ein Formular in anderen Sprachen benötigt, so muss das Formular mit dem selben Namen, aber in der entsprechend anderen Sprache, in der Transaktion SE71 angelegt/gespeichert werden, um die Übersetzung durchführen zu können.

Während der Laufzeit können SAPscript Formulare gedebugged werden. Dafür muss der Debugger in Transaktion SE71 im Menü unter „Hilfsmittel“ als erstes eingeschalten werden. Anschließend wird das Druckprogramm / die Transaktion zum Prozessieren des Formulars ausgeführt.
Das Debuggen ist relativ unkomfortable und eigentlich nicht mehr zeitgemäß. Es wird jedes Textelement angesprungen, was z.T. zeitaufwändig ist. Werte von Variablen kann man sich anzeigen lassen in dem der Variablenname ohne „&“ im Debugger eingegeben und mit ENTER bestätigt wird.

Mittels Funktionsbaustein OPEN_FORM wird das SAPscript Formular aufgerufen.

Transaktion	Beschreibung
SE71	SAPscript Editor
SE72	SAPscript Stil
SE78	Verwaltung Formulargrafiken
SO10	(SAPscript-) Standardtexte
TXBA	Verwendungsnachweis Textbausteine

SmartForms (2001)

Im Vergleich zu SAPscript hat SmartForms eine modernere SAP GUI Oberfläche, zur Gestaltung von Formularen. Ab dieser Technologie wurde auch mit einer Schnittstelle zur Datenübertragung zwischen Druckprogramm und Formular gearbeitet. Somit ist jedoch auch eine Möglichkeit mehr da, wo sich evtl. Coding für eine Datenbeschaffung bzw. –steuerung verbergen kann.

Bei dieser Technologie wurde die Mehrsprachigkeit von SAP besser umgesetzt als im SAPscript. Hier kann mittels Transaktion SE63 übersetzt werden und es muss nicht das komplette Formular in einer neuen Sprache angelegt werden. Des weiteren wurde eine Anbindung an das SAP Transportwesen integriert. Leider fehlt genauso wie bei SAPscript eine Versionierung der Formularanpassungen im Standard. Dies macht es erforderlich einen manuellen Prozess zu gestalten, mit dem gewährleistet wird auch kurzfristig auf einen älteren Formularstand zurückgehen zu können. Ein Beispiel hierfür wäre, dass anzupassende Formular unter einem neuen Namen (ggf. mit Datumsangabe im Namen) im Entwicklungssystem vor der Änderung in ein lokales Paket zu kopieren und somit diesen letzten im Produktivsystem funktionierenden Stand zu sichern. Stimmen Sie sich bezüglich Vorgehen und Namenskonvention unbedingt in ihrem Entwicklungsteam ab!

Der Name des Schnittstellenbausteins wird vom System generiert und unterscheidet sich von SAP System zu SAP System (Entwicklung, Qualitätssicherung, Produktion). Daher ist es nötig den Funktionsbaustein „SSF_FUNCTION_MODULE_NAME“ im Druckprogramm aufzurufen um den tatsächlichen Namen (Importing-Parameter FM_NAME) des generierten Funktionsbausteins zur Laufzeit im jeweiligen SAP System zu ermitteln.

Möchte man ein SmartForms Formular debuggen setzt man am Besten einen Breakpoint im generierten Schnittstellenfunktionsbaustein. Den Namen des Funktionsbausteins kann man sich über die Transaktion SMARTFORMS im Menü „Umfeld“ anzeigen lassen. Diesen Funktionsbaustein dann z.B. mittels Transaktion SE37 oder SE80 anzeigen und an entsprechender Stelle einen Breakpoint setzen.

Der SAP Standard liefert diverse Testprogramme und Testformulare aus. Diese beginnen mit „SF_*“.

Transaktion	Beschreibung
SMARTFORMS	SmartForms Editor für Formulare und Stile

Adobe Forms

SAP Interactive Forms by Adobe (2005)

Lassen Sie sich von dem Teil „Interactive“ im Namen nicht täuschen – hierbei handelt es sich sehr wohl um „Druckformulare“ und nicht ausschließlich um interaktive Formulare.

Das Formularlayout wird mittels LiveCycle Designer (LCD von Adobe) in der Transaktion SFP gestaltet. Der LCD muss dafür im SAP GUI installiert sein. Ebenfalls in der Transaktion SFP wird die Schnittstelle und der Kontext des Formulars angelegt und bearbeitet.

Folgende Funktionalitäten werden bei der Formulargestaltung mit SAP Interactive Forms by Adobe im Vergleich zu SAPscript und SmartForms unterstützt:

Grafiken können direkt eingebettet werden
Objekte können gedreht werden
verschiedene Seitenausrichtungen in einem Formular möglich
Grafische Elemente (Falzmarken) möglich
Wiederverwendung komplexer Layoutelemente
Verwendung von TrueType-Schriftarten möglich
Barcodes können auf vielen Druckern gedruckt werden (Postscript, PCL, PDF und Zebra)
Barrierefreiheit möglich
Drag&Drop Funktion zum Positionieren von Objekten

Adobe Formulare bestehen bzgl. Layout aus verschiedenen Objekten:

Masterseite:
ein oder mehrere Masterseiten sind pro Formular möglich und sind die oberste Ebene eines Formulars um das Formular zu strukturieren. Hier werden Informationen, welche sich auf jeder Ausgabeseite wiederholen sollen platziert, ebenso wie die Größe und der Platz des Inhaltsbereichs definiert.
Inhaltsbereich:
Bereich zur Ausgabe der dynamischen oder statischen Inhalte.
Inhaltsseite:
enthält die Inhalte, die einem Inhaltsbereich einer Masterseite zugeordnet werden.

Um diese Objekte zu pflegen und zu bearbeiten, muss im Layoutbereich der Transaktion SFP zwischen den Tabreitern „Designansicht“ und „Masterseiten“ gewechselt werden.
Der Tabreiter „PDF-Vorschau“ ermöglicht eine Vorschau auf das Formularlayout.

Tipp:
Wird bei Bearbeiten > Formulareigenschaften > Vorschau eine XFD.xml Datei mit Beispieldaten (welche z.B. aus einem Test- oder Produktivsystem generiert und heruntergeladen wurde) hinterlegt, so werden diese Formularinhalte dann auch in einem Entwicklungssystem unter “PDF-Vorschau” angezeigt. Dies ist äußerst hilfreich um z.B. inhaltsabhängige Formatierungen zu testen o.ä.

Vorschau

Hinweis:
Der LCD lässt Anpassungen im Anzeigenmodus zu. Diese können NICHT gespeichert werden!
Vergewissern Sie sich also vor der Arbeit an einem Adobe Formular, dass Sie sich im „Ändern-Modus“ der Transaktion SFP befinden.

Die Schnittstelle ist ein eigenständiges Objekt mit einem eindeutigen Namen. Sie kann mehrfach verwendet werden und stellt die Zuordnung der Anwendungsdaten, z.B. aus einem Druckprogramm, zum Formular dar.

Aufbau

Folgende Schnittstellentypen stehen zur Verfügung:

ABAP Dictionary basierte Schnittstelle
XML Schema basierte Schnittstelle
Smart Forms kompatible Schnittstelle

Der am häufigsten verwendete Schnittstellentyp ist die „ABAP Dictionary basierte“ Schnittstelle.
Die Schnittstelle besteht aus drei konkreten Bereichen:

Formularschnittstelle
mit den Unterbereichen: Import, Export, Ausnahmen
Globale Definitionen
Zur Definition von Variablen um zusätzlich zu Daten der Formularschnittstelle auch andere Daten speichern zu können.
Initialisierung
Möglichkeit zusätzliche Daten im Formular nachzulesen. Das Coding sollte kurz und knapp gehalten werden. Der Editor hat an dieser Stelle einige Einschränkungen wie z.B. keine Vorwärtsnavigation und kein Pretty-Printer.

Empfehlung Business Logik in eine Klasse auslagern, welche hier aufgerufen wird.

Hinweis:
Um die Übersichtlichkeit nicht zu verlieren und die Logik des Formulardrucks nicht zu komplex zu machen, sollte vor jeder Implementierung überlegt werden, ob das nötige Coding im aufrufenden Druckprogramm hinterlegt wird oder in der Formularschnittstelle. Die Entscheidung hängt natürlich auch davon ab, ob ein SAP Standarddruckprogramm verwendet wird, oder ein kundeneigenes Druckprogramm.

Wie bei SmartForms wird auch bei Adobe Forms Formularen ein vom SAP System generierter Funktionsbaustein benötigt, um das Formular auszugeben. Da dieser Funktionsbausteinname ebenfalls wie bei SmartForms von System zu System unterschiedlich ist, muss der Funktionsbaustein FP_FUCTION_MODULE_NAME verwendet werden, um zur Laufzeit den richtigen Namen des Funktionsbausteins zu ermitteln.
Grundsätzlich hat der generierte Funktionsbaustein die gleichen Import- und Exportparameter wie die Formularschnittstelle (SFP), außerdem sind die Kontextobjekte ebenfalls enthalten.

In das Debugging eines Adobe Formulars kann ebenfalls mittels Breakpoint im generierten Funktionsbaustein eingestiegen werden.

Adobe Forms Formulare können mittels der Transaktion SFP versioniert werden. Dies kann manuell erfolgen oder wird automatisch durchgeführt, sobald ein Transport vom Entwicklungssystem in ein anderes SAP System erzeugt wird.

Die Übersetzung eines Adobe Formulars kann direkt in der Transaktion SFP durchgeführt werden (Menü: Springen > Übersetzung) oder mittels Transaktion SE63 (Menü: ABAP Objekte > Andere Langtexte > FS Formulare und Stile > PDFB PDF- basierte Formulare).

Der SAP Standard liefert diverse Testprogramme und Testformulare aus. Diese beginnen mit „FP_TEST*“.

Transaktion	Beschreibung
SFP	Adobe Form Builder für Formulare und Formularschnittstellen

SAP S/4HANA Forms (2015 S/4HANA)

Grundlage sind Adobe Formulare mit Gateway-Schnittstellen, deren Datenbeschaffung mittels Gateway-Services (also keine klassischen Druckprogramme) erfolgt. Die Pflege erfolgt mit Fiori Apps und somit sind “SAP S/4HANA Forms” public-cloud-fähig.

Das Layout wird ebenfalls mit dem LiveCycle Designer, jedoch als standalone, designed. Hierbei ist zu beachten, das die bearbeiteten Objekte manuell in Transportaufträge aufgenommen werden müssen (mittels Fiori-App ID F1589) und es keine automatische Objektsperre gibt.

Ebenso wie die “SAP Interactive Forms by Adobe” benötigen die SAP S/4HANA Forms einen Adobe Document Service (ADS -> SAP Forms Service by Adobe).

Zu nennen ist an dieser Stelle, dass kundenindividuelle Bedingungen nur sehr beschränkt abgebildet werden können.

Diese Formulartechnologie ist nur zusammen mit der Ausgabelösung S/4HANA Output Control (siehe Abschnitt XYZ) möglich.

Hinweis:

lokale Bearbeitung des Layouts / Formulars -> daher muss sich im Team abgestimmt werden!
keine autom. Transportanbindung -> Bedenken Sie das Sie alle Objekte manuell zusammensuchen und in einen Transport aufnehmen müssen.

App ID	Beschreibung
F1434	Formularvorlagen pflegen
F2894	Texte verwalten
F2761	Logos verwalten
F1589	Objekte in Transporte aufnehmen

Hinweis: Um diese Fiori Apps finden zu können muss die Katalog-ID SAP_BASIS_TCR_T dem angemeldeten Benutzer über eine Rolle zugewiesen werden (Transaktion PFCG).

Transaktion PFCG

Zuordnung Katalog

Zuordnung Benutzer

Adobe Fragments

Es handelt sich hierbei um die Wiederverwendung von Masterformularvorlagen. Dadurch lassen sich Ausgaben aus unterschiedlichen Teilen zusammensetzen. Es wird zwischen den folgenden zwei Teilen unterschieden:

Masterformular
Kopf- und Fußbereich
Findung durch Customizing in Abhängigkeit von Organisationsebenen wie z.B. Buchungskreis
Inhaltsformular
z.B. Rechnung oder Bestellung
Findung durch BRF+ in Abhängigkeit zur Ausgabeart (z.B. Bestellung)

Wichtige Fragmente sind z.B:

SOMU_FORM_MASTER_A4
SOMU_FORM_MASTER_LETTER

Darstellung im SAP-GUI

Darstellung in Fiori

Fragments

Adobe Fragments sind nur im Zusammenhang mit Output Control nutzbar

          {: .no_toc} # Ausgabelösungen

Im Folgenden erhalten Sie einen Überblick über die möglichen Ausgabelösungen.

Nachrichtensteuerung (NAST)

Mit der Nachrichtensteuerung werden verschiedene Ausgabearten wie Drucken, E-Mail, EDI, Workflows, Systemintegration (ALE) und Sonderfunktionen im SAP pro Nachricht zu diversen Modulen (z.B. SD und MM) gecustomzied. Über die sogenannte Konditionstechnik wird die produktive Ausgabe von Formularen und Etiketten gesteuert. Hinter einer Nachricht liegt die Zuordnung des Druckprogramms und des Formulars, welche angestoßen werden, wenn eine Nachricht erzeugt wird.

Die Transaktion NACE dient als zentraler Einstiegspunkt zur Pflege der Nachrichtenfindung pro Applikation. Die dort gepflegten Einstellungen werden in der Datenbanktabelle TNAPR gespeichert.

Hinweis:
Eine Auswertung aller erzeugten Nachrichten kann über die Transaktion TAANA für die Datenbanktabelle NAST erstellt werden. Hierfür muss diese Transaktion im Produktivsystem ausgeführt werden. Um die Auswertung Jahresweise durchzuführen muss vorher ggf.noch ein neues „virtuelles Feld“ (ERYEAR) hinzugefügt werden. Die Ergebnisliste kann als Excel-Tabelle heruntergeladen werden und dort für eine leichtere Auswertung zur Pivot-Tabelle umgestellt werden.

Eine solche Auswertung empfiehlt sich, um sich einen Überblick zu verschaffen, welche Nachrichtenarten überhaupt und hauptsächlich verwendet werden. In welchen Sprachen werden meine Belege (Formulare) ausgegeben und wie groß ist das jeweilige Volumen. Dies hilft bei einer weiteren Planung von Umstellungs- und Go-Live Szenarien.

Eine genaue Anleitung zur Nutzung der Transaktion TAANA finden Sie unter folgendem Link (HIER SOFTWAY LINK ERLAUBT BEI YOUTUBE????).

Pflege der Tabelle

Pflege der Felder

Post Processing Framework (PPF)

Das PPF dient der Automatisierung von bestimmten Aktionen in der Lieferabwicklung zur Ausgabe von Dokumenten von Belegen per Drucker oder per E-Mail. Verwendung findet es z.B. im eWM und TM. Die Pflege erfolgt über die Transaktion SPPFCADM.

Druck-Workbench

Die Ausgabe von Dokumenten erfolgt über die Definition von Korrespondenzarten. Verwendet wird sie vor allem als Branchenlösung im IS-U Bereich (Energieversorger), ist aber auch außerhalb von IS-U grundsätzlich verfügbar. In der Druck-Workbench wird die Datenversorgung eines Anwendungsformulars gekapselt. Es können zur Datenermittlung SAP Standard Objekte oder kundeneigene Objekte verwendet und hinterlegt werden. Mittels Transaktion EFRM werden die relevanten Einstelllungen vorgenommen werden.

Applikationsspezifische Lösungen

Applikationsspezifisches Customizing bestimmt die Ausgabe von Dokumenten. Diese Art der Ausgabelösung wird z.B. im FI, PP und QM verwendet. Im FI zum Beispiel wird die Findung des Mahnformulars abhängig von der Mahnstufe durchgeführt.

S/4HANA Output Control

Mit SAP S/4HANA bietet SAP eine weitere Ausgabelösung mit dem Namen „SAP S/4HANA Output Management“ an. Diese beinhaltet den wiederverwendbaren Service „SAP S/4HANA Output Control“, welcher für viele komplexe Ausgabeszenarien verwendet werden kann. Auf Ebene von Organisationseinheiten kann die Findung von Masterformularvorlagen, Logos und allgemeine Kopf- und Fußtexte gecustomized werden. Mit dieser Ausgabelösung können sogenannte „Adobe Fragments“ verwendet werden. Siehe hierzu den entsprechenden Abschnitt. Im Vergleich zur Nachrichtensteuerung (NAST) haben Sie mit dem Output Control die Einschränkung, dass keine Workflows und Sonderfunktionen hinterlegt werden können.

Output Szenarien

Hinweis:
In diesem Zusammenhang wird oft BRFplus (oder BRF+) als Ausgabelösung genannt. Dies ist falsch. BRFplus ist eine optionale Möglichkeit um eine Konfiguration für die Dokumentenausgabe zu hinterlegen (= ein Regelwerk, ähnlich der Konditionstechnik NAST).

Die Einstellungen im S/4HANA Output Control erfolgt in der GUI über den folgenden Pfad:
Transaktion SPRO > Anwendungsübergreifende Komponenten > Ausgabesteuerung

Unter Hinweis 2791338 finden sich FAQs zum Thema Ausgabesteuerung.

          <h1 class="no_toc" id="adobe-document-services">Adobe Document Services</h1>

ADS On-Premise
SAP Forms Service by Adobe (Cloud-ADS)

Adobe Document Services – auch kurz „ADS“ genannt – wird von SAP Interactive Forms als auch SAP S/4HANA Forms benötigt, um die gewünschten Datei- oder Druckformate zu erzeugen (Rendering). Mit anderen Worten handelt es sich hierbei um die Services, welche die Dokumente zur Laufzeit erzeugen und generieren.

Die erzeugten Dateiformate sind PDF oder PDF/A. Das Format PDF/A stellt hierbei eine Variante des PDF dar, welche verwendet wird um Langzeitarchivierung sicherzustellen. Damit können Dokumente, unabhängig von der verwendeten Software, immer wieder reproduziert werden, da alle relevanten Informationen in der Datei eingebettet sind.

Die folgenden wichtigsten Druckformate können von den ADS erzeugt werden:

PCL
ZPL
PostScript

Abhängig von der ADS Version werden auch die Druckersprachen z.B. IPL, DPL oder TPCL unterstützt.

Bei den Adobe Document Services muss zwischen zwei Versionen unterschieden werden. Einer lokalen on-premise Version „lokalem ADS“ und einer Cloud Version „SAP Forms Service by Adobe (Cloud-ADS)“.

ADS On-Premise

SAP Wartung und Support auf
- SAP NetWeaver Application Server Java bis 2027 (erweiterte Wartung bis 2030)
- SAP S/4 HANA Java bis 2030
Die Nachfolgelösung wird auf SAP HANA Extended Application Services Advanced Model (XSA) laufen und ist für Q1 2027 mit dem S/4 HANA 2025 FPS03 geplant.
Für Druck-Formulare lizenzkostenfrei
Blog zur Maintenance Strategie von SAP

SAP Forms Service by Adobe (Cloud-ADS)

Läuft als Service auf der SAP BTP (Cloud Foundry Environment)
Bereitstellung und Wartung durch SAP
Zusätzliche Informationen unter Hinweis 2219598

Ob die Adobe Document Services in Ihrem System eingerichtet und angebunden sind, können Sie mit dem Testprogramm FP_TEST_00 (Form Processing – Zentrales Testprogramm) schnell und zuverlässig testen.

Weitere Testprogramme sind:

FP_TEST_01 Form Processing – Zentrales Testprogramm mit Archivierung
FP_TEST_02 Form Processing – Testprogramm für verschiedene Datentypen

    <h1 class="no_toc" id="application-lifecycle-management-alm">Application Lifecycle Management (ALM)</h1>

Zielgruppe

Das Kapitel richtet sich primär an Produktverantwortliche, Qualitätsbeauftragte, Entwicklungsleiter und interessierte Entwickler, die im Rahmen einer ganzheitlichen Softwarelebenszyklusbetrachtung die eine oder andere Stellschraube für qualitativ hochwertige und effektive Softwareentwicklung drehen wollen.

Inhalt des Kapitels

Unter dem Begriff “Application Lifecycle Management” (ALM) fassen wir alle Prozesse und Werkzeuge zur transparenten Verwaltung des gesamten Lebenszyklus von SAP- und nicht SAP-Softwarelösungen zusammen. Der Lebenszyklus startet mit der Anforderungsaufnahme, erstreckt sich über deren Entwicklung, Implementierung, Test und Bereitstellung, bishin zum Betrieb mit kontinuierlichen Verbesserungen und endet mit der Außerbetriebnahme der Softwarelösung. ALM ist ein wichtiger Bestandteil moderner Softwareentwicklung und unterstützt Sie dabei, die richtigen Leitplanken für qualitativ hochwertige Software in ihrem Softwareentwicklungsprozess zu implementieren.

In diesem Kapitel erhalten Sie einen Überblick und nützlicher Handlungsempfehlungen zu folgenden Themen:

          <h1 class="no_toc" id="alm-hintergrundwissen-und-werkzeugunterstützung">ALM-Hintergrundwissen und Werkzeugunterstützung</h1>

ALM-Unterstützung durch die SAP
Nutzen von ALM

ALM-Unterstützung durch die SAP

Die SAP unterstützt den Themenbereich ALM durch die umfangreiche Bereitstellung verschiedener Werkzeuge, Best Practices und Services (siehe dazu SAP Support - ALM). Besonders deutlich wurde dies mit der Einführung des SAP Solution Managers 7.0 im Jahr 2008 und der im Release 7.1 (2011) enthaltenen Funktionserweiterungen. Seitdem ist der Solution Manager bei vielen SAP Kunden als zentraler Bestandteil der SAP-ALM-Strategie für On-Premise Systeme der SAP Business Suite 7 Komponenten im Einsatz. Der SAP Solution Manager folgt der Wartungsstrategie der SAP Business Suite 7 und wird (Stand: Mai 2025) noch bis Ende 2027 (mit Extended Maintenance Support bis 2030) von der SAP gewartet.

Das Nachfolgeprodukt des SAP Solution Managers nennt sich SAP Cloud ALM und ist - wie der Name schon sagt - eine reine Cloud-Lösung, die auf der SAP Business Technology Platform (BTP) läuft. SAP Cloud ALM befindet sich seit einigen Jahren im Aufbau und wird kontinuierlich, in enger Abstimmung mit der DSAG und Anwenderundernehmen, weiterentwickel. Der Funktionsumfang ist im Vergleich zum SAP Solution Manager derzeit noch eingeschränkt und aktuell (Stand: Mai 2025) eher für kleinere Unternehmen ohne über Jahre gewachsenes ALM sowie für cloud-zentrierte Systemlandschaften geeignet.

Weitere SAP-Produkte aus der ALM-Familie sind SAP Focused Run als eigenständiges On-Premise-System für den Monitoring-Bereich, sowie die SAP Solution Manager-Addons Focused Build für z.B. agile Projekte und Focused Insights für Dashboards jeglicher Art.

Zusammengefasst decken die oben genannten Produkte folgenden Funktionsumfang ab:

Anforderungsmanagement

Erfassung, Dokumentation und Nachverfolgung von Geschäftsanforderungen
Unterstützung bei der Abstimmung von IT- und Business-Zielen

Change- und Request-Management

Steuerung von Änderungen an SAP-Systemen
Planung und Durchführung von Releases und Transporten
Minimierung von Ausfallzeiten und Risiken durch strukturierte Prozesse

Testmanagement

Planung, Durchführung und Dokumentation von Tests
Integration manueller und automatisierter Tests
Qualitätssicherung vor Produktivsetzungen

Weiterführende Informationen

Testmanagement

IT-Service-Management (ITSM)

Unterstützung bei Störungsmanagement, Incident- und Problem-Handling
Integration mit ITIL-konformen Prozessen

Projekt- und Portfolio-Management (PPM)

Planung, Steuerung und Kontrolle von IT-Projekten
Ressourcenmanagement und Budgetverfolgung

Custom Code Management

Analyse und Optimierung von kundenspezifischem ABAP-Code
Bewertung der Systembelastung und Wartbarkeit

Application Operations / System Monitoring

Überwachung von SAP-Systemen in Echtzeit
Proaktive Fehlererkennung und Performance-Optimierung

Business Process Monitoring und Optimierung

Überwachung und Analyse von Geschäftsprozessen
Identifikation von Optimierungspotenzialen

Dokumentation und Wissensmanagement

Zentrale Ablage von technischen und funktionalen Dokumentationen
Wiederverwendbarkeit von Informationen und Know-how-Sicherung

Webseiten & Ressourcen

- SAP Support - Application Lifecycle Management (ALM)

- E3-Special SAP Solution Manager

Nutzen von ALM

Der Mehrwert eines durchgängigen ALM-Ansatzes besteht in der strukturierten Erfassung, Dokumentation und Nachvollziehbarkeit aller Aktivitäten über den gesamten Lebenszyklus einer Anwendung hinweg. Hiervon profitieren unternehmensinterne und externe Akteure gleichermaßen.

So können durch das ALM - korrekt implementiert und stringent angewendet - die Anforderungen von Wirtschaftsprüfern zu rechtlichen Regularien wie z.B. die lückenlose Dokumentation aller Änderungen an Systemen, die finanzrelevante Prozesse betreffen erfüllt werden (§ 239 Abs. 2 HGB, § 257 HGB). Dies betrifft das Anforderungsmanagement über ein nachvollziehbares Test- und Transportmanagement bis zur vollständigen Dokumentation einschließlich aller Änderungen, um nur die wichtigsten Aspekte hervorzuheben.

Aus Sicht der SAP-Entwicklung ist in erster Linie das Change Request Management (ChaRM) hervorzuheben, das die Prozesse und Anwendungen des Anforderungs- und Transportmanagements perfekt verbindet und um verschiedene Konsistenz- und Qualitätsprüfungen erweitert werden kann.

Hinsichtlich der Dokumentation besteht unter anderem die Möglichkeit, Entwicklungsobjekte automatisch aus den angebundenen SAP-Systemen auszulesen und anschließend (manuell) den entsprechenden Prozessen zuzuweisen, was etwa die Änderung von Prozessen durch den Entwickler vereinfachen kann.

          <h1 class="no_toc" id="qualitätssicherung-und--monitoring">Qualitätssicherung und -Monitoring</h1>

Kontinuierliche Selbstüberprüfung durch den Entwickler
Code Review
Quality Gates im Release-Prozess
Ganzheitliche Betrachtung und Kontinuierliche Qualitätskontrolle

In der Softwareentwicklung existieren unterschiedliche Prüfverfahren die Softwarequalität Ihrer Entwicklungen an bestimmten Zeitpunkten zu messen. Weit verbreitet ist der Einsatz von statischen Code-Analyse-Werkzeugen, die im Softwareentwicklungsprozess bei der Überprüfung von Entwicklungsaktivitäten zu festgelegten Prüfzeitpunkten (Quality Gates) für die Validierung von Entwicklungsrichtlinien zum Einsatz kommen. Für weitere Details zu dem Thema Statische Code Analyse mit SAP-Werkzeugen verweisen wir gerne auf den unten verlinkten DSAG ATC-Leitfaden.

Darüberhinaus existieren Software Analyse Werkzeuge, deren Ausrichtung eher ganzheitlicher Natur sind und die sich auf das Monitoring und die evolutionäre Entwicklung der Softwarearchitektur konzentrieren. Diese Werkzeugkategorie bietet Optionen an, die Informationen aus der statischen Code Analyse grafisch aufzubereiten und z.B. als Trend in einer Zeitleiste, als 3D-City-Model oder als Heatmap abzubilden. Hierfür werden weitere Daten über das Nutzungsverhalten, organisatorische Gegebenheiten, wie die Anzahl der unterschiedlichen Entwickler oder die Änderungshäufigkeit bestimmter Quellcode-Artefakte, hinzugelesen und für die Identifikation von potentiellen Hotspots verwendet, aus denen sich dann organisatorische Maßnahmen für Qualitätsverbesserungen ableiten lassen.

Neben den nachfolgend aufgeführten Prozessen, Praktiken und Werkzeugen zur Erkennung von Qualitätsmängeln kommt es vor allem darauf an, wie sie mit den identifizierten Mängeln umgehen. Gemäß dem Motto “Das Bessere ist der Feind des Guten”, empfehlen wir ihnen angemessen und bewusst mit dem Thema Softwarequalität umzugehen. Hierfür eignet sich die Definition einer auf ihr Unternehmen zugeschnittene Custom Code Strategie, die konkret festlegt, welcher Qualitätsstandard für welche Kategorie von Entwicklung einzuhalten ist.

Kontinuierliche Selbstüberprüfung durch den Entwickler

Je früher ein Mangel in der Softwareentwicklung gefunden wird, desto günstiger ist dessen Behebung. Gerade für den Entwickler ergibt sich hieraus ein hoher Anspruch an die eigene Verantwortung, die Codequalität adäquat im Auge zu behalten und frühzeitig Probleme aus dem Weg zu räumen. Zwei Faktoren spielen dabei eine entscheidende Rolle:

Die Disziplin des Entwicklers, den Code kontinuierlich auf Mängel zu prüfen
Das Werkzeug mit dem der Entwickler arbeitet

Die eingesetzte Entwicklungsumgebung ist ausschlaggebend für die Früherkennung und Behebung von Mängeln

Bevorzugen sie die ABAP Development Tools für Eclipse (ADT) als Entwicklungsumgebung für ABAP: Hierdurch können sie auf integrierte Refactoring-Möglichkeiten, erweitertes Syntax-Highlighting und erweiterte Code-Vervollständigung, Autokorrektur ausgewählter ATC-Fundstellen durch Quick-Fixes, Inline Anzeige von ATC-Fundstellen an der auftretenden Code-Zeile nach ausgeführter ATC Prüfung und eine frei konfigurierbare Benutzeroberfläche zugreifen.
Nutzen sie das Eclipse-Ökosystem um die Effizienz Ihrer Entwickler zu steigern: Durch die Bereitstellung des ADT-SDKs existiert die Möglichkeit, die ABAP Development Tools über standardisierte Schnittstellen zu erweitern. Hierdurch sind in den vergangenen Jahren diverse Projekte entstanden, die unter anderem Erweiterungen der IDE anbieten und das Entwicklerleben in vielerlei Hinsicht vereinfachen. Als Beispiel für so eine Erweiterung möchten wir den ABAP Cleanererwähnen, der Code Refactorings unterstützt, die sich primär auf den Einsatz von moderner ABAP Syntax und die Einhaltung eines einheitlichen Styleguides konzentriert.
Achten sie bei dem Einsatz von Eclipse Plug-Ins auf sicherheitsrelevante Rahmenbedingungen: Dieser Leitfaden soll keine Einladung sein, sämtliche Open Source oder frei verfügbaren Eclipse Plug-Ins ohne weiteres in Ihrem produktiven Entwicklungsumfeld zu verwenden. Bitte beachten Sie vor Installation der Plug-Ins auf die in ihrem Unternehmen geltenden Vorgänge für Sicherheitsprüfungen und Freigabeprozesse für die Nutzung neuer Software.

Webseiten & Ressourcen

- ABAP Open Source Projects

Code Review

Ein wichtiges Mittel, um die Qualität des Codes zu gewährleisten und Wissen im Team zu teilen, sind Code Reviews. Unter Code Review versteht man gemeinhin, dass eine vom Autor verschiedene Person den Code liest, versucht zu verstehen, und Anmerkungen sowie Verbesserungsvorschläge hinterlässt.

In vielen Softwareprojekten werden Code Reviews basierend auf sog. Pull Requests durchgeführt. Dazu werden Code-Änderungen im Versionskontrollsystem auf einem separaten Branch vorgenommen, und sobald die Implementierung in einem ersten vollständigen Zustand vorliegt, einem anderen Mitglied des Teams zum Review übergeben. Plattformen wie GitHub, GitLab oder Azure DevOps bieten dazu Möglichkeiten, sämtliche Änderungen auf diesem Branch übersichtlich darzustellen und mit Kommentaren zu versehen. Oft sind darüber hinaus auch Bewertungsfunktionen vorhanden, so dass etwa ein Pull Request nur dann freigegeben werden kann, wenn das Code Review mit positivem Ergebnis abgeschlossen wurde. Da in der SAP-Entwicklung aktuell kein Standard-Tool für Code Reviews existiert, ist die Abstimmung mit den Nicht-SAP-Teams empfehlenswert. Werden dort Reviews auf Pull Requests in GitHub oder Azure DevOps verwendet, kann bei Auswahl desselben Tools auf vorhandenes Vorwissen im Unternehmen zurückgegriffen werden.

Der folgende Abschnitt liefert einige allgemeine Best Practices zu Code Reviews. Anschließend wird erörtert, inwieweit diese in der ABAP-Entwicklung Anwendung finden können und welche Besonderheiten dabei ggf. zu beachten sind.

Best Practices

1. Allgemeine Prinzipien

Kleine Änderungen, häufige Reviews: Große Code-Änderungen sind schwerer zu überblicken. Stattdessen sollten Reviews auf überschaubaren Einheiten durchgeführt werden.
Statische Analyse als Eingangskriterium: Investiere erst dann manuellen Aufwand für Code Reviews, wenn automatisierte Verfahren wie Unit Tests und statische Codeanalyse keine Probleme mehr im Code finden.
Klare Erwartungen: Definiere im Team, was in einem Code Review überprüft werden soll. Hierfür empfiehlt sich die Erstellung einer gemeinsamen Review-Guideline. Beispiele sind weiter unten verlinkt.
Feedback-Kultur: Code-Review sollte nicht als zusätzlicher Freigabeprozess verstanden werden, sondern als Mittel zum Erfahrungsaustausch mit dem gemeinsamen Ziel, die Qualität zu verbessern. Dies bedeutet, dass sowohl Code-Autor als auch Reviewer offen für konstruktive Kritik sein sollten.
Kurze Review-Zyklen: Lange Wartezeiten können den Entwicklungsprozess verlangsamen. Es sollte darauf geachtet werden, dass Änderungen zügig reviewt und ggf. nachgearbeitet werden. Hierfür empfiehlt es sich, interne Ziele zu vereinbaren und zu überwachen, etwa dass keine Änderung länger als 2 Tage auf Code-Review warten muss.

2. Für den Autor

Codekommentare: Erkläre die Gründe für bestimmte Entscheidungen und den Kontext des Codes. Falls ein Reviewer den Code nicht versteht, tut man es selbst nach einigen Monaten vermutlich auch nicht mehr.
Vor dem Review selbst überprüfen: Überprüfe den Code selbst gründlich, bevor du ihn zum Review stellst.
Sei bereit, Änderungen anzunehmen: Sei offen für Feedback und bereit, deinen Code anzupassen.

3. Für den Reviewer

Konzentriere dich auf die Intention: Verstehe, was der Autor mit dem Code erreichen wollte.
Sei respektvoll: Feedback sollte sich immer auf den Code beziehen, nicht die Person. Auch Verständnisfragen sind wertvolles Feedback.
Sei konstruktiv: Gib konkrete Vorschläge zur Verbesserung.
Fokus: Konzentriere dich auf Themen wie Verständlichkeit, Architektur, Algorithmen oder Testbarkeit des Codes.
Augenmaß: Eine Flut von Kommentaren kann den Autor überfordern. Falls ohnehin eine Überarbeitung nötig ist, konzentriere dich zunächst auf die wichtigsten Vorschläge.

Weitere Ressourcen

ABAP Code Reviews - A practical guide
CQSE Blog “Lessons from Code Review” (Teil 1, Teil 2)
Google Engineering Practices Documentation

abapGit

Eine Möglichkeit, ABAP-Code in einem Git-Repository mit Unterstützung für Pull Requests bereitzustellen, ist abapGit (s. auch Kapitel Versionsverwaltung).

Insbesondere ABAP-Entwicklungsteams setzen für Code Review häufig auf einen Prozess, der abapGit enthält. Dies haben verschiedene Praxisvorträge im Arbeitskreis Development gezeigt (Veranstaltungsseite im DSAGNet). Das Vorgehen ist hier analog zur Nicht-SAP-Welt: Änderungen werden auf einem Branch vorgenommen und dort via Git Commit veröffentlicht. Dies geschieht entweder manuell über das abapGit-UI oder etwa automatisiert über einen Background Push.

Auf GitHub ist zudem ein Beispielprojekt veröffentlicht, welches bei Taskfreigabe automatisch einen Pull Request via abapGit erstellt oder aktualisiert. Dieses ist laut den Autoren allerdings nicht als fertiges Produkt zu verstehen, sondern als Startpunkt für eine eigene Implementierung, welche sich an den spezifischen Anforderungen und Prozessen des eigenen Unternehmens orientiert.

Git-based CTS (gCTS)

Obwohl der SAP Styleguide ABAP Code Reviews - A practical guide gCTS explizit erwähnt, stellt es zum aktuellen Zeitpunkt (Stand: Mai 2025) keine praktikable Lösung für die Durchführung von Code Reviews dar. Es weist mehrere Eigenschaften auf, die im Widerspruch zu den oben genannten Anforderungen stehen. Konkret:

Commits werden erst bei Transportfreigabe durchgeführt. Idealerweise sollte ein Code-Review Teil der “Done-Kriterien“ eines Transportauftrags sein. Der Code muss folglich vorher im Repository verfügbar sein.
Der Committer in gCTS ist die Person, die den Transport freigegeben hat. Das Repository enthält keine Information zu der Person, die den Code erstellt hat. Dies erschwert die Diskussion im Rahmen des Code Reviews.

Diese beiden Punkte können zu einem gewissen Grad durch Custom Code gelöst werden, etwa indem man bereits bei Freigabe einer Entwickler-Aufgabe einen Commit erzeugt. Das größte Hindernis für Code Reviews auf gCTS-Repositories ist allerdings, dass in gCTS-Repositories weder Dateipfade noch -inhalte für Menschen leicht lesbar sind. Teilweise werden technische Bezeichner als Dateinamen verwendet, bei anderen Objekttypen ist der Code auf einer einzigen Zeile dargestellt, als Teil einer großen JSON-Struktur. SAP hat zu diesem Zweck gemeinsam mit der Community die ABAP File Formats definiert, welche die genannten Probleme adressieren. Diese werden allerdings in gCTS aktuell nicht implementiert. Auf der GitHub-Seite der ABAP File Formats wird zwar darauf verwiesen, dass dies in Zukunft der Fall sein soll. Konkrete Zeitpläne oder Zusagen seitens SAP liegen den Autoren allerdings nicht vor.

Fazit

Zusammenfassend lässt sich sagen, dass für die Durchführung von Reviews für ABAP-Code aktuell abapGit die einzige praktikable Lösung ist. Allerdings ist abapGit ein zusätzliches Tool, das Entwickler:innen verwenden müssen. Ohne weitere Anpassung bettet es sich nicht natürlich in bestehende Entwicklungsprozesse ein. Eine erfolgreiche Lösung für Code Reviews erfordert daher einigen initialen Aufwand, um eine möglichst nahtlose Integration in den eigenen Entwicklungsprozess sicherzustellen. Beispiele aus der Praxis zeigen jedoch, dass dies durchaus möglich ist und letztlich ein wertvoller Baustein zur Entwicklung hochwertigen Codes sein kann. Nicht zuletzt die Tatsache, dass SAP selbst auf Code-Reviews in der ABAP-Entwicklung setzt, sollte Argument genug sein, sich mit der Thematik auseinanderzusetzen.

Quality Gates im Release-Prozess

Vor der Freigabe eines neuen Features in den Release-Prozess empfiehlt sich eine finale und automatisierte Qualitätskontrolle, die den erstellten Code auf kritische Sicherheits-Fundstellen überprüft und bei Treffern die Freigabe blockiert. Das bedeutet nicht, dass sie die Sicherheitsprüfungen bei der kontinuierlichen Qualitätsprüfen oder im Code Review auslassen sollen. Im Gegenteil! Die Sicherheitsprüfung muss fester Bestandteil der anderen Prüfverfahren sein, damit sie frühzeitig auf dieses sensible Thema reagieren können. Das Quality Gate im Release-Prozess ist vielmehr die abschließende Kontrollinstanz, um die unbeabsichtigte oder vorsätzliche Einführung von Sicherheitslücken vor dem Import in nachgelagerte Systeme zu erkennen und zu unterbinden. Die Prüfung dient als Versicherung, dass ihnen keine, durch statische Codeanalyse-Werkzeuge erkennbare Schwachstelle entwischen kann.

Alle anderen Fundstellen, wie z.B. die Verletzung von Wartbarkeits-, Robustheits- und Effizienz-Kriterien, sollten im Vorfeld durch die kontinuierliche Qualitätsprüfung des Entwickler und den Code Review Prozess angemessen behandelt werden. Vernachlässigen sie die vorgelagerten Prüfungen, endet das entweder in unglücklichen Business Usern, die sie wegen schwerwiegender und zu spät erkannter Qualitätsmängeln auf ein neues Releasedatum vertrösten müssen, oder in einem auf Dauer immer komplexeren, schwer verständlichen und wartungsintensiven System. Beide Szenarien sollten sie unbedingt vermeiden und Qualitätsprüfungen frühzeitig und kontinuierlich durchführen.

Quality-Gate Unterstützungs-Prozesse

Definieren sie ein Verfahren zur systematischen Kennzeichnung von Falsch-Positiv-Meldungen und Ausnahmegenehmigungen während der Qualitätskontrolle. Statische Code Analysetools bieten hierfür in der Regel Mechanismen an, mit der sie die identifizierten Findings entsprechend unterdrücken können. Vermeiden sie Engpässe und nutzen sie das Verfahren bereits vor der finalen Qualitätskontrolle.
Nutzen sie bei der Einführung von Qualitätskontrollprozessen das sogenannten Baseline-Verfahren zur Unterdrückung von Qualitätsmeldungen, die vor der Einführung des Qualitätskontrollprozesses entstanden sind. Nützlich ist das vor allem in Bestandssystemen mit einer großen Code-Basis an Alt-Entwicklungen, bei denen Sie Meldungen aus dem Bestands-Code von neu hinzugefügte Qualitätsmängel unterscheiden wollen. Achten sie darauf, sicherheitskritische Prüfungen nicht in die Baseline mit aufzunehmen. Diese müssen gesondert betrachtet, analysiert und ggf. über eine Falsch-Positiv Meldung ausgeschlossen, oder eine separate Korrektur-Initiative behoben werden.
Setzen sie auf eine Nulltolleranz-Strategie für sicherheitskritische Fundstellen im Kunden- und Partner-Code. SAP ERP Systeme sind auf Grund ihrer zentralen Rollen in der Unternehmens-IT ein beliebtes Angriffsziel für Cyber-Kriminalität. Eine nicht erkannte oder absichtlich eingebaute Sicherheitslücke kann zur Betriebsunterbrechungen und erheblichen finanziellen Schaden führen. Falls sie von ihren Stakeholdern dennoch zu einer Ausnahmegenehmigung genötigt werden, fordern sie die Unterstützung von ihrem Informationssicherheitsbeauftragten im Unternehmen ein und klären, ob für solch einen Bedarf ein Risiko-Akzeptanz-Prozess definiert ist. Weitere Informationen zu dem Thema finden sie im Kapitel Sicher ABAP Programmierung.
Führen Sie eine Sicherheitsprüfung aller Quellcode-Artefakte durch, bevor diese in Ihr System eingebunden werden. Lassen Sie sich von SAP Add-On Anbietern Löschtransporte zur Verfügung stellen, bevor Sie deren Produkte in Ihrem System einspielen. Importieren und scannen Sie die Transporte von Drittanbietern erstmalig nur in einem Sandbox System, falls dieser Ihnen keinen Löschtransport bereitstellt.
Setzen sie sich mit Ihrer Einkaufsabteilung oder dem in Ihrem Unternehmen zuständigen Bereich für Vertragsmanagement in Verbindung, falls sich der Anbieter wenig kooperativ zeigt und Ihnen keine Korrekturen der Findings oder ausführliche False-Positive-Beschreibungen zur Verfügung stellt.
Gehen Sie keine rechtlichen Risiken ein und unterlassen Sie die Veröffentlichung der identifizierten Schwachstellen. Das Ausnutzen oder Veröffentlichen von Exploits kann nach deutschem Recht (s. $202c Strafgesetzbuch) unter Umständen als Vorbereitungshandlung für eine Straftat gelten. Im Härtefall ist das Gespräch mit einem IT-Rechtsanwalt, oder die Kontaktaufnahme mit einer anerkannten Stelle wie dem Bundesamt for Sicherheit in der Informationstechnik - BSI oder einer Bug-Bounty-Platform sinnvoll.

Manipulation von Quality Gates

Achten sie auf die Implementierung eines manipulationsfreien Prüf- und Freigabeprozesses: Die Freiheiten die ein Entwickler im Entwicklungssystem zur Verfügung hat, können in zeitkritischen Situationen (Entwicklung und Qualitätssicherung in mehreren Zeitzonen verteilt / Dezentrales Release Management / etc.) ein nicht zu unterschätzende Herausforderung darstellen. Gerade in Unternehmen die keine vorgelagerte kontinuierliche Selbstkontrolle durch den Entwickler, fehlende Pair Programming oder Code Review Prozesse, zu große und über lange Zeiträume gestreckte Releases haben, kann dies dazu führen, dass Entwickler mit einem festen Lieferdatum im Nacken, zu Kurzschluss-Reaktionen neigen und über die vorhandenen Debug and Replace Berechtigungen die Quality Gates und damit verbundenen Qualitätsprüfungen aushebeln. Die Manipulation des Prüf- und Freigabeprozesses ist nur durch kontinuierliches Monitoring von Debug- und Replace Aktivitäten im System-Log (SM21) zu erkennen und kann nur teilweise durch Berechtigungseinschränkungen für die Freigabe von Transport Requests und Transport Tasks abgewehrt werden. Findige Entwickler finden fast immer einen Weg, vorhandene Quality Gates zu umgehen.
Beheben Sie die Ursache des Problems, nicht nur das Symptom: Bei der Entdeckung von Quality Gate Manipulation ist es ratsam zuerst das Gespräch mit dem Entwickler zu suchen und die Ursache zu identifizieren, die zu der Notwendigkeit einer Manipulation geführt hat. Oft ist die “Not” unter der der Entwickler handelt, Unkenntnis über den, oder ein Mangel an fehlender Flexibilität im Entwicklungsprozess. Hilfreich ist die Investition in leichtgewichtiges und gut nachvollziehbares On-Boarding Material für den Entwickler und für prozessbeteiligte Personen. Zusätzlich kann eine Aufmerksamkeitsinitiative innerhalb der Produktteams über die Notwendigkeit früher und kontinuierlicher Qualitätssicherungsmaßnahmen sinnvoll sein.
Greifen Sie bei Wiederholungsfällen und Nichteinhaltung der Prozesse konsequent durch: Hierfür müssen sie den Prozess im Vorfeld mit der Management- und Entscheider-Ebene abgestimmt haben und sich die Handlungslegitimation einholen. Natürlich hat die psychologische Sicherheit der Entwickler eine hohe Priorität, weswegen grundsätzlich bei Erst-, oder Zweitverstößen das Gespräch mit dem Entwickler im vertraulichen Rahmen gesucht werden muss. Spätestens beim dritten Auftreten kann von einer arglistigen Täuschung oder beabsichtigter Schädigung des Unternehmens ausgegangen werden. Gerade bei durchgeschleusten Sicherheitsschwachstellen kann von einem Cybersecurity Vorfall ausgegangen werden, der rechtliche Konsequenzen nach sich ziehen sollte. Solche beabsichtigten Sicherheitsvorfälle sollten, sofern keine alibifreie Begründung vorliegt, bereits beim ersten Auftreten konsequent geahndet werden.

Ganzheitliche Betrachtung und Kontinuierliche Qualitätskontrolle

Die kontinuierliche Qualitätskontrolle stellt einen strategischen Ansatz dar, der dem nachhaltigen Schutz Ihrer Investitionen in kundenspezifische Entwicklungen dient. Ziel ist es, potenzielle Schwachstellen und kritische Entwicklungsmuster frühzeitig zu identifizieren, um Systemsicherheit, Leistungsfähigkeit, Wartbarkeit und Portabilität gezielt zu optimieren.

Ein zentrales Instrument in diesem Kontext sind moderne Custom Code Analytics-Werkzeuge. Diese bieten weitreichendere Analysemöglichkeiten als klassische statische Codeanalyse-Tools. Während statische Codeanalyse sich primär auf die Prüfung von Syntax, Stilrichtlinien und bekannten Programmierfehlern konzentriert, verfolgen Custom Code Analytics-Tools einen umfassenderen Ansatz: Sie analysieren kundenspezifische Entwicklungen im Gesamtkontext des Systems – unter Berücksichtigung von Nutzungshäufigkeit, Performance-Auswirkungen, Upgrade-Kompatibilität sowie Abhängigkeiten zu Standardmodulen und anderen Eigenentwicklungen.

Ein weiterer Mehrwert liegt in der Fähigkeit dieser Werkzeuge, Hotspot-Analysen durchzuführen. Dabei werden Codebereiche identifiziert, die überproportional oft geändert werden, hohe Komplexität aufweisen oder sich als besonders wartungsintensiv erwiesen haben. Dies ermöglicht eine gezielte Priorisierung von Refactoring-Maßnahmen und trägt substanziell zur Erhöhung der langfristigen Codequalität und Systemstabilität bei.

Neben der technischen Optimierung eröffnet der Einsatz von Custom Code Analytics auch erhebliche wirtschaftliche Potenziale: Durch die Identifikation und Eliminierung von doppeltem oder nicht mehr genutztem Code sowie die Erkennung veralteter oder kritischer Standardmodulverwendungen können Wartungsaufwände reduziert, Upgrade-Projekte vereinfacht und unnötige Lizenz- oder Entwicklungskosten vermieden werden.

Für SAP Business Suite Kunden mit SAP Enterprise Support enthält der SAP Solution Manager ab Version 7.2 SP5 eine Zusammenstellung von Werkzeugen, die unter dem Begriff Custom Code Lifecycle Management ein sehr umfangreiches Portfolio an Analyse- und Verwaltungswerkzeugen anbieten. Als bekannter Stellvertreter dieser Werkzeuge ist das Custom Code Decommissioning Cockpit zu nennen, das häufig bei der Vorbereitung von Migrationsprojekten von SAP ECC auf SAP S/4HANA verwendet wird, um nicht mehr genutzten Kundencode vor der Migration kostengünstig stillzulegen. Eine ausführliche Beschreibung über die Funktionalität mit Präsentationsmaterial und Videos finden Sie im verlinkten Expert Content Custom Code Management with SAP Solution Manager.

Leider ist bis zum heutigen Tag (Stand: Mai 2025) noch kein adäquates Nachfolgeprodukt für das Custom Code Lifecycle Management im SAP Solution Manager offiziell bekannt, das dessen Umfang und Leistung ansatzweise abdeckt. Stattdessen existieren verstreut spezialisierte Insellösungen und Services, die leider nur zeitpunktbezogene Analysen, aber kein ganzheitliches und evolutionäres Monitorings gewährleisten (SAP for Me Custom Code Analytics Application, S/4HANA Readiness Check, Clean Core Cockpit, Intelligent Custom Code Management Service). Gerade im Hinblick auf das technologie-offene Ökosystem im SAP-Umfeld macht es Sinn, sich mit Kollegen anderer Technologiebereiche auszutauschen und als Alternative ggf. auf ein bereits in Ihrem Unternehmen vorhandenes Software Analyse Werkzeug mit ABAP-Auswertungsmöglichkeiten zuzugreifen.

Neben den von der SAP angebotenen Werkzeugen gibt es eine Reihe von kommerziellen und frei verfügbaren Werkzeugen, die sich im Bereich Funktionalität, Leistungsumfang, Support und Weiterentwicklung stark voneinander unterscheiden. Als potentielle Vertreter und ohne eine Empfehlung für die Werkzeuge auszusprechen, möchten wir ihnen kurz beigefügte Kandidaten vorstellen:

ABAP2CodeCharta

ABAP2CodeCharta ist ein Open-Source-Tool, das ABAP-Quellcode in ein CodeCharta-Format konvertiert. Es dient der Visualisierung von ABAP-Code-Strukturen in sogenannten Code Cities, also dreidimensionalen Darstellungen, in denen z. B. Komplexität, Größe oder Änderungsfrequenz von Code-Komponenten visuell erfasst werden können. Das Tool unterstützt dabei die Hotspot-Erkennung, fördert das Verständnis großer Codebasen und hilft bei der Priorisierung von Refactoring-Maßnahmen.

Teamscale

Teamscale ist ein kommerzielles Custom Code Analytics Tool für die kontinuierliche Analyse und Bewertung von Softwarequalität. Es unterstützt viele Programmiersprachen (inkl. ABAP) und kombiniert statische Codeanalyse mit Nutzungsauswertungen, Änderungsverhalten und Architekturmetriken. Teamscale erkennt z. B. technische Schuld, ungenutzten oder redundanten Code, Hotspots und Verstöße gegen Qualitätsrichtlinien. Es bietet Dashboards, Trends und Integrationen in DevOps-Prozesse und ist insbesondere in komplexen Unternehmenslandschaften ein Werkzeug zur nachhaltigen Qualitätssteuerung.

Weiterführende Internetquellen und Literaturempfehlung

- Intelligent Custom Code Management

- Managing Custom Code - SAP Cloud ALM or SAP Solution Manager?

          <h1 class="no_toc" id="versionsverwaltung-in-sap">Versionsverwaltung in SAP</h1>

Einleitung/Motivation
Git-Grundlagen
1. Wichtige Begriffe
Einsatz von Git-basierten Lösungen in der ABAP-Entwicklung
Versionskontrollsysteme im SAP-Umfeld
Vergleich der unterschiedlichen Versionskontrollsystemen
1. Versionskontrollsysteme
Einsatzszenarien
Normale 3-System-Landschaft
Vergleich des Entwicklungsprozess mit verschiedenen Versionsverwaltungen
Annäherung Entwicklungsprozesse ABAP und Non-ABAP über git-basierte Tools
Security Aspekte
Integration an andere Komponenten
Risiken
Zusammenfassung
Empfehlung
Quellen

Einleitung/Motivation

Zu den aufbewahrungspflichtigen Dokumenten gemäß HGB, AO und GoBS gehören auch die Repository-Objekten in ABAP. Dies wurde lange Zeit durch die integrierte Versionsverwaltung innerhalb der ABAP-Workbench (SE80) erreicht. In den letzten Jahren hat sich aber ABAP weiterentwickelt, sei es durch den Einsatz einer externen Entwicklungsumgebung (ABAP Development Tools), den Einsatz von Git-Versionsverwaltung oder die Entwicklung weiterer Repository-Objekte, die nicht in der ABAP-Workbench entwickelt werden können. Daher stellt sich für jeden ABAP-Entwickler die zentrale Frage:

Welche Versionsverwaltung soll ich wann nehmen?

Dieses Kapitel soll daher einen Überblick und eine Gegenüberstellung von Versionsverwaltungs-Lösungen innerhalb des SAP-Universums für ABAP-Entwickler geben.

Git-Grundlagen

Git ist ein verteiltes Versionierungssystem, welches frei als Open-Source zur Verfügung gestellt wird. Es wurde 2005 vom Linux-Erfinder Linus Torvalds entwickelt. Im Programmierbereich dient es dazu:

eigene Änderungen zu überwachen
Änderungen rückgängig zu machen
Änderungen anderen zur Verfügung zu stellen
Aktualisierungen von anderen einzuholen

Dadurch ergeben sich folgende Vorteile:

es kann zeitgleich entwickelt werden, z. B. für verschiedene Features
Versionierung verhindert, dass bereits getätigte Arbeiten verloren gehen bzw. überschrieben werden
Bei Bedarf kann zu früheren Versionen zurückgekehrt werden oder simultan an verschiedenen Versionen gearbeitet werden

Wichtige Begriffe

Repository: In einem Repository bzw. einem Repo befinden sich alle Dateien inklusive derer vorangegangenen Versionen. Dadurch stehen stets alle Änderungen zur Verfügung, die von einer Datei ins Repo gespielt wurden und es kann nachvollzogen werden, wer wann welche Änderungen durchgeführt hat.
Branches: Beim Einsatz von Git dienen Branches (engl.: to branch - sich verzweigen) dazu, einen separaten Arbeitszweig zu erstellen. Dieser kann dann auch als neuer Kontext gesehen werden, in dem gearbeitet wird. So kann z.B. die Programmierung eines Features in einem eigenen Branch erfolgen, der bei Fertigstellung und nach dem Testen zurück in den Master-Zweig eingearbeitet wird.
Versionierung: Bei der Versionierung werden im Git alle getätigten Änderungen protokolliert. Mittels “Commit” können die Änderungen zu dem Repository hinzugefügt werden, eine neue Version der Datei(en) befindet sich dann im Repo. Anschließend können verschiedene Versionen miteinander verglichen, Änderungen rückgängig oder zu einer früheren Version zurückgekehrt werden.

Einsatz von Git-basierten Lösungen in der ABAP-Entwicklung

In vielen Programmiersprachen ist eine Verwaltung von Programmcode in einem Git-Repository Standard. Durch den Einsatz von Lars Hvam Petersen, der es durch seine freie OpenSource Lösung abapGit ermöglicht hat, ABAP-Code in ein Git-Repository zu bringen, nehmen Git-basierte Lösungen in der ABAP-Welt eine immer wichtigere Rolle ein. Der Einsatz von Git-basierten Lösungen in der ABAP-Entwicklung hat folgende technologische Vorteile:

Standardmäßige Funktionen für die Versionsverwaltung: Durch den Einsatz von Git können standardmäßige Funktionen eingesetzt werden, wie das Rollback nicht nur für ein Objekt, sondern für alle Objekte gleichzeitig.
Zusammenarbeit von mehreren Entwicklern gleichzeitig an unterschiedlichen Anforderungen: Mit Hilfe von Git ist es möglich, dass mehrere Entwickler gleichzeitig mit Hilfe von Branches an unterschiedlichen Anforderungen arbeiten können.
Ermöglichen von externen Tools: Es ist nun möglich, nicht nur SAP-Produkte für den Entwicklungsworkflow zu verwenden, sondern man kann auch externe Tools verwenden, um seinen Code z.B. zu prüfen. Zudem können CI-Pipelines gebaut werden, was mit dem Standard-Transportmechanismus nicht möglich ist.
Versionierung: Bisher war es nur möglich, eine Version zu einem Objekt zu wissen. Nun ist es möglich mit Hilfe von Tags eine Reihe von Objekten zu versionieren. Dies hat den Vorteil, dass nun die Anwendung einen Releasecharakter besitzen kann.
Code ist zentral: Der Code befindet sich an einer zentralen Stelle, und alle Änderungen zu der Anwendung werden dorthin gebracht. Neben dem ABAP-Code können auch andere Bestandteile der Anwendung wie z.B. Fiori oder auch .NET Entwicklungen im Git-Repository gespeichert werden. Es kann auch die Dokumentation im Git gespeichert werden.

Neben den technologischen Vorteilen gibt es auch organisatorische Vorteile

Git ist Standardlösung: Es ist einfacher, andere Menschen für die SAP-Entwicklung zu begeistern, wenn sie schon Tools oder Technologien aus anderen Programmiersprachen kennen. Git ist die Standardlösung für andere Programmiersprachen, und es muss kein neues Know-How aufgebaut werden. Besonders Studenten, die Git schon kennen, können sich dann für ABAP besser begeistern.
Einheitliches Format für Programmiersprachen: Im Git-Repository können nicht nur SAP-Entwicklungen gespeichert werden, sondern es können auch andere Entwicklerteams dort ihren Code zentral hinterlegen.
Format: Das Format ist einheitlich und kann von jedem gelesen werden. Es ist nicht verschlüsselt, und alle Änderungen können nachvollzogen werden. So kann auch ein Wirtschaftsprüfer alle Änderungen sehen, wann und von wem sie gemacht wurden.

Versionskontrollsysteme im SAP-Umfeld

Folgende Versionskontrollsysteme gibt es im SAP-Umfeld:

Serverbasierte Versionsverwaltung

Die serverbasierte Versionsverwaltung ist für alle editierbaren Objekte der ABAP Workbench aktiv. Die Versionsverwaltung kann über

SE80 - Object Navigator
SE09 - Transport Organizer
die Anzeige- und Pflegetransaktionen für Repository Objekte

aufgerufen werden.

Die entsprechenden Objekte werden bei jeder Transportfreigabe versioniert.

Lokale Versionsverwaltung in ABAP Development Tools

Die auf der Eclipse IDE basierenden ABAP Development Tools bietet zwei Basis, eingebaute Versionsverwaltungen für Entwicklungsressourcen an, die mittels des ABAP-Compare Editors ausgeführt werden können und umfangreiche Vergleichsmöglichkeiten bieten:

clientbasierte lokale Versionsverwaltung: - Das Standardfeature unter Eclipse bietet eine Standardversionsverwaltung. Jedes Mal wenn ein Objekt, wie z.B. eine ABAP-Klasse bearbeitet und gespeichert wird, speichert Eclipse die Version nach den persönlichen eingestellten Präferenzen. Dies ist sinnvoll wenn Änderungen nachvollzogen werden sollen, die vor einer Transportfreigabe erfolgten.
serverbasierte Revisionshistorie: - Dies entspricht der lokalen Versionsverwaltung und zeigt Versionen basierend auf dem aktuellen Stand und den freigegebenen Transporten an. Gegenüber der GUI-basierten Variante, sind hier Änderungen, insbesondere bei Klassen deutlich übersichtlicher und besser nachzuvollziehen. Des Weiteren bietet sich hier die Möglichkeit auch andere Systeme, die als ABAP-Projekte in Eclipse eingebunden sind, zum Versionsvergleich heranzuziehen (z.B. zentrale Entwicklungssystemlinie und Q-System der Produktionslinie). Dafür sind keine RFC-Verbindungen zwischen den Systemen erforderlich, der Vergleich erfolgt lokal.

Details finden Sie hierzu im ADT-Leitfaden der DSAG

abapGit

abapGit ist ein in ABAP entwickelter Git-Client. Es wurde von Lars Hvam Petersen entwickelt und ist ein OpenSource Projekt. Mit abapGit haben Entwickler die Möglichkeit eine Git-Versionskontrolle mit dem SAP-Applikationsserver zu verbinden und ABAP-Entwicklungsobjekte in einem Git-Repository anzulegen.

gCTS

Im Gegensatz zu abapGit ist gCTS (Git-enabled Change and Transport System) ein von SAP bereitgestellte Erweiterung zu CTS. Es unterstützt die Integration von Git in das bestehende CTS, um moderne Versionskontrollfunktionen zu ermöglichen.

Versionsverwaltung in SAP BAS

Mit SAP Business Application Studio steht Unternehmen ein Werkzeug für die Entwicklung ihrer Anwendungen und Erweiterungen mit Bezug zu SAP-Lösungen zur Verfügung. Die Entwicklungsumgebung stellt der Anbieter dabei in Form eines Cloud-basierten Services bereit. Für die einfachere Versionsverwaltung ist eine Integration mit Git vorgesehen. Die Versionierung ist aber auch mit anderen Systemen möglich.

Vergleich der unterschiedlichen Versionskontrollsystemen

Das hier brauchen wir dann nicht mehr ? steht ja oben —-

Versionskontrollsysteme

Lokale Versionsverwaltung in der SE80

Versionsverwaltung in ABAP Development Tools

abapGit in SAP GUI

abapGit in Eclipse

abapGit in der Cloud

gCTS onPremise

gCTS in der Cloud

SAP BAS

Das hier brauchen wir dann nicht mehr ? steht ja oben —-

Vlt. noch Bewertung und Empfehlung vorgehen.

Einsatzszenarien

Normale 3-System-Landschaft

Bei diesem Einsatzszenario geht es darum, dass der Code auf dem Entwicklungssystem in ein Git-Repository mit einem Git-Versionsverwaltungssystem übertragen wird.

Darstellung 3-System Landschaft

Softwarelieferant

Dieses Einsatzszenario dient zum Austausch zwischen Quellcode von einem Softwarelieferant an seinem Kunden über ein Git-Repository. Darstellung Softwarelieferant

Verteilung in verschiedene Systemlandschaften

Hier geht es darum, dass man zwischen seinen verschiedenen Systemlandschaften Quellcode Austausch. So ist es möglich ohne Quertransporte den gleichen Quellcode zu nutzen und weiterzuarbeiten.
Alt text

Recovery

Dieses Szenario beschreibt die Möglichkeit, dass aus dem Git-Repository ein alter Stand zurückgewonnen werden kann. Dabei muss nicht jedes Repository-Objekt einzeln zurückgeholt werden, sondern ein alter Stand einer ganzen Anwendung. Alt text

Paralleles Arbeiten

Alt text

Custom Code Migration

Alt text

Das hier brauchen wir dann nicht mehr ? steht ja oben —- – Kundenentwicklung in einer normalen 3-System-Landschaft – Entwicklung in verschiedene Systemlandschaften verteilen – Recovery in drei Systemlandschaft – Paralleles Arbeiten – Custom Code Migration (Backup Legacy)

Vergleich des Entwicklungsprozess mit verschiedenen Versionsverwaltungen

SAP-Standard	GIT-basiert
Auftrag muss am Anfang angelegt werden	Commit wird nach der Änderung durchgeführt
Verteilen von Code – keine Kontrolle über die Änderungen in anderen Systemen	Zentraler Anlaufpunkt
Versionierung einer Anwendung nicht möglich	Versionierung von einer ganzen Anwendung über standardfunktionalitäten möglich
Rückgängig machen der Änderungen eines Transports nur manuell mit massivem Aufwand mit Einschränkungen möglich	Zurückgehen auf vorigen Commit damit zurücksetzen aller Änderugen über gCTS oder ABAPGIT möglich

Annäherung Entwicklungsprozesse ABAP und Non-ABAP über git-basierte Tools

Security Aspekte

Integration an andere Komponenten

Risiken

Zusammenfassung

Empfehlung

Quellen

https://www.rheinwerk-verlag.de/git-und-sap/?srsltid=AfmBOooMbM45uQOGPLDAiaKz5hHazrf45BIEVjmOIe8mz9HjpdHjgzZq

Open Source

Open Source

Einleitung

Open Source hat es in der ABAP-Entwicklung besonders schwer Fuß zu fassen. Immer noch halten sich Einwände, dass der Einsatz von frei verfügbarer Software in den geschäftskritischen SAP-Systemen mit den Unternehmensdaten gar nicht möglich oder zu rechtfertigen sei. Dabei gibt es für viele der berechtigten Einwände Lösungen, um die Risiken zu minimieren und die Chancen, die Open-Source-Software bietet, nutzen zu können. In anderen Programmierumfeldern überwiegen die Chancen bereits lange gegenüber den Restrisiken und es wurden Prozesse und Tools geschaffen, um Open-Source-Bestandteile effektiv in den eigenen Entwicklungsprozess zu integrieren. Dieses Kapitel soll Ihnen einen Überblick zum aktuellen Stand von Open Source in der ABAP-Entwicklung geben sowie Prozesse und Tools vorstellen, um…

…Open-Source-Projekte in die eigenen Lösungen zu integrieren (Einsatz von Open Source)
…an Open-Source-Projekten mitzuwirken (Beteiligung an Open Source)
…eigene Lösungen als Open-Source-Projekt bereitzustellen (Entwicklung von Open Source).

Eine Open-Source-Strategie muss jedes Unternehmen für sich selbst erschließen. Hier finden Sie eine Arbeitsgrundlage und Erfahrungsberichte.

Was ist Open Source?

Open Source Software (OSS) ist Software, welche unter einer Open-Source-Lizenz bereitgestellt wird. In allen drei zuvor genannten Anwendungsfällen ist die Lizenz maßgeblich für die Nutzung, die Modifikation und die Weiterverbreitung des bereitgestellten Codings. Zudem muss dieses frei verfügbar sein, also nicht nur einer bestimmten Gruppe an Personen bereitgestellt werden. Dies ermöglicht es Ihnen zum Beispiel den Quellcode einer Anwendung vor dem Einsatz zu prüfen und die Binärdateien zur Ausführung selbst zu erzeugen, anstatt darauf zu vertrauen, dass die bereitgestellten Dateien auch zu dem Quellcode gehören. Bugs können Sie im Zweifel selbst beheben, statt auf den Softwareanbieter warten zu müssen oder auf Support angewiesen zu sein. Zusatzfunktionalität und Integrationen können Sie selbst entwickeln und auch anderen Nutzern der Software bereitstellen. Versprochene Features wie Ende-zu-Ende-Verschlüsselung und deaktivierte Telemetrie können Sie selbst überprüfen.

SAP S/4HANA ist nicht “Open Source” nur weil Sie als Entwickler den von der SAP geschriebenen Quellcode lesen können. Open Source ist viel mehr als die bloße Bereitstellung des Codings gegenüber dem Kunden und thematisiert die freie Nutzung, Modifikation und Weiterverbreitung ohne in einem Kundenverhältnis mit dem Softwareanbieter zu stehen.

Motivation und Chancen

Warum sollten Sie sich mit Open Source in der ABAP-Entwicklung beschäftigen? Langsam aber stetig steigt die Anzahl an Szenarien, in denen Ihnen Open Source, und auch Open-Source-ABAP, im Alltag begegnet, statt, dass Sie danach selbst aktiv suchen müssen. Die Anzahl an in der Open Source Community verfügbaren ABAP-Projekten wächst - auf dotabap.org werden zum Zeitpunkt der Erstellung dieses Kapitels 299 Projekte gelistet. Die SAP selbst veröffentlicht Software als Open-Source-Projekte, wie zum Beispiel Code Pal for ABAP oder auch den RAP Generator und diverse Tutorials oder Lerninhalte, wie zum Beispiel RAP100 oder Fiori Elements Feature Showcase for RAP. Sich dem kategorisch zu verschließen führt zunehmend mehr zu verpassten Chancen…

…in der Optimierung der eigenen Entwicklungsprozesse

Mit Tools wie ABAP Cleaner, Code Pal for ABAP und abapOpenChecks können Sie Entwickler entlasten bei der Umsetzung von Entwicklungsrichtlinien und Best Practices, in dem diese teilweise automatisiert umgesetzt und in anderen Teilen statisch geprüft und Entwickler aktiv auf Findings hingewiesen werden. Und das weit über den Umfang der im SAP-Standard ausgelieferten Möglichkeiten hinaus (ABAP Formatter / Pretty Printer, ABAP Test Cockpit). Mit zJoule können Sie unabhängig vom Joule-Rollout der SAP bereits KI-Unterstützung in der ABAP-Entwicklung einsetzen.
Mit abapGit bietet sich Ihnen die Möglichkeit Ihre Entwicklungsprozesse Technologie-übergreifend mit einheitlichem Tooling zu harmonisieren und Ihre gesamte Unternehmenscodebase in einer Single Source of Truth zu verwalten, statt ABAP als Special Snowflake mit Sonderregeln zu betrachten. Sie können Code Reviews mit dafür ausgelegtem Tooling durchführen. Sie können angefangene Änderungen automatisiert zurücknehmen, wenn sie der Fachbereich nach Entwicklungszeit doch nicht mehr haben möchte ohne große manuelle Rückbauaufwände. Und das alles sogar bei Systemen ab SAP Basis 7.02.
Mit Hilfe von abaplint können Sie außerhalb eines SAP-Systems ABAP Coding prüfen, entwickeln und mit dem Transpiler sogar ausführen. Sie können so Continuous Integration Pipelines aufsetzen ohne dafür spezielle SAP-Systeme kostenintensiv aufsetzen zu müssen und statische Codeanalyse und Unit Tests ausführen (mit Einschränkungen im Vergleich zu “nativer” Ausführung in ABAP-Systemen).
Über Generatoren wie den RAP Generator oder ABAP OpenAPI Generator können Sie Boilerplate-Coding generieren und müssen dieses anschließend nur anpassen. So lassen sich Entwicklungsaufwände sparen und insbesondere auch schnell Prototypen aufsetzen.

…in der Umsetzung von betriebswirtschaftlichen Anforderungen

Mit abap2xlsx können Sie die kreativen Anforderungen der Fachbereiche zur Erstellung, zum Auslesen und zur Änderung von Excel-Dateien umsetzen. Und das schon ab SAP Basis 7.31. Sie müssen so nicht Ihre Prozesse anpassen, weil die OLE-basierte SAP API für Excel-Mappen keine Hintergrundjobs unterstützt und ein installiertes Microsoft Office beim Anwender erwartet. Sie müssen insbesondere auch nicht den Entwicklungsaufwand investieren selbst eine Codebase zu implementieren und zu warten, die sich mit der Konvertierung und den Umgang mit Excel-Dateien befasst. Und Sie müssen auch nicht in Anbetracht des Implementierungsaufwands die Anforderung als nicht verhältnismäßig umsetzbar abweisen sondern können auf der Arbeit aufsetzen, die andere sich bereits gemacht haben.
Ähnlich verhält es sich bei anderen technischen Problemstellungen, zu denen es bereits etablierte Open-Source-Lösungen gibt. Beispielsweise ABAP Logger anstelle eigener Wrapper-Klassen um die Funktionsbausteine des Business Application Log. Oder ajson als JSON-Bibliothek für ab SAP Basis 7.02.

…in der Außendarstellung

Sie können bewerten, ob wiederverwendbare Komponenten Ihrer ABAP-basierten Lösungen nicht auch als Open-Source-Projekt Sinn machen würden. Coding, welches nicht in Konkurrenz Ihr Geschäftsmodell umsetzt, sondern die Optimierung des Entwicklungsprozesses oder übergreifenden Themen wie der User Experience, Revisionssicherheit oder ähnlichem dient, könnte auch von anderen Unternehmen genutzt werden. Wenn Sie diese Komponenten als frei verfügbare Software publizieren, ermöglichen Sie externe Beteiligungen an der Entwicklung von denen Sie profitieren können.
Zusätzlich kann dies als Aushängeschild im Recruiting neuer Entwickler dienen. Diese sehen direkt, dass Sie modern entwickeln und sich nicht scheuen den Quellcode nach außen zu zeigen.
Beispiele: IBM, Microsoft, rku.it, Schwarz IT
Wenn Ihr Unternehmen Dienstleistungen zur Verfügung stellt, die über Schnittstellen mit Partnern/Kunden umgesetzt werden, welche diese auch in Ihren SAP-Systemen mittels ABAP implementieren, können Sie eine Open Source SDK bereitstellen, welche Ihre API implementiert. Die Nutzer der SDK haben direkt eine Möglichkeit Issues zu öffnen oder ergänzende Features selbst per Pull Request vorzuschlagen und Ihren Implementierungsaufwand erheblich zu verringern oder mehr Funktionalität in Ihrer Software anzubieten. Sie können intern die SDK selbst einsetzen oder für Integrationstests verwenden.
Beispiele: ABAP SDK für Azure, ABAP SDK für Google Cloud, AWS SDK für SAP ABAP, Microsoft AI SDK für ABAP, ABAP SDK for IBM watsonx

…im Upskilling von Entwicklern

Durch die Auseinandersetzung mit externen Bibliotheken und deren Implementierung können Sie Ihre Kenntnisse erweitern mit Blick auf objektorientiertes Design und Softwarearchitektur. Sie können mit neuen Technologien oder Ansätzen vertraut werden und das direkt mit produktivem Quellcode, statt Demobeispielen. Dieser Effekt verstärkt sich insbesondere bei der Beteiligung durch eigene Features oder Bugfixes und Code Reviews.

Sie sehen es gibt viele Stellen an denen Open Source, auch in der ABAP-Entwicklung, einen erheblichen Mehrwert liefern kann. Eine Auseinandersetzung mit dem Thema lohnt sich daher in jedem Fall, selbst wenn nur einige der oben genannten Punkte in Ihrem Fall relevant sind.

Ausbaustufen

Eine mögliche Herangehensweise an das Thema ist die verschiedenen Anwendungsfälle als aufeinander aufbauend zu sehen:

Sie können sich zunächst mit dem Thema befassen, wie Sie Open Source Tools in Ihren Entwicklungsprozess integrieren und damit unmittelbar einen Mehrwert erzielen. Dabei geht es zunächst noch nicht um Open-Source-Softwarebestandteile, die sich in Ihrem Coding befinden, sondern lediglich um Tools, die in Ihrem Entwicklungsprozess und damit auch nur in Ihrer Entwicklungssystemlandschaft einziehen würden. Dies ist oft der am einfachsten zu betrachtende Fall und ein guter Einstiegspunkt in das Thema.
Diese Ausbaustufe ist in Einsatz von Open Source beschrieben.
1. Diese Stufe lässt sich optional erweitern mit der Nutzung von Open-Source-Bibliotheken in Ihren entwickelten Softwarelösungen. In diesem Fall erreichen die Open-Source-Bestandteile auch Ihr Produktivsystem oder werden mit als Bestandteil Ihrer Software ausgeliefert.
Als nächstes können Sie die Beteiligung an Open-Source-Projekten ins Auge fassen. Dabei erweitern oder verändern Sie eine Open-Source-Bibliothek und stellen diese Anpassungen der Community wieder zur Verfügung, sodass auch andere Unternehmen davon profitieren können. Damit Entwickler so sich beteiligen können, muss in Ihrem Unternehmen eine Richtlinie vorhanden sein, wie dies konkret ausgestaltet werden kann.
Diese Stufe wird in Beteiligung an Open Source behandelt.
Die letzte Stufe ist die Entwicklung eigener Software als Open-Source-Software. In diesem Fall bieten Sie selbst ausgewählte Komponenten Ihrer eigenen Softwarelösungen als Open-Source-Software an und ermöglichen es so, dass andere sie einsetzen, aber auch sich daran beteiligen können.
Diese Stufe wird in Entwicklung von Open Source thematisiert.

Die einzelnen Stufen bieten unterschiedliche Chancen, aber kommen auch mit unterschiedlichen Risiken und Aufwänden. Diese werden in den genannten Unterkapiteln aufgegriffen.

Lizenzen

Die Lizenz einer Software ist ausschlaggebend dafür, wie Sie sie einsetzen können. Konkret in Bezug auf Open Source macht eine Open-Source-Lizenz eine Software zur Open Source Software. Open-Source-Lizenzen gewähren ausdrücklich Rechte gegebenüber dem Lizenznehmer, geben ihm aber auf Pflichten auf, wie der mit der Software umzugehen hat. Wenn Sie ein Softwareprojekt finden, welches seinen Quellcode öffentlich zugänglich publiziert hat, aber keine Lizenz zu finden ist, dann handelt es sich nicht um Open Source, sondern lediglich um Source Available. Bei einer Einführung von Open Source sollten Sie sich in Ihrem Unternehmen schlau machen, ob beziehungsweise wer sich mit dem Lizenzthema beschäftigt. Gerade in größeren Unternehmen, die viele verschiedene Programmiersprachen einsetzen, kann es eine zentrale Instanz geben, die sich um Kompatibilität der Lizenzen beim Einsatz von Open-Source-Komponenten kümmert.

TODO Aspekte von Lizenzen

In nachfolgender Tabelle finden Sie populäre Open-Source-Lizenzen, die auch in der ABAP-Entwicklung verwendet werden (Quelle dotabap.org). Details finden Sie zum Beispiel unter choosealicense beziehungsweise choosealicense Appendix.

	MIT	Apache 2.0	GPL 3.0	GPL 2.0
Rechte
Kommerzielle Nutzung	Erlaubt	Erlaubt	Erlaubt	Erlaubt
Weiterverbreitung	Erlaubt	Erlaubt	Erlaubt	Erlaubt
Modifikation	Erlaubt	Erlaubt	Erlaubt	Erlaubt
Pflichten
Veröffentlichung von Quellcode zu Modifikationen			Erforderlich	Erforderlich
Angabe der Lizenz / Copyright im eigenen Produkt	Erforderlich	Erforderlich	Erforderlich	Erforderlich
Nutzung der selben Lizenz für Modifikationen			Erforderlich	Erforderlich
Limitierungen
Haftung	Eingeschränkt	Eingeschränkt	Eingeschränkt	Eingeschränkt
Garantie	Eingeschränkt	Eingeschränkt	Eingeschränkt	Eingeschränkt

TODO: Bereitstellung von Lizenzen in ABAP-Code…

          <h1 class="no_toc" id="rahmenbedingungen">Rahmenbedingungen</h1>

Erschwerte Rahmenbedingungen in der ABAP-Entwicklung

Erschwerte Rahmenbedingungen in der ABAP-Entwicklung

ABAP hat es durch einige Rahmenbedingungen besonders schwer im Open-Source-Umfeld Fuß zu fassen.

Quellcode in der Datenbank

Der Quellcode von quelltextbasierten Entwicklungsobjekten ist in der Tabelle REPOSRC der Primärdatenbank des SAP-Systems abgelegt. Metadaten und nicht-quelltextbasierte Entwicklungsobjekte finden sich in einem relationalen Modell in der Datenbank wieder. Dies ist aus Sicht anderer Programmiersprachen unüblich. Standard-Tooling, welches in der Open-Source-Entwicklung eingesetzt wird, erwartet die Verwaltung der Quelltexte in einem Dateisystem mit Hilfe von Dateien und Ordnern und ist somit zunächst inkompatibel mit der ABAP-Entwicklung.

Mit abapGit lassen sich die Datenbanktabelleninhalte und das relationale Modell in Dateien und Ordner serialisieren. Zusätzlich ist der Weg zurück von Dateien und Ordnern in das Modell des SAP-Systems über die Deserialisierung möglich. Somit bietet abapGit eine Schnittstelle zwischen den Formaten und enabled die Nutzung von Dateisystem-basierten Tools. Alternativ oder ergänzend steht mit dem Git-Enabled Change and Transport System (gCTS) ein weiterer Ansatz zur Verfügung.

Ungeeignete eingebaute Versionsverwaltung

Zentraler Dreh- und Angelpunkt in der Open-Source-Entwicklung ist das Versionsverwaltungssystem. Es ermöglicht die Beschaffung und den Austausch von Quellcode und somit das gemeinsame Arbeiten am Projekt ohne ein zentrales Entwicklungssystem. Die in der ABAP-Plattform eingebaute Versionsverwaltung ist in dem Kontext ungeeignet. Ihr Schwerpunkt ist die revisionssichere Nachverfolgung von Änderungen, nicht der Austausch über das System hinaus. Das Transportwesen mit seinem proprietären binären Austauschformat ist ebenfalls ungeeignet.

Mit abapGit lassen sich in allen ABAP-Laufzeitumgebungen die Entwicklungsobjekte mit der defacto-Standard-Versionsverwaltung git versionieren und austauschen. Dabei wird eine breite Massen an Objekttypen unterstützt. Im Unternehmenskontext kann abapGit ergänzend zur eingebauten Versionsverwaltung und zum klassischen Transportwesen eingesetzt und Stück für Stück oder pro Team / Projekt ausgerollt werden.

Proprietäre Programmiersprache

ABAP ist proprietär. Es gibt keine frei verfügbare Spezifikation der Programmiersprache. Dies schränkt die Entwicklung von Tooling ein, welches im Open-Source-Umfeld benötigt wird. Denn ohne Spezifikation und ohne Compiler außerhalb eines SAP-Systems lassen sich schwierig Continuous-Integration-Maßnahmen in die Entwicklung integrieren. SAP-Systeme lassen sich schwer in den Prozess einbauen, da lizenztechnisch eine Nutzung eines Systems von unbekannten Usern nicht erlaubt ist (TODO Quelle?). In der Open-Source-Entwicklung ist aber ja genau das das Ziel, jedem die Beteiligung an der Entwicklung der Software zu ermöglichen.

Trotz mangelnden Informationen seitens der SAP haben sich Entwickler in der Open-Source-Community die Mühe gemacht Tooling zu entwickeln. An dieser Stelle ist insbesondere abaplint hervorzuheben. Das Tool ist in der Lage die syntaktische Korrektheit und diverse Code-Style und CI-Prüfungen durchzuführen - ganz ohne SAP-System! Darüber hinaus kann es sogar ABAP-Coding ausführen, indem es dieses nach Javascript transpiliert. Somit lassen sich Unit-Tests in einer CI-Umgebung auf Basis von Pull Requests ausführen ohne ein SAP-System im Zugriff zu haben.
Über die ABAP Feature Matrix lässt sich herausfinden, welche Features in welchem Release verfügbar sind. Dies ist im Open-Source-Kontext wichtig, weil man oft Releases unterstützen möchte, welche niedriger sind als das Release des Systems auf dem man entwickelt. abaplint bietet außerdem die Möglichkeit automatisiert auf Kompatibilität mit niedrigeren Releases zu prüfen oder sogar automatische Downports durchzuführen. Somit müssen nicht verschiedene Systeme vorgehalten werden.

Monolithisches System

TODO

Geschäftskritische Anwendungen und Prozesse

TODO

Unternehmenskritische Daten im System

TODO

Kommunikation und Verhalten der SAP

TODO
SAP behindert durch Historie mit Code Exchange, gCTS, inkompatible Formate, uneinheitliche Kommunikation, abapGit Fork, abapGit ADT Frontend

Namensräume

TODO

          {: .no_toc} # Einsatz von Open Source

Chancen

Risiken

Tooling wird neu eingeführt, welches die Hürde erheblich senkt, um massenhaft proprietäres Coding zu extrahieren und “zur Konkurrenz mitzunehmen”
Tooling wird eingeführt, welches massenhaft Entwicklungsobjekte im System ändern kann. Fehlbedienung könnte zu Datenverlust in der Codebase führen.
Externes Coding gelangt ins System, welches ggf. nicht geprüft wurde und Sicherheitslücken oder Schadsoftware enthält
Externes Coding gelangt ins System, welches einen separaten Softwarelebenszyklus hat. Wie mit Updates umgehen?
Externes Coding gelangt ins System, welches standardmäßig keinen Support hat. Wie mit Problemen umgehen? Was ist bei Betrieb-stilllegenden-Bug im Produktivsystem in der externen Software?
Tooling wird eingeführt, mit dem Entwickler einfach externes Coding installieren können. Wie halte ich die davon hab, dass sie einfach alles installieren und die Systemstabilität kompromittieren?

Wer stellt Open-Source-Software bereit?

Eine umfangreiche Auflistung von auf GitHub gehosteten Open-Source-ABAP-Projekten finden Sie auf dotabap.org.

(Screenshot)

Dotabap.org
SAP Open Source Manifesto

Wer nutzt Open-Source-Software?

Who Uses abapGit? - abapGit Docs

Bewertung und Lebenszyklus einer externen Abhängigkeit

Verbreitung, aktive Weiterentwicklung, Anzahl Contributors
Wer kümmert sich um Updates, wer testet diese, bewertet diese
Worauf hätte die Software Zugriff im System, ist sie nur auf Entwicklung oder auch Produktiv, bestehen Netzwerkverbindungen
Entscheidungsmatrix SAP aus Open Source Forum
Due Diligence
(Support, …)
Wie verbreitet ist das OpenSource Projekt/Produkt?
“Empfiehlt” SAP das Projekt eventuell auch, oder nutzt dieses?
Wird das OpenSource Projekt in Blogs erwähnt? Wie ist die Bewertung in diesen Blog‘s?
Bevor man sich für Open Source oder ein bestimmtes Open Source Projekt entscheidet, sollte man folgende Dinge prüfen bzw. folgende Fragestellungen für sich beantworten:
- Unter welcher Lizenz wird das jeweilige Projekt veröffentlicht?
- Was sind die Lizenzbedingungen? Kann ich diese erfüllen?
- Open Source bedeutet nicht automatisch kostenlos, was sind die Lizenzkosten?
- Wie verbreitet ist ein Open Source Projekt?
- Kommt es vielleicht sogar von der SAP und SAP übernimmt den Support/die Wartung?
- Empfiehlt die SAP ein bestimmtes Projekt, oder nutzt es gar selbst?
- Was sagt die Community zu einem Projekt, wie ist das Feedback, wie bekannt ist es (in Diskussionsforen …), wie ist die „Bewertung“?
- …
Andreas?

Sicherheitsaspekte

Horrorszenarien durchgehen

Verhalten bei Upgrades

Lizenzen

“Diese Lizenz ist wichtig. Sie kann auch die kommerzielle Nutzung untersagen oder eine kompatible Lizenz für alle durchgeführten Modifikationen erzwingen. Ebenfalls können Lizenzen verschiedener Open-Source-Projekte und die Lizenz der eigenen Software miteinander inkompatibel sein.”

Support

Argument “Keine Software ohne Enterprise Support” durchgehen

Auslieferung von Open-Source-Abhängigkeiten in eigenen Produkten

Namensräume, Rename, Lizenzen, kein Z beim Kunden

        <h1 class="no_toc" id="beteiligung-an-open-source">Beteiligung an Open Source</h1>

Beteiligung an Open Source

Beteiligung an Open Source

Als Alternative zum Fork, Beteiligung im Upstream Projekt, automatisierte Tests
Einfache Beteiligung -> Doku, Issues gut formuliert, kleinere Themen -> geringe Einstiegshürde

          <h1 class="no_toc" id="entwicklung-von-open-source">Entwicklung von Open Source</h1>

Mehrwert aus Unternehmenssicht
Anpassung des Entwicklungsprozesses zur Berücksichtigung externer Entwickler
Beispielhafte Setups

Mehrwert aus Unternehmenssicht

Verweis auch auf Versionsverwaltungskapitel

Anpassung des Entwicklungsprozesses zur Berücksichtigung externer Entwickler

Namensräume, Tools und Prozesse, um mit fehlendem Originalsystem umzugehen, Unterstützung verschiedener Releases, Unit Tests, ….
Open Source Namespaces
Minimierung von Abhängigkeiten zum SAP-Standard
Auswirkungen auf die Paketstruktur
“Inner Source” -> oder Versionsverwaltungskapitel

Beispielhafte Setups

abapGit

7.02, Unit Tests ohne Server

abap2ui5

Multitarget, Downport, …

abap-file-formats

          <h1 class="no_toc" id="abapgit-als-enabler-von-open-source">abapGit als Enabler von Open Source</h1>

Übersicht
Verfügbarkeit und Versionen von abapGit
Voraussetzungen
Konfiguration und Einrichtung
Risiken

Übersicht

Übersichtsgrafik

Verfügbarkeit und Versionen von abapGit

Voraussetzungen

OP/Private Cloud: 702, Netzwerkverbindung oder Offline-Repos
BTP/Public Cloud: Schon da, eingeschränkt, nur Online-Repos
Jemand muss sich kümmern

Konfiguration und Einrichtung

Insbesondere Exits

Risiken

Berechtigungen
Möglichkeit der massenhaften Extraktion der gesamten propritären Codebase und Mitnehmen zur Konkurrenz
Möglichkeit am Transportwesen vorbei massenhaft Software zu installieren

          {: .no_toc}

Vorstellung ausgewählter Projekte

Übersicht

Eine Übersicht von ABAP Open Source Projekten findet sich auf dotabap.org. Dort finden sich aktuell knapp 300 Projekte. Sollte Dein Projekt noch fehlen kann dies wie hier beschrieben durch einen Pull Request ergänzt werden.

Projekte zur Unterstützung des Entwicklungsprozesses

abapOpenChecks

Mit abapOpenChecks werden Prüfungen für den SAP Code Inspector und das ABAP Test Cockpit bereitstellt. Überblick:

Besitzer: larshp
Erstellt am: 7. Juli 2014
Standardbranch: main
Programmiersprache: ABAP
Lizenz: MIT License
Sterne: 276
Forks: 79
Offene Issues: 304
Geschlossene Issues: 439
Letzter Push: 24. Oktober 2024
Homepage: docs.abapopenchecks.org

abaplint

Mit abaplint/abaplint können statische Codeanalysen für ABAP Durchgeführt werden. Überblick:

Besitzer: abaplint
Erstellt am: 20. Dezember 2015
Standardbranch: main
Programmiersprache: Hauptsächlich TypeScript (97,6 %), gefolgt von ABAP (1,7 %), JavaScript (0,6 %), CSS (0,1 %) und HTML sowie Less (< 0,1 %)
Lizenz: MIT License
Sterne: 227
Forks: 70
Offene Issues: 370
Geschlossene Issues: 1.588
Letzter Push: 24. Oktober 2024
Homepage: abaplint.org

code pal for ABAP

Mit Code Pal for ABAP bzw. Code Pal for ABAP - Cloud Edition werden ATC-Prüfungen bereitstellt, um ABAP-Programmierer*innen bei der Einhaltung des Clean ABAP Style Guide zu unterstützen. Überblick:

Besitzer: SAP
Erstellt am: 2. April 2020
Standardbranch: master
Programmiersprache: ABAP (100 %)
Lizenz: Apache License 2.0
Sterne: 348
Forks: 65
Offene Issues: 30 / 8
Geschlossene Issues: 235 / 19
Letzter Push: 19. August 2024

ABAP OpenAPI Client & Server Generator

Mit abap-openapi/abap-openapi können aus einer OpenAPI Spezifikation ein ABAP Client- bzw. Server generiert werden. Viele SAP SaaS und auch Anwendungen außerhalb der SAP Welt stellen APIs mit einer OpenAPI Spezifikation bereit. Um diese in ABAP zu verwenden kann mit ABAP OpenAPI ein Client basierend auf einem ABAP Interface für die Datendefinitionen und einer ABAP Klasse für die Client Implementierung generiert werden. Damit lassen sich direkt aus ABAP heraus nicht nur SOAP und OData, sondern auch REST APIs ansprechen. Überblick:

Besitzer: abap-openapi
Erstellt am: 19. Januar 2021
Standardbranch: main
Programmiersprache: ABAP (99,6 %), Other (0,4 %)
Lizenz: MIT License
Sterne: 73
Forks: 9
Offene Issues: 23
Geschlossene Issues: 26
Letzter Push: 15. Oktober 2024
Homepage: abap-openapi.github.io/web-openapi-client

Projekte als Bestandteil eigener Erweiterungen oder Produkte

abap2ui5

Mit abap2UI5/abap2UI5 können SAPUI5-Apps ausschließlich in ABAP entwickelt werden. Überblick:

Besitzer: abap2UI5
Erstellt am: 5. Dezember 2022
Standardbranch: main
Programmiersprachen: ABAP (94,6 %), JavaScript (5,3 %), Andere (0,1 %)
Lizenz: MIT License
Sterne: 293
Forks: 57
Offene Issues: 6
Geschlossene Issues: 352
Letzter Push: 28. Oktober 2024
Homepage: abap2UI5.org

abap2xlsx

Mit abap2xlsx/abap2xlsx können im ABAP Applikationsserver professionelle Excel-Tabellen erstellt und gelesen werden. Überblick:

Besitzer: abap2xlsx
Erstellt am: 26. Dezember 2013
Standardbranch: main
Programmiersprache: ABAP (100 %)
Lizenz: Apache License 2.0
Sterne: 712
Forks: 291
Offene Issues: 115
Geschlossene Issues: 722
Letzter Push: 25. Oktober 2024
Homepage: abap2xlsx.github.io/abap2xlsx

Anwendungsfälle

Erzeugung formatierter Berichte
Download und Upload zur Datenpflege

Integration

Integration

Einführung

Die Integration von SAP Systemen, und auch Non-SAP Systemen, würde an sich den Rahmen dieses Leitfadens sprengen. Daher finden Sie hier vor allem aktuell genutzte Technologien und eine ungefähre Richtung, welche Technologien die nächsten Jahre bestehen werden. Dabei sollten Sie immer im Hinterkopf behalten, dass auch das Thema Middleware eine wichtige Rolle beim Verteilen von Daten und dem Monitoring sind. Siehe auch Rubrik Kapitel Clean Core

Zusätzlich sollten Sie beachten, dass mit der zunehmenden Migration von SAP-Systemen in die Cloud, nicht-funktionale Anforderungen (NFRs) wie Verfügbarkeit, Sicherheit, Skalierbarkeit und Beobachtbarkeit (Englisch: observability) von Anfang an zu berücksichtigen. Diese Aspekte sind in On-Premise-Umgebungen oft selbstverständlich, müssen aber in der Cloud neu durchdacht und aktiv integriert werden. Eine unzureichende Planung kann zu hohen Kosten für Nachbesserungen führen, insbesondere wenn ein System erst bei steigender Nutzerzahl oder im Ernstfall seine Grenzen aufzeigt. Siehe Artikel “The Seven Reasons Your SAP Tech Initiatives Are Failing”

Business Accelerator Hub

Der Business Accelerator Hub von SAP stellt standardisierte Dokumentationen zu allen Arten von Schnittstellen zur Verfügung. Möchten Sie mehr über die verfügbaren Standard Schnittstellen zu Ihrem SAP Produkt erfahren, sollten Sie zuerst einmal hier die Möglichkeiten prüfen. Die Suche nach Produkt, Technologie und Modul vereinfacht das Finden der richtigen Schnittstellen.

Technologie

In diesem Abschnitt geht es um verschiedene Schnittstellentechnologien und Sie erhalten hier einen groben Überblick über die gängigen Technologien.

IDoc

Intermediate Document, kurz IDoc, ist ein Datenaustauschformat von SAP, um verschiedene Systeme miteinander zu integrieren. Die Daten können dabei ins System geladen oder daraus exportiert werden. Die meisten IDocs werden auf Positionsbasis erstellt, das heißt der gesamte Datensatz steht auf einer Zeile und es wird per Identifikation (meist der erste Teil der Zeile) das Format für die Daten abgeleitet. In aktuelleren Systemen gibt es auch IDocs im XML Format.

RFC

Remote Function Call, kurz RFC, ist die Verwendung von klassischen Funktionsbausteinen zur Kommunikation über Systemgrenzen hinweg. Dabei können sogenannte Destionations verwendet werden, um einen Funktionsbaustein in einem anderen System aufzurufen.

Der Aufruf von Funktionsbausteinen von Non-SAP-Systemen ist ebenfalls möglich, dafür gibt es für die verschiedenen Programmiersprachen Adapter, die meist durch SAP zur Verfügung gestellt werden. Dazu finden Sie hier einige Beispiele:

SOAP

Simple Object Access Protocol, kurz SOAP, ist ein standardisiertes Schnittstellenformat zum Austausch von XML Nachrichten zwischen verschiedenen Systemen. Die Technologie wird auch außerhalb der SAP Welt für Schnittstellen genutzt. Das Format der Payload beschränkt sich nicht auf XML, sondern es können auch CSV oder BASE64 Daten verwendet werden (muss noch geprüft werden).

OData

Das Open Data Protocol, kurz OData, ist ein standardisiertes Protokoll für HTTP Kommunikation. Darin werden Standards beschrieben, wie Anfragen und Antworten von Schnittstellen zur Verfügung gestellt wird und wie in Integration in das HTTP Protokoll aussieht. Die Kommunikation kann im Format XML, aber auch JSON, erfolgen. OData ist mittlerweile der Standard zum Aufbau von UI und API Schnittstellen im SAP System. Die aktuell verfügbare Version ist “OData v4” und ermöglicht gegenüber “OData v2” weitere Möglichkeiten zur Integration von Anwendungen.

HTTP

Grundsätzlich können alle Schnittstellen die über Hypertext Transfer Protocol, kurz HTTP, verfügen, auch über SAP und per HTTP Client konsumiert werden. Meist beschränkt sich die Implementierung allerdings auf eine Individualentwicklung und Sie sollten vorher prüfen, ob es nicht Standardaustauschformate wie OData oder SOAP gibt.

Event

Die aktuelle Integration können Sie mit Events schaffen. Dabei wird zu definierten Zeitpunkten im Standard- oder Kundenprozess ein Event erzeugt, welches in einer Queue (bspw. über SAP Event Mesh) zur Verfügung gestellt wird. Auf die Queue können sich interessierte Anwendungen und Prozesse registrieren, die dann über neue Events benachrichtigt werden. Ein Event ist meist eine einfache Nachricht mit dem auslösenden Event, dem Schlüssel des Objekts und einer Payload.

Clean Core

Welche Technologien sind bei der Umstellung auf Clean Core eigentlich noch relevant und welche sollten Sie am besten schon heute vermeiden? In diesem Abschnitt erfahren Sie mehr über die empfohlenen Technologien beim Aufbau oder der Migration zu Clean Core. Im SAP Leitfaden “Supporting Business Transformation with a Cloud ERP Clean Core Strategy” finden Sie Hinweise dazu.

Clean Integration

Empfehlung zu Clean Core Integration{: .img-caption}

Dazu erhalten Sie hier die Übersicht der oben genannten Technologien unterteilt in die Bereiche zum Weiterführen und zum Vermeiden. Die Verteilung ergibt sich aus den Empfehlungen des Leitfadens.

Verwenden	Vermeiden
OData	RFC
SOAP	IDoc
Events
HTTP (REST)

Empfehlungen für Grenzfälle

Bei der Integration von SAP-Systemen gibt es Grenzfälle, in denen nicht alle standardisierten SAP-Integrationsarten optimal genutzt werden können. In solchen Szenarien ist es essenziell, eine sorgfältige Abgrenzung zu anderen SAP- sowie Non-SAP-Tools vorzunehmen.

Berücksichtigung zukünftiger Entwicklungen

SAP entwickelt seine Integrationslösungen kontinuierlich weiter. Daher sollte stets geprüft werden, welche Technologien zukünftig an Bedeutung gewinnen und welche möglicherweise durch neuere Lösungen ersetzt werden. Eine zukunftsorientierte Planung hilft, technologische Sackgassen zu vermeiden und die Integration langfristig stabil und nachhaltig zu gestalten.

Bestand alter Technologien

Obwohl SAP kontinuierlich neue Integrationslösungen bereitstellt, sind einige ältere Technologien weiterhin wertvoll und können noch nicht vollständig abgelöst werden. Daher ist es wichtig, bestehende Lösungen nicht vorschnell außer Betrieb zu nehmen, sondern ihre Relevanz im jeweiligen Unternehmenskontext zu bewerten. Beispielsweise sind IDoc und RFC in vielen Legacy-Systemen tief verankert und bieten weiterhin zuverlässige Kommunikationsmöglichkeiten.

Nachhaltige Architektur und Clean-Core-Strategie

Die Gestaltung einer nachhaltigen Architektur sollte unter Berücksichtigung der Clean-Core-Strategie erfolgen. Die Public Cloud dient hier oft als Vorbild für Musterintegrationen, die sich durch hohe Standardisierung und Wartungsfreundlichkeit auszeichnen. Ziel ist es, den individuellen Code-Anteil gering zu halten und Standardlösungen zu bevorzugen.

Wichtige Entscheidungsfaktoren bei Grenzfällen

Kosten: Der finanzielle Aufwand für Entwicklung(sressourcen), Betrieb, Lizensen und Wartung muss gegen den Nutzen abgewogen werden.
Features: Prüfen, ob bestehende Integrationslösungen alle benötigten Funktionen abdecken oder Anpassungen erforderlich sind.
Vendor Lock-In: Abhängigkeiten von bestimmten SAP- oder Drittanbieter-Technologien sollten kritisch betrachtet werden.
Monitoring: Eine effektive Überwachung der Integration ist essenziell, um Probleme frühzeitig zu erkennen und zu beheben. Für den Fall von Systemausfällen sind Reprozessierung-szenarien vorzusehen.

Beispiel: Massendatentransferierung

EDI (Electronic Data Interchange) im S/4 HANA

(Web) APIs basierend auf REST oder SOAP haben ihre Grenzen. Dafür sollten anderen Technologien eingesetzt werden. Beispielsweise SAP EDI ist für die Verarbeitung großer Mengen elektronischer Daten konzipiert für 100.000+ Nachrichten pro Tag – und erfolgt mit zahlreichen B2B-Partnern unter Verwendung standardisierter Formate wie EDIFACT.

Im direkten Vergleich wird schnell klar, warum IDocs für SAP EDI die bessere Wahl sind: Sie sind asynchron, für Massendaten ausgelegt und bieten vordefinierte Validierungen sowie robuste Monitoring- und Reprocessing-Mechanismen. APIs hingegen sind meistens synchron, verarbeiten Nachrichten einzeln und erfordern zusätzlichen Aufwand für Fehlerbehandlung und Mappings. In Hochlast-Szenarien kann eine API-basierte EDI-Integration daher erhebliche Performance-Probleme und hohe Betriebskosten verursachen.

Weitere Lösungswege für Massendatentranferierung

SAP Landscape Transformation Replication Server, ABAP und NetWeaver basiert
SAP HANA Smart Data Integration (SDI), SAP HANA Datenbank basiert
Master Data Governance (MDG), basiert auf den Data Repliaction Framework im ERP

Cloud Connector

Sind Sie im Bereich der Business Technology Platform (BTP) unterwegs, benötigen sie auch einen Cloud Connector in ihrer Infrastruktur, um eine Verbindung von der Cloud nach On-Premise aufbauen zu können. Der Cloud Connector fungiert als Gateway und Proxy und routet den Netzwerkverkehr aus dem Internet zu den richtigen Systemen in ihrer Landschaft hinter der Firewall.

Aufbau

Beim Aufbau Ihrer Cloud Connector Landschaft sollten Sie auf die Trennung der Systemschienen achten, da in Produktion meist die strikteren Regeln für Zugriffe auf Ressourcen gelten. In diesem Fall werden mindestens zwei Instanzen vorgeschlagen, einmal für DEV/TEST und eine für PROD. Je nach laufenden Prozessen und Wichtigkeit, sollten Sie über eine entsprechende ausfallsichere Struktur nachdenken (Hochverfügbarkeit).

Protokolle

Aktuell gibt es zwei Protokolle, die in den meisten Anwendungsfällen und Zugriffen verwendet werden.

HTTP - Führend ist hierbei das Protokoll OData und SOAP, es ist aber auch Plain HTTP möglich, um Daten und Systeme in On-Premise anzusprechen.
RFC - RFC-fähige Funktionsbausteine können ebenfalls konsumiert werden, auch wenn sie nicht mehr die strategische Zielrichtung der SAP sind, so stehen damit viele Funktionen des Systems zur Verfügung, ohne Clean Core zu verletzen.

Die Freigabe der Ressourcen erfolgt in den jeweilig konfigurierten Systemen im Cloud Connector. Bei HTTP werden entsprechende Pfade/URLs freigegeben, bei RFC die entsprechenden Funktionsbausteine. In Produktion empfiehlt sich eine explizite Freigabe von Ressourcen und die Vermeidung von Wildcards (*).

Erweiterungen

Erstellen Sie Erweiterungen in der BTP, dann tun sie das normalerweise mit CAP (Cloud Application Programming Model) oder RAP (ABAP RESTful Application Programming Model). Damit Sie dann auf Daten zugreifen können, benötigen Sie einen konfigurierten Cloud Connector an dem Sub-Account. Die Konfiguration ist nicht Teil dieses Leitfadens, da er meist durch Ihre SAP Basis durchgeführt wird.

In den meisten Fällen werden sie im Destination Service der BTP die Verbindung zum On-Premise System konfigurieren. Verwenden Sie das SAP BTP ABAP Environment um Ihre Erweiterungen zu erstellen, dann können Sie diese auch im System als Communication Arrangements und Communication Systems abbilden und benötigen die Konfiguration im Destination Service nicht. Wollen Sie allerdings Standard-Fiori Anwendungen erweitern, benötigen Sie einen Zugriff über den Sub-Account, um auf Ihre Systeme Zugriff zu erhalten.

Zugriffsrichtung

Bisher hatten Sie vor allem von Zugriffen aus dem Internet oder der BTP Richtung On-Premise gelesen. Der Cloud Connector kann aber auch als Proxy genutzt werden, um von einem On-Premise System auf ein Cloud System zu routen und die direkte Anbindung des Cloud Systems zu vermeiden. Das ABAP Test Cockpit auf dem ABAP Environment ist zum Beispiel so ein Fall.

    <h1 class="no_toc" id="sicherheit">Sicherheit</h1>

Dieses Kapitel beschreibt ein paar Themengebiete rundum ABAP Entwicklung und es werden ein paar Konzepte erläurtert. Der Fokus liegt hier auf Applikationssicherheit; die SAP-Basis und System-Sicherheitsthemen nicht näher betrachtet. Wir empfehlen Ihnen einen Threat-Modelling-Workshop für SAP-System-Angriffszenarien und ihre Abdeckung durchzuführen.

Das Themengebiet Sicherheit in der ABAP Entwicklung ist komplex und die hier aufgeführten Sicherheitsthemen sind ein guter Start. Bei weiteren Fragen weist der Leitfaden auf Referenzen und weitergehende Literatur hin.

          {: .no_toc}

Überblick

ABAP Security: Warum sichere Programmierung in SAP entscheidend ist

Vom funktionierenden Code zur sicheren Anwendung

Als ABAP-Entwickler kennen Sie das: Ein neues Projekt steht an, die Anforderungen sind klar definiert, und der Zeitdruck ist hoch. Die Prioritäten sind schnell gesetzt – die Funktion muss implementiert werden, der Code soll wartbar und performant sein. Doch wo bleibt dabei die Sicherheit?

In der Realität vieler SAP-Projekte spielt Code Security eine untergeordnete Rolle. Während wir uns intensiv Gedanken über Datenstrukturen, Algorithmen und Performance-Optimierung machen, wird die Sicherheit oft als “nice-to-have” betrachtet oder ganz übersehen. Dabei sind gerade SAP-Systeme besonders schützenswert – sie beherbergen die wertvollsten Daten eines Unternehmens.

ABAP-Code: Der Schlüssel zu den Kronjuwelen

Ihr ABAP-Code ist mehr als nur Programmlogik. Er ist der Schlüssel zu den digitalen Kronjuwelen Ihres Unternehmens:

Vollzugriff auf Unternehmensdaten: Stammdaten, Finanzdaten, Personalinformationen – alles ist über ABAP erreichbar
Systemübergreifende Verbindungen: RFC-Calls, Webservices und Schnittstellen verbinden Ihr SAP-System mit der gesamten IT-Landschaft
Privilegierte Systemzugriffe: ABAP-Programme laufen oft mit erweiterten Berechtigungen und können Sicherheitsbarrieren umgehen

Unsicherer ABAP-Code kann nahezu alle etablierten Sicherheitsmaßnahmen aushebeln:

Rollen- und Profilberechtigungen werden umgangen
Mandantentrennungen verlieren ihre Wirkung
Betriebssystem-Berechtigungen werden übersprungen
Firewall-Regeln und Netzwerksperren werden unterlaufen

Der Teufelskreis der nachgelagerten Sicherheit

Viele Entwicklungsprojekte folgen einem bekannten Muster:

Funktion implementieren – Das Programm muss erstmal laufen
Wartbarkeit sicherstellen – Code-Qualität und Dokumentation
Performance optimieren – Wenn es zu langsam wird, wird nachgebessert
Sicherheit nachrüsten? – Oft bleibt dafür keine Zeit oder kein Budget

Dieses Vorgehen ist problematisch, denn Sicherheit nachträglich zu implementieren ist nicht nur aufwendig, sondern oft unmöglich ohne grundlegende Neuimplementierung. Was als kleiner “Security-Fix” geplant war, wird schnell zur kompletten Architektur-Überarbeitung.

Warum Security von Anfang an mitgedacht werden muss

Wirtschaftliche Gründe sprechen klar für “Security by Design”:

Kostenfaktor: Sicherheitslücken nachträglich zu schließen ist 10-100x teurer als sichere Programmierung von Beginn an
Risikominimierung: Ein einziger Sicherheitsvorfall kann Millionenschäden verursachen
Compliance: Regulatorische Anforderungen (DSGVO, SOX, etc.) erfordern nachweisbar sichere Entwicklungsprozesse
Reputation: Datenschutzverletzungen beschädigen das Vertrauen von Kunden und Geschäftspartnern nachhaltig

Technische Vorteile sicherer Programmierung:

Datensparsamkeit: Sicherer Code verarbeitet nur notwendige Daten und schont Serverressourcen
Stabilität: Security-bewusste Programmierung führt zu robusterem Code
Wartbarkeit: Explizite Sicherheitsprüfungen machen Code verständlicher und nachvollziehbarer

Ihr Beitrag zur Unternehmenssicherheit

Als ABAP-Entwickler tragen Sie eine besondere Verantwortung. Ihr Code läuft im Herzen der Unternehmens-IT und hat Zugriff auf die wertvollsten Daten. Mit dem Wissen aus diesem Kapitel können Sie:

Sicherheitslücken bereits in der Entwicklungsphase vermeiden
Bestehenden Code auf potenzielle Schwachstellen analysieren
Ein Bewusstsein für Security-Aspekte in Ihrem Entwicklungsteam schaffen
Zur Gesamtsicherheit der SAP-Landschaft beitragen

Sicherer ABAP-Code ist kein Luxus – er ist eine Notwendigkeit in der heutigen vernetzten Geschäftswelt. Lassen Sie uns gemeinsam dafür sorgen, dass Ihre Entwicklungen nicht nur funktional und performant, sondern auch sicher sind.

Die folgenden Abschnitte führen Sie durch konkrete Sicherheitsaspekte mit praxisnahen Beispielen und Lösungsansätzen. Jeder Code-Schnipsel wurde so gewählt, dass er reale Herausforderungen aus dem Entwicklungsalltag widerspiegelt.

          {: .no_toc}

Grundlagen

Die häufigsten ABAP-Sicherheitslücken im Überblick

Nach der Einführung in die Bedeutung sicherer ABAP-Programmierung ist es wichtig, die konkreten Bedrohungen zu verstehen, denen SAP-Systeme täglich ausgesetzt sind. Die Erfahrung aus Hunderten von SAP-Sicherheitsaudits zeigt ein klares Bild: Bestimmte Schwachstellen-Muster wiederholen sich immer wieder in ABAP-Code.

Die Top 5 der ABAP-Sicherheitslücken

1. SQL-Injection durch dynamische Datenbankabfragen Der Klassiker unter den Sicherheitslücken: Benutzereingaben werden ungefiltert in SQL-Statements eingebaut. Ein harmlos aussehender Report kann so zum Einfallstor für Datendiebstahl werden. Besonders tückisch: Die meisten Entwickler kennen SQL-Injection aus der Web-Entwicklung, übersehen aber die ABAP-spezifischen Varianten in Open SQL und Native SQL. ABAP Schützt hier vor dem den ganz großen Problemen, bspw. der Webentwicklung mit “DROP DATABASE;”. Allerdings enthält das SAP System immer die Kronjuwelen der Daten, so dass unberechtigte Zugriffe schwerere Auswirkungen im BusinessKontext haben.

2. Fehlende oder unvollständige Berechtigungsprüfungen ABAP-Programme laufen oft mit erweiterten Systemrechten (unter anderem im Batch oder gegenüber dem Betriebssystem). Wenn die explizite Prüfung von Benutzerberechtigungen fehlt oder unvollständig implementiert ist, können Anwender auf Daten und Funktionen zugreifen, die ihnen eigentlich verwehrt sein sollten. Besonders kritisch wird es bei RFC-fähigen Funktionsbausteinen, die über das Netzwerk aufgerufen werden können.

3. Cross-Site Scripting (XSS) in Web-Dynpro und BSP-Anwendungen Sobald ABAP-Code Daten für Webanwendungen ausgibt, droht XSS. Ungefilterter HTML-Code in Benutzereingaben kann zu verschiedenen Problemen im Backend führen. Viele SAP Systeme “bereinigen” Benutzereingaben nicht und das Problem verstärkt sich durch die sich immer Verbreitende Nutzung moderner Frontend-Technologien wie Fiori und UI5.

4. Code-Injection in dynamischen ABAP-Konstrukten ABAP bietet mächtige Funktionen für dynamische Programmierung: GENERATE SUBROUTINE POOL, dynamische Methodenaufrufe, RTTI (Run Time Type Information) oder XCO. Diese Flexibilität kann zum Sicherheitsrisiko werden, wenn Benutzereingaben ungefiltert in dynamischen Code-Konstrukten verwendet werden.

Warum entstehen diese Schwachstellen immer wieder?

Die Ursachen sind vielfältig, aber vorhersagbar:

Zeitmangel und Projektdruck: Sicherheitsprüfungen werden als “zusätzlicher Aufwand” gesehen und bei knappen Deadlines gestrichen. Dabei ist sicherer Code oft nicht komplexer als unsicherer – er erfordert nur das richtige Bewusstsein.

Fehlende Security-Awareness: Viele ABAP-Entwickler kommen aus der klassischen betriebswirtschaftlichen Anwendungsentwicklung oder sind technisch interessiert Keyuser gewesen und haben Security-Aspekte nie systematisch gelernt. Was in der Java- oder .NET-Welt Standard ist, ist in der ABAP-Welt oft unbekannt.

Komplexität der SAP-Berechtigungskonzepte: SAP-Autorisierungen sind komplex und vielschichtig. Entwickler verlassen sich darauf, dass “das System schon richtig konfiguriert ist”, ohne zu verstehen, wo ihre Verantwortung beginnt.

Legacy-Code ohne Security-Fokus: Viele SAP-Systeme enthalten Code aus den 1990er Jahren, als Sicherheit noch keine Priorität hatte. Dieser Code wird oft kopiert und als Vorlage für neue Entwicklungen verwendet – samt seiner Schwachstellen.

Security-Mindset: Vom reaktiven zum proaktiven Denken

Der entscheidende Unterschied zwischen sicherer und unsicherer Software liegt nicht in der Technologie – er liegt in der Denkweise der Entwickler. Ein “Security-Mindset” bedeutet, Sicherheit nicht als nachträgliche Prüfung zu betrachten, sondern als integralen Bestandteil des Entwicklungsprozesses.

Reaktives vs. proaktives Security-Denken

Reaktiver Ansatz – “Security als Feuerwehr”:

Sicherheitslücken werden erst behoben, wenn sie entdeckt werden
Security-Tests finden erst am Ende der Entwicklung (oder gar nicht) statt
Schwachstellen erfordern oft grundlegende Code-Änderungen
Hohe Kosten durch Nachbesserungen und mögliche Sicherheitsvorfälle

Proaktiver Ansatz – “Security by Design”:

Sicherheitsanforderungen werden von Anfang an mitgedacht
Jede Funktion wird unter Sicherheitsaspekten entworfen
Kontinuierliche Sicherheitsprüfungen während der Entwicklung
Geringere Gesamtkosten durch Vermeidung von Nachbesserungen

Die Prinzipien des Security-Mindsets

1. Vertraue niemals, prüfe immer Jede Eingabe ist potenziell gefährlich – egal ob sie von einem vertrauenswürdigen System oder einem internen Benutzer kommt. Implementieren Sie Validierung und Sanitizing für alle Eingaben, auch für interne Schnittstellen. Der schlimmste Satz für einen Entwickler sollte der “Ich brauche das nicht Testen, ich vertraue dir!” sein. Dies wälzt die Verantwortung alleine auf den Entwickler.

2. Minimiere die Angriffsfläche Exponieren Sie nur die Funktionen, die wirklich benötigt werden, Löschen Sie was überflüssig geworden ist. Ein RFC-fähiger Funktionsbaustein, der nur intern verwendet wird, ist eine unnötige Schwachstelle. Der alte, obsolete Report, den man aus “Dokumentationsgründen” noch im System lässt wird zur Falle. Implementieren Sie das Prinzip der minimalen Berechtigung – sowohl für Code als auch für Benutzer.

3. Denken Sie wie ein Angreifer Fragen Sie sich bei jeder Funktion: “Wie könnte jemand diese missbrauchen?” Betrachten Sie nicht nur den vorgesehenen Anwendungsfall, sondern auch mögliche Missbrauchsszenarien. Was passiert, wenn jemand unerwartete Eingaben macht oder mehrere Funktionen in unvorhergesehener Reihenfolge aufruft? Sind alle Fehler abgefangen?

4. Implementieren Sie Defense in Depth Verlassen Sie sich nie auf eine einzige Sicherheitsmaßnahme. Kombinieren Sie Input-Validierung, Berechtigungsprüfungen, Output-Encoding und Logging. Wenn eine Schutzmaßnahme versagt, sollten andere greifen. Sorgen Sie in ihrer Abteilung für eine einheitliche Art des Loggings, so dass Probleme schnell sichtbar werden.

5. Machen Sie Sicherheit transparent Dokumentieren Sie Ihre Sicherheitsmaßnahmen im Code. Verwenden Sie aussagekräftige Variablennamen und Kommentare, die auch späteren Entwicklern zeigen, warum bestimmte Prüfungen implementiert wurden.

Der Weg zur Security-Kultur im Team

Die Entwicklung eines Security-Mindsets ist nicht nur eine individuelle Aufgabe – sie erfordert eine Kulturveränderung im gesamten Entwicklungsteam:

Wissensaufbau: Regelmäßige Security-Schulungen und der Austausch über aktuelle Bedrohungen schaffen Bewusstsein. Nutzen Sie interne Präsentationen, um konkrete Beispiele aus Ihren eigenen Systemen zu diskutieren.

Integration in den Entwicklungsprozess: Machen Sie Sicherheitsprüfungen zu einem festen Bestandteil Ihrer Code-Reviews. Entwickeln Sie Checklisten und Guidelines, die jedem Entwickler helfen, sicherheitsrelevante Aspekte zu berücksichtigen.

Positive Fehlerkultur: Behandeln Sie entdeckte Sicherheitslücken als Lernmöglichkeiten, nicht als Versagen. Teams, die offen über Schwachstellen sprechen können, entwickeln ein stärkeres Sicherheitsbewusstsein.

Kontinuierliche Verbesserung: Analysieren Sie regelmäßig aufgetretene Sicherheitsprobleme und leiten Sie systematische Verbesserungen ab. Welche Schwachstellen-Muster treten wiederholt auf? Wie können Sie diese in Zukunft vermeiden?

Das Security-Mindset ist kein Ziel, das man einmal erreicht – es ist eine kontinuierliche Haltung, die jeden Tag gelebt werden muss. Mit dem Wissen um die häufigsten Schwachstellen und der richtigen Einstellung können Sie dazu beitragen, dass Ihre ABAP-Entwicklungen nicht nur funktional und performant, sondern auch sicher sind.

          {: .no_toc}

Bedrohungen

SQL-Injection in ABAP: Angriffsvektoren und Abwehrmaßnahmen

SQL-Injection gehört zu den gefährlichsten und zugleich am häufigsten übersehenen Schwachstellen in ABAP-Systemen. Während viele Entwickler glauben, dass OpenSQL automatisch vor Injection-Angriffen schützt, zeigt die Praxis ein anderes Bild.

Angriffsvektoren in ABAP

Native SQL – Der offensichtliche Risikofaktor:

" GEFÄHRLICH: Direkte Einbindung von Benutzereingaben
DATA: lv_where TYPE string.
lv_where = |MANDT = '{ sy-mandt }' AND KUNNR = '{ p_kunnr }'|.
EXEC SQL.
  SELECT * FROM KNA1 WHERE :lv_where
ENDEXEC.

Ein Angreifer könnte p_kunnr mit ' OR '1'='1 befüllen und erhält Zugriff auf alle Kundendaten. Noch kritischer wird es bei UPDATE- oder DELETE-Statements.

OpenSQL – Vermeintlich sicher, aber tückisch: Auch OpenSQL ist nicht automatisch immun gegen Injection-Angriffe, besonders bei dynamischen WHERE-Klauseln:

" GEFÄHRLICH: Dynamische WHERE-Klausel ohne Validierung
DATA: lv_where TYPE string.
lv_where = |KUNNR = '{ p_kunnr }'|.
SELECT * FROM kna1 WHERE (lv_where) INTO TABLE lt_customers.

RFC-Funktionsbausteine als Einfallstor: Besonders kritisch werden SQL-Injections, wenn sie über RFC-Schnittstellen ausgenutzt werden können. Ein unsicherer Funktionsbaustein kann zum Sprungbrett für Angriffe aus dem gesamten Netzwerk werden. Der Funktionsbaustein RFC_READ_TABLE implementiert eine solche, dynamische Programmierung.

Effektive Abwehrmaßnahmen

1. Parametrisierte Queries verwenden:

" SICHER: Verwendung von Platzhaltern
SELECT * FROM kna1 
  WHERE kunnr = @p_kunnr 
  INTO TABLE @lt_customers.

2. Input-Validierung implementieren:

" Validierung von Eingaben vor Datenbankzugriff
IF p_kunnr CA ';''"`*%_'.
  MESSAGE 'Ungültige Zeichen in Eingabe' TYPE 'E'.
ENDIF.

3. Escaping-Funktionen nutzen: Für unvermeidbare dynamische Konstrukte sollten SAP-eigene Escaping-Funktionen verwendet werden, um gefährliche Zeichen zu neutralisieren.

Cross-Site Scripting (XSS) in SAP-Webanwendungen

Mit der zunehmenden Webbasierung von SAP-Anwendungen durch Fiori, UI5 und Web Dynpro werden XSS-Angriffe zu einem kritischen Risikofaktor. ABAP-Entwickler müssen verstehen, wie ihre Backend-Logik zur Frontend-Sicherheit beiträgt.

XSS-Angriffsvektoren in SAP

Stored XSS in Stammdaten:

" GEFÄHRLICH: Ungefilterter HTML-Code in Ausgabe
DATA: lv_name TYPE kna1-name1.
lv_name = '<script>alert("XSS")</script>Kunde GmbH'.
" Direkte Ausgabe ohne Encoding führt zu XSS

Wenn dieser Kundenname später in einer Webanwendung angezeigt wird, wird der JavaScript-Code ausgeführt. Besonders tückisch: Der Schadcode wird persistent in der Datenbank gespeichert und betrifft alle Benutzer, die diese Daten anzeigen.

Reflected XSS in URL-Parametern: Web Dynpro- und BSP-Anwendungen, die URL-Parameter direkt in die HTML-Ausgabe einbinden, sind anfällig für Reflected XSS. Ein präparierter Link kann ausreichen, um Schadcode zu injizieren.

DOM-basiertes XSS in modernen UI5-Anwendungen: Bei der Integration von ABAP-Backend-Daten in moderne Frontend-Frameworks entstehen neue Angriffsvektoren, wenn JSON-Responses ungefilterte Benutzerdaten enthalten.

Schutzmaßnahmen gegen XSS

1. Output-Encoding implementieren:

" HTML-Encoding für Web-Ausgabe
DATA: lv_encoded TYPE string.
lv_encoded = cl_http_utility=>escape_html( lv_user_input ).

2. Content Security Policy (CSP) nutzen: Konfigurieren Sie CSP-Header in Ihren Webanwendungen, um die Ausführung von Inline-JavaScript zu verhindern.

3. Eingabevalidierung am Backend: Implementieren Sie strenge Validierungsregeln für alle Eingaben, die später in Webanwendungen dargestellt werden.

Unsichere Direktzugriffe auf Objekte und Autorisierungsumgehung

Diese Schwachstellenklasse entsteht, wenn ABAP-Programme Objektreferenzen direkt aus Benutzereingaben übernehmen, ohne zu prüfen, ob der Benutzer berechtigt ist, auf diese Objekte zuzugreifen.

Typische Angriffsmuster

Horizontale Rechteausweitung: Ein Sachbearbeiter ändert eine Kundennummer in einem URL-Parameter und erhält plötzlich Zugriff auf Daten anderer Kunden, für die er keine Berechtigung hat.

Vertikale Rechteausweitung: Durch Manipulation von Organisationseinheiten oder Buchungskreisen in Parametern kann ein Benutzer auf Daten zugreifen, die seiner Hierarchieebene nicht entsprechen.

Session-Hijacking durch vorhersagbare IDs: Wenn interne Objekt-IDs oder Session-Kennungen vorhersagbar sind, können Angreifer systematisch verschiedene Werte ausprobieren.

Effektive Autorisierungsprüfungen

1. Explizite Berechtigungsprüfung:

" Immer explizite Berechtigung prüfen
AUTHORITY-CHECK OBJECT 'F_KNA1_BEK'
  ID 'KUNNR' FIELD p_kunnr
  ID 'ACTVT' FIELD '03'.
IF sy-subrc <> 0.
  MESSAGE 'Keine Berechtigung' TYPE 'E'.
ENDIF.

Für alle Objekte mit ABAP Code gilt hier: 1) die Berechtigungsprüfung machen 2) SY-SUBRC auswertung nicht vergessen 3) Ranges entsprechend erweitern mit SIGN = ‘E’ und ‘EQ’ 4) SELECT auf die Haupttabelle machen

In vielen Fällen haben Fachbereiche eine Debugberechtigung, damit im Supportfall schnell von der Entwicklung geholfen werden kann. In solchen Fällen könnte sich ein Sachbearbeiter einen Break-point setzen und die gesamte Tabelle vor der Berechtigungsprüfung über den Debugger herunterladen.

2. Kontextuelle Autorisierung: Prüfen Sie nicht nur die Berechtigung für ein Objekt, sondern auch den Kontext der Anfrage (Organisationseinheit, Zeitraum, etc.). Scheuen Sie sich nicht eine Abfrage mehrfach ausführen zu lassen.

Code-Injection und Dynamic Programming Risiken

ABAP bietet mächtige Funktionen für dynamische Programmierung, die bei unsachgemäßer Verwendung zu schwerwiegenden Sicherheitslücken führen können.

Gefährliche dynamische Konstrukte

GENERATE SUBROUTINE POOL:

" EXTREM GEFÄHRLICH: Direkte Code-Generierung
DATA: lv_code TYPE string.
lv_code = |FORM test. WRITE '{ p_input }'. ENDFORM.|.
GENERATE SUBROUTINE POOL lv_code NAME lv_prog.

Wenn p_input Schadcode enthält, wird dieser zur Laufzeit ausgeführt.

Dynamische Methodenaufrufe:

" GEFÄHRLICH: Unkontrollierte Methodenaufrufe
CALL METHOD (p_class)=>(p_method).

Ein Angreifer könnte kritische Systemmethoden aufrufen oder Daten manipulieren.

Sichere Alternativen

1. Whitelist-Ansatz:

" Nur erlaubte Werte zulassen
CASE p_method.
  WHEN 'GET_DATA' OR 'SAVE_DATA'.
    CALL METHOD (lv_class)=>(p_method).
  WHEN OTHERS.
    MESSAGE 'Unerlaubter Methodenaufruf' TYPE 'E'.
ENDCASE.

2. Factory-Pattern verwenden: Implementieren Sie Factory-Klassen, die nur sichere, vordefinierte Objekte zurückgeben.

3. Reflection-APIs sicher nutzen: Wenn RTTI (Run Time Type Information) verwendet wird, implementieren Sie strenge Validierung und Berechtigungsprüfungen.

Präventive Maßnahmen

Die effektivste Abwehr gegen diese Bedrohungen ist eine Kombination aus technischen Maßnahmen und organisatorischen Prozessen:

Code-Reviews mit Security-Fokus: Schulen Sie Ihr Team, diese Schwachstellen-Muster zu erkennen
Automatisierte Sicherheitstests: Nutzen Sie Tools wie den SAP Code Vulnerability Analyzer
Penetrationstests: Lassen Sie Ihre Systeme und Anwendungen regelmäßig von SAP spezialisierten Sicherheitsexperten testen
Incident Response Plan: Definieren Sie Prozesse für den Umgang mit entdeckten Schwachstellen
```
        {: .no_toc}
```

Sichere Entwicklung

In einer zunehmend digitalisierten Geschäftswelt ist die Absicherung von ABAP-Anwendungen unerlässlich. Sicherheit beginnt bereits bei der Entwicklung – durch konsequent angewendete sichere Programmierungspraktiken.

Input-Validierung: Der erste Schutzwall

Die Validierung von Benutzereingaben ist eine der effektivsten Verteidigungslinien gegen Angriffe. Ohne Validierung können manipulierte Eingaben zu Code-Injektionen oder unautorisierten Zugriffen führen. In ABAP sollten daher nur bekannte und erwartete Werte akzeptiert werden. Hier bieten sich Whitelists, Eingabemasken und Typprüfungen an. Besonders bei dynamischen SQL-Statements oder Dateioperationen ist eine vorherige Prüfung auf Plausibilität unabdingbar.

Whitelist-Ansatz bevorzugen:

" SICHER: Nur erlaubte Zeichen zulassen
IF p_kunnr CO '1234567890'.
  " Verarbeitung nur für numerische Kundennummern
ELSE.
  MESSAGE 'Kundennummer darf nur Ziffern enthalten' TYPE 'E'.
ENDIF.

Datentyp- und Längenprüfung:

" Explizite Längen- und Formatprüfung (Gerne mit REGEX arbeiten)
IF strlen( p_email ) > 50 OR p_email CN '@.'.
  MESSAGE 'Ungültige E-Mail-Adresse' TYPE 'E'.
ENDIF.

Webservice-Eingaben härten: Bei SOAP- und REST-Services müssen neben den obigen Input-Validierungen evtl. als String übergebene XML/JSON-Inhalte zusätzlich auf strukturelle Integrität geprüft werden, bevor sie in ABAP-Strukturen deserialisiert werden.

Output-Encoding: Daten sicher ausgeben

Bei Webtechnologien wie BSP, Web Dynpro oder UI5 kann unsicherer Output zu Cross Site Scripting (XSS) führen. Um dies zu verhindern, ist ein konsequentes Output-Encoding notwendig. Die SAP-eigene Methode cl_http_utility=>escape_html bietet hier eine einfache Möglichkeit, HTML-Ausgaben abzusichern. Alle potenziell gefährlichen Zeichen sollten bei der Ausgabe entschärft werden, insbesondere wenn User-Eingaben in HTML, JavaScript oder XML-Kontexten erscheinen.

HTML-Encoding für Webanwendungen

" HTML-Encoding für Web-Ausgabe
DATA: lv_encoded TYPE string.
lv_encoded = cl_http_utility=>escape_html( lv_user_input ).

Sichere Datenbankzugriffe: OpenSQL Best Practices

OpenSQL bietet eine abstrahierte und sichere Möglichkeit, auf Daten zuzugreifen. Dennoch entstehen Sicherheitsrisiken durch dynamische Statements, insbesondere wenn Tabellen- oder WHERE-Bedingungen aus Benutzereingaben generiert werden. Die Verwendung von CLIENT SPECIFIED oder direkter SQL-Manipulation (z. B. EXEC SQL) kann zu Mandantenüberschreitungen und Audit-Bypass führen. Best Practices umfassen hier:

Verwendung fester Tabellen- und Feldnamen
Keine dynamischen WHERE-Klauseln aus User-Input
Kein direkter Zugriff mit nativem SQL
Verzicht auf MODIFY ohne Prüfung von Berechtigungen
Keine Mandantenüberschreitungen benutzen

Dynamische WHERE-Klauseln absichern

" Sichere Implementierung dynamischer Abfragen
DATA: lt_where TYPE stringtab,
      lv_where TYPE string.

" Whitelist für erlaubte Felder
CASE p_field.
  WHEN 'KUNNR' OR 'NAME1' OR 'ORT01'.
    APPEND |{ p_field } = @p_value| TO lt_where.
  WHEN OTHERS.
    MESSAGE 'Unerlaubtes Feld in Abfrage' TYPE 'E'.
ENDCASE.

SELECT * FROM kna1 WHERE (lt_where) INTO TABLE @lt_result.

Berechtigungsprüfungen richtig implementieren

Ein häufiger Fehler besteht in fehlenden oder unvollständigen Authority-Checks. Jeder sicherheitsrelevante Zugriff muss durch AUTHORITY-CHECK abgesichert und der Rückgabewert sy-subrc sofort ausgewertet werden. Problematisch sind insbesondere:

Prüfungen mit DUMMY-Feldern (z. B. ACTVT = ' ')
Prüfungen auf Superuser-Berechtigungen (*)
fehlende Prüfung nach dem AUTHORITY-CHECK auf SY-SUBRC
Verwendung von Alias-Usern in SUBMIT ... USER-Anweisungen

Zudem ist sicherzustellen, dass kundeneigene Programme mit einer Berechtigungsgruppe versehen werden, um implizite Prüfungen auszulösen. Für eine gute UI und eine sichere Programmierung empfiehlt es sich die wichtigsten Berechtigungsobjekte direkt vor nach dem Start, vor der Usereingabe mit DUMMYzu prüfen um sowohl den Anwendungsserver als auch den Datenbankserver nicht mit Anfragen zu belasten, die im Nachinein sowieso nicht berechtigt sind. Beispielsweise zeigt ein Report Daten zu einem Debitor in einer Verkaufsorganisation an. Der Report ist mit einem Z Berechtigugnsobjekt versehen um zu prüfen ob der User diesen Kunden sehen darf. Hier kann beim ersten Aufruf (INITIALIZATION im Report) direkt das Berechtigungsobjekt gegen Dummyobjekte geprüft werden. Schlägt dies schon fehl braucht der User sich nicht die Mühe machen eine funktionierende Kombination zu finden.

" Vollständige Berechtigungsprüfung
AUTHORITY-CHECK OBJECT 'Z_KNA1_BEK'
  ID 'KUNNR' FIELD lv_kunnr
  ID 'ACTVT' FIELD '03'
  ID 'VKORG' FIELD lv_vkorg.

CASE sy-subrc.
  WHEN 0.
    " Berechtigung vorhanden
  WHEN 4.
    MESSAGE 'Keine Berechtigung für Kunde' TYPE 'E'.
  WHEN 12.
    MESSAGE 'Berechtigungsobjekt für den User nicht gepflegt' TYPE 'E'.
ENDCASE.

Berechtigungen in CDS Views

CDS Views bringen mit der Data Control Language (DCL) einen paradigmatischen Wandel in der SAP-Berechtigungslogik. Während traditionelle ABAP-Programme Autorisierungsprüfungen explizit im Code implementieren müssen, werden Berechtigungen in CDS Views deklarativ auf Datenebene definiert. DCL ermöglicht es, Berechtigungslogik direkt bei den Datenstrukturen zu definieren, anstatt sie in jeden konsumierenden Report oder jede Anwendung zu implementieren. Dies reduziert Redundanz sowie Arbeitsaufwand und erhöht die Konsistenz der Berechtigungsprüfungen erheblich.

Mit der konsequenten Anwendung von DCL, durchdachten Berechtigungskonzepten und regelmäßigen Sicherheitsüberprüfungen können Sie die Vorteile von CDS nutzen.

Die Investition in sichere CDS-Entwicklung zahlt sich langfristig aus. Sie ermöglicht es, moderne SAP-Anwendungen zu entwickeln, die sowohl performant als auch sicher sind.

Organisatorische Berechtigungen immer komplett prüfen

" Mehrstufige Berechtigungsprüfung
" 1. Funktionale Berechtigung
AUTHORITY-CHECK OBJECT 'Z_BKPF_BUK'
  ID 'BUKRS' FIELD lv_bukrs
  ID 'ACTVT' FIELD '02'.
IF sy-subrc <> 0.
    RAISE EXCEPTION TYPE zcx_no_authority.
 ENDIF.

" 2. Organisatorische Berechtigung  
AUTHORITY-CHECK OBJECT 'Z_BKPF_GSB'
  ID 'GSBER' FIELD lv_gsber
  ID 'ACTVT' FIELD '02'.
IF sy-subrc <> 0.
    RAISE EXCEPTION TYPE zcx_no_authority.
 ENDIF.

Sichere RFC- und Webservice-Kommunikation

Remote Function Calls (RFC) stellen ein zentrales Kommunikationselement dar, sind jedoch nur im Zielsystem autorisierungsgeprüft. Die Verwendung von Trusted-RFC-Verbindungen erhöht hier die Gefahr unkontrollierter Funktionsaufrufe. Daher müssen RFCs:

mit abgesichert werden,
gezielt per Rollenvergabe autorisiert werden,
im Fall externer Kommunikation mit Whitelisting abgesichert werden.

Für Webservices ist besonders auf die sichere Übergabe von Parametern und eine saubere Serialisierung/Deserialisierung zu achten.

RFC-Funktionsbausteine absichern

FUNCTION z_secure_customer_read.
  " Berechtigungsprüfung am Funktionseinstieg
  AUTHORITY-CHECK OBJECT 'Z_FUNC'
    ID 'ACTVT' FIELD '03'.
  
  IF sy-subrc <> 0.
    RAISE EXCEPTION TYPE zcx_no_authority.
  ENDIF.

Mandantensicherheit: Datentrennungen garantieren

SAP-Systeme basieren auf der strikten Trennung von Mandanten. Diese Trennung wird jedoch bei unsachgemäßer Verwendung von CLIENT SPECIFIED aufgehoben. Programme dürfen keine mandantenübergreifenden Zugriffe enthalten, es sei denn, dies ist zwingend erforderlich und autorisiert. Die Datenintegrität und Compliance-Vorgaben erfordern es, dass Mandantengrenzen eingehalten und regelmäßig auditiert werden.

Sichere Dateizugriffe und Pfadtraversal-Schutz

Dateizugriffe sind besonders kritisch, da sie direkt auf das Dateisystem des Servers zugreifen. ABAP bietet hierzu OPEN DATASET, READ, TRANSFER usw., die alle über das Objekt S_DATASET abgesichert sind. Schutzmaßnahmen beinhalten:

Nutzung von AUTHORITY_CHECK
Verwendung logischer Dateinamen
Vermeidung von Directory Traversal durch das Blockieren von „..“ oder /
Pflegen der Tabelle SPTH

Zusätzlich sollten Dateiuploads/-downloads nur über Dialogfunktionen der CL_GUI_FRONTEND_SERVICES erfolgen, um eine Sicherheitsprüfung auf der Client-Seite zu ermöglichen.

Pfadvalidierung implementieren

" Sichere Pfadvalidierung
DATA: lv_safe_path TYPE string,
      lv_filename TYPE string.

" Nur erlaubte Zeichen in Dateinamen
IF p_filename CA '\/:*?"<>|'.
  MESSAGE 'Ungültige Zeichen im Dateinamen' TYPE 'E'.
ENDIF.

" Pfadtraversal verhindern
IF p_filename CS '..'.
  MESSAGE 'Pfadtraversal-Versuch erkannt' TYPE 'E'.
ENDIF.

" Sicheren Basispfad verwenden
lv_safe_path = |/secure/upload/{ p_filename }|.

Generelles

Generell sollten aktuelle Techniken in anderen Sprachen immer darauf geprüft werden, ob und in welcher Weise sie in ABAP relevant sind. Bei manchen Techniken verlagert sich das Risiko, aber es bleibt gleich hoch.

          {: .no_toc}

Entwicklungsprozess

Secure Code Reviews: Systematische Sicherheitsprüfungen

Code Reviews sind in der ABAP-Entwicklung bereits etabliert – aber werden sie auch systematisch für Sicherheitsaspekte genutzt? Ein effektiver Secure Code Review geht über die reine Funktionalitätsprüfung hinaus und integriert Sicherheitsaspekte als festen Bestandteil des Qualitätssicherungsprozesses.

Struktur eines Security-fokussierten Code Reviews

Vor dem Review: Vorbereitung ist alles Der Reviewer sollte sich zunächst über den Kontext der Anwendung informieren: Welche sensiblen Daten werden verarbeitet? Über welche Schnittstellen ist das Programm erreichbar? Welche Berechtigungen sind erforderlich? Diese Informationen bestimmen das Risikoprofil und damit die Intensität der Sicherheitsprüfung.

Während des Reviews: Systematisches Vorgehen Ein strukturierter Ablauf verhindert, dass wichtige Sicherheitsaspekte übersehen werden. Beginnen Sie mit den kritischen Bereichen: Eingabeverarbeitung, Datenbankzugriffe, Ausgabegenerierung und Berechtigungsprüfungen. Arbeiten Sie sich systematisch durch den Code und dokumentieren Sie dabei nicht nur gefundene Probleme, sondern auch positive Sicherheitsmaßnahmen.

Nach dem Review: Nachverfolgung und Lernen Jeder Secure Code Review sollte dokumentiert werden. Welche Schwachstellen wurden gefunden? Welche Sicherheitsmaßnahmen wurden positiv bewertet? Diese Informationen helfen dabei, wiederkehrende Problemmuster zu identifizieren und das Team kontinuierlich zu verbessern.

Best Practices für ABAP Secure Code Reviews

Fokus auf kritische Code-Pfade: Nicht jede Zeile Code hat das gleiche Sicherheitsrisiko. Konzentrieren Sie sich auf Bereiche mit Benutzereingaben, Datenbankzugriffe, RFC-Schnittstellen und privilegierte Operationen.

Vier-Augen-Prinzip mit Security-Expertise: Idealerweise sollte mindestens ein Reviewer über fundierte Security-Kenntnisse verfügen. Wenn das nicht möglich ist, nutzen Sie Checklisten und Tools, um das fehlende Fachwissen zu kompensieren.

Dokumentation der Sicherheitslogik: Prüfen Sie, ob sicherheitskritische Entscheidungen im Code dokumentiert sind. Warum wurde eine bestimmte Validierung implementiert? Welche Angriffsvektoren soll sie abwehren?

Automatisierte Sicherheitstests in der ABAP-Entwicklung

Manuelle Code Reviews sind unverzichtbar, aber sie skalieren schlecht und sind fehleranfällig. Automatisierte Sicherheitstests können wiederkehrende Prüfungen übernehmen und das Entwicklungsteam bei der kontinuierlichen Qualitätssicherung unterstützen.

Static Application Security Testing für ABAP

Integration in die Entwicklungsumgebung: Moderne Static Application Security Testing-Tools können direkt in die SAP-Entwicklungsumgebung integriert werden. Sie analysieren den ABAP-Code bereits während der Entwicklung und weisen auf potenzielle Sicherheitslücken hin, bevor der Code ins Produktivsystem gelangt.

Automatisierte Pattern-Erkennung: Diese Tools erkennen bekannte Schwachstellen-Muster wie SQL-Injection-Potenziale, fehlende Input-Validierung oder unsichere Kryptografie-Verwendung. Sie können auch compliance-relevante Coding-Standards durchsetzen.

Kontinuierliche Überwachung: In der Entwicklungsumgebung können Static Application Security Testing-Tools bei jedem Transport automatisch ausgeführt werden. Kritische Sicherheitslücken können so den Transport blockieren und erzwingen eine Nachbesserung vor der Produktivsetzung.

Integration in den Entwicklungsprozess

Regelmäßige Scans: Führen Sie Scans in regelmäßigen Abständen durch – idealerweise automatisiert nach größeren Code-Änderungen oder vor wichtigen Releases.

Developer-Feedback: Stellen Sie sicher, dass Ergebnisse zeitnah an die verantwortlichen Entwickler kommuniziert werden. Je schneller Feedback erfolgt, desto effektiver ist das Lernen.

Security-Checklisten für ABAP-Entwickler

Checklisten sind ein bewährtes Mittel, um komplexe Prozesse systematisch und vollständig abzuarbeiten. Für die ABAP-Sicherheit sind sie besonders wertvoll, da sie auch weniger erfahrenen Entwicklern helfen, wichtige Sicherheitsaspekte nicht zu übersehen.

Entwicklungs-Checkliste: Vor der Implementierung

Sicherheitsanforderungen definieren: Welche sensiblen Daten werden verarbeitet? Welche Benutzergruppen sollen Zugriff haben? Welche regulatorischen Anforderungen sind zu beachten? Wurden relevante Berechtigungsobjekte genannt? Müssen eigene Berechtigungsobjekte erstellt werden?

Bedrohungsmodellierung: Welche Angriffsvektoren sind für diese spezifische Anwendung relevant? Wo sind die kritischen Sicherheitsgrenzen?

Implementierungs-Checkliste: Während der Entwicklung

Input-Validierung: Werden alle Benutzereingaben validiert und sanitized? Sind die Validierungsregeln angemessen strikt?

Berechtigungsprüfungen: Sind alle sicherheitskritischen Operationen durch explizite Berechtigungsprüfungen geschützt?

Sichere Datenbankzugriffe: Werden parametrisierte Queries verwendet? Ist Dynamic SQL vermieden oder sicher implementiert?

Output-Encoding: Werden alle Ausgaben kontextspezifisch encodiert?

Test-Checkliste: Vor der Produktivsetzung

Sicherheitstests durchgeführt: Wurden alle relevanten automatisierten Sicherheitstests ausgeführt?

Code Review abgeschlossen: Hat ein qualifizierter Reviewer den Code unter Sicherheitsaspekten geprüft?

Penetration Testing: Wurden kritische Anwendungen durch Penetration Tests validiert?

Dokumentation vollständig: Sind alle Sicherheitsmaßnahmen und -entscheidungen dokumentiert?

Wartungs-Checkliste: Nach der Produktivsetzung

Monitoring aktiv: Sind alle sicherheitsrelevanten Ereignisse in das Monitoring eingebunden?

Update-Prozesse: Sind Prozesse für Security-Updates und Patch-Management etabliert?

Regelmäßige Re-Assessments: Sind regelmäßige Sicherheitsüberprüfungen geplant?

Die Kombination aus systematischen Code Reviews, automatisierten Tools und strukturierten Checklisten schafft ein robustes Sicherheitsnetz für Ihre ABAP-Entwicklung. Kein einzelnes Tool oder Verfahren kann alle Sicherheitslücken verhindern – aber die intelligente Kombination verschiedener Ansätze minimiert das Risiko erheblich und schafft eine Kultur der kontinuierlichen Sicherheitsverbesserung.

          {: .no_toc}

Entwicklung

Wieso Sicherheit in ABAP Programmierung wichtig ist?

… Copy Paste… “Motzgrundlage”

Ein SAP-System oder eine ABAP-Laufzeit enthält verschiedene Funktionen für das Identitäts- und Zugriffsmanagement von Benutzern, die ABAP-Programme ausführen. Die Funktionen umfassen:

Werkzeuge zur Benutzerverwaltung, wie z.B. das Anlegen, Sperren und Löschen von Benutzern gemäß den gängigen Compliance-Standards.
Verschiedene Authentifizierungsprotokolle, einschließlich Single-Sign-On-Optionen
Durchsetzung von Passwortrichtlinien und Credential Management für Benutzer
Ein erweiterbares Rollen- und Berechtigungsmanagement mit der Möglichkeit, individuelle Rollen für Benutzer zu entwerfen und zuzuweisen.
Implizite Zugriffskontrolle auf Programmebene beim Start eines ABAP-Programms durch Überprüfung der Startberechtigungen der Benutzer
APIs zur Zugriffskontrolle innerhalb eines Programms und implizite Zugriffskontrolle auf Anweisungsebene für bestimmte APIs (z.B. Zugriff auf das Dateisystem).

SAP hat im Laufe der Zeit verschiedene Sicherheits-APIs und Sicherheitsfunktionen in den funktionalen Kern der Sprache und in die propagierten Frameworks implementiert, um es Programmierern zu ermöglichen, Sicherheitsanforderungen in ABAP-Programmen umzusetzen. Ein ABAP-Entwickler kann oft aus mehreren Anweisungen oder APIs auswählen, um bestimmte Funktionen zu implementieren. Implizite Sicherheitsfunktionen wie Eingabevalidierung und Verschlüsselung variieren ebenfalls je nach dem gewählten Framework. Die folgenden APIs und Sicherheitsframeworks stehen zur Wiederverwendung zur Verfügung:

OS-Befehlsbeschränkung
RFC-Callback-Whitelisting
Vereinheitlichtes Konnektivitäts-Framework (UCON)
HTTP-Pfad-Whitelist
Ausgabekodierung und
Dienstprogramme für die Eingabevalidierung
Virus-Scan-Schnittstelle
Zugangskontroll-API
Protokollierungs-APIs (eine Menge) und implizite Protokollierung

Sicheres Programmieren

Top 5 – die schlimmsten „Back Door“ Schwachstellen

… Copy Paste… “Motzgrundlage”

Directory Traversal (Write Access)

Directory-Traversal-Angriffe (Verzeichniswechselangriffe) funktionieren durch Manipulation des Dateinamens oder der Pfadinformationen durch Eingabe von Sonderzeichen in eine Zeichenkette, die als Datei-Locator dient.

Wird eine derartige Zeichenkette zur Abänderung von Inhalten einer Datei verwendet, lässt sich eine Anwendung austricksen und dazu bringen, Dateien zu ändern, auf die der Benutzer keinen Zugriff besitzen sollte. Dieser Angriff ist möglich, da es der Anwendung nicht gelingt, Befehlszeichen in Eingaben zu ermitteln und zu entfernen, die als Bestandteil des Datei-Locators verwendet werden.

Das wirkt sich auf Dateien in allen Verzeichnissen aus, für die die anfällige Anwendung Schreibzugriff besitzt. Darunter können auch Dateien im Unternehmens-LAN fallen. Risiko Durch Kontrolle, welche Dateien eine Anwendung ändern werden, sind mindestens folgende Angriffe möglich:

Schreibzugriff auf entscheidende Konfigurationsdateien. Dies kann Angreifern zuspielen, noch weiter in ein bereits angegriffenes System einzudringen.
Schreibzugriff auf Protokolldateien.
Schreibzugriff auf die Datenpersistenz einer produktiven Datenbank.

Alle diese Risiken gefährden die Integrität des produktiven SAP-Servers. Details Viele Anwendungen greifen auf Dateien auf dem SAP-Server zum Schreiben von Daten zu. Typische Anwendungsfälle umfassen die temporäre Persistenz von Datei-Uploads und den Export von Geschäftsdaten zur Übernahme von einem Altsystem. Auf Betriebssystemebene werden Dateien durch Datei-Locators identifiziert. Diese Datei Locators enthaltenen Angaben über die Laufwerk- oder Dateifreigabe, das Verzeichnis, den Namen und die Endung einer bestimmten Datei. Es gibt Fälle, bei denen ein Teil solcher Datei-Locator-Angaben auf externem Input basiert. Beispielsweise kann der Name einer auf den Server hochgeladenen Datei auch verwendet werden, um diese in einen temporären Ordner zu speichern. Eine externe Eingabe kann jedoch Sonderzeichen enthalten, die sich zur Manipulation des übergreifenden File Locators nutzen lassen. Als Folge hiervon werden Dateien von anderen Laufwerken, Dateifreigaben oder sonstige Verzeichnisse unter Umständen verändert. Auch auf Dateien anderer Dateitypen bzw. Erweiterungen lässt sich ggf. zugreifen. Ein solcher Angriff wird als Directory-Traversal-Angriff bezeichnet. Durch unzulässige Verzeichniswechsel kann ein unbefugter Benutzer beliebige Dateien auf dem SAP-Server ändern, auf dem die anfällige Anwendung ausgeführt wird. Je nach dem Dateizugriffsmodus kann ein Angreifer Daten entweder ändern oder löschen. Diese Schwachstelle führt zu einer unsachgemäßen Verwendung der ABAP-Befehle OPEN DATASET FOR OUTPUT, OPEN DATASET FOR APPENDING, DELETE DATASET, TRUNCATE DATASET und TRANSFER. Über solche Sicherheitslücken lässt sich die Integrität eines produktiven SAP-Servers beeinträchtigen. Ein Angreifer kann Dateien löschen oder ändern, die für den ordnungsgemäßen Systembetrieb von Entscheidung sind. Zusätzlich kann ein Angreifer Dateien ändern und löschen, die Geschäftsdaten enthalten. Auf jeden Fall stellt der unberechtigte Schreibzugriff für beliebige Dateien auf einem Server ein kritisches Sicherheitsrisiko dar. Die Wahrscheinlichkeit einer bestimmten Problematik ändert sich, sofern der Eingabe ein Postfix hinzugefügt wird.

Generic ABAP Module Calls

Durch die Kontrolle, welche ABAP-Module auf einem SAP-System ausgeführt werden, sind mindestens folgende Angriffe möglich: Absturz des SAP-Anwendungsservers Störung der Geschäftslogik, was zu einem inkonsistentem Datenstand führt Manipulation der Geschäftslogik, was einen unprivilegierten Zugriff auf geschützte Funktionen zur Folge hat Einige dieser Risiken können gegen gesetzliche Vorgaben verstoßen, da solche Schwachstellen den unprivilegierten Zugriff auf kritische Geschäftslogik ermöglichen. Details In ABAP gibt es Befehle, die Transaktionen, Funktionsbausteine, Methoden, Formulare und Berichte dynamisch aufrufen. Dynamisch bedeutet, dass der Name des auszuführenden Bausteins basierend auf den Eingaben zur Laufzeit bestimmt wird. Dynamische Baustein-Aufrufe sind eine wichtige Funktion, um flexiblen und wiederverwendbaren Code zu schreiben. Dies kann jedoch sehr gefährlich sein, wenn ein solcher Baustein durch einen böswilligen Benutzer kontrolliert wird. Findings berücksichtigen das Vorhandenseins eines AUTHORITY-CHECK. Zudem werden indirekte (in Untermodulen aufgerufene) AUTHORITY-CHECKs berücksichtigt. Die Wahrscheinlichkeit einer bestimmten Problematik ändert sich, wenn der Eingabe ein Präfix oder Postfix hinzugefügt wird.

OS Command Injection (CALL ‘SYSTEM’)

Dieser Testfall prüft, ob eine (externe) Eingabe als ein Betriebssystembefehl mittels Kernel Funktion ‘SYSTEM’ ausgeführt wird. In solch einem Fall könnte ein Angreifer beliebige Befehle auf dem SAP-Anwendungsserver ausführen. Risiko Das Ausführen von beliebigen Betriebssystembefehlen kann zu folgenden Risiken führen: Absturz des SAP-Anwendungsserver Installation von Malware Erstellung von privilegierten Benutzerkonten Lese- / Schreibzugriff auf alle Dateien des SAP-Anwendungsservers Details Die Kernel-Funktion ‘SYSTEM’ ermöglicht die Ausführung von beliebigen Betriebssystembefehlen. Werden hierdurch (externe) Eingaben verarbeitet, wird der standardmäßige SAP-Sicherheitsmechanismus für die Ausführung von Betriebssystembefehlen umgangen. Über die Transaktionen SM49 oder SM69 können Administratoren eine Liste der zulässigen Betriebssystembefehle pflegen und für deren Ausführung entsprechende Berechtigungen zuordnen. Auf diese Weise kann ein Administrator den Zugriff auf gefährliche Befehle einschränken. Die Kernel-Funktion ‘SYSTEM’ umgeht jedoch die Befehlsliste aus SM49 / SM69. Aus diesem Grund lässt sich mittels der Kernel-Funktion ‘SYSTEM’ jeder Betriebssystembefehl ausführen. Dies stellt ein kritisches Sicherheitsrisiko dar.

ABAP Command Injection (Report)

Die ABAP-Befehle INSERT REPORT und SUBMIT können zusammen dynamischen ABAP Code während der Laufzeit erzeugen und ausführen, was zu einem sehr hohen Sicherheitsrisiko werden kann, sofern Benutzereingaben Teil eines solchen dynamischen Berichts sind. Risiko Kann ein Benutzer beliebige ABAP-Befehle auf einem SAP-System ausführen, muss das System als vollständig kompromittiert betrachtet werden: Lese- und Schreibzugriff auf alle (geschäftlichen) Daten in der Datenbank Ausführung einer beliebigen Geschäftslogik Solche Sicherheitslücken stellen Compliance-Verstöße dar. Details Der ABAP-Befehl INSERT REPORT wird zur dynamischen Erzeugung eines ABAP-Reports verwendet. Dies erfolgt durch Verkettung von Zeichenketten, die üblicherweise aus einer Datenquelle gelesen werden. Sobald der ABAP-Report zusammengestellt wurde, kann er mit dem Befehl GENERATE REPORT ausgeführt werden. Eine solche Verfahrensweise der Programmierung ist sehr gefährlich, da hierdurch spontan bösartiger Code erstellt werden kann und keine Spuren dieses Codes im System hinterlassen werden.

Dangerous ABAP Commands

Bei diesem Testfall wird die Verwendung der ABAP-Befehle EDITOR-CALL FOR REPORT und COMMUNICATION geprüft. Beachten Sie, dass dieser Testfall Ausgangspunkte für die weitere Prüfung ermittelt und eine manuelle Nachbearbeitung erfordert. Risiko Das Geschäftsrisiko hängt von der erkannten Funktionalität ab und muss durch manuelle Analysen bestimmt werden. Details Dieser Testfall betrifft die folgenden ABAP-Befehle: EDITOR-CALL FOR REPORT COMMUNICATION Diese Befehle sind entweder kritisch oder obsolet. Sie sollten auf jeden Fall nicht im eigenentwickelten Code enthalten sein. EDITOR-CALL FOR REPORT ermöglicht den Aufruf eines ABAP-Editors für Quellcode. Besondere Entwicklungsberechtigungen sind dennoch erforderlich. Eigenentwickelter Code sollte keinen ABAP-Code-Editor zur Verfügung stellen. Dies sollte ausschließlich über SAP Standardfunktionen möglich sein, die ordnungsgemäß eingeschränkt und geprüft werden können. COMMUNICATION diente zum Austausch von Systemdaten und wurde verwendet, bevor RFC verfügbar war. Diese Art von Datenaustausch ist obsolet. Unter dem Aspekt der Sicherheit ergibt sich ein Risiko, da Sicherheitsfunktionen wie z. B. SNC nicht für den COMMUNICATION-basierten Datenaustausch verwendet werden können.

Einführung ABAP Cleaner

“ABAP Cleaner” im Bereich “Sicherheit”? Ja, man könnte meinen da passt was nicht so ganz. Der “ABAP Cleaner” hat sein Hauptanwendungsgebiet auf “Clean Code” / “Clean ABAP”, die Verwendung des”ABAP Cleaners” trägt auch zu Erhöhung der Sicherheit bei der ABAP Code Erstellung bei.

SAP hat Ende Mai 2023 den „ABAP Cleaner“ als generell verfügbar im GITHUB veröffentlicht. wird als Eclipse-AddOn (Erweiterung) zusätzlich zu den SAP ADT (ABAP Development Tools) installiert und bettet sich in diese ein. Die Grundfunktionalität liegt auf Clean Code (siehe auch Clean ABAP Styleguides der SAP), in der aktuellen Version (1.16.1 – Mitte Mai 2023 sind über 75 Checks/CleanUp’s enthalten. Diese können auch auf eigene Bedürfnisse konfiguriert werden. Ebenso ruft SAP aktiv dazu auf, bei Erweiterungswünschen diese via GITHUB an die SAP zu melden. Als „Nebeneffekt“ sind einige Prüfungen im Rahmen von Clean Code/Clean ABAP auch eine Stärkung der Sicherheit innerhalb des ABAP-Codes (z.B. Bereinigung obsoleter Sprachelemente, …). Deshalb sollte der ABAP Cleaner grundsätzlich für die ABAP Codeerstellung verwendet werden.
Desweiteren soll hier auch auf den ADT Guide der DSAG verweisen werden, dieser enthält weitere nützliche Informationen zu den ABAP Development Tools (ADT) der SAP.

Installation und Funktion

Die Programmsourcen liegen auf dem GITHUB Projekt von SAP. Die Installation ist auf der Seite detailliert beschrieben. Voraussetzung für den ABAP Cleaner ist die Installation der SAP ADT (ABAP Development Tools) und des SAPGUI (nur Windows) oder des JAVAGUI.

Der „ABAP Cleaner“ bettet sich vollständig in die ADT in Eclipse ein. Die Korrekturen am erstellten ABAP Code werden über die ADT Funktion „Quick Fix“ umgesetzt.

SAP liefert für die Konfiguration liefert 2 Profile aust: „DEFAULT“ und „ESSENTIAL“, diese können angepasst/erweitert werden (durch kopieren in jeweils eigene Profile). Grundsätzlich liegen diese beiden Profile lokal auf dem Arbeitsplatzrechner, empfohlen wird für beide Profile eine Grundkonfiguration zu machen und dann per Export/Import Funktion entsprechend zu verteilen und damit eine gemeinsame Nutzung zu vereinfachen.

Profile und Regeln

Funktionsweise

Grundsätzlich kann der ABAP Cleaner im Modus „interaktiv“ und „automatisch“ benutzt werden:

Die automatische Bereinigung wird mit (Ctrl + 4 oder über das Menü ‘Source Code / Clean Up With Automated ABAP Cleaner’ ) angestartet.
Die interaktive Bereinigung mit “Ctrl + Shift + 4 oder über das Menü ‘Source Code / Clean Up With Interactive ABAP Cleaner…’.

Interaktiver Modus

Bei der automatischen Bereinigung wird der Code vollautomatisch geprüft und bereinigt.

Bei der interaktiven Bereinigung werden die Codingstrecken im Splitt-Screen angezeigt:

Geteiles Bild

Hier bekommt man dann die einzelnen „Befunde“ angezeigt und kann diese interaktiv bearbeiten/anpassen lassen.

Regelwerk

Auf der GITHUB Seite sind alle verfügbaren Checks/Clean-Ups im Detail beschrieben. Details siehe „ABAP Cleaner Rules“:

Verfügbare Regeln

Hintergrundinformationen/Linksammlung

SAP liefert einige Richtlinien und Regeln für „sauberen“ ABAP Code aus:

den Clean ABAP Styleguide,
die Clean Code Checks, wie im Projekt ‚Code Pal for ABAP‘ implementiert,(Erweiterung der Checks für den ATC – ABAP Test Cockpit) – siehe auch im Kapitel “ATC”

Grundlage von Clean ABAP oder den Clean ABAP Styleguides ist das Konzept „Clean Code“ von Robert C. Martin, welches auf die Programmiersprache ABAP angewandt wurde.

Buch Clean Code

Der ABAP Cleaner wurde zwar erst im Mai 2023 als „general available“ zur Verfügung gestellt, er hat aber einen “internen” SAP Entwicklungsweg hinter sich:

Projekt Meilensteine

SAP entwickelt den ABAP Cleaner permanent weiter.

Frage von Peter L.

Ist ABAP Cleaner wirklich Sicherheit ?

Verweis auf ADT Leitfaden Plugins – hier ist aBAP Cleaner beschrieben bzw, installation etc, von plugns generell.

          {: .no_toc}

ABAP Test Cockpit

Überblick

Das ABAP Test Cockpit (ATC) ist ein Werkzeug zur Ausführung statischer und dynamischer Qualitätsprüfungen für ABAP-Quellcode und dazugehörige Repository-Objekte.

Die SAP-Empfehlung ist ein zentrales ATC-System, dieses System soll recht „schmal“ gehalten sein, sprich nur ein ABAP Netweaver System mit entsprechender Datenbank und der Softwarekomponente SAP_BASIS. SAP spricht von „Sie müssen lediglich ein zentrales ATC-Prüfsystem installieren und konfigurieren: das reine SAP-Basissystem (SAP_BASIS >=7.51) innerhalb Ihrer SAP-Systemlandschaft“. Daraus folgt, man braucht eigentlich nur ein AS ABAP System mit der Softwarekomponente SAP_BASIS

Aber: Das zentrale ATC System sollte in der gesamten Systemlandschaft das softwaretechnisch neueste System sein, das hat den Vorteil, dass die neuesten Checks dort vorhanden sind und die Remote-Prüfungen einfacher durchlaufen .

SAP liefert alle Checks über die SAP_BASIS Komponente aus, deshalb wird empfohlen, jeweils den aktuellsten Stand einzusetzen, damit man auch mit den aktuellsten Checks arbeitet/prüft. Ein weiterer Vorteil mit dem „schmalen“ System ist, dass das ATC-System bei Bedarf recht „einfach“ aktualisiert (Supportpackage-Update) werden kann. Grundsätzlich sollte man 1–2mal im Jahr das ATC-System aktualisieren (die „Anwendung“ und die Datenbank).

Die Checks/die Prüfungen sind einmal in den „Code Inspector“ integriert, dies ist eine Funktion innerhalb der SAP-Entwicklungsumgebung und der SAP ADT (ABAP Development Tools – Eclipse Erweiterung). Dabei werden die Checks über die Funktion „Prüfen => ABAP Test Cockpit“ angestoßen. Ebenso besteht die Möglichkeit alle RFC fähigen Checks (überwiegend sind alle Checks RFC fähig) auch als periodischer Job im Hintergrund laufen zu lassen und den kompletten Code zu prüfen und ein „Verzeichnis“ der Befunde zu erstellen.

Abgerundet werden die Prüfungen mit der Integration in das SAP CTS „Korrektur- und Transportsystem“ für Systemänderungen/Entwicklungen. Hier kann man das System so einstellen, dass bei jeder Transportfreigabe gegen die Checks des ATC geprüft wird. Werden Befunde festgestellt, so kann eingestellt werden, dass diese die Transportfreigabe verhindern. Damit wird sichergestellt, dass nur einwandfreier Code in die SAP-Systeme transportiert wird. Diese Funktion kann zusätzlich mit einem „Befreiungsworkflow“ erweitert werden.

Zentrales ATC

Schema Central ATC

Auf der linken Seite ist das zentrale ATC System zu sehen. Dieses besteht im Standard aus den Komponenten ATC (ABAP Test Cockpit) und dem ACI (ABAP Code Inspektor). Mit einer gesonderten Lizenz kann das CVA (SAP Custom Code Vulnerability Analyser) aktiviert und genutzt werden. Das CVA prüft den eigen erstellte Code gegen SAP Empfehlungen für “Sicheres Programmieren”. Details zum CVA und den Prüfungen werden später noch etwas näher erläutert..

Hinweis: Das ATC System kann mit der open Source Komponente abapGIT (nicht zu verwechseln mit gCTS der SAP) erweitert werden (siehe hierzu die Empfehlungen im Kapital “Open Source”). Im folgenden werden einzelnen Komponenten erläutert

abapGIT

abapGIT ist ein Open-Source-GIT-Client für ABAP. Dieser ist in ABAP entwickelt und benötigt mindestens eine SAP BASIS Version 702 oder höher.

abapGit ist ein Werkzeug zum Importieren und Exportieren von Code zwischen ABAP-Systemen. Wenn ein Entwickler über einen Entwicklerschlüssel für das System verfügt, kann er diese Aktionen bereits ausführen. abapGit ermöglicht es dem Entwickler, Massenexporte/Änderungen/Importe durchzuführen, aber nicht mehr, als bereits manuell möglich ist.

Mit abapGIT ist es möglich, über ein eigenes GIT ABAP Objekte über Systemgrenzen hinweg recht einfach zu deployen. Gerade in einer Double-Maintenance-Phase war diese Möglichkeit in der Vergangenheit eine große Hilfe und Arbeitserleichterung für die ABAP Entwickler. Außerdem wird abapGIT als Basis für die abapOpenChecks benötigt. Deshalb sollte diese Funktion wieder implementiert werden.

abapGIT wird „einfach“ als einzelner ABAP Report über das GIT-Repository zur Verfügung gestellt. Dieser ABAP Report wird dann in das ATC System und auch in die angeschlossenen Entwicklungssysteme implementiert.

Die Installation wird hier beschrieben: Installation - abapGit Docs außerdem gibt es in der SAP Basis eine detaillierte Installationsanleitung inkl. Dokumentation wie ein Update/neue Version installiert wird.

abapGit GUI Client

Prüfungen - ABAP Checks

SAP liefert mit dem ATC bereits eine große Anzahl von Prüfungen aus, welche direkt vom Code Inspector und vom ATC verwendet werden.

Folgende Teilbereiche liefert SAP aus:

SCI Prüfvariante

Die ABAP-Checks sollten zwischen ABAP Entwicklung und dem Sicherheitsteam abgestimmt werden (welche Prüfungen sind sinnvoll), dann sollten die als „sinnvoll“ erachteten für Hintergrundprüfungen und auch für die Onlineprüfung im Rahmen der Transportfreigaben aktiviert werden

S/4 Readiness-Checks

Spezielle Checks welche SAP ausliefert sind die sog. „S/4HANA -Readiness“-Checks. Dies sind Prüfungen mit denen der kundeneigene Code auf S/4HANA Tauglichkeit“ überprüft werden können.

Im Detail werden folgende Prüfungen ausgeliefert:

S/4HANA Readiness Prüfvariante

Typischerweise wird im Rahmen eines Custom Code Livecycle Projektes der komplette kundeneigene Code im Hintergrund auf S/4HANA Tauglichkeit geprüft und die Befunde dann mit entsprechenden Tools, häufig auch automatisiert, auf S/4HANA umgestellt bzw. konvertiert werden.

Beispiel:

S/4HANA Readiness Ergebnis

Die S/4HANA Bereitschaftsprüfungen sollten für Hintergrundprüfungen und auch für die Onlineprüfung im Rahmen der Transportfreigaben aktiviert werden, solange man noch auf ECC entsprechenden Code entwickeln. Mit einer Systemkonvertierung auf S/4HANA kann man die Checks dann ausschalten.

abapOpenChecks

abapOpenChecks sind Checks der SAP Community für den ATC und den Code Inspector. Die Installation erfolgt über abapGIT (siehe vorherige Kapitel).

In der aktuellen Version liefert abapOpenChecks über 100 zusätzliche Checks für den ATC aus und erweitert die von SAP ausgelieferten Prüfungen.

abapOpenChecks Prüfungen (Teil-1)

…

abapOpenChecks Prüfungen (Teil-2)

Eine aktuelle Liste der Prüfungen ist hier einzusehen: abapOpenChecks - Checks

Die abapOpenChecks sollten für Hintergrundprüfungen und auch für die Onlineprüfung im Rahmen der Transportfreigaben aktiviert werden.

Code Pal for ABAP

Code PAL. Dieses Tool bietet eine Reihe von Prüfungen, die bei der Einhaltung des Clean ABAP-Styleguides helfen. Obwohl nicht alle Empfehlungen aus dem Leitfaden durch statische Codeanalyse überprüft werden können und in bestimmten Situationen die strikte Einhaltung des Leitfadens möglicherweise nicht empfohlen wird, bietet dies zumindest für eine Teilmenge von Empfehlungen eine robuste automatisierte Unterstützung.

CodePal

Wichtig: aktuell (im Juni 2023) sind die Code PAL Checks noch nicht RFC-fähig und können aktuell nur auf dem lokalen Entwicklungssystem geprüft werden, allerdings plant SAP im August 2023 die Checks remotefähig auszuliefern. Die Checks sind auch in den ATC und den Code Inspector integriert/integrierbar.

SAP liefert die Code PAL Checks über GITHUB aus, die Installation erfolgt ebenfalls über abapGIT. Die Installation ist hier beschrieben: code-pal-for-abap/how-to-install.md at master · SAP/code-pal-for-abap · GitHub

Im Mai 2023 gibt es folgende Checks (56 Checks):

CodePal Prüfungen (Teil-1)

…

CodePal Prüfungen (Teil-2)

Die aktuelle Liste ist hier zu finden: SAP/code-pal-for-abap

Die Code PAL Checks sollten mit den Entwicklern abgestimmt werden (welche Prüfungen sind sinnvoll), dann sollten die als „sinnvoll“ erachteten für Hintergrundprüfungen und auch für die Onlineprüfung im Rahmen der Transportfreigaben aktiviert werden. Eventuell ist es sinnvoll die Installation erst im August/September 2023 zu machen, wenn die Checks remotefähig sind.

Eine sinnvolle Ergänzung zu den Code PAL Checks ist der ABAP Cleaner, eine Erweiterung zu Eclipse. Hier kann bereits bei der Codeerstellung (bei der Codeeingabe) auf Clean ABAP Konzepteinhaltung geprüft werden.

Code Pal for ABAP Cloud

Seit Mitte September 2023 gibt es eine Version von “code pal” für ABAP in Cloud (BTP) Umgebungen. Grundsätzlich scheint (nach der Dokumentation) “code pal for cloud checks” genauso zu funktionieren wie der “normale” “code pal”. SAP liefert über das GITHUB neue Checks aus, welche mit “abapgit” importiert werden können. Die Checks sind in einem eigenen Namensbereich /CC4A/CODE_PAL hintergelegt. Details sind von SAP in folgendem Blog beschrieben: “Clean code checks for ABAP – Cloud Edition”. Ebenso sind die Checks in der Entwicklungsplattform Eclipse verfügbar, so dass bereits beim Entwicklungsprozess auf Clean Code geprüft werden kann, wenn man mit ABAP Cloud entwickelt.

Prüfungen - Sicherheit

Standard-Sicherheitsprüfungen

SAP liefert im Rahmen der Standardauslieferung der Check folgende Sicherheitsprüfungen aus:

CVA Prüfungen

Die SAP Standard Sicherheitsprüfungen sollten für Hintergrundprüfungen und auch für die Onlineprüfung im Rahmen der Transportfreigaben aktiviert werden. Eventuell kann man auch mit den Entwicklern abgestimmt kritische Anweisungen definieren, auf die man noch prüfen kann/sollte

CVA - Code Vulnerability Analyzer

Der CVA ist ein Produkt der SAP welches man zusätzlich lizenzieren muss. Im Rahmen der Rahmenvertragsverlängerung (Juli 2022) wurde dieses Produkt zu einem sehr günstigen Preis gekauft. Das Produkt erweitert die SAP-Sicherheitsprüfungen erheblich, die Prüfungen des CVA sind die gleichen Prüfungen mit denen SAP ihren eigenen Code (der Code welche mit den SAP ABAP Systemen ausgeliefert wird) prüft. Mittlerweile kann das CVA auch kostenlos zusammen mit einem SAP BTP ABAP Environment provisioniert werden, Voraussetzung ist dabei der Einsatz des ABAP Environments als zentrales Prüfsystem.

Auch diese Prüfungen werden bei jedem Netweaver ABAP – Update erweitert.

Der CVA führt eine statische Analyse des ABAP-Sourcecodes durch und meldet mögliche Sicherheitsrisiken

Auszug aus SAP Hinweis 1921820 - SAP Code vulnerability Analyzer - Support Package Planning zum Prüfumfang des CVA:

Die Checks:

CVA Prüfungen (Teil-1)

…

CVA Prüfungen (Teil-2)

Aus Sicherheitsgründen hat SAP die CVA Check in 2 Prüfvarianten hinterlegt, so dass man „nur“ CVA komplett prüfen kann, d.h einzelne Prüfungen können nicht ausschalten werden.

Komplette Prüfungen

BSP sind Checks für Business Server Pages, diese sind aus technischen Gründen separat.

Die Prüfungen des CVA sollten für Hintergrundprüfungen und auch für die Onlineprüfung im Rahmen der Transportfreigaben aktiviert werden.

          {: .no_toc}

SAP Screen Personas 3.0

Allgemein

Was ist “SAP Screen Personas 3.0”?

Aus der SAP Onlinehilfe:

SAP Screen Personas 3.0 unterstützt die Transformation klassischer Anwendungen in benutzerorientierte UIs, die auf bestimmte Anwendungsrollen und Geschäftsanforderungen zugeschnitten sind. Die vereinfachten Versionen klassischer Anwendungen werden als Flavors bezeichnet. Diese angepassten UIs können für ein oder mehrere Bilder innerhalb einer klassischen Anwendung oder anwendungsübergreifend verwendet werden. Die Flavors sind von den zugrunde liegenden Transaktionen unabhängig und können auf bestimmte Anwendungsrollen ausgerichtet sein. Eine klassische Anwendung kann über mehrere Flavors verfügen. Beispielsweise kann es ein bestimmtes Flavor pro Benutzergruppe geben.

Technisch basiert SAP Screen Personas 3.0 (Personas) auf einem SICF-Service, der einen vorkonfigurierten Service des SAP GUI for HTML unter dem Standardknoten /sap/bc/personas startet. Die Engine hat eigene Services unter dem Standardknoten host/sap/bc/se. Das bedeutet die Sicherheitsmaßnahmen für das SAP GUI for HTML und ITS gelten für Screen Personas und seine Services grundsätzlich auch.

SICF Service

Bei SAP Screen Personas handelt es sich um eine Benutzungsoberflächen-Technologie, die als Add-On im Backend-System implementiert wird, Die Sicherheit ist deshalb abhängig von den für dieses System verfügbaren Funktionen. zu Datenzugriff-Governance oder Datenschutz. Die meisten dieser Systemfunktionen werden durch die zugrunde liegenden Systemmechanismen und -richtlinien vorgegeben. Alle für SAP Screen Personas spezifischen Aspekte oder möglichen Diskrepanzen und Bereiche von besonderem Interesse werden nachfolgend erläutert.

Spezielle Sicherheitsaspekte

SSL Verschlüsselung der Verbindung

Die Services welche von Personas verwendet werden sind SSL zu verschlüsseln:

Verschlüsselung

Schutz vor Cross Site Request Forgery für ITS

Zum Schutz von Cross Site Requests ist an den Services unter GUI Konfiguration der Parameter ~XSRFCHECK = 1 zu setzen. Details sind im Hinweis 1481392 beschrieben.

Parametereinstellung

Allgemeine Empfehlungen für ITS und SAP GUI for HTML

Abmeldung für SAP GUI for HTML aktivieren

Damit die Abmeldung aus dem HTML GUI sicher funktioniert müssen folgende Dinge beachtet werden:

Logoff Service muss in ICF aktiviert werden → Service-Baum /sap/public/bc/icf/logoff aktivieren
Im HTML GUI Service sowie in den Personas Services muss als Abmeldeseite der Logoff Service hinterlegt werden

Abmeldung Web-GUI

Bei der Abmeldeseite des WEBGUI Services den Service /sap/public/bc/icf/logoff als Redirect angeben.

Details sind im SAP Hinweis 1777513 beschrieben (ebenso weitere Hintergrundinformationen)

Domain Relaxing deaktivieren (falls notwendig)

Das Domain Relaxing ermöglicht es client-seitigen (zum Beispiel auf einem Browser) Funktionen oder Anwendungen, mit anderen client-seitigen Funktionen in anderen Client Fenstern zu kommunizieren. Das Domain Relaxing ist nötig, falls Anwendungen von verschiedenen Backend-Systemen (Servern) am Frontend Daten austauschen müssen. Es muss dafür gesorgt werden, dass für alle betroffenen Anwendungen die gleiche Client Domain eingestellt ist, da andernfalls vom Client (Browser) ein Zugriffsfehler beim Versuch der Kommunikation beanstandet wird.

Falls es zu einem solchen Browser-Verhalten kommen sollte, muss das Domain Relaxing deaktiviert werden. Dazu wird in der GUI-Konfiguration des Services der Parameter ~no_domain_relaxing hinzugefügt und auf 1 (Eins) gesetzt.

Domain Relaxing

Details sind im SAP Hinweis 2111099 beschrieben (ebenso weitere Hintergrundinformationen)

=> Einfügen Abschnitt

SAP Berechtigungen

SAP Screen Personas 3.0 ist nur dann für einen Benutzer aktiviert, wenn er über die erforderlichen Berechtigungen basierend auf Benutzerrolle verfügt. Die Rollenzuordnung erfolgt im Rahmen des regulären Benutzerverwaltungsprozesses. SAP liefert folgende Standardrollen aus:

Administrator: /PERSONAS/ADMIN_ROLE - Diese Rolle hat vollständigen Zugriff auf alle Funktionen, die SAP Screen Personas dem Flavor-Consumer zur Laufzeit zur Verfügung stehen, kann den Zugriff auf alle Funktionen der Flavor-Builder-Aufgaben zur Design-Zeit ermöglichen und Administrationsaufgaben in der Administrationsumgebung ausführen.
Flavor-Konsument: /PERSONAS/CONSUMER_ROLE - Diese Rolle hat Berechtigungen für den Zugriff auf Flavors für klassische Anwendungen. Flavor Konsumenten können mit dem Flavor-Manager zwischen Flavors und dem ursprünglichen Bild wählen und Flavors zwischen dem Flavor-Manager und der Flavor Galerie verschieben.
Flavor-Builder: /PERSONAS/EDITOR_ROLE - Diese Rolle wird verwendet, um Flavors und andere benutzereigene Objekte mit Bearbeitungsrechten in allen Design Zeit-Editoren zu erstellen.

SAP liefert die Rollen ohne generiertes Berechtigungsprofil aus, deshalb muss das Profil jeweils generiert und sehr wahrscheinlich auch angepasst werden.

Grundsätzlich gilt: Die Benutzer müssen immer Zugriff auf den Transaktionscode haben, zusätzlich zu dem, was ihnen in SAP Screen Personas gehört um eine Funktion innerhalb von Personas ausführen zu können. Also TCD (Applikationsberechtigung) plus Personas Berechtigungen müssen vorhanden sein.

Die folgenden Tabellen erläutern, wie Personas die verschiedenen Berechtigungsobjekte zum Erstellen von Flavors verwendet und mit den standardmäßig ausgelieferten Rollen verteilt:

Screen Personas Berechtigungen (Teil 1)

Screen Personas Berechtigungen (Teil 2)

Screen Personas Berechtigungen (Teil 3)

    <h1 class="no_toc" id="künstliche-intelligenz">Künstliche Intelligenz</h1>

KI in der Entwicklung
1. Hilfestellungen für die Entscheidungsfindung
Generative KI in der Entwicklung
AI als Werkzeug bei Dokumentationserstellung
Weitere Hinweise

KI in der Entwicklung

Aktuell ist das Thema AI ein Hypethema. Produkte/Lösungen wie ChatGPT, Microsoft Copilot, Google GEMINI und SAP Joule werden überall diskutiert und finden in Lösungen ihre praktische Anwendung. Auch in der Softwareentwicklung werden diese Lösungen eingesetzt, sogar in der ABAP Entwicklung gibt es entsprechende AI Unterstützung, diese steckt zwar noch in den „Kinderschuhen“, aber es gibt diese schon, die Lösungen werden allerdings stetig weiterentwickelt, so dass diese bald aus den “Kinderschuhen” entwachsen werden.

Was hier in der Zukunft noch kommen wird ist sehr spannend und aktuell nicht vorhersehbar. In diesem Kapitel wollen wir allgemeine Hilfestellungen für eine Entscheidungsfindung für die Nutzung/Anwendung von AI Lösungen in der Softwareentwicklung geben. Wir wollen bewusst nicht die eine oder andere Softwarelösung vorstellen oder bewerten.

Generell lässt sich heute sagen, das KI in der Software-Entwicklung hilft, schneller und besser (sicherer) zu entwickeln (Code zu entwickeln). Die AI entwickelt sich hier rasant weiter, aber sie wird aktuell den menschlichen Entwickler noch nicht ersetzen können, sie kann aber diesen schon sehr gut unterstützen.

Hilfestellungen für die Entscheidungsfindung

Folgende Fragestellungen können zu einer Entscheidungsfindung beitragen:

Welche Sicherheitsanforderungen werden an die AI gestellt?
- Private Space vs. Public Space
  - Private Space: AI Modelle und -Daten werden geschützt und sind vor unbefugtem Zugriff abgesichert
  - Public Space: AI-Systeme und -Daten sind für die breite Öffentlichkeit zugänglich wo ist hier die Datenhaltung - in der EU?
Welche Modelle werden verwendet?
- LLM Large Language Model
- ML Machine Learning
- Deep Learning
- Neuronale Netze
- Andere, wenn ja welche?
Werden Third-Party AI Produkte verwendet, ja ja welche?
Welche Datenbasis wurde/wird für das Trainieren verwendet?
Werden eigene Unternehmensdaten für das Trainieren der Modelle verwendet?
- Wie ist sichergestellt, dass die Daten „beim Unternehmen verbleiben“ und nicht weiterverwendet werden?
Erfüllt die Lösung geltenden Regelungen/gesetzliche Vorgaben (z.B. EU AI Act, DSGVO/GDPR, …)
Wie ist die AI Lösung gemäß den EU Kritikalitätsstufen (minimales/kein Risiko, Begrenzt, Hoch, Inakzeptabel) eingruppiert
Wird sichergestellt dass die Lösung keine urheberrechtlich geschützen Daten oder Inhalte verwendet? Wie wird dies sichergestellt?
Kann die Speicherung von Prompts deaktiviert werden? Wo werden die Prompts gespeichert?
Hat das Unternehmen welches die Lösung entwickelt hat/vertreibt ein „AI-Ethik-Fundament“, Beispielhaft sei hier die SAP genannt „KI Ethik Handbuch“
Was ist der Inhalt? Wie passt dieser auf die eigene Unternehmenskultur oder gar mit dem eigenen AI Ethik Fundament?

Neben den oben genannten Fragestellungen birgt der Einsatz von AI auch Themen-/Problemfelder wie man mit ethischen Bedenken der aus den Trainingsdaten übernommene „Voreingenommenheit“ von KI Modellen (Schlagwort ist hier AI BIAS) umgeht bzw. wie man diese begegnet/entgegnet?

Oder auch Fragestellungen der Ergebnisüberprüfung durch „Sachkundige“ um algorithmische Verzerrungen („Halluzinationen“) zu erkennen. Hierzu sei auf das Ergebnis einer Studie der Purdue University, West Lafayette, USA im Rahmen der Konferenz CHI 2024 verwiesen, die zu dem Ergebnis kommt, dass 39% der Fehler im Ergebnis einer KI unerkannt geblieben sind, da die Fragen „höflich“ beantwortet wurden. Deshalb die Empfehlung die Ergebnisse sachlich und besonnen zu prüfen und zu validieren.

Generative KI in der Entwicklung

Genereller Disclamer zu diesem Teilbereich: Aktuell (Juli 2024) sind die Tools der SAP im Bereich der AI Unterstützung in der ABAP Entwicklung noch nicht verfügbar, diese befinden sich in der Entwicklung. Deshalb kann hier nur über den aktuellen Entwicklungsstand und die darüber verfügbaren Informationen eine Einschätzung gegeben werden. Dies bitte immer berücksichtigen.

Aktueller Stand des Ansatzes der AI Unterstützung im SAP Umfeld:

SAP Business AI approach

Quelle SAP – DSAG Online Session 11.07.2024 – Einsatzszenarion von gen. AI in der modernen ABAP Entwicklung

Zentrale Komponente ist“SAP Joule“, für die Integration der einzeln Modelle dient die „AI Foundation“ auf der BTP. Dies ist auch die Basis für die technische Verfügungstellung der AI Unterstützung für ABAP.

Geplant sind aktuell drei Bereiche der Unterstützung im ABAP Entwicklungsumfeld:

Accelerate
- Hier plant SAP aktuell 4 Anwendungsfälle
  - Generierung von RAP Business Objekten (BO‘s) und Services
  - Generierung von Unit-Tests für ABAP Klassen, CDS-Views und RAP BO‘s
  - Erläuterung/“Erklärung“ von bereits existierendem (legacy) code
  - Hilfe bei Code Snippets, Codeanalysen, Dokumentation, vorhanden Hilfsinhalte und Code Prognosen (prediction)
Transform
- Unterstützung bei der Migration von kundeneigenem Code in ABAP Cloud. Eingebunden in die „ADT for Eclipse“ soll hier eine Migrationsunterstüzung erfolgen, ebenso soll eine Implementierung der AI im „ABAP Test Cockpit Cloud“ erfolgen.
Empower
- Geplant ist hier, die Integration von AI Szenarien mit einem AI-SDK in kundeneigene Entwicklungen zu unterstützen

Ausblick auf die SAP Entwicklung und die geplante Roadmap (Stand Juli 2024)

Roadmap

Aktuelle Roadmap

Einflussmöglichkeiten

AI als Werkzeug bei Dokumentationserstellung

Bis sich AI im Alltag des ABAP Entwicklers dauerhaft und voll integriert wiederfindet, wird sicher noch einige Zeit vergehen. Allerdings kann AI bereits jetzt unterstützend ohne technische Integration sinnvoll im Entwickleralltag eingesetzt werden.

Ein Anwendungsszenario ist die unterstützende Erstellung der Dokumentation einer Eigenentwicklung. So können die aktuell verfügbaren Chat Bots vom Entwickler oder dem für die Entwicklung zuständigen Mitarbeiter verwendet werden um die technische Dokumentation der Anwendung zu erstellen. Dazu muss der generativen AI die Aufgabe (also das gewünschte Ergebnis: Erstelle eine technische Dokumentation), der Kontext und Zweck der Anwendung mitgeteilt werden. Für die technischen Details kann dann der Code der wichtigsten Klassen, die die Geschäftslogik enthält und ergänzende Informationen mitgegeben werden. Sind bereits erläuternde Informationen als Kommentar oder im besten Fall als ABAP Doc in der Entwicklung enthalten, kann dies von der genAI für die Dokumentation herangezogen werden.

Als erstes Ergebnis erhält man hier eine Beschreibung was die AI aus dem Code und den Informationen auswerten konnte. Hier wird schnell offensichtlich inwiefern der Code die gewünschte Logik erklärbar umsetzt und wo iterationen und manuelle Korrekturen und Ergänzungen notwendig sind.

Um eine ansprechende Dokumentation zu bekommen ist gutes Prompt Engineering erforderlich. Doch mit jeder Iteration kann man hier Erfahrung sammeln um bessere Ergebnisse zu erzielen.

Auch wenn die genAI hier nicht in wenigen Minuten die vollständige und direkt verwendbare Dokumentation erstellt, hilft dieser Prozess bei der Erstellung einer Entwurfsversion und erspart Tipparbeit. Beim Durchsehen wird schnell ersichtlich wo manuelle Nacharbeit erforderlich ist, Man bekommt sozusagen einen Diskussionspartner und erzielt am Ende ein besseres Ergebnis, da durch die Iteration mit der genAI logische Inkonsistenzen oder Unklarheiten beim Lesen erkannt werden.

Ob man am Ende schneller ist, kommt auf die Anwendung und die Beherrschung der AI an. Aber der schwierige Schritt des Anfangs ist deutlich einfacher und die gewonnene Zeit kann investiert werden eine qualitativ hochwertige Dokumentation zu erstellen.

Eine technische Integration entfällt, da die Schnittstelle der Mensch ist. Bei der Übertragung des Codes und Beschreibung der Anwendung im gen AI Prompt sind die Belange des Datenschutzes und ggf. eine Prüfung auf Vertraulichkeit der Anwendung zu berücksichtigen.

Im Idealfall ist im Unternehmen eine genAI im Einsatz die diese Belange über eigene Tenants oder spezielle Verträge absichert.

Weitere Hinweise

Wichtig: beim Review der Antworten, die Antworten „nüchtern“ prüfen (lt. Studie 39% der Fehler unerkannt geblieben, da Fragen „höflich“ beantwortet wurden): Qualitätsmängel: Forscher warnen vor ChatGPT-Einsatz beim Programmieren

    <h1 class="no_toc" id="mitarbeiter">Mitarbeiter</h1>

Name	Unternehmen	Tätigkeit beim Leitfaden
Alexander Lukas	EnBW	Schreiben, Review
Andrea Schlotthauer	SAP	Review
Andreas Göb	CQSE
Armin Junge	msg systems ag	Schreiben, Review
Bernd Reichel	HORNBACH Baumarkt AG	Schreiben, Review
Björn Schulz	REWE digital GmbH	Organisation, Schreiben, Review
Carine Tchoutouo Djomo	SAP	Review
Domi Bigl	Cadaxo
Dominik Panzer	Intense AG	Schreiben, Review
Enno Wulff	Inwerken	Schreiben, Review
Fabian Küng	inpeek AG
Fabian Lupa	adesso business consulting AG	Schreiben, Review
Florian Henninger	Cordes und Graefe	Schreiben, Review
Frank Engert	Softway AG
Gregor Wolf	profes
Harald Weidmann	Würth IT GmbH
Holger Stumm	log(2)
Jan Sauerland	ebm-papst St. Georgen GmbH & Co.KG	Schreiben, Review
Jens Knappik	thyssenkrupp	Schreiben, Review
Jens Zähringer	Nagarro ES
Josephine Reinhold	Softway AG	Schreiben, Review
Julius Dacheneder	msg systems ag	Schreiben, Review
Jürgen Creyaufmüller	Würth IT GmbH
Marc Zimmek	Claas
Marco Krapf	Würth IT GmbH	Schreiben, Review
Marcus Richter	CGI	Schreiben, Review
Markus Gradl	KRONES AG
Markus Rest	SVA	Schreiben, Review
Peter Luz	Robert Bosch GmbH	Kapitel ABAP Schreiben, Review
Sebastian Freilinger-Huber	msg systems ag	Organisation, Review
Sven Treutler	rku IT	Schreiben, Review
Thomas Fiedler	SAP	Review
Timo John	ADventas Gmbh	KAP Testing, KAP ABAP, KAP Clean Core, Review
Urs Bühlmann	inpeek AG
Volodymyr Vashchenko	Festo SE & Co.KG	Schreiben, Review

Autoren

Hier stellen sich die Autoren vor, an welchen Kapiteln sie mitgearbeitet haben, was sie in der realen Welt tun und was sie motiviert hat am Leitfaden mitzuarbeiten.

Name	Beteiligte Kapitel	Tätigkeit und Motivation
Volodymyr Vashchenko	Clean Core, Organisation, Core Data Services, Integration	Als ABAP Lead Developer bei FESTO bin ich der Innovationstornado, der immer vorne mitmischt. Mit der DSAG-Community Standards zu setzen, ist für mich wie ein heiliger Ritterschlag – nur mit weniger Rüstung und mehr Kaffeekicks!
Dominik Panzer	Organisation	Selbst die talentiertesten ABAP Entwicklerinnen mit dem besten KnowHow werden nicht erfolgreich sein, wenn sie nicht im Unternehmen ein positiv unterstützendes Umfeld finden: vom Management bis zu den Team-Kolleginnen, fundierend auf einer klaren Strategie, bewusst entschiedener Architektur und modernen Softwareentwicklungs-Prozessen. Deshalb engagiere ich mich neben "technischer Exzellenz" auch für Themen aus den Bereichen Organisation und Softwareentwicklungsprozesse/-vorgehensmodelle. Nur beides zusammen macht Menschen und damit die Unternehmen für die sie arbeiten erfolgreich.
Jan Sauerland	Moderne ABAP Entwicklung	Als Hauptansprechpartner für ABAP-Programmierung im Unternehmen hatte ich auf Basis des alten ABAP-Leitfadens von 2016 bereits unternehmensinterne ABAP-Richtlinien entworfen. Daher freue ich mich sehr darüber, nun selbst am DSAG-Leitfaden für ABAP mitwirken und mein gesammeltes Wissen einbringen zu können.

Danksagungen

Hier weitere Danksagungen …