Die besten ABAP-Tricks beim Entwickeln

Du bist ABAP-Entwickler und möchtest die Qualität in Deinen ABAP-Programmen erhöhen? Mit Richtlinien beim Entwickeln kannst Du einfach und schnell die Qualität in Deine Code verbessern. Weniger Fehler und bessere Lesbarkeit erhöhen die Wartbarkeit und erhöhen die Kundenzufriedenheit.

Mit diesem Artikel zeige ich Dir die besten Tipps und Tricks, die jeder ABAP-Entwickler anwenden soll, um seine Qualität beim Programmieren zu erhöhen. Viel Spaß.

Richtige Editoreinstellungen

Im Editor (ABAP Editor) kannst Du viele nützliche Funktionen aktivieren, um Dir das Leben beim täglichen Entwickeln zu erleichtern.

Wenn Du im ABAP Editor (Transaktion SE38) oder in der ABAP Workbench (Transaktion SE80) als Beispiel bist, kannst Du die Editoreinstellungen unter “Hilfsmittel > Einstellungen” erreichen.

Anschließend kannst Du im Reiter “ABAP Editor” die Editoreinstellungen vornehmen. Im Reiter “Editor” darunter nimmst Du allgemeine Einstellungen zum Editor vor. Hier sollte vor allem der “Quellcode-basierte Editor” ausgewählt werden.

Im ABAP-Editor kannst Du verschiedene Editoreinstellungen vornehmen. Mindestens sollte hier die Einstellung "Quellcode-basierter Editor" aktiviert werden.

Der Reiter “Pretty Printer” ist ebenfalls wichtig für eine leichtere Arbeit mit dem ABAP Editor. Der Pretty Printer ist ein Tool, die Du mit dem Button “Pretty Printer” oder der Tastenkombination “Umschalt + F1” ausführen kannst. Durch diese Kombination wird Dein Quellcode gemäß den Einstellungen formatiert. Dadurch erhöhst Du die Lesbarkeit Deines Codes enorm. Vor dem Aktivieren Deines Codes solltest Du deshalb immer den Pretty Printer ausführen.

Beim Pretty Printer ist das “Einrücken” und eine Unterscheidung zwischen Groß- und Kleinschreibung von Vorteil. Hier ist es nützlich, alle Schlüsselwörter “groß” zu schreiben, auch wenn ABAP als Programmiersprache nicht case sensitive ist.

In den Editoreinstellungen kannst Du für den Pretty Printer wichtige Einstellungen vornehmen. "Einrücken" und "Groß-/Kleinschreibung" kannst Du entsprechend vorauswählen.

Der Reiter “Splitscreen” ist weniger relevant und kann mit den Standardeinstellungen belassen werden.

Gerade als Entwickler ist das Debugging und die Fehlersuche eine tagtägliche Arbeit. Teilweise muss man auch RFC- oder Remote-Aufrufe im Debugging testen und dafür einen externen Breakpoint setzen. Dieser wird dann aber vom RFC-Benutzer aufgerufen und nicht vom eigenen SAP-Benutzer. Der RFC-Benutzer kann deshalb im Reiter “Debugging” eingetragen werden.

Beachte aber dabei, dass Du unbedingt nach dem Debuggen erneut Deinen SAP-Benutzer wieder einträgst oder den externen Breakpoints entfernst, da ansonsten jeder externe Aufruf vom externen Breakpoint gestoppt wird und Du den Aufruf fortführen musst.

In den Editoreinstellungen unter "Debugging" kann man den RFC-Benutzer eintragen, um RFC-Aufrufe mit dem RFC-Benutzer zu testen und zu debuggen.

Code-Vorlagen für übersichtliche und vordefinierte Kommentare

Code-Vorlagen – Übersicht und Beispiel

Jeder ABAP-Entwickler sollte mit Code-Vorlagen arbeiten. Das erleichtert Dir ungemein die tägliche Arbeit. Du kannst Dich mehr auf das Programmieren konzentrieren, anstatt typische und gleiche Kommentare immer und immer wieder einzufügen.

Im ABAP Editor erreichst Du ganz unten rechts in Deiner SAP GUI die Code-Vorlagen, wenn Du den entsprechenden Button drückst:

Durch Drücken des Buttons in dem ABAP Editor öffnen sich die Optionen. Hier gibt es den Knoten "Code-Vorlagen" wo Du die Code-Vorlagen definieren und pflegen kannst.

Nach Drücken des Buttons öffnen sich die Optionen. Hier kannst Du einfach den Knoten “Code-Vorlagen” auswählen.

In dem Screenshot siehst Du bereits, dass ich eine Code-Vorlage namens “block” gepflegt habe. Wenn man nun im Quellode die ID der Code-Vorlage schreibt und dann die TAB-Taste betätigt, kann man die Code-Vorlage nutzen. In diesem Beispiel wird noch ein Vorlagenparameter “Beschreibung” verwendet. Das sorgt dafür, dass man in einem PopUp einen Text eingeben kann, der dann gemäß der Code-Vorlage eingefügt wird.

Code-Vorlagen sind einfach und sehr hilfreich bei der ABAP-Entwicklung. Ein Muss für jeden ABAP-Entwickler. Durch Code-Vorlagen kann man einfach schön formatierte Kommentare nutzen.

Dadurch kann man sehr einfach und schnell vordefinierte Kommentare nutzen und muss diese nicht jedes Mal von Neuem erstellen.

Code-Vorlagen im Muster nutzen

Man kann aber anstatt Code-Vorlagen auch Muster benutzen, um einen formatierten Kommentar einfach einzufügen. Unter “Hilfsmittel > Weitere Hilfsmittel > Muster bearbeiten > Muster anlegen” kann man neue Muster anlegen. Dann kann man einfach den Text eingeben, den man einfügen möchte, wenn man dieses Muster aufruft.

Man kann aber anstatt Code-Vorlagen auch Muster benutzen, um einen formatierten Kommentar einfach einzufügen.

Das angelegte Muster kannst Du einfach über “Muster > Anderes Muster” auswählen bzw. aufrufen. Anschließend wird der vordefinierte Text 1:1 eingefügt.

Gerade wenn Deine Code-Vorlagen umfangreicher sind, ergibt es Sinn, die Code-Vorlagen in einem Funktionsbaustein auszulagern.

Namenskonventionen

Um die Lesbarkeit und Wartbarkeit Deines ABAP-Programms enorm zu erhöhen, sollte man unbedingt in Teams sich auf Namenskonventionen einigen. Dadurch wird sofort sichergestellt, wie Variablen, Strukturen, Tabellen, etc. heißen sollten. Sofort erkennt man im Programm selber, um welchen Typ es sich handelt, ohne jedes mal in der Datendeklaration das nachzusehen.

Folgende Präfixe kann man dabei verwenden:

TypLokalGlobalFeldsymbolKlassenattributImport, Export, Return, Change in Fubas
Variablelv_gv_<fv_cviv_, ev_, rv_, cv_
Strukturls_gs_<fs_csis_, es_, rs_, cs_
Tabellentyplt_gt_<ft_ctit_, et_, rt_, ct_
Referenzlr_gr_<fr_crir_, er_, rr_, cr_
Konstantelc_gc_<fc_cc

Bessere Performance in ABAP-Programmen

Schnellerer Zugriff bei internen Tabellen

Bei internen Tabellen sollte man Feldsymbole verwenden anstatt Strukturen. Das hat folgende Vorteile:

  • höhere Performance, da keine unnötigen Daten kopiert werden
  • geringere Fehleranfälligkeit, da die interne Tabelle mit geändert wird, wenn sich das Feldsymbol ändert
LOOP AT lt_test ASSIGNING <ls_test>.
    <ls_test>-value = 'TEST'.
ENDLOOP.

Bei READ TABLE muss man prüfen, ob das Feldsymbol zugewiesen ist, da ansonsten eine Excpetion geworfen wird, die das Programm abstürzen lässt.

READ TABLE lt_test WITH KEY id = '1' ASSIGNING <ls_test>.
IF sy-subrc = 0.
" Zugriff auf das Feldsymbol <ls_test>
ENDIF.

Zugriff auf Datenbank

Das Verhalten und die Performance des Systems hängt davon ab wie viel Last auf der Datenbank entsteht, wie viele Daten zwischen der Datenbank und dem Applikationsserver übertragen werden müssen und letztlich auch wie viel Last auf dem Application Server selbst entsteht. Für diese Grüne ist es ratsam, die Anfragen auf die Datenbank so selten wie möglich ausführen zu lassen und auch nur die Daten abzufragen, die man wirklich benötigt.

Nur Daten lesen, die man wirklich benötigt

Beispiel für schlechten Code:

SELECT * FROM SPFLI INTO ls_spfli.
WRITE: / ls_spfli-carrid.
ENDSELECT.

Beispiel für besseren Code:

SELECT carrid FROM SPFLI INTO ls_spfli-spfli.
WRITE: / ls_spfli-carrid.
ENDSELECT. 

Vollständigen Schlüssel angeben

Beispiel für schlechten Code:

SELECT * FROM sflight INTO ls_sflight WHERE connid = '1234'.

Beispiel für besseren Code:

SELECT * FROM sflight INTO ls_sflight WHERE carrid = 'LH' AND connid = '1234'.

Wiederholter, einzelne Zugriffe vermeiden

Beispiel für schlechten Code:

SELECT SINGLE * FROM SPFLI INTO ls_spfli WHERE CARRID='LH' AND
CONNID='1234'.

SELECT SINGLE * FROM SPFLI INTO ls_spfli WHERE CARRID='LH' AND
CONNID='1235'.

SELECT SINGLE * FROM SPFLI INTO ls_spfli WHERE CARRID='LH' AND
CONNID='1236'.

Beispiel für besseren Code:

SELECT * FROM SPFLI INTO ... WHERE CARRID='LH'.

ENDSELECT.

Joins verwenden anstatt geschachtelter SELECTs

Beispiel für schlechten Code:

SELECT feld1 FROM tabelle1 INTO wa.
    SELECT feld2 FROM tabelle2 INTO wa2 WHERE feld2 = wa-feld1

    ENDSELECT.
ENDSELECT.

Beispiel für besseren Code:

SELECT feld1 feld2 FROM tabelle1 INNER JOIN tabelle2 ON tabelle1-feld1 = tabelle2-feld2.

ENDSELECT.

WHERE-Bedingungen, BETWEEN und LIKE

Bei WHERE-Bedingungen sollte man niemals negative Formulierungen wie z.B. “<>” oder “NOT” verwenden. Der Datenbank-Optimizer kann hier nicht mehr eingreifen und wird deshalb immer einen Full Table Scan durchführen. Das sorgt für Performanceeinbußen.

BETWEEN sollte ebenfalls nicht mehr verwendet werden. Stattdessen lieber “IN” benutzen.

Versuche stets bei Zugriffen auf die Datenbank den LIKE-Operator zu vermeiden. Das ist einerseits keine eindeutige Suche und kann die Performance verschlechtern.

Nützliche Transaktionen für die Analyse

Ich habe einmal alle nützlichen Transaktionscodes notiert, die jeder ABAP-Entwickler kennen und einsetzen sollte. Diese sind für die tägliche Arbeit von enormen Nutzen.

TransaktionscodeBeschreibung
CODE_SCANNERABAP Suche
SCICode Inspector
ATCABAP Test Cockpit
SM12Datenbanksperren lösen
DB13Jobs DBA-Einplanungskalender
DB02Datenbankanalyse
SM50Übersicht über Workprozesse
ST05SQL Performance-Trace
SM51Instanz-Prozessübersicht
ST02Tune Summary
ST04DB Performance
SE30Laufzeitanalyse
ST03NSystemlastmonitor
STADSAP Workload Monitor
ST06System-Monitor
RZ11Dokumentation Profilparameter
DB05Selektivanalyse der DB-Tabellen

Aktuelle ABAP-Syntax vermeiden

Verwende nicht die aktuelle ABAP-Syntax. Das klingt im ersten Moment konfus, kann Dir aber in Zukunft sehr viel Ärger ersparen. Warum sollte man nicht die aktuelle ABAP-Syntax wie z.B. Inline-Deklaration oder neuen Select-Statements nicht verwenden? Die Antwort ist einfach und simpel: Weil Deine Kunden nicht alle die gleiche ABAP-Version haben und es deshalb zu Problemen kommen kann.

Wenn Du natürlich exklusiv für einen Kunden oder ein Unternehmen entwickelst, dann sollte natürlich auch die aktuelle Syntax verwendet werden. Wenn Du Consultant oder Dienstleister bist, tunlichst nicht.

Oft nehmen Kolleginnen und Kollegen Deine Programmierung als Kopiervorlage. Das kann beim Ausliefern an den Kunden Probleme verursachen.

Beispiele für neue Syntax für ABAP in der Version >= 7.4

SELECT matnr, bukrs
  FROM ekpo
  WHERE ebeln IN selcrit
  AND   ebelp = ebelp
  INTO TABLE @DATA(lt_ekpo).
LOOP AT lt_ekpo ASSIGNING FIELD-SYMBOL(<ls_ekpo>).

ENDLOOP

Eine Übersicht über die aktuelle ABAP-Syntax findest Du unter help.sap.com.

Eindeutige Benamung in Transporten

Egal ob Customizing-, Workbenchtransporte oder Transporte von Kopien: Achte auf eine einheitliche Benamung und halte die Namenskonvention im Unternehmen ein.

Dabei eignet sich z.B. folgende Konvention:

<Projektkürzel> ddMMyyyy XxXx (T) <Beschreibung>

KonventionBeschreibungBeispiel
<Projektkürzel>Wort, Kürzel oder kurze Beschreibung vom Projekt für das der Transport erstellt wird.FI_2020
ddMMyyyyTag, Monat und Jahr der Erstellung15092020
XxXxZwei Buchstaben des Vornamen und zwei Buchstaben des NachnamenAnGe
TBuchstabe für Art des Transports
C = Customizing-Transport
W = Workbench-Transport
T = Transport von Kopien
L = Lokaler Transport
C
<Beschreibung>Beschreibung was in dem Transport enthalten istAnpassung Kostenstelle für Kontierung

Insgesamt könnte also eine Bezeichnung für einen Beispiel-Transport folgendermaßen sein:

FI_2020 15092020 AnGe (C) Anpassung Kostenstelle für Kontierung

Über den Autor

Schön, dass Du Dich für SAP ERP interessierst.

Mein Name ist Andreas Geiger und ich bin der Gründer von ERP-UP.de. Mein Ziel ist es, so viel nützliches Wissen wie möglich über das SAP ERP-System zu vermitteln. Ich möchte Dir damit einen Mehrwert bieten. Es freut mich, wenn ich Dir damit helfen kann.

Mehr zu ERP UP

Schreibe einen Kommentar