ABAP

ABAP ist eine proprietäre Programmiersprache der Softwarefirma SAP, die für die Programmierung kommerzieller Anwendungen im SAP-Umfeld entwickelt wurde und ähnelt in ihrer Grundstruktur der Programmiersprache COBOL.

Ursprünglich stand die Abkürzung für „Allgemeiner Berichts-Anwendungs-Prozessor“, da mit dieser Sprache nur kundenspezifische Auswertungen programmiert werden, aber keine Datenbankveränderungen vorgenommen werden konnten. Im Zuge der Weiterentwicklungen der Sprache steht die Abkürzung nun für „Advanced Business Application Programming“. Der Sprachumfang ist nicht fest definiert und wurde in der Vergangenheit immer wieder erweitert, z. B. um die objektorientierten Sprachbefehle von ABAP Objects.

Seit 1990 basieren alle SAP R/3-Module auf ABAP, das aus dem Vorgänger SAP R/2 übernommen wurde. Seit der Einführung von SAP NetWeaver bietet die SAP neben ABAP auch eine Ablauf- und Programmierumgebung für Java, und dementsprechend einen ABAP-basierten und einen Java-basierten Applikationsserver an (siehe SAP NetWeaver Application Server).

Eigenschaften

ABAP ist eine 4GL-Sprache, die speziell für die Massendatenverarbeitung in kommerziellen Anwendungen entwickelt wurde, und bietet u. a. folgende Vorteile gegenüber elementareren Sprachen, in denen solche Funktionen in Bibliotheken liegen:

• Als Open SQL in die Sprache integrierter Datenbankzugriff
• In die ABAP-Laufzeitumgebung integrierte Performance-Optimierung von Datenbankzugriffen über die SAP-Pufferung
• Interne Tabellen für die dynamische Speicherung und Bearbeitung von tabellarischen Massendaten im Arbeitsspeicher
• In die ABAP-Laufzeitumgebung integriertes Konzept des Online Transaction Processing (OLTP), bei dem viele Benutzer gleichzeitig auf die zentrale Datenbank zugreifen
• In die Sprache integrierte Schnittstelle zu anderen Programmierumgebungen über Remote Function Call
• In die Sprache integrierte Schnittstelle zu XML

Die Integration solcher Funktionen in die Sprache ist im wesentlichen vorteilhaft für die statische Überprüfbarkeit und die Ausführungsgeschwindigkeit von Programmen. Im Gegenzug enthält ABAP dadurch auch wesentlich mehr Sprachelemente als andere Programmiersprachen.

ABAP unterstützt ein auf Unterprogrammen und Funktionsbausteinen basierendes, prozedurales und ab Release 6.10 ein auf Klassen und Interfaces basierendes, objektorientiertes Programmiermodell. Beide Modelle sind interoperabel.

ABAP Workbench

Die Programmierung in ABAP wird durch eine Entwicklungsumgebung unterstützt, die darauf ausgerichtet ist, große Projekte mit mehreren (hunderten) Entwicklern zu ermöglichen. Hierbei muss zu jeder Zeit ein lauffähiges System gewährleistet bleiben. Dazu werden die geänderten Objekte auf sog. Transportaufträgen erfasst, welche bei Freigabe auf das Dateisystem exportiert werden und in Folgesysteme importiert werden können. Durch diesen Mechanismus kann die Entwicklung der Programme von ihrem produktiven Einsatz getrennt erfolgen.

Die Entwicklungsumgebung zur Programmiersprache ABAP ist die ABAP Workbench. In der ABAP Workbench (Einstieg über den sogenannten Object Navigator, Transaktion SE80) können jedoch auch andere Objekte wie z. B. BSP (Business Server Pages, mit HTML-Anteilen) bearbeitet werden.

Das Besondere ist die sogenannte „Vorwärtsnavigation“. So führt ein Doppelklick auf einen Tabellennamen direkt zur Definition der Datenbanktabelle im ABAP-Dictionary, wohingegen Doppelklick auf einen Methodennamen direkt in diese Methode führt.

Die ABAP-Workbench wird mit der Zeit an die Anforderungen moderner Software-Entwicklung angepasst. Seit dem letzten Release wird beispielsweise auch Syntax-Highlighting unterstützt.

Codebeispiele für R/3 Versionen >= 4.7 SR 1

Vollständiges Programm

Das nachfolgende Programm gibt den Inhalt der Tabelle TSTC (enthält SAP-Transaktionscodes) aus.

 REPORT ztest.
 CLASS demo DEFINITION.
   PUBLIC SECTION.
     CLASS-METHODS main.
 ENDCLASS.
 CLASS demo IMPLEMENTATION.
   METHOD main.
     DATA tstc_tab TYPE TABLE OF tstc.
     DATA alv      TYPE REF TO cl_salv_table.
     DATA exc      TYPE REF TO cx_salv_msg.
     SELECT *
            FROM tstc
            INTO TABLE tstc_tab.
     TRY.
         cl_salv_table=>factory(
           IMPORTING r_salv_table = alv
           CHANGING t_table = tstc_tab ).
         alv->display( ).
       CATCH cx_salv_msg into exc.
         MESSAGE exc TYPE 'I'
           DISPLAY LIKE 'E'.
     ENDTRY.
   ENDMETHOD.
 ENDCLASS.
 START-OF-SELECTION.
   demo=>main( ).

• REPORT ZTEST. Beschreibt den Typ (REPORT) und den Namen (ztest) des Programms. Der Name richtet sich nach den Namenraumskonventionen, die besagen, dass kundeneigene (also nicht von SAP stammende) Programme in reservierten Namensräumen liegen müssen. Z* und Y* sind die bekanntesten solchen Namensräume für Reports.
• CLASS demo DEFINITION ... ENDCLASS. Deklarationsteil einer Klasse demo.
• CLASS-METHODS main. Deklaration einer statischen Methode main.
• CLASS demo IMPLEMENTATION ... ENDCLASS. Implementierungsteil einer Klasse demo mit Methodenimplementierung METHOD ... ENDMETHOD
• DATA tstc_tab TYPE TABLE OF tstc. Diese Anweisung definiert eine interne Tabelle tstc_tab, deren Zeilentyp die Struktur einer Zeile der Datenbanktabelle TSTC hat.
• DATA alv TYPE REF TO cl_salv_table. Diese Anweisung definiert eine Referenzvariable für ein List-Viewer-Objekt.
• DATA exc TYPE REF TO cx_salv_msg. Diese Anweisung definiert eine Referenzvariable für ein Ausnahmeobjekt.
• SELECT * FROM tstc INTO TABLE tstc_tab. Diese Anweisung liest alle Daten der Datenbanktabelle tstc in die interne Tabelle tstc_tab. Der Stern indiziert, dass alle Spalten der Datenbanktabelle in die interne Tabelle geschrieben werden sollen.
• TRY ... CATCH ... ENDTRY. Ausnahmebehandlung (Verfügbar seit Version 4.7 SR1).
• cl_salv_table=>factory( ... ). Erzeugung eines List-Viewers für die interne Tabelle.
• alv->display( ). Aufruf der Methode display des List-Viewers.
• START-OF-SELECTION. Einleitung eines Ereignisblockes (dient hier als Einstiegspunkt)
• demo=>main( )Aufruf der Methode main der Klasse demo.

Datenstrukturen

Hier ein weiteres:

• Definition 2 kurzer Feldleisten.

REPORT  YTEST1.
TYPES: BEGIN OF trec1,
  f11,
  f12,
  f13,
END OF trec1.

TYPES: BEGIN OF trec2,
  f21,
  f22,
  f23,
END OF trec2.

• wie die beiden Typen benutzt werden sollen (innerhalb der Feldleiste rec1),Strukturnamen (a/b)

DATA: BEGIN OF rec1.
 INCLUDE TYPE trec1 AS a.
 INCLUDE TYPE trec2 AS b.
DATA: END OF rec1.

• Deklaration 2ter Feldleiste, die aber 2x trec1 includiert.
• Renaming: dass durch Anfügen der Zeichenkette low u high trotzdem eindeutige Feldnamen entstehen.

DATA: BEGIN OF rec2.
 INCLUDE TYPE trec1 AS a RENAMING WITH SUFFIX low.
 INCLUDE TYPE trec1 AS b RENAMING WITH SUFFIX high.
DATA: END OF rec2.

• unterschiedliche Zugriffsmöglichkeiten auf die Teilfelder!
• Nachweis, dass durch INCLUDE Anweisung flache Struktur entsteht.

rec1-f11     = '1'.
rec1-f21     = '4'.

• Name der Substruktur wird benutzt, um auf Teilfelder zuzugreifen
• Strukturnamen a&b ist Zugriff auf 3 Felder jeder Substruktur möglich.

rec1-a-f12   = '2'.
rec1-b-f22   = '5'.

• Zeigen möglichen Einsatzzweck für die Substrukturnamen. Nur einfacher Zugriff auf Teilmenge der Struktur möglich.

WRITE: / '1. ',rec1.
WRITE: / '2. ',rec1-a.
WRITE: / '3. ',rec1-b.

• RENAMING erstellt Feldleiste, in deren flacher Darstellung die Namen der Teilfelder durch ein
• Suffix eindeutig getrennt werden. (32 bis 35 zeigen das) Wird aber unter Verwendung der Strukturnamen
• auf Teilfelder zugegriffen, gelten die alten Namen ohne Suffix.

rec2-f11low   = 'A'.
rec2-f13low   = 'C'.
rec2-f11high  = 'D'.
rec2-f13high  = 'F'.
rec2-a-f12    = 'B'.
rec2-b-f12    = 'E'.
WRITE: / '4.', rec2.

• Bei M-C sind Feldnamen relevant (von rec1 zu rec2). Es wird nur der Name der Struktur benutzt.
• Also verwendet M-C die flache Struktur. In dieser Sichtweise sind die Namen der Teilfelder durch
• anfügen der Suffixe in rec2 unterschiedlich, es findet keine Übertragung von Feldinhalten statt.
• Das ändert sich wenn durch Verwendung der Strukturnamen die ursprünglichen Feldnamen sichtbar sind.
• Dann wäre so wie hier eine Zuweisung der Teilfelder f11 bis f13 möglich.

CLEAR rec2.
MOVE-CORRESPONDING rec1 TO rec2.
WRITE: / '5.',rec2.

CLEAR rec2.
MOVE-CORRESPONDING rec1 TO rec2-a.
MOVE-CORRESPONDING rec1 TO rec2-b.
WRITE: / '6.',rec2.

ABAP Objects

Unter ABAP Objects versteht man die objektorientierten Erweiterungen der Programmiersprache ABAP. Sie implementiert sämtliche Elemente der objektorientierten Programmierung (OOP) mit Ausnahme von Mehrfachvererbung und dem Überladen von Methoden. Interfaces sowie optionale Parameter werden unterstützt. Mit speziellen RTTI-Klassen ist auch reflektive Programmierung möglich, ab der Version 6.40 sogar (eingeschränkt) die dynamische Erzeugung neuer Typen.

ABAP Objects ist ab SAP Release 4.6 verfügbar und wird seitdem beständig weiterentwickelt und z. B. durch Object-Services ergänzt. Die objektorientierten Sprachelemente sind Voraussetzung für die Entwicklung von modernen Benutzeroberflächen mit Controls sowie für die Realisierung von Webanwendungen und XML-Services in ABAP. Große Teile der ABAP Workbench selbst sind objektorientiert in ABAP Objects implementiert.

ABAP Objects schränkt den Sprachumfang von "klassischem" ABAP in einigen Punkten ein. So sind zum Beispiel interne Tabellen mit Kopfzeilen im Kontext von ABAP Objects nicht mehr erlaubt.

Web Dynpro

Seit SAP NetWeaver 7.0 gibt es mit WebDynpro für ABAP auch die Möglichkeit Web-Applikationen in ABAP zu entwickeln. WebDynpro ABAP basiert auf der Web Dynpro-Technologie. Ursprünglich wollte SAP diese Technologie nur für die Programmiersprache Java (ab NetWeaver 6.40) zur Verfügung stellen. Aufgrund von Kundenanfragen (fehlendes Java-Know-how bei ABAP-Entwicklern bzw. fehlendes SAP-Know-how bei Java-Entwicklern) entschied sich SAP diese Technologie in ABAP zu integrieren.

Kritik

Allgemein

Die Vielzahl der möglichen ABAP-Anweisungen und Ihrer Varianten führt allgemein zu einem schwerer verständlichen Quellcode als in anderen gängigen Programmiersprachen.

• Zuweisungen: So existiert zum Beispiel neben einer mathematischen Form der Zuweisung „variable = 18 / 3.“ auch die cobol-ähnliche Notation „MOVE 18 / 3 TO variable“. Auch für andere Aufgaben gibt es mehrere mögliche Notationen.

• Signifikanz von Leerzeichen: Unterschied zwischen '+' und ' +' (Plus und Blank-Plus)

Beispiel:

DATA myvar(3) TYPE N VALUE '123'..

'myvar+1' (ohne Leerzeichen) ergibt '23' (Offset einer Zeichenkette), 'myvar + 1' (mit Leerzeichen) ergibt '124' (Addition).

Diese ähnliche Schreibweise für sehr unterschiedlich wirkende Operationen ist eine potenzielle Fehlerquelle.

• Wenngleich auch in ABAP gängige Entwurfsmuster implementiert werden können, führt der meist betriebswirtschaftliche Hintergrund von ABAP-Entwicklern zu eher unübersichtlichen, monolithischen Code-Blöcken. Moderne Aspekte der Software-Technik wie Schichtenarchitektur, Kapselung oder Programmierung gegen Schnittstellen finden in ABAP häufig nicht die notwendige Berücksichtigung.

Vor Release 7.1

Insbesondere vor Release 7.1 sind Details erkennbar, die den Umgang mit der Sprache erschweren.

• Ausdrücke wurden nur bei Zuweisung zu einer Variablen ausgewertet, aber weder in einer IF-Bedingung noch in einer WRITE-Anweisung noch bei der Parameterübergabe an eine Funktion.

Beispiel: IF A * B < 15. muss ersetzt werden durch DATA C TYPE xxx. C = A * B. IF C < 15..

• Das Ergebnis eines Funktionsaufrufes ist nicht unmittelbar in einem Ausdruck verwendbar.

Seit Release 7.1

Mit Netweaver 7.1 sind eine Reihe von Vereinfachungen der Sprache, insbesondere verkettete Ausdrücke, verfügbar.

Beispiel: IF A * B < 15.

Beispiel: IF X->NEXT( )->NEXT( )->GET_RESULT( Y->GET_TYPE( ) ) > 20.

Dieser Artikel basiert auf dem Artikel ABAP aus der freien Enzyklopädie Wikipedia und steht unter der GNU Lizenz für freie Dokumentation. In der Wikipedia ist eine Liste der Autoren verfügbar, dort kann man den Artikel bearbeiten.