Eine Beispieltransaktion 

Zur Illustration des Konzepts der dialoggesteuerten Ausführung und des Gebrauchs von Transaktionen, wird im folgenden die einfache Beispieltransaktion DEMO_TRANSACTION aus dem Paket SABAPDOCU gezeigt.

Funktionalität

Die Beispieltransaktion besteht aus nur einem Bild. Hier kann der Benutzer die Kennung einer Fluggesellschaft und eine Flugnummer angeben und damit Fluginformationen anfordern:

Wenn der Benutzer Anzeigen wählt, holt das System die angeforderten Flugdaten aus der Datenbank und zeigt sie an:

Aufbau

Im folgenden ist der Aufbau der Beispieltransaktion beschrieben.

Sämtliche Komponenten findet man im Repository Browser unter dem Programmnamen SAPMDEMO_TRANSACTION. Während der Ausführung der Transaktion kann man sich auch über System → Status einen Überblick über die Komponenten verschaffen dort über Doppelklick in das entsprechende Werkzeug der ABAP Workbench verzweigen.

Dynpro

Jedes Bildschirmbild enthält Felder, über die Informationen angezeigt oder abgefragt werden. Felder können u.a. Textstrings, Eingabe- oder Ausgabefelder, Auswahlknöpfe, Ankreuzfelder oder Drucktasten sein. Das Bild in der Transaktion DEMO_TRANSACTION enthält nur Texte und Ein-/Ausgabefelder.

Ein Dynpro besteht aus mehreren Komponenten:

·        Dynpro-Attribute: Angabe der Bildnummer, Nummer des Folgebilds und anderer Attribute.

·        Layout: Anordnung der Texte, Felder und Drucktasten etc. für ein Bild.

·        Feldattribute: Definition der Eigenschaften der einzelnen Felder auf einem Bild.

·        Ablauflogik: Aufruf der ABAP-Module für ein Bild.

Alle Bestandteile eines Dynpros werden mit dem Werkzeug Screen Painter erstellt und bearbeitet. Um den Screen Painter aufzurufen, legt man zum Beispiel ein Dynpro im Repository Browser an oder wählt ein Dynpro durch Doppelklick aus. Der Repository Browser verzweigt in den Screen Painter, wo  die Ablauflogik des zu erstellenden Dynpros bzw. des zu verändernden Dynpros eingegeben werden kann. Über entsprechende Drucktasten kann in den Fullscreen-Editor, die Feldliste oder in die Pflege der Dynpro-Attribute verzweiget werden.

Dynproattribute

Aus der Sicht des Benutzers ist eine Transaktion eine Abfolge von Bildern, die eines nach dem anderen angezeigt werden. Wie wird diese Abfolge festgelegt? Die Attribute der Transaktion geben das erste Bild an, und die Attribute der einzelnen Bilder bestimmen das Nachfolgebild für das aktuelle Bild. Das Nachfolgebild kann auch dynamisch durch das ABAP-Programm gesetzt werden.

Für das vorliegende Beispiel ist eine Änderung der Dynpro-Attribute nicht notwendig, da kein Folgedynpro aufgerufen wird.

Layout

Über die Drucktaste Fullscreen gelangt man im Screen Painter in den Fullscreen Editor. Hier wird das Layout des Dynpros festgelegen. Für die Transaktion DEMO_TRANSACTION können die gewünschten Felder der Tabelle SPFLI des ABAP Dictionary entnommen werden (siehe Screen Painter).

Feldattribute

In der Feldliste können die Attribute der einzelnen Felder angezeigt und verändert werden. (Ein-/Ausgabefelder, Mussfelder, mit Werthilfetaste, unsichtbar etc.)
Die Felder Fluggesellschaft (SPFLI-CARRID) und Flugnummer (SPFLI-CONNID) werden als Ein-/Ausgabefelder eingerichtet. Die übrigen Felder werden nur für die Ausgabe der Flugdaten benötigt.

Ablauflogik

Das Coding der Ablauflogik eines Bildes besteht aus einigen Befehlen, die syntaktisch an die Konstrukte der Sprache ABAP angelehnt sind. Die Schlüsselwörter der Ablauflogik können nicht in ABAP verwendet werden und umgekehrt. Das Coding der Ablauflogik wird im Screen Painter als Teil des Dynpros eingegeben.

Die Ablauflogik für das Bild der Beispieltransaktion DEMO_TRANSACTION sieht so aus:

PROCESS BEFORE OUTPUT.
  MODULE set_status_0100.
*
PROCESS AFTER INPUT
  MODULE user_command_0100.

Die Anweisungen PROCESS leiten die Ablauflogik für die beiden Ereignisse PBO und PAI des Dynpros ein. Die Anweisungen MODULE rufen jeweils ein Dialogmodul im zugehörigen ABAP-Programm auf. In diesem Beispiel wird jeweils nur ein einziges Dialogmodul für das Ereignis PBO und PAI aufgerufen. Die Ablauflogik von PBO und PAI kann jedoch mehrere Anweisungen enthalten und jeweils mehrere Dialogmodule hintereinander aufrufen. Umgekehrt kann ein Dialogmodul von verschiedenen Dynpros aufgerufen werden.

Die Syntax der Ablauflogik beinhaltet nur wenige Schlüsselwörter. Die wichtigsten sind MODULE, FIELD, CHAIN, LOOP, CALL SUBSCREEN. Informationen zur Syntax der Ablauflogik findet man unter Hilfsmittel →Hilfe zu... im Editor der Ablauflogik. Im angezeigten Dialogfenster wählt man dann Ablauflogik-Schlüsselwort und gibt den Namen des gewünschten Schlüsselwortes ein.

ABAP-Programm

Das ABAP-Programm hat ist ein Modul-Pool. Beim Anlegen eines Modul-Pools im Repository Browser organisiert die ABAP Workbench den Programmtext automatisch in mehreren Include-Programmen. Falls das ABAP-Programm der Namenskonvention SAPMnamefolgt, bietet der Hierarchiebaum des Repository Browsers unter folgenden Bezeichnungen einen Zugriff auf die einzelnen Include-Programme an:

·        Globale Felder: Globale Datendeklarationen im Include MnameTOP, die für alle Module des ABAP-Programms gelten.

·        PBO-Module: Dialogmodule in den Includes MnameOnn, die vor der Bildanzeige aufgerufen werden.

·        PAI-Module: Dialogmodule in den Includes MnameInn, die nach einer Benutzeraktion aufgerufen werden

·        Unterprogamme: Programminterne Unterprogramme in den Includes MnameFnn, die von jeder beliebigen Stelle im Programm aus aufgerufen werden

·        Listenereignisse: Ereignisblöcke für Ereignisse des Listenprozessors in den Includes MnameEnn, die bei der Listenverarbeitung auftreten können.

Ein Include-Programm kann mehrere Verarbeitungsblöcke enthalten, die normalerweise alle vom gleichen Typ sind (also z.B. nur PBO-Module oder nur PAI-Module). Es kann aber auch für jeden Verarbeitungsblock ein eigenes Include-Programm angelegt werden und es können auch verschiedene Typen von Verarbeitungsblöcken in einem Include-Programm sein.

Wenn man dem von der Workbench vorgegebenen Weg folgt, enthält der Quelltext des Rahmenprogramms nichts außer einer Folge von INCLUDE-Anweisungen, die die einzelnen Include-Programme einbinden:

*&---------------------------------------------------------------*
*&  Modulpool        SAPMDEMO_TRANSACTION                        *
*&                                                               *
*&---------------------------------------------------------------*
*&                                                               *
*&     Daten der Tabelle SPFLI anzeigen                          *
*&                                                               *
*&---------------------------------------------------------------*

* Globale Daten
INCLUDE mdemo_transactiontop.

* PAI-Module
INCLUDE mdemo_transactioni01.

* PBO-Module
INCLUDE mdemo_transactiono01.

Im vorliegenden Beispielprogramm sehen die aufgelösten Include-Programme wie folgt aus:

*&---------------------------------------------------------------*
*& Modulpool        SAPMDEMO_TRANSACTION                         *
*&            FUNKTION: Daten der Tabelle SPFLI anzeigen         *
*&                                                               *
*&---------------------------------------------------------------*
*----------------------------------------------------------------*
*   INCLUDE MDEMO_TRANSACTIONTOP (Dies ist das TOP-Inlude:       *
*           das TOP-Modul enthält globale Datendeklarationen)    *
*----------------------------------------------------------------*
PROGRAM  sapmdemo_transaction.
  TABLES: spfli.

  DATA ok_code(4).

*----------------------------------------------------------------*
*   INCLUDE MDEMO_TRANSACTIONO01  (Dies ist ein PBO-Include.)    *
*----------------------------------------------------------------*
*&---------------------------------------------------------------*
*&      Modul STATUS_0100
*&---------------------------------------------------------------*
*    GUI-Status und Titel für Bild 100 angeben                   *
*----------------------------------------------------------------*
MODULE status_0100.
  SET PF-STATUS ‘TZ0100’.
  SET TITLEBAR ‘100’.
ENDMODULE.

*----------------------------------------------------------------*
*   INCLUDE MDEMO_TRANSACTIONI01  (Dies ist ein PAI-Include.)    *
*----------------------------------------------------------------*
*&---------------------------------------------------------------*
*&      Modul   USER_COMMAND_0100  INPUT
*&---------------------------------------------------------------*
*       Daten aus SPFLI holen oder Transaktion verlassen         *
*----------------------------------------------------------------*
MODULE USER_COMMAND_0100 INPUT.
  CASE ok_code.
    WHEN ‘SHOW’.
      CLEAR ok_code.
      SELECT SINGLE * FROM spfli WHERE carrid = spfli-carrid
                                  AND  connid = spfli-connid.
    WHEN space.
    WHEN OTHERS.
      CLEAR ok_code.
      SET SCREEN 0. LEAVE SCREEN.
   ENDCASE.
ENDMODULE.

Im Include-Programm mdemo_transactiontop wird mit der TABLES-Anweisung ein Tabellenarbeitsbereich für die Datenbanktabelle SPFLI angelegt. Da die Ein-/Ausgabefelder auf dem Dynpro mit dem gleichen Dictionary-Bezug angelegt wurden, dient der Tabellenarbeitsbereich als Interface für die Datenübergabe zwischen Dynpro und ABAP-Programm. Das Feld ok_code dient der Übernahme von Funktionscodes aus dem gleichnamigen Dynprofeld.

Im Include-Programm mdemo_transactiono01 setzt das PBO-Modul für das Dynpro 100 den Dialogtatus STATUS_0100 und den GUI-Titel 100. Dieser GUI-Status und dieser GUI-Titel bleiben für alle Folgedynpros gültig, bis ein neuer Dialogtatus oder GUI-Titel gesetzt wird. Das Setzen des Dialogstatus ist sehr wichtig, da sonst ein leerer Dialogtatus verwendet, der es dem Benutzer nicht erlaubt das Programm zu verlassen.

Im Include-Programm mdemo_transactioni01 überprüft das das PAI-Modul USER_COMMAND_0100, welche Drucktaste der Benutzer gewählt hat (CASE ok_code). Die Drucktaste Anzeigen wurde auf dem Dynpro mit dem Funktionscode ‘SHOW’ angelegt. Wenn der Benutzer diesen Funktionscode auslöst liest das Programm Sätze aus der Datenbank SPFLI, die den vom Benutzer eingegebenen Daten entsprechen. In der WHERE-Bedingung der SELECT-Anweisung werden die Felder SPFLI-CARRID und SPFLI-CONNID des vom Dynpro versorgten Tabellenarbeitsbereichs mit den Datenbankschlüsselfeldern CARRID und CONNID verglichen.

Wenn das Bild erneut angezeigt wird, erscheint die vollständige Information in den Ausgabefeldern des Bildes, denn vor der Anzeige werden die Daten des Tabellenarbeitsbereichs wieder an das Dynpro übergeben.

GUI-Status und GUI-Titel

GUI-Status und GUI-Titel sind sogenannte Oberflächenelemente von Bildschirmbildern. Beide werden mit dem Werkzeug Menu Painter der ABAP Workbench angelegt und bearbeitet. Auf Dynpros werden GUI-Status vom Typ Dialogstatus verwendet.

Ein Dialogstatus ist eine Zusammenfassung von interaktiven Oberflächenelementen für ein Bildschirmbild. Durch das Setzen des Dialogstatus mit der ABAP-Anweisung SET PF-STATUS werden die entsprechenden Elemente für das folgende Bildschirmbild verwendet. Der Dialogstatus für ein Dynpro einer Transaktion enthält typischerweise alle ihm möglichen Elemente, also Menüleiste, Symbolleiste, Drucktastenleiste und Tastenbelegung. Diese Elemente erlauben es dem Benutzer z.B. durch Auswahl eines Menü-Eintrags oder Drücken einer Drucktaste einen Funktionscode an die PAI-Module des aktuellen Dynpros zu senden. Es gibt auch speziellere GUI-Status namens (Status für) Dialogfenster und Kontextmenüs. Diese enthalten dem speziellen Zeck angepasst weniger Elemente. Ein Status für ein Dialogfenster hat keine Menüleiste und keine Symbolleiste. Ein Kontextmenü ist ein einzelnes kontextabhängiges Menü, das mit der rechten Maustaste (SHIFT F10) aktiviert werden kann.

Der GUI-Titel ist der Bildtitel, der in der Titelleiste des Fensters angezeigt wird. Der GUI-Titel wird nicht in einem GUI-Status mit den anderen Oberflächenelementen zusammengefasst. Jeder GUI-Titel muss extra mit der ABAP-Anweisung SET TITLEBAR gesetzt werden.

Interaktion zwischen Dynpro und ABAP-Programm

In ihrer einfachsten Form ist eine Transaktion eine Sammlung von Bildern und ABAP-Verarbeitungsblöcken, die unter der Steuerung der Laufzeitumgebung ablaufen. Die Laufzeitumgebung arbeitet Dynpro für Dynpro ab und ruft die erforderliche ABAP-Verarbeitung für die Bilder aus.

Die Laufzeitumgebung ist der Überbegriff für Dynpro- und ABAP-Prozessor (siehe Workprozesse). Für jedes Bild führt der Dynproprozessor die Ablauflogik des Bildes aus, in der die entsprechende ABAP-Verarbeitung für jedes Bild aufgerufen wird. Die Steuerung wechselt immer zwischen Dynpro- und ABAP-Prozessor und der Ablauf des Anwendungsprogramms wechselt entsprechend zwischen Ablauflogik und ABAP-Verarbeitungslogik. Wie wir bei ABAP-Programmen von Ereignissen sprechen, kennen wir auch in der Ablauflogik zwei Zeitpunktereignisse, nämlich PBO und PAI eines Dynpros. Die Laufzeitumgebung, in diesem Fall der Dynpro-Prozessor, löst diese Ereignisse aus, z.B. PAI bei einer Benutzeraktion auf dem Bildschirm.

Die zeitliche Reihenfolge der Ereignisse für Transaktion DEMO_TRANSACTION sieht beispielsweise so aus:

...

       1.      Im Dynpro-Ereignis PBO ruft die Anweisung MODULE STATUS_0100 das entsprechende Dialogmodul auf und übergibt die Steuerung an den ABAP-Prozessor.

       2.      Wenn das Modul STATUS_0100abgearbeitet ist, geht die Steuerung an die Ablauflogik zurück. Der Dynproprozessor zeigt das Bildschirmbild an.

       3.      Eine Benutzeraktion löst das Dynpro-Ereignis PAI aus. Die Anweisung MODULE USER_COMMAND_0100 ruft das entsprechende Dialogmodul auf und übergibt die Steuerung an den ABAP-Prozessor.

       4.      Wenn das Modul USER_COMMAND_0100 abgearbeitet ist, geht die Steuerung an den Dynpro-Prozessor zurück. Da in den Dynproattributen als statisches Folgebild 100 eingetragen ist, beginnt der Programmablauf des Dynpros wieder bei Schritt 1.

Bei jedem Wechsel zwischen den Prozessoren werden die Daten gleichnamiger Felder übergeben. Beim Wechsel von Ablauflogik zu Verarbeitungslogik werden die globalen ABAP-Variablen mit den Inhalten gleichnamiger Dynprofelder gefüllt und umgekehrt. Zu den Dynprofeldern gehört immer ein Feld (Typ OK), das den Funktionscode der Benutzeraktion enthält. Um dieses auszuwerten, muss das ABAP-Programm ein gleichnamiges globales Feld enthalten.