Übersicht zu Dialogprogrammen
Wir bezeichnen den Ablauf eines dialoggesteuerten Programms bzw. eines Programms, das über einen Transaktionscode gestartet wird als SAP-Transaktion oder auch kurz als Transaktion, wenn aus dem Zusammenhang klar ist, was gemeint ist. Der Begriff Transaktion wird in der Informationsverarbeitung mehrfach verwendet. Im Zusammenhang mit dem Teilhaberbetrieb (OLTP, Online Transaction Processing), wo mehrere Benutzer gleichzeitig im Dialogbetrieb an einem System arbeiten, steht der Begriff Transaktion für einen Benutzerauftrag. Im Zusammenhang mit
Datenbankänderungen steht der Begriff Transaktion für eine Zustandsänderung auf der Datenbank.Während Programme vom Typ 1 sowohl durch Angabe des Programmnamens als auch über Transaktionscodes gestartet werden können, können Programme vom Typ M nur über Transaktionscodes und steuernde Dynpros gestartet werden. Dynpros rufen im zugehörigen ABAP-Programm Dialogmodule auf. ABAP-Programme vom Typ M dienen hauptsächlich als Container für Dialogmodule und heißen deshalb Modulpools. Programme vom Typ 1 oder Funktionsbausteine vom Typ F können durch die Anweisung CALL SCREEN ein Dynpro aufrufen und dadurch in die dialoggesteuerte Ausführung wechseln. Der Programmtext der aufrufenden Programme vom Typ 1 oder F müssen dann die entsprechenden Dialogmodule enthalten.
Programme, die ganz oder teilweise dialoggesteuert sind können nicht im Hintergrund ausgeführt werden. Deshalb spricht man auch von Dialogprogrammen.
Komponenten eines Dialogprogramms
Ein dialoggesteuertes Programm setzt sich aus folgenden Grundbausteinen zusammen:
Der Transaktionscode startet eine Dynproablaufkette. Ein Transaktionscode wird in der ABAP Workbench im Repository Browser oder über die Transaktion SE93 mit einem ABAP-Programm und einem zugehörigen Einstiegs-Dynpro verknüpft. Alternativ zum Start über über einen Transaktionscode kann die Dynproablaufkette aus jedem ABAP-Programm mit der Anweisung CALL SCREEN gestartet werden.
Jeder Dialog in einem R/3-System wird von
Das Bildschirmbild selbst hat ein Layout, das die Position von Ein-/Ausgabefeldern, Textfeldern und grafischen Bedienelementen wie Auswahlknöpfen und Ankreuzfeldern bestimmt. Die Ablauflogik besteht aus zwei Teilen:
Alle Dynpros, die innerhalb eines ABAP-Programms aufgerufen werden sollen, müssen zum gleichen Programm gehören. Die Dynpros zu einem Programm sind numeriert. Zu jedem Dynpro ist ein Standardfolgedynpro vermerkt. Damit kann sowohl eine lineare als auch eine zyklische
Zu jedem Bildschirmbild gehört ein
Jedes Dynpro und jeder GUI-Status im R/3-System sind mit genau einem ABAP-Programm verknüpft. Das zugehörige ABAP-Programm enthält die Dialogmodule, die von der Dynpro-Ablauflogik aufgerufen werden und verarbeitet die Benutzereingaben des GUI-Status. Ein ABAP-Programm mit Dynpros heißt auch Dialogprogramm. Bei einem Modulpool vom Typ M ist der zeitlich zuerst aufgerufene Verarbeitungsblock immer ein Dialogmodul. Es können aber auch andere ABAP-Programme, z.B. vom Typ 1 oder vom Typ F mit Dynpros verknüpft sein. Dann wird der erste Verarbeitungsblock anders aufgerufen, z.B. über die Laufzeitumgebung oder über den Aufruf einer Prozedur, und die Dynprofloge wird durch CALL SCREEN gestartet.
Bei den Dialogmodulen werden PBO- und PAI-Module unterschieden. Dialogmodule, die zum Zeitpunkt PBO aufgerufen werden, sollen die Bildschirmmaske kontextabhängig vorbereiten, z.B. durch Setzen von Feldinhalten oder durch Ausblenden nicht benötigter Felder im Bildschirmlayout. Dialogmodule, die zum Zeitpunkt PAI aufgerufen werden, sollen die Eingaben des Benutzers überprüfen und geeignete Dialogschritte bzw. die Verbuchung veranlassen.
Übergabe von Daten zwischen ABAP-Programm und Dynpro
Wie werden im ABAP-Programm bekannte Felder auf dem Bildschirmbild angezeigt? Und wie werden Benutzereingaben in Feldern auf dem Bildschirmbild an das ABAP-Programm übermittelt? Im Gegensatz zur Listenprogrammierung können Felddaten nicht mit der Anweisung WRITE auf dem Bild ausgegeben werden. Das System überträgt die Daten vielmehr, indem es Dynpro-Feldnamen mit ABAP-Feldnamen vergleicht. Sind die beiden Namen gleich, werden die Werte zwischen Dynpro und zu ABAP-Programm übertragen. Die Datenwerte werden unmittelbar vor bzw. nach der Bildanzeige vom Programm in die Dynprofelder kopiert bzw. umgekehrt.
Feldeigenschaften
Für alle Bildschirmfelder eines Dynpros werden im Screen Painter Feldeigenschaften festgelegt. Bei gleicher Namensgebung für ein Feld im ABAP Dictionary und im Dynpro besteht automatisch ein Bezug zwischen den beiden Feldern. Dies führt dazu, daß ein großer Teil der Feldeigenschaften im Dynpro automatisch aus dem ABAP Dictionary übernommen werden kann. Die Feldeigenschaften, sowie Datenelement und Domäne des zugeordneten Dictionary-Feldes bilden die Grundlage für die Standardfunktionen, die das Dynpro im Dialog leistet (automatische Formatprüfungen für Bildschirmfelder, automatische Wertebereichsprüfungen, Online-Hilfe etc.)
Fehlerdialoge
Eine weitere Aufgabe des Dynpro-Prozessors ist die Durchführung von Fehlerdialogen. Die Überprüfung der Eingabedaten wird entweder automatisch über Prüftabellen des ABAP Dictionary oder vom ABAP-Programm selbst durchgeführt. Der Dynpro-Prozessor blendet die Fehlermeldung in das empfangene Bildschirmbild ein und sendet es an den Benutzer zurück. Die Meldung wird gegebenenfalls kontextabhängig ausgegeben, d.h. aktuelle Feldinhalte werden für Platzhalter im Meldungstext eingesetzt. Außerdem werden nur diejenigen Felder eingabebereit gemacht, für die eine Korrektur ihres Inhalts zur Behebung des Fehlers beitragen kann. Siehe auch
Nachrichten auf Dynpros.Datenkonsistenz
Um über komplexe Anwendungen hinweg Daten konsistent zu halten, stellt ABAP Techniken zur Optimierung von Datenbankaktualisierungen bereit, welche unabhängig von der darunterliegenden Datenbank arbeiten und den speziellen Anforderungen der Dialogprogrammierung entsprechen. Siehe auch
Datenbankänderungen programmieren.