3 ABAP-spezifische Grundregeln - EDV-BUCHVERSAND

43

»Ach, wenn Du erfahren wolltest, wie ich Dich liebe, so müßtest Du mir eine neue Sprache schenken.«– Friedrich Schiller

3 ABAP-spezifische Grundregeln

Neben den in Kapitel 2, »Allgemeine Grundregeln«, aufgeführten Regeln füh-ren wir in diesem Kapitel zusätzlich einen Satz ABAP-spezifischer Grundregelnein, die sich aus speziellen technischen Gegebenheiten der Sprache ABAP, derABAP-Laufzeitumgebung und ihrer Historie ergeben. Auch diese Grundregelnbestimmen viele der auf dieses Kapitel folgenden spezielleren Regeln.

3.1 ABAP Objects als Programmiermodell

Hintergrund

ABAP ist eine hybride Programmiersprache, die sowohl ein prozedurales alsauch ein objektorientiertes Programmiermodell unterstützt. Das prozeduraleProgrammiermodell beruht auf der Modularisierung von Programmen in dieklassischen Verarbeitungsblöcke, das heißt Ereignisblöcke, Dialogmodule,Funktionsbausteine und Unterprogramme. In ABAP Objects tritt die Klassekonzeptionell an die Stelle des klassischen Programms,1 und die Modularisie-rung erfolgt durch deren Methoden.

Beide Modelle sind in der Weise interoperabel, dass in klassischen Verarbei-tungsblöcken auf Klassen zugegriffen werden kann und innerhalb von Metho-den wiederum klassische Programme und Prozeduren aufgerufen werdenkönnen. Der hybride Charakter der Sprache ist in erster Linie der Abwärtskom-patibilität geschuldet, da ABAP prozedurale Wurzeln hat und sowohl ganzeProgramme als auch wiederverwendbare Prozeduren (in erster Linie Funk-tionsbausteine) mit Einführung des objektorientierten ProgrammiermodellsEnde der 1990er-Jahre weiterhin nutzbar bleiben sollten.

1 Technisch gesehen sind Klassen nach wie vor in Programmen deklariert und implementiert.

1286.book Seite 43 Donnerstag, 30. April 2009 12:06 12

ABAP-spezifische Grundregeln3

44

Regel

Details

Die Forderung nach der Trennung der Belange (siehe Regel 2.1) wird am bestendurch eine weitestgehende Verwendung von ABAP Objects unterstützt. Einedetaillierte Gegenüberstellung von ABAP Objects und dem prozeduralen Pro-grammiermodell ist nicht Gegenstand dieses Buches. Dass die objektorientierteProgrammierung – und hier insbesondere ABAP Objects im Vergleich zumklassischen prozeduralen ABAP – besser geeignet ist, die Anforderungen zeit-gemäßer Programmierung zu erfüllen, wurde unter anderem in einem Beitragim SAP Professional Journal (Not Yet Using ABAP Objects? – Eight Reasons whyevery ABAP Developer Should Give It a Second Look) dargelegt. Die dort genann-ten acht Gründe, ABAP Objects zu verwenden, lauten zusammengefasst wiefolgt:

1. DatenkapselungABAP Objects ermöglicht eine fortgeschrittene Art der Datenkapselung. Beider klassischen prozeduralen Programmierung wird der Zustand einerAnwendung durch den Inhalt von globalen Variablen bestimmt. In derobjektorientierten Programmierung ist der Zustand in Klassen oder Objek-ten als Instanzen von Klassen gekapselt. Die Aufteilung der Daten in die ver-schiedenen Sichtbarkeitsbereiche einer Klasse – öffentlich, geschützt, paket-sichtbar (ab Release 7.2) und privat – sorgt für eine klare Unterscheidungzwischen extern und intern verwendbaren Daten. Selbst ohne eine tiefgehende objektorientierte Modellierung profitieren Anwendungspro-gramme hinsichtlich Robustheit und Wartbarkeit von diesen Eigenschaften.

2. Explizite InstanzierungABAP Objects ermöglicht die mehrfache Instanzierung einer Klasse über ex-plizite Objekterzeugung mittels der Anweisung CREATE OBJECT. Jede Instanzeiner Klasse (Objekt) hat einen eigenen Zustand, der durch die Werte ihrerAttribute festgelegt wird und über die Methoden der Klassen geändert wer-den kann. Eine automatische Garbage Collection sorgt dafür, dass Objekte,die nicht mehr benötigt werden, aus dem Speicher gelöscht werden. Im pro-

Regel 3.1: ABAP Objects verwenden

Verwenden Sie bei der Neu- und Weiterentwicklung so weit wie möglich ABAP Ob-jects. Klassische Verarbeitungsblöcke dürfen nur noch in Ausnahmefällen neu ange-legt werden.


ABAP Objects als Programmiermodell 3.1

45

zeduralen Modell gibt es keine Mehrfachinstanzierung, weshalb dort mit zu-standslosen Funktionen auf getrennt abgelegten Daten gearbeitet werdenmuss.

3. VererbungABAP Objects ermöglicht die Wiederverwendung von Klassen durch Verer-bung, wobei Klassen mit speziellen Verhaltensweisen von allgemeinerenKlassen abgeleitet werden und nur die Unterschiede neu implementiert wer-den müssen. Im prozeduralen Modell können vorhandene Funktionen nurgenauso verwendet werden, wie sie sind, oder es müssen neue angelegt wer-den.

4. InterfacesIn ABAP Objects können Objekte über eigenständige Interfaces ansprochenwerden. Dies befreit Entwickler davon, sich um Implementierungsdetailsder hinter dem Interface liegenden Klasse kümmern zu müssen. Dadurchkann der Anbieter eines Interface die dahinterliegenden Implementierun-gen ändern, ohne dass die Programme, die das Interface verwenden, modi-fiziert werden müssen. Im prozeduralen Modell gibt es kein solches Konzepteigenständiger Interfaces.

5. EreignisseABAP Objects erleichtert die Implementierung ereignisgetriebener Pro-grammabläufe. Anwendungen können über einen Publish-and-Subscribe-Mechanismus lose gekoppelt werden, wobei der Auslöser eines Ereignissesnichts über eventuelle Behandler wissen muss. Dies erlaubt größere Flexibi-lität im Vergleich zum prozeduralen Ansatz, bei dem Programme stärker ge-koppelt sind und der Programmablauf in der Regel viel starrer vorgegebenist.

6. Explizite orthogonale KonzepteIn ABAP Objects gibt es eine kleine Anzahl genau definierter fundamentalerund zueinander orthogonaler Konzepte, die es zuverlässiger und wenigerfehleranfällig als das klassische ABAP machen. Im klassischen prozeduralenABAP dominieren implizite Verhaltensweisen, in denen Programme durchimplizite Ereignisse der Laufzeitumgebung und über globale Daten gesteuertwerden. Die Konzepte von ABAP Objects werden dagegen in einem Pro-gramm explizit wiedergegeben. ABAP Objects ist damit im Vergleich zumklassischen prozeduralen ABAP einfacher erlern- und anwendbar.

7. Bereinigte SyntaxIn ABAP Objects gelten bereinigte Syntax- und Semantikregeln. Das klassi-sche prozedurale ABAP ist eine evolutionär gewachsene Sprache mit vielenobsoleten und sich überschneidenden Konzepten. Mit Einführung vonABAP Objects bot sich mit Klassen und Methoden ein Feld für bereinigte



46

Syntax- und Semantikregeln, das von Anforderungen an die Abwärtskompa-tibilität völlig unbelastet war. Auf diese Weise konnten in ABAP Objects, dasheißt innerhalb von Klassen und Methoden, die meisten obsoleten und feh-leranfälligen Sprachkonstrukte syntaktisch verboten werden. Zusätzlichwerden fragwürdige und potenziell fehlerhafte Zugriffe auf Daten schärferüberprüft und gegebenenfalls ebenso verboten. Die Syntaxbereinigung er-zwingt in Klassen eine Verwendung der Sprache ABAP, wie sie außerhalbvon Klassen nur durch Richtlinien gefordert werden kann (siehe Abschnitt3.3, »Modernes ABAP«).

8. Zugang zu neuen TechnologienABAP Objects ist oft der einzige Weg, um mit neuen ABAP-Technologienumzugehen. Beispielsweise bieten GUI Controls, Web Dynpro ABAP, RunTime Type Services (RTTS) oder das Internet Connection Framework (ICF)ausschließlich klassenbasierte Schnittstellen an. Wenn Programme, die sol-che Services verwenden, weiterhin rein prozedural implementiert würden,käme es zu einer unnötigen Vermischung der Programmiermodelle mit ent-sprechender Erhöhung der Komplexität.

Die dringende Empfehlung zur Verwendung von ABAP Objects hat somitsowohl inhaltliche als auch formale Aspekte:

� Wie in den Punkten 1 bis 5 aufgeführt, ist das objektorientierte Program-miermodell inhaltlich besser geeignet, die Komplexität von Software durchPrinzipien wie Kapselung und Vererbung beherrschbar zu halten. Zugegebe-nermaßen ist gutes objektorientiertes Design keine leichte Aufgabe, undauch heute noch gibt es Entwickler mit wenig Erfahrung auf diesem Gebiet.Wer vor diesem Hintergrund immer noch mit dem Gedanken spielt, eineNeuentwicklung in klassischer prozeduraler Manier anzugehen, muss sichjedoch vergegenwärtigen, dass auch das prozedurale ereignisgesteuerteABAP-Programmiermodell mit seinen Systemereignissen nicht leicht zudurchschauen ist.

� Die Punkte 6 bis 8 beschreiben eher formale Aspekte. Die dort aufgeführtenGründe sprechen dafür, Prozeduren heute nur noch in Form von Methodenanzulegen, selbst in Abwesenheit eines echten objektorientierten Designs.Funktionsbausteine und Unterprogramme sollen nur noch in den Ausnah-mefällen angelegt werden, in denen ABAP Objects bisher keine Alternativebietet.

Hinweise und Empfehlungen zum erfolgreichen Einsatz von ABAP Objects lie-fert Abschnitt 5.1, »Objektorientierte Programmierung«.



47

Ausnahme

Im derzeitigen Zustand (Releases 7.0 EhP2 und 7.2) fehlen in ABAP Objectsnoch folgende Eigenschaften, um klassische Verarbeitungsblöcke vollständigdurch Methoden zu ersetzen:

� Remote Method Invocation (RMI) als Ersatz für den Remote Function Call(RFC)

� ein Ersatz für den Aufruf von Verbuchungsfunktionsbausteinen (CALLFUNCTION IN UPDATE TASK)

� ein Ersatz für den Aufruf von Unterprogrammen bei COMMIT WORK undROLLBACK WORK (PERFORM ON COMMIT/ROLLBACK)

� objektorientierte Behandlung von klassischen Dynpros inklusive Selektions-bildern als Ersatz für Dialogtransaktionen, CALL SCREEN und CALL

SELECTION-SCREEN

� dynamische Erzeugung von Klassen als Ersatz für die klassische dynamischeProgrammerzeugung (GENERATE SUBROUTINE POOL)

� direkte Unterstützung der Hintergrundverarbeitung als Ersatz für den Auf-ruf ausführbarer Programme (SUBMIT VIA JOB)

Genau für diese Fälle dürfen in neuen Programmen noch folgende klassischeVerarbeitungsblöcke angelegt werden:

� Funktionsbausteine werden noch für RFC und die Verbuchung benötigt undfür den Aufruf von klassischen Dynpros und Selektionsbildern empfohlen(siehe Regel 5.19).

� Unterprogramme werden noch für PERFORM ON COMMIT/ROLLBACK und indynamisch generierten Subroutinen-Pools (GENERATE SUBROUTINE POOL)benötigt.

� Dialogmodule und Ereignisblöcke für Selektionsbildereignisse werden nochin Funktionsgruppen benötigt, die klassische Dynpros und Selektionsbilderverschalen (siehe Regel 3.2).

� Der Ereignisblock START-OF-SELECTION wird noch in ausführbaren Program-men benötigt, die für die Hintergrundverarbeitung vorgesehen sind.

Innerhalb eines solchen Verarbeitungsblocks soll die Ausführung dann jedochsofort an eine geeignete Methode delegiert werden (siehe Regel 6.37, »KeineImplementierungen in Funktionsbausteinen und Unterprogrammen« undRegel 6.44, »Keine Implementierungen in Dialogmodulen und Ereignisblö-cken«). Diese muss keine Methode einer globalen Klasse sein, sondern kanndurchaus im Rahmen einer lokalen Klasse innerhalb des zugehörigen Rahmen-



48

programms angesiedelt sein. Damit auch in solchen Verarbeitungsblöcken diegleiche strengere Prüfung wie in Methoden durchgeführt wird, kann in dererweiterten Programmprüfung (siehe Abschnitt 3.4.2, »Erweiterte Programm-prüfung«) die Prüfung Veraltete Anweisungen (OO-Kontext) eingeschaltetwerden.

Schlechtes Beispiel

Listing 3.1 enthält eine ansatzweise Implementierung der Behandlung von ver-schiedenen Arten von Bankkonten in einer Funktionsgruppe und deren Ver-wendung in einem Programm, wobei nur die Funktion »Abheben einesBetrags« gezeigt wird. Die Funktionsbausteine der Funktionsgruppe arbeitenauf externen Daten, die hier beim Ereignis LOAD-OF-PROGRAM in eine globaleinterne Tabelle geladen werden. Die Steuerung, ob mit einem Giro- oder Spar-konto umgegangen wird, erfolgt über einen Eingabeparameter, und die unter-schiedliche Behandlung wird über eine CASE-WHEN-Kontrollstruktur an unter-schiedliche Unterprogramme delegiert, wobei keine Wiederverwendungstattfindet. Die Unterprogramme greifen auf die globale interne Tabelle zu. Ineinem Anwendungsprogramm wird der Funktionsbaustein zum Abheben fürverschiedene Konten aufgerufen. Die Ausnahmebehandlung erfolgt klassischmit weiteren CASE-WHEN-Kontrollstrukturen für die Abfrage von sy-subrc.

FUNCTION-POOL account.

DATA account_tab TYPE SORTED TABLE OF accountsWITH UNIQUE KEY id.

LOAD-OF-PROGRAM."fetch amount for all accounts into account_tab...

...

FUNCTION withdraw.*"-----------------------------------------------------*" IMPORTING*" REFERENCE(id) TYPE accounts-id*" REFERENCE(kind) TYPE c DEFAULT 'C'*" REFERENCE(amount) TYPE accounts-amount*" EXCEPTIONS*" negative_amount*" unknown_account_type*"------------------------------------------------------

CASE kind.WHEN 'C'.

PERFORM withdraw_from_checking_account



49

USING id amount.WHEN 'S'.PERFORM withdraw_from_savings_account

USING id amount.WHEN OTHERS.RAISE unknown_account_type.

ENDCASE.ENDFUNCTION.

FORM withdraw_from_checking_accountUSING l_id TYPE accounts-id

l_amount TYPE accounts-amount.FIELD-SYMBOLS <account> TYPE accounts.READ TABLE account_tab ASSIGNING <account>

WITH TABLE KEY id = l_id.<account> = <account> - l_amount.IF <account> < 0.

"Handle debit balance...

ENDIF.ENDFORM.

FORM withdraw_from_savings_accountUSING l_id TYPE accounts-id

l_amount TYPE accounts-amount.FIELD-SYMBOLS <account> TYPE accounts.READ TABLE account_tab ASSIGNING <account>

WITH TABLE KEY id = l_id.IF <account>_wa-amount > l_amount.

<account>-amount = <account>-amount - l_amount.ELSE.

RAISE negative_amount.ENDIF.

ENDFORM.

*********************************************************

PROGRAM bank_application.

...

CALL FUNCTION 'WITHDRAW'EXPORTING

id = ...kind = 'C'amount = ...

EXCEPTIONSunknown_account_type = 2negative_amount = 4.



50

CASE sy-subrc.WHEN 2.

...WHEN 4.

...ENDCASE.

...

CALL FUNCTION 'WITHDRAW'EXPORTING

id = ...kind = 'S'amount = ...

EXCEPTIONSunknown_account_type = 2negative_amount = 4.

CASE sy-subrc.WHEN 2.

...WHEN 4.

...ENDCASE.

Listing 3.1 Modellierung von Bankkonten in Funktionsgruppe

Gutes Beispiel

Listing 3.2 enthält eine ansatzweise Implementierung der Behandlung von ver-schiedenen Arten von Bankkonten in Klassen und deren Verwendung in einerKlasse, wobei wieder nur die Funktion »Abheben eines Betrags« gezeigt wird.

Die verschiedenen Kontoarten werden in Unterklassen einer abstrakten Klassefür Konten implementiert. Jede Instanz eines Kontos wird in ihrem Konstruk-tor genau mit den Daten versorgt, die sie benötigt. Die Anwendungsklasseerzeugt je nach Bedarf Instanzen von Konten der gewünschten Art und ver-wendet deren Methoden polymorph über eine Oberklassenreferenzvariable.Die Ausnahmebehandlung erfolgt über klassenbasierte Ausnahmen. Es werdenkeine CASE-WHEN-Kontrollstrukturen benötigt. Wie bereits in der Beschreibungder Beispiele von Abschnitt 2.1, »Trennung der Belange«, angekündigt, ent-steht hier bei der Verwendung von Klassen kein Overhead an Code mehrgegenüber der prozeduralen Programmierung.

CLASS cx_negative_amount DEFINITION PUBLICINHERITING FROM cx_static_check.

ENDCLASS.



51

CLASS cl_account DEFINITION ABSTRACT PUBLIC.PUBLIC SECTION.

METHODS: constructor IMPORTING id TYPE string,withdraw IMPORTING amount TYPE i

RAISING cx_negative_amount.PROTECTED SECTION.

DATA amount TYPE accounts-amount.ENDCLASS.

CLASS cl_account IMPLEMENTATION.METHOD constructor.

"fetch amount for one account into attribute amount...

ENDMETHOD.METHOD withdraw.

me->amount = me->amount - amount.ENDMETHOD.

ENDCLASS.

CLASS cl_checking_account DEFINITION PUBLICINHERITING FROM cl_account.

PUBLIC SECTION.METHODS withdraw REDEFINITION.

ENDCLASS.

CLASS cl_checking_account IMPLEMENTATION.METHOD withdraw.

super->withdraw( amount ).IF me->amount < 0."Handle debit balance...

ENDIF.ENDMETHOD.

ENDCLASS.

CLASS cl_savings_account DEFINITION PUBLICINHERITING FROM cl_account.

PUBLIC SECTION.METHODS withdraw REDEFINITION.

ENDCLASS.

CLASS cl_savings_account IMPLEMENTATION.METHOD withdraw.

IF me->amount > amount.super->withdraw( amount ).

ELSE.RAISE EXCEPTION TYPE cx_negative_amount.

ENDIF.



52

ENDMETHOD.ENDCLASS.

********************************************************

CLASS bank_application DEFINITION PUBLIC.PUBLIC SECTION.

CLASS-METHODS main.ENDCLASS.

CLASS bank_application IMPLEMENTATION.METHOD main.

DATA: account1 TYPE REF TO cl_account,account2 TYPE REF TO cl_account.

...

CREATE OBJECT account1 TYPE cl_checking_accountEXPORTING

id = ...

CREATE OBJECT account2 TYPE cl_savings_accountEXPORTING

id = ...

...

TRY.account1->withdraw( ... ).account2->withdraw( ... ).

CATCH cx_negative_amount....

ENDTRY.ENDMETHOD.

ENDCLASS.

Listing 3.2 Modellierung von Bankkonten in Klassen

3.2 Programmtyp und Programmeigenschaften

Bereits beim Anlegen eines ABAP-Programms erfolgt über die Wahl des Pro-grammtyps und der Programmattribute eine Weichenstellung bezüglich derspäteren Robustheit und Wartbarkeit. Programmtyp und Programmattributebestimmen unter anderem die Prüfschärfe der Syntaxprüfung. Eine weiterewichtige Eigenschaft von Programmen (wie auch von allen anderen Entwick-lungsobjekten) ist deren Originalsprache.


Programmtyp und Programmeigenschaften 3.2

53

3.2.1 Programmtyp

Hintergrund

Jedes ABAP-Programm hat einen Programmtyp, der festlegt, welche Deklarati-onen und Verarbeitungsblöcke ein Programm enthalten und wie es über dieABAP-Laufzeitumgebung ausgeführt werden kann. Die möglichen Programm-typen in ABAP sind:

� Ausführbares ProgrammEin ausführbares Programm kann alle möglichen deklarativen Anweisungenenthalten. Alle Verarbeitungsblöcke außer Funktionsbausteinen sind mög-lich. Es unterstützt klassische Dynpros sowie Selektionsbilder und kannsowohl über die Anweisung SUBMIT als auch über Transaktionscodes ausge-führt werden. Ein ausführbares Programm wird mit dem ABAP Editor ange-legt.

� Class-PoolEin Class-Pool enthält stets deklarative Anweisungen für eine globale Klasseund kann daneben auch deklarative Anweisungen für lokale Typen, Inter-faces und Klassen beinhalten. Als Verarbeitungsblöcke sind nur Methodenmöglich. Er unterstützt keine klassischen Dynpros oder Selektionsbilder.Die Methoden der globalen Klasse können je nach Sichtbarkeit von außenaufgerufen und die öffentlichen Methoden der globalen Klasse auch überTransaktionscodes ausgeführt werden. Ein Class-Pool wird mit dem ClassBuilder angelegt.

� Interface-PoolEin Interface-Pool kann nur die deklarativen Anweisungen für ein globalesInterface enthalten. Es sind keine Verarbeitungsblöcke und keine klassi-schen Dynpros oder Selektionsbilder möglich. Ein Interface-Pool ist nichtaufruf- oder ausführbar und wird mit dem Class Builder angelegt.

� Funktionsgruppe (Function-Pool)Eine Funktionsgruppe kann alle Arten von deklarativen Anweisungen ent-halten. Alle Verarbeitungsblöcke außer Reporting-Ereignisblöcken werdenunterstützt. Sie unterstützt klassische Dynpros sowie Selektionsbilder. IhreFunktionsbausteine können aufgerufen werden, es ist aber auch über Trans-aktionscodes ein Einstieg in die Dynpro-Verarbeitung der Funktionsgruppemöglich. Eine Funktionsgruppe wird mit dem Function Builder angelegt.

� Modul-PoolEin Modul-Pool kann alle möglichen deklarativen Anweisungen enthalten.Alle Verarbeitungsblöcke außer Reporting-Ereignisblöcken und Funktions-bausteinen werden unterstützt. Er unterstützt klassische Dynpros sowie



54

Selektionsbilder und kann über Transaktionscodes ausgeführt werden. EinModul-Pool wird mit dem ABAP Editor angelegt.

� Subroutinen-PoolEin Subroutinen-Pool kann alle möglichen deklarativen Anweisungen ent-halten. Als Verarbeitungsblöcke sind der Ereignisblock LOAD-OF-PROGRAMsowie Unterprogramme und Methoden möglich. Er unterstützt keine klassi-schen Dynpros oder Selektionsbilder. Die Unterprogramme können aufge-rufen werden, es ist aber auch eine Ausführung von Methoden über Trans-aktionscodes möglich. Ein Subroutinen-Pool wird mit dem ABAP Editorangelegt.

� Typgruppe (Type-Pool)Eine Typgruppe kann die deklarativen Anweisungen TYPES und CONSTANTSenthalten. Es sind keine Verarbeitungsblöcke und keine klassischen Dyn-pros oder Selektionsbilder möglich. Eine Typgruppe ist nicht aufruf- oderausführbar. Eine Typgruppe wird mithilfe des ABAP Dictionarys angelegt.

Neben den genannten Kompilationseinheiten, das heißt Programmen, dieeigenständig kompilierbar sind, gibt es auch Include-Programme, auf die wir inAbschnitt 4.5, »Quelltextorganisation«, gesondert eingehen.

Eine Programmausführung in ABAP bedeutet, dass ein Programm in den Spei-cher geladen wird und einer oder mehrere seiner Verarbeitungsblöcke ausge-führt werden. Man kann hier die eigenständige und die gerufene Programm-ausführung unterscheiden:

� Eigenständige ProgrammausführungBei der eigenständigen Programmausführung wird das Programm entwederüber einen Transaktionscode (Anweisungen CALL TRANSACTION und LEAVE TOTRANSACTION) oder bei einem ausführbaren Programm über die AnweisungSUBMIT gestartet. Die Anweisung SUBMIT gestattet auch die Ausführung ineinem Hintergrundprozess.

� Gerufene ProgrammausführungBei der gerufenen Programmausführung ruft ein laufendes Programm eineProzedur (Methode, Funktionsbaustein oder Unterprogramm) eines ande-ren Programms auf, das bei Bedarf in den internen Modus des Aufrufersgeladen wird (siehe Abschnitt 6.5.6).

Der Programmablauf im Rahmen der eigenständigen Programmausführung istabhängig vom gewählten Programmtyp und der Art des Programmaufrufs:

� Beim Programmaufruf über eine Transaktion muss zwischen objektorientier-ten (OO-Transaktion) und Dialogtransaktionen unterschieden werden. Beiobjektorientierten Transaktionen ist der Transaktionscode mit einer



55

Methode einer lokalen oder globalen Klasse verbunden. Der Programmab-lauf wird durch diese Methode bestimmt. Dialogtransaktionen sind hinge-gen mit einem klassischen Dynpro des Programms verknüpft. DerProgrammablauf wird hier durch die zugehörige Dynpro-Ablauflogikbestimmt.

� Der Programmablauf eines über SUBMIT gestarteten ausführbaren Programmswird durch den Reporting-Prozess der ABAP-Laufzeitumgebung bestimmt.Hierbei werden die verschiedenen Reporting-Ereignisblöcke START-OF-SELECTION, GET und END-OF-SELECTION des Programms von der Laufzeitum-gebung aufgerufen.

Der Programmtyp muss unter Beachtung der hier aufgezählten technischenEigenschaften eines Programms und der Anforderungen an die Programmaus-führung geeignet gewählt werden. Nicht mehr alle der genannten Programm-typen lassen sich sinnvoll für Neuentwicklungen einsetzen.2

Regel

Details

Die in Regel 3.2 aufgeführte Hierarchie zur Wahl des Programmtyps ergibt sichaus der grundlegenden Regel in Abschnitt 3.1, die die Verwendung von ABAPObjects vorschreibt. Die folgende Liste führt die Teilaspekte noch weiter aus:

2 Ab Release 7.2 kann die Verwendbarkeit globaler Klassen durch das operationale Paketkon-zept auf ein Paket eingeschränkt werden, sodass diese Rolle von Subroutinen-Pools anBedeutung verliert.

Regel 3.2: Geeigneten Programmtyp wählen

Wählen Sie den Programmtyp wie folgt:

� Für globale Klassen und Interfaces ergibt sich automatisch der ProgrammtypClass-Pool bzw. Interface-Pool.

� Für die Implementierung abgeschlossener Funktionalität, die nicht in der Klassen-bibliothek erscheinen soll, kann der Programmtyp Subroutinen-Pool für lokaleKlassen verwendet werden.2

� Bei Bedarf für Funktionsbausteine ergibt sich automatisch der Programmtyp Funk-tionsgruppe. Außerdem sind Funktionsgruppen zur Verschalung klassischer Dyn-pros oder von Selektionsbildern zu verwenden.

� Bei Bedarf für eine Ausführung im Rahmen der Hintergrundverarbeitung ergibtsich automatisch der Programmtyp ausführbares Programm.

� Es sollen keine neuen Modul-Pools und Typgruppen mehr angelegt werden.



56

� Soll im Rahmen von ABAP Objects Funktionalität paket- oder systemweitzur Verfügung gestellt werden, erfolgt dies über globale Klassen oder Inter-faces, die implizit den Programmtyp Class-Pool oder Interface-Pool haben.Der Aufruf erfolgt entweder über einen Methodenaufruf oder über eine OO-Transaktion, wenn eine eigenständige Programmausführung gewünscht ist.

� Zur Implementierung abgeschlossener Funktionalität, die nicht über einenMethodenaufruf, sondern über einen Transaktionscode aufgerufen werdensoll und die darüber hinaus weder eine Parameterübergabe benötigt nocheine Benutzeroberfläche aufweist, kann der Programmtyp Subroutinen-Poolverwendet werden. Die Implementierung soll ausschließlich über lokaleKlassen und der Programmaufruf über eine OO-Transaktion erfolgen. Sub-routinen-Pools waren, wie die Bezeichnung nahelegt, ursprünglich einmalfür Unterprogramme vorgesehen, die aus anderen Programmen aufgerufenwerden. Da Unterprogramme und insbesondere deren externer Aufruf imRahmen der vorliegenden Programmierrichtlinien für obsolet erklärt wer-den, entfällt dieser Verwendungszweck für Subroutinen-Pools. Stattdessenwerden Subroutinen-Pools hier als unabhängige Container für lokale Klas-sen vorgeschlagen, da sie ansonsten kaum von impliziten Prozessen derABAP-Laufzeitumgebung beeinflusst werden.

� Remotefähige Funktionsbausteine (Remote-enabled Function Module,RFM), die Funktionalität über die RFC-Schnittstelle entweder server- odersystemübergreifend zur Verfügung stellen oder der Parallelisierung dienen,können nur in einer Funktionsgruppe angelegt werden. Die Implementie-rung der eigentlichen Funktionalität soll aber in einer Klasse erfolgen, bei-spielsweise in einer lokalen Klasse innerhalb der Funktionsgruppe (sieheRegel 6.37).

� Für Verbuchungsfunktionsbausteine, die im Rahmen der Verbuchung mitCALL FUNCTION IN UPDATE TASK aufgerufen werden, gilt das Gleiche wie fürremotefähige Funktionsbausteine.

� Programme mit einer klassischen Dynpro-Oberfläche oder Selektionsbil-dern (soweit diese noch erforderlich sein sollten; siehe Regel 5.18, »WebDynpro ABAP verwenden«) sollen ebenfalls in Form einer Funktionsgruppeangelegt werden, die lediglich die Benutzeroberfläche implementiert,jedoch keine eigene Anwendungslogik enthält (siehe Regel 2.1, »SoC-Prinzipbefolgen« und Regel 5.19, »Klassische Dynpros und Selektionsbilder kap-seln«). Dieser Programmtyp ist deshalb geeignet, weil er sowohl klassischeDynpros als auch eine externe funktionale Schnittstelle in Form von Funk-tionsbausteinen enthalten kann. Die von der Dynpro-Ablauflogik aufgerufe-



57

nen Dialogmodule der Funktionsgruppe sollten im Wesentlichen nurMethodenaufrufe enthalten, beispielsweise für Methoden lokaler Klassen.

� Ein ausführbares Programm besteht aus einer Reihe von Ereignisblöcken,die beim Eintreten der verschiedenen Reporting-Ereignisse ausgeführt wer-den. Diese Form der Ereignissteuerung ist im Wesentlichen obsolet und sollnicht mehr verwendet werden. Ausführbare Programme sollen nur nochdort zum Einsatz kommen, wo dies technisch notwendig ist, im Wesentli-chen demnach für die Hintergrundverarbeitung. Auch in diesem Fall soll dieeigentliche Implementierung in Methoden erfolgen, beispielsweise überMethoden einer lokalen Klasse innerhalb des ausführbaren Programms. DerEreignisblock des Einstiegsereignisses START-OF-SELECTION soll lediglich auseinem Methodenaufruf bestehen (siehe Regel 6.44), und andere Ereignisblö-cke sollten nicht mehr vorkommen.

� Der Modul-Pool war der Programmtyp, der traditionsgemäß bei der klassi-schen Dialogprogrammierung mit Dynpros zum Einsatz kam. Wie inAbschnitt 2.1 aufgezeigt, wird durch Modul-Pools das Konzept der Tren-nung der Belange nicht ausreichend unterstützt. Aus diesem Grund sollenkeine neuen Modul-Pools mehr angelegt werden. Stattdessen sollen klassi-sche Dynpros, soweit diese noch verwendet werden müssen, in Funktions-gruppen verschalt werden.

� Der Programmtyp Typgruppe wurde anfangs als Notlösung dafür einge-führt, dass im ABAP Dictionary zeitweise noch keine Typen für interneTabellen definiert werden konnten. Ebenso verhielt es sich mit der globalenAblage von Konstanten. Beide Lücken sind inzwischen geschlossen. ImABAP Dictionary können beliebige Typen definiert werden, und in globalenKlassen und Interfaces ist es möglich, sowohl Typen als auch Konstanten zurpaket- oder systemweiten Verwendung anzulegen. Aus diesem Grund ist derProgrammtyp Typgruppe obsolet, und es sollen keine neuen Typgruppenmehr angelegt werden (siehe Abschnitt 6.1.2, »Deklaration von Datentypenund Konstanten«).

Anmerkung

In den Fällen, in denen noch mit anderen Programmtypen als Class- und Inter-face-Pools gearbeitet wird, sollte in der erweiterten Programmprüfung (sieheAbschnitt 3.4.2) die Prüfung Veraltete Anweisungen (OO-Kontext) einge-schaltet werden, um auch für die Programmteile, die nicht in lokalen Klassenimplementiert sind, die gleiche strengere Syntaxprüfung wie innerhalb vonKlassen durchzuführen.



58

3.2.2 Programmattribute

Hintergrund

Jedes ABAP-Programm hat neben weiteren, weniger wichtigen Eigenschafteneinen Satz von Programmattributen, die bestimmte Aspekte des Programmver-haltens und der Syntaxprüfschärfe steuern. Diese sind:

� Unicode-Prüfungen aktivzur Erstellung eines Unicode-Programms

� Festpunktarithmetikfür die Berücksichtigung des Dezimaltrennzeichens in Operationen mitgepackten Zahlen

� Logische Datenbankzur Verknüpfung eines ausführbaren Programms mit einer logischen Daten-bank

Die Programmeigenschaften werden beim Anlegen eines Programms im ent-sprechenden Werkzeug (Class Builder, Function Builder, ABAP Editor) festge-legt und können auch nachträglich noch geändert werden.

Regel

Details

Verschiedene Verhaltensweisen oder Prüfschärfen werden nur noch aus Kom-patibilitätsgründen angeboten, um bestehende Programme weiterhin kompi-lier- und ausführbar zu halten. Neue Programme sollen in keinem Fall von ver-alteten Einstellungen Gebrauch machen.

� Beim Anlegen eines neuen Programms ist das Attribut Unicode-Prüfungen

aktiv bereits als Standardeinstellung gesetzt. Dieses Attribut darf niemalszurückgesetzt werden. Nur mit eingeschalteten Unicode-Prüfungen kann

Regel 3.3: Standardeinstellungen für Programmattribute übernehmen

Setzen Sie die Programmattribute für neue Programme wie folgt:

� Unicode-Prüfungen aktiv eingeschaltet

� Festpunktarithmetik eingeschaltet

� keine Zuordnung zu einer logischen Datenbank

Diese Einstellungen entsprechen den Vorschlagswerten beim Anlegen eines neuenProgramms, die daher ohne Änderungen übernommen werden sollen. Einmal ge-setzte Programmattribute sollten nachträglich nicht mehr abgeändert werden.



59

sichergestellt werden, dass das Programm sowohl in Unicode-Systemen alsauch in Nicht-Unicode-Systemen lauffähig ist und jeweils die gleichenErgebnisse liefert.3 Bei der Vorbereitung eines Nicht-Unicode-Systems zurUmstellung auf Unicode müssen alle noch vorhandenen Nicht-Unicode-Pro-gramme in Unicode-Programme umgesetzt werden. Die Aktivierung derUnicode-Prüfungen bringt dem Entwickler ausschließlich Vorteile, bei-spielsweise in Form einer strengeren statischen Typprüfung und einer strik-ten Trennung von Byte- und Zeichenkettenverarbeitung.

� Beim Anlegen eines neuen Programms ist das Attribut Festpunktarithmetik

bereits als Standardeinstellung gesetzt. Auch dieses Attribut darf niemalszurückgesetzt werden. Bei ausgeschalteter Festpunktarithmetik wird dieStellung des Dezimaltrennzeichens von gepackten Zahlen (Typ p) nur bei derAusgabe auf dem klassischen Dynpro oder bei der Formatierung mittelsWRITE TO berücksichtigt, nicht jedoch bei Berechnungen. Ein solches Verhal-ten wird heute nur in den seltensten Fällen den Erwartungen des Entwick-lers entsprechen. Soll mit gepackten Zahlen ohne Nachkommastellengerechnet werden, ist dies über den Zusatz DECIMALS 0 bei der Deklarationanzugeben.

� Beim Anlegen eines neuen ausführbaren Programms ist das Attribut Logi-

sche Datenbank leer. Durch dieses Attribut werden ausführbare Pro-gramme einer logischen Datenbank4 zugeordnet, wodurch das Selektions-bild und der Programmablauf des Programms mit dem Selektionsbild unddem Ablauf der logischen Datenbank kombiniert werden. Logische Daten-banken sollen nicht mehr verwendet werden, da sie auf der programmüber-greifenden Nutzung globaler Daten, einem impliziten Unterprogrammauf-ruf und der Reporting-Ereignissteuerung beruhen und damit modernenKonzepten zuwiderlaufen. Der Zugriff auf bestehende logische Datenban-ken kann bei Bedarf über den Funktionsbaustein LDB_PROCESS erfolgen, derbeispielsweise aus einer Methode heraus aufgerufen werden kann. Neue

3 Ein Programm mit eingeschalteten Unicode-Prüfungen wird als Unicode-Programm bezeich-net. Als Unicode-System bezeichnet man ein SAP-System, in dem die Zeichendarstellung imUnicode-Format (ISO/IEC 10646) erfolgt (derzeit UTF-16 mit plattformabhängiger Byterei-henfolge). Auf einem Unicode-System können nur Unicode-Programme, Unicode-Pro-gramme können aber auch auf Nicht-Unicode-Systemen ausgeführt werden. Die von SAPausgelieferten Programme sind in der Regel Unicode-Programme.

4 Eine logische Datenbank ist ein spezielles Entwicklungsobjekt, das im Logical Database Buil-der bearbeitet wird und anderen ABAP-Programmen Daten aus den Knoten einer hierarchi-schen Baumstruktur zur Verfügung stellt. Eine logische Datenbank verfügt über eine hierar-chische Struktur, ein in ABAP geschriebenes Datenbankprogramm und ein eigenesStandardselektionsbild.



60

logische Datenbanken sollen nicht mehr angelegt werden. Stattdessen sollein entsprechender Service über eine globale Klasse angeboten werden.

Da eine nachträgliche Änderung von Programmeigenschaften potenziell mitUmstellungsaufwand verbunden ist, sollten die richtigen Eigenschaften vonAnfang an eingestellt und nicht mehr geändert werden. Insbesondere bei Attri-buten, die die Syntaxprüfung beeinflussen (derzeit die Unicode-Prüfung) sollteman sich immer gleich für die größtmögliche Prüfschärfe entscheiden, um beispäteren eventuell angeordneten Umstellungen bestens vorbereitet zu sein.

Im Folgenden gehen wir davon aus, dass nur noch mit eingeschalteter Uni-code-Prüfung und Festpunktarithmetik und ohne logische Datenbanken gear-beitet wird. Für veraltete oder problematische Sprachkonstrukte, die nur nochbei ausgeschalteten Unicode-Prüfungen verfügbar sind, wird in diesen Richtli-nien daher keine spezielle Regel mehr erstellt. Wir erwähnen sie nur kurz imRahmen der Liste der obsoleten Sprachelemente (siehe Anhang A).

Schlechtes Beispiel

Abbildung 3.1 zeigt ein ABAP-Programm, bei dem in den Programmeigen-schaften das Attribut Unicode-Prüfungen aktiv entgegen der Empfehlungvon Regel 3.3 nicht ausgewählt ist.

In dem Nicht-Unicode-Programm aus Abbildung 3.1 ist es straflos möglich,einen schreibenden Teilfeldzugriff über zwei numerische Komponenten einer

Abbildung 3.1 Erlaubter Teilfeldzugriff auf eine Struktur in einem Nicht-Unicode-Programm



61

Struktur hinweg auszuführen, wobei – horribile dictu – ein implizites Casting(siehe Abschnitt 6.2.8) des Teilbereichs auf den Typ c stattfindet. Das Ergebnisin den Komponenten ist abhängig von Ausrichtungslücken, der internen Dar-stellung numerischer Werte (Bytereihenfolge) sowie der verwendeten Code-page und damit extrem plattformabhängig. Ein produktives Programm darfkeinesfalls solchen Code enthalten. Es führt in der Regel zu fehlerhaften Datenoder zu schwer nachvollziehbaren Laufzeitfehlern.

Gutes Beispiel

Abbildung 3.2 zeigt ein ABAP-Programm, bei dem in den Programmeigen-schaften nach Regel 3.3 das Attribut Unicode-Prüfungen aktiv ausgewählt ist.

Im Unicode-Programm aus Abbildung 3.2 führt der Code aus Abbildung 3.1 zueinem Syntaxfehler. Unerwünschte Teilfeldzugriffe sind wie andere uner-wünschte Zugriffe auf Strukturen oder andere Teile des Arbeitsspeichers ver-boten. Falls statisch erkennbar, führen diese wie im hier gezeigten Beispiel zueinem Syntaxfehler. Anderenfalls kommt es während der Programmausfüh-rung zu einem Laufzeitfehler mit einem aussagekräftigen Kurzdump.

Abbildung 3.2 Syntaxfehler bei Teilfeldzugriff auf eine Struktur in einem Unicode-Programm



62

3.2.3 Originalsprache

Hintergrund

Beim Anlegen eines neuen Repository-Objektes (beispielsweise eines Pro-gramms, einer Klasse oder einer Datenbanktabelle im ABAP Dictionary) mussseine Originalsprache festgelegt werden. Dies passiert implizit durch die aktu-elle Anmeldesprache. Alle während der Entwicklung angelegten übersetzungs-fähigen Texte des Entwicklungsobjektes, wie zum Beispiel beschreibende Kurz-und Langtexte, die Textelemente eines Programms und auch die Dokumenta-tion von Datentypen oder Schnittstellen, werden der angegebenen Original-sprache zugeordnet. Die Erstellung der Texte in anderen Sprachen erfolgtdurch einen von der Entwicklung losgelösten Übersetzungsvorgang aus derOriginalsprache in die Zielsprachen.

Derzeit gibt es keine technische Unterstützung für die projektweite Ersetzungeiner einmal gewählten Originalsprache durch eine andere Sprache.

Regel

Details

Bei der Festlegung der Originalsprache soll wie folgt vorgegangen werden:

� Bei einsprachiger Besetzung aller an einem Projekt beteiligten Entwicklungs-gruppen ist die Originalsprache aller Entwicklungsobjekte die Mutterspra-che aller beteiligten Entwickler (einsprachige Entwicklung).

� Bei mehrsprachiger Besetzung der Entwicklungsgruppen

� ist die Originalsprache aller Entwicklungsobjekte entweder eine vonallen Beteiligten verstandene Sprache – in der Regel Englisch – (einspra-chige Entwicklung)

� oder richtet sich die Originalsprache von Entwicklungsobjekten in Tei-len des Projektes nach der Muttersprache der hauptsächlich daran arbei-tenden Entwickler (mehrsprachige Entwicklung).

Regel 3.4: Originalsprache auf Projektebene festlegen

Legen Sie vor Beginn der Implementierung eine sorgfältig ausgewählte Originalspra-che auf Projektebene für die Repository-Objekte fest. Entwickler dürfen ihre Entwick-lungsobjekte nur in der für das jeweilige Projekt (oder in Ausnahmefällen für ein Teil-projekt) festgelegten Originalsprache anlegen.



63

Einsprachige Entwicklungsgruppen stellen sozusagen den Idealfall dar, sindheutzutage aber nicht immer zu realisieren. Die beiden möglichen Einstellun-gen für mehrsprachige Entwicklergruppen – einsprachige und mehrsprachigeEntwicklung – erfüllen zwei unterschiedliche Anforderungen, die sich aberwidersprechen:

� Bei der Anmeldung an einem System in einer anderen Sprache als der Ori-ginalsprache lässt sich im Allgemeinen nicht sinnvoll mit einem in der Ent-wicklung befindlichen oder neu entwickelten Produkt arbeiten, bis eineÜbersetzung der relevanten Texte in die jeweilige Zielsprache vorliegt. DieÜbersetzung erfolgt in der Regel in einem nachgelagerten Übersetzungssys-tem und muss in das Entwicklungssystem zurücktransportiert werden. Ausdiesem Grund ist eine effiziente Entwicklung, insbesondere in internationalbesetzten Entwicklungsgruppen (die eventuell auch noch über mehrereStandorte verteilt sind), nur dann möglich, wenn zu Beginn projektweit eineeinheitliche Originalsprache festgelegt wird, die es allen am Entwicklungs-und Validierungsprozess beteiligten Personen erlaubt, das Produkt zumin-dest testweise zu verwenden. Bei einsprachiger Entwicklung in mehrspra-chigen Entwicklungsgruppen müssen daher einige, wenn nicht gar alle Ent-wickler eines Projektes Texte in einer Sprache anlegen, die nicht ihre Mut-tersprache ist.

� Für die sprachliche und stilistische Überprüfung von Oberflächentexten undDokumentationen, die von Entwicklern in anderen Sprachen als ihrer Mut-tersprache angelegt werden, gibt es in der Regel keine Unterstützung inForm von Werkzeugen oder definierten Abläufen. Daher wäre es wün-schenswert, dass die an der Entwicklung von Benutzerdialogen und Doku-mentationen beteiligten Entwickler idealerweise in ihrer Muttersprachearbeiten und diese Texte dann von geschulten Übersetzern anhand von vor-gegebener Terminologie in deren Muttersprache übersetzt werden.

Der zweite Punkt ist der Grund, warum nicht Englisch als allumfassende ein-heitliche Originalsprache für alle Entwicklungsprojekte gefordert wird, son-dern dass einsprachige Entwicklungsgruppen durchaus in ihrer Muttersprachemit eventueller nachgelagerter Übersetzung arbeiten sollten.

Bei mehrsprachigen Entwicklungsgruppen kommt es letztendlich auf den kon-kreten Fall an, welche Originalsprache für jedes Entwicklungsobjekt festgelegtwird. In der Regel wiegt der erste Punkt schwerer, sodass bei internationalerEntwicklung eine einsprachige Entwicklung durchgeführt werden muss, umdie Entwicklungsressourcen für ein Projekt möglichst effektiv zu nutzen. InEinzelfällen kann es bei Teilprojekten, in denen besonders viel Text angelegt



64

werden muss, durchaus auch sinnvoll sein, die Originalsprache gemäß derMuttersprache der Entwickler festzulegen.5

Bei mehrsprachigen Projekten sollten betriebswirtschaftlich zusammengehö-rige Funktionen sprachenrein entwickelt werden, zumindest auf Paketebene.Auch Tabelleninhalte sollten in einer einheitlichen Sprache angelegt werden.

Hinweis

Da die Originalsprache beim Anlegen eines Repository-Objekts durch dieAnmeldesprache festgelegt wird, muss für das Anlegen und Bearbeiten vonRepository-Objekten ganz bewusst die Entscheidung für eine Anmeldesprachegetroffen werden.

Anmerkung

Unabhängig davon, ob eine ein- oder mehrsprachige Entwicklung innerhalbeines Projektes durchgeführt wird, muss vor Entwicklungsbeginn immer eineeinheitliche Terminologie für alle im Projekt angelegten Texte erstellt und diesedurchgängig befolgt werden. Bei einer mehrsprachigen Entwicklung sollte dieÜbersetzung der Terminologiebegriffe in die verwendeten Sprachen möglichstvor Beginn der Entwicklung vorgenommen werden, damit sie von den Ent-wicklern verwendet werden können. Zudem müssen immer die existierendenStandards für Oberflächentexte und Dokumentation befolgt werden (sieheAbschnitt 2.3, »Korrektheit und Qualität«).

3.3 Modernes ABAP

Hintergrund

ABAP ist eine lebendige Programmiersprache, die kontinuierlich weiterentwi-ckelt wird. Seit der Einführung von ABAP vor etwa 30 Jahren entstehen lau-fend neue ABAP-Programme, während parallel dazu an der Sprache ABAPselbst gearbeitet wird. Weiterentwicklungen an der Sprache ABAP sind entwe-der Erweiterungen der vorhandenen Spracheigenschaften, um neue Funktio-nalität einzuführen, oder der Ersatz vorhandener Funktionalität durch fortge-schrittenere Konzepte. Der Ersatz vorhandener durch neue Sprachelementemacht die vorhandenen in der Regel überflüssig bzw. obsolet. Das prominen-

5 Dies betrifft insbesondere die SAP-eigene Entwicklung, bei der nach wie vor größereAnteile von deutschsprachigen Entwicklern ausgeführt werden.


Modernes ABAP 3.3

65

teste Beispiel einer Weiterentwicklung der Sprache ABAP ist nach wie vor dieEinführung von ABAP Objects zu Release 4.6.

SAP hat sich bezüglich der Sprache ABAP einer Politik der strikten Abwärts-kompatibilität verschrieben. Das bedeutet zum einen, dass ein beispielsweisezu R/3-Release 3.0 geschriebenes ABAP-Programm auf einem AS ABAP inRelease 7.2 unverändert ausgeführt werden kann, zumindest solange es sichum ein Nicht-Unicode-System handelt. Auf der anderen Seite bedeutet es aberauch:

� Ein erfahrener Entwickler wurde bisher durch fast nichts gezwungen, alteGewohnheiten abzulegen und sich mit neuen Konzepten zu beschäftigen.Die einzige Ausnahme stellt die Umstellung auf Unicode-Systeme dar, fürdie ABAP-Programme in Unicode-Programme mit leicht veränderten Syn-taxregeln umgewandelt werden müssen.

� ABAP-Einsteiger werden durch die Vielfalt der Möglichkeiten verwirrt, diees gibt, um ein und dasselbe zu tun. Wenn dann im Zweifelsfall ältere Pro-gramme als Vorlagen dienen, kommen oft statt der neuen weiterhin dieobsoleten Konzepte zum Einsatz.

Um diesen Problemen abzuhelfen, gibt es folgende einfache Regel.

Regel

Details

Neuere Sprachelemente sind immer die besseren Sprachelemente. ObsoleteSprachmittel werden nur aus Gründen der Abwärtskompatibilität weiterhinangeboten. Eine Anweisung oder ein Anweisungszusatz wird erst dann fürobsolet erklärt, wenn eine leistungsfähigere Alternative existiert oder dasSprachelement als fehlerträchtig (in dem Sinne, dass es zu unsicherer und nichtrobuster Programmierung einlädt) erkannt wurde. Aus diesem Grund ist einesichere und robuste Programmierung nicht mit dem Einsatz obsoleter Sprach-elemente zu vereinbaren. Damit verbietet sich die Verwendung solcher obso-leter Sprachmittel im Rahmen der Neuentwicklung.

Regel 3.5: Keine obsoleten Sprachmittel verwenden

Verwenden Sie für Neuentwicklungen keine obsoleten Sprachmittel. Auch für beste-hende Programme wird eine inkrementelle Umstellung auf neuere Konzepte empfoh-len, wie sie zur Verfügung stehen.



66

Bei der Verwendung von ABAP Objects ist ein Großteil der obsoleten Anwei-sungen und Zusätze bereits syntaktisch verboten. Unter anderem aus diesemGrund wird die Verwendung von ABAP Objects unbedingt empfohlen (sieheRegel 3.1). Außerhalb von ABAP Objects, das heißt in den Fällen, die nachAbschnitt 3.1, »ABAP Objects als Programmiermodell«, noch erlaubt sind,muss selbst Sorge dafür getragen werden, dass keine obsoleten Sprachelementezum Einsatz kommen. Hierfür liefert Anhang A, »Obsolete Sprachkonstrukte«,eine Übersicht der obsoleten Anweisungen und Anweisungszusätze.

Schlechtes Beispiel

Listing 3.3 zeigt die Lösung einer Aufgabe unter Verwendung obsoleter Sprach-mittel. Eine Prozedur soll in einem Text text alle Vorkommen einer Unterfolgesubstring durch eine neue Zeichenfolge new ersetzen, falls die Unterfolge nichtam Ende eines Wortes steht.

FORM bad_example USING substring TYPE csequencenew TYPE csequence

CHANGING text TYPE csequence.DATA: pattern TYPE string,

subrc TYPE sy-subrc.CONCATENATE '*' substring INTO pattern.SEARCH text FOR pattern.IF sy-subrc <> 0.

CLEAR subrc.WHILE subrc = 0.

REPLACE substring WITH new INTO text.subrc = sy-subrc.

ENDWHILE.ENDIF.

ENDFORM.

Listing 3.3 Verwendung obsoleter Sprachmittel

In Listing 3.3 sind, abgesehen von der Modularisierung mit FORM-ENDFORM, dieAnweisung SEARCH und die verwendete Variante von REPLACE ab Release 7.0obsolet. Darüber hinaus steht ab den Releases 7.0 EhP2 und 7.2 ein Zeichen-kettenoperator && als Ersatz für CONCATENATE zur Verfügung.

Gutes Beispiel

Listing 3.4 führt die gleiche Aufgabe wie Listing 3.3 unter Verwendung derneuesten zur Verfügung stehenden Sprachelemente aus.


Modernes ABAP 3.3

67

METHOD good_example.FIND REGEX substring && `\b` IN text.IF sy-subrc <> 0.

REPLACE ALL OCCURRENCES OF substring IN text WITH new.ENDIF.

ENDMETHOD.

Listing 3.4 Verwendung moderner Sprachmittel

Das Unterprogramm wird durch eine Methode ersetzt. Durch Verwendungvon FIND in Zusammenhang mit einem regulären Ausdruck, der über den Zei-chenkettenoperator && zusammengesetzt wird, ist keine Hilfsvariable mehrnötig. Die WHILE-Schleife wird durch REPLACE ALL OCCURRENCES ersetzt, wobeieine weitere Hilfsvariable entfällt und der Kontrollfluss in die ABAP-Laufzeit-umgebung verschoben wird. Letzteres erhöht die Ausführungsgeschwindigkeitund ist auch zur Erfüllung von Regel 4.22 zur Beschränkung der maximalenSchachtelungstiefe hilfreich.

Anmerkung

Im Zusammenhang mit Regel 3.5, »Keine obsoleten Sprachmittel verwenden«,stellt sich die Frage, wie es mit der Koexistenz alter und neuer Konzepte inner-halb einer Programmeinheit aussieht. Es gibt nur eine Stelle, an der dies syn-taktisch klar geregelt ist, nämlich die Verwendung des klassischen und desklassenbasierten Ausnahmekonzeptes (siehe Abschnitt 5.2.2) in Verarbeitungs-blöcken. Anderenfalls können obsolete Sprachelemente in einem Programm-teil direkt neben neuen Sprachelementen stehen. Unsere Empfehlung hierzuist, die Verwendung innerhalb eines Kontextes möglichst einheitlich zu gestal-ten, das heißt nicht verschiedene Anweisungen, wie zum Beispiel FIND undSEARCH, nebeneinander zum gleichen Zweck einzusetzen.

Dies soll aber nicht bedeuten, dass bei Erweiterungen an bestehenden Proze-duren aus Gründen der Einheitlichkeit weiterhin obsolete Sprachelemente ver-wendet werden sollen, nur weil sie dort bereits vorhanden sind. Vielmehrsollte man die Gelegenheit ergreifen und gleich die gesamte Prozedur auf dieentsprechenden neuen Sprachelemente umstellen. Durch die Abdeckung derzu ändernden Prozeduren mit Modultests kann sichergestellt werden, dass esbei einer solchen Umstellung nicht zu Überraschungen kommt.



68

3.4 Prüfungen auf Korrektheit

In Abschnitt 2.3, »Korrektheit und Qualität«, wurde bereits allgemein auf dieKorrektheit und Qualität von Programmen eingegangen, und die für derenÜberprüfung vorhandenen Werkzeuge wurden kurz vorgestellt. Der vorlie-gende Abschnitt beschäftigt sich nochmals speziell mit der syntaktischen Kor-rektheit von ABAP-Programmen, die mit der Syntaxprüfung und der erweiter-ten Programmprüfung kontrolliert wird, sowie mit der Standardprüfung desCode Inspectors und dem neuen ABAP-Testcockpit.

3.4.1 Syntaxprüfung

Hintergrund

Die Syntaxprüfung liefert Syntaxfehler und Syntaxwarnungen.

� Sobald ein Syntaxfehler auftritt, wird die Prüfung beendet und eine entspre-chende Fehlermeldung angezeigt. In vielen Fällen wird eine Korrektur vor-geschlagen, die übernommen werden kann. Ein Programm mit Syntaxfeh-lern ist zwar aktivierbar, kann aber nicht generiert und damit nicht ausge-führt werden. Syntaxfehler werden von der erweiterten Programmprüfungals fatale Fehler gemeldet. Syntaxfehler müssen unbedingt behoben werden.

� Tritt eine Syntaxwarnung auf, wird die Syntaxprüfung nicht beendet, unddas Programm ist im Prinzip ausführbar. Die Syntaxwarnungen werdennach einer Ausführung der Syntaxprüfung im ABAP Editor und auch von dererweiterten Programmprüfung (siehe Abschnitt 3.4.2) angezeigt.6 Bei derAktivierung eines Programms werden Syntaxwarnungen nur dann ausgege-ben, wenn es gleichzeitig auch Syntaxfehler gibt.

Die von der Syntaxprüfung gemeldeten Warnungen sind in drei Prioritätenunterteilt, die aber nur von der erweiterten Programmprüfung angezeigtwerden:

� Priorität 1Fehler, die erkennbar zu einem Programmabbruch bei der Ausführungdes ABAP-Programms führen werden. Zudem alle Konstrukte, die kei-nesfalls verwendet werden sollen, da sie auf Programmierfehler hindeu-ten und höchstwahrscheinlich zu falschem Verhalten führen.

6 Natürlich zeigen Testwerkzeuge, die die Prüfungen der erweiterten Programmprüfungumfassen, wie der Code Inspector und das SAP-interne ABAP-Testcockpit (seit den Releases7.0 EhP2 und 7.2), die Syntaxwarnungen ebenfalls an.


Prüfungen auf Korrektheit 3.4

69

� Priorität 2Alle Konstrukte, die nicht unbedingt zu Fehlverhalten führen, aber zumBeispiel obsolet sind und durch aktuelle Konstrukte ersetzt werden sol-len. Fehler der Priorität 2 können in zukünftigen Releases zu Fehlernder Priorität 1 oder zu Syntaxfehlern werden.

� Priorität 3Fasst alle Fehler zusammen, deren Behebung zwar wünschenswert, abernicht unbedingt für das aktuelle Release notwendig ist. Eine Verschär-fung der Priorität in kommenden Releases ist jedoch nicht ausgeschlos-sen.

Die Prüfschärfe der ABAP-Syntaxprüfung wird durch die beim Anlegen einesProgramms getroffenen Entscheidungen bestimmt (siehe Abschnitt 3.2, »Pro-grammtyp und Programmeigenschaften«). So können Programmkonstrukte,die außerhalb von Klassen oder in Nicht-Unicode-Programmen nur zu Syntax-warnungen führen, in Klassen oder in Unicode-Programmen echte Syntaxfeh-ler darstellen. Seit den Releases 7.0 EhP2 und 7.2 können ausgesuchte Syntax-warnungen durch sogenannte Pragmas7 unterdrückt werden.

Mit der Einführung des operationalen Paketkonzeptes ab Release 7.2 überprüftdie Syntaxprüfung auch Paketverletzungen. Dabei hängt es von der beimbetreffenden Paket eingestellten Kapselungsstärke ab, ob es zu einem Syntax-fehler oder lediglich zu einer Syntaxwarnung kommt.

Regel

Details

Die Ursachen von Syntaxwarnungen müssen immer korrigiert werden, da sieim Allgemeinen zu unvorhersagbaren Fehlern führen. Solche Warnungen wer-den von SAP häufig in einem späteren Release des AS ABAP zu Fehlern herauf-gestuft. In diesem Fall ist dann ein zunächst nur mit Syntaxwarnungen behaf-tetes Programm nach einem Upgrade syntaktisch falsch und nicht mehrbenutzbar. Genauso verhält es sich bei der Umstellung von Nicht-Unicode-Pro-

7 Ein Pragma ist eine Programmdirektive, die den Programmablauf nicht beeinflusst, sondernAuswirkung auf bestimmte Überprüfungen hat.

Regel 3.6: Syntaxwarnungen beachten

Nehmen Sie alle Warnungen der ABAP-Syntaxprüfung ernst. In einem fertiggestelltenProgramm dürfen keine Syntaxwarnungen mehr auftreten.



70

grammen auf Unicode-Programme oder bei der Migration älterer Programm-teile nach ABAP Objects.

Bezüglich der Paketprüfung stellt die konsequente Verwendung des bereits vorRelease 7.2 zur Verfügung stehenden Paketkonzeptes (Auswahl von Paketprü-

fung als Server im Package Builder) bzw. die Einstellung einer schwachenKapselung ab Release 7.2 einen ersten Schritt auf dem Weg zur echten Kapse-lung dar. Sie ermöglicht den Verwendern von Entwicklungsobjekten eineAnpassung ihrer Verwendungsstellen, noch bevor es zu harten Syntaxfehlernkommt. Aus diesem Grund müssen sowohl vor als auch nach Release 7.2 ins-besondere alle Warnungen der Paketprüfung ernst genommen und behobenwerden, damit das Programm auch nach einer verschärften Kapselung der ver-wendeten Pakete syntaktisch korrekt bleibt.

Schlechtes Beispiel

Abbildung 3.3 zeigt einen Ausschnitt eines Nicht-Unicode-Programms ineinem Nicht-Unicode-System, in dem eine VALUE-Angabe zu einer Syntaxwar-nung führt, weil ein nicht typgerechter Startwert für eine Struktur gesetzt wird.

Abbildung 3.3 Programm mit Syntaxwarnung



71

Anmerkung

In einem Unicode-Programm – das heißt einem Programm, für das die Pro-grammeigenschaft Unicode-Prüfungen aktiv gesetzt ist – führt die Anwei-sung, die in Abbildung 3.3 nur zu einer Warnung führt, zu einem Syntaxfehler.

Gutes Beispiel

Abbildung 3.4 zeigt das korrigierte Programm aus Abbildung 3.3. Die Kompo-nenten der Struktur werden im Instanzkonstruktor typgerecht mit Startwertenversorgt. Das Programm ist frei von Syntaxwarnungen und auch als Unicode-Programm korrekt.

3.4.2 Erweiterte Programmprüfung

Hintergrund

Die erweiterte Programmprüfung kann für aktivierte Programme entweder ausder ABAP Workbench heraus oder über die Transaktion SLIN aufgerufen wer-den. Sie führt statische Prüfungen durch, die für die normale Syntaxprüfung zuaufwendig sind. Es können entweder einzelne oder mehrere Teiltests oder eineStandardprüfung durchgeführt werden, die die wichtigsten Teiltests umfasst.

Abbildung 3.4 Korrektes Programm ohne Syntaxwarnung



72

Die erweiterte Programmprüfung gibt Fehler, Warnungen und Meldungenaus. Von der Standardprüfung werden die Fehler und Warnungen gemeldet,die besonders kritisch sind.8 Darüber hinaus werden immer auch die Fehlerund Warnungen der Syntaxprüfung angezeigt.

Seit den Releases 7.0 EhP2 und 7.2 kann im Einstiegsbild der erweiterten Pro-grammprüfung auch eine Prüfung von Programmierrichtlinien ausgewähltwerden, die die Einhaltung einiger der in diesem Buch vorgestellten Regeln,die statisch verifiziert werden können, überprüft.

Die Meldungen der erweiterten Programmprüfung, die in speziellen Sonder-fällen unzutreffend sind, können über Pseudokommentare und seit denReleases 7.0 EhP2 und 7.2 über Pragmas ausgeblendet werden. Meldungen, diedirekt von der normalen Syntaxprüfung kommen, ließen sich vor den Releases7.0 EhP2 und 7.2 nicht ausblenden.

Regel

Details

Die von der erweiterten Programmprüfung ausgegebenen Fehler, Warnungenund Meldungen sind genauso wichtig wie die Syntaxfehler und Syntaxwarnun-gen der Syntaxprüfung (siehe Abschnitt 3.4.1). Ein von der erweiterten Pro-grammprüfung gemeldeter Fehler kann zum Beispiel darauf hinweisen, dassein Programm bei der Ausführung sicher zu einem Laufzeitfehler führt. War-nungen und Meldungen weisen in der Regel auf die fragwürdige Verwendungvon Sprachelementen hin, die aller Voraussicht nach zu unerwartetem Pro-grammverhalten führt.

In den seltenen Fällen, in denen ein von der erweiterten Programmprüfunggemeldetes Prüfergebnis unberechtigt ist, muss dies durch einen geeignetenPseudokommentar oder ein Pragma (seit den Releases 7.0 EhP2 und 7.2) doku-mentiert werden (der geeignete Pseudokommentar bzw. das Pragma wird in

8 Die Einstufung eines einzelnen Ergebnisses als Fehler, Warnung oder Meldung kann variie-ren, je nachdem, ob eine Standardprüfung oder aber explizit ausgewählte Einzelprüfungendurchgeführt werden.

Regel 3.7: Erweiterte Programmprüfung verwenden

Verwenden Sie die erweiterte Programmprüfung, und nehmen Sie ihre Ergebnisseernst. Für ein fertiggestelltes Programm dürfen keine Meldungen der Standardprü-fung mehr auftreten.



73

der Meldung jeweils genannt). Dadurch wird diese Meldung der erweitertenProgrammprüfung unterdrückt. Idealerweise sollte in weniger offensichtlichenSituationen ein zusätzlicher Kommentar erläutern, warum an dieser Stelle dieMeldung nicht zutreffend ist.

Hinweis

Die erweiterte Programmprüfung ist eine wertvolle Hilfe beim Schreiben kor-rekter ABAP-Programme. Dieser Vorteil darf nicht durch Verwendung unspe-zifischer Pseudokommentare oder Pragmas zunichte gemacht werden. Insbe-sondere sollte die Anweisung

SET EXTENDED CHECK OFF.

niemals verwendet werden, die alle Meldungen der erweiterten Programmprü-fung für einen gesamten Quelltextabschnitt unterdrückt.

Wird ein ABAP-Programm einem Code-Review unterzogen, sollten die Ergeb-nisse der erweiterten Programmprüfung zur Beurteilung der Qualität mit her-angezogen werden.

Schlechtes Beispiel

Abbildung 3.5 zeigt das Ergebnis einer Teilprüfung der erweiterten Programm-prüfung, die seit den Releases 7.0 EhP2 und 7.2 ausgeführt wird. Sie macht aufeine äußerst fragwürdige Abfrage des Inhalts von sy-subrc aufmerksam (sieheAbschnitt 6.3.4, »Rückgabewert«).

Abbildung 3.5 Warnung der erweiterten Programmprüfung



74

Der Programmabschnitt zeigt einen typischen Fehler in einem syntaktisch kor-rekten Programm. Der Entwickler nimmt fälschlicherweise an, dass die stati-sche Form der Anweisung ASSIGN das Systemfeld sy-subrc setzt, was aber nichtder Fall ist. Dies hat zur Folge, dass er sich zum einen in der falschen Sicherheitwiegt, sein Programm abgesichert zu haben, und zum anderen ein falsches Pro-grammverhalten auftritt, wenn sy-subrc von vorhergehenden Anweisungenher einen Wert ungleich null hat. Der große Vorteil der erweiterten Programm-prüfung ist daher, dass nicht nur einzelne Anweisungen auf syntaktische Kor-rektheit, sondern ganze Programmabschnitte auf semantische Fehler hin unter-sucht werden.

Gutes Beispiel

Abbildung 3.6 zeigt die korrigierte Fassung des Programms aus Abbildung 3.5.Statt der falschen Abfrage von sy-subrc wird der in der Dokumentation emp-fohlene logische Ausdruck IS ASSIGNED verwendet. Die Meldung der erweiter-ten Programmprüfung wäre zwar auch durch einen Pseudokommentar "#ECRC_READ oder ein Pragma ##SUBRC_READ (seit den Releases 7.0 EhP2 und 7.2)ausblendbar, aber das wird in einem solchen Fall wie hier gerade nicht emp-fohlen, da die erweiterte Programmprüfung auf ein echtes Problem hinweist.

Abbildung 3.6 Erweitere Programmprüfung ohne Meldung



75

3.4.3 Code Inspector

Hintergrund

Der Code Inspector ist ein Werkzeug zur statischen Überprüfung von Reposi-tory-Objekten bezüglich Performance, Sicherheit, Syntax und der Einhaltungvon Namenskonventionen. Der volle Funktionsumfang des Code Inspectorskann über die Transaktion SCI verwendet werden, um komplexe statische Prü-fungen sowie regelmäßige Massentests für große Mengen von Entwicklungs-objekten auszuführen.

Der Code Inspector kann auch aus der ABAP Workbench heraus aufgerufenwerden, um eine Standardmenge an Prüfungen für ihr aktuelles Objekt durch-zuführen, wie zum Beispiel über den Menüpfad Programm � Prüfen � Code

Inspector des ABAP Editors. Die hierbei verwendete Standardprüfvarianteenthält die meisten Prüfungen der erweiterten Programmprüfung (sieheAbschnitt 3.4.2) sowie einige weitere Sicherheits- und Performanceprüfungen.Weiterhin kann der Code Inspector in die Freigabe von Transporten eingebun-den werden.

Wie bei der erweiterten Programmprüfung sind auch die Ergebnisse des CodeInspectors in die drei Kategorien Fehler, Warnungen und einfache Meldungenunterteilt und können mit speziellen Pseudokommentaren ausgeblendet wer-den.

Regel

Details

Wird Regel 3.7, »Erweiterte Programmprüfung verwenden«, beachtet, meldetdie Standardprüfvariante des Code Inspectors nur noch Meldungen von Prü-fungen, die über die erweiterte Programmprüfung hinausgehen. Dies sind imWesentlichen Meldungen über eventuelle Performance- oder Sicherheitsrisi-ken in Programmen. Beispiele sind Meldungen über ungünstige WHERE-Bedin-gungen beim SELECT, die Wertübergabe statt der Referenzübergabe von Para-metern oder unsichere Programmaufrufe.

Diese Probleme sind, verglichen mit den Meldungen der erweiterten Pro-grammprüfung, nicht immer so einfach an der Ursache zu korrigieren, bei-

Regel 3.8: Standardprüfvariante des Code Inspectors verwenden

Führen Sie die Standardprüfvariante des Code Inspectors vor der Freigabe eines Pro-gramms aus, und beseitigen Sie sämtliche Fehlermeldungen.



76

spielsweise weil es keine andere Möglichkeit für eine Selektion gibt oder dieÜbersichtlichkeit oder Robustheit eines Konstruktes als wichtiger als ein even-tueller kleiner Performanceverlust angesehen wird.

In solchen Fällen können die Meldungen mit den passenden Pseudokommen-taren unterdrückt werden. Ein solcher Pseudokommentar drückt für den Leserdes Programms klar aus, dass der Programmautor die entsprechenden Über-prüfungen durchgeführt hat und er die Meldung bewusst und aus guten Grün-den unterdrückt. Letzteres kann, wo notwendig, durch zusätzliche normaleKommentare erhärtet werden (siehe Abschnitt 4.3).

Schlechtes Beispiel

Abbildung 3.7 zeigt das Ergebnis eines Code-Inspector-Laufs für eine Beispiel-klasse. Es werden Warnungen ausgegeben, weil eine interne Tabelle per Wert-übergabe zurückgegeben und in der SELECT-Anweisung ein Inner Join fürDatenbanktabellen mit eingeschalteter SAP-Pufferung verwendet wird.

Abbildung 3.7 Warnungen des Code Inspectors



77

Gutes Beispiel

Abbildung 3.8 zeigt die korrigierte Fassung des Programms aus Abbildung 3.7,für die der Code Inspector keine Meldungen mehr ausgibt.

Die Wertübergabe der internen Tabelle wurde durch eine Referenzübergabeersetzt. Bei der Übergabe des elementaren Parameters langu wurde die Wert-übergabe aus Gründen der Robustheit belassen. In der verwendeten Standard-prüfung hatte sie auch keine Warnung erzeugt. Wenn der Code Inspector ineinem solchen Fall eine Warnung anzeigt, kann sie mit dem Pseudokommentar"#EC CI_VALPAR ausgeblendet werden.

Der Inner Join der SELECT-Anweisung umgeht die SAP-Pufferung, was beieinem häufigen Aufruf der Methode zu Performanceproblemen führen würde.Wenn wir für das gezeigte Beispiel aber annehmen, dass die Methode Teileiner größeren Anwendung ist, in der selbst für eine Pufferung der ausgewähl-ten Daten über Shared Objects gesorgt wird, ist die Verwendung des InnerJoins anderen weniger performanten Konstrukten, wie zum Beispiel einer

Abbildung 3.8 Code-Inspektion ohne Meldungen



78

geschachtelten SELECT-Schleife, vorzuziehen. Deshalb wird die Warnung desCode Inspectors über den Pseudokommentar "#EC CI_BUFFJOIN ausgeblendetund die Gründe hierfür über einen normalen Kommentar erläutert.

3.4.4 ABAP-Testcockpit

Hintergrund

Seit den Releases 7.0 EhP2 und 7.2 ist mit dem ABAP-Testcockpit (ATC) zurSAP-internen Verwendung ein Framework in die ABAP Workbench integriert,das den entwicklungsnahen Umgang mit den notwendigen Tests erheblicherleichtert. Das ATC erlaubt die Ausführung und Ergebnisanzeige verschiede-ner Tests für Entwicklungsobjekte, wie beispielsweise:

� erweiterte Programmprüfungen

� statische Performanctests

� Modultests mit ABAP Unit

� statische Bedienbarkeitstests

� Paketprüfungen

Während der Code Inspector nur über die in Abschnitt 3.4.3 aufgeführte Stan-dardprüfung in die Entwicklungsumgebung integriert ist und ansonsten nurüber eine eigene Transaktion bedienbar ist, ist das ATC vollständig in denObject Navigator und den Transport Organizer integriert und steht dort fürentwicklungsbegleitende Tests zur Verfügung. Qualitätsmanagern erlaubt dasATC die Durchführung von Massentests. Das ABAP-Testcockpit steht vorerstaber nur bei SAP selbst und eventuell bei SAP-Partnern für die Entwicklungvon SAP-Programmen zur Verfügung.

Regel

Details

Mit dem ATC steht erstmals ein Werkzeug zur Verfügung, das von SAP-Ent-wicklern und im Rahmen einer zentralen Qualitätssicherung gleichermaßen

Regel 3.9: ABAP-Testcockpit richtig konfigurieren und verwenden

Ist das ABAP-Testcockpit in Ihrem System verfügbar, stellen Sie vor einer Transport-freigabe sicher, dass ein ATC-Lauf über alle beteiligten Entwicklungsobjekte hinwegkeine Meldungen mehr anzeigt. Hierzu sollte die ATC-Prüfung direkt in die Trans-portfreigabe eingebunden werden.



79

verwendet werden kann. Überprüft ein Entwickler beispielsweise alle Entwick-lungsobjekte eines Paketes im Entwicklungssystem mit der gleichen ATC-Kon-figuration, wie ein Qualitätsmanager es im Rahmen eines Massenlaufs in einemKonsolidierungssystem tut, kann er alle Meldungen im Vorfeld verhindern,ohne auf Rückmeldungen vom Qualitätsmanager warten zu müssen.

Ist das ATC vorhanden und richtig konfiguriert, schließt Regel 3.9 die vorher-gehenden Regeln 3.6, 3.7 und 3.8 mit ein.

Ausnahme

Das ATC steht derzeit noch nicht für Entwicklungen in Kundensystemen zurVerfügung.

Schlechtes Beispiel

Abbildung 3.9 zeigt das Ergebnis der Ausführung eines ATC-Laufs im TransportOrganizer. Der geprüfte Transportauftrag enthält noch fehlerhafte Objekte.

Abbildung 3.9 Warnung des ABAP-Testcockpits



80

Gutes Beispiel

Abbildung 3.10 zeigt das Ergebnis eines ATC-Laufs im Transport Organizernach Behebung des Fehlers aus Abbildung 3.9. Jetzt kann der Transport freige-geben werden.

Abbildung 3.10 ABAP-Testcockpit ohne Meldungen


389

Index

& � Literaloperator&& � Verkettungsoperator<, Schreibweise 139<=, Schreibweise 139=, Schreibweise 139, 147=<, obsolet 361=> � Klassenkomponentenselektor=>, obsolet 361-> � Instanzkomponentenselektor>, Schreibweise 139><, obsolet 361>=, Schreibweise 139?=, Schreibweise 147?TO, Schreibweise 1474GL-Sprache, Hintergrund 162

A

ABAP-AnweisungAnordnung 85Beispiel 87Schreibweise 138

abap_boolHintergrund 247Verwendung 247

ABAP Database Connectivity � ADBCABAP Dictionary

Hintergrund 226Verwendung 228

abap_falseHintergrund 247Verwendung 247

ABAP ObjectsBeispiel 50Hintergrund 43Regel 44

ABAP-Programmierungklassisch 27objektorientiert 159

ABAP-SprachmittelBeispiel 165Hintergrund 64Koexistenz 67Regel 65Verwendung 163

ABAP-Testcockpit � ATCabap_true

Hintergrund 247Verwendung 247

abap_undefinedVerwendung 248

ABAP UnitModultest 40

ABAP-WortNamensgebung 110

AbbruchmeldungVerwendung 199

abfangbarer LaufzeitfehlerHintergrund 193obsolet 360Regel 194

AbwärtskompatibilitätHintergrund 65

ADBCHintergrund 216Verwendung 217

ADDVerwendung 147

ADD FROMobsolet 364

ADD THENobsolet 364

ADD-CORRESPONDINGobsolet 364

aktivierbare AssertionVerwendung 196

ALVHintergrund 209

ALV-ListeBeispiel 211

anonymer ContainerHintergrund 267Regel 267

anonymes DatenobjektBeispiel 339dynamisches Speicherobjekt 325Hintergrund 223

AnwendungslogikTrennung der Belange 31


390

Index

AnwendungspufferBeispiel 221Hintergrund 219Verwendung 220

arithmetischer AusdruckBeispiel 152Schreibweise 148

ASCII-ZeichensatzVerwendung 346

ASSERTHintergrund 195Verwendung 196

AssertionBeispiel 196Hintergrund 177, 195Regel 195Verwendung 178, 199

ASSIGNdynamischer Zugriff 332Verwendung 333

ASSIGN DECIMALSobsolet 363

ASSIGN LOCAL COPY OFobsolet 358

ASSIGN TABLE FIELDobsolet 364

ASSIGN TYPEobsolet 363

ASSIGNINGBeispiel 295dynamischer Zugriff 332Verwendung 294

AT LINE-SELECTIONHintergrund 314

AT PFnnobsolet 370

AT SELECTION-SCREENHintergrund 314Verwendung 315

AT USER-COMMANDHintergrund 314

ATCBeispiel 79, 80Hintergrund 78Regel 78Verwendung 78

AtomisierungBeispiel 164

AusdruckKomplexität 151Regel 151

ausführbares ProgrammProgrammtyp 53Regel 55Trennung der Belange 26Verwendung 57

AusgabeparameterHintergrund 299

AusnahmeHintergrund 177Namensgebung 100Verwendung 178

AusnahmebehandlungHintergrund 179Regel 180Remote Function Call 181

AusnahmekategorieHintergrund 183Regel 184

AusnahmeklasseBeispiel 188, 189Hintergrund 187Regel 188Verwendung 188

AusnahmetextBeispiel 187Hintergrund 185Regel 185

B

BAdINamenskonvention 105

BarrierefreiheitProduktstandard 37, 212Regel 212

benanntes DatenobjektHintergrund 223

BenutzerfreundlichkeitProduktstandard 38

BerechnungHintergrund 249Regel 147Schreibweise 147

BETWEENSchreibweise 139


391

Index

BezeichnerBeispiel 102, 103, 107Hintergrund 96Regel 97

BezeichnerspracheBeispiel 96Hintergrund 95Regel 95

binäre GleitpunktzahlBeispiel 260Hintergrund 257Verwendung 259

Bit-AusdruckSchreibweise 148

BOMOPEN DATASET 348Textdatei 348

Boolescher DatentypHintergrund 247

Boxed ComponentHintergrund 234Verwendung 328

Browser ControlVerwendung 213

BSPVerwendung 202

Business Add-In � BAdIBusiness Server Pages � BSPByte-Order Mark � BOMBytestring

Hintergrund 243

C

CALL CUSTOMER SUBSCREENobsolet 369

CALL CUSTOMER-FUNCTIONobsolet 359

CALL DIALOGobsolet 359

CALL FUNCTION IN UPDATE TASKVerwendung 47

CALL METHODRegel 145

CALL SCREENHintergrund 200Verwendung 47

CALL SELECTION-SCREENHintergrund 200

CALL SELECTION-SCREEN (Forts.)Verwendung 47

CALL TRANSACTIONProgrammausführung 54

CALL TRANSFORMATIONVerwendung 268

Camel Case StyleBeispiel 84Verwendung 83

CASEKomplexität 153obsolet 361

CASTINGASSIGN 263Beispiel 265Hintergrund 263implizites 264Regel 264Verwendung 333

CATCHHintergrund 190

CATCH SYSTEM-EXCEPTIONSBeispiel 194Hintergrund 193obsolet 360Verwendung 194

CHANGINGBeispiel 301Hintergrund 299Namenskonvention 109Verwendung 300

CHECKBeispiel 313Hintergrund 312Verwendung 312

Checkpoint-GruppeAssertion 195, 196

CL_JAVA_SCRIPTobsolet 374

Class-Poollokale Deklaration 173Programmtyp 53Regel 55Verwendung 56

CLEANUPBeispiel 193Hintergrund 191Regel 192


392

Index

CLEANUP (Forts.)Verwendung 192

CLEARVerwendung 327

CLEAR WITH NULLobsolet 363

CLIENT SPECIFIEDVerwendung 218

Code InspectorBeispiel 76, 77Fehler 75Hintergrund 75Meldung 75Namenskonvention 375Pseudokommentar 75Regel 75Verwendung 75Warnung 75

CodepageTextdatei 348

COLLECTHintergrund 292Regel 293Verwendung 293

COMMON PARTobsolet 355

COMMUNICATIONobsolet 374

COMPUTEBeispiel 149, 150Regel 149

COMPUTE EXACTVerwendung 149

CONSTANTSHintergrund 226

constructorMETHODS 175

CONTEXTSobsolet 373

CONTROLSVerwendung 232

CONVERT DATEobsolet 365Verwendung 252

CONVERT TIME STAMPVerwendung 252

Coverage AnalyzerTestabdeckung 40

CREATE AREA HANDLEVerwendung 220

CREATE DATAdynamischer Zugriff 332Regel 336

CREATE-ZusatzCLASS DEFINITION 175

CX_DYNAMIC_CHECKHintergrund 183Regel 191

CX_NO_CHECKHintergrund 183Regel 191

CX_ROOTRegel 191

CX_STATIC_CHECKHintergrund 183Regel 191

D

DATAVerwendung 232

DATA COMMON PARTSchnittstellen-Arbeitsbereich 310

DateiHintergrund 214Verwendung 215

DatenbanktabelleHintergrund 214Verwendung 214

DatenbankzugriffHintergrund 216Regel 216

Daten-ClusterVerwendung 215

DatenkapselungABAP Objects 44

DatenobjektBezug auf 237Hintergrund 223

DatenreferenzBeispiel 334dynamischer Zugriff 332Regel 333Verwendung 333

DatentypBeispiel 236, 280Bezug auf 237


393

Index

Datentyp (Forts.)Hintergrund 223, 226, 235Namensgebung 98Namenskonvention 114Regel 225, 227, 235

DatumsfeldHintergrund 251Verwendung 251

DeklarationKettensatz 141

DELETE dbtabobsolet 373

DEMANDobsolet 373

DereferenzierungVerwendung 333

DESCRIBE FIELDVerwendung 336

DETAILobsolet 369

dezimale GleitpunktzahlBeispiel 261Hintergrund 257Verwendung 259

DialogmodulHintergrund 297, 314Regel 315Verwendung 47, 206

DialognachrichtVerwendung 198

DialogprogrammBeispiel 207Trennung der Belange 26

DialogtransaktionProgrammausführung 54Verwendung 47

DIVIDEVerwendung 147

DIVIDE-CORRESPONDINGobsolet 364

DOKomplexität 153

DO VARYINGobsolet 362

DokumentationMittel 40Produktstandard 37

Doppelpunkt-Komma-Logik � Kettensatz

DrucklisteHintergrund 209

Druckparameterobsolet 370

dynamische ProgrammierungBeispiel 322, 323Hintergrund 319Regel 320Verwendung 320

dynamische Token-AngabeBeispiel 339Hintergrund 335Verwendung 322, 336

dynamischer AufrufHintergrund 319, 335Verwendung 322

dynamischer ZugriffHintergrund 319, 332, 335Regel 333Verwendung 322, 333

dynamisches DatenobjektHintergrund 323Regel 324Verwendung 322

dynamisches SpeicherobjektBeispiel 328Besetzung 331Hintergrund 319Regel 326, 330Speicherverbrauch 325Verwaltung 329

DynproBeispiel 203, 207Hintergrund 200Regel 205Verwendung 202, 310

E

eCATTSzenarientest 40

EDITOR-CALLobsolet 366

eigenständiger DatentypBeispiel 226Hintergrund 224

EingabeparameterHintergrund 299


394

Index

EinrückungKommentar 124Verwendung 89

einsprachige EntwicklungRegel 62

ENCODINGOPEN DATASET 348

END-OF-SELECTIONHintergrund 314Programmausführung 55

EnglischBezeichnersprache 95Entwicklungssprache 63Kommentarsprache 119Verwendung 95

EntwicklungsspracheHintergrund 62

EQSchreibweise 139

EreignisABAP Objects 45Namensgebung 99

EreignisbehandlerNamensgebung 99

EreignisblockHintergrund 297, 314Regel 315Verwendung 47

error_messageVerwendung 198

erweiterte ProgrammprüfungBeispiel 73, 74Fehler 72Hintergrund 71Meldung 72Regel 72Verwendung 72Warnung 72

EXACTCOMPUTE 149MOVE 254

Exclusive BufferVerwendung 220

EXITHintergrund 312Verwendung 312

Exit-MeldungVerwendung 199

EXPORTSchreibweise 139

EXPORT TO DATA BUFFERVerwendung 268, 324

EXPORT TO INTERNAL TABLEVerwendung 325

EXPORTINGBeispiel 300, 305Hintergrund 299Namenskonvention 109Referenzübergabe 303Regel 304Verwendung 300, 304

externer ProzeduraufrufHintergrund 308

F

FehlerCode Inspector 75erweiterte Programmprüfung 72

FehlermeldungVerwendung 198

FehlersituationBehandlung 177Regel 177

FeldsymbolBeispiel 334dynamischer Zugriff 332Regel 333Typisierung 307Verwendung 333

FestpunktarithmetikProgrammattribut 58Regel 58Verwendung 59

FIELD (Dynpro)obsolet 368

FIELDSobsolet 358

FIELD-SYMBOLSDeklaration 231obsolet 356

finale KlasseVerwendung 171

FINDSchreibweise 140

FORMobsolet 354


395

Index

FormalparameterArt 299Regel 299, 302Typisierung 305Übergabe 301

FORMATHintergrund 201

FREEVerwendung 327

Function-PoolProgrammtyp 53

funktionale KorrektheitProduktstandard 37

funktionale MethodeNamensgebung 99, 113

FunktionsbausteinHintergrund 297Regel 298Verwendung 47, 309

FunktionsgruppeBeispiel 48, 232globaler Deklarationsteil 130Komplexität 156Programmtyp 53Regel 55Verwendung 56, 205

G

Garbage CollectorVerwendung 327

GESchreibweise 139

gebundener DatentypBeispiel 226Hintergrund 224

GENERATE SUBROUTINE POOLHintergrund 335Verwendung 47

generische ProgrammierungHintergrund 320, 335Regel 336Verwendung 322

generische TypisierungBeispiel 307Hintergrund 306

generischer DatentypHintergrund 306

gepackte ZahlHintergrund 257Verwendung 258

GETHintergrund 314Programmausführung 55

GET REFERENCEdynamischer Zugriff 332

GleitpunktzahlHintergrund 258

globale AusnahmeklasseNamenskonvention 105

globale DeklarationAnordnung 128Beispiel 129, 130Top-Include 128

globale Klasselokale Deklaration 173Namenskonvention 105Verwendung 227

globale VariableVerwendung 231

globaler DeklarationsteilHintergrund 127Regel 127

globales DatenobjektHintergrund 268Namensgebung 113Namenskonvention 109

globales InterfaceNamenskonvention 105

GlobalisierungProduktstandard 37, 340

Groß-/KleinschreibungBeispiel 84Hintergrund 82Regel 83Verwendung 83, 90

GTSchreibweise 139

GUI-StatusVerwendung 310

GUI-TitelÜbersetzbarkeit 343

gültiger WertBeispiel 252Hintergrund 250Regel 251


396

Index

GültigkeitsbereichNamenskonvention 114

H

Hash-SchlüsselHintergrund 285Verwendung 287

Hash-TabelleHintergrund 282Tabellenart 283Verwendung 285

HauptprogrammHintergrund 309

HauptprogrammgruppeHintergrund 309

Headerdynamisches Speicherobjekt 329

HEADER LINEobsolet 357

HilfsvariableBeispiel 152, 238Deklaration 237Verwendung 151

HintergrundverarbeitungVerwendung 47

I

IFKomplexität 153

IMPORTSchreibweise 139

IMPORTINGHintergrund 299Namenskonvention 109Verwendung 300

INSchreibweise 139

INCLUDE STRUCTUREHintergrund 233Verwendung 233

INCLUDE TYPEBeispiel 234Hintergrund 233Verwendung 233

Include-ProgrammBeispiel 137Hintergrund 134, 136

Include-Programm (Forts.)Mehrfachverwendung 136Regel 134, 136Verwendung 134, 229

IndextabelleTabellenart 283Verwendung 285

INDXVerwendung 215

InformationsnachrichtVerwendung 198

INITIAL SIZEBeispiel 290Hintergrund 289Regel 289Verwendung 289

INITIALIZATIONHintergrund 314Verwendung 315

INPUTobsolet 369

INSERT REPORTHintergrund 335

InstanzierungABAP Objects 44

InstanzkomponenteHintergrund 166

InstanzkomponentenselektorNamensgebung 112, 113

InstanzkonstruktorHintergrund 175Regel 176Verwendung 167

IntegerzahlHintergrund 257Verwendung 258

intenationale EntwicklungEntwicklungssprache 63

InterfaceABAP Objects 45Namensgebung 98Verwendung 171

Interfacekomponenten-SelektorBeispiel 172Hintergrund 171Regel 171Verwendung 172

Interface-PoolProgrammtyp 53


397

Index

Interface-Pool (Forts.)Regel 55Verwendung 56

Interface-ReferenzvariableBeispiel 172Hintergrund 171Regel 171

InternationalisierungHintergrund 340Produktstandard 37

interne TabelleAusgabeverhalten 293befüllen 291, 292dynamisches Datenobjekt 323Hintergrund 281Schleifenverarbeitung 296Sekundärschlüssel 285Speicherbedarf 289Tabellenart 283Verwendung 324

interner ProzeduraufrufHintergrund 308

INTOREAD TABLE, LOOP AT 294

IS ASSIGNEDSchreibweise 139

IS BOUNDSchreibweise 139

IS INITIALSchreibweise 139

IS REQUESTEDobsolet 361

IS SUPPLIEDSchreibweise 139

J

Java-KonventionVerwendung 84

K

KapselungHintergrund 160Regel 161

kaufmännische NotationHintergrund 255

KettensatzHintergrund 141

Kettensatz (Forts.)Regel 141Verwendung 141

KISS-PrinzipBeispiel 35Hintergrund 34Regel 34

KlasseKomplexität 155Namensgebung 98

klassenbasierte AusnahmeBehandlung 189Beispiel 182Hintergrund 179Regel 190Verwendung 180Weiterleitung 189

KlassengrößeHintergrund 155Regel 156

KlassenkomponenteNamensgebung 112

KlassenkomponentenselektorNamensgebung 112

KlassenreferenzvariableHintergrund 171Verwendung 172

klassische AusnahmeBeispiel 181Hintergrund 179Verwendung 180

klassische ListeBeispiel 211Hintergrund 209Verwendung 210

KleinschreibungBeispiel 90

kombinierende ZeichenHintergrund 347

KommentarAnordnung 123Beispiel 122, 125, 126Hintergrund 118Pseudokommentar 124Regel 121Übersetzbarkeit 340Verwendung 120, 152

KommentarspracheBeispiel 119, 120


398

Index

Kommentarsprache (Forts.)Hintergrund 118Regel 118

KommentarzeileHintergrund 118

KompilationseinheitHintergrund 134

KomplexitätFunktionsgruppe 156Hintergrund 150Klasse 155Kontrollstruktur 153Prozedur 154toter Code 157

KonstanteBeispiel 229, 243Hintergrund 226Namensgebung 99Regel 227Verwendung 241

KontextNamenskonvention 114

KontrollstrukturKettensatz 143Kommentar 123Komplexität 153

KonvertierungBeispiel 250Hintergrund 249Regel 249

KonvertierungsregelHintergrund 253Regel 253

KopfkommentareVerwendung 122

KundennamensraumBezeichner 104

Kurzform (Daten-Cluster)obsolet 372, 373

Kurzform (interne Tabelle)obsolet 366

Kurzform (Open SQL)obsolet 371

L

LaufzeitanalysePerformancetest 40

LaufzeitfehlerBeispiel 266Hintergrund 265, 321Regel 266, 321

LESchreibweise 139

LEAVEobsolet 360

LEAVE PROGRAMVerwendung 199

LEAVE TO LIST-PROCESSINGHintergrund 201

LEAVE TO TRANSACTIONProgrammausführung 54

LeerzeilenVerwendung 89

LENGTHSchreibweise 139

LIKEHintergrund 237Regel 237Verwendung 237

LIKE LINE OFRegel 237

LIKE-Bezugobsolet 356

ListeHintergrund 200, 209Regel 210Verwendung 202

LiteralHintergrund 240Regel 241

LiteraloperatorBeispiel 93Verwendung 92

LOADobsolet 358

LoaderVerwendung 220

LOAD-OF-PROGRAMHintergrund 314Verwendung 315

LOCALobsolet 363

LocaleTextumgebung 344

logische DatenbankProgrammattribut 58


399

Index

logische Datenbank (Forts.)Regel 58Verwendung 59

lokale DeklarationAnordnung 131Beispiel 132, 133Gültigkeit 132Hintergrund 131Regel 131, 174Verwendung 173, 227

lokale KlasseDeklaration 129globale Klasse 173Namensgebung 113Verwendung 157, 206, 227, 310

lokaler BezeichnerNamensgebung 112

lokaler Datentypglobale Klasse 173

lokales InterfaceDeklaration 129globale Klasse 173Namensgebung 113

LokalisierungProduktstandard 37

LokatorVerwendung 327

LOOPKomplexität 153

LOOP (Dynpro)obsolet 369

LOOP ATHintergrund 293Regel 294

LOOP AT dbtabobsolet 373

LTSchreibweise 139

M

MAJOR-IDobsolet 372

MakroBeispiel 318Hintergrund 297, 316Regel 316Verwendung 317

MandantenbehandlungBeispiel 218, 219Hintergrund 217Regel 218

mathematische NotationHintergrund 255Verwendung 256

MAXIMUMobsolet 371

mehrsprachige EntwicklungRegel 62

MeldungCode Inspector 75erweiterte Programmprüfung 72

Memory InspectorSpeichertest 40Verwendung 328

MESSAGEHintergrund 197Verwendung 178

MethodeHintergrund 297Namensgebung 99Verwendung 309

MethodenaufrufBeispiel 145, 146Kurzform 145Langform 145Regel 145Schreibweise 145

MINIMUMobsolet 371

MINOR-IDobsolet 372

Mixed Case StyleBeispiel 84Verwendung 83

moderne SprachmittelBeispiel 66Hintergrund 64Verwendung 65

MODIFYBeispiel 295Regel 294

MODIFY dbtabobsolet 373

ModularisierungHintergrund 162Regel 162


400

Index

MODULEHintergrund 314

Modul-PoolProgrammtyp 53Regel 55Trennung der Belange 26Verwendung 57

MOVEBeispiel 148Verwendung 147

MOVE PERCENTAGEobsolet 362

MULTIPLYVerwendung 147

MULTIPLY-CORRESPONDINGobsolet 364

N

NachrichtAusnahmetext 198Hintergrund 177, 197Regel 198Übersetzbarkeit 342Verwendung 178

NachrichtentextAusnahmetext 186

NachrichtentypHintergrund 197

NamensgebungAbkürzung 100Beispiel 107, 116Hintergrund 93, 96Namensraum 110Präfix 114Programmobjekt 108Regel 97Repository-Objekt 104Suffix 114Verschattung 111Ziffer 101

NamenskonventionHintergrund 94Repository-Objekt 105Überprüfung 375

NamensraumpräfixVerwendung 107

Native SQLHintergrund 216

Native SQL (Forts.)Verwendung 217

NEW-SECTIONobsolet 370

nmax (Eingebaute Funktion)Verwendung 154

nmin (Eingebaute Funktion)Verwendung 154

NODESHintergrund 239Schnittstellen-Arbeitsbereich 310Verwendung 240

NOTSchreibweise 139

NulldivisionBeispiel 263Hintergrund 262Regel 263

numerischer TextHintergrund 251

numerischer TypHintergrund 257Regel 258

O

OberflächentechnologieHintergrund 200Kapselung 204Regel 201

OberklasseHintergrund 170

ObjektRegel 166

ObjekterzeugungVerwendung 167

Objektheaderdynamisches Speicherobjekt 329

ObjektorientierungDesign 159, 166Verwendung 161

obsolete SprachmittelBeispiel 66Hintergrund 64, 353Verwendung 65

OCCURSobsolet 357

ON CHANGE OFobsolet 361


401

Index

Online Text Repository � OTROO-Transaktion

Programmausführung 54Verwendung 56

OPEN DATASETRegel 348

Open SQLHintergrund 216Kettensatz 144Verwendung 216

operationale AnweisungKettensatz 142

OperatorenschreibweiseVerwendung 147

OriginalspracheHintergrund 62Regel 62

orthogonales KonzeptABAP Objects 45

OTRAusnahmetext 186

P

PACKobsolet 362

PACKAGE SECTIONRegel 161

PACKAGE SIZEVerwendung 327

PAI-ModulVerwendung 206

PaketHintergrund 104Namensgebung 98Namenskonvention 106

PaketkonzeptVerwendung 31, 106, 171, 215

PaketprüfungSyntaxprüfung 70

PaketschnittstelleNamensgebung 98

PARAMETERSHintergrund 200Verwendung 232

ParameterschnittstelleHintergrund 299

PBO-ModulVerwendung 206

PERFORMobsolet 359

PERFORM IN PROGRAMHintergrund 308

PERFORM ON COMMITVerwendung 47

PERFORM ON ROLLBACKVerwendung 47

PerformanceProduktstandard 38

PerformancetestCode Inspector 75

PERFORMINGobsolet 371

PersistenzHintergrund 214Regel 214Trennung der Belange 31

PolymorphieVerwendung 171

PrädikatSchreibweise 139

PräfixnamensraumBezeichner 104

Pragmaerweiterte Programmprüfung 72Syntaxprüfung 70Verwendung 72

Pretty PrinterBeispiel 85, 87Groß-/Kleinschreibung 83Hintergrund 88Regel 88Verwendung 89

PrimärschlüsselBeispiel 288Hintergrund 282

PRIVATE SECTIONglobale Klasse 173

ProduktstandardBeispiel 41Hintergrund 37Regel 39

Programmausführbares 26

ProgrammattributHintergrund 58Regel 58


402

Index

ProgrammaufbauHintergrund 81

ProgrammgenerierungBeispiel 338Hintergrund 335Verwendung 337

ProgrammgruppeHintergrund 309

ProgrammierstilHintergrund 81

ProgrammobjektNamensgebung 108Namensregel 109

ProgrammtypHintergrund 53Regel 55

PROVIDEobsolet 368

Proxy ServiceTrennung der Belange 31

ProzedurHintergrund 297Komplexität 154Namensgebung 99Regel 298verlassen 312Verwendung 309

ProzeduraufrufHintergrund 308Programmausführung 54Regel 309

ProzedurvolumenBeispiel 155Hintergrund 154Regel 154

PseudokommentarBeispiel 77Code Inspector 75erweiterte Programmprüfung 72Verwendung 72, 76

PUBLIC SECTIONRegel 161

R

RahmenprogrammHintergrund 134Quelltextmodularisierung 135

RAISEVerwendung 180

RAISE EXCEPTIONVerwendung 181

RAISINGMESSAGE 197, 199

RANGESobsolet 358

READobsolet 367

READ DATASETSchreibweise 140

READ TABLEHintergrund 293Regel 294

READ TABLE dbtabobsolet 373

RechenausdruckSchreibweise 148

RechentypHintergrund 249

RedefinitionHintergrund 170Verwendung 167

REFERENCE INTOdynamischer Zugriff 332Verwendung 294

Referenzsemantikdynamischer Zugriff 332Verwendung 333

ReferenzübergabeBeispiel 269Hintergrund 268, 302Regel 268Verwendung 302

REFRESHobsolet 367

REFRESH FROM dbtabobsolet 373

REJECTVerwendung 313

remotefähiger Funktionsbaustein � RFMREPLACE

obsolet 365Schreibweise 140

REPLACE ... ALL OCCURENCESVerwendung 153

REPORT 26Beispiel 27


403

Index

REPORT (Forts.)klassisch 28Trennung der Belange 31

Repository-ObjektNamensgebung 104Namenskonvention 105

RESUMABLEVerwendung 185

RESUMEVerwendung 180

RETURNBeispiel 313Hintergrund 312Regel 312

RETURNINGHintergrund 299Namenskonvention 109Verwendung 300

RFCVerwendung 47

RFMBeispiel 27Verwendung 56

ROLLBACK WORKVerwendung 199

RTTCVerwendung 336

RTTIVerwendung 336

RTTSVerwendung 336

RückgabewertHintergrund 299

Run Time Type Creation � RTTCRun Time Type Information � RTTIRun Time Type Services � RTTSRundungsfehler

Beispiel 262Hintergrund 261Regel 261

S

SAP GUIHintergrund 200

SAP List Viewer � ALVSAP-Namensraum

Bezeichner 104

SAP-PufferungHintergrund 219

SchachtelungstiefeBeispiel 154Hintergrund 153Regel 153

Schnittstellen-ArbeitsbereichBeispiel 311Verwendung 310

SchnittstellenparameterNamensgebung 98Namenskonvention 115

SchreibweiseBeispiel 140Regel 139

SCI � Code InspectorSEARCH

obsolet 365Sekundärschlüssel

Beispiel 288Regel 286Verwendung 286

SELECT (Dynpro)obsolet 368

SELECTION-SCREENHintergrund 200

SELECT-OPTIONSHintergrund 200Verwendung 232

SelektionsbildBeispiel 207Hintergrund 200Regel 205Verwendung 202

SelektionsbildereignisVerwendung 47, 206

Separation of Concerns � Trennung der Belange

serviceorientierte Architektur � SOASET EXTENDED CHECK OFF

Regel 73SET LOCALE

Beispiel 345Regel 344Textumgebung 344

SHARED BUFFERVerwendung 220

SHARED MEMORYHintergrund 219


404

Index

SHARED MEMORY (Forts.)Regel 219Verwendung 220

Shared ObjectsBeispiel 221Hintergrund 219Verwendung 220

SharingDetails 302Hintergrund 243

SicherheitCode Inspector 75Produktstandard 38

SingletonBeispiel 168Hintergrund 166Verwendung 166

SLINerweiterte Programmprüfung 71

SOATrennung der Belange 26

SoC � Trennung der BelangeSORT

Verwendung 291SORTED BY

Hintergrund 291Regel 291Verwendung 291

sortierte TabelleHintergrund 282Tabellenart 283Verwendung 284

sortierter SchlüsselHintergrund 285Verwendung 287

SPLITVerwendung 347

SpracheTextumgebung 344

StandardkommentarVerwendung 89

StandardprüfvarianteCode Inspector 75

Standard-SelektionsbildVerwendung 207

StandardtabelleHintergrund 282Tabellenart 283Verwendung 284

START-OF-SELECTIONHintergrund 314Programmausführung 55Verwendung 47, 57, 315

StartwertBeispiel 246Hintergrund 245Regel 246

statische KlasseBeispiel 168Hintergrund 166Polymorphie 167Regel 166Verwendung 167

statische KomponenteHintergrund 166

statischer KonstruktorVerwendung 167

StatusmeldungVerwendung 198

STOPVerwendung 313

StreamingVerwendung 327

Stringdynamisches Datenobjekt 323dynamisches Speicherobjekt 325Hintergrund 243Regel 244Verwendung 324

Stringheaderdynamisches Speicherobjekt 329

StringliteralHintergrund 241

STRUCTURE-Typisierungobsolet 355, 357

strukturierte ProgrammierungHintergrund 162Verwendung 163

SUBMITProgrammausführung 54Verwendung 315

SUBMIT VIA JOBVerwendung 47

Subroutinen-PoolProgrammtyp 54Regel 55Verwendung 56


405

Index

SUBTRACTVerwendung 147

SUBTRACT-CORRESPONDINGobsolet 364

SUMMARYobsolet 369

SUMMINGobsolet 371

SUPPLYobsolet 373

Surrogat-BereichHintergrund 347

syHintergrund 270

sy-indexVerwendung 274

sy-mandtVerwendung 218

SyntaxbereinigungABAP Objects 45

SyntaxfehlerHintergrund 68

SyntaxprüfungBeispiel 71Hintergrund 68Prüfschärfe 69Verwendung 69

SyntaxwarnungBeispiel 70Hintergrund 68Priorität 68Regel 69

SYSTHintergrund 270

System-CodepageTextumgebung 344

SystemfeldAktualparameter 276Auswertung 273Beispiel 271, 272, 274, 277, 278, 279,

281Benutzeroberfläche 278Hintergrund 270, 272Operandenposition 280Regel 270, 272, 273, 277, 278, 280Verwendung 271, 272, 273, 277, 279,

280Zugriff 270

SystemtextHintergrund 340

sy-subrcBeispiel 276Hintergrund 275Regel 275Verwendung 274, 275

sy-tabixVerwendung 274, 288

T

TabellenarbeitsbereichHintergrund 239Regel 239

TabellenartHintergrund 282Regel 284

Tabellenheaderdynamisches Speicherobjekt 329

TabellenindexHintergrund 282

Tabellenkörperdynamisches Speicherobjekt 325Hintergrund 296Regel 296Verwendung 296

TABLESHintergrund 239obsolet 354, 356Schnittstellen-Arbeitsbereich 310Verwendung 232, 240, 300

technisch-wissenschaftliche NotationHintergrund 255

TechnologiezugangABAP Objects 46

TeilfeldzugriffHintergrund 266Verwendung 347

TerminologieRegel 64

TextdateiBeispiel 349Regel 348

TextfeldBeispiel 244Verwendung 244

TextfeldliteralHintergrund 241


406

Index

TextstringBeispiel 245Hintergrund 243Verwendung 244

TextsymbolVerwendung 341

TextumgebungHintergrund 344Regel 344

Top-IncludeBeispiel 232globaler Deklarationsteil 128

toter CodeHintergrund 157Komplexität 157Regel 157

TransaktionProgrammausführung 54

TRANSLATEobsolet 366

Transport OrganizerATC 79

Trennung der BelangeBeispiel 30Regel 26

TRYBeispiel 195Hintergrund 190

TYPEHintergrund 237Regel 237

Type-PoolProgrammtyp 54

TYPE-POOLSobsolet 355

TYPESHintergrund 226

TypgruppeBeispiel 229Hintergrund 226Programmtyp 54Regel 55Verwendung 57, 228

TypisierungHintergrund 305Regel 306

U

ÜbersetzbarkeitBeispiel 342, 343, 344Hintergrund 341Regel 341, 343

UI-ServiceTrennung der Belange 31

ungültiger WertBeispiel 252Hintergrund 250

Unicode-ProgrammBeispiel 61Hintergrund 58Verwendung 58, 354

Unicode-PrüfungBeispiel 60Programmattribut 58Regel 58Verwendung 58

UnterklasseHintergrund 170Verwendung 170

UnterprogrammHintergrund 297Regel 298Verwendung 47, 310

UnterstrichBeispiel 84

UnterstrukturBeispiel 234Hintergrund 233Regel 233

USINGHintergrund 299Verwendung 300

V

VALUEDATA 245

VariableHintergrund 230Namensgebung 98Regel 231

VerarbeitungsblockHintergrund 297

VerbuchungsfunktionsbausteinVerwendung 56


407

Index

VererbungABAP Objects 45Hintergrund 170Regel 170Wiederverwendung 170

Verkettungsoperator &&Verwendung 92

vollständige TypisierungBeispiel 308Hintergrund 305

W

WahrheitswertBeispiel 248Hintergrund 247Regel 247

WarnungCode Inspector 75erweiterte Programmprüfung 72Verwendung 198

Web Dynpro ABAPBeispiel 203Hintergrund 201Verwendung 201, 213

WertebereichHintergrund 266

Wertesemantikdynamischer Zugriff 332Verwendung 333

WertübergabeBeispiel 270Hintergrund 302Verwendung 269, 302

WHILEKomplexität 153

WHILE VARYobsolet 362

WITH BYTE-ORDER MARKOPEN DATASET 348

WRITEHintergrund 201

WRITE TOobsolet 367Verwendung 262

Z

ZahlenangabeBeispiel 256, 257Hintergrund 255Regel 256

ZahlenliteralBeispiel 242Hintergrund 241Verwendung 241

ZeichenkettenausdruckSchreibweise 148

Zeichenketten-TemplateVerwendung 262, 341

ZeichenliteralHintergrund 241Übersetzbarkeit 340Verwendung 242, 341

ZeichensatzHintergrund 346Regel 346

ZeigerVerwendung 333

ZeilenbreiteBeispiel 92, 93Hintergrund 91Regel 91Verwendung 92

ZeilenendekommentarHintergrund 118Verwendung 124

ZeilentypHintergrund 282

ZeitfeldHintergrund 251

ZeitstempelVerwendung 252

ZusatzprogrammgruppeHintergrund 309

ZusicherungHintergrund 177

ZuweisungHintergrund 249Konvertierungsregel 253Regel 147Schreibweise 147verlustfrei 254


3 ABAP-spezifische Grundregeln - EDV-BUCHVERSAND

Documents

Transcript of 3 ABAP-spezifische Grundregeln - EDV-BUCHVERSAND