Dynpro-Folgen als Module aufrufen 

Wenn man eine Dynpro-Folge mitsamt ihrer Ablauf- und Anwendungslogik wieder verwendbar kapseln will, muss man beachten, dass alle Dynpros einer Folge immer fest mit einem einzigen ABAP-Programm verknüpft sind. Das ABAP-Programm enthält sämtliche von den einzelnen Dynpros aufrufbaren Dialogmodule.

Es ist zurzeit also nicht möglich, Dynpros einer einzelnen Prozedur (Unterprogramm, Funktionsbaustein, Methode) zuzuordnen, sondern immer nur dem Rahmenprogramm der Prozedur.

Der vollständige Aufruf eines Rahmenprogramms, wie z.B. über CALL TRANSACTION, um eine Dynpro-Folge zu verwenden, öffnet eine neue SAP-LUW. Dieser Effekt ist insbesondere bei der Modularisierung von Datenbank ändernden Transaktionen nicht immer erwünscht.

Als Alternative bietet es sich an, eine externe Prozedur aufzurufen, deren Rahmenprogramm mit einer Dynpro-Folge verknüpft ist und die entsprechenden Dialogmodule enthält. Prozeduren laufen in der gleichen SAP-LUW und im gleichen internen Modus wie das aufrufende Programm.

Verwendung von Funktionsbausteinen

Häufig verwendet man Funktionsbausteine und ihre Funktionsgruppen, um Dynpro-Folgen zu definieren und aufzurufen, die in der gleichen SAP-LUW laufen wie der Aufrufer

Um eine Dynpro-Folge in einem Funktionsbaustein zu kapseln verwendet man innerhalb des Funktionsbausteins die Anweisung CALL SCREEN. Das aufgerufene Dynpro und alle Folge-Dynpros gehören zur Funktionsgruppe des Funktionsbausteins. Die Dialogmodule, die aus der Dynpro-Ablauflogik aufgerufen werden, sind im Rahmenprogramm des Funktionsbausteins definiert. Der Function Builder unterstützt die Definition von Dialogmodulen durch das automatische Anlegen von geeigneten Include-Programmen.

Eine solche Funktionsgruppe enthält beispielsweise nur einen einzigen Funktionsbaustein und eine einzige Dynpro-Folge. Es sind aber auch mehrere Funktionsbausteine und mehrere unabhängige Dynpro-Folgen möglich.

Verwendung von Dialogbausteinen

Dialogbausteine waren die Vorläufer der Funktionsbausteine. Sie sollen inzwischen nicht mehr angelegt werden. Der Vollständigkeit halber wird hier kurz auf sie eingegangen.

Dialogbausteine sind Konstrukte, die ähnlich wie Transaktionscodes über ein Einstiegsdynpro mit einer Dynpro-Folge eines beliebigen ABAP-Programms verknüpft sind. Der Aufruf eines Dialogbausteins ruft das zugehörige ABAP-Programm auf und startet die Ausführung mit dem Einstiegsdynpro. Zusätzlich kann in einem Dialogbaustein eine Schnittstelle definiert werden. Die Parameter müssen zuvor im ABAP-Programm als globale Daten deklariert worden sein. Dialogbausteine werden mit einem dem Function Builder vergleichbaren Werkzeug (Transaktion SE35) der ABAP Workbench erstellt und verwaltet. Einem ABAP Programm können verschiedene Dialogbausteine zugeordnet werden.

 

Der Aufruf eines Dialogbausteins erfolgt mit der Anweisung CALL DIALOG:

CALL DIALOG dialog
            [AND SKIP FIRST SCREEN]
            [EXPORTING f₁ FROM a₁ ... f_n FROM a_n]
            [IMPORTING f₁ TO a₁ ... f_n TO a_n]
            [USING itab].

Die Syntax von CALL DIALOG ist wie bei CALL TRANSACTION. Zusätzlich können globale Daten des aufgerufenen Programms über die Schnittstelle versorgt werden.

Beim Aufruf eines Dialogbausteins wird zwar wie bei einem startbaren Programm ein neuer interner Modus geöffnet, das aufgerufene Programm läuft aber in der gleichen SAP-LUW wie das aufrufende Programm. Da Dialogbausteine einen neuen Modus öffnen, sind sie weniger performant als Funktionsbausteine. Andererseits sind Dialogbausteine das einzige Mittel, um einen Moduswechsel ohne Wechsel der SAP-LUW zu erzwingen. Nur indem man das Einstiegsdynpro einer bestehenden Transaktion mit einem Dialogbaustein verknüpft, kann man eine gesamte Transaktion innerhalb der SAP LUW eines Aufrufers ausführen.

Wenn Dynpro-Folgen sowohl als Dialogbaustein in der SAP-LUW des Aufrufers als auch als Transaktion in eigener SAP LUW ausgeführt werden sollen, ist dafür zu sorgen, dass alle Verbuchungsaufträge ohne Verlust der Datenintegrität ausgeführt werden können. Es gelten folgende spezielle Bedingungen:

·        Sperren werden beim Aufruf als Dialogbaustein vom Aufrufer geerbt.

Falls die Dynpro-Folge als Dialogbaustein aufgerufen wird, wird davon ausgegangen, dass eine Sperre für ein bestimmtes Objekt bereits existiert. Falls die Dynpro-Folge als Transaktion gestartet wird, müssen eigene Sperren eingerichtet werden. Mit der Systemvariablen sy-calld kann zur Laufzeit festgestellt werden, ob ein Programm im aufgerufenen Zustand läuft oder nicht.

·        Verbuchungs-Schlüssel werden beim Aufruf als Dialogbaustein vom Aufrufer geerbt.

·        COMMIT und ROLLBACK WORK-Anweisungen werden beim Aufruf als Dialogbaustein teilweise ignoriert.

Die Anweisungen COMMIT WORK und ROLLBACK WORKführen im aufgerufenen Programm zu Datenbank-Commits bzw. Datenbank-Rollbacks. Mit CALL FUNCTION IN UPDATE TASK und PERFORM ON [COMMIT|ROLLBACK] registrierte Prozeduren werden aber erst bei den entsprechenden Anweisungen im aufrufenden Programm ausgeführt.

·        Verbuchungs-Funktionsbausteine, die mit der Option IN UPDATE TASKaufgerufen werden, werden beim Aufruf als Dialogbaustein nicht angestoßen.

Es muss sichergestellt sein, dass der Aufruf eines solchen Funktionsbausteins bis zum nächsten COMMIT WORK im aufrufenden Programm verzögert werden darf.

·        Unterprogramme, die mit PERFORM ON COMMIT aufgerufen werden, werden beim Aufruf als Dialogbaustein nicht ausgeführt.

Es muss sichergestellt sein, dass der Aufruf eines solchen Unterprogramms bis zum nächsten COMMIT WORK im aufrufenden Programm verzögert werden darf. Insbesondere werden die globalen Daten des Dialogbausteins mit dem internen Modus abgebaut, wenn die Kontrolle an das aufrufende Programm zurückgeht. Unterprogramme, die mit PERFORM ON COMMIT aufgerufen werden, dürfen also nicht mit diesen globalen Daten arbeiten.

·        Für die Ausführung als Transaktion ist dafür zu sorgen, dass die Eingabeparameter der Schnittstelle immer mit sinnvollen Vorschlagswerten versehen sind.