Rheinwerk < openbook > SAP-Wissen aus erster Hand
SAP-Wissen aus erster Hand.
 
Inhaltsverzeichnis
Vorwort zur vierten Auflage
1 ABAP und die ersten Schritte im SAP-System
2 ABAP Dictionary
3 Programmieren im ABAP Editor
4 Felder und Berechnungen
5 Modifikation von Zeichenketten
6 Debugging von Programmen
7 Modifikation von transparenten Datenbanktabellen
8 Rechnen mit Datum und Zeit, Mengen und Währungen
9 Mit Daten in einer Datenbanktabelle arbeiten
10 Programmablaufsteuerung und logische Ausdrücke
11 Selektionsbildschirme
12 Interne Tabellen
13 Modularisierung von Programmen
14 Weiterführende Themen
A Icons auf einen Blick
B Abkürzungsverzeichnis
C Die Autoren
Stichwortverzeichnis

Download:
- Beispielprogramme, ca. 23 KB

Buch bestellen
Ihre Meinung?

Spacer
<< zurück
Einstieg in ABAP von Karl-Heinz Kühnhauser, Thorsten Franz
Buch: Einstieg in ABAP

Einstieg in ABAP
Pfeil 14 Weiterführende Themen
Pfeil 14.1 Interessante Zeiten für die Programmiersprache ABAP
Pfeil 14.2 SAP HANA
Pfeil 14.3 Programmieren mit Frameworks
Pfeil 14.3.1 Beispiel Archivierungslösung
Pfeil 14.3.2 Skizze einer möglichen Archivierungslösung
Pfeil 14.4 Wichtige Frameworks im SAP-Standard
Pfeil 14.4.1 Web Dynpro ABAP und Floorplan Manager
Pfeil 14.4.2 SOAP-Webservices
Pfeil 14.4.3 OData-Services mit SAP Gateway
Pfeil 14.4.4 Frameworks für Erweiterungen
Pfeil 14.5 Auf zu neuen Ufern!
 
Zum Seitenanfang

14.3    Programmieren mit Frameworks Zur vorigen ÜberschriftZur nächsten Überschrift

Ein Phänomen, dem man in der objektorientierten Programmierung besonders häufig begegnet, hat in der ABAP-Welt massiv Einzug gehalten: Frameworks, eingedeutscht auch als Rahmenwerke bezeichnet, unterstützen Entwickler bei der Lösung wiederkehrender Aufgaben. Um das gleiche Problem nicht immer neu in ähnlicher Weise lösen zu müssen, verwenden Sie Bibliotheken, die das vorliegende Problem auf allgemeine und möglichst komfortabel wiederverwendbare Weise lösen.

Sie müssen dann nur noch das selbst programmieren, was am aktuellen Problem einzigartig ist, und was nicht in der allgemeinen Bibliothek vorhergesehen werden konnte.

Wie stellen Sie es nun an, dass Ihr problemspezifischer, nicht wiederverwendbarer Code und der generische Code des Frameworks reibungslos zusammenarbeiten? Populäre Frameworks sind sehr mächtig und entsprechend umfangreich. Sie bestehen aus vielen einzelnen Komponenten, die wie die Teile eines Puzzles zusammenarbeiten und jeweils genau zum richtigen Zeitpunkt und an der richtigen Stelle aufgerufen werden müssen. Ihre Interna sind aufgrund ihrer generischen Programmierweise häufig kompliziert und schwer zu durchschauen. Es wäre daher nicht sinnvoll, die Verantwortung für den korrekten Aufruf aller Bestandteile eines komplizierten Frameworks dem Anwender (also dem Programmierer, der es verwendet) zu überlassen, denn dessen Arbeit soll durch das Framework schließlich einfacher und nicht komplizierter werden.

Stattdessen sieht die Lösung typischerweise so aus, dass das Framework selbst die Kontrolle über den Gesamtablauf übernimmt. Einmal aufgerufen, übernimmt das Framework die Führung und ruft alle notwendigen Komponenten für einen sinnvollen Gesamtablauf selbst auf. Dazu gehören auch die von Ihnen programmierten, problemspezifischen (also nicht generischen) Bestandteile, die sich in den Gesamtablauf des Rahmenwerks reibungslos einfügen müssen und von diesem zum richtigen Zeitpunkt aufgerufen werden.

Hierfür bestehen zwei Voraussetzungen:

  • Die aufzurufende Komponente (beispielsweise eine ABAP-Klasse) muss dem Framework bekannt gemacht worden sein. Im ABAP-Umfeld geschieht dies zumeist, indem der Klassenname in eine Customizing-Tabelle eingetragen wird. Das Framework ermittelt zur Laufzeit die aufzurufenden ABAP-Klassen aus dieser Tabelle und ruft sie zum passenden Zeitpunkt auf.

    Eine alternative Methode besteht darin, dass Sie eine bestimmte Methode des Frameworks aufrufen und dabei den Namen der ABAP-Klasse oder eine entsprechende Objektinstanz übergeben. Damit haben Sie als Anwendungsprogrammierer Ihren Code erfolgreich registriert und es dem Framework ermöglicht, ihn zu gegebener Zeit aufzurufen.

  • Der vom Framework gerufene Anwendungscode muss die Vorgaben des Frameworks bezüglich der Schnittstelle einhalten. Wenn das Framework den Nutzercode aufruft, erwartet es, dass ganz gewisse Parameter vorhanden sind, die es zur Kommunikation mit dem Anwendungscode benötigt. Dies wird normalerweise sichergestellt, indem das Framework vorgibt, dass der Anwendungscode in einer ABAP-Klasse liegt, die ein bestimmtes, vom Framework vorgegebenes Klasseninterface implementiert, und damit die in diesem definierten Methoden und Parameter anbietet.

[»]  Software in Fachwerkbauweise

Das englische Wort Framework bedeutet Rahmenwerk. Stellen Sie sich die Programmierung mit Frameworks einfach vor wie den Bau eines Fachwerkhauses oder eines modernen Hauses in Holzrahmenbauweise. Zuerst wird der Rahmen errichtet, der die gesamte Konstruktion stützt, ihr Stabilität verleiht und ihre innere wie äußere Form definiert. Anschließend werden die Zwischenräume ausgefüllt, die der Rahmen lässt. Die Struktur des Rahmens ist entscheidend – mit dem bloßen Füllmaterial kann man keine tragende Wand errichten, wenn diese nicht in der Konstruktion des Rahmens vorgesehen ist.

Die Analogie gilt übrigens auch für die Ansprüche an die Qualität und Robustheit der Entwicklung: Eine marode Wandfüllung in einem Fachwerkhaus kann man ausbessern; aber ein morscher Fachwerkrahmen trägt kein Haus. Deshalb kommt es in der Framework-Entwicklung besonders auf einen robusten und langlebigen Rahmen an, der beim Ausfüllen möglichst viel Flexibilität zulässt und Gestaltungsräume bietet.

Die Technik, die Ablaufsteuerung und insbesondere den Aufruf des problemspezifischen Anwendungscodes dem Framework zu überlassen, nennt man Inversion of Control. Scherzhaft spricht man auch vom Hollywood-Prinzip: »Rufen Sie uns nicht an, wir rufen Sie an.«

 
Zum Seitenanfang

14.3.1    Beispiel Archivierungslösung Zur vorigen ÜberschriftZur nächsten Überschrift

Als Beispiel für ein Framework wollen wir hier eine Archivierungslösung betrachten. Archivierung ist notwendig, weil die Daten in vielen Tabellen eines Anwendungssystems nicht ewig bestehen können. Wird der Inhalt einer Tabelle im Laufe der Zeit zu umfangreich, werden Schreib- und vor allem Lesezugriffe immer langsamer, bis die Anwendbarkeit des Systems gefährdet ist. Zudem können große Mengen alter, nicht mehr benötigter Daten für die Anwender problematisch sein, wenn diese beispielsweise in Auswahldialogen vor lauter alten, abgeschlossenen Daten nicht mehr die aktuell zu bearbeitenden finden. Einerseits möchte man alte, abgeschlossene Daten aus dem Weg schaffen, damit sie den laufenden Betrieb nicht aufhalten oder stören. Andererseits möchte oder darf man sie nicht einfach löschen: Vielleicht benötigt man sie in Zukunft doch noch einmal, um einen lange zurückliegenden Einzelfall zu prüfen, oder es gibt gesetzliche Aufbewahrungsfristen, die das Löschen der Daten verbieten.

Die Lösung besteht hier in einer Datenarchivierung, bei der die vorerst nicht mehr benötigten Daten gesammelt, exportiert und z. B. auf einem externen Speichermedium außerhalb des SAP-Systems gespeichert werden. Anschließend werden sie im SAP-System gelöscht.

Dabei besteht die Anforderung, dass die gelöschten Daten nicht rückstandsfrei gelöscht werden sollen: Im SAP-System sollen Informationen bestehen bleiben, die es dem Anwender erlauben, relevante archivierte Datensätze nach bestimmten Suchkriterien aufzufinden und aus dem Archiv auszulesen. Hierzu wird im SAP-System ein sogenannter Archivindex angelegt, der auf die genaue Position der archivierten Datensätze im Archiv verweist und zusätzlich eine kleine Auswahl der Datenfelder des archivierten Datensatzes enthält – gerade genug, um relevante Datensätze im Archiv ermitteln zu können und zu verhindern, dass die im Archiv liegenden Datensätze gänzlich in der Anonymität verschwinden.

Analysiert man nun die konkrete Aufgabenstellung für mehrere zu archivierende Tabellen, stellt man schnell fest, dass die Gemeinsamkeiten zwischen den verschiedenen Archivierungsszenarien größer sind als die Unterschiede. Für sie soll eine allgemeine Lösung angestrebt werden:

  • Der grundsätzliche Ablauf (zu archivierende Daten identifizieren, sammeln, im Archiv speichern, Archivindex erzeugen, löschen) ist immer gleich.

  • Die Archivrecherche funktioniert ebenfalls grundsätzlich immer gleich: Suche nach archivierten Sätzen anhand einer handverlesenen Auswahl von Datenfeldern, Rückladen so gefundener Datensätze aus dem Archiv, Darstellung auf einer reinen Anzeigeoberfläche.

Die folgenden Merkmale sind von Archivierungsszenario zu Archivierungsszenario unterschiedlich und damit jeweils individuell zu realisieren:

  • Die fachliche Logik, anhand der die nicht mehr benötigten, zu archivierenden Datensätze erkannt werden, unterscheidet sich von Kunde zu Kunde und von Szenario zu Szenario.

  • Die zu archivierenden Tabellen und ihre Strukturen sind von Szenario zu Szenario unterschiedlich.

  • Die zum Wiederauffinden von archivierten Datensätzen benötigten Felder des Archivindexes unterscheiden sich ebenfalls von Fall zu Fall.

  • Die Dialogoberfläche zur Anzeige eines im Archiv liegenden Datensatzes unterscheidet sich von Tabelle zu Tabelle.

 
Zum Seitenanfang

14.3.2    Skizze einer möglichen Archivierungslösung Zur vorigen ÜberschriftZur nächsten Überschrift

Im Folgenden beschreiben wir eine mögliche Lösung für das Archivierungsproblem, die beispielhaft zeigt, wie Sie Frameworks zum Lösen wiederkehrender Probleme verwenden können – entweder, indem Sie selbst ein Framework entwickeln, oder einfach nur eines verwenden, das andere entwickelt haben.

Unsere wiederverwendbare Lösung für das Archivierungsproblem besteht aus einem Framework, das die allgemeinen, vom jeweiligen Anwendungsfall unabhängigen Aspekte löst und an bestimmten, neuralgischen Punkten gezielt Anwendungscode aufruft, der genau den Teil des Problems abdeckt, für den keine allgemeine Lösung geschaffen werden kann – also beispielsweise eine spezielle Methode zum Auswählen der zu archivierenden Datensätze oder einen speziellen Dialog zum Anzeigen eines im Archiv vorliegenden Datensatzes.

Dabei kontrolliert das Framework den im vorangehenden Abschnitt beschriebenen Gesamtablauf (zu archivierende Daten identifizieren, sammeln, im Archiv speichern, Archivindex erzeugen, löschen) selbst und ruft den anwendungsfallspezifischen Code (Logik zur Identifikation zu archivierender Daten, Anzeigedialog) zum passenden Zeitpunkt auf. In einer Customizing-Tabelle werden die Namen der anwendungsspezifischen ABAP-Klassen eingetragen, die beispielsweise die Datenselektion übernehmen.

Diese anwendungsspezifischen ABAP-Klassen müssen bestimmte, vom Framework vorgegebene Klassen-Interfaces implementieren, damit ihre Schnittstelle zur Laufzeit zu dem passt, was das Framework erwartet. Sie müssen gewissermaßen sicherstellen, dass sie auch die gleiche Sprache sprechen, wenn der ersehnte Anruf aus Hollywood kommt.

 


Ihre Meinung?

Wie hat Ihnen das Openbook gefallen? Wir freuen uns immer über Ihre Rückmeldung. Schreiben Sie uns gerne Ihr Feedback als E-Mail an kommunikation@rheinwerk-verlag.de

<< zurück
 Zum Rheinwerk-Shop
Zum Rheinwerk-Shop: Einstieg in ABAP Einstieg in ABAP
Jetzt Buch bestellen

 Buchempfehlungen
Zum Rheinwerk-Shop: SAP – Der technische Einstieg
SAP – Der technische Einstieg


Zum Rheinwerk-Shop: ABAP Objects – Das umfassende Handbuch
ABAP Objects – Das umfassende Handbuch


Zum Rheinwerk-Shop: ABAP-Entwicklung für SAP S/4HANA
ABAP-Entwicklung für SAP S/4HANA


Zum Rheinwerk-Shop: Kundeneigene Erweiterungen mit ABAP
Kundeneigene Erweiterungen mit ABAP


Zum Rheinwerk-Shop: Schrödinger programmiert ABAP
Schrödinger programmiert ABAP


Zum Rheinwerk-Shop: Migration nach SAP S/4HANA
Migration nach SAP S/4HANA


Zum Rheinwerk-Shop: Design Thinking mit SAP
Design Thinking mit SAP


 Lieferung
Versandkostenfrei bestellen in Deutschland, Österreich und in die Schweiz
InfoInfo

 
 


Copyright © Rheinwerk Verlag GmbH 2020
Für Ihren privaten Gebrauch dürfen Sie die Online-Version natürlich ausdrucken. Ansonsten unterliegt das <openbook> denselben Bestimmungen, wie die gebundene Ausgabe: Das Werk einschließlich aller seiner Teile ist urheberrechtlich geschützt.
Alle Rechte vorbehalten einschließlich der Vervielfältigung, Übersetzung, Mikroverfilmung sowie Einspeicherung und Verarbeitung in elektronischen Systemen.

 
[Rheinwerk]

Rheinwerk Verlag GmbH, Rheinwerkallee 4, 53227 Bonn, Tel.: 0228.42150.0, Fax 0228.42150.77, service@rheinwerk-verlag.de

Cookie-Einstellungen ändern