ABAP - Aufbau eines Reports
Wie geht es weiter nach dem virtuellen Ende des Forms? Wie solltest du den Report aufbauen, was ist zu beachten und was gibt es für nützliche Sachen. Mehr dazu in diesem Artikel.
Inhaltsverzeichnis
Im letzten Artikel haben wir die Möglichkeiten betrachtet, wie wir Klassen in den Report implementieren und somit von den mittlerweile obsoleten Forms wegkommen. Heute wollen wir mit dir zusammen aufzeigen, was sich sonst noch so bei der Strukturierung ändern lässt, um sauberen und übersichtlichen Code zu generieren.
Die Klasse
Bei der Implementierung der Klasse wird man erst einmal vor der Frage stehen, wie soll die Klasse implementiert werden. Willst du sie lokal anlegen oder global? Soll sie statisch sein, mit einer Instanz oder im Singleton Prinzip arbeiten?
Jede dieser Implementierungen hat natürlich eigene Vor- und Nachteile, das sollte dir bewusst sein, bei der Auswahl der passenden Methode für die Implementierung.
- Solltest du dir Gedanken darüber machen, ob du die Klasse vielleicht noch einmal verwenden willst oder ob sie so statisch ist, dass sie nur zu diesem einen Fall passt, dann greife zu einer lokalen Klasse direkt im Programm.
- Möchtest du die Klasse wiederverwenden und sie leicht abgewandelt in anderen Reports einsetzen, dann verwende eine nicht finale globale Klasse.
- Bei einer lokalen Klasse kannst du je nach eigenem Geschmack entscheiden. Willst du eine Instanz, dann lege die Klasse als Instanz bei der Initialisierung bzw. beim Load-of-Program an.
Struktur
Bei der Anlage eines neuen Reports ist eine gute Struktur der erste Teil zum Ziel. Die Übersichtlichkeit und die Navigation im Report ist auch wichtig für deine Kollegen, die später einmal den Report übernehmen oder warten müssen.
Von daher solltest du dir ganz zu Anfang Gedanken darüber machen, wie du allgemein deine Reports strukturieren möchtest. Wir wollen dir daher einen Vorschlag dazu geben.
Einstieg
Direkt nach dem Einstieg solltest du direkte Navigationsmöglichkeiten anbieten. Das Ganze am Beispiel einer statischen/lokalen Klasse.
*----------------------------------------------------------------------*
*--- Includes
*----------------------------------------------------------------------*
INCLUDE:
ztest_01_top,
ztest_01_sel,
ztest_01_c01.
*----------------------------------------------------------------------*
*--- ABAP Events
*----------------------------------------------------------------------*
INITIALIZATION.
lcl_prog=>init_program( ).
AT SELECTION-SCREEN OUTPUT.
lcl_prog=>pbo_1000( ).
AT SELECTION-SCREEN.
lcl_prog=>ucomm( sscrfields-ucomm ).
END-OF-SELECTION.
lcl_prog=>start( ).
In dem gezeigten Beispiel startet das Programm mit den Includes des Reports, also alles was so an Daten und weiteren Definitionen zum Report dazu gehört. Danach folgen die Report Ereignisse der einzelnen Verarbeitungsschritte. In jedes Include und jede Methode der Events kann man mit einer Vorwärtsnavigation abspringen und sich direkt den Code ansehen.
Includes
Die Includes sorgen für eine saubere Strukturierung des Programms und der einzelnen Bestandteile.
- Im TOP-Include (_TOP) wird der Programmkopf und die Nachrichtenklasse definiert. Weiterhin werden alle globale Variablen und Typen definiert. Im Normalfall wird allerdings nur der Verweis auf die Screenfields (sccrfields) benötigt, die den Usercommand weitergibt (siehe oberes Beispiel).
- Im Selektionsinclude (_SEL) liegen alle Selektionsbilder die für den Report benötigt werden.
- In den Klassenincludes (_Cxx) liegen jeweils Klassendefinition- und Implementierung einer Klasse, um die Ressourcen vom Rest des Programms zu trennen.
- Weiterhin könnte es noch ein Form-Include (_Fxx) geben, dass aber eigentlich nur noch für Modul-Routinen von Dynpros verwendet wird.
Selektionsbild
Bei der Übergabe der Daten vom Selektionsbild an die Klasse gibt es zwei grundlegende Konzepte:
- Du verwendest die globalen Parameter und Select-Options direkt in der Klasse und greifst auf sie zu, als wären sie exterene Datenquellen.
- Du übergibst die Parameter beim Start der Verarbeitung direkt an die Verarbeitungsroutine.
Der zweite Fall wäre eigentlich der Sauberste, dafür aber auch der aufwändigste, da du die einzelnen Select-Options auch im Eingang typisieren müsstest.
Datenhaltung
Die globalen Daten in einem Programm würden zum Großteil verschwinden, dies ist aber nicht immer möglich, da gewisse Werte global gehalten werden müssen. Dazu einige Beispiele:
- Screenfields für die Weitergabe des Usercommands an die Methode zur Auswertung
- Hilfsfelder für Select-Options des Selektionsbildes
- Globale Tabellen für Dynpros zur Datenhaltung und zur Verarbeitung
- Globale Typisierungen
Alle anderen Werte würden in die Klasse wandern, da hier auch die Verarbeitung stattfindet. Somit liegen zum Beispiel ...
- Konstanten
- Daten
- Typisierungen
... alle in der Klasse.
Wie genau dann die einzelne Klasse implementiert wird, liegt an dir als Entwickler und sollte sorgsam durchdacht werden, ob dies deinem Konzept entspricht und ob dies auch leicht erweiterbar und wartbar ist.
Fazit
Dies sollte nur ein Beispiel für die Strukturierung eines Reports sein und stellt keine Verpflichtung für dich da. Vielleicht konnten wir dich mit dem Konzept etwas auf neue Ideen und Ansätze bringen, die du nun in deine tägliche Arbeit übernehmen kannst.
