19,99 €
Mehr erfahren.
- Herausgeber: Espresso Tutorials
- Kategorie: Wissenschaft und neue Technologien
- Sprache: Deutsch
Mit der Neuauflage dieses Praxishandbuchs erhalten Entwickler und SAP-Berater, die mit der ABAP-Programmiersprache vertraut sind und nachvollziehbare bzw. wartungsfreundliche Algorithmen entwickeln wollen, einen noch größeren und praxisnäheren Fundus von Tipps und Tricks zur Fehlerminimierung und Wiederverwendbarkeit ihrer Codebasis.
Der Buchautor zeigt Ihnen anhand anschaulicher Beispiele, was sich hinter Clean Code, Unit-Tests, Refactoring oder Regressionstests verbirgt und wie Sie mithilfe dieser Werkzeuge sowohl Ihre Codequalität als auch Ihren Projekterfolg steigern. Dazu gehört des Weiteren eine umfassende Dokumentation, unterstützt u. a. durch die ABAP Development Tools for Eclipse (ADT), ABAP-Doc oder das C4-Modell. Nach einer gut strukturierten Testphase mittels Unit-Tests, SQL-Statements und Testattrappen werden Sie dem Releasetermin ruhig entgegenblicken. Im Hinblick auf den Transport Ihrer Entwicklung liefert Ihnen das Buch wertvolle Hinweise, um ungewollte Seiteneffekte zu vermeiden.
- Wartungsfreundliche Programme entwickeln und testen
- ABAP Unit, Coverage Analyzer und ABAP Test Cockpit
- Mit Versionsverwaltungswerkzeugen arbeiten
- Beispiele für Umsetzung in der Praxis
Das E-Book können Sie in Legimi-Apps oder einer beliebigen App lesen, die das folgende Format unterstützen:
Seitenzahl: 157
Veröffentlichungsjahr: 2024
Ähnliche
Johannes Gerbershagen
Qualitätsmanagement in der ABAP-Entwicklung unter SAP®
2., überarbeitete Auflage
Johannes GerbershagenQualitätsmanagement in der ABAP-Entwicklung unter SAP®, 2., überarbeitete Auflage
ISBN:978-3-960123-50-7 (E-Book)
Lektorat:Anja Achilles, Bernhard Edlmann
Korrektorat:Stefan Marschner
Coverdesign:Philip Esch
Coverfoto:© manfredxy | 641783620 – istockphoto.com
Satz & Layout: Johann-Christian Hanke
Alle Rechte vorbehalten
2. überarbeitete Auflage 2024
© Espresso Tutorials GmbH, Gleichen 2024
URL:www.espresso-tutorials.de
Das vorliegende Werk ist in allen seinen Teilen urheberrechtlich geschützt. Alle Rechte vorbehalten, insbesondere das Recht der Übersetzung, des Vortrags, der Reproduktion und der Vervielfältigung. Espresso Tutorials GmbH, Bahnhofstr. 2, 37130 Gleichen, Deutschland.
Ungeachtet der Sorgfalt, die auf die Erstellung von Text und Abbildungen verwendet wurde, können weder der Verlag noch Autoren oder Herausgeber für mögliche Fehler und deren Folgen eine juristische Verantwortung oder Haftung übernehmen.
Feedback:Wir freuen uns über Fragen und Anmerkungen jeglicher Art. Bitte senden Sie diese an: [email protected].
Inhaltsverzeichnis
Willkommen bei Espresso Tutorials!
Unser Ziel ist es, SAP-Wissen wie einen Espresso zu servieren: Auf das Wesentliche verdichtete Informationen anstelle langatmiger Kompendien – für ein effektives Lernen an konkreten Fallbeispielen. Viele unserer Bücher enthalten zusätzlich Videos, mit denen Sie Schritt für Schritt die vermittelten Inhalte nachvollziehen können. Besuchen Sie unseren YouTube-Kanal mit einer umfangreichen Auswahl frei zugänglicher Videos: https://www.youtube.com/user/EspressoTutorials.
Kennen Sie schon unser Forum? Hier erhalten Sie stets aktuelle Informationen zu Entwicklungen der SAP-Software, Hilfe zu Ihren Fragen und die Gelegenheit, mit anderen Anwendern zu diskutieren: https://forum.espresso-tutorials.com/.
Eine Auswahl weiterer Bücher von Espresso Tutorials:
Ulrich Bähr, Axel Treusch:
Praxisbuch SAP
®
Interactive Forms und Adobe LiveCycle Designer
– 2., erweiterte Auflage
Thomas Stutenbäumer:
SAP
®
Praxishandbuch ABAP Teil 1 – Konzeption, Entwicklung und Debugging
– 2., erweiterte Auflage
Thomas Stutenbäumer:
SAP
®
Praxishandbuch ABAP
®
Teil 2 – Performance, Erweiterungen, Transportwesen
– 2., erweiterte Auflage
Johannes Gerbershagen:
Praxishandbuch SAP
®
CAP – Cloud Application Programming Model
Christoph Lordieck, Manfred Sprenger:
SAP
®
-Schnelleinstieg: ABAP-Entwicklung in Eclipse
– 2., erweiterte Auflage
Julian Danho, Phillip Dörrschuck:
Schnelleinstieg in das SAP
®
ABAP
®
RESTful Application Programming Model (RAP)
Vorwort
Dieses Buch richtet sich an ABAP-Entwickler und SAP-Berater, die sich mit der Entwicklung von Qualitätssoftware beschäftigen. Es verschafft Ihnen einen Überblick, wie Sie hochwertige ABAP-Entwicklungen erstellen und diese Wertigkeit langfristig erhalten können. Lernen Sie die Themen Clean Code, Unit-Tests, Refactoring oder Regressionstests kennen und steigern Sie mithilfe dieser Werkzeuge sowohl Ihre Codequalität als auch Ihren Projekterfolg.
Mit der Auswahl der Themen richte ich mich gleichermaßen an Anfänger, denen das Thema »Codequalität« noch unbekannt ist, wie auch an fortgeschrittene Programmierer. Kenntnisse in der Programmiersprache ABAP sowie in der Objektorientierung in ABAP (ABAP Objects) sind allerdings Voraussetzung für ein besseres Verständnis.
Die Hauptthemen dieses Buches sind robustes Softwaredesign, Dokumentation, strukturiertes Testen, Bestandscode und Werkzeuge der ABAP-Entwicklungsumgebung. Nach einigen einführenden Bemerkungen zu den Codebeispielen stelle ich im zweiten Kapitel einige Gestaltungsrichtlinien vor, mit denen Sie Programme robust gestalten. In Kapitel 3 zeige ich Ideen und Modelle auf, wie Sie aussagekräftige Dokumentationen erstellen, die Ihnen später bei der Fehlersuche, beim Konfigurieren Ihrer Programme und bei Änderungen der Programmlogik behilflich sind. Das Kapitel »Strukturiertes Testen« beschäftigt sich damit, warum Tests im Entwicklungsprozess einen hohen Stellenwert haben, und macht Sie mit Strategien wie automatisierten Unit-Test sowie Integrationstests vertraut. Im folgenden Abschnitt über Bestandscode lernen Sie einige Methoden kennen, wie Sie ungewollte Seiteneffekte bei Erweiterungen oder Änderungen an bestehenden Programmen vermeiden, und im folgenden Kapitel lernen Sie Werkzeuge wie das ABAP Test Cockpit und den Code Inspector kennen. Ich schließe mit einem Perspektivwechsel auf das Management, indem ich in Kapitel 7 erkläre, wie auch diese Seite dazu beitragen kann, dass qualitativ hochwertige Software entsteht.
In der hier vorliegenden zweiten Auflage des Buches gehe ich unter anderem vermehrt auf den Einsatz von Werkzeugen und Hilfsmitteln wie der Open SQL-Testumgebung oder den ABAP Development Tools for Eclipse (ADT) ein. Zudem finden Sie mehr Beispiele, wie Sie theoretische Konzepte in die Praxis umsetzen.
Im Text verwenden wir Kästen, um wichtige Informationen besonders hervorzuheben. Jeder Kasten ist zusätzlich mit einem Piktogramm versehen, das diesen genauer klassifiziert:
Hinweis
Hinweise bieten praktische Tipps zum Umgang mit dem jeweiligen Thema.
Beispiel
Beispiele dienen dazu, ein Thema besser zu illustrieren.
Achtung
Warnungen weisen auf mögliche Fehlerquellen oder Stolpersteine im Zusammenhang mit einem Thema hin.
Übungsaufgabe
Übungsaufgaben helfen Ihnen, Ihr Wissen zu festigen und zu vertiefen.
Die Form der Anrede
Um den Lesefluss nicht zu beeinträchtigen, verwenden wir im vorliegenden Buch bei personenbezogenen Substantiven und Pronomen zwar nur die gewohnte männliche Sprachform, meinen aber gleichermaßen Personen weiblichen und diversen Geschlechts.
Hinweis zum Urheberrecht
Sämtliche in diesem Buch abgedruckten Screenshots unterliegen dem Copyright der SAP SE. Alle Rechte an den Screenshots hält die SAP SE. Der Einfachheit halber haben wir im Rest des Buches darauf verzichtet, dies unter jedem Screenshot gesondert auszuweisen.
1 Die Programmierbeispiele
In diesem Kapitel gebe ich Ihnen einige Informationen zu den Programmierbeispielen, die Sie durch dieses Buch begleiten. Damit Sie dem Inhalt besser folgen und die in Listings dargestellten Beispiele auch selbst ausprobieren können, sollten Sie dieses Kapitel nicht überspringen.
Codebeispiel »abgesagte Angebote«
Als Demonstrationswerkzeug diente mir bei der Erstellung dieses Buches ein Codebeispiel, dem ich in den nachfolgenden Kapiteln den Namen »Abgesagte Angebote« gegeben habe. Dieses Codebeispiel erstellt eine Auswertung über Angebote, deren Positionen vom Kunden mit dem Grund »zu teuer« abgesagt wurden. Die Auswertung enthält die Preisspanne der abgesagten Positionen sowie das Verhältnis zwischen der Anzahl abgesagter Positionen und der Anzahl der gesamten Positionen. Die Preisspanne bezieht sich immer auf eine konkrete Währung und eine bestimmte Menge. Die Mengen werden in der im Materialstamm hinterlegten Basismengeneinheit angegeben. Es erfolgt keine Umrechnung der unterschiedlichen Währungen in den einzelnen Positionen.
Den Source Code habe ich Ihnen im GIT-Repository https://github.com/germanysources/clean_code_demo zur Verfügung gestellt. Darin wurden zu Demonstrationszwecken hauptsächlich deutsche Begriffe und Kommentare verwendet. Der Source Code ist mit SAP NetWeaver Releases 7.52 und höher kompatibel.
Wichtigste Entwicklungsobjekte des Codebeispiels:
Report
zangebote_abgesagt
: übernimmt die Anzeige der Auswertung im ALV Grid,
Klasse
zangebote_abgesagt
: liest die Angebote von der Datenbank und bereitet die Daten für die Auswertung auf,
Klasse
zangebote_abgesagt_stub_demo
: enthält dieselbe Funktionalität wie die Klasse
zangebote_abgesagt
; demonstriert eine in
Abschnitt 4.6
beschriebenen Testattrappen.
Das angegebene Repository enthält zwei Varianten in zwei separaten Branches:
Branch: master
Die erste Variante setzt die Anzeige- und Änderungsmöglichkeit für Angebote im SD-Modul voraus. Die Kopfdaten der Angebote werden in dieser Variante aus den Tabellen vbak und vbkd sowie die Positionsdaten aus der Tabelle vbap ermittelt.
Branch: without_sd_tables
Die zweite Variante ist unabhängig von den Modulen SD und MM und kann damit insbesondere auf miniSAP-Installationen verwendet werden. In dieser Variante werden alle in den Modulen SD und MM vorhandenen Datenbanktabellen durch z-Tabellen ersetzt. Tabelle 1.1 gibt Ihnen einen Überblick, welche Tabellen durch z-Tabellen getauscht wurden. Für alle z-Tabellen existieren Pflege-Views, die Sie über die Transaktion SM30 erreichen.
Bedeutung
Tabelle SD/MM-Modul (wird im Masterbranch verwendet)
z-Tabelle (wird im WITHOUT_SD_TABLES-Branch verwendet)
Kopfdaten Angebote
VBAK,VBKD
ZANGEBOT_VBAK
Positionsdaten Angebote
VBAP
ZANGEBOT_VBAP
Kundenstamm
KNA1
ZANGEBOT_KUNDEN
Materialstamm
MARA
ZANGEBOT_MATERIA
Materialtexte
MAKT
ZANGEBOT_MATTEXT
Tabelle 1.1: Tausch der Datenbanktabellen im Master- und im WITHOUT_SD_TABLES-Branch
Für die Installation benötigen Sie das Open-Source-Versionsverwaltungswerkzeug abapGit, das in Abschnitt 6.1.2 vorgestellt wird. Falls Sie noch nicht mit abapGit gearbeitet haben, empfehle ich Ihnen, zunächst Abschnitt 6.1.2 zu lesen.
Codebeispiele aus dem Flugbetrieb
Das Codebeispiel »abgesagte Angebote« erstellt nur eine Auswertung. Neben dem Erzeugen von Auswertungen wird ABAP aber auch häufig für transaktionale Applikationen verwendet, mit denen die Nutzer Datenänderungen vornehmen. Transaktionale Applikationen werden anhand separater Codebeispiele verdeutlicht, die wie viele ABAP-Codebeispiele kleine Ausschnitte aus der Abwicklung eines Flugbetriebes zeigen. Diese Beispiele sollen Ihnen zur Verdeutlichung des geschriebenen Textes dienen, ohne dabei wie das Codebeispiel »abgesagte Angebote« eine konkrete Anforderung zu implementieren.
Download-Link Listings
Sie finden die zugehörigen Listings auch unter dem folgenden Download-Link: https://es-tu.de/jikGRB
Nach dem Download können Sie die Quelltexte in die ABAP-Workbench oder in die ADT kopieren.
2 Robustes Softwaredesign
Wie kann bereits in der Entwurfs- und Entwicklungsphase das Grundgerüst für ein erfolgreiches Projekt gelegt werden? In diesem Kapitel werde ich Ihnen einige Ideen dazu aufzeigen.
Ich teile die unter Experten häufig vertretene Meinung, dass durch die Entwicklung von Clean Code Software robust gestaltet wird. Clean Code umfasst eine Reihe von Maßnahmen, um Software aufgeräumt und sauber zu gestalten. Durch Ordnung und Klarheit können Sie folgende Ziele realisieren:
Nachvollziehbarkeit der Algorithmen,
Vermeidung von Stolperfallen,
einfache Wartung: Entwickler, die bisher nicht in das Projekt involviert waren, können den Source Code trotzdem lesen, verstehen und warten,
Fehlerminimierung: viele Bugs werden schon in der Testphase und nicht erst im produktiven Einsatz gefunden,
Wiederverwendbarkeit: dieselben Funktionen müssen nicht jedes Mal kopiert oder neu geschrieben werden.
In den nächsten Abschnitten stelle ich Ihnen einige Maßnahmen für die Entwicklung von Clean Code vor.
2.1 Übersichtlicher und verständlicher Source Code
Bei größeren Projekten empfiehlt es sich, den Source Code übersichtlich und verständlich zu gestalten. In der folgenden Liste möchte ich Ihnen daher einige einfache Gestaltungsrichtlinien vorstellen, die dazu beitragen.
Prozeduren kurz halten:
Sie müssen weniger am Bildschirm scrollen. Idealerweise kann der Bildschirm die Prozedur komplett darstellen.
Die Aufteilung in kleinere Einheiten erleichtert den Überblick und die Navigation. Wenn Sie sich nur einen Prozedurnamen zu merken oder aufzuschreiben brauchen, ist das meistens leichter, als eine Reihe von Anweisungen und Variablen im Kopf zu behalten.
Tief verschachtelte Schleifen und IF-ELSE-Blöcke lassen sich damit vermeiden.
Aussagekräftige Programm-, Klassen-, Methoden-, Prozedur- und Parameternamen vergeben:
oft verwendete Abkürzungen dokumentieren,
einheitliche Begriffe und Abkürzungen verwenden, die dem gesamten Team geläufig sind.
Aussagekräftige Namen und auch Kommentare sollen die Implementierung so detailliert beschreiben, dass sie von jedem Entwickler verstanden werden kann. Wofür wurde unser Programm konzipiert? Welchen Zweck erfüllt diese Prozedur? Mit welchen Werten sind die Eingabeparameter zu übergeben? Unter welchen Umständen werden Ausnahmen oder Fehlermeldungen geworfen? Die entsprechenden Antworten sollten wir den Namen bzw. Kommentaren entnehmen können.
Innerhalb von Prozeduren können Sie mit frei formulierten Kommentaren den Zweck Ihrer Anweisungen ausdrücken. Nach außen können Sie die für die Verwendung der Prozedur relevanten Informationen als ABAP-Doc-Kommentare bereitstellen. Listing 2.1 zeigt die Platzierung eines ABAP-Doc-Kommentars vor der entsprechenden Methodendefinition.
"! Liest alle Positionen (abgesagte und "! nicht abgesagte Angebote). "! @parameter angebots_nummern | Positionen dieser "! Angebote werden gelesen "! @parameter positionen | alle Strukturfelder "! werden mit den Werten aus der Tabelle vbap "! uebergeben METHODS get_angebotspositionen IMPORTING angebots_nummern TYPE zangebots_kopfdaten EXPORTING positionen TYPE zangebots_positionen.
Listing 2.1: Beschreibung einer Methode mit ABAP-Doc-Kommentaren
Auf die Syntax der ABAP-Doc-Kommentare gehe ich nochmal detailliert in Abschnitt 3.3 ein.
Die verwendeten Namen sollten einer eindeutigen Terminologie folgen. Sie sollten sie daher sinnvollerweise mit den Prozesseigentümern und den Entwicklern abstimmen, damit die Terminologie in einem klaren Zusammenhang mit dem im Code abgebildeten Geschäftsprozess steht. APIs bzw. Bibliotheken, die technischer Natur sind (z.B. die RTTS[RunTime Type Services]-Klasse cl_abap_typedescr), können mit technischen Fachbegriffen beschrieben werden. Bei anwendungsspezifischen Quelltexten ist die Verwendung von Fachbegriffen, die dem Geschäftsprozess entlehnt wurden, oft aussagekräftiger als eine rein auf die technische Umsetzung fokussierte Terminologie.
Aussagekräftige Namen: Tell don’t ask
Die Klasse zangebote_abgesagt enthält die Methode get_angebotskopfdaten. Aus technischer Sicht hätte ich diese Methode auch kurz get_vbak nennen können, da hier Datensätze aus der Tabelle vbak gelesen werden. Der Methodenname get_vbak wirft allerdings einige Fragen auf. Wenn Sie die Abkürzung vbak für »Vertriebsbelege Kopfdaten« nicht kennen, würden Sie sich sicherlich fragen: Was bedeutet vbak? Und selbst wenn Sie sie kennen, würden Sie sich vielleicht fragen, welche Vertriebsbelege aus der Tabelle vbak gelesen werden (Angebote, Kontrakte oder Aufträge).
Versionsverwaltungswerkzeuge richtig nutzen:
Änderungshinweise mit Autor und Datum in den einzelnen Zeilen erschweren nach vielen Modifikationen die Lesbarkeit und Verständlichkeit. Versionsverwaltungswerkzeuge dokumentieren bereits alle Änderungen mit Autor, Datum und den eingefügten, geänderten sowie gelöschten Zeilen.
Das Versionsverwaltungswerkzeug der ABAP Workbench ist, wie in Abbildung 2.1 ersichtlich, über den Menüpfad
Hilfsmittel • Versionen • Versionsverwaltung
zu erreichen. Bei der Freigabe eines Transportauftrages wird automatisch eine neue Version erzeugt. Die älteren Versionen gehen nicht verloren, wenn Sie auf Änderungshinweise im Code verzichten.
Inzwischen gibt es auch Open-Source-Versionsverwaltungswerkzeuge wie
git
®
(
https://git-scm.com
) und
abapGit
(
https://github.com/larshp/abapgit
), mit denen Sie die Änderungen im Source Code optimal nachvollziehen können. Beide Werkzeuge stelle ich in
Abschnitt 6.1
detailliert vor.
Abbildung 2.1: Versionsverwaltung in der ABAP Workbench
2.2 Technologieauswahl
Inzwischen stellt die SAP neben prozeduralem bzw. objektorientiertem ABAP eine Reihe von neuen Technologien zur Verfügung, unter anderem:
ABAP CDS (ABAP Core Data Services)
SAP RAP mit UI5 und Fiori
SAP CAP
Zu Beginn eines Projektes stellt sich natürlich die Frage, mit welcher Technologie es implementiert werden soll bzw., bei einer größeren Überarbeitung, ob die bestehende Technologie beibehalten wird. Darum habe ich im Folgenden eine kleine Entscheidungshilfe zusammengestellt, welche Technologie sich für welchen Einsatzzweck eignet und welche Vorkenntnisse Sie bzw. die Projektentwickler mitbringen sollten.
ABAP CDS:
Geeignet für komplexe Datenbankabfragen, um Daten aus verschiedenen Tabellen zu kombinieren, zudem für Journale, Auswertungen und Schnittstellen für Business-Intelligence-Systeme sowie um Redundanzen zu vermeiden. Sie sollten SQL-Kenntnisse, beispielsweise über INNER JOIN und OUTER JOIN, mitbringen.
SAP RAP mit SAP UI5 und SAP Fiori:
Geeignet für Web-Applikationen mit vielfältigen Gestaltungsmöglichkeiten. Sie sollten Kenntnisse in JavaScript, XML, UI5 und dem Fiori Launchpad mitbringen.
SAP CAP:
Geeignet für Web-Applikationen mit separater Datenbank. Sie sollten Kenntnisse in JavaScript, Node.js, UI5 und dem Fiori Launchpad mitbringen.
Ziel der neuen Technologien ist es nicht, das klassische ABAP zu ersetzen, sondern es um Frameworks zu ergänzen, mit deren Hilfe sich wiederkehrende Anforderungen, die zuvor eine Implementierung als Einzelfalllösung nötig machten, effizienter bewältigen lassen. Zu beachten ist dabei, dass alle Technologien Kenntnisse der Materie voraussetzen und Stolperfallen für Anfänger bereithalten, sodass Sie sich mit der Technologie befassen sollten, bevor Sie diese produktiv einsetzen.
2.3 Trennen der Belange (Separation of Concerns)
Unter dem Begriff Trennen der Belange versteht man die Abgrenzung der Ein- und Ausgaben von der Anwendungslogik. Die Anwendungslogik enthält nur Operationen mit ABAP-Variablen und ist unabhängig von externen Ressourcen wie der Benutzerschnittstelle, der relationalen Datenbank oder dem Dateisystem. Praktisch umsetzen lässt sich dies, indem Sie, wie in den folgenden Abschnitten beschrieben, einzelne Prozeduren, Funktionsgruppen oder Klassen für die Anwendungslogik, die Benutzerschnittstelle und die SQL-Statements bzw. die Interaktion mit dem Dateisystem definieren.
2.3.1 SQL-Statements
SQL-Statements sollten an möglichst wenigen Stellen gebündelt werden (z.B. nur in eigenen Prozeduren oder hinter eigenen Interfaces).
Dies bringt Ihnen während der Entwicklungs- und Testphase einige Vorteile:
Die SQL-Statements können Sie, wie in
Abschnitt 4.6
dargestellt, durch
Testattrappen
ersetzen, auch wenn Ihr System keine Open-SQL-Testumgebung (
Abschnitt 4.5
) bereitstellt. Eine Testattrappe liefert immer dasselbe Resultat, auch wenn sich die Datensätze in der Datenbank ändern. Mit ihrer Hilfe können Sie einzelne Komponenten der Anwendungslogik isoliert testen.
Die Anwendungslogik wird nicht so stark an das Datenbankschema gekoppelt. Schemaänderungen haben somit weniger Auswirkungen auf die Anwendungslogik.
SQL-Statements im Codebeispiel »abgesagte Angebote«
In der Klasse zangebote_abgesagt wurden die SQL-Statements in den folgenden Methoden gebündelt:
in der Methode get_angebotskopfdaten, die die Kopfdaten der Angebote (Tabelle vbak) liest, in der Methode get_texte, die die Materialtexte und Kundennamen liest, sowie in der Methode get_angebotspositionen, die die einzelnen Positionen (Tabelle vbap) liest.Die restlichen Methoden dieser Klasse enthalten die Anwendungslogik ohne SQL-Statements.
2.3.2 Präsentationslogik (User Interface)
Zum User Interface gehören alle Elemente, die direkt mit dem Benutzer interagieren (Dynpros, Table Controls, ALV Grids, Pop-ups, Meldungen mit der Anweisung MESSAGE usw.). Es spricht vieles dafür, das User Interface von der Anwendungslogik zu separieren. Dadurch gibt es bei Änderungen des User Interface weniger Seiteneffekte auf die Anwendungslogik und umgekehrt.
Der zweite Vorteil besteht darin, dass die Anwendungslogik auch von Hintergrundprogrammen genutzt werden kann.
Und es gibt sogar noch einen weiteren Vorteil: Sie können dem Benutzer dieselbe Anwendungslogik auf verschiedene Arten präsentieren – z.B. in der SAP GUI, im Web Dynpro oder als UI5-Applikation.
Mit der Trennung von User Interface, Anwendungslogik und SQL-Statements vermeiden Sie außerdem Dynpro-Wechsel zwischen zwei schreibenden SQL-Statements oder zwei Verbuchungsbausteinen. Solch ein Dynpro-Wechsel schließt die Datenbank-LUW zu früh ab und durchbricht damit das Transaktionskonzept, auf das ich in Abschnitt 2.5 unter »COMMIT WORK-Anweisungen« näher eingehe.
Im Codebeispiel »abgesagte Angebote« wurde das User Interface im Report zangebote_abgesagt implementiert. Die Trennung von User Interface und Anwendungslogik wurde durch den Einsatz des Bausteines REUSE_ALV_GRID_DISPLAY sowie der Klasse zangebote_abgesagt erreicht, die die Daten in der Methode get_angebote passend aufbereitet. Wenn Sie sich den Report zangebote_abgesagt in Listing 2.2 genauer anschauen, entdecken Sie einen TRY-Block, der die klassenbasierte Ausnahme zcx_angebot_abgesagt auffängt. Diese Ausnahme wird in der Anwendungslogik geworfen und erst im START-OF-SELECTION-Ereignis mithilfe der Anweisung MESSAGE not_found TYPE 'S' in eine sichtbare Meldung umgewandelt. Das Verhalten der MESSAGE-Anweisung ist abhängig vom eingesetzten User Interface. Daher sollte sie streng genommen nicht in der Anwendungslogik, sondern erst im User Interface verwendet werden.
Klassenbasierte Ausnahmen in der Anwendungslogik
Verwenden Sie in der Anwendungslogik klassenbasierte Ausnahmen als Transportmittel für eine Fehlermeldung. Fangen Sie die Ausnahme erst im User Interface ab und wandeln Sie sie dort in eine für den Benutzer sichtbare Fehlermeldung um.
Buchempfehlung
Einen Leitfaden zur Implementierung von Ausnahmeklassen finden Sie im Buch »Schnelleinstieg in SAP ABAP Objects« (Deppe, Espresso Tutorials, 2., erweiterte Auflage 2017: http://5194.espresso-tutorials.de).
Listing 2.2: Auszug aus dem Report zangebote_abgesagt
MVC-Prinzip
Das MVC-Prinzip löst die Trennung von Anwendungslogik und User Interface durch die Einführung von drei Abstraktionsniveaus:
1. M für Model: stellt das Datenmodell und die Prozeduren der Anwendungslogik bereit,
2. V für View: enthält die Komponenten der Präsentationslogik,
3. C für Controller
