13.4    Speicherbereiche für Datenübergabe 

Um das Problem der Datenübergabe zwischen verschiedenen Reports zu lösen, können Sie Dateien, Datenbanktabellen oder Arbeitsspeicherbereiche verwenden.

Für den Einstieg in ABAP betrachten wir die Datenübergabe mithilfe von Arbeitsspeicherbereichen. Hierzu werden Arbeitsspeicherbereiche verwendet, auf die mehrere Programme gemeinsam zugreifen dürfen. Sie müssen nur dafür sorgen, dass der richtige Report die richtigen Bereiche zur richtigen Zeit füllt, damit der andere Report dort sinnvolle Daten findet, wenn er sie benötigt. Diese Arbeitsspeicherbereiche heißen globales SAP Memory, lokales SAP Memory, ABAP Memory und Shared Memory.

 

13.4.1    Globales SAP Memory 

Das globale SAP Memory steht einem Anwender während seiner Anmeldedauer zur Verfügung; d. h. der Inhalt steht bis zum Abmelden des Benutzers vom System bereit. In diesem Bereich können Feldinhalte geschrieben und gelesen werden. Zur eindeutigen Identifizierung eines Inhalts dient eine bis zu 20-stellige Parameter-ID. Sehr häufig werden diese Parameter auch verwendet, um Selektionsbildschirme von Programmen mit Vorschlagswerten zu füllen.

Dem Schreiben in das globale SAP Memory dient die Anweisung SET PARAMETER ID, dem Lesen aus dem SAP Memory die Anweisung GET PARAMETER ID.

Möchten Sie beispielsweise den Inhalt des Feldes PROGNAME in die Parameter-ID Z_TEST schreiben, lautet die Anweisung:

SET PARAMETER ID 'Z_TEST' FIELD progname.

Müssen Sie umgekehrt aus dem SAP Memory den Inhalt des Parameters Z_TEST in die Variable PROGNAME des Programms einlesen, schreiben Sie:

GET PARAMETER ID 'Z_TEST' FIELD progname.

Mit der Anweisung SET PARAMETER und GET PARAMETER kann nur eine bestehende Parameter-ID genutzt werden. Sie kann allerdings über den ABAP Editor durch Vorwärtsnavigation oder über die ABAP Workbench leicht angelegt werden.

 

13.4.2    Lokales SAP Memory 

Das lokale SAP Memory steht nur für die Dauer einer Transaktion zur Verfügung. Sofern Sie aus dem Report mit der SUBMIT-Anweisung weitere Reports aufrufen, können die gerufenen Reports ebenfalls auf das lokale SAP Memory zugreifen. Die Anweisungen SET PARAMETER ID und GET PARAMETER ID schreiben in beide Speicherbereiche. Das lokale SAP Memory gewährleistet lediglich, dass während der Laufzeit der Transaktion die für sie geltenden Parameter-IDs unverändert bleiben, während sich die Inhalte des globalen SAP Memorys in dieser Zeit durch Ereignisse in einer anderen Transaktion durchaus ändern können.

 

13.4.3    ABAP Memory 

Die Lebensdauer des ABAP Memorys ist die kürzeste der drei Speicherbereiche. Dort abgelegte Inhalte bleiben nur so lange erhalten, wie auch ein externer Modus mit seinen internen Modi erhalten bleibt. Schließt aber beispielsweise der Benutzer diesen Modus, sind die Speicherinhalte gelöscht. Ein typischer Anwendungsfall ist die Übergabe von Daten an ein gerufenes Programm.

Die Anweisung, um Daten ins ABAP Memory zu schreiben, lautet EXPORT TO MEMORY ID. Mit der Anweisung IMPORT FROM MEMORY ID holen Sie Daten aus dem ABAP-Memory-Bereich zurück in Ihr ABAP-Programm.

Mit der EXPORT-Anweisung werden Objekte wie Felder, Workareas oder interne Tabellen in das ABAP Memory geschrieben. Die Objekte werden als Feldliste angegeben. Es existiert auch eine Variante dieser Anweisung ohne die Angabe der bis zu 60-stelligen Memory-ID, bei der stets derselbe Speicherbereich beschrieben bzw. ausgelesen wird. Die Memory-ID ist der Clustername.

Die Objekte werden im ABAP Memory als Cluster abgelegt, d. h. als Folge von Binärzeichen. Es ist deshalb sehr wichtig, dass die Struktur der Objekte beim Schreiben und Lesen übereinstimmt. Beim Lesen mit der IMPORT-Anweisung wird die angegebene Struktur bitweise gefüllt.

Möchten Sie beispielsweise die interne Tabelle ITAB04 als Cluster in das ABAP Memory schreiben, können Sie den Clusternamen als Literal oder eine Variable angeben, die den Clusternamen enthält – in folgendem Beispiel sei dies die Variable PROGNAME. Die EXPORT-Anweisung lautet dann:

EXPORT itab04 TO MEMORY ID progname.

In diesem Beispiel würde nur eine interne Tabelle exportiert. Wären mehrere Tabellen oder eine Kombination von Feldern, Workareas und Tabellen exportiert worden, würden sie alle binär im angegebenen Cluster liegen. Das ABAP Memory kann innerhalb der maximal 32-stelligen Namensmöglichkeiten beliebig viele Cluster enthalten, die allen Programmen in der Aufrufkette zur Verfügung stehen.

Möchten Sie beispielsweise im gerufenen Programm aus dem Cluster im ABAP Memory, das in der Variablen PROGNAME angegeben ist, die interne Tabelle ITAB04 wieder importieren und in die interne Tabelle ITAB05 stellen, lautet die Anweisung:

IMPORT itab04 TO itab05 FROM MEMORY ID progname.

Damit sind Sie nun in der Lage, auch große und komplexe Datenstrukturen an Programme in der Aufrufkette zu übergeben.

 

13.4.4    Shared Objects 

Wenn Sie die fortgeschrittene objektorientierte Programmierung in ABAP beherrschen, d. h. gezielt Objektinstanzen erzeugen und verwalten können, steht Ihnen mit den Shared Objects eine weitere Technik zum Zugriff auf einen übergreifenden Speicherbereich zur Verfügung. Da es hier zu weit führen würde, die fortgeschrittene, objektorientierte Programmierung in ABAP zu vermitteln, können wir auch auf diese Technik nur kurz eingehen. Der folgende Abschnitt soll Ihnen jedoch einen Eindruck vermitteln und Ihnen einen weiteren Grund liefern, sich in das Thema ABAP Objects einzuarbeiten.

Shared Objects sind Objektinstanzen von ABAP-Klassen, die nicht wie andere Objekte im Speicher ihres internen Modus leben, sondern im Shared Memory des ABAP-Applikationsservers verwaltet werden – in demselben Speicherbereich, in dem auch das ABAP Memory liegt. Um verschiedene Verwender (beispielsweise mehrere SAP-Anwendungen) des Shared Memorys auseinanderhalten zu können, werden die dort abgelegten Inhalte in sogenannten Gebieten organisiert, die Sie in Transaktion SHMA anlegen und verwalten können.

Um Objekte im Shared Memory ablegen und daraus auslesen zu können, müssen einige Bedingungen erfüllt sein:

• Erstens müssen die verwendeten Klassen im Class Builder die Eigenschaft Shared-Memory-fähig besitzen.

• Zweitens muss das verwendete Gebiet in Transaktion SHMA existieren.

• Drittens müssen Sie eine besondere Klasse, die sogenannte Gebietswurzelklasse, anlegen und in der Transaktion SHMA dem Gebiet zuordnen. Diese Klasse dient als Ihre Klasse für den Zugriff auf die im Shared Memory abgelegten Daten. Das bedeutet, dass Sie die Attribute und Methoden so wählen sollten, dass Sie damit – direkt oder indirekt – auf alle Daten und Objekte Zugriff erhalten können, die Sie im Shared Memory zu verwalten gedenken.

Sind diese Voraussetzungen erfüllt, können Sie mit wenigen Codezeilen auf das Shared Memory zugreifen und dabei alle Vorzüge der objektorientierten Programmierung genießen.