Die ABAP-Programme der Verarbeitungslogik übernehmen die zentrale Rolle der Datenverarbeitung in der R/3-Anwendungsprogrammierung. Die Programmiersprache ABAP ist speziell für dialogorientierte Datenbankanwendungen konzipiert. In den folgenden Abschnitten gehen wir detailliert auf Aufbau und Ausführung von ABAP-Programmen ein.

ABAP-Programme dienen der Datenverarbeitung während der einzelnen Dialogschritte eines Anwendungsprogramms. Das bedeutet, daß ABAP-Programme nicht als eine einzige sequentielle Einheit aufgebaut sein können, sondern in Abschnitte unterteilt sein müssen, die den einzelnen Dialogschritten zugeordnet werden können. Um dieser Anforderung gerecht zu werden, sind ABAP-Programme modular aus Verarbeitungsblöcken aufgebaut. Ein Verarbeitungsblock besteht aus (normalerweise mehreren) ABAP-Anweisungen. Verarbeitungsblöcke sind nicht schachtelbar und die Programmausführung beruht auf dem Aufruf von Verarbeitungsblöcken.

Das folgende Bild zeigt den Aufbau eines ABAP-Programms:

Jedes ABAP-Programm besteht aus den folgenden zwei Teilen:

Der erste Teil eines ABAP-Programms ist der Deklarationsteil für globale Daten, Klassen und Selektionsbilder. Dieser Teil wird gebildet aus:

• allen Datendeklarationsanweisungen für globale Daten. Globale Daten sind in allen internen Verarbeitungsblöcken sichtbar. Sie werden durch die Datendeklarationsanweisungen definiert, die vor dem ersten Verarbeitungsblock, in Dialogmodulen oder in Ereignisblöcken stehen. In den letztgenannten beiden Verarbeitungsblöcken sind mit zwei Ausnahmen keine lokalen Daten deklarierbar.
• allen Definitionen von Selektionsbildern.
• allen Deklarationen von programminternen Klassen (Anweisung CLASS DEFINITION). Programminterne Klassen sind Teil von ABAP Objects, der objektorientierten Erweiterung von ABAP.

Datendeklarationsanweisungen, die Prozeduren (Methoden, Unterprogramme, Funktionsbausteine) aufgeführt sind, bilden den Deklarationsteil für die lokalen Daten dieser Verarbeitungsblöcke. Diese Daten sind auch nur innerhalb der Prozeduren sichtbar.

Der zweite Teil eines ABAP-Programms umfaßt alle Verarbeitungsblöcke des Programms. Folgende Typen von Verarbeitungsblöcken sind möglich:

• Dialogmodule (kein lokaler Datenbereich)
• Ereignisblöcke (bis auf zwei Ausnahmen kein lokaler Datenbereich)
• Prozeduren (Methoden, Unterprogramme und Funktionsbausteine mit jeweils lokalem Datenbereich)

Während Dialogmodule und Prozeduren durch definierende ABAP-Schlüsselwörter eingeschlossen sind, werden Ereignisblöcke durch Ereignisschlüsselwörter eingeleitet und durch den nächsten Verarbeitungsblock beendet.

Alle ABAP-Anweisungen (bis auf die deklarativen Anweisungen des Deklarationsteils) sind Teil eines Verarbeitungsblocks. Nichtdeklarative ABAP-Anweisungen, die zwischen dem Deklarationsteil für globale Daten und einem Verarbeitungsblock stehen, werden automatisch dem Ereignisblock START-OF-SELECTION zugeordnet.

Der Aufruf von Verarbeitungsblöcken kann werden entweder von außerhalb des ABAP-Programms oder durch ABAP-Befehle, die selbst wieder in Verarbeitungsblöcken stehen, erfolgen. Dialogmodule und Ereignisblöcke werden von außerhalb des ABAP-Programms aufgerufen, Prozeduren werden durch ABAP-Befehle in ABAP-Programmen aufgerufen.

Der Aufruf von Ereignissblöcken unterscheidet sich wie folgt von den Aufrufen von anderen Verarbeitungsblöcken:

Ereignisblöcke werden aufgrund von Ereignissen aufgerufen. Benutzeraktionen auf Selektionsbildern und Listen aber auch die Laufzeitumgebung lösen Ereignisse aus, die in ABAP-Programmen behandelt werden können. Nur für Ereignisse, auf die das Programm reagieren soll, müssen Ereignisblöcke definiert sein (während z.B. zu einem Unterprogrammaufruf sehr wohl ein Unterprogramm existieren muß). Das bedeutet, daß ein ABAP-Programm auf bestimmte Ereignisse reagieren kann, aber nicht muß.

Ein ABAP-Programm auszuführen bedeutet, seine Verarbeitungsblöcke aufzurufen. ABAP-Programme werden von außerhalb des Programms gesteuert. Die Steuerung erfolgt 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 steuert Bildschirme und ABAP-Verarbeitungsblöcke. Die Laufzeitumgebung enthält einige spezialisierte Steuerungsabläufe, die Bildschirme und ABAP-Verarbeitungsblöcke in bestimmten, zweckgebundenen Reihenfolgen aufrufen können. Wir bezeichnen diese zeitlich aufeinanderfolgenden 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.

Im R/3-System unterscheiden wir zwischen verschiedenen Typen von ABAP-Programmen. Die Programmtypen müssen bei der Programmerstellung festgelegt werden. Sie definieren die grundlegenden technische Eigenschaften des Programms. Das wesentliche Unterscheidungsmerkmal zwischen den einzelnen Programmtypen ist die Art und Weise wie die Verarbeitungsblöcke der Programme von der Laufzeitumgebung aufgerufen werden.

Bei der Ausführung eines Anwendungs-Programms muß zumindest der erste Verarbeitungsblock eines ABAP-Programms 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 eines ABAP-Programms 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.

Beim Programmstart durch Benutzer unterscheiden wir zwischen der direkten Ausführung durch Angabe des Programmnamens und dem Start über Transaktionscodes. Sie können jedes Anwendungsprogramm mit einem Transaktionscode versehen. Der Benutzer kann das Programm dann über die direkte Eingabe des Transaktionscodes starten. Weiterhin werden in der Regel alle Transaktionscodes auch mit Menüpfaden auf den Bildschirmen des R/3-Systems verknüpft.

Folgende Programmtypen sind für Anwendungsprogramme von Bedeutung:

Ein Typ 1-Programm hat die wichtige technische Eigenschaft, daß es nicht unmittelbar über selbstdefinierte Dynpros gesteuert werden muß. Bei einem Typ 1-Programm übernehmen Prozessoren der Laufzeitumgebung automatisch und in einer vorgegebenen Reihenfolge die Aufrufe von Verarbeitungsblöcken und gegebenenfalls von Bildschirmen (Selektionsbilder und Listen). Benutzeraktionen auf den Bildschirmen können den Aufruf weiterer Verarbeitungsblöcke vernanlassen.

Ein Typ 1-Programm und damit der zugehörige Prozessor in der Laufzeitumgebung wird ausschließlich über die Anweisung SUBMIT aus anderen ABAP-Programm heraus gestartet. Das R/3-System bietet verschiedene Möglichkeiten, die Ausführung von Typ 1-Programmen durch Angabe des Programmnamens auf Bildschirmbildern zu starten. Deshalb sprechen wir bei Typ 1-Programmen auch von ausführbaren Programmen.

Bei Typ 1-Programmen läuft in der Laufzeitumgebung eine vordefinierte Folge von Prozess-Schritten ab. 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 daß der Programmierer eigene Dynpros definieren muß. Weiterhin steuert die Laufzeitumgebung die Zusammenarbeit mit einer logischen Datenbank. Eine logische Datenbank ist ein spezielles ABAP-Programm zum Lesen von Daten aus Datenbanktabellen. Der vorgegebene Ablauf eines Typ 1-Programms orientiert sich somit an den Aufgaben des Reporting. Dazu zählen Selektionseingabe, das Lesen von Daten, die Datenverarbeitung und die Darstellung der Daten. Aus diesem Grund werden ausführbare Programme vom Typ 1 im R/3-System oft als Report und das Starten von ausführbaren Programmen als Reporting bezeichnet.

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.

Für die Ausführung von ausführbaren Programmen ist kein Benutzerdialog notwendig. 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 im R/3-System.

Wenn ein ausführbares Programme vom Typ 1 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.

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

Beim Start des Programms über den Transaktionscode wird in der Laufzeitumgebung ein Prozessor gestartet, der zunächst das Startdynpro 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 Folgedynpro. Jedes Dynpro hat ein statisches oder dynamisches Folgedynpro. Dynpros und ihre Folgedynpros sind die Bestandteile von frei definierbaren Dynprofolgen.
• andere Dynprofolgen, 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 TRANSACTION oder SUBMIT aufrufen.

Da ABAP-Programme mit dem Programmattribut Typ M hauptsächlich Dialogmodule der zugehörigen Dynpros enthalten, bezeichnen wir sie als Modulpool. Die Arbeit mit Modulpools ist bei stark dialogorientierten Programmen mit vielen Dynpros sinnvoll, in denen der Programmablauf weitgehend durch die Ablauflogik von Dynprofolgen definiert wird.

Typ F-Programme können nicht über Transaktionscodes oder Eingabe des Namens gestartet werden, sondern dienen ausschließlich als Container für Funktionsbausteine. Funktionsbausteine sind spezielle Prozeduren im R/3-System, die aus anderen ABAP-Programmen aufgerufen werden können.

Wir bezeichnen Typ F-Programme auch als Funktionsgruppen. Funktionsbausteine dürfen nur in Funktionsgruppen programmiert werden. Zur Erstellung von Funktionsbausteinen und Funktionsgruppen enthält die ABAP Workbench das spezielle Werkzeug Function Builder. Außer Funktionsbausteinen können Funktionsgruppen globale Datendeklarationen und Unterprogramme enthalten, die für alle Funktionsbausteine sichtbar sind.

Wie Programme vom Typ 1 und M können Funktionsgruppen Bildschirme, also eigene Dynpros, Selektionsbilder und Listen enthalten. Die Verarbeitung dieser Bildschirme, d,h. die Reaktion auf Benutzeraktionen in Ereignisblöcken und Dialogmodulen, findet ebenfalls in der Funktionsgruppe statt. Der Aufruf der Bildschirme erfolgt aus den Funktionsbausteinen der Gruppe. Eine Funktionsgruppe mit Bildschirmen und einem einzigen Funktionsbaustein ermöglicht also die Modularisierung von Bildschirmabläufen.

Typ K-Programme können nicht über Transaktionscodes oder Eingabe des Namens gestartet werden, sondern ein Typ K-Programm dient ausschließlich als Container für eine globale Klasse in ABAP Objects. Wir bezeichnen Typ K-Programme als Klassen-Definitionen. Zur Erstellung von Klassen-Definitionen enthält die ABAP Workbench das spezielle Werkzeug Class Builder.

Typ J-Programme können nicht über Transaktionscodes oder Eingabe des Namens gestartet werden, sondern ein Typ J-Programm dient ausschließlich als Container für ein globales Inrterface in ABAP Objects. Wir bezeichnen Typ J-Programme als Interface-Definitionen. Interface-Definitionen werden wie Klassen-Definitionen mit dem Werkzeug Class Builder der ABAP Workbench erstellt.

Typ S-Programme können nicht über Transaktionscodes oder Eingabe des Namens gestartet werden, sondern ein Typ S-Programm dient ausschließlich als Container für Unterprogramme, die extern aus anderen ABAP-Programmen aufgerufen werden können. Wir bezeichnen Typ S-Programme als Subroutinenpool. Subroutinenpools können keine Bildschirme enthalten.

Typ I-Programme sind nicht ausführbar, sondern dienen ausschließlich als Mittel um Programmtexte in kleine editierbare Einheiten zu gliedern. Wir nennen Typ-I Programme Include-Programme. Der Programmtext in Include-Programmen kann über die Anweisung INCLUDE an beliebigen Stellen anderer ABAP-Programm eingefügt 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 Modulpools und Funktionsgruppen auf Include-Programme.