ABAP Delta

ABAP Delta -1-

1. Entwicklungswerkzeuge

1.1 ABAP-Editor

Der neue ABAP-Editor muss zunächst einmal aktiviert werden:

Die Option wird nur angeboten, wenn sowohl das SAP-System wir auch der SAPGui einen
Mindest-Releasestand haben.

Das Layout des neuen Editors unterscheidet sich von der bisherigen Darstellung:

ABAP Delta -2-

Durch Anwahl des Icons im rechten unteren Teil des Editors kann man die Konfiguration
des Editors verändern:

Interessant sind hier insbesondere die Möglichkeiten der Code-Vervollständigung und der
Codevorlagen:

ABAP Delta -3-

Ebenso kann die Formatierung und die Autokorrektur eingestellt werden:

Das Layout für den Ausdruck des Sourcecodes kann beeinflusst werden:

Zusätzliche Funktionen, die nicht im Kontextmenü angeboten werden, können Tastaturcodes

zugewiesen werden:

ABAP Delta -4-

Das folgende Bild zeigt einen Ausschnitt aus dem Kontextmenü des Editors:

Die Editor-Konfiguration wird lokal auf der Workstation im Arbeitsverzeichnis

(Unterverzeichnis „ab4_data“) des SAPGUI‘s gesichert:

ABAP Delta -5-

1.2 Debugger

Neben dem bisherigen Debugger (Classic Debugger), steht ein neuer Debugger zur
Verfügung. Er kann über „Einstellungen“ aktiviert werden:

Der Debugger wird in einem neuen Modus gestartet (wenn noch nicht die Maximalzahl der
Modi erreicht ist).

ABAP Delta -6-

Der aktuelle Inhalt von Variablen kann komfortabel angezeigt werden:

Ebenso kann der Inhalt kompletter Strukturen und interner Tabellen sichtbar gemacht
werden. Die Bearbeitung interner Tabellen ist mit Hilfe der „Tabellen Services“ möglich.

ABAP Delta -7-

Interessant ist die Möglichkeit, während des Debuggings zu beliebigen Source-Code-Zeilen
zu springen (auch Rückwärts). Achten Sie aber darauf, dass bei Rückwärtssprüngen der
aktuelle Inhalt von Variablen nicht verändert wird.

Ebenso kann eine Debug-Session gesichert und wieder geladen werden. Das bedeutet
allerdings nicht, dass man nach dem laden der Session das Debugging fortsetzen kann.
Verschiedene Arten von Breakpoints werden unterstützt:

• Debugger Breakpoint
wirkt nur in der Debugger-Session

• Session Breakpoint
wirkt in allen Modi der gleichen Session

• Externer (User) Breakpoint

wirkt in allen Session des aktuellen Users

ABAP Delta -8-

Der Debugger verfügt über insgesamt vier „Desktops“ zur Anzeige von Informationen. Drei
dieser Desktops sind frei konfigurierbar:

Mit Hilfe des „Diff-Tools“ kann man den Inhalt von 2 Variablen oder von 2 internen Tabellen
miteinander vergleichen:

ABAP Delta -9-

1.3 Checkpoints

Das Konzept der „Checkpoints“ erweitert erheblich die Möglichkeiten der bisher verwendeten
Anweisung „BREAK-POINT“. BREAK-POINT ist gekennzeichnet durch:

• BREAK-POINT hält Verarbeitung an und verzweigt in Debugger

• Anweisung wird unabhängig von User, System etc. durchlaufen

Breakpoints können nun aktiviert oder deaktiviert werden. Dazu muss der Breakpoint einer
sogenannten Checkpoint-Gruppe zugewiesen werden. Checkpointgruppen können mit Hilfe
der Transaktion SAAB oder durch Vorwärtsnavigation aus dem Editor heraus definiert
werden:

Achten Sie unbedingt darauf, dass Checkpoint-Gruppen eigenständige Entwicklungsobjekte

sind mit Transportsystem-Anschluss. Ein Programm ist syntaktisch falsch, wenn die
verwendete Checkpoint-Gruppe nicht existiert.

Mit Hilfe der Transaktion SAAB kann nun konfiguriert werden, ob und für welchen User ein
Breakpoint wirksam sein soll. Wählen Sie dazu im Startbild der Transaktion SAAB zunächst
die Checkpoint-Gruppe, zu der der Breakpoint gehört, und dann die Aktivieren-Funktion
(nicht die Ändern-Funktion).

ABAP Delta - 10 -
Im Folgebild können Sie dann die Benutzer auswählen, für die die Breakpoints wirksam
werden sollen:

Die ASSERT-Anweisung deckt im Prinzip die Möglichkeiten der Anweisung BREAK-POINT

ab, bietet aber zusätzlich die Möglichkeit, bei Bedarf Variablen-Inhalte zu protokollieren:

Achten Sie darauf, dass die ASSERT-Anweisung nur zu einer Reaktion des Systems führt,
wenn die hinter CONDITION angegebene Bedingung nicht (!) wahr ist.

Hinter FIELDS angegebene Variable werden bei aktivierten ASSERT‘s in Protokoll

geschrieben. Die Größe jedes der mit dem Zusatz FIELDS im Protokoll abgespeicherten
Objekte wird durch den Profilparameter „abap/aab_log_field_size_limit“ begrenzt. Der Wert
des Profilparameters gibt die Größe in Bytes an. Der voreingestellte Wert ist 1.024.

Das Systemverhalten für ASSERT wird mit Hilfe der Transaktion SAAB eingestellt:

ABAP Delta - 11 -
Das Protokoll kann in der Transaktion SAAB abgerufen werden:

Hinweis: Bei einer mehrfachen Ausführung des Programms überschreibt im Normalfall das
letzte Protokoll immer das vorangehende Protokoll. Mit Hilfe des Zusatzes SUBKEY können
Sie Schlüssel für die Protokollzeilen bilden.

Der Zusatz SUBKEY wirkt nur, wenn die Anweisung ASSERT Einträge in ein Protokoll
schreibt. Bei der Angabe von SUBKEY wird der Inhalt von sub als Unterschlüssel im
Protokoll abgelegt. Bereits vorhandene Protokolleinträge der gleichen ASSERT-Anweisung
werden nur bei gleichem Inhalt des Unterschlüssels überschrieben. Für sub muss ein
zeichenartiges Datenobjekt angegeben werden, von dem die ersten 200 Zeichen
ausgewertet werden. Ohne die Angabe von SUBKEY ist der Unterschlüssel initial.

Soll an bestimmten Stellen im Progamm bei der Ausführung lediglich ein Protokoll
geschrieben werden, kann die Anweisung LOG-POINT verwendet werden:

Bei aktivierter Checkpoint-Gruppe wird ein Protokolleintrag analog zur Protokollierung bei
ASSERT geschrieben. Eine FIELDS-Angabe wie bei ASSERT ist möglich.

ABAP Delta - 12 -
Im Prinzip deckt zwar die ASSERT-Anweisung die Möglichkeiten von LOG-POINT und
BREAK-POINT ab, das Systemverhalten kann aber mit Hilfe der Transaktion SAAB für diese
Anweisung unabhängig voneinander eingestellt werden.

Im Startbild der Transaktion SAAB besteht die Möglichkeit, eine Übersicht aller aktiven
Elemente von Checkpoint-Gruppen anzuzeigen:

ABAP Delta - 13 -
1.4 Code-Inspector

Der „Code-Inspector“ soll Entwickler und Qualitätsbeauftragen die Analyse vom Programmen
hinsichtlich Performance, Sicherheit, Einhaltung von Namenskonventionen etc. ermöglichen.
Der Aufruf des Code-Inspectors ist aus dem Editor heraus oder mit Hilfe des
Transaktionscodes SCI möglich.

Um eine Inspektion durchführen zu können, muss zunächst festgelegt werden, welche

Prüfkriterien angelegt werden sollen. Diese Prüfkriterien werden zu einer „Prüfvariante“
zusammengefasst. Die Programm, Pakete, …, die geprüft werden sollen, werden mit Hilfe
eine „Objektmenge“ festgelegt. Einer konkreten Inspektion werden dann eine Objektmenge
und eine Prüfvariante zugeordnet:

Alle genannten Grundelemente des Code-Inspector können Benutzerspezifisch oder auch

benutzerübergreifend definiert werden.

ABAP Delta - 14 -
Mit Hilfe der Prüfvariante wird festgelegt, welche Kriterien bei der Prüfung angewendet
werden sollen:

In der Objektmenge legen Sie fest, welche Objekte einer Prüfung unterzogen werden sollen.
Es können z.B. alle Repository-Objekte in einer Inspektion untersucht werden, die einem
Paket zugeordnet sind.

Hinweis: SAP-Original-Objekte sind von einer Inspektion immer ausgenommen!!

ABAP Delta - 15 -
Eine Inspektion wird immer für eine bestimmte Objektmenge und eine gewählte Prüfvariante
durchgeführt:

Achten Sie darauf, dass Inspektionen versioniert werden können. Eine Version eine
Inspektion kann nur ein einziges Mal ausgeführt werden. Der Version ist jeweils das
Inspektionsprotokoll zugeordnet. Vor einer erneuten Inspektion muss also gegebenenfalls
zunächst eine neue Version erzeugt werden.

ABAP Delta - 16 -
Eine besondere Bedeutung kommt der Variante mit dem Namen DEFAULT zu. Die
DEFAULT-Variante wird verwendet, wenn man den Code-Inspector direkt aus dem ABAP-
Editor heraus startet. Die global gültige DEFAULT-Variante kann mit Hilfe eine
benutzerspezifische Variante gleichen Namens übersteuert werden. Die DEFAULT-
Varianten werden mit Hilfe der Transaktion SAAB gepflegt.

ABAP Delta - 17 -
1.5 Single Transaction Analysis

1.5.1 Übersicht

Die Transaktion ST12 wurde entwickelt, um die Verwendung des ABAP-Trace zu fördern, die
ABAP- und Performance-Traces (SQL Enqueue RFC, Transaktion ST05) zu integrieren und
das Tracing und den Analyseprozess schneller und komfortabler zu gestalten. Der ABAP-
Trace mit ST12 ist der zentrale Einstiegspunkt für die Performance-Analyse. Er sollte zum
zielgesteuerten Auffinden von Hotspots, zur Analyse der zeitlichen Verteilung und zur
Optimierung von ABAP/CPU-gebundenen Problemen verwendet werden. SQL-Trace sollte
für DB-gebundene Probleme verwendet werden.

Die Transaktion ST12 ähnelt einer Kombination der Standard ABAP- und SQL-Trace-
Transaktionen SE30 und ST05.

ST12 kombiniert ABAP- und Performance-Traces (SQL) in einer Transaktion, deren

Funktionserweiterungen hauptsächlich im Bereich des ABAP-Trace liegen. ST12 erlaubt, bei
einem gemeinschaftlichen ein-/ausschalten mit dem Performance-Trace, den ABAP-Trace
für einen anderen Benutzer zu aktivieren. Damit kann ein SAP Servicetechniker eine von
einem Nutzer im Unternehmen ausgeführte Dialogtransaktion verfolgen, ohne dafür
Beispieldaten zu benötigen. ABAP- und Performance-Traces können auf einem anderen,
oder sogar auf allen Servern, aktiviert werden, um zum Beispiel eingehende RFCs
abzufangen.

Mit ST12 können Sie werthaltige Trace-Ergebnisse einfach vorhalten, und Sie zum Beispiel
an das SAP-Backoffice weiterleiten. Die Ergebnisse des ABAP-Trace werden vollständig in
der Datenbank erfasst. Für einen Performance-Trace behält die Transaktion ST12 den
Zeitrahmen und den Server, und navigiert mit einem Klick direkt in die ST05 Trace-Anzeige
auf dem richtigen Server. Ausgewählte Ergebnisse des Performance-Trace oder andere
Untersuchungsergebnisse können als Anmerkungstexte in einer Trace-Analyse gespeichert
werden.

ABAP Delta - 18 -
Die ST12 ABAP Trace Summary weist schnell den Beitrag bekannter zeitaufwendiger
Funktionalitäten auf. Sie ist auch in der Lage, den voraussichtlichen Zeitaufwand bestimmter
Programme, insbesondere User-Exits und kundeneigener Codings, zu schätzen.
Mit ST12 können die Programmhierarchien im aggregierten ABAP-Trace 'pro Aufruf'
analysiert werden. Daher ist der nicht-aggregierte ABAP-Trace mit seinen großen Trace-
Dateien nicht mehr erforderlich und wurde in der ST12 weggelassen.

1.5.2 Verfügbarkeit

Die Transaktion ST12 ist ab Basis-Release 4.6B verfügbar (nur in englischer Sprache). Sie
wird über das Add-On ST-A/PI (Application-Servicetools für EarlyWatch/GoingLive, siehe
Hinweis 69455) ausgeliefert. Die ST-A/PI Version muss 01F* oder höher sein.

Die Funktion, den ABAP-Trace für einen anderen Benutzer einzuschalten, benötigt

• im Basis-Release 4.6*: Add-On ST-A/PI >= 01F*, Kernel 4.6D Patch Level >= 1805
• im Basis-Release 6.x: Add-On ST-A/PI >= 01G*, Kernel 640, Patch Level >= 83
• im Basis-Release 7.0 oder höher: Add-On ST-A/PI 01G

1.5.3 ST12 im Vergleich zu SE30 (Delta-Course)

1.5.3.1 Vereinfachungen bei den ABAP-Traceoptionen

Der nicht-aggregierte ABAP-Trace wird nicht in der ST12 angeboten. Ein Grund hierfür liegt
darin, dass er für die meisten Geschäftsvorgänge zu groß wird, ein anderer, dass er
aufgrund der neuen Funktionen zur Hierarchieanalyse in ST12 absolut überflüssig ist.
Die Startoptionen sind sehr viel einfacher als in der SE30. Als voreingestellter Wert dient die
Aggregation 'pro Aufrufposition' und ein Trace-Umfang wie in der DEFAULT-Variante in der
SE30, d.h. Rückverfolgungs-Modularisierungseinheiten und Datenbankoperationen.
Beachten Sie zum Thema Kennzeichen 'mit internen Tabellen' und 'spezifische Einheiten'
das obige Kapitel. Die Beschränkung auf eine Modularisierungseinheit ist möglich. Einige
selten benutzte Optionen sind als Dialogfenster verfügbar.

1.5.3.2 Möglichkeiten, den Trace zu starten

Es werden drei Szenarien angeboten:

• Das 'Benutzerszenario ermöglicht es, den ABAP-Trace für die nächste Aktion unter
einem bestimmten Benutzernamen und einem bestimmten Aufgabentyp (DIA BTC RFC
UPD) auf jedem Applikationsserer oder systemweit zu aktivieren. In geringfügiger
Abweichung zum SQL-Trace verfolgt dieses nicht alles unter dem Benutzernamen, der
Trace wird jedoch für nur einen Benutzerkontext eingeschaltet, der den nächsten Roll-In
durchführt und der den geeigneten Benutzer und Aufgabentyp hat. Der Trace dauert
dann solange an, bis dieser Benutzerkontext/diese Transaktion abgeschlossen ist.

ABAP Delta - 19 -
• Wählen Sie '< Alle Server >' im Serverfeld, um eine solche nächste Aktion systemweit
zu verfolgen. Die Traceanforderung wird daraufhin auf alle Server verteilt. Bei jedem
Refresh prüft ST12, ob auf irgendeinem Server ein Trace angelaufen ist. Ist dies der Fall,
dann wird '< Alle Server >' durch den expliziten Servernamen ersetzt und die
Traceanforderungen auf den anderen Servern bereinigt. Dies ermöglicht beispielsweise,
einen eingehenden RFC oder einen Batch-Job abzufangen, der auf einem beliebigen
Server startet.

Die Voraussetzung für das gesamte 'Benutzer'-Szenario ist ein Kernel-Patch. Beachten
Sie dazu den obigen Absatz 'Verfügbarkeit'.

ABAP Delta - 20 -
• Das Szenario Tasks & HTTP ist ab SAP Basis-Release 6.10 verfügbar. Es erlaubt die
Spezifizierung einer maximalen Anzahl von ABAP-Trace-Aktivierungen = ABAP-Trace-
Dateien, und ist daher gut geeignet, viele eingehende RFCs oder BSPs zu verfolgen, da
hierbei jedes Bildschirmelement einen eigenen Aufruf zum R/3-System durchführt.

• Der 'Workprozess', ebenso wie der 'Parallelmodus' der SE30 werden dazu verwendet,
Teile von Prozessen mit langen Laufzeiten zu verfolgen, insbesondere Batch-Jobs aus
einer Liste ähnlich der Prozessübersicht in der Transaktion SM50.

Im Folgebild ist der Workprozess zu wählen, für den der Trace erfolgen soll.

• Im Szenario 'aktueller Modus' muss die zu analysierende Transaktion aus der ST12
gestartet werden, so dass Beispieldaten wie in der SE30 erforderlich sind.

ABAP Delta - 21 -
1.5.3.3 Trace-Sammlung und Verwaltung von gesicherten Traces

ST12 'holt' den ABAP-Trace aus dem lokalen Dateiensystem und speichert ihn in der
Datenbank als 'Traceanalyse' ab. Damit ist der Trace zentral und dauerhaft verfügbar, was
bei der Weitergabe des Trace auf andere Stufen zur weiteren Analyse von erheblichem
Vorteil ist. Im Szenario 'Benutzer' oder 'Workprozess' wird die asynchrone Trace-Sammlung
durch das Drücken des Knopfes 'Trace beenden & sammeln' ausgelöst. Geeignete
Suchfunktionen sind inbegriffen.

1.5.3.4. Auswertung

Auswerten
ABAP-Trace zeigt aggregierte Trefferliste.

Neue Funktionen im Vergleich zu SE30:

a) Umschalten zwischen Aggregationsstufen

Die Eingangsanzeige zeigt den Trace 'pro Aufrufposition'.

ABAP Delta - 22 -
Mit Hilfe der ersten zwei Knöpfe des Menüs kann man zu anderen Aggregationen
umschalten. Die zweite Stufe lautet 'Voll'.

Die neue Aggregation 'pro Modularisierungseinheit' ist gewissermaßen

eine Mischung aus beiden. Auf einer höheren Stufe zeigt es nur eine Zeile für jede
Modularisierungseinheit. Wenn Sie eine solche Zeile expandieren, werden die Anweisungen
und Aufrufe innerhalb dieser Modularisierungseinheit in der Aggregation 'pro Aufrufposition'
gezeigt. Anweisungen und Aufrufe außerhalb von Modularisierungseinheiten werden
unterhalb der Dummyzeilen '<Programm> [außerhalb v. Mod.einheiten]' gruppiert. Die
Nettozeiten von einfachen Anweisungen werden zu den Nettozeiten der Modu-
larisierungseinheit auf der höheren Stufe hinzuaddiert. Diese Aggregation ist geeignet, um
lokalisierte Probleme in einzelnen Modularisierungseinheiten ausfindig zu machen.

ABAP Delta - 23 -
b) Top-down Aufrufbaum und Buttom-up Aufrufhierarchie

Verwenden Sie die Aggregation 'pro Aufrufposition' zur Analyse von Beziehungen zwischen
Aufrufhierarchien:

-> Die 'Buttom-up Aufrufhierarchie' arbeitet wie eine mehrstufige Verwendungssuche. Die
Hierarchie oberhalb eines Eintrags wird in Form eines Schwimmbahnen-Diagramms
angezeigt. Das leere Karosymbol zeigt, wo ein Aufruf emittiert wird, das ausgefüllte nach
unten/oben weisende Dreieck bezeichnet, wo der Aufruf ankommt. Bei den kleinen Pfeilen
handelt es sich um reine Kosmetik, die die Richtung des Aufrufs anzeigt. Die genaue
Aussage ist: "Aus Modularisierungseinheit leeres Karo> ist ein Aufruf an
Modularisierungseinheit <ausgefülltes nach unten/oben weisendes Dreieck emittiert.".

-> Die 'Top-down time split hierarchy' zeigt die 30 wichtigsten Aufrufe unterhalb eines
Eintrags in einem Schwimmbahnen-Diagramm. Wichtig ist hierbei die aggregierte
Bewegungszeit, die sie vom ursprünglichen Aufruf erhalten haben. Die untergeordneten
Modularisierungseinheiten sind zu eindeutigen Sparten gruppiert. Es wird angezeigt, wie sie
mit dem ursprünglichen Eintrag verbunden sind und an welcher Stelle die Bewegungszeit
aufgesplittet wird (mehrere leere Karos in einer Zeile). Dies ist für die Zeitverteilung und die
Analyse des Zeitverlusts sehr hilfreich.

ABAP Delta - 24 -
-> Setzen Sie für den 'Top-down Aufrufbaum' den Cursor auf den Aufruf einer
Modularisierungseinheit (Perform- oder Call Method/ /Function/Screen) und drücken Sie den
Baumknopf. Die darunter liegende Hierarchie wird nun in einer neuen Spalte angezeigt. Alle
Aufrufe dieser Modularisierungseinheit werden mit '0' bezeichnet, einschließlich derer,
worauf Sie Ihren Cursor setzen. '1' bezeichnet die Anweisungen innerhalb dieser
Modularisierungseinheit, '2' die Anweisungen in den Modularisierungseinheiten eine Stufe
tiefer und dann iterativ down up auf 30 Stufen. Buchstaben werden dazu verwendet,
niedrigere Stufen zu bezeichnen.

In beiden Fällen sind die Trace-Zeilen in der Hierarchie farblich markiert. Der Knopf 'Nur
Aufrufbaum/Aufruf Hierarchiefilter' stellt einen ALV-Listenfilter ein, so dass nur
Traceeingänge in der Hierarchie angezeigt werden. Die Ausschaltknöpfe bewirken, dass die
Hierarchiespalten verschwinden.
Anmerkungen:
Die Hierarchie berücksichtigt nur Aufrufe von Routinen, Methoden, Funktionen und Call-
Screens von PBO PAI-Bausteinen.
Die zweite Einschränkung zeigt, dass unter technischen Gesichtspunkten nur die
Hierarchiebeziehungen eine Stufe nach oben/unten bekannt sind. Ein Beispiel zur
Verdeutlichung: Nehmen wir an, dass ein ABAP-Programm eine Formroutine A1 und A2 hat
und beide eine Routine B mit einem anderen Eingabeparameter aufrufen. Wenn von A1
aufgerufen, ruft B eine Routine C1 auf. Wenn von A2 aufgerufen, ruft B eine Routine C2 auf.
Wenn Sie nun den Cursor auf 'A1 durchführen' setzen, enthält der Top-down Aufrufbaum
nicht nur B und C1 enthalten, sondern auch C2, die von B aufgerufen wurde, aber in
Wirklichkeit nicht, wenn B von A1 aufgerufen wurde. Ähnlich verhält es sich, wenn Sie den
Cursor auf 'C1 durchführen' setzen, d.h. eine Button-up Aufrufhierarchie enthält dann die
Routinen B und A1 ebenso wie A2.
Ebenso kann es passieren, dass obwohl die Routine B von der Routine A1 aufgerufen
wurde, B immer noch höher in der nach Bruttozeiten sortierten Liste erscheint, weil B
ebenfalls von A2 aufgerufen wurde.

ABAP Delta - 25 -
c) letzter Änderer & am

'Einblenden/ausblenden->Letzter Änderer' ruft die Benutzernamen Letzter Änderer' auf und

ändert die Daten aus dem ABAP-Repository. Für einfache Anweisungen zeigt es die
Änderungsinfo des umfassenden Quelltext-Includes. Für Modularisierungseinheiten bezieht
sich die Info auf das Ziel-Include, das die aufgerufene Modularisierungseinheit enthält. Das
macht es einfach, einen beliebigen User-Exit oder eine Kundenmodifikation ausfindig zu
machen.

d) Kurztexte zur Funktionsanalyse

Die Funktion 'Kurztexte einblenden/ausblenden' aus dem Menü ruft Titel von Funktionen,
Methoden, Funktionsgruppen, Reports, Klassen, Dynpros oder Tabellen aus dem ABAP-
Repository auf und zeigt diese an. Zusammen mit den technischen Namen der Routinen,
Funktionen usw. liefern diese die Grundlage für eine funktionale Zeitverteilungsanalyse. Falls
die englischen Titel nicht verfügbar sind, werden diese in Deutsch oder in anderen Sprachen
angezeigt.

ABAP Delta - 26 -
1.5.3.5 'Kontext-Trace' über RFCs und Remote Traceerfassung

Der ABAP-Trace kann via RFC vererbt werden, so dass die Fernaktivitäten ebenso verfolgt
werden. Voraussetzung hierfür ist, dass sowohl das Ursprungs- als auch das Remote-
System ein Basis-Release ab 6.10. haben müssen. Der Parameter rstr/accept_remote_trace
muss im Remote-System auf 'true' gesetzt werden. Ab Basis-Releases 6.10 und 6.20 muss
dieser Parameter in der Profilpflegetransaktion RZ10 geändert und der Applikationsserver
gestartet werden, damit die Änderungen aktiv werden. Ab Basis-Release 6.40 kann er unter
Verwendung der Transaktion RZ11 dynamisch auf 'true' umgeschaltet werden. Beachten
Sie, dass der Parameter nicht dauerhaft auf 'true' gesetzt werden, da dies zu einer nicht
erwünschten Vererbung des Trace führen kann, z.B. durch bestimmte externe Schnittstellen.
Insbesondere sollten Sie die ständige Änderung in der RZ10 auf 'false' zurückändern,
nachdem der Trace abgeschlossen ist.

Starten Sie den Trace aus der ST12 mit dem aktivierten Kennzeichen 'Kontext-Trace'. Wenn
die ursprüngliche Transaktion RFCs durchführt, schreiben diese RFCs eigene ABAP-
Tracedateien in deren Server-Dateiensystem.

Starten Sie nun die Laufzeitanalyse in gewohnter Form.

ABAP Delta - 27 -
Nach Abschluss der Laufzeitmessung rücken Sie zur Sammlung dieser Trace-Dateien
'Externe Traces sammeln' in der ersten Zeile der ST12.

Geben Sie eine RFC-Destination in das Remote-System ein. Geben Sie eine Zeitspanne an
oder löschen Sie die vorgegebene, um alle Dateien zu finden. Drücken Sie anschließend
'Start', um die Suche nach geeigneten Trace-Dateien auf allen Servern des Remote-Systems
zu initiieren.

Wählen Sie die geeignete Datei aus und drücken Sie 'sammeln'. Die Trace-Datei wird
daraufhin ferngeholt und als neue Trace-Analyse gespeichert.

ABAP Delta - 28 -
Sie können nun beide Traces (den auf der lokalen Maschine und den Remote ausgeführten)
auswerten.

ABAP Delta - 29 -
2. Paketkonzept

Das Paketkonzept löst das bisherige Konzept der „Entwicklungsklassen“ ab. Ein Paket
übernimmt die Funktionen einer Entwicklungsklasse wie z.B. die Zuordnung zu einer
Transportschicht, bietet jedoch einige zusätzliche Möglichkeiten:

So können z.B. Pakete auch andere Pakete enthalten und die Sichtbarkeit von Objekten
eines Paketes die Verwendung außerhalb des Paketes festgelegt werden.

Pakete können mit Hilfe der Transaktionen SE80, SE21 und SPACKAGE angelegt werden:

Es werden „Pakettypen“ unterschieden:

„Hauptpakete“ dienen primär als Container für zusammengehörige Entwicklungsobjekte, die

dasselbe Originalsystem, dieselbe Transportschicht und dieselbe Attributierung bezüglich
der Kundenauslieferung haben. Entwicklungsobjekte können jedoch nicht direkt im
Hauptpaket liegen, sondern in den jeweiligen Teilpaketen. Mehrere Hauptpakete können zur
größeren Einheit, einem „Strukturpaket“ zusammengefasst werden.

ABAP Delta - 30 -
Das Konzept der „Paketschnittstellen“ soll helfen, die Verwendung von Objekten eines
Pakets durch Objekte anderer Pakete zu steuern. Im folgenden Bild wird eine Beispiel-
anforderung beschrieben:

Um die Paketprüfung zu ermöglichen, sind einige Einstellungen im System vorzunehmen.

Zum einen muss zunächst die Paketprüfung global in der Tabelle PAKPARAM aktiviert
werden. Zusätzlich muss pro Paket (!) entschieden werden, welcher Prüfung durchgeführt
werden soll:

ABAP Delta - 31 -
Hinweis: Die Optionen für die Paketprüfung werden nur angeboten, wenn die Paketprüfung
generell in der Tabelle PAKPARAM freigeschaltet wurde. Es sind folgende Einstellungen
möglich:

• Kennzeichen für Paketprüfung als Server

Wenn das Kennzeichen für Paketprüfung als Server gesetzt ist, müssen alle (außerhalb
des betroffenen Pakets befindlichen) Verwender nach dem Paketkonzept leben. D.h. die
Verwender-Pakete brauchen Verwendungserklärungen auf die Paketschnittstellen, die
die verwendeten Entwicklungselemente enthalten. Anderenfalls ergeben sich Fehler bei
der Erweiterten Programmprüfung (SLIN) bzw. beim Aktivieren von DDIC-Objekten.

• Kennzeichen für Paketprüfung als Client

Wenn das Kennzeichen für Paketprüfung als Client gesetzt ist, muss innerhalb des
Pakets das Paketkonzept befolgt werden. D.h für das betroffene Paket braucht man
Verwendungserklärungen auf eine Menge von Paketschnittstellen, die die (von den im
betroffenen Paket) verwendeten Entwicklungselemente enthalten. (Eine Ausnahme ergibt
sich nur, wenn bzw. solange ein verwendetes Entwicklungselement in keiner
Paketschnittstelle vorkommt.) Anderenfalls ergeben sich Fehler bei der Erweiterten
Programmprüfung (SLIN) bzw. beim Aktivieren von DDIC-Objekten.

Zu jedem Paket können eine oder mehrere Paketschnittstellen definiert werden. Jeder
Paketschnittstelle wiederum können Objekte zugeordnet werden. Die außerhalb des Paketes
sichtbar sein sollen:

ABAP Delta - 32 -
Sollen Objekte eines Pakets Objekte anderer Pakete verwenden, muss das Paket diejenigen
Paketschnittstellen in der Verwendungserklärung aufführen, die die „fremden“ Objekte
sichtbar machen.

Beachten Sie, dass trotz eingeschalteter Paketprüfungen keine Fehler gemeldet werden,
wenn z.B. ein Programm eines Paketes Funktionsbausteines eines beliebigen anderen
Paketes aufruft. Dies gilt für die normale Syntaxprüfung und erst recht zur Laufzeit.

Eine Paketprüfung wird zunächst einmal nur bei der „Erweiterten Syntaxprüfung“
durchgeführt. Beachten Sie hierbei, dass die Paketprüfung aktiviert sein muss. Ob bei
Prüfungsfehlern Fehlermeldungen, Warnungen oder nur Informationen angezeigt werden,
legen Sie unter „Fehlerschwere“ im Verwendungsnachweis fest. Beachten Sie aber, dass der
Fehlertext unabhängig von der eingestellten Fehlerschwere immer gleichlautend

„Objekt …. Besitzt keine ausreichende Berechtigung zur Verwendung des Objekts …“

lautet.

ABAP Delta - 33 -
Bei Data-Dictionary-Elementen erfolgt die Paketprüfung automatisch bei der Aktivierung:

ABAP Delta - 34 -
3. Enhancements im ABAP-Dictionary

3.1. Zusätzliche Datenbankindizes (Extension-Index)

Wenn für eine von SAP ausgelieferte Tabelle ein zusätzlicher Datenbankindex angelegt
werden soll, ist eine Reparatur (Modifikation) des SAP-Objekts erforderlich, selbst wenn der
zusätzliche Index im Kundennamensraum liegt:

Eine modifikationsfreie Anlage zusätzlicher Indizes ist ab NetWeaver 7.0 mit Hilfe eines
„Extension-Index“ möglich:

Der Name des Index muss natürlich im Kundennamensraum liegen:

ABAP Delta - 35 -
Der Index kann dann in gewohnter Weise definiert werden:

Eine Zuordnung zu einem Paket und einem Transportauftrag ist wie üblich möglich.

Extension-Indizes sind in der Index-Übersicht markiert:

ABAP Delta - 36 -
3.2. Zusätzliche Festwerte für Domänen (Festwert-Append)

Festwerte zu SAP-Domänen können nun modifikationsfrei erweitert werden:

Mit Hilfe der Funktion können die bereits vorhandenen Domänenwerte

eingeblendet werden:

ABAP Delta - 37 -
Es besteht der übliche Anschluss an das Transportsystem. Die neu hinzugefügten Werte
werden automatisch bei der Werthilfe (F4) angezeigt:

Zu einer Domäne können mehrere Festwert-Appends definiert werden:

Beachten Sie die Empfehlungen der SAP-Dokumentation:

ABAP Delta - 38 -
4. Coding-Anpassungen durch das Enhancement-Framework

4.1. Überblick

Die bisher von SAP angebotenen Erweiterungstechniken werden nach wie vor unterstützt,
SAP-seitig aber nicht mehr weiter entwickelt (Ausnahme BAdI). Kennzeichnend war, dass
jweiles eigenstängie Implementierungswerkzeuge genutzt wurden wie z.B. die Transaktionen
SMOD und CMOD für Customer-Exits, die Transaktion FIBF für Business-Transaction-
Events und die Transaktionen SE18 und SE19 für Business-AddIns.

Das Enhancement Framework fügt neue Techniken hinzu:

Enhancement-Point gestatten prinzipiell das modifikationsfreie Einfügen von Source-Code,

Enhancement-Sections das modifikationsfreie Ersetzen von Source-Code. Mit Hilfe von
„Kernel BAdIs“ ist ein performanterer Aufruf von Business-AddIn’s möglich. Enhancement
Spots dienen zur Bündelung logisch zusammengehöriger Point’s, Section’s und Kernel
BAdI’s zu einer Verwaltungseinheit.

ABAP Delta - 39 -
4.2. Enhancement Spots

Enhancement Spots übernehmen in etwa die Funktionalität von Erweiterungen (Transaktion

SMOD) bzw. Erweiterungsprojekten (Transaktion CMOD) oder von „Produkte“ der Business
Transaction Events (Transaktion FIBF).

Enhancement Spots können mit Hilfe der Transaktion SE80 (Erweiterungs-Infosystem)

ermittelt und Implementierungen zu den Spots angelegt werden.

ABAP Delta - 40 -
4.3. Enhancement Points

Mit Hilfe von „Enhancement Points“ soll ein modifikationsfreies Einfügen von Quelltexten,
Variablen und Parameterdeklarationen in SAP-Programmen, SAP-Funktionsbausteinen und
SAP-Methoden ermöglicht werden.

Unterschieden werden:

• Expliziter Enhancement Point

Von SAP vorbereitete Einfügemöglichkeit

• Impliziter Enhancement Point

An bestimmten Stellen standardmäßig, also ohne Vorgabe durch SAP-Entwickler,

vorhandene Erweiterungsmöglichkeit.

4.3.1 Impliziter Enhancement Point

Ein impliziter Enhancement Point ist eine nicht von SAP vorgedachte Erweiterungsstelle, die
aber dennoch nicht frei gewählt werden kann. Zulässige Stellen für implizite „Source-Code-
PlugIns“ können im Editor eingeblendet werden.

ABAP Delta - 41 -
Im folgenden Beispielprogramm soll die Sortierung der internen Tabelle geändert werden. In
einem zweiten Schritt sollen zusätzliche Tabellenfelder ausgegeben werden.

REPORT zenh01.

TYPES :
BEGIN OF ty_spfli,
carrid TYPE spfli-carrid,
connid TYPE spfli-connid,
cityfrom TYPE spfli-cityfrom,
cityto TYPE spfli-cityto,
END OF ty_spfli.

DATA :
gt_spfli TYPE TABLE OF ty_spfli.

PERFORM spfli_lesen.
PERFORM spfli_ausgeben.

*&-----------------------------------------------------------*
*& Form spfli_lesen
*&-----------------------------------------------------------*

FORM spfli_lesen.
SELECT * FROM spfli
INTO CORRESPONDING FIELDS OF TABLE gt_spfli.
ENDFORM. "spfli_lesen

*&-----------------------------------------------------------*
*& Form spfli_ausgeben
*&-----------------------------------------------------------*

FORM spfli_ausgeben.
DATA :
ls_spfli TYPE ty_spfli.

LOOP AT gt_spfli INTO ls_spfli.

WRITE : / ls_spfli-carrid, ls_spfli-connid,
ls_spfli-cityfrom, ls_spfli-cityto.
ENDLOOP.
ENDFORM. "spfli_ausgeben

Das Programm wird zunächst im ABAP-Editor im Anzeigemodus geöffnet und dann der
Erweiterungsmodus aktiviert:

ABAP Delta - 42 -
Anschließend werden die impliziten Erweiterungsstellen eingeblendet.

Hinweis: Bitte die Reihenfolge „Erweiterungsmodus aktivieren“, dann „Erweiterungsstellen

einblenden“ berücksichtigen!

Eine geeignete Erweiterungsstelle für die Umsortierung ist z.B. am Ende der Form-Routine
„spfli_lesen“ zu finden. Um hier eine Erweiterung anzulegen, muss der Cursor auf die
entsprechende Zeile gestellt werden und über das Kontextmenü eine
Erweiterungsimplementierung angelegt werden:

Da wir Coding einfügen möchten, muss im nächsten Bild die entsprechende Option bestätigt
werden. Der Erweiterungsimplementierung ist ein Name im Kundennamensraum zu geben:

Erweiterungsimplementierungen sind an das Transportsystem angeschlossen.

Nun kann das Coding ergänzt werden:

ABAP Delta - 43 -
Die Erweiterung wird automatisch durch die Anweisungsfolge „ENHANCEMENT…
ENDENHANCEMENT“ geklammert und mit einer fortlaufenden Nummer sowie dem Namen
der Erweiterungsimplementierung versehen.

Schließlich muss die Erweiterung aktiviert werden:

Es können bei Bedarf weitere Implementierungen angelegt werden.

Beachten Sie aber, dass Sie nur bedingt (über den Namen der Erweiterungsimplemen-
tierung?) Einfluss auf die Reihenfolge haben, in der die Erweiterungen ausgeführt werden.

Vorhandene Implementierungen können auch geändert, zurückgenommen oder ersetzt

werden.

Bei der Ersetzung einer Implementierung ist nur am angehängten Kommentar erkenntlich,
welche Implementierung gültig ist!

Neben der Ergänzung eines Sourcecodes z.B. am Anfang und am Ende einer Form-Routine
können auch lokal im Programm definierte Strukturen erweitert werden.

ABAP Delta - 44 -
Bemerkenswert ist allerdings die Syntax, mit der die Erweiterung zu erfolgen hat:

Um die Ausgabe der Zusatzfelder zu ermöglichen, wird im vorliegenden Beispiel das Coding
der Form-Routine „spfli_ausgeben“ im Prinzip vollständig ersetzt, weil innerhalb der LOOP-
Schleife keine implizite Erweiterung möglich ist.

Neben der impliziten Erweiterung von Quellcodes (an den ausgewiesenen Stellen!) können
prinzipiell auch für Funktionsbausteine zusätzliche, allerdings nur optionale Parameter
vereinbart werden. Die zusätzliche Definition von EXCEPTIONS ist nicht möglich.

ABAP Delta - 45 -
Es muss wieder eine Erweiterungsimplementierung angelegt werden:

Das erforderliche Zusatzcoding kann durch eine implizite Erweiterung am Anfang oder am
Ende des Bausteins erfolgen (oder aber in aufgerufen Form’s, eingebettenen Include’s, ..).

Beachten Sie aber, dass es wie immer Ausnahmen gibt:

Aber Achtung, es gibt

Ausnahmen !

ABAP Delta - 46 -
Grundsätzlich ist es möglich, auch globale Klassen zu erweitern:

• Zusätzliche optionale Methodenparameter vom Typ „Importing“, „Exporting“ oder

„Changing“, aber keine „Returning“-Parameter oder zusätzliche Exceptions.

• Zusätzliche Attribute oder Methoden (Public, Private oder Protected)

• Pre- und/oder Pos-Methoden zu einer SAP-Methode oder alternativ die Definition einer
Overwrite-Methode.

Beispiel: Postmethode zu „GET_SPFLI_BY_CARRID“ zur Klasse CL_WD_FLIGHT_MODEL.

Mit Hilfe der Postmethode soll die im Returning-Parameter FLIGHTS übergebene interne
Tabelle sortiert werden:

Die Erweiterung beginnt mit der Funktion „Klasse
Erweitern“:

Es muss nun entschieden werden, welche Methodenerweiterung vorzunehmen ist:

ABAP Delta - 47 -
Die Post-Methode kann nun angelegt werden. Es wird automatisch ein Include mit einer
lokalen Klasse angelegt, in deren Namensgebung der gewählte Implementierungsname
einfließt. Das Public-Attribut CORE_OBJECT ist eine Referenz auf die Originalklasse und
stellt damit alle öffentlichen Komponenten der Originalklasse zur Verfügung. Private- oider
Protected-Komponenten sind in den Pre-, Post- oder Overwrite-Methoden nicht sichtbar!

Das gewünschte Coding für die Sortierung kann nun in der lokalen Methode
„IPO_ZIM_CL_WD_FLIGHT_MODEL~GET_SPFLI_BY_CARRID“ erfolgen. Es stehen die
ursprünglichen Importparameter zur Verfügung, alle Export- und Returning-Parameter
werden zu Changing-Parameter.

Die Post-Methode wird nun automatisch jedes Mal nach dem Aufruf der ursprünglichen
Methode GET_SPFLI_BY_CARRID“ durchlaufen.

ABAP Delta - 48 -
4.3.2 Expliziter Enhancement-Point

Bei einem expliziten Enhancement-Point ist im Gegensatz zu den implizit möglichen

Erweiterungen die Sourcecode-Zeile, in der die Erweiterung eingebaut werden kann, bereits
SAP-seitig vordefiniert.

Die expliziten Enhancement-Points sind durch die Anweisung „ENHANCEMENT-POINT“

gekennzeichnet und immer einen Enhancement-Spot zugeordnet.

Beispiel-Coding:

*&-----------------------------------------------------------------*
*& Report ZENH02
*&
*&-----------------------------------------------------------------*

REPORT zenh02.

DATA :
gt_spfli TYPE TABLE OF spfli,
gs_spfli TYPE spfli.

SELECT * FROM spfli INTO TABLE gt_spfli.

ENHANCEMENT-POINT sort SPOTS zenh02_spot.

LOOP AT gt_spfli INTO gs_spfli.

WRITE : / gs_spfli-carrid, gs_spfli-connid,
gs_spfli-cityfrom, gs_spfli-cityto.
ENHANCEMENT-POINT write SPOTS zenh02_spot.
ENDLOOP.

Prinzipiell werden explizite Enhancement-Points genauso implementiert wie implizite, d.h. es

wird eine Erweiterungsimplementierung angelegt und das Coding ergänzt:

Auch Erweiterungsimplementierungen zu expliziten Enhancement-Points können mehrfach

definiert, zurückgenommen, ersetzt oder geändert werden (siehe entsprechende
Ausführungen zu impliziten Enhancement-Points).

ABAP Delta - 49 -
4.3.3 Enhancement-Section

Eine Enhancement-Section ist ein vordefinierter Coding-Abschnitt, der durch ein anderes
Coding modifikationsfrei ersetzt werden kann. Enhancement-Sections sind durch die
Anweisungsfolge „ENHANCEMENT-SECTION….“ / „END-ENHANCEMENT-SECTION“
geklammert und immer einem Enhancement-Spot zugeordnet. Es gibt keine impliziten
Enhancement-Sections!

Beispiel:

Im folgenden Coding-Abschnitt wurde die Ausgabeschleife innerhalb einer Enhancement-

Section eingebettet:

*&-----------------------------------------------------------------*
*& Report ZENH03
*&
*&-----------------------------------------------------------------*

REPORT zenh03.

DATA :
gt_spfli TYPE TABLE OF spfli,
gs_spfli TYPE spfli.

SELECT * FROM spfli INTO TABLE gt_spfli.

ENHANCEMENT-SECTION ausgabe SPOTS zenh03_spot.

LOOP AT gt_spfli INTO gs_spfli.
WRITE : / gs_spfli-carrid, gs_spfli-connid,
gs_spfli-cityfrom, gs_spfli-cityto.
ENDLOOP.
END-ENHANCEMENT-SECTION.

Das gesamte Coding der Section kann mit Hilfe einer Erweiterungsimplementierung ersetzt
werden:

ABAP Delta - 50 -
Achten Sie darauf, dass es keinen Sinn macht, für eine Enhancement-Section mehrere
(aktive) Implementierungen anzulegen. Es werden nicht alle Implementierungen durchlaufen,
sondern nur eine! Welche dies ist, lässt sich nur schwer (über den Namen der
Implementierung?) festlegen.

Noch ein Hinweis:

Explizite Enhancement-Points und Sections, die das Erweitern oder das Ersetzen
ausführbarer Anweisungen erlauben, nennt man auch dynamische Enhancements.

Explizite Enhancement-Points und Sections, die das Erweitern oder das Ersetzen von
Deklarationen erlauben, nennt man auch statistische Enhancements.

4.3.4 Debugging

Werden Source-Codes mit aktiven Enhancements gedebugged, wird zunächst der Original-
Source-Code angezeigt. Erst wenn die „ENHANCEMENT“-Anweisung durchlaufen wird, wird
das aktive Coding angezeigt:

ABAP Delta - 51 -
4.3.5 Enhancements in SAP-Programmen

Betrachtet man ein Standard-SAP-Programm wie RV10A001, so sind dort scheinbar bereits
eine große Anzahl von Implementierungen zu den Enhancement-Points angelegt und auch
aktiviert worden.

Trotzdem werden nicht alle der Implementierungen zur Laufzeit tatsächlich ausgeführt. Die
Ursache liegt darin, dass Entwicklungsobjekte (wie z.B. Erweiterungsimplementierungen,
Enhancement-Spots, …) einem sogenannten „Schalter“ zugeordnet werden können. Erst
wenn dieser Schalter auf „on“ gesetzt wird, wird die Implementierung tatsächlich auch
ausgeführt:

Nähere Erläuterungen siehe Kapitel „Switch-Framework“.

ABAP Delta - 52 -
5. Business AddIns (BAdI’s)

Die BAdI-Technologie ist die derzeitig wichtigste Erweiterungstechnik der SAP. Mit Hilfe von
BAdI’s können nicht nur Erweiterungen an Quelltexten vorgenommen werden, sondern auch
Menü-Ergänzungen und zusätzliche Dynpro-Felder definiert werden. Wichtig ist dabei aber
zu beachten, dass bei der BAdI-Technik alle Erweiterungen bereits von SAP vorgeplant sein
müssen, d.h. zum Beispiel, dass die Stellen im Sourcecode, an denen zusätzliches Coding
eingefügt werden kann, vom SAP-Entwickler festgelegt worden sind.

Sourcecode-Erweiterungen werden nach folgendem Prinzip (bei klassichen BAdI’s)

vorgenommen:

Der SAP-Entwickler definiert zunächst mit Hilfe der Transaktion SE18 eine Erweiterung
(BAdI). Mit Hilfe eines Interfaces wird festgelegt, welche Methoden die Erweiterung anbieten
soll. An den im Sourcecode vorgesehenen Stellen sorgt der Entwickler nun dafür, dass die
vom Kunden-Entwickler vorgenommenen Implementierungen des Interfaces ermittelt und
aufgerufen werden.

„Klassische BAdI’s“ und die neueren „Kernel-BAdI’s“ unterscheiden sich im Wesentlichen

darin, wie zur Laufzeit die von Kunden-Entwickler vorgenommenen Implementierung ermittelt
und aufgerufen werden. Zusätzlich ist zu beachten, dass Kernel-BAdI’s immer einem
Enhancement-Spot zugewiesen sind.

5.1. Klassisches BAdI

An einem einfachen Beispiel soll gezeigt werden, wie ein klassisches Business AddIn vom
SAP-Entwickler definiert und anschließend vom Kunden-Entwickler implementiert wird.

Ausgangspunkt soll das folgende Programm sein:

*&-----------------------------------------------------------*
*& Report ZBADI01
*&
*&-----------------------------------------------------------*

REPORT zbadi01.

DATA :
lt_spfli TYPE TABLE OF spfli,
ls_spfli LIKE LINE OF lt_spfli.

START-OF-SELECTION.
SELECT * FROM spfli INTO TABLE lt_spfli.

* Hier soll sortiert werden können

LOOP AT lt_spfli INTO ls_spfli.

WRITE : / ls_spfli-carrid, ls_spfli-connid,
ls_spfli-cityfrom, ls_spfli-cityto.
* Hier sollen weitere Felder ausgegeben werden können.
ENDLOOP.

ABAP Delta - 53 -
An den mit einem Kommentar versehenen Stellen möchte der SAP-Entwickler dem
Kundenentwickler gestatten, modifikationsfrei die Daten der internen Tabellen lt_spfli zu
sortieren bzw. zusätzliche Felder auszugeben.

Mit Hilfe der Transaktion SE18 wird zunächst ein „klassisches BAdI“ angelegt:

Im Interface werden zwei Methode SORTIEREN und AUSGABE definiert:

ABAP Delta - 54 -
Bei der Definition des BAdI’s wird automatisch eine sogenannte Adapterklasse (generierte
BAdI-Klasse) angelegt.

Diese Klasse liefert eine Implementierung des Interfaces des BAdI’s. Das Implementierungs-
coding wird ebenfalls automatisch erzeugt:

Prinzipiell nutzt der SAP-Entwickler in seinem Programm die Adapterklasse, um an den

betreffenden Stellen die Kunden-Implementierungen des Interfaces zu bestimmen und
aufzurufen.

Nach der Definition des BAdI’s kann der SAP-Entwickler nun die Aufrufe im eigentlichen
Programm einbauen.

ABAP Delta - 55 -
Zunächst muss eine Referenzvariable auf das BAdI-Interface definiert werden. Mit Hilfe des
sogenannten „Exit-Handlers“ wird eine Instanz der Adapterklasse angelegt. Dies kann zur
Laufzeit sehr gut mit dem Debugger überprüft werden:

Schließlich muss an den betreffenden Stellen der Aufruf der Methoden erfolgen. Bedenken
Sie, dass eigentlich der SAP-Entwickler nicht die Implementierungen des Kundenentwicklers
kennt. Stattdessen ruft er stellvertretend die Methoden der Adapterklasse auf, die ihrerseits
die Implementierungen des Kundenentwicklers bestimmen und aufrufen.

Damit ist die Arbeit des SAP-Entwicklers abgeschlossen.

Hinweis:

Bei der Definition eines BAdI’s kann der SAP-Entwickler entscheiden, ob gleichzeitig
mehrere aktive (also aufrufbare) Implementierungen möglich sein sollen. Zu beachten ist
allerdings, dass man in diesem Fall keinen Einfluss darauf hat, in welcher Reihenfolge die
Implementierungen ausgeführt werden.

ABAP Delta - 56 -
BAdI’s können auch „filterabhängig“ definiert werden. Dies bedeutet, man hätte in unserem
Beispiel etwa die Möglichkeit, die Fluggesellschaft (CARRID) als Filterwert zu vereinbaren
und könnte dann pro Fluggesellschaft eine eigenständige Implementierung vereinbaren. Man
hat dadurch den Vorteil, dass man nicht in einer einzigen Implementierung durch komplexe
Fallunterscheidungen das Coding für die verschiedenen Werte von CARRID unterscheiden
zu müssen. Beispiel:

Jeder Interface-Methode wird automatisch der Parameter FLT_VAL übergeben, der beim
Aufruf der gewünschte Filterwert übergeben werden kann.

Der Aufruf mit Übergabe eines Filterwerts kann dann so aussehen:

Die entsprechende Methode der Adapterklasse sucht dann genau die Implementierung des
Kundenentwicklers, die für den aktuell übergebenen Filterwert zugeordnet wurde heraus und
ruft diese auf.

Mit Hilfe einer „Default-Implementierung“ kann der SAP-Entwickler Coding vorgeben für die
Filterwerte, für die keine explizite Implementierung vorgesehen ist.

ABAP Delta - 57 -
Nun zu den Arbeiten auf Seiten des Kunden-Entwicklers. Er kann mit Hilfe der Transaktion
SE19 zu einem BAdI die Implementierungen anlegen:

ABAP Delta - 58 -
Die Implementierung muss nun noch aktiviert werden:

Beachten Sie, dass nur bei „mehrfach nutzbaren“ BAdI’s mehr als eine Implementierung zur
gleichen Zeit aktiv sein darf.

Bei filterabhängigen BAdI’s ist bei der Implementierung jeweils anzugeben, für welche
Filterwerte die Implementierung gelten soll:

Es ist möglich, die gleiche Implementierung für mehrere Filterwerte zu nutzen. Den Methode
wird jeweils im Parameter FLT_VAL der aktuelle Filterwert übergeben und kann
gegebenenfalls in der Implementierung ausgewertet werden.

Die notwendigen Schritte auf Seiten des SAP-Entwicklers und des Kunden-Entwicklers
werden an dem schon bekannten Beispiel demonstriert.

ABAP Delta - 59 -
5.2 Kernel BAdI

Ziel bei der Entwicklung der „neuen BAdI’s“, der sogenannten Kernel-BAdI’s war in erster
Linie, den Aufruf der BAdI-Implementierungen zu beschleunigen. Bei den Kernel-BAdI’s
erfolgt der Methodenaufruf nicht mehr mit Hilfe einer Adapterklasse, sondern durch ein im
SAP-Kernel verankertes BAdI-Handle. Der Aufruf ist um den Faktor 40 – 600 schneller!

*&-----------------------------------------------------------*
*& Report ZBADI02
*&
*&-----------------------------------------------------------*

REPORT zbadi02.

DATA :
lt_spfli TYPE TABLE OF spfli,
ls_spfli LIKE LINE OF lt_spfli.

START-OF-SELECTION.
SELECT * FROM spfli INTO TABLE lt_spfli.

* Hier soll sortiert werden können

LOOP AT lt_spfli INTO ls_spfli.

WRITE : / ls_spfli-carrid, ls_spfli-connid,
ls_spfli-cityfrom, ls_spfli-cityto.
* Hier sollen weitere Felder ausgegeben werden können.
ENDLOOP.

Kernel-BAdI’s sind grundsätzlich immer einem Erweiterungs-Spot zugeordnet. Der SAP-

Entwickler muss diesen Spot zunächst mit Hilfe der Transaktion SE18 anlegen:

Unter Technologie steht derzeitig ausschließlich „BAdI-Definition“ zur Verfügung.

ABAP Delta - 60 -
Für den Erweiterungsspot können nun eine oder mehrere BAdI-Definitionen angelegt
werden:

Der Name des BAdI-Interface ist im Gegensatz zu klassischen BAdI’s nicht fest vorgegeben,
sondern wird vom Entwickler festgelegt:

Das Interface wird nun exakt genau so definiert wie bei klassischen BAdI’s:

ABAP Delta - 61 -
Im Coding des zu erweiternden Programms ist nun eine Referenz-Variable auf das Kernel-
BAdI (nicht auf das Interface!) zu definieren. Das BAdI-Handle (Ersatz für die
Adapterklasse) wird mit Hilfe der Anweisung GET BADI erzeugt.

Achten Sie auf die Fehlerbehandlung für den „GET BADI“ - Aufruf. GET BADI erzeugt einen
Laufzeitfehler, wenn es keine aktive Implementierung zum BAdI gibt.

Der Aufruf der Implementierungen zu den Interface-Methoden erfolgt durch „CALL BADI“.
Beachten Sie auch hier die Fehlerbehandlung.

Hinweis:

Man kann einem Kernel-BAdI eine Klasse (Fallback-Klasse) mit einer Default-
Implementierung zuordnen. Diese Default-Implementierung wird verwendet, wenn es keine
sonstige aktive Implementierung gibt.

ABAP Delta - 62 -
Nun zur Arbeit auf Kundenseite. Der Entwickler kann mit Hilfe der Transaktion SE19 eine
Implementierung zum Kernel-BAdI anlegen. Anzugeben ist allerdings zunächst der
Erweiterungsspot, dem das BAdI zugeordnet wurde:

Der Erweiterungsimplementierung muss ein Name zugeordnet werden.

Auch die Implementierung zum BAdI benötigt einen Namen:

Der Name der implementierenden Klasse ist anzugeben. Sie wird, falls sie nicht schon
existiert, automatisch angelegt:

ABAP Delta - 63 -
Nach Doppelklick auf den Methodennamen kann das Coding eingegeben werden:

Die BAdI-Implementierung muss nun noch auf „aktiv“ gesetzt werden:

Achten Sie darauf, dass bei BAdI-Implementierung auch der Aktivierungszustand

transportiert wird. Es ist nicht vorgesehen, erst im Zielsystem zu entscheiden, ob ein BAdI-
Implementierung aktiv ist oder nicht.

ABAP Delta - 64 -
6. Switch-Framework

Die Idee des Switch-Frameworks besteht darin, in einem SAP-System alle eventuell
notwendigen (branchenspezifischen) Erweiterungen bereits fertig codiert auszuliefern, diese
jedoch erst bei Bedarf zu aktivieren.

Zunächst werden Schalter definiert. Diesen können dann Repository-Objekte wie Pakete,
Menü-Einträge, Dynpro-Felder, Append-Strukturen etc. zugeordnet werden. Schalter
wiederum werden zu „Business Functions“ zusammengefasst, „Business Functions“ zu
„Business Function Sets“. Wird ein „Business Function Set“ aktiviert, werden automatisch
alle Erweiterungen wirksam, die Schalter des „Business Function Sets“ zugeordnet sind.

Die Zuordnung von Repository-Objekten zu Schaltern erfolgt zum Teil direkt aus dem
betreffenden Entwicklungswerkzeug (Screen-Painter, Menü-Painter) heraus. Ist für ein
Entwicklungsobjekt eine direkte Schalterzuordnung nicht möglich, erfolgt die Zuordnung über
den Umweg „Paket“. Das betreffende Paket muss dann einem Schalter zugeordnet sein.

ABAP Delta - 65 -
6.1 Schalter definieren

Schalter werden mit Hilfe der Transaktion SFW1 definiert. Beim Start der Transaktion
erhalten Sie allerdings den Hinweis, dass die Transaktion nur für den SAP-internen
Gebrauch freigegeben ist.

Über die Anlegen-Funktion kann ein neuer Schalter hinzugefügt werden:

Anschließend muss der Schalter aktiviert werden (das bedeutet noch nicht, dass sich jetzt
schon Auswirkungen ergeben).

Über die Detail-Pflege können nun dem Schalter z.B. Pakete zugeordnet werden:

ABAP Delta - 66 -
Nach der Aktivierung des Schalters ist die Schalterzuordnung in der Paketdefinition sichtbar
(etwas Geduld bitte, die Aktivierung läuft im Hintergrund):

6.2 Zuordnung von Repository-Objekten

Dem Paket können nun beliebige Repository-Objekte zugewiesen werden. Im Beispiel soll
zunächst zur Tabelle SFLIGHT eine Append-Struktur definiert werden.

Die Append-Struktur wird dem Paket ZSFWDEMOPAKET zugeordnet. Nach der Aktivierung
der Append-Struktur bleibt der Status der Struktur bei „neu“, der über das Paket zugeordnete
Schalter wird angezeigt:

ABAP Delta - 67 -
Im Demo-Programm ZSFW_DEMO ist ein expliziter Enhancement-Point definiert.

*&-----------------------------------------------------------*
*& Report ZSFW_DEMO
*&
*&-----------------------------------------------------------*

REPORT zsfw_demo.

DATA :
ls_sflight TYPE sflight.

START-OF-SELECTION.
SELECT * FROM sflight INTO ls_sflight.
WRITE : / ls_sflight-carrid, ls_sflight-connid,
ls_sflight-fldate.
ENHANCEMENT-POINT zusatzfelder SPOTS zsfw_sflight.
ENDSELECT.

Für diesen Enhancement-Point wird eine Implementierung angelegt, die ebenfalls dem Paket
ZSFWDEMOPAKET zugeordnet wird.

Bemerkenswert ist, dass im Coding bereits die Komponenten der noch nicht aktiven Append-
Struktur ansprechbar sind (Kein Wunder, es wird keine Syntaxprüfung durchgeführt!). Die
Implementierung des Enhancement-Point wird als „active“ gekennzeichnet, obwohl sie noch
nicht ausgeführt wird.

ABAP Delta - 68 -
Führt man einen Doppelklick auf den Namen der Erweiterungsimplementierung aus, erkennt
man unter den „Eigenschaften“, dass die Implementierung dem Schalter ZSFWDEMO
zugeordnet ist und der Schalter noch auf „off“ steht.

6.3 Definition von Business Functions

Mit Hilfe der Transaktion SFW2 können sogenannte „Business Functions“ definiert werden.

Diesen Business Functions können nun Schalter zugeordnet werden:

ABAP Delta - 69 -
6.4 Definition Business Function Set

Mit Hilfe eines „Business Function Sets“ können „Business Functions“ gruppiert werden. Sie
werden mit Hilfe der Transaktion SFW3 gepflegt.

Beachten Sie, dass die Aktivierung eines Business Function Sets mit Hilfe der Transaktion
SFW3 noch nicht bedeutet, dass sich Auswirkungen auf die Laufzeitumgebung zeigen.

6.5. Aktivierung von Business Function Sets

Ein Business Function Set kann mit Hilfe der Transaktion SFW5 aktiviert werden.

Die Aktivierung des Add-Ons wird im Hintergrund ausgeführt. Es werden dabei automatisch
alle den abhängigen Schaltern zugeordneten Repository-Objekte aktiviert. Im aktuellen Fall
bedeutet dies, dass jetzt die Append-Struktur zur Tabelle SFLIGHT sichtbar ist und auch die
Erweiterungsimplementierung ausgeführt wird.

ABAP Delta - 70 -
Anzeige des Programm ZSFW_DEMO:

Hinweis:

Beachten Sie unbedingt, dass die Aktivierung von Business Function Sets nicht
immer rückgängig gemacht werden kann, z.B. dann nicht, wenn Dictionary-Objekte
aktiviert wurden.

ABAP Delta - 71 -