Programmausführung und Programmtypen 

Ein ABAP-Programm auszuführen bedeutet, seine Verarbeitungsblöcke in einer bestimmten Reihenfolge aufzurufen. Diese Steuerung erfolgt von außerhalb des Programms durch die Prozessoren des aktuellen Workprozesses. Für den zeitlichen Ablauf fassen wir Dynpro-Prozessor und ABAP-Prozessor der beteiligten Workprozesse zur ABAP-Laufzeitumgebung zusammen. Die Laufzeitumgebung enthält einige spezialisierte Steuerungsabläufe, die Bildschirmbilder und ABAP-Verarbeitungsblöcke in bestimmten, zweckgebundenen Reihenfolgen aufrufen können. Wir bezeichnen diese zeitlich aufeinander folgenden Abschnitte auch als Prozessoren. Bei der Ausführung eines ABAP-Programms wechseln sich die einzelnen Prozessoren hintereinander ab und es hat immer ein bestimmter Prozessor die Kontrolle.

 

Jedes ABAP-Programm besitzt einen Programmtyp, der bei der Programmerstellung in den Programmeigenschaften festgelegt werden muss.

Zur Auswahl gibt es hier 7 Typen: ausführbares Programm, Modul-Pool, Funktionsgruppe, Class-Pool, Interface-Pool, Subroutinen-Pool und Include-Programm.

Vor Release 4.6 wurden hierfür die internen einstelligen Kürzel angegeben. Ein ausführbares Programm hatte beispielsweise den Typ 1. Inzwischen wird der Programmtyp über den vollen Namen ausgesucht. Er definiert die grundlegenden technischen Eigenschaften des Programms d.h. welche Verarbeitungsblöcke ein Programm enthalten kann, wie das Programm von der ABAP-Laufzeitumgebung behandelt bzw. ausgeführt wird und ob es mit eigenen Dynpros arbeiten kann.

 

Bei der Ausführung eines ABAP-Anwendungsprogramms muss zumindest der erste Verarbeitungsblock von außerhalb des Programms, also aus der Laufzeitumgebung aufgerufen werden. Aus diesem Verarbeitungsblock heraus können dann weitere Verarbeitungsblöcke aufgerufen oder die Kontrolle wieder an die Laufzeitumgebung abgegeben werden. Beim Start eines ABAP-Programms wird ein vom Programmtyp abhängiger Prozessor in der Laufzeitumgebung gestartet, der den ersten ABAP-Verarbeitungsblock aufruft. Der Start kann durch den Benutzer, aber auch durch das System, z.B. bei der Hintergrundverarbeitung, oder durch externe Schnittstellen, z.B. bei Remote Function Calls (RFC) erfolgen.

 

Der Benutzer eines SAP-Systems kommt in der Regel nicht direkt mit dem Programm in Kontakt. Die Ausnahme davon sind ausführbare Programme, die über Eingabe ihres Namens nach System -> Dienste -> Reporting gestartet werden können. Alle anderen eigenständigen Programme (d.h. alle Programmtypen mit Ausnahme von Include-Programmen) können entweder über einen Transaktionscode aufgerufen oder nur durch die Verwendung ihrer Prozeduren geladen werden. Meistens müssen Benutzer aber nicht einmal den Programmnamen bzw. den Transaktionscode kennen, da der Aufruf eines Programms in der Regel mit Menüpfaden der zugehörigen Anwendungen verknüpft ist.

Unter Transaktionscode versteht man einen zwanzigstelligen Namen, der mit einem Dynpro oder mit einer Methode eines ABAP-Programms verknüpft ist und zum Ausführen von Programmen dient. Dies geschieht durch die Eingabe des Transaktionscodes in das Eingabefeld der Systemfunktionsleiste oder durch die Anweisungen CALL TRANSACTION oder LEAVE TO TRANSACTION. Mit Dynpros verknüpfte Transaktionscodes sind bei ausführbaren Programmen, Modul-Pools und Funktionsgruppen möglich. Die mit Methoden verknüpften Transaktionscodes sind für alle Programmtypen außer für Include-Programme erlaubt.

Ausführbare Programme

Ausführbare Programme werden direkt mit dem Werkzeug ABAP Editor angelegt und können mit Ausnahme von Funktionsbausteinen alle in ABAP möglichen Verarbeitungsblöcke sowie beliebig viele lokale Klassen enthalten. Sie werden ausschließlich über die Anweisung SUBMITgestartet. Auch wenn der NetWeaver AS ABAP verschiedene Möglichkeiten bietet, ausführbare Programme durch Angabe des Programmnamens auf Bildschirmbildern aufzurufen, wird im Hintergrund letztendlich stets die Anweisung SUBMITausgeführt. 

Ausführbare Programme müssen nicht unmittelbar über selbstdefinierte Dynpros gesteuert werden, weil zugehörige Prozessoren der Laufzeitumgebung automatisch und in einer vorgegebenen Reihenfolge die Aufrufe von Verarbeitungsblöcken und gegebenenfalls von Bildschirmen (Selektionsbilder und Listen) übernehmen. Der Ablauf ermöglicht erst eine Eingabe von Selektionsparametern auf einem Selektionsbild, dann eine Datenselektion und Datenverarbeitung und schließlich die Datenausgabe auf einer Liste, ohne dass der Programmierer eigene Dynpros definieren muss. Benutzeraktionen auf den Bildschirmen können den Aufruf weiterer Verarbeitungsblöcke veranlassen.

Weiterhin steuert die Laufzeitumgebung die Zusammenarbeit mit einer logischen Datenbank, d.h. mit einem speziellen ABAP-Programm zum Lesen von Daten aus Datenbanktabellen. Der vorgegebene Ablauf eines ausführbaren Programms orientiert sich somit an den Aufgaben des Reporting (Selektionseingabe, das Lesen von Daten, die Datenverarbeitung und die Darstellung der Daten). Aus diesem Grund werden ausführbare Programme oft als Report und das Starten von ausführbaren Programmen als Reporting bezeichnet (siehe: Reportprogrammierung), was auch damit in Einklang steht, dass der Quelltext eines ausführbaren Programms mit der Anweisung REPORTeingeleitet wird.

Da die Definition von Ereignisblöcken nicht vorgeschrieben ist, kann der Programmierer entscheiden, auf welche Ereignisse das ausführbare Programm reagieren soll. Weiterhin kann er jederzeit eigene Dynpros oder Verarbeitungsblöcke aufrufen, um den vorgegebenen Ablauf zu verlassen, z.B. um Daten statt auf einer Liste in einer Tabelle auf einem Dynpro darzustellen. Das einfachste ausführbare Programm enthält z.B. nur den Standardverarbeitungsblock START-OF-SELECTION.

Bei ausführbaren Programmen ist kein Benutzerdialog notwendig (siehe: Dialogprogrammierung). Das Selektionsbild kann über Varianten gefüllt werden und Ausgabedaten können statt auf die Liste direkt ins Spool-System gestellt werden. Deshalb sind ausführbare Programme Voraussetzung für die Hintergrundverarbeitung.

Wenn ein ausführbares Programm mit Transaktionscodes versehen wird, kann der Benutzer das Programm auch über den Transaktionscode starten. Auch in diesem Fall findet in der Laufzeitumgebung der reporting-orientierte Ablauf statt, weshalb wir solche Transaktionen auch als Report-Transaktionen bezeichnen.

Der Einsatz von ausführbaren Programmen ist immer dann sinnvoll, wenn der Programmablauf ganz oder teilweise dem vordefinierten Ablauf in der Laufzeitumgebung entspricht. Vor Release 4.5A waren ausführbare Programme die Voraussetzung für den Einsatz von logischen Datenbanken. Inzwischen können logische Datenbanken aber auch selbständig aufgerufen werden.

Modul-Pools

Modul-Pools werden direkt mit dem ABAP Editor angelegt und mit der Anweisung PROGRAMeingeleitet. Sie können mit Ausnahme von Reporting-Ereignisblöcken und Funktionsbausteinen alle in ABAP möglichen Verarbeitungsblöcke sowie beliebig viele lokale Klassen enthalten. Während ihrer Ausführung können sämtliche Ereignisse der ABAP-Laufzeitumgebung auftreten.  

Die wichtigste technische Eigenschaft von Modul-Pools ist die Tatsache, dass sie ausschließlich über die Ablauflogik von Dynpros gesteuert werden. Diese Programme müssen über Transaktionscodes aufgerufen werden, die mit einem Dynpro (Einstiegs-Dynpro) des Programms verknüpft sind. Bei diesen Programmen muss der Programmierer also eigene Dynpros definieren, wobei das Einstiegs-Dynpro auch ein Selektionsbild sein kann.

Beim Start des Programms über den Transaktionscode wird in der Laufzeitumgebung ein Prozessor gestartet, der zunächst das Einstiegs-Dynpro aufruft, welches dann ein Dialogmodul des zugehörigen ABAP-Programms aufruft. Der weitere Ablauf ist völlig beliebig. Das Dialogmodul kann beispielsweise

·        die Kontrolle an das Dynpro zurückgeben, dann verzweigt der Ablauf zu einem Folge-Dynpro. Jedes Dynpro hat ein statisches oder dynamisches Folge-Dynpro. Dynpros und ihre Folge-Dynpros sind die Bestandteile von frei definierbaren Dynpro-Folgen.

·        andere Dynpro-Folgen, Selektionsbilder oder Listen aufrufen, von denen dann wiederum die entsprechenden Verarbeitungsblöcke im ABAP-Programm gestartet werden.

·        andere interne oder externe Verarbeitungsblöcke aufrufen.

·        andere Anwendungsprogramme über CALL TRANSACTIONoder SUBMIT aufrufen.

Die Arbeit mit Modul-Pools ist bei stark dialogorientierten Programmen mit vielen Dynpros sinnvoll, in denen der Programmablauf weitgehend durch die Ablauflogik von Dynpro-Folgen definiert wird.

Funktionsgruppen

Funktionsgruppen bzw. Function-Pools werden mit der Anweisung FUNCTION-POOL eingeleitet und sind die einzigen Programme, die Funktionsbausteine (spezielle Prozeduren, die aus allen anderen ABAP-Programmen aufgerufen werden können) enthalten dürfen. Sie können zwar über Transaktionscodes ausgeführt werden, werden jedoch in der Regel durch den Aufruf ihrer Funktionsbausteine geladen. Mit Ausnahme von Reporting-Ereignisblöcken können Funktionsgruppen alle in ABAP möglichen Verarbeitungsblöcke und beliebig viele lokale Klassen enthalten.

Wie ausführbare Programme und Modul-Pools können Funktionsgruppe eigene Dynpros und damit auch Selektionsbilder und Listen-Dynpros enthalten. Die Verarbeitung der Bildschirmbilder, d.h. die Reaktion auf Benutzeraktionen in Ereignisblöcken und Dialogmodulen, findet ebenfalls in der Funktionsgruppe statt. Der Aufruf der Bildschirmbilder erfolgt aus den Funktionsbausteinen der Gruppe. Eine Funktionsgruppe mit Bildschirmen und einem einzigen Funktionsbaustein ermöglicht damit die Modularisierung von Bildschirmabläufen.

Zur Erstellung von Funktionsbausteinen und Funktionsgruppen enthält die ABAP Workbench das spezielle Werkzeug Function Builder.

Class-Pools

Class-Pools können keine eigenen Dynpros und keine Verarbeitungsblöcke außer Methoden enthalten. Sie werden mit der Anweisung CLASS-POOL eingeleitet und dienen ausschließlich als Container für genau eine globale Klasse und beliebig viele lokale Klassen. Class-Pools werden durch die Verwendung ihrer globalen Klasse geladen. Seit Release 6.10 können auch Transaktioncodes mit Methoden globaler Klassen verknüpft werden, wodurch bei ihrer Verwendung implizit ein Objekt der Klasse erzeugt wird.

Zur Erstellung von Class-Pools enthält die ABAP Workbench das spezielle Werkzeug Class Builder.

Interface-Pools

Interface-Pools können keine eigenen Dynpros und keinerlei Verarbeitungsblöcke enthalten. Sie werden mit der Anweisung INTERFACE-POOL eingeleitet und dienen ausschließlich als Container für ein globales Interface, das in beliebigen globalen oder lokalen Klassen implementiert werden kann. Sie werden über die Verwendung des Interfaces geladen.

Interface-Pools werden wie Class-Pools mit dem Werkzeug Class Builder der ABAP Workbench erstellt.

Subroutinen-Pools

Subroutinen-Pools werden mit dem ABAP Editor angelegt und mit der Anweisung PROGRAMeingeleitet. Sie können keine eigenen Dynpros und außer dem Ereignisblock LOAD-OF-PROGRAM nur Unterprogramme als Verarbeitungsblöcke enthalten. Subroutinen-Pools werden durch den externen Aufruf ihrer Unterprogramme aus anderen ABAP-Programmen geladen.

Typgruppen

Typgruppen bzw. Typen-Pools werden mit dem Werkzeug ABAP Dictionary angelegt und mit der Anweisung TYPE-POOLeingeleitet. Sie können keine eigenen Dynpros und keinerlei Verarbeitungsblöcke enthalten. Typgruppen dienen ausschließlich als Container für globale Datentypen, die über die Anweisung TYPE-POOLS in jedem ABAP-Programm sichtbar gemacht werden können.

Include-Programme

Include-Programme sind im Gegensatz zu allen anderen Programmtypen keine eigenständigen Kompilationseinheiten mit eigenem Speicherbereich. Sie sind nicht ausführbar, sondern haben eine reine Bibliotheksfunktion für ABAP-Quelltext. Sie dienen ausschließlich als Mittel, um Programmtexte in kleine editierbare Einheiten zu gliedern, die über die Anweisung INCLUDE an beliebigen Stellen anderer ABAP-Programme eingebunden werden. Include-Programme stehen technisch in keinerlei Zusammenhang mit Verarbeitungsblöcken. Es bietet sich aber an, logische Programmeinheiten, wie den Deklarationsteil für globale Daten, mehrere gleichartige oder einzelne Verarbeitungsblöcke in jeweils eigene Include-Programme aufzuteilen. Die ABAP Workbench unterstützt die automatische Aufteilung von Modul-Pools, Funktionsgruppen und Class-Pools in Include-Programme. Eigene Include-Programme legt man direkt mit dem ABAP Editor an.