BC430 ABAP Dictionary

BC430
ABAP Dictionary
mySAP Technology
Stand
Schulungszentrum
Referenten
Schulungs-
Homepage
Teilnehmerhandbuch
Version der Schulung: 2006/Q2
Dauer der Schulung: 3 Tag(e)
Materialnummer: 50084449
An SAP course - use it to learn, reference it for work

Copyright
Copyright © 2007 SAP AG. Alle Rechte vorbehalten.
Weitergabe und Vervielfältigung dieser Publikation oder von Teilen daraus sind, zu welchem Zweck
und in welcher Form auch immer, ohne die ausdrückliche schriftliche Genehmigung durch SAP AG
nicht gestattet. In dieser Publikation enthaltene Informationen können ohne vorherige Ankündigung
geändert werden.
Die von SAP AG oder deren Vertriebsfirmen angebotenen Software-Produkte können

Software-Komponenten auch anderer Software-Häuser enthalten.
Markenzeichen
• Microsoft®, WINDOWS®, NT®, EXCEL®, Word®, PowerPoint® und SQL Server® sind
eingetragene Marken der Microsoft Corporation.
• IBM®, DB2®, OS/2®, DB2/6000®, Parallel Sysplex®, MVS/ESA®, RS/6000®, AIX®,
S/390®, AS/400®, OS/390® und OS/400® sind eingetragene Marken der IBM Corporation.
• ORACLE® ist eine eingetragene Marke der ORACLE Corporation.
• INFORMIX®-OnLine for SAP und Informix® Dynamic ServerTM sind eingetragene Marken
der Informix Software Incorporated.
• UNIX®, X/Open®, OSF/1® und Motif® sind eingetragene Marken der Open Group.
• Citrix®, das Citrix-Logo, ICA®, Program Neighborhood®, MetaFrame®, WinFrame®,
VideoFrame®, MultiWin® und andere hier erwähnte Namen von Citrix-Produkten sind
Marken von Citrix Systems, Inc.
• HTML, DHTML, XML, XHTML sind Marken oder eingetragene Marken des W3C®, World
Wide Web Consortium, Massachusetts Institute of Technology.
• JAVA® ist eine eingetragene Marke der Sun Microsystems, Inc.
• JAVASCRIPT® ist eine eingetragene Marke der Sun Microsystems, Inc., verwendet unter der
Lizenz der von Netscape entwickelten und implementierten Technologie.
• SAP, SAP Logo, R/2, RIVA, R/3, ABAP, SAP ArchiveLink, SAP Business Workflow,
WebFlow, SAP EarlyWatch, BAPI, SAPPHIRE, Management Cockpit, mySAP.com Logo
und mySAP.com sind Marken oder eingetragene Marken der SAP AG in Deutschland und
vielen anderen Ländern weltweit. Alle anderen Produkte sind Marken oder eingetragene
Marken der jeweiligen Firmen.
Verzichtserklärung
Bei der Zusammenstellung der Texte, Verweise und Abbildungen wurde mit größter Sorgfalt
vorgegangen; trotzdem ist ein vollständiger Fehlerausschluss nicht möglich. Die nachfolgende
Dokumentation erfolgt daher ohne Gewähr für Richtigkeit und Vollständigkeit der gemachten
Angaben, für deren Verifizierung allein der Anwender die Verantwortung trägt.
SAP übernimmt für aus der Verwendung dieser Dokumentation entstehende Schäden, gleich aus
welchem Rechtsgrund, eine Haftung nur im Falle vorsätzlichen oder grob fahrlässigen Handelns;
im übrigen ist die Haftung von SAP ausgeschlossen. SAP übernimmt keine Verantwortung für die
Inhalte von Seiten Dritter, auf welche wir durch Links verweisen.
g2007411102223
Über dieses Handbuch
Dieses Handbuch ergänzt die Präsentation des Schulungsreferenten und dient als
Nachschlagewerk. Es ist nicht zum Selbststudium geeignet.
Typografische Konventionen
Die folgenden typografischen Konventionen werden in diesem Handbuch
verwendet:
Format Beschreibung
Beispieltext Wörter oder Zeichen, die vom Bildschirmbild zitiert

werden. Dazu gehören Feldbezeichner, Bildtitel,
Drucktastenbezeichner sowie Menünamen, Menüpfade
und Menüeinträge. Querverweise auf andere
Dokumentationen
Beispieltext Hervorgehobene Wörter oder Ausdrücke im Fließtext,

Titel von Grafiken und Tabellen
BEISPIELTEXT Namen von Systemobjekten. Dazu gehören

Reportnamen, Programmnamen, Transaktionscodes,
Tabellennamen und einzelne Schlüsselbegriffe einer
Programmiersprache, die von Fließtext umrahmt sind,
z.B. SELECT und INCLUDE.
Beispieltext Ausgabe auf dem Bildschirmbild. Dazu gehören

Datei- und Verzeichnisnamen und ihre Pfade,
Meldungen, Namen von Variablen und Parametern,
Quelltext und Namen von Installations-, Upgrade- und
Nicht-SAP-Software.
Beispieltext Exakte Benutzereingabe. Dazu gehören Wörter oder

Zeichen, die Sie genau so in das System eingeben, wie es
in der Dokumentation angegeben ist.
<Beispiel- Variable Benutzereingabe. Die Wörter und Zeichen in

text> spitzen Klammern müssen Sie durch entsprechende
Eingaben ersetzen, bevor Sie sie in das System eingeben.
2006/Q2 © 2007 SAP AG. Alle Rechte vorbehalten. iii

Über dieses Handbuch BC430
Symbole im Text
Die folgenden Ikonen werden in diesem Handbuch verwendet:
Symbol Bedeutung
Für mehr Information, Hinweise oder Hintergründe
Bemerkung oder weitere Erklärung zum

vorangegangenen Punkt
Ausnahme oder Gefahr
Vorgehensweise
Gibt an, dass der Abschnitt in der Präsentation des

Referenten angezeigt wird.
iv © 2007 SAP AG. Alle Rechte vorbehalten. 2006/Q2

Inhaltsverzeichnis
Überblick über die Schulung .......................................... vii
Ziele der Schulung .....................................................vii
Lernziele der Schulung ................................................vii
Kapitel 1: Einführung ins Dictionary .................................. 1

Überblick der Funktionen des ABAP Dicitonary ....................2
Kapitel 2: Datenobjekte im ABAP Dictionary........................ 9

Grundlegende Datentypen........................................... 11
Tabellen im ABAP Dictionary ........................................ 46
Besondere SAP-Tabellen ............................................ 70
Kapitel 3: Performance beim Tabellenzugriff...................... 77

Performance beim Tabellenzugriff ................................. 78
Kapitel 4: Eingabeprüfungen......................................... 103

Konsistenz durch Eingabeprüfungen..............................104
Kapitel 5: Abhängigkeiten bei Objekten ........................... 133

Abhängigkeiten bei Objekten.......................................134
Kapitel 6: Änderungen an Tabellen ................................. 147

Änderungen an Tabellen ............................................148
Kapitel 7: Views und Pflegedialoge................................. 175

Views ..................................................................176
Pflegedialoge .........................................................192
Kapitel 8: Suchhilfen ................................................... 211

Suchhilfen.............................................................212
2006/Q2 © 2007 SAP AG. Alle Rechte vorbehalten. v

Inhaltsverzeichnis BC430
vi © 2007 SAP AG. Alle Rechte vorbehalten. 2006/Q2

Überblick über die
Schulung
Die Schulung vermittelt Ihnen die Rolle des ABAP Dictionarys im SAP-System
sowie dessen Funktionsumfang
Zielgruppe
Diese Schulung richtet sich an die folgenden Zielgruppen:
• ABAP-Entwickler und Administratoren, die globale Datenobjekte,

Datenbanktabellen, Views usw. im Dictionary anlegen.
• Datenbankdesigner, die ein Datenmodell entwerfen und in die Datenbank
übertragen wollen.
Voraussetzungen für die Teilnahme

Erforderliche Vorkenntnisse
• BC400 oder entsprechende Grundkenntnisse im Programmieren mit ABAP
• SAPTEC oder entsprechende Kenntnisse im Umgang mit der SAPGUI
Empfohlene Vorkenntnisse
• Prinzipielles Verständnis über den Aufbau einer Relationalen Datenbank
Ziele der Schulung

Diese Schulung ermöglicht es Ihnen,
• die Funktion des ABAP Dictionary im R/3 System zu beschreiben

• die Definition von Datenbankobjekten vorzunehmen zu beschreiben und zu
nutzen
• benutzerdefinierte Datentypen anzulegen und zu verwalten
• die Services im ABAP Dictionary zu verwenden
• die Einbindung des Dictionary in die Entwicklungsumgebung und die
Laufzeitumgebung
• die Modelierungssprache UML zur Datenmodellierung zu verwenden.
Lernziele der Schulung

Am Ende dieser Schulung können Sie
2006/Q2 © 2007 SAP AG. Alle Rechte vorbehalten. vii

Überblick über die Schulung BC430
• Das ABAP Dictionary mit seinen Services verwenden und beschreiben
Informationen über die SAP-Softwarekomponenten

Die Informationen in dieser Schulung beziehen sich auf folgende SAP
Softwarekomponenten und Releasestände:
viii © 2007 SAP AG. Alle Rechte vorbehalten. 2006/Q2

Kapitel 1
Einführung ins Dictionary
Überblick über das Kapitel

Den Kapitelüberblick entnehmen Sie bitte dem Überblick der einzelnen Lektionen
zu diesem Kapitel.
Lernziele des Kapitels

Am Ende dieses Kapitels können Sie
• die Funktion des ABAP Dictionary im R/3-System nennen

• die Möglichkeiten zur Definition von Datenobjekten und Datentypen
beschreiben
• die vom ABAP Dictionary angebotenen Services beschreiben
• Die Einbindung des ABAP Dictionary in die Entwicklungsumgebung und
die Laufzeitumgebung erläutern
Inhalt des Kapitels

Lektion: Überblick der Funktionen des ABAP Dicitonary .....................2
2006/Q2 © 2007 SAP AG. Alle Rechte vorbehalten. 1

Kapitel 1: Einführung ins Dictionary BC430
Lektion: Überblick der Funktionen des ABAP Dicitonary
Überblick über die Lektion

In dieser Lektion erhalten Sie einen Überblick über den Funktionsumfang des
ABAP Dictionarys
Lernziele der Lektion

Am Ende dieser Lektion können Sie
beschreiben
Unternehmensszenario
Sie sollen einem Kollegen die wesentlichen Möglichkeiten des ABAP-Dictionary
erläutern
Überblick der Funktionen
Abbildung 1: Funktion des ABAP Dictionary
2 © 2007 SAP AG. Alle Rechte vorbehalten. 2006/Q2

BC430 Lektion: Überblick der Funktionen des ABAP Dicitonary
Das ABAP Dictionary ermöglicht die zentrale Verwaltung aller im R/3 System
verwendeten Typdefinitionen.
Im ABAP Dictionary können benutzerdefinierte Typen (Datenelemente,
Strukturen und Tabellentypen) zur Verwendung in ABAP Programmen oder in
Schnittstellen von Funktionsbausteinen, Objektmethoden usw. angelegt werden.
Auch Datenbankobjekte wie Tabellen, Indizes und Views können im ABAP
Dictionary definiert und mit dieser Definition auf der Datenbank angelegt werden.
Weiterhin stellt das ABAP Dictionary eine Reihe von Services zur Verfügung, die
die Programmentwicklung unterstützen. Hier werden beispielsweise das Setzen
und Freigeben von Sperren, die Definition einer Eingabehilfe (F4-Hilfe) und das
Anbinden einer Feldhilfe (F1-Hilfe) an ein Dynprofeld unterstützt.
Abbildung 2: Datenbankobjekte im ABAP Dictionary
Im ABAP Dictionary können Tabellen und Datenbank-Views definiert werden.

Diese Objekte werden dann mit dieser Definition auf der unterliegenden
Datenbank angelegt. Änderungen an der Definition einer Tabelle oder eines
Datenbank-Views werden automatisch auf der Datenbank nachgezogen.
Um die Zugriffe auf Daten in einer Tabelle zu beschleunigen, können Indizes im
ABAP Dictionary definiert werden. Diese Indizes werden dann ebenfalls auf
der Datenbank angelegt.

Abbildung 3: Typdefinitionen im ABAP Dictionary
Es gibt drei unterschiedliche Kategorien im ABAP Dictionary:

• Datenelemente:Beschreiben durch Angabe von Datentyp, Länge und
gegebenenfalls Dezimalstellen einen elementaren Typ.
• Strukturen: Bestehen aus Komponenten, die einen beliebigen Typ haben
können.
• Tabellentypen: Beschreiben den Aufbau einer internen Tabelle.
Aus diesen Grundtypen können beliebig komplexe benutzerdefinierte Typen
aufgebaut werden.
Beispiel: Die Daten eines Mitarbeiters sind in einer Struktur MITARBEITER mit
den Komponenten NAME, ADRESSE und TELEFON zusammengefaßt. Die
Komponente NAME ist wieder eine Struktur mit den Komponenten VORNAME
und NACHNAME. Diese beiden Komponenten sind elementar, d.h. durch ein
Datenelement typisiert. Ebenso ist die Komponente ADRESSE durch ein Struktur
typisiert, deren Komponenten wiederum Strukturen sind. Die Komponente
TELEFON wird über einen Tabellentyp definiert (da ein Mitarbeiter mehr als eine
Telefonnummer haben kann).
Typen werden beispielsweise in ABAP Programmen oder zur Typisierung der
Schnittstellenparameter von Funktionsbausteinen verwendet.

Abbildung 4: Services des ABAP Dictionary
Das ABAP Dictionary unterstützt die Programmentwicklung durch eine Reihe

von Services:
• Über Suchhilfen können Eingabehilfen (F4-Hilfen) für Dynprofelder
definiert werden.
• Dynprofeldern kann durch Erfassen einer Dokumentation zum Datenelement
auf einfache Weise eine Feldhilfe (F1-Hilfe) zugeordnet werden.
• Über Fremdschlüssel kann für Dynprofelder auf einfache Art eine
Eingabeprüfung definiert werden, die die Konsistenz eingegebener Werte
sicherstellt.
• Das ABAP Dictionary liefert eine Unterstützung für das Setzen und
Freigeben von Sperren. Hierzu müssen Sperrobjekte im ABAP Dictionary
angelegt werden. Aus diesen werden automatisch Funktionsbausteine
zum Setzen und Freigeben von Sperren generiert, die dann in die
Anwendungsprogramme eingebunden werden können.
• Für Datenbankobjekte (Tabellen, Views) kann über Einstellungen zur
Pufferung die Performance beim Zugriff auf deren Daten erhöht werden.
• Über die Protokollierung kann eine automatische Aufzeichnung von
Änderungen an Tabelleneinträgen eingeschaltet werden.

Abbildung 5: Einbindung in Entwicklungs- und Laufzeitumgebung
Das ABAP Dictionary ist aktiv in die Entwicklungsumgebung und die

Laufzeitumgebung integriert. Jede Änderung wirkt sich sofort auf die betroffenen
ABAP Programme und Dynpros aus.
Beispiele:
• ABAP Interpreter und Dynpro-Interpreter greifen beim Generieren eines
Programms oder Dynpros auf die im ABAP Dictionary abgelegten
Definitionen der Typen zu, die in diesem Programm bzw. Dynpro verwendet
werden.
• Die ABAP Werkzeuge bzw. der Screen Painter nutzen die im ABAP
Dictionary abgelegten Informationen, um eine Unterstützung bei der
Programmentwicklung zu geben. Ein Beispiel hierfür ist die Funktion Holen
aus Dictionary im Screenpainter, mit der Felder einer im ABAP Dictionary
definierten Tabelle oder Struktur auf einem Dynpro platziert werden können.
• Die Datenbank-Schnittstelle nutzt die im ABAP Dictionary abgelegten
Informationen zu Tabellen bzw. Datenbank-Views für den Zugriff auf die
Daten dieser Objekte.

Zusammenfassung der Lektion

Nun können Sie
beschreiben

Zusammenfassung des Kapitels BC430
Zusammenfassung des Kapitels

Nun können Sie
beschreiben

Kapitel 2
Datenobjekte im ABAP Dictionary

In diesem Kapitel werden Sie verschiedene Möglichkeiten kennen lernen,
Datenobjekte im Dictionary abzubilden

• Domänen anlegen und in Datenelementen verwenden

• Datenelemente definieren und als Definitionsgrundlage für Datenobjekte
in ABAP-Programmen verwenden
• Strukturen definieren und als Definitionsgrundlage für Datenobjekte in
ABAP-Programmen verwenden
• Interne Tabellen definieren und als Definitionsgrundlage für Datenobjekte
• Komplexe (geschachtelte / tiefe) Strukturen definieren und als
Definitionsgrundlage für Datenobjekte in ABAP-Programmen verwenden
• Globale Konstanten mit Hilfe eines Typpools definieren und in
• Tabellen anlegen
• Das zweistufige Domänenkonzept verwenden
• Die technischen Einstellungen einer Tabelle definieren
• Include-Strukturen anlegen und verwenden
• Tabellentypen beschreiben, die es außer den Transparenten Tabellen im
SAP-System noch gibt
• Pool- und Clustertabellen voneinander unterscheiden
• Vor- und Nachteile von Pool- und Clustertabellen beschreiben.
Inhalt des Kapitels

Lektion: Grundlegende Datentypen ........................................... 11
Übung 1: Grundlegende Datentypen ..................................... 25
Übung 2: Einfache und geschachtelte Strukturen....................... 31

Kapitel 2: Datenobjekte im ABAP Dictionary BC430
Übung 3: Tabellentypen (interne Tabellen / ITAB's)..................... 37

Übung 4: Tiefe Strukturen .................................................. 41
Lektion: Tabellen im ABAP Dictionary......................................... 46
Übung 5: Tabellen im ABAP Dictionary................................... 57
Lektion: Besondere SAP-Tabellen............................................. 70

BC430 Lektion: Grundlegende Datentypen
Lektion: Grundlegende Datentypen

In dieser Lektion lernen Sie die grundlegenden Datentypen und deren gegenseitige
Verwendung kennen.

Sie sollten einfache und komplexe Datentypen im Dictionary definieren und in
einem ABAP-Programm verwenden können.

Datentypen
Abbildung 6: Einstiegsbild des Data Dictionary(SE11)
Im ABAP Dictionary können programmübergreifende (global bekannte)

Datentypen definiert werden. Auf diese Datentypen kann in jedem
ABAP-Programm des SAP-Systems mit dem TYPE-Zusatz entsprechender
ABAP-Anweisungen Bezug genommen werden.
Auf dem Einstiegsbild werden die entsprechenden Definitionen über das Feld
Datentyp definiert. Unter Datentyp sind die drei Grundtypen Datenelement,
Struktur und Tabellentyp ( interne Tabellen – ITAB ) zu finden.
Die Typgruppe stellt an sich ein Relikt aus älterer Zeit (vor Release 4.5a ) dar, als
es noch nicht nicht möglich war eigene globale, komplexe Datentypen für die
Deklaration von Datenobjekten in ABAP anzulegen. Die Typgruppe wird dafür
immer noch verwendet. Beim neu Anlegen von globalen komplexen Datentypen
sollten Sie in Zukunft die Möglichkeiten der Dictionary-Strukturen verwenden.
Außerdem wurde und wird die Typgruppe für das Anlegen von globalen
Konstanten verwendet. Das Verwenden von globalen Konstanten wird auch von
ABAP-Objekts in Form von konstanten Attributen einer Klasse unterstützt. Wenn
Sie jedoch nicht objektorientiert programmieren wollen, bleibt nur die Typgruppe
für das Definieren einer globalen Konstante.

Abbildung 7: Datentypen im ABAP-Dictionary
Für die Definition von Datenobjekten in ABAP-Programmen können, mit

Ausnahme der Domäne die obigen Typdefinitionen verwendet werden. Die Pfeile
zeigen die gegenseitige Verwendbarkeit an.
Datenelemente verwenden idealerweise Domänen um ihre technischen
Eigenschaften zu definieren. Auf Domänen kann ein ABAP-Programm jedoch
nicht zur Definition von Datenobjekten zugreifen,
Datenelemente beziehen Ihren Datentyp in der Regel aus Domänen. Dieser
Datentyp kann aber auch aus einem eingebauten Typ abgeleitet werden.
Eine Struktur besteht aus Komponenten die elementare Felder, Tabellen und
wiederum Strukturen sein können.
Der Zeilentyp eines Tabellentyps (ITAB) kann ein strukturierter Typ oder ein
elementarer Typ sein.

Abbildung 8: Domäne
Die Domänen dienen zur zentralen Verwaltung der technischen Eigenschaften

von Datenobjekten. Die Domänen können nicht direkt zur Verwendung in
Programmen, Tabellen usw. verwendet werden. Der Datentyp ‚Datenelement‘
(siehe unten) dient hier als Brücke der Technischen Eigenschaften in die
verschiedenen Datentypen / Datenobjekte.
Unter Technischen Informationen sind folgende Punkte zu verstehen:
Format:
In den Angaben zum Format finden sich der Datentyp und die Anzahl
der Stellen, die in ein abhängiges Datenobjekt eingegeben werden
können. Für den Fall, daß das Format numerischen Charakter hat, kann
auch noch eine Größe für die Nachkommastellen bestimmt werden.
Der Datentyp basiert auf 24 eingebauten Typen. Die am häufigsten
verwendeten Datentypen werden im Folgenden erläutert :
CHAR
Zeichenfolge
Felder vom Typ CHAR dürfen in Tabellen nur die maximale
Länge 255 haben. Sollen längere Zeichenfolgen in Tabellen
benutzt werden, ist der Datentyp LCHR zu wählen. In Strukturen
bestehen keine Begrenzungen bzgl. der Länge solcher Felder.
DATS
Datum

Die Länge ist bei diesem Datentyp auf 8 Stellen festgelegt. Die
Ausgabemaske kann über das Benutzerprofil festgelegt werden.
DEC
Rechen- oder Betragsfeld mit Komma, Vorzeichen und
Tausenderpunkten.
Ein DEC Feld darf maximal 31 Stellen lang sein.
NUMC
Zeichenfolge, die nur Ziffern enthalten darf. Die Länge eines
Feldes dieses Typs ist auf maximal 255 Stellen begrenzt.
Ausgabeeigenschaften:
Hier wird die maximale Feldlänge inklusive Aufbereitungszeichen
(z.B. Kommata oder Punkte) für die Eingabe und Ausgabe von Werten
angegeben.
Dieser Wert wird normalerweise automatisch berechnet, sobald unter
Format eine Anzahl der Stellen vergeben wurde, kann aber nachträglich
überschrieben werden. Das Ausgabeformat wirkt sich auf die Ausgabe
auf Dynpros und Selektionsbildern aus. Beim Einbau eines Feldes
auf ein Dynpro werden die Angaben aus diesem Bereich verwendet,
können jedoch im Screen Painter modifiziert werden.
Des weiteren besteht die Möglichkeit, eine Konvertierungsroutine
für diese Domäne zu definieren. Sie dient dazu, beim Umwandeln
des Inhalts eines Dynpro-Feldes vom Anzeigeformat in das
SAP-interne Format und umgekehrt, sowie bei der Ausgabe mittels
der ABAP-Anweisung WRITE , das Anzeigeformat zu ändern (z.B.
führende Nullen vor eine Zahl stellen). Ebenso können mit dieser
Konvertierungs-Routine evtl. ungeeignete Standardkonvertierungen
übersteuert werden.
Für bestimmte Datentypen (DEC, FLTP, QUAN und CURR) wird
die Checkbox Vorzeichen eingabebereit. Wird diese aktiviert, wird
auf einem Dynpro das erste Zeichen des Feldes für das Vorzeichen
reserviert. Die Ausgabelänge sollte entsprechend um 1 erhöht werden.
Für zeichenartige Datentypen kann außerdem bestimmt werden, ob
auch Kleinbuchstaben erlaubt sind. Ist dieses Flag nicht gesetzt,
können zwar im entsprechenden Eingabefeld Kleinbuchstaben erfasst
werden, die jedoch in Großbuchstaben umgewandelt werden, sobald
die Eingabe vom Anwender bestätigt wird (z.B. ENTER-Taste).
Darüber hinaus können gültige Wertebereiche definiert werden, die
zur Eingabeprüfung verwendet werden. Diese Thema wird jedoch an
anderer Stelle im Kurs noch näher erläutert.

Abbildung 9: Datenelement
Die Datenelemente sind zum einen die Brücke zwischen Domänen und den
Datenobjekten, beherbergen darüber hinaus aber auch noch semantische/fachliche
Informationen über daraus erzeugte Datenobjekte.
In den Datenelementen können und sollten auch die Feldbezeichner für das
Datenfeld gepflegt sein. Diese Feldbezeichner (kurz, mittel oder lang) können
später auf Dynpros oder Selektionsbildern zur Erläuterung des Feldinhaltes
angezeigt werden.
Auf Selektionsbildern (z.B. ABAP-Befehl PARAMETERS) kann nur die
lange Version des Feldbezeichners aus dem Dictionary gezogen werden (Im
ABAP-Editor Menüpfad: Springen -> Textelemente -> Selectionstext =>
Checkbox ‚Dictionary Referenz ).
Wird der Feldwert in einer Liste ausgegeben, wird der Eintrag aus dem
Feldbezeichner für Überschrift verwendet. Für die jeweiligen Feldbezeichner
ist auch eine Länge mitzugeben. Diese Länge gibt die maximale Länge für den
Feldbezeichner an. Für den Fall, daß Sie für ein global agierendes Unternehmen
arbeiten, können Sie die Feldbezeichner in andere Sprachen übersetzen
(Menüpfad: Springen -> Übersetzung oder die Transaktion SE63). Denken Sie
bei der Längenangabe daran, daß in einer anderen Sprache der gleiche Begriff im
Feldbezeichner evtl. mehr Buchstaben benötigt.

An ein Datenelement kann eine Suchhilfe (F4-Hilfe / Wertehilfe) angehängt

werden. Das Thema Suchhilfen wird in einem folgenden Kapitel des Kurses
ausführlicher behandelt. Suchhilfen können auf verschiedenen Ebenen
eingebunden werden.
In verschiedenen Anwendungen kommt es vor, daß ein bestimmter Wert auf
mehreren Dynpro‘s einzugeben ist. Um dem Anwender die mehrfach gleiche
Eingabe des gleichen Wertes zu ersparen, ist es möglich dem Datenelement
einen SET/GET-Parameter zuzuweisen. In diesen Parameter wird der Wert
übertragen, wenn das Dynpro verlassen wird. Sollte auf einem folgenden Dynpro
ein Eingabefeld existieren, daß auf dem gleichen Datenelement basiert, wird
dieser Wert aus dem Parameter ausgelesen und in das Dynprofeld eingetragen.
Die SET/GET-Parameter halten den Wert pro Sitzung. Nachdem sich der
Anwender abgemeldet hat, gehen diese Werte verloren. Zur Verwendung eines
SET/GET-Parameters muß dieser in der Tabelle TPARA eingetragen sein!
Sie können dem Datenelement außerdem einen englischsprachigen Defaultnamen
zuordnen. Dies wirkt sich jedoch nur aus, wenn Sie das Datenelement als
Komponente in BAPI-Strukturen verwenden. Diese sollten den Defaultnamen
verwenden, damit Komponentennamen einheitlich vergeben werden.
Über den Reiter Datentyp, werden die technischen Eigenschaften für das
Datenelement gepflegt. Hier sollten vor allem Domänen zum Einsatz kommen, da
Sie für die technische Typisierung prädestiniert sind. Es ist jedoch auch möglich
das Datenelement über die gleichen eingebauten Typen zu definieren, die für die
Definition der Domänen verwendet wird. Als Spezialfall ist es auch möglich ein
Datenelement als Referenztyp anzulegen. Der referenzierte Typ ist dabei nicht
auf den Typ ‚DATENELEMENT‘ beschränkt. Es kann ein beliebiger anderer
Referenztyp oder gar eine generische Referenz auf ANY, OBJECT oder DATA
sein. Eine Referenz des Typs ANY kann sowohl auf Objekte als auch auf Daten
zeigen. Die Definition als Referenz entspricht der Typdeklaration in einem
ABAP-Programm “TYPES tr_dt TYPE REF TO data”.

Abbildung 10: Strukturen
Eine Struktur besteht aus Komponenten in Form von Datenelementen, eingebauten

Typen, Strukturdefinitionen von internen Tabellen, DB-Tabellen Views oder
anderen bestehenden Strukturdefinitionen.
Auch wenn über das Inkludieren einer View oder DB-Tabelle Felder eines
eigentlich zweidimensionalen Objekts in die Struktur aufgenommen werden,
bleibt das daraus erzeugbare Datenobjekt flach (eindimensional).
Eine sogenannte Tiefe Struktur entsteht immer dann, wenn für die Definition
einer Komponente ein Tabellentyp verwendet wird. Diese Komponente ist dann
zwar zweidimensional, die restlichen Komponenten der Struktur bleiben jedoch
flach (eindimensional).

Abbildung 11: Einfache Strukturen in ABAP verwenden
Die einfachste Form einer Struktur ist die Aneinanderreihung von Feldern durch
das Verwenden von Datenelementen. Hierbei entsteht immer eine sog. flache
Struktur. Ein Datenobjekt auf Basis dieses Strukturtyps ist immer eindimensional
(im Gegensatz zu einem tabellenartigen zweidimensionalen Datenobjekt). Die
einzelnen Elemente (Komponenten) der Struktur werden über den Namen der
Struktur, einen Bindestrich und den Namen der Komponente angesprochen.

Abbildung 12: Geschachtelte Struktur
Es ist möglich ein anderes strukturiertes Objekt mit in die Struktur aufzunehmen
und einer Komponente zuzuweisen. Diese eine Komponente referiert auf das
strukturierte Objekt und dieses neue Datenobjekt wird nun als geschachtelte
Struktur bezeichnet.
Derartige Strukturen sind beliebig ineinander schachtelbar.

Abbildung 13: Interne Tabellen
Sobald man eine interne Tabelle als Strukturkomponente einfügt, wird daraus
eine sogenannte tiefe Struktur.
Interne Tabellen oder ITAB‘s, können über eine bestehende Zeilenstruktur
definiert werden. Dabei können Datenbanktabellen, Strukturdefinitionen, Views,
Datenelemente, direkte Typdefinitionen oder bestehende Tabellentypen als
Zeilentyp verwendet werden.
Durch das deklarieren einer Internen Tabelle in einem ABAP-Programm entsteht
ein zweidimensionales Array im Hauptsspeicher.

Abbildung 14: Tiefe Struktur
Eine tiefe Struktur enthält mindestens eine Tabelle. Die Komponente einer solchen
Tabelle trägt einen eigenen Namen, über den sie wie eine normale interne Tabelle
angesprochen werden kann (LOOP AT ..., INSERT ... INTO TABLE, ...).
Eine interne Tabelle kann als Zeilentyp wiederum eine tiefe Struktur
haben. Dadurch kann man mehrdimensionale Datentypen erzeugen, da das
ineinanderschachteln von interner Tabelle und Struktur mehrfach möglich ist.
Achtung: Im Gegensatz dazu können Datenbanktabellen nur flache

Strukturen aufnehmen.

Abbildung 15: Typgruppe
Falls Sie globale Konstanten definieren möchten, müssen Sie eine Typgruppe
verwenden. Der Name der Typgruppe darf maximal fünf Zeichen enthalten. In der
Typgruppe können Sie mit der CONSTANTS-Anweisung Konstanten definieren.
Als Typen stehen Ihnen die eingebauten ABAP-Typen oder die globalen Typen
des Dictionarys zur Verfügung.
Um die Typen einer Typgruppe in einem Programm nutzen zu können, machen Sie
die Typgruppe mit TYPE-POOLS-Anweisung bekannt. Ab dieser Zeile können
Sie alle Konstanten der Typgruppe verwenden.
Die Definition einer Typgruppe ist ein Stück ABAP-Code, das entweder über das
Dictionary (SE11) oder über den ABAP-Editor (SE38) gepflegt wird.
Realisierung:
Die erste Anweisung für die Typgruppe zmytp ist immer: TYPE-POOL zmytp.
Danach folgt die Definition von Datentypen mit der Anweisung TYPES,
wie unter Programmlokale Datentypen beschrieben. Weiterhin können
programmübergreifende Konstanten mit der Anweisung CONSTANTS deklariert
werden. Alle Namen dieser Datentypen und Konstanten müssen mit dem Namen
der Typgruppe und einem Unterstrich beginnen:
zmytp_
In einem ABAP-Programm müssen Typgruppen vor ihrer Verwendung mit
folgender Anweisung bekanntgemacht werden:

TYPE-POOLS zmytp.
Bei Verwendung dieser Anweisung können alle Datentypen und Konstanten, die
in der Typgruppe zmytp definiert sind, im Programm verwendet werden. Es
können mehrere Typgruppen in einem Programm verwendet werden.

Übung 1: Grundlegende Datentypen

Lernziele der Übung
Am Ende dieser Übung können Sie
• Grundlegende Datentypen im Dictionary anlegen und in ABAP-Programmen
verwenden
Sie sollten für Ihr Entwicklungsprojekt einige globale Datentypen anlegen, auf
welche auch die anderen Projektbeteiligten zugreifen können.
Aufgabe 1:
Legen Sie zwei Domänen an, um Sie später in Datenelementen verwenden zu
können.
1. Rufen Sie die Transaktion SE11 auf.
2. Legen Sie eine Domäne mit dem Namen ZDO_10NUM_## Im Einstiegsbild
des ABAP-Dictionaries an.
3. Die Domäne soll für Datenelemente angelegt werden, die für 10stellige
Dezimalzahlen aufnehmen sollen. Von den 10 Stellen sollen 2 Stellen für
Nachkomma reserviert werden. Die Datenelemente sollen ausserdem für
kaufmännische Berechungen verwendet werden können.
4. Sichern (als lokales Objekt) und aktivieren Sie die Domäne.
5. Legen Sie eine Domäne mit dem Namen ZDO_30CHAR_## im
Einstiegsbild des ABAP-Dictionaries an. Die Domäne soll 30 Textzeichen
aufnehmen können und in den Eingabefeldern soll die Eingabe von
Kleinbuchstaben erlaubt sein..
Aufgabe 2:
Legen Sie meherere Datenelemente an und verwenden Sie die bereits definierten
Domänen für die technischen Eigenschaften.
2. Legen Sie ein Datenelement (ZLASTNAME##) für den Nachnamen einer
Person an und verwenden Sie eine passende Domäne. Das Datenelement soll
30 Buchstaben in Groß- und Kleinschrift aufnehmen können.
Fortsetzung auf der nächsten Seite

3. Legen Sie ein Datenelement (ZFIRSTNAME##) für den Vornamen einer

4. Legen Sie ein Datenelement (ZASSETS##) für Aktiva an und verwenden
Sie eine passende Domäne. Das Datenelement soll für kaufmännische
Berechnungen verwendet werden.
5. Legen Sie ein Datenelement (ZLIABILITIES##) für Passiva an und
verwenden Sie eine passende Domäne. Das Datenelement soll für
kaufmännische Berechnungen verwendet werden.
Aufgabe 3:
Programm anlegen
1. Legen Sie das ausführbare Programm ZBC430_##_DATA_ELEMENTS
ohne „TOP-Include“ an.
2. Legen Sie im Programm mit dem ABAP-Befehl PARAMETERS die
folgenden Eingabefelder an.
Parameter Datentyp
pa_fname ZFIRSTNAME##
pa_lname ZLASTNAME##
pa_activ ZASSETS##
pa_liabs ZLIABILITIES##
Berechnen Sie das Ergebnis von Aktiva minus Passiva und geben Sie alle
Parameter sowie das Rechenergebniss auf einer Liste aus.
3. Führen Sie das Programm aus und geben Sie verschiedene Werte im
Selektionsbild ein, die Sie sich auf einer Liste ausgeben lassen.

Lösung 1: Grundlegende Datentypen

Aufgabe 1:
Legen Sie zwei Domänen an, um Sie später in Datenelementen verwenden zu
können.
a) Gehen Sie ins Kommandofeld tragen Sie se11, wenn Sie sich im SAP
EASY ACCESS-Menü befinden, ein und bestätigen Sie die Eingaben
Befinden Sie sich in einer anderen Transaktion, müssen Sie ins
Kommandofeld /n se11 eintragen und die Eingabe bestätigen.
2. Legen Sie eine Domäne mit dem Namen ZDO_10NUM_## Im Einstiegsbild
des ABAP-Dictionaries an.
a) Wählen Sie auf den Radiobuttons den Punkt Domäne aus.
b) Tragen Sie den Namen der Domäne in das Eingabefeld ein.
c) Drücken Sie die Schaltfläche für Anlegen
3. Die Domäne soll für Datenelemente angelegt werden, die für 10stellige
Dezimalzahlen aufnehmen sollen. Von den 10 Stellen sollen 2 Stellen für
Nachkomma reserviert werden. Die Datenelemente sollen ausserdem für
kaufmännische Berechungen verwendet werden können.
a) Tragen Sie im Feld Kurzbeschreibung einen sinnvollen beschreibenden
Text für die Domäne ein
b) Tragen Sie im Feld Datentyp den Wert DEC ein oder wählen Sie diesen
Eintrag aus der Wertehilfe (F4) aus.
c) Im Feld Zahl der Stellen tragen Sie den Wert 10 ein
d) Im Feld Dezimalstellen tragen Sie den Wert 2 ein
e) Setzten Sie den Haken an der Checkbox Vorzeichen
a) Betätigen Sie dazu die Schaltfläche Sichern in der oberen Leiste der
Schaltflächen.
5. Legen Sie eine Domäne mit dem Namen ZDO_30CHAR_## im
Einstiegsbild des ABAP-Dictionaries an. Die Domäne soll 30 Textzeichen
aufnehmen können und in den Eingabefeldern soll die Eingabe von
Kleinbuchstaben erlaubt sein..
a) Gehen Sie wie in den vorangegangenen Schritten vor und definieren
Sie die entsprechenden Eigenschaften unter dem Reiter Definition


a) Betätigen Sie dazu die Schaltfläche Sichern in der oberen Leiste der
Schaltflächen.
Aufgabe 2:
Legen Sie meherere Datenelemente an und verwenden Sie die bereits definierten
Domänen für die technischen Eigenschaften.
a) Gehen Sie ins Kommandofeld tragen Sie se11 ein, wenn Sie sich im
SAP EASY ACCESS-Menü befinden, ein und bestätigen Sie die
Eingaben
Befinden Sie sich in einer anderen Transaktion befinden, müssen Sie
ins Kommandofeld /n se11 eintragen und die Eingabe bestätigen.
2. Legen Sie ein Datenelement (ZLASTNAME##) für den Nachnamen einer
a) Wählen Sie auf den Radiobuttons den Punkt Datentyp aus.
b) Tragen Sie den Namen des Datentyps in das Eingabefeld ein.
c) Drücken Sie die Schaltfläche für Anlegen.
d) Im erscheinenden Popup wählen Sie den Radiobutton für Datenelement
aus und bestätigen Sie die Eingabe.
e) Tragen Sie im Feld Kurzbeschreibung einen sinnvollen beschreibenden
Text für das Datenelement ein.
f) Unter dem Reiter Datentyp geben Sie unter elementarer Typ die
passende Domäne an, die sie im verhergehenden Teil der Übung
angelegt haben
g) Unter dem Reiter Feldbezeichner müssen Sie noch geeignete
Bezeichnungen für Ihr Datenelement erfassen. Diese Bezeichnungen
erscheinen z.b. auf Dynpros und Selektionsbildern (Lange Version)
zur Erläuterung der Felder.
3. Legen Sie ein Datenelement (ZFIRSTNAME##) für den Vornamen einer
a) Verfahren Sie analog zum vorherigen Übung.

4. Legen Sie ein Datenelement (ZASSETS##) für Aktiva an und verwenden

Sie eine passende Domäne. Das Datenelement soll für kaufmännische
Berechnungen verwendet werden.
5. Legen Sie ein Datenelement (ZLIABILITIES##) für Passiva an und
verwenden Sie eine passende Domäne. Das Datenelement soll für
kaufmännische Berechnungen verwendet werden.
Aufgabe 3:
Programm anlegen
1. Legen Sie das ausführbare Programm ZBC430_##_DATA_ELEMENTS
ohne „TOP-Include“ an.
a) Verwenden Sie zum Anlegen die Transaktion SE80 oder die
Transaktion SE38.
2. Legen Sie im Programm mit dem ABAP-Befehl PARAMETERS die
folgenden Eingabefelder an.
Parameter Datentyp
pa_fname ZFIRSTNAME##
pa_lname ZLASTNAME##
pa_activ ZASSETS##
pa_liabs ZLIABILITIES##
Berechnen Sie das Ergebnis von Aktiva minus Passiva und geben Sie alle
Parameter sowie das Rechenergebniss auf einer Liste aus.
a) Siehe Quelltextauszug in der Musterlösung.

3. Führen Sie das Programm aus und geben Sie verschiedene Werte im
Selektionsbild ein, die Sie sich auf einer Liste ausgeben lassen.
a) Beachten Sie, daß entsprechend den Definitionen in den Domänen
bei den Namen die Eingabe von Groß- und Kleinbuchstaben möglich
sein muß. Bei den beiden numerischen Feldern muss die Eingabe der
Nachkommastellen und eines negativen Vorzeichens möglich sein.
Ergebnis
Quelltextauszug: SAPBC430S_DATA_ELEMENTS
REPORT sapbc430s_data_elements .
*Replace ## by Your Group- Screennumber and uncomment the ABAP-coding
DATA: result TYPE zassets##.
PARAMETERS: pa_fname TYPE zfirstname##,

pa_lname TYPE zlastname##,
pa_activ TYPE zassets##,
pa_liabs TYPE zliabilities##.
START-OF-SELECTION.
NEW-LINE.
WRITE: 'Client:', pa_fname, pa_lname.
result = pa_activ - pa_liabs.
NEW-LINE.
WRITE: 'Finance:', pa_activ, pa_liabs, result.

Übung 2: Einfache und geschachtelte

Strukturen
• einfache und geschachtelte Strukturen im Dictionary anlegen und in
Um komplexe Datenstrukturen abbilden zu können sollen Sie für Ihr Projekt eine
komplexe Struktur im Dictionary aufbauen.
Aufgabe 1:
Legen Sie einfache Strukturen an, um Sie später in ABAP-Programmen
verwenden zu können.
1. Legen Sie im Dictionary eine Struktur ZNAME## an und nehmen Sie
die zwei folgenden Komponenten in die Struktur auf. Verwenden Sie zur
Typisierung die Datenelemente, die Sie in vorangegangenen Übungen
erzeugt haben
Komponente Komponententyp Bedeutung
FIRSTNAME eigener Vorname

LASTNAME eigener Nachname
2. Legen Sie eine Struktur ZADRESS## an und tragen Sie die vier folgenden
Komponenten ein:
STREET S_STREET Straße

NR S_NO Hausnummer
ZIP POSTCODE Postleitzahl
CITY S_CITY Wohnort

Aufgabe 2:
Legen Sie eine geschachtelte Struktur an, um Sie später in ABAP-Programmen
1. Legen Sie im Dictionary eine Struktur ZPERSON## an.
2. Nehmen Sie in die Struktur ZPERSON## die Struktur ZADRESS## als
Include-Struktur auf. Nehmen Sie außerdem die Struktur ZNAME##
als geschachtelte Struktur unter dem Komponentennamen NAME in die
Struktur ZPERSON## auf.
3. Legen Sie ein ABAP-Programm ZBC430_##_STRUCT_NESTED
an. Erzeugen Sie in diesem Programm ein strukturiertes Datenobjekt
(wa_person) vom Typ ZPERSON##. Füllen Sie die Komponenten dieses
Datenojekts mit beliebigen Personendaten und geben Sie diese Daten auf
einer Liste aus.

Lösung 2: Einfache und geschachtelte

Strukturen
Aufgabe 1:
Legen Sie einfache Strukturen an, um Sie später in ABAP-Programmen
1. Legen Sie im Dictionary eine Struktur ZNAME## an und nehmen Sie
die zwei folgenden Komponenten in die Struktur auf. Verwenden Sie zur
Typisierung die Datenelemente, die Sie in vorangegangenen Übungen
erzeugt haben
FIRSTNAME eigener Vorname

LASTNAME eigener Nachname
a) Starten Sie die SE11 und tragen Sie im Eingabefeld Datentyp den
Namen der Struktur ein.
b) Drücken Sie auf die Schaltfläche Anlegen und wählen Sie im folgenden
Dialog Struktur aus.
c) Vergeben Sie ein Kurzbeschreibung und tragen Sie die angegebenen
Komponenten ein. Aktivieren Sie die Struktur, damit Sie global
bekannt ist.
2. Legen Sie eine Struktur ZADRESS## an und tragen Sie die vier folgenden
Komponenten ein:
STREET S_STREET Straße

NR S_NO Hausnummer
ZIP POSTCODE Postleitzahl
CITY S_CITY Wohnort
a) Gehen Sie analog zum vorangegangenen Übungsteil vor.

Aufgabe 2:
Legen Sie eine geschachtelte Struktur an, um Sie später in ABAP-Programmen
1. Legen Sie im Dictionary eine Struktur ZPERSON## an.
a) Gehen Sie analog zum vorangegangenen Übungsteil vor.
2. Nehmen Sie in die Struktur ZPERSON## die Struktur ZADRESS## als
Include-Struktur auf. Nehmen Sie außerdem die Struktur ZNAME##
als geschachtelte Struktur unter dem Komponentennamen NAME in die
Struktur ZPERSON## auf.
a) Includieren Sie die Adresse entweder über das Menü
Bearbeiten->Include->Einfügen oder schreiben Sie in der Spalte
Komponente das Schlüsselwort .INCLUDE.
Achtung: Der Punkt vor dem Schlüsselwort ist wichtig.
Für die zweite Struktur, die Sie als tiefe Struktur aufnehmen wollen,
geben Sie eine beliebige Komponentenbezeichnung (z.B. 'Name') ein.
.include ZADRESS## Adressenstruktur

NAME ZNAME## referiert auf die
Namens-Struktur

3. Legen Sie ein ABAP-Programm ZBC430_##_STRUCT_NESTED

an. Erzeugen Sie in diesem Programm ein strukturiertes Datenobjekt
(wa_person) vom Typ ZPERSON##. Füllen Sie die Komponenten dieses
Datenojekts mit beliebigen Personendaten und geben Sie diese Daten auf
einer Liste aus.
Ergebnis
Quelltextauszug: SAPBC430S_STRUCT_NESTED
REPORT sapbc430s_struct_nested.
*Replace ## by Your group- or screennumber and

*uncomment the ABAP-coding
DATA wa_person TYPE zperson##.
START-OF-SELECTION.
wa_person-name-firstname = 'Harry'.
wa_person-name-lastname = 'Potter'.
wa_person-street = 'Privet Drive'.

wa_person-nr = '3'.
wa_person-zip = 'GB-10889'.
wa_person-city = 'London'.
WRITE: / wa_person-name-firstname ,
wa_person-name-lastname ,
wa_person-street ,
wa_person-nr ,
wa_person-zip ,
wa_person-city .


Übung 3: Tabellentypen (interne Tabellen

/ ITAB's)
• Tabellentypen anlegen und in ABAP-Programmen verwenden
Zur lokalen Datenhaltung sollen Sie einen Tabelletyp definieren, der die Daten
sortiert vorhält.
Aufgabe:
Legen Sie einfache interne Tabelle auf Basis einer vorhandenen Struktur an, um
Sie später in ABAP-Programmen verwenden zu können.
1. Legen Sie im Dictionary einen Tabellentyp ZIT_SFLIGHT## an. Der
Tabellentyp soll auf dem Zeilentyp der Datenbanktabelle SFLIGHT basieren
und nach dem Flugdatum (FLDATE) sortiert sein
2. Legen Sie ein ABAP-Programm ZBC430_##_ITAB_SORTED an.
Erzeugen Sie in diesem Programm als Arbeitsbereich ein strukturiertes
Datenobjekt (wa_sflight) vom Typ SFLIGHT und eine interne Tabelle auf
Basis des soeben definierten Tabellentyps. Selektieren Sie aus der Tabelle
SFLIGHT die Daten einer Fluggesellschaft (z.B. 'JL') in den Arbeitsbereich
und geben diesen unsortiert in einer Liste aus.
3. Erweitern Sie das Programm folgendermaßen. Fügen Sie eine Linie
(ABAP-Befehl ULINE ) in die Liste ein. Laden Sie die gleichen Daten
erneut über den SELECT-Befehl mit Array-Fetch in die interne Tabelle vom
Typ ZIT_SFLIGHT## und geben Sie den Inhalt der Tabelle mit Hilfe des
LOOP-Befehls auf der selben Liste aus. Vergleichen Sie die Reihenfolge, der
Daten in den beiden Listenabschnitten.

Lösung 3: Tabellentypen (interne Tabellen

/ ITAB's)
Aufgabe:
Legen Sie einfache interne Tabelle auf Basis einer vorhandenen Struktur an, um
Sie später in ABAP-Programmen verwenden zu können.
1. Legen Sie im Dictionary einen Tabellentyp ZIT_SFLIGHT## an. Der
Tabellentyp soll auf dem Zeilentyp der Datenbanktabelle SFLIGHT basieren
und nach dem Flugdatum (FLDATE) sortiert sein
a) Gehen Sie ins Kommandofeld und tragen Sie se11, wenn Sie sich
im SAP EASY ACCESS-Menü befinden, ein und bestätigen Sie die
Eingaben
b) Wählen Sie auf den Radiobuttons den Punkt Datentyp
c) Tragen Sie den Namen der Tabelle in das Eingabefeld ein.
d) Drücken Sie die Schaltfläche für Anlegen.
e) Wählen Sie im folgenden Dialog Tabellentyp aus.
f) Vergeben Sie eine Kurzbeschreibung und tragen Sie im Feld Zeilentyp
den Namen der Datenbanktabelle ein.
g) Wechseln Sie auf den Tabreiter Initialisierung und Zugriff und wählen
Sie als Zugriffsart Sortierte Tabelle aus.
h) Wechseln Sie auf den Tabreiter Schlüssel und wählen Sie als
Schlüsselart nonunique aus.
i) Wählen Sie nun noch die entsprechende Schlüsselkomponente über
die Schlüsseldefinition Schlüsselkomponenten und die Schaltfläche
Komponenten auswählen.
j) Aktivieren Sie die Tabelle, damit Sie global bekannt ist.
2. Legen Sie ein ABAP-Programm ZBC430_##_ITAB_SORTED an.
Erzeugen Sie in diesem Programm als Arbeitsbereich ein strukturiertes
Datenobjekt (wa_sflight) vom Typ SFLIGHT und eine interne Tabelle auf
Basis des soeben definierten Tabellentyps. Selektieren Sie aus der Tabelle
SFLIGHT die Daten einer Fluggesellschaft (z.B. 'JL') in den Arbeitsbereich
und geben diesen unsortiert in einer Liste aus.

3. Erweitern Sie das Programm folgendermaßen. Fügen Sie eine Linie

(ABAP-Befehl ULINE ) in die Liste ein. Laden Sie die gleichen Daten
erneut über den SELECT-Befehl mit Array-Fetch in die interne Tabelle vom
Typ ZIT_SFLIGHT## und geben Sie den Inhalt der Tabelle mit Hilfe des
LOOP-Befehls auf der selben Liste aus. Vergleichen Sie die Reihenfolge, der
Daten in den beiden Listenabschnitten.
Ergebnis
Quelltextauszug: SAPBC430S_ITAB_SORTED
REPORT SAPBC430S_ITAB_SORTED.
**Replace ## by Your group- or screennumber and

**uncomment the ABAP-coding
DATA it_flight TYPE zit_sflight##.

DATA wa_sflight TYPE sflight.
WRITE / 'Printout in tableorder of Database:'.
SELECT * FROM sflight

INTO wa_sflight
WHERE carrid = 'JL'.
WRITE: / wa_sflight-carrid,
wa_sflight-connid,
wa_sflight-fldate,
wa_sflight-price,
wa_sflight-currency,
wa_sflight-planetype.
ENDSELECT.
ULINE.
SELECT * FROM sflight

INTO TABLE it_flight
WHERE carrid = 'JL'.
WRITE / 'Printout in tableorder of sorted ITAB:'.
LOOP AT it_flight INTO wa_sflight.

WRITE: / wa_sflight-carrid,
wa_sflight-connid,

wa_sflight-fldate,
wa_sflight-price,
wa_sflight-currency,
wa_sflight-planetype.
ENDLOOP.

Übung 4: Tiefe Strukturen

• tiefe Strukturen anlegen und in ABAP-Programmen verwenden
Sie sollen für Ihr Projektteam die Struktur der Personendaten insoweit erweitern,
dass Sie eine beliebig lange Telefonliste für jeden Mitarbeiter aufnehmen kann.
Aufgabe:
Legen Sie eine interne Tabelle auf Basis eines Datenobjektes an, um Sie in eine
Struktur aufzunehmen. Verwenden Sie diese in einem ABAP-Programm.
1. Legen Sie im Dictionary einen Tabellentyp einer Standard-Tabelle
ZIT_PHONE_NUMBER## an. Der Tabellentyp soll auf dem Zeilentyp
der bestehenden Struktur STR_PHONE basieren.
2. Erweitern Sie im Dictionary Ihre bestehende StrukturZPERSON##. Die
neue Komponente soll den Namen PHONE erhalten und auf der internen
Tabelle ZIT_PHONE_NUMBER## basieren.
3. Legen Sie ein ABAP-Programm ZBC430_##_STRUCT_DEEP
an. Kopieren Sie dazu Ihre Lösung des Programmes
ZBC430_##_STRUCT_NESTED oder die Mustervorlage
SAPBC430S_STRUCT_NESTED. Erweitern Sie dieses Programm um
einen Arbeitsbereich für ein strukturiertes Datenobjekt (wa_phone) vom
Typ STR_PHONE.
4. Erweitern Sie das Programm folgendermaßen:
Fügen Sie drei Telefonnummern in das strukturierte Datenobjekt wa_person
ein und geben Sie diese Daten mit Hilfe des LOOP-Befehls auf der selben
Liste aus.

Lösung 4: Tiefe Strukturen

Aufgabe:
Legen Sie eine interne Tabelle auf Basis eines Datenobjektes an, um Sie in eine
Struktur aufzunehmen. Verwenden Sie diese in einem ABAP-Programm.
1. Legen Sie im Dictionary einen Tabellentyp einer Standard-Tabelle
ZIT_PHONE_NUMBER## an. Der Tabellentyp soll auf dem Zeilentyp
der bestehenden Struktur STR_PHONE basieren.
a) Gehen Sie ins Kommandofeld und tragen Sie se11, wenn Sie sich
im SAP EASY ACCESS-Menü befinden, ein und bestätigen Sie die
Eingaben
b) Wählen Sie auf den Radiobuttons den Punkt Datentyp
c) Tragen Sie den Namen der Tabelle in das Eingabefeld ein.
d) Drücken Sie die Schaltfläche für Anlegen.
e) Wählen Sie im folgenden Dialog Tabellentyp aus.
f) Vergeben Sie eine Kurzbeschreibung und tragen Sie im Feld Zeilentyp
den Namen der Struktur ein.
g) Wechseln Sie auf den Tabreiter Initialisierung und Zugriff und wählen
Sie als Zugriffsart Standard Tabelle aus.
h) Wechseln Sie auf den Tabreiter Schlüssel und wählen Sie als
Schlüsselart nonunique aus.
i) Wählen Sie nun noch als Schlüsseldefinition den Standardschlüssel

2. Erweitern Sie im Dictionary Ihre bestehende StrukturZPERSON##. Die

neue Komponente soll den Namen PHONE erhalten und auf der internen
Tabelle ZIT_PHONE_NUMBER## basieren.
a) tragen Sie eine neue Komponente mit dem Namen Phone in Ihre
Struktur ein und geben Sie als Komponententyp den neu geschaffenen
Tabellentyp an.
.include ZADRESS## Adressenstruktur

NAME ZNAME## referiert auf die
Namens-Struktur
PHONE ZIT_PHONE_NUM- referiert auf die
BER## Telefontabelle
3. Legen Sie ein ABAP-Programm ZBC430_##_STRUCT_DEEP

an. Kopieren Sie dazu Ihre Lösung des Programmes
ZBC430_##_STRUCT_NESTED oder die Mustervorlage
SAPBC430S_STRUCT_NESTED. Erweitern Sie dieses Programm um
einen Arbeitsbereich für ein strukturiertes Datenobjekt (wa_phone) vom
Typ STR_PHONE.
4. Erweitern Sie das Programm folgendermaßen:
Fügen Sie drei Telefonnummern in das strukturierte Datenobjekt wa_person
ein und geben Sie diese Daten mit Hilfe des LOOP-Befehls auf der selben
Liste aus.
Ergebnis
Quelltextauszug: SAPBC430S_STRUCT_DEEP
REPORT sapbc430s_struct_deep.
DATA wa_person TYPE zperson##.

DATA wa_phone TYPE str_phone.
START-OF-SELECTION.
*Fill deep structure with data

wa_person-name-firstname = 'Harry'.
wa_person-name-lastname = 'Potter'.
wa_person-street = 'Privet Drive'.

wa_person-nr = '3'.
wa_person-zip = 'GB-10889'.
wa_person-city = 'London'.
wa_phone-p_type = 'P'.
wa_phone-p_number = '+31-10-9938990'.
INSERT wa_phone INTO TABLE wa_person-phone.
wa_phone-p_type = 'F'.
wa_phone-p_number = '+31-10-9938991'.
wa_phone-p_type = 'M'.
wa_phone-p_number = '+31-79-12211433'.
*Write on List
WRITE: / wa_person-name-firstname ,
wa_person-name-lastname ,
wa_person-street ,
wa_person-nr ,
wa_person-zip ,
wa_person-city .
WRITE: / 'Phone-Numbers:'.
LOOP AT wa_person-phone INTO wa_phone.

WRITE: AT 20 wa_phone-p_type,
wa_phone-p_number.
NEW-LINE.
ENDLOOP.


Nun können Sie

Lektion: Tabellen im ABAP Dictionary

Sie sollen für Ihr Unternehmen Informationseinheiten sog. Entitäten in der
Datenbank abbilden.
Tabellen
Abbildung 16: Tabelle - Feld
Die Struktur der Objekte der Anwendungsentwicklung werden in Tabellen auf der
unterliegenden relationalen Datenbank abgebildet.
Die Attribute dieser Objekte entsprechen Feldern der Tabelle.

BC430 Lektion: Tabellen im ABAP Dictionary
Eine Tabelle besteht aus Spalten (Felder) und Zeilen (Einträgen). Sie hat
einen Namen und verschiedene allgemeine Eigenschaften wie z.B. die
Auslieferungsklasse oder die Pflegeerlaubnis.
Ein Feld hat einen eindeutigen Namen und Eigenschaften, z.B. kann es
Schlüsselfeld sein.
Eine Tabelle hat ein oder mehrere Schlüsselfelder, den sog. Primärschlüssel.
Die Werte dieser Schlüsselfelder identifizieren einen Eintrag der Tabelle eindeutig.
Für Felder, die Währungsangaben (Datentyp CURR) bzw. Mengenangaben
(Datentyp QUAN) enthalten, muß eine Referenztabelle angegeben werden.
Diese muß ein Feld (Referenzfeld) mit dem Währungsschlüsselformat (Datentyp
CUKY) bzw. dem Format für Mengeneinheiten (Datentyp UNIT) enthalten.
Die Zuordnung des Feldes zum Referenzfeld wird erst zur Laufzeit durch ein
Programm hergestellt.
Abbildung 17: Grundobjekte des ABAP Dictionary
Die Grundobjekte zur Datendefinition im ABAP Dictionary sind Tabelle,

Datenelement und Domäne. Die Domäne dient zur technischen (z.B.
Feldtyp, Feldlänge) und das Datenelement zur semantischen Definition (z.B.
Kurzbeschreibung) eines Tabellenfeldes.
Eine Domäne beschreibt den Wertebereich eines Feldes durch Datentyp
und Feldlänge. Der Wertebereich kann durch die Angabe von Festwerten
eingeschränkt werden.
Ein Datenelement beschreibt die Bedeutung einer Domäne in einem bestimmten
betriebswirtschaftlichen Zusammenhang. Das Datenelement enthält hauptsächlich
die Feldhilfe (F1-Doku) und die Feldbezeichner im Dynpro.

Ein Feld ist kein unabhängiges Objekt; es hängt von der Tabelle ab. Ein Feld kann
nur innerhalb einer Tabelle gepflegt werden.
Zu einem Feld können Datentyp und Anzahl der Stellen direkt eingeben werden.
In diesem Fall wird kein Datenelement benötigt. Stattdessen werden durch die
Angabe eines direkten Typs Datentyp und Anzahl der Stellen festgelegt.
Die Datentypeigenschaften eines Datenelements können auch durch die Angabe
eines Eingebauten Typs, wobei Datentyp und Anzahl der Stellen direkt
eingegeben werden, festgelegt werden.
Abbildung 18: Zweistufiges Domänenkonzept: Beispiel
In der Tabelle SPFLI ist der Flugplan hinterlegt. Die Tabellenfelder AIRPFROM
(Startflughafen) und AIRPTO (Zielflughafen) haben die gleiche Domäne
S_AIRPID. Beide Felder verwenden die gleiche Domäne, weil beide Felder
Flughäfen enthalten und damit die gleichen technischen Eigenschaften besitzen.
Sie haben jedoch unterschiedliche semantische Bedeutung und verwenden
unterschiedliche Datenelemente, um dies zu dokumentieren. Das Feld
AIRPFROM verwendet das Datenelement S_FROMAIRP und das Feld AIRPTO
verwendet das Datenelement S_TOAIRP.

Abbildung 19: Transparente Tabellen und Strukturen
Eine transparente Tabelle wird beim Aktivieren im ABAP Dictionary

automatisch auf der Datenbank angelegt. Dabei wird die datenbankunabhängige
Beschreibung der Tabelle im ABAP Dictionary in die Sprache des verwendeten
Datenbank-Systems übersetzt.
Die Datenbanktabelle hat den gleichen Namen wie die Tabelle im ABAP
Dictionary. Auch die Felder haben auf der Datenbank und im ABAP Dictionary
die gleichen Namen. Die Datentypen im ABAP Dictionary werden in die
korrespondierenden Datentypen des Datenbanksystems überführt.
Die Feldreihenfolge im ABAP Dictionary kann von der Feldreihenfolge auf der
Datenbank abweichen. Dies erlaubt das Einfügen neuer Felder, ohne daß die
Tabelle umgesetzt werden muß. Wenn Sie ein neues Feld hinzufügen, passen Sie
die Reihenfolge der Felder an, indem Sie den Datenbankkatalog ändern (ALTER
TABLE). Das neue Feld wird zur Datenbanktabelle hinzugefügt.
Auf eine transparente Tabelle kann von ABAP Programmen auf zwei Arten
zugegriffen werden. Zum einen kann mittels OPEN SQL (oder EXEC SQL) auf
die in der Tabelle enthaltenen Daten zugegriffen werden. Zum anderen definiert
die Tabelle einen strukturierten Typ, auf den bei der Definition von Variablen
(oder komplexeren Typen) zugegriffen werden kann.
Es ist auch möglich, im ABAP Dictionary einen strukturierten Typ anzulegen,
der keine Entsprechung auf der Datenbank besitzt. Solche Typen werden als
Strukturen bezeichnet. Strukturen können ebenfalls zur Typisierung von
Variablen benutzt werden.

Abbildung 20: Include-Strukturen
Strukturen können in Tabellen oder anderen Strukturen inkludiert werden, um

redundante Strukturdefinitionen zu vermeiden.
Eine Tabelle kann immer nur als ganze Tabelle inkludiert werden.
In einer Includekette darf nur eine Datenbanktabelle vorkommen. Die Tabelle,
in die man inkludiert, gehört zur Includekette. Daraus folgt, daß ein Inkludieren
einer tranparenten Tabelle in eine transparente Tabelle nicht erlaubt ist.
Includes können selbst wieder andere Includes enthalten.
Fremdschlüsseldefinitionen werden im allgemeinen vom Include an die
inkludierende Tabelle vererbt. Die Attribute der Fremdschlüsseldefinition werden
dabei vom Include an die inkludierende Tabelle weitergegeben, so daß der
Fremdschlüssel von der Definition im Include abhängt.

Abbildung 21: Technische Einstellungen
Bei der Definition einer transparenten Tabelle im ABAP Dictionary müssen

technische Einstellungen gepflegt werden.
Die technischen Einstellungen dienen der individuellen Optimierung von
Platzbedarf und Zugriffsverhalten von Datenbanktabellen.
Über die technischen Einstellungen kann bestimmt werden, wie die Tabelle beim
Anlegen auf der Datenbank behandelt wird, ob die Tabelle gepuffert wird und ob
Änderungen an Einträgen protokolliert werden sollen.
Beim Aktivieren der Tabelle im ABAP Dictionary wird die Tabelle automatisch
auf der Datenbank angelegt. Die hierbei notwendigen Informationen über den
zu wählenden Speicherbereich (Tablespace) und die vermutliche Tabellengröße
werden aus den Einstellungen für die Datenart und die Größenkategorie ermittelt.
Über die Einstellungen zur Pufferung wird bestimmt, ob und wie die Tabelle
gepuffert wird.
Es kann bestimmt werden, ob Änderungen an den Tabelleneinträgen protokolliert
werden sollen.

Abbildung 22: Fragmentierung der Tabellen in der Datenbank
Insbesondere Tabellen die Bewegungsdaten aufnehmen, können durch schnelles

Wachstum oder häufiges Verändern der Datenbestände (einfügen und löschen
von Datensätzen) große Lücken im allokierten Speicherplatz aufweisen. Diese
Fragmentierung der Daten auf den Festplatten der DB-Server führt immer wieder
zu Performanceproblemen, die durch einfache Maßnamen, wie das Anlegen eines
Index nicht zu beheben sind.
Fragmentierte Indizes können durch das einfache Löschen und wieder Anlegen
defragmentiert werden. Die Datenbank berechnet dabei den Inhalt und den Aufbau
des Index neu und legt den benötigten Speicherplatz nach Möglichkeit in einem
Stück im Speichermedium an. Während der Index neu aufgebaut wird, kann die
DB-Tabelle weiter verwendet werden.
Achtung: Stammt der Index von einer großen Tabelle ( < 100.000
Datensätze ), braucht das Anlegen evtl. mehrere Minuten oder gar Stunden
( bei Tabellen im BW-Umfeld ). Außerdem ist während der Neuanlage
des Index, dieser nicht für die Datenbankzugriffe verwendbar, was zu
einer zusätzlichen Belastung (Full Table Scan) der Datenbank führen
würde, wenn Datensätze aus der entsprechenden Tabelle gelesen werden.
Fragmentierte Tabellen müssen umgesetzt werden (siehe Änderungen an

DB-Tabellen), um die Fragmentierung zu verringern. Das SAP-System erzeugt
dazu eine neue Tabelle. In diese Tabelle werden die Daten übertragen. Die alte
Tabelle wird danach gelöscht, und die neue Tabelle nimmt ihren Platz ein. Sollte

eine Tabelle unerwartet schnell gewachsen sein, sollten vor der Umsetzung die
Technischen Einstellungen dieser Tabelle nochmals überprüft und gegebenenfalls
angepasst werden.
Achtung: Während des Umsetzprozesses kann der Inhalt der Tabelle

weder gelesen noch verändert werden. Der Umsetzprozess einer Tabelle
ist in produktiver Umgebung mit größtmöglicher Vorsicht auszuführen,
da je nach Größe der Tabelle der Umsetzprozess mehrere Minuten bis
Stunden dauern kann.
= > Solche Umsetzprozesse (an Tabellen oder Indizes ) sollten deshalb
möglichst in lastarmen Zeiten stattfinden.
Um derartige Fragmentierungen nach Möglichkeit von vorneherein zu vermeiden,

wählt man entsprechend Größe und Datenart in den technischen Einstellungen
der Tabellen.
Abbildung 23: Datenart
Mit der Datenart können Sie auf logischer Seite festlegen, in welchem physischen
Bereich der Datenbank (z.B. bei ORACLE der Tablespace) Ihre Tabelle auf der
Datenbank abgelegt wird. Mit der korrekten Wahl der Datenart wird die Tabelle
beim Aktivieren im ABAP Dictionary automatisch im richtigen Bereich auf der
Datenbank angelegt.
Die wichtigsten Datenarten sind Stammdaten, Bewegungsdaten,
Organisationsdaten und Systemdaten.
Stammdaten sind Daten, die nur selten geändert werden. Ein Beispiel für
Stammdaten sind die in einer Adressendatei enthaltenen Daten, wie z.B. Name,
Anschrift und Telefonnummer.

Bewegungsdaten sind Daten, die oft verändert werden. Ein Beispiel sind die in
einem Lager vorhandenen Warenbestände, die sich nach jeder Bestellung ändern.
Organisationsdaten sind Daten, die bei der Einstellung des Systems beim
Customizing angegeben werden und sich danach nur selten ändern. Ein Beispiel
sind die Länderschlüssel.
Systemdaten sind Daten, die das SAP-System selbst benötigt. Ein Beispiel sind
Programm-Sourcen.
Für den Kunden stehen weitere Datenarten, sog. Kundendatenarten (USER,
USER1), zur Verfügung. Diese sind für kundeneigene Entwicklungen vorgesehen.
Auf der Datenbank müssen dafür eigene Speicherbereiche allokiert werden.
Abbildung 24: Größenkategorie
Die Größenkategorie beschreibt den vermuteten Platzbedarf der Tabelle auf der
Datenbank.
Beim Anlegen der Tabelle auf der Datenbank wird für diese ein initialer
Speicherbereich (Initial Extent) reserviert. Des Größe des Initial Extens ist bei
allen Größenkategorien identisch. Benötigt die Tabelle später durch Erfassen
von Daten mehr Platz, so werden Speicherbereiche (Extents) hinzugefügt. Diese
hinzugefügten Speicherbereiche haben eine feste Größe, die durch die im ABAP
Dictionary bestimmte Größenkategorie festgelegt ist.
Sie können eine Größenkategorie zwischen 0 und 4 wählen. Jeder Kategorie
wird eine feste Extent-Größe zugeordnet, die vom verwendeten Datenbanksystem
abhängt.

Die korrekte Zuordnung einer Größenkategorie stellt sicher, daß nicht sehr
viele kleine Extents zu einer Tabelle entstehen. Weiterhin wird vermieden, daß
Speicherplatz durch Anlegen von zu großen Extents verschwendet wird.
Abbildung 25: Protokollierung
Sie können mit Hilfe der Protokollierung Änderungen an den Tabelleneinträgen

aufzeichnen und sichern.
Um die Protokollierung einzuschalten, muß das entsprechende Kennzeichen
in den technischen Einstellungen markiert werden. Die Protokollierung findet
allerdings nur statt, wenn das SAP-System mit einem Profile gestartet wurde, das
den Parameter´ rec/client́ enthält. Das Markieren des Flags im ABAP Dictionary
allein genügt nicht, um die Protokollierung anzustoßen.
Der Parameter „rec/client“ kann dabei verschiedene Einstellungen

besitzen:
rec/client = ALL Alle Mandanten sollen protokolliert werden.
rec/client = 000[...] Nur die angegebenen Mandanten sollen
protokoliert werden.
rec/client = OFF Protokollierung ist in diesem System
deaktiviert.

Die Protokollierung der Datenänderungen wird unabhängig von der Verbuchung

durchgeführt. Sie können die Protokolle über die Transaktion Tabellenhistorie
(SCU3) anzeigen.
Achtung: Durch die Protokollierung schaffen Sie sich einen

Flaschenhals im System:
• Zusätzliche Schreibzugriffe, um jede Tabellenmodifikation zu
protokollieren.
• Die Protokollierungstabelle ist eine Tabelle auf die viele Benutzer
parallel zugreifen wollen, dadurch entstehen Sperrsituationen,
obwohl die User auf verschiedene Anwendungstabellen zugreifen!
Zusammenfassung
• Alle betriebswirtschaftlichen Daten werden in Form von Tabellen verwaltet,
deren Definition im ABAP Dictionary abgelegt ist.
• Zur Tabellendefinition wird ein zweistufiges Domänenkonzept benutzt. Die
semantische Definition wird über Datenelemente und die technische über
Domänen realisiert.
• Die Felder von Include-Strukturen können in Tabellen inkludiert werden.
• Die technischen Einstellungen einer Tabelle bestimmen, wie die Tabelle auf
der Datenbank angelegt wird (Tablespace, Extentgröße) und ob Änderungen
an den Datensätzen protokolliert werden.

Übung 5: Tabellen im ABAP Dictionary

• Tabellen anlegen und das zweistufige Domänenkonzept verwenden
• Die technischen Einstellungen sinnvoll festlegen
• Felder dokumentieren
Die Tabellen des Flugmodells sollen in den Übungen um eine
Mitarbeiterverwaltung erweitert werden. Diese Mitarbeiterverwaltung soll es
den Fluggesellschaften ermöglichen, Daten über die bei ihnen beschäftigten
Mitarbeiter (zum Beispiel Name, Personalnummer, Gehalt, Abteilung) und über
organisatorische Zuordnungen (Abteilungen der Fluggesellschaften) zu erfassen
und auszuwerten.
Hierzu müssen in dieser Übung zwei Tabellen angelegt werden, die die Daten
der Mitarbeiter und der in den Fluggesellschaften vorhandenen Abteilungen
aufnehmen.
In Tabelle ZEMPLOY## werden die Daten zu den Mitarbeitern gepflegt. Neben
Namen und Adressen sind in Tablelle ZEMPLOY## auch die Gehälter der
Mitarbeiter hinterlegt. In Tabelle ZDEPMENT## sind die Abteilungen der
Fluggesellschaften hinterlegt. Jede Abteilung ist über eine Telefonummer und
Faxnummer erreichbar. Diese Tabellen werden in den folgenden Übungen dann
Schritt für Schritt erweitert.

Aufgabe 1:
Legen Sie die zwei transparenten Tabellen ZEMPLOY## und ZDEPMENT## an.
Bestimmen Sie deren Schlüsselfelder.
Notiz: Bevor Sie die Tabellen aktivieren können, müssen Sie noch die
technischen Einstellungen der Tabellen definieren. Die Vorgehensweise
wird in den letzten Aufgabenpunkten beschrieben. Die ersten
Aufgabenpunkte können auch ohne Aktivierung der Tabelle gelöst
werden.
Für drei Fluggesellschaften sind Daten gepflegt. Eine Fluggesellschaft
hat 20.000 Mitarbeiter und zwischen 10 und 30 Abteilungen. Die Daten
sind weder zu puffern noch zu protokollieren. Die Pufferung wird in der
Übung zum nächsten Kapitel überdacht.
1. Legen Sie Tabelle ZEMPLOY## an.

Über den Pfad Werkzeuge → ABAP Workbench → Entwicklung →
Dictionary gelangen Sie in das Übersichtsbild des ABAP Dictionary.
Tabelle ZEMPLOY##
Feld Datenelement Domäne Typ, Bedeutung
Länge
CLIENT S_MANDT MANDT Mandant
CARRIER S_CARR_ID S_CARR_ID Flugge-
sellschaft
EMP_NUM eigenes eigenes NUMC, Personal-
10 nummer
FIRST_NAME S_FNAME S_FNAME Vorname
LAST_NAME S_LNAME S_LNAME Nachname
DEPARTMENT eigenes eigenes CHAR, Abteilungskürzel
4
AREA eigenes eigenes CHAR, Bereich
1
SALARY eigenes eigenes CURR, Gehalt
10
Dez. 2
CURRENCY S_CURRCODE S_CURR Währung
2. Legen Sie Tabelle ZDEPMENT## an.


Tabelle ZDEPMENT##
Feld Datenele- Domäne Typ, Bedeutung
ment Länge
sellschaft
4
TELNR eigenes S_PHONE CHAR, Telefon
30
FAXNR eigenes S_PHONE CHAR, Faxnummer
30
3. Dokumentieren Sie die Felder Personalnummer und Abteilungskürzel.

4. Um die Tabelle aktivieren zu können, müssen Sie nun noch die technischen
Einstellungen und falls ein Betragsfeld in der Tabelle existiert ein
Währungsfeld zuordnen.

Aufgabe 2:
Stellen Sie sicher, daß für die Aufzeichnung der Änderungen in beiden Tabellen
stets die gleichen Felder zur Verfügung stehen, indem Sie diese Felder über eine
Unterstruktur ZCHANGE## in beide Tabellen einhängen.
Notiz: Änderungen an den Tabellen ZEMPLOY## und ZDEPMENT##

sind kritisch und müssen deshalb aufgezeichnet werden. Die
Pflegetransaktion muß also festhalten, wer einen Tabelleneintrag
zuletzt geändert hat. Dazu müssen Felder für die Personalnummer des
letzten Änderers und das Datum der letzten Änderung an die Tabellen
ZEMPLOY## und ZDEPMENT## angehängt werden.
In einer realen Anwendung würde die oben beschriebene Erweiterung
natürlich immer damit einhergehen, daß die Standardtabellenpflege für
die beiden Tabellen ausgeschaltet wird. Stattdessen würden eigene
Pflegetransaktionen für die Tabellen angelegt, in denen die Felder zur
Änderungsprotokollierung nicht direkt vom Benutzer sondern intern vom
Programm gefüllt werden.
Das Anlegen solcher Transaktionen geht aber über den Stoff dieses Kurses
hinaus. Daher nehmen wir im Rahmen dieses Kurses immer an, daß alle
Benutzer diese Felder in der Standardtabellenpflege selber (korrekt) füllen.
1. Legen Sie die Struktur ZCHANGE## an. Legen Sie für das Feld letzter
Änderer ein neues Datenelement an, verwenden Sie die Domäne welche Sie
für die Personalnummer angelegt haben. Benutzen Sie S_CHDATE als
Datenelement für das Datum der letzten Änderung.
2. Fügen Sie ZCHANGE## als Include in die Tabellen ZEMPLOY## und
ZDEPMENT##.
3. Finden Sie heraus, welche Aktionen auf der Datenbank durchgeführt wurden.
4. Starten Sie das Programm BC430_CHECK in der Transaktion SE38.
Notiz: Programm BC430_CHECK überprüft die Korrektheit Ihrer

Lösungen und füllt die neu angelegten Tabellen ZEMPLOY##
und ZDEPMENT## mit Beispieldaten, die für spätere Übungen
benötigt werden.

Lösung 5: Tabellen im ABAP Dictionary

Aufgabe 1:
Legen Sie die zwei transparenten Tabellen ZEMPLOY## und ZDEPMENT## an.
Bestimmen Sie deren Schlüsselfelder.
Notiz: Bevor Sie die Tabellen aktivieren können, müssen Sie noch die
technischen Einstellungen der Tabellen definieren. Die Vorgehensweise
wird in den letzten Aufgabenpunkten beschrieben. Die ersten
Aufgabenpunkte können auch ohne Aktivierung der Tabelle gelöst
werden.
Für drei Fluggesellschaften sind Daten gepflegt. Eine Fluggesellschaft
hat 20.000 Mitarbeiter und zwischen 10 und 30 Abteilungen. Die Daten
sind weder zu puffern noch zu protokollieren. Die Pufferung wird in der
Übung zum nächsten Kapitel überdacht.
1. Legen Sie Tabelle ZEMPLOY## an.

Tabelle ZEMPLOY##
Feld Datenelement Domäne Typ, Bedeutung
Länge
sellschaft
EMP_NUM eigenes eigenes NUMC, Personal-
10 nummer
FIRST_NAME S_FNAME S_FNAME Vorname
LAST_NAME S_LNAME S_LNAME Nachname
4
AREA eigenes eigenes CHAR, Bereich
1
SALARY eigenes eigenes CURR, Gehalt
10
Dez. 2
CURRENCY S_CURRCODE S_CURR Währung

a) Markieren Sie Datenbanktabelle, und geben Sie den Tabellennamen

ZEMPLOY## im entsprechenden Eingabefeld an. Wählen Sie Anlegen.
Erfassen Sie im Pflegebild der Tabelle eine Kurzbeschreibung.
b) Wählen Sie die Auslieferungsklasse A, und markieren Sie
Tabellenpflege erlaubt.
c) Wählen Sie die Registerkarte Felder, um in die Pflege der
Felddefinitionen zu springen. Geben Sie die Feldnamen (müssen nicht
im Kundennamensraum liegen) an.
d) Für die Felder Mandant, Fluggesellschaft, Vorname, Nachname und
Währung benutzen Sie die vorgegebenen Datenelemente, indem
Sie die Namen der Datenelemente in die Spalte Feldtyp eintragen.
Anschließend sichern Sie Ihre Eingaben.
e) Für die Felder Personalnummer, Abteilungskürzel, Bereich und Gehalt
sollen Sie eigene Datenelemente anlegen. Geben Sie in der Spalte
Feldtyp einen Namen (Z<objekt>##) für das Datenelement an.
Markieren Sie den Namen des Datenelements. Sie gelangen zur
Datenelementdefinition.
f) Vergeben Sie eine Kurzbeschreibung (Bestandteil der F1-Hilfe).
Wählen Sie die Registerkarte Feldbezeichner und hinterlegen Sie dort
die Texte für die Feldbezeichner.
g) Weiterhin müssen Sie dem Datenelement eine technische Beschreibung
(Domäne) zuordnen. Wählen Sie die Registerkarte Definition und
tragen Sie dort einen Namen (Z<objekt>##) für Ihre Domäne ein.
Falls die Domäne vorgegeben ist, aktivieren Sie das Datenelement und
kehren Sie (mit F3) zum Pflegebildschirm der Tabellenfelder zurück.
Ansonsten markieren Sie den Domänennamen. Sie gelangen dann
zur Domänendefinition.
h) Dort legen Sie die Kurzbeschreibung, den Datentyp (NUMC, CHAR,
oder CURR) und die Feldlänge fest. Aktivieren Sie die Domäne.
i) Gehen Sie ein Bild zurück (mit F3) zur Datenelementdefinition und
aktivieren Sie Ihr Datenelement.
j) Navigieren Sie nochmals ein Bild zurück zur Felddefinition. Beginnen
Sie wieder bei e), bis alle Felder der Tabelle definiert sind. Sichern Sie
anschließend Ihre Tabelle.
k) Für das Feld Gehalt müssen Sie die Referenztabelle und das
Referenzfeld festlegen. Markieren Sie den Feldnamen und tragen Sie
im folgenden Dialogfenster ein:

Feld Wert
Referenztabelle ZEMPLOY##
Referenzfeld Währung
l) Definieren Sie die Schlüsselfelder für Tabelle ZEMPLOY##, indem Sie

hinter den Feldnamen die Spalte Key ankreuzen. Die Felder Mandant,
Fluggesellschaft, und Personalnummer identifizieren einen Eintrag
eindeutig. Sie müssen deshalb als Schlüsselfelder gekennzeichnet
werden.
Notiz: Die Schlüsselfelder Mandant, Fluggesellschaft, und
Personalnummermüssen in dieser Reihenfolge am Anfang
der Feldliste stehen.
m) Aktivieren Sie Ihre Tabelle ZEMPLOY##. Dadurch gelangen sie

automatisch in das Pflegebild für die technischen Einstellungen.
Notiz: Da sich die Inhalte der Tabelle ZEMPLOY## selten
ändern, muß als Datenart APPLO (Stammdaten) gewählt
werden. Die erwartete Anzahl von Sätzen in Tabelle
ZEMPLOY## ist 60.000, daher müssen Sie Größenkategorie 2
wählen. Die Tabelle sollte weder gepuffert noch protokolliert
sein.
Tabelle ZEMPLOY##
Datenart APPL0 (Stammdaten)
Größenkategorie 2
Pufferung nicht erlaubt
Protokollierung keine Protokollierung
Sichern Sie die technischen Einstellungen. Kehren Sie dann in die

Pflege der Tabelle zurück (F3). Die Tabelle wird aktiviert.
2. Legen Sie Tabelle ZDEPMENT## an.

Tabelle ZDEPMENT##
Feld Datenele- Domäne Typ, Bedeutung
ment Länge
sellschaft
4
TELNR eigenes S_PHONE CHAR, Telefon
30
FAXNR eigenes S_PHONE CHAR, Faxnummer
30
a) Markieren Sie Datenbanktabelle, und geben Sie den Tabellennamen

ZDEPMENT## im entsprechenden Eingabefeld an. Wählen Sie
Anlegen. Erfassen Sie im Pflegebild der Tabelle eine Kurzbeschreibung.
b) Wählen Sie die Auslieferungsklasse A, und markieren Sie
Tabellenpflege erlaubt.
c) Wählen Sie die Registerkarte Felder, um in die Pflege der
Felddefinitionen zu springen. Geben Sie die Feldnamen (müssen nicht
im Kundennamensraum liegen) an.
d) Für die Felder Mandant und Fluggesellschaft benutzen Sie die
vorgegebenen Datenelemente, indem Sie die Namen der Datenelemente
in die Spalte Feldtyp eintragen. Anschließend sichern Sie Ihre
Eingaben.
e) Für die Felder Abteilungskürzel, Telefonnummer, und Faxnummer
sollen Sie eigene Datenelemente anlegen. Geben Sie in der Spalte
Feldtyp einen Namen (Z<objekt>##) für das Datenelement an.
Markieren Sie den Namen des Datenelements. Sie gelangen zur
Datenelementdefinition.
f) Vergeben Sie eine Kurzbeschreibung (Bestandteil der F1-Hilfe).
Wählen Sie die Registerkarte Feldbezeichner und hinterlegen Sie dort
die Texte für die Feldbezeichner.

g) Weiterhin müssen Sie dem Datenelement eine technische Beschreibung

(Domäne) zuordnen. Wählen Sie die Registerkarte Definition und
tragen Sie dort einen Namen (Z<objekt>##) für Ihre Domäne ein.
Ansonsten markieren Sie den Domänennamen. Sie gelangen dann
zur Domänendefinition.
Notiz: Falls die Domäne vorgegeben ist, aktivieren Sie das
Datenelement und kehren Sie (mit F3) zum Pflegebildschirm
der Tabellenfelder zurück.
h) Dort legen Sie die Kurzbeschreibung, den Datentyp (CHAR) und die
Feldlänge (30) fest. Aktivieren Sie die Domäne.
i) Gehen Sie ein Bild zurück (mit F3) zur Datenelementdefinition und
aktivieren Sie Ihr Datenelement.
j) Sichern Sie Ihre Tabelle.
k) Definieren Sie die Schlüsselfelder für Tabelle ZDEPMENT##, indem
Sie hinter den Feldnamen die Spalte Key ankreuzen. Die Felder
Mandant, Fluggesellschaft, und Abteilungskürzel identifizieren
einen Eintrag eindeutig. Sie müssen deshalb als Schlüsselfelder
gekennzeichnet werden.
l) Aktivieren Sie Ihre Tabelle, und legen Sie die technischen Einstellungen
fest:
Da sich die Inhalte der Tabelle ZDEPMENT## selten ändern, muß als
Datenart APPL0 (Stammdaten) gewählt werden. Die erwartete Anzahl
von Sätzen in Tabelle ZDEPMENT## ist mit maximal 90 definiert,
daher müssen Sie Größenkategorie 0 wählen. Die Tabelle sollte weder
gepuffert noch protokolliert sein.
Tabelle ZDEPMENT##
Feld Wert
Datenart APPL0 (Stammdaten)
Größenkategorie 0
Pufferung nicht erlaubt
Protokollierung keine Protokollierung

3. Dokumentieren Sie die Felder Personalnummer und Abteilungskürzel.

a) Doppelklicken Sie das Datenelement, um auf dessen
Datenelementdefinition zu gelangen. Wechseln Sie mit Anzeigen
<=> Ändern in den Änderungsmodus. Wählen Sie Springen →
Dokumentation.
b) Geben Sie den Feldern einen Text mit, und sichern Sie anschließend
Ihre Eingaben.
4. Um die Tabelle aktivieren zu können, müssen Sie nun noch die technischen
Einstellungen und falls ein Betragsfeld in der Tabelle existiert ein
Währungsfeld zuordnen.
a) Klicken Sie auf die Schaltfläche Technische Einstellungen
b) Wählen Sie nun die passende Datenart und die Größenkategorie .
c) Sichern Sie Ihre Änderungen und kehren Sie zurück zur Feldansicht
der Tabelle
d) Für Betragsfelder (z.B. SALERY) müssen noch Währungsfelder
zugeordnet werden. Dafür wechseln Sie auf den Tabreiter Währungs-/
Mengenfelder.
e) Im Feld Referenztabelle tragen Sie den Namen der aktuellen Tabelle
ein.
f) Im Feld Referencfeld tragen sie den Namen des Feldes ein, den Sie für
die Währung verwendet haben.

Aufgabe 2:
Stellen Sie sicher, daß für die Aufzeichnung der Änderungen in beiden Tabellen
stets die gleichen Felder zur Verfügung stehen, indem Sie diese Felder über eine
Unterstruktur ZCHANGE## in beide Tabellen einhängen.
Notiz: Änderungen an den Tabellen ZEMPLOY## und ZDEPMENT##

sind kritisch und müssen deshalb aufgezeichnet werden. Die
Pflegetransaktion muß also festhalten, wer einen Tabelleneintrag
zuletzt geändert hat. Dazu müssen Felder für die Personalnummer des
letzten Änderers und das Datum der letzten Änderung an die Tabellen
ZEMPLOY## und ZDEPMENT## angehängt werden.
In einer realen Anwendung würde die oben beschriebene Erweiterung
natürlich immer damit einhergehen, daß die Standardtabellenpflege für
die beiden Tabellen ausgeschaltet wird. Stattdessen würden eigene
Pflegetransaktionen für die Tabellen angelegt, in denen die Felder zur
Änderungsprotokollierung nicht direkt vom Benutzer sondern intern vom
Programm gefüllt werden.
Das Anlegen solcher Transaktionen geht aber über den Stoff dieses Kurses
hinaus. Daher nehmen wir im Rahmen dieses Kurses immer an, daß alle
Benutzer diese Felder in der Standardtabellenpflege selber (korrekt) füllen.
1. Legen Sie die Struktur ZCHANGE## an. Legen Sie für das Feld letzter
Änderer ein neues Datenelement an, verwenden Sie die Domäne welche Sie
für die Personalnummer angelegt haben. Benutzen Sie S_CHDATE als
Datenelement für das Datum der letzten Änderung.
a) Markieren Sie im Einstiegsbild des ABAP Dictionary Datentyp und
geben Sie ZCHANGE## in das entsprechende Feld ein. Wählen Sie
Anlegen.
b) Markieren Sie Struktur im folgenden Dialogfenster.
c) Geben Sie in der Spalte Komponente die Feldnamen und in der Spalte
Komponententyp die zugehörigen Datenelemente an. Legen Sie Ihr
eigenes Datenelement für das erste Feld an. Verwenden Sie die
Domäne, die Sie für die Personalnummer in Tabelle ZEMPLOY##
angelegt haben.
d) Legen Sie ein Feld für die Personalnummer und eins für das
Änderungsdatum an. Für das zweite Feld benutzen Sie das
Datenelement S_CHDATE.
e) Aktivieren Sie die Struktur ZCHANGE##.

2. Fügen Sie ZCHANGE## als Include in die Tabellen ZEMPLOY## und

ZDEPMENT##.
a) Verzweigen Sie in die Pflege der Tabelle ZEMPLOY##.
b) Wählen Sie Neue Zeilen, und stellen Sie den Cursor auf das erste
neue Feld.
c) Wählen Sie Bearbeiten → Include → Einfügen.
d) Geben Sie im folgenden Dialogfenster den Namen ZCHANGE## ein
und wählen Sie Weiter.
e) Aktivieren Sie Ihre Tabelle ZEMPLOY##. Machen Sie die gleichen
Einträge, um die Unterstruktur ZCHANGE## in die Tabelle
ZDEPMENT## aufzunehmen.
3. Finden Sie heraus, welche Aktionen auf der Datenbank durchgeführt wurden.
a) Über Hilfsmittel → Aktivierungprotokoll können Sie sich anzeigen
lassen, welche Aktionen auf der Datenbank durchgeführt wurden.
Notiz: Programm BC430_CHECK überprüft die Korrektheit Ihrer

Lösungen und füllt die neu angelegten Tabellen ZEMPLOY##
und ZDEPMENT## mit Beispieldaten, die für spätere Übungen
benötigt werden.
a) Starten Sie die Transaktion SE38 über das Eingabefeld ein. Starten
Sie Programm BC430_CHECK.


Nun können Sie

Lektion: Besondere SAP-Tabellen

Sie lernen Pool- und Clustertabellen kennen

Bei Performanceuntersuchungen einiger Anwendungen sind Sie auf
Select-Anweisungen gestossen, die auf der der Datenbank scheinbar auf andere
Tabellen zugreifen, als im entsprechenden ABAP-Coding angewiesen.
Pool- und Clustertabellen
Abbildung 26: Überblick der DB-Tabellentypen

BC430 Lektion: Besondere SAP-Tabellen
Neben transparenten Tabellen, bei denen die Definition im ABAP Dictionary

und die auf der Datenbank identisch sind, gibt es im R/3 System Pool- und
Clustertabellen.
Pool- und Clustertabellen zeichnen sich dadurch aus, daß mehrere logisch im
ABAP Dictionary definierte Tabellen in einer physikalischen Datenbanktabelle
(Tabellenpool bzw. -Cluster) zusammengefaßt werden.
Abbildung 27: Clustertabellen
Die Idee von Clustertabellen ist, daß man über verschiedene Tabellen verteilte,
funktional abhängige Daten zusammen in einer Datenbanktabelle ablegt.
Entsprechend bildet die Schnittmenge der Schlüsselfelder der Clustertabellen den
Schlüssel des Tabellenclusters (Clusterschlüssel).
Die von einem Clusterschlüssel abhängigen Daten werden im VARDATA-Feld
des Tabellencluster abgelegt. Reicht das VARDATA-Feld nicht aus, um alle
abhängigen Daten aufzunehmen, wird von der Datenbankschnittstelle ein
Überlaufsatz angelegt. Über das Feld PAGNO wird die Eindeutigkeit innerhalb
des Tabellenclusters gewährleistet.
Der Inhalt des VARDATA-Feldes wird von der Datenbankschnittstelle
komprimiert. Entsprechend beinhaltet das VARDATA-Feld eine Beschreibung
zur Dekomprimierung seiner Daten. Die Felder TIMESTAMP und PAGELG
beinhalten administrative Informationen.

Abbildung 28: Pooltabellen
Die Grundidee eines Tabellenpools ist im Unterschied zu Tabellenclustern

die Ablage von Datensätze aus im ABAP Dictionary definierten Tabellen, die
nicht voneinander abhängig sind. Man möchte kleine R/3 Tabellen zu einer
Datenbanktabelle zusammenfassen.
In obigem Beispiel erkennt man, daß die Schnittmenge der Schlüsselfelder von
TABA und TABB leer ist. Trotzdem werden die Datensätze aus TABA und TABB
in den Tabellenpool TABAB abgelegt werden.
Der Schlüssel für einen Datensatz des Tabellenpools TABAB besteht aus den
beiden Feldern TABNAME und VARKEY. Das Feld TABNAME nimmt dabei den
Namen der Pooltabelle auf. Das Feld VARKEY besteht aus der Konkatenation
der Schlüsselfelder der Pooltabelle. Daraus ergibt sich die Notwendigkeit, daß die
Schlüsselfelder einer Pooltabelle vom Typ C sein müssen.
In dem VARDATA-Feld werden die Nichtschlüsselfelder der Pooltabellen durch
die Datenbankschnittstelle in komprimierter Form unstrukturiert abgelegt. Das
Feld DATALN beinhaltet die Länge des VARDATA-Feldes.

BC430 Lektion: Besondere SAP-Tabellen
Abbildung 29: Vor- und Nachteile von Pool- bzw. Clustertabellen
Der entscheidende Vorteil von Pool- und Clustertabellen liegt darin, daß die Daten
komprimiert auf der Datenbank abgelegt werden. Dadurch reduziert sich der
benötigte Speicherplatz und die Netzwerklast.
Die Zusammenfassung von Tabellen zu Tabellenpools oder Tabellenclustern führt
zu weniger Tabellen, die Komprimierung zu weniger Feldern auf der Datenbank.
In der Folge werden weniger unterschiedliche SQL-Anweisungen ausgeführt.
Pool- und Clustertabellen werden nicht als separate Tabellen auf der Datenbank
angelegt. Insofern vereinfacht sich die Administration. Bei Clustertabellen werden
funktional abhängige Daten zusammen gelesen, was weniger Datenbankzugriffe
zur Folge hat.
Der entscheidende Nachteil liegt in der eingeschränkten Datenbankfunktionalität.
Es ist nicht möglich, für Nichtschlüsselfelder einen Index anzulegen. Es gibt
entweder Primärindizes oder Indizes auf eine Teilmenge der Schlüsselfelder. Die
Verwendung von Datenbankviews oder ABAP JOIN‘s ist genauso ausgeschlossen,
wie Table Appends. Auf die Daten in Pool- oder Clustertabellen kann
ausschließlich über OPEN SQL zugegriffen werden (kein Native SQL).
Für Pooltabellen werden nur die WHERE-Bedingungen für Schlüsselfelder, für
Clustertabellen nur die WHERE-Bedingungen für die Felder des Clusterschlüssels
(Untermenge der Schlüsselfelder) an die Datenbank übertragen. ORDER BY -
oder GROUP BY - Klauseln für Nichtschlüsselfelder werden nicht übertragen.
Für Pooltabellen braucht man längere Schlüssel als semantisch notwendig.


Nun können Sie

BC430 Zusammenfassung des Kapitels

Nun können Sie


Kapitel 3
Performance beim Tabellenzugriff

In diesem Kapitel werden Sie grundlegende Aspekte des performanten
Tabellenzugriffs kennen lernen.

• beurteilen, in welchen Fällen Sie Tabellenzugriffe durch Indizes

beschleunigen können
• Indizes im ABAP Dictionary anlegen
• die verschiedenen Pufferungsarten unterscheiden
• beurteilen, wann die Pufferung einer Tabelle sinnvoll ist und welche
Pufferungsart Sie wählen müssen
• die Pufferung einer Tabelle über die technischen Einstellungen vornehmen
Inhalt des Kapitels

Lektion: Performance beim Tabellenzugriff................................... 78
Übung 6: Performanceaspekte beim Tabellenzugriff ................... 93

Kapitel 3: Performance beim Tabellenzugriff BC430
Lektion: Performance beim Tabellenzugriff

Einige Transaktionen in Ihren Anwendungen beinhalten Select-Anweisungen,
die sehr lange Laufzeiten verursachen. Sie sollten nun ohne die Programme zu
verändern, die Performance verbessern.
Verbesserte Performance durch Zugriff per Index
Abbildung 30: Struktur eines Index

BC430 Lektion: Performance beim Tabellenzugriff
Über einen Index kann die Selektion von Datensätzen aus einer Tabelle
beschleunigt werden.
Ein Index kann als eine auf bestimmte Felder reduzierte Kopie einer
Datenbanktabelle aufgefaßt werden. Die Daten liegen in dieser Kopie in sortierter
Form vor. Diese Sortierung ermöglicht einen schnellen Zugriff auf die Sätze der
Tabelle (z.B. über binäre Suche). Im Index sind nicht alle Felder der Tabelle
enthalten. Damit alle Feldinhalte gelesen werden können, ist in einem Index noch
ein Zeiger vom Indexeintrag auf den zugehörigen Tabelleneintrag enthalten.
• Beachten Sie beim Anlegen von Indizes bitte folgende Punkte:
– Ein Index ist bei der Selektion nur bis zum letzten spezifizierten Feld
von Nutzen! An erster Stelle sollten die Felder stehen, die bei vielen
Selektionen in der WHERE-Klausel spezifiziert werden.
– In einem Index sind nur solche Felder sinnvoll, deren Werte die
Datenmenge stark einschränken.
– Beim Ändern eines Datensatzes aus einer Tabelle muß die Sortierung
im Index angepaßt werden. Tabellen, deren Inhalte oft verändert
werden, sollten nicht zu viele Indizes besitzen.
– Achten Sie darauf, daß die Indizes zu einer Tabelle möglichst disjunkt
sind.
Abbildung 31: Zugriff über Indizes
Welcher Index zur Tabelle von der Datenbank für den Zugriff auf Datensätze
verwendet wird, wird vom Optimizer der Datenbank entschieden.

Man unterscheidet zwischen dem Primärindex und den Sekundärindizes einer

Tabelle. Der Primärindex besteht aus den Schlüsselfeldern der Tabelle. Der
Primärindex wird automatisch beim Aktivieren der Tabelle auf der Datenbank
mitangelegt. Falls auf eine große Tabelle häufig auf eine Art zugegriffen wird, bei
der die Sortierung des Primärindex für den Zugriff nicht ausgenutzt werden kann,
sollten Sekundärindizes zur Tabelle angelegt werden.
Indizes einer Tabelle haben eine dreistellige Index-ID. 0 ist für den Primärindex
reserviert. Kunden können zu SAP-Tabellen eigene Indizes anlegen, deren
Kennung mit Y oder Z beginnen muß.
Falls die Indexfelder Schlüsselfunktion besitzen, d.h. jeden Satz der Tabelle
bereits eindeutig identifizieren, kann ein Index als Unique-Index gekennzeichnet
werden. Damit wird von Seiten der DB sichergestellt, daß bzgl. der Indexfelder
keine Duplikate entstehen.
Bei der Definition eines Sekundärindex im ABAP Dictionary kann angegeben
werden, ob dieser beim Aktivieren auf der Datenbank angelegt werden soll. Es
kann auch Indizes geben, die nur auf bestimmten Datenbanksystemen einen
Performancegewinn bringen. Deshalb kann bei der Definition eines Index eine
Liste von Datenbanksystemen spezifiziert werden. Der Index wird dann beim
Aktivieren nur auf den angegebenen Datenbanksystemen angelegt.

Verbesserung der Performance durch Tabellenpuffer-

ung
Abbildung 32: Zugriff auf Daten über den Puffer
Die Pufferung einer Tabelle erhöht die Performance beim lesenden Zugriff auf
die Sätze der Tabelle.
Die Sätze einer gepufferten Tabelle werden beim Zugriff auf die Tabelle direkt
aus dem lokalen Puffer des Applikationsservers gelesen, auf dem die zugreifende
Transaktion läuft. Zeitaufwendige Datenbankzugriffe entfallen damit. Der Zugriff
wird um den Faktor 10 bis 100 besser. Die Erhöhung der Geschwindigkeit hängt
von der Struktur der Tabelle und der genauen Systemkonfiguration ab. Die
Pufferung kann also die Performance des Systems erheblich steigern.
Wenn durch Einlagern neuer Daten Platzbedarf im Puffer entsteht, werden
diejenigen Daten verdrängt, auf die am längsten nicht zugegriffen wurde. Die
Verdrängung findet asynchron zu bestimmten Zeitpunkten statt, die dynamisch
anhand der Zugriffe auf den Puffer bestimmt werden. Verdrängung findet nur statt,
wenn zu diesem Zeitpunkt der freie Platz im Puffer einen voreingestellten Wert
unterschreitet oder die Zugriffsqualität zu schlecht ist.
Über die Eingabe von /$TAB im Kommandofeld können die Tabellenpuffer auf
dem entsprechenden Applikationsserver zurückgesetzt werden. Verwenden Sie
dieses Kommando nur, wenn Inkonsistenzen im Puffer entstanden sind. Das
Füllen der Puffer kann in großen Systemen mehrere Stunden dauern. Während
dieser Zeit ist die Performance erheblich beeinträchtigt.

Die Pufferungsart bestimmt, welche Sätze der Tabelle beim Zugriff auf einen
Satz der Tabelle in den Puffer des Applikationsservers geladen werden. Man
unterscheidet die folgenden Pufferungsarten:
• Vollständige Pufferung: Sobald auf einen Satz der Tabelle zugegriffen
wird, werden alle Sätze der Tabelle in den Puffer geladen.
• Generische Pufferung: Beim Zugriff auf einen Satz der Tabelle werden alle
Sätze in den Puffer geladen, deren linksbündiger Teil des Schlüssels mit
diesem Satz übereinstimmt.
• Pufferung von Einzelsätzen: Nur der Satz wird in den Puffer geladen,
auf den zugegriffen wurde.
Abbildung 33: Vollständige Pufferung
Bei vollständiger Pufferung befindet sich die Tabelle entweder ganz oder gar
nicht im Puffer. Beim Zugriff auf einen Satz der Tabelle werden alle Sätze der
Tabelle in den Puffer geladen.
Bei der Entscheidung, ob eine Tabelle vollständig gepuffert werden soll, müssen
die Tabellengröße, die Anzahl der lesenden Zugriffe und die Zahl der schreibenden
Zugriffe auf die Tabelle berücksichtigt werden. Je kleiner die Tabelle ist, je
häufiger sie gelesen und je seltener in sie geschrieben wird, um so günstiger ist
es, die Tabelle vollständig zu puffern.

Auch für Tabellen, auf die häufig Zugriffe auf nicht vorhandene Sätze abgesetzt
werden, ist vollständige Pufferung günstig. Da sich alle Sätze der Tabelle im
Puffer befinden, kann direkt im Puffer entschieden werden, ob ein Satz vorhanden
ist oder nicht.
Die Datensätze sind im Puffer entsprechend dem Tabellenschlüssel sortiert.
Bei Zugriffen über SELECT können nur Felder bis zum letzten spezifizierten
Schlüsselfeld für den Zugriff verwendet werden. Bei solchen Zugriffen sollte also
ein möglichst großer linksbündiger Teil des Schlüssels verwendet werden. Ist
beispielsweise das erste Schlüsselfeld nicht versorgt, so erfolgt ein Full-Table-Scan
im Puffer. Unter diesen Umständen kann ein direkter Zugriff auf die Datenbank
effizienter sein, falls dort ein geeigneter Sekundärindex vorhanden ist.
Abbildung 34: Generische Pufferung
Bei generischer Pufferung werden beim Zugriff auf einen Satz der Tabelle alle
mit diesem Satz in den generischen Schlüsselfeldern übereinstimmenden Sätze
in den Puffer geladen. Der generische Schlüssel ist ein linksbündiger Teil des
Primärschlüssels der Tabelle, der bei der Wahl der Pufferungsart festgelegt werden
muß. Der generische Schlüssel sollte so gewählt werden, daß die generischen
Bereiche nicht zu klein werden und damit nicht zu viele generische Bereiche
entstehen. Gibt es pro generischem Bereich nur einige wenige Sätze, so ist es in der
Regel günstiger, die Tabelle vollständig zu puffern. Wird der generische Schlüssel
zu groß gewählt, so werden bei Änderungen an den Einträgen der Tabelle zu viele
Daten invalidiert, was sich ebenfalls negativ auf die Performance auswirken kann.

Eine Tabelle sollte generisch gepuffert werden, wenn für die Verarbeitung in der
Regel nur bestimmte generische Bereiche der Tabelle benötigt werden.
Mandantenabhängige, vollständig gepufferte Tabellen werden automatisch
generisch gepuffert. Das Mandantenfeld ist der generische Schlüssel. Es wird
davon ausgegangen, daß auf einem Applikationsserver nicht auf allen Mandanten
gleichzeitig gearbeitet wird. Sprachabhängige Tabellen sind ein weiteres Beispiel
für den sinnvollen Einsatz generischer Pufferung. Der generische Schlüssel
umfaßt alle Schlüsselfelder bis einschließlich des Sprachfeldes.
Die generischen Bereiche werden im Puffer als eigenständige Objekte verwaltet.
Die Verwaltung der generischen Bereiche ist dabei völlig analog zur Verwaltung
vollständig gepufferter Tabellen. Beachten Sie deshalb auch die zur vollständigen
Pufferung gegebenen Hinweise.
Abbildung 35: Pufferung von Einzelsätzen
Es werden nur die Sätze in den Puffer geladen, auf die tatsächlich zugegriffen
wird. Pufferung von Einzelsätzen spart dadurch gegenüber generischer bzw.
vollständiger Pufferung Speicherplatz im Puffer ein. Der Verwaltungsaufwand
im Puffer ist allerdings höher als bei generischer oder vollständiger Pufferung.
Es sind weiterhin zum Laden der Sätze wesentlich mehr Datenbankzugriffe
erforderlich als bei den anderen Pufferungsarten.
Pufferung von Einzelsätzen ist insbesondere bei großen Tabellen empfehlenswert,
für die nur auf wenige Sätze wiederholt durch SELECT SINGLE zugegriffen
wird. Alle Zugriffe auf die Tabelle, die nicht über SELECT SINGLE abgesetzt
werden, gehen am Puffer vorbei direkt auf die Datenbank.

Wird mit SELECT SINGLE auf einen noch nicht gepufferten Satz zugegriffen,
erfolgt ein Datenbankzugriff, um den Satz zu laden. Enthält die Tabelle keinen
Satz zum angegebenen Schlüssel, so wird dieser Satz im Puffer als nicht existent
vermerkt. Bei einem späteren Zugriff mit demselben Schlüssel kann damit ein
erneuter Datenbankzugriff vermieden werden.
Zum Laden einer Tabelle ist bei vollständiger Pufferung nur ein Datenbankzugriff
erforderlich, während bei Pufferung von Einzelsätzen viele Datenbankzugriffe
notwendig sind. Deshalb ist bei kleinen Tabellen, auf die oft zugegriffen wird,
vollständige Pufferung in der Regel günstiger.
Abbildung 36: Pufferung von Tabellen
Die Verwaltung und Synchronisation der Puffer auf den einzelnen

Applikationsservern wird vom R/3-System durchgeführt. Greift ein
Applikationsprogramm auf Daten einer Tabelle zu, so wird über die
Datenbank-Schnittstelle ermittelt, ob sich diese Daten im Puffer des
Applikationsservers befinden. Ist dies der Fall, so werden die Daten direkt aus
dem Puffer gelesen. Sind die Daten nicht im Puffer des Applikationsservers
enthalten, so werden die Daten direkt von der Datenbank gelesen und dabei in den
Puffer geladen. Der nächste Zugriff auf diese Daten kann damit aus dem Puffer
befriedigt werden.

Abbildung 37: Synchronisation von Puffern 1
Da die Puffer lokal auf den Applikationsservern liegen, ist es nötig, diese nach
Änderungen an den Daten einer gepufferten Tabelle zu synchronisieren. Diese
Synchronisation erfolgt in festen Zeitintervallen, deren Dauer im System-Profile
eingestellt werden kann. Der entsprechende Parameter heißt „rdisp/bufreftime“
und gibt die Länge des Intervalls in Sekunden an. Der Wert muss zwischen 60 und
3600 liegen. Wir empfehlen einen Wert zwischen 60 und 240.
Das folgende Beispiel zeigt, wie die lokalen Puffer des Systems synchronisiert
werden. Wir gehen von einem System mit zwei Applikationsservern aus.
Ausgangssituation: Beide Server haben bisher noch nicht auf Sätze der
vollständig zu puffernden Tabelle SCARR zugegriffen. Die Tabelle ist deshalb
noch nicht in den lokalen Puffern der beiden Server enthalten.
• Zeitpunkt 1: Ein Anwender auf Server 1 liest Sätze aus der Tabelle SCARR
auf der Datenbank.
• Zeitpunkt 2: Die Tabelle SCARR wird vollständig in den lokalen Puffer
von Server 1 geladen. Für Zugriffe von Server 1 auf die Daten der Tabelle
SCARR wird nun der lokale Puffer dieses Servers verwendet.

• Zeitpunkt 3: Ein Anwender auf Server 2 greift auf Sätze der Tabelle zu. Da
sich die Tabelle noch nicht im lokalen Puffer von Server 2 befindet, werden
die Sätze direkt von der Datenbank gelesen.
• Zeitpunkt 4: Die Tabelle SCARR wird in den lokalen Puffer von Server
2 geladen. Server 2 verwendet daher auch seinen lokalen Puffer, um beim
nächsten Lesen von Tabelle SCARR auf deren Daten zuzugreifen.

• Zeitpunkt 5: Ein Anwender auf Server 1 löscht Sätze aus der Tabelle
SCARR und aktualisiert die Datenbank.
• Zeitpunkt 6: Server 1 schreibt einen Eintrag in die Synchronisationstabelle.
• Zeitpunkt 7: Server 1 aktualisiert seinen lokalen Puffer.

• Zeitpunkt 8: Ein Anwender auf Server 2 greift auf die gelöschten

Datensätze zu. Da sich die Tabelle SCARR in seinem lokalen Puffer
befindet, erfolgt der Zugriff über diesen lokalen Puffer.
– Server 2 findet also die Sätze, obwohl diese in der Datenbanktabelle
nicht mehr vorhanden sind.
– Würde der gleiche Zugriff von einem Anwendungsprogramm auf
Server 1 ausgeführt, so würde dieses Programm erkennen, daß die
Sätze nicht mehr vorhanden sind. Zu diesem Zeitpunkt hängt das
Verhalten eines Anwendungsprogramms also davon ab, auf welchem
Server es läuft.

• Zeitpunkt 9: Der Synchronisationszeitpunkt ist erreicht. Beide Server sehen

in der Synchronistionstabelle nach, ob eine der Tabellen in ihrem lokalen
Puffer inzwischen von einem anderen Server verändert wurde.
• Zeitpunkt 10: Server 2 stellt fest, daß die Tabelle SCARR in der
Zwischenzeit von Server 1 verändert wurde. Server 2 invalidiert deshalb die
Tabelle in seinem lokalen Puffer. Der nächste Zugriff von Server 2 auf Daten
der Tabelle SCARR geht deshalb über die Datenbank. Server 1 muß die
Tabelle in seinem Puffer nicht invalidieren, da er selbst der einzige Änderer
der Tabelle SCARR ist. Server 1 greift also beim nächsten Zugriff auf Sätze
der Tabelle SCARR erneut über seinen lokalen Puffer zu.

• Zeitpunkt 11: Server 2 greift erneut auf Sätze der Tabelle SCARR zu. Da
SCARR im lokalen Puffer von Server 2 invalidiert ist, erfolgt der Zugriff
über die Datenbank.
• Zeitpunkt 12: Die Tabelle wird erneut un den lokalen Puffer von Server 2
geladen. Die Informationen über Tabelle SCARR sind nun wieder konsistent
auf den Servern und der Datenbank.
Vor- und Nachteile dieses Verfahrens zur Puffersynchronisation:
• Vorteil: Die Netzlast wird gering gehalten. Würden die Puffer sofort nach
jeder Änderung synchronisiert, müßte jeder Server jede Änderung an einer
gepufferten Tabelle allen anderen Servern über das Netz mitteilen. Dies
würde sich negativ auf die Performance auswirken.
• Nachteil: Die lokalen Puffer der Applikationsserver können zwischen den
Synchronisationszeitpunkten veraltete Daten enthalten.
Daraus folgt:
• Es dürfen nur solche Tabellen gepuffert werden, auf die sehr selten
schreibend zugegriffen wird (read mostly) oder für die solche temporären
Inkonsistenzen keine Bedeutung haben.
• Tabellen, deren Einträge sich oft verändern, sollten nicht gepuffert werden.
Sonst findet ein ständiges Invalidieren und Neuladen statt, was sich negativ
auf die Performance auswirkt.

Ein Index ist ein Hilfsmittel, um lesende Zugriffe auf eine Tabelle zu
beschleunigen. Ein Index kann als eine sortierte, auf die Indexfelder reduzierte
Kopie der Tabelle aufgefaßt werden.
Die Tabellenpuffer befinden sich lokal auf den Applikationsservern.
Die Pufferung kann die Performance beim Zugriff auf Daten einer Tabelle
erheblich steigern. Die Wahl der richtigen Pufferungsart ist wichtig.
Die Tabellenpuffer werden in festen Zeitintervallen an Änderungen der
Tabelleneinträge angepaßt.
Je häufiger auf eine Tabelle lesend zugegriffen wird und je seltener die
Tabelleninhalte verändert werden, desto günstiger ist es, die Tabelle zu puffern.
Abbildung 43: Entscheidungsbaum zur Pufferung
Der Entscheidungsbaum zum Puffern von Tabellen soll Ihnen zur Handreichung
auf Ihrem Entwicklungssystem dienen. Die oben genannten Erkenntnisse sind hier
in Diagrammform abgebildet.

Übung 6: Performanceaspekte beim

Tabellenzugriff
• Indizes anlegen
• Die Pufferungseigenschaften einer Tabelle pflegen
Für die tägliche Arbeit benötigen die Sachbearbeiter der Fluggesellschaften einen
schnellen Zugriff auf die Daten der Tabellen der Mitarbeiterverwaltung. In dieser
Übung sollen die Zugriffe auf die Daten in diesen Tabellen beschleunigt werden.
Auf die Personaldaten eines Mitarbeiters wird oft über die Kombination aus Vor-
und Nachnamen zugegriffen. Dabei ist der Nachname häufiger bekannt (beim
Zugriff spezifiziert) als der Vorname. Hierzu muß ein Index angelegt werden.
Für die Zusammenstellung der Mannschaft eines Fluges ist eine Zuordnung der
Mitarbeiter (Piloten und Flugbegleiter) zu Flügen notwendig. Hierzu muß eine
Tabelle angelegt werden, in der zu jedem Flug die beteiligten Mitarbeiter und
deren Funktionen auf dem Flug erfaßt werden können.
Aufgabe 1:
Legen Sie einen Index an, der den Zugriff auf die Kombination aus Vornamen
und Nachnamen unterstützt. Sorgen Sie dafür, daß der Index auf der Datenbank
angelegt wird.
Die Personaldaten der Mitarbeiter werden in der Tabelle ZEMPLOY## verwaltet.
Für diese Tabelle ist daher der Index anzulegen.
1. Legen Sie einen Index für die Tabelle ZEMPLOY## an. Er muß die Felder
Mandant, Nachname, und Vorname enthalten. Ordnen Sie die Felder in
dieser Reihenfolge.
Notiz: Der Index ist sicher kein Unique-Index, da es Mitarbeiter

mit gleichem Vor- und Nachnamen geben kann. Weiterhin besteht
kein Grund, den Index nur auf bestimmten Datenbanksystemen
anzulegen.

Aufgabe 2:
Kopieren Sie die Tabelle SFLCREW auf die Tabelle ZFLCREW##. Aktivieren
Sie die Tabelle ZFLCREW## anschließend.
1. Kopieren Sie die Tabelle SFLCREW auf die Tabelle ZFLCREW##. Ersetzen
Sie das vorhandene Datenelement für die Mitarbeiternummer durch ein
eigenes Datenelement.
Aufgabe 3:
Pflegen Sie die Einstellungen zur Pufferung der Tabellen ZDEPMENT## und
ZFLCREW#.
Überdenken Sie diese Einstellungen zur Pufferung der Tabellen ZDEPMENT##
und ZFLCREW##. Beachten Sie dabei folgende Informationen zur Nutzung
dieser Tabellen.
Die Fluggesellschaften haben zwischen 10 und 30 Abteilungen. Es werden nur
wenige Fluggesellschaften (maximal 3) in den Tabellen gemeinsam verwaltet. Die
Daten über die Mannschaften bereits beendeter Flüge werden alle drei Monate in
eine Archivdatei ausgelagert. Die Tabelle ZFLCREW## hat daher relativ wenige
Einträge (höchstens 5.000 pro Fluggesellschaft).
Auf die Tabellen ZDEPMENT## und ZFLCREW## wird sehr häufig zugegriffen.
Dabei werden Datensätze aus diesen Tabellen oft wiederholt gelesen.
Auf einem Applikationsserver arbeiten nur Verwaltungsmitarbeiter einer
Fluggesellschaft. Die Daten zur Besatzung eines Fluges sind nur innerhalb der
Fluggesellschaft von Interesse. Da die Fluggesellschaften einige Leistungen
gemeinsam erbringen, müssen Verwaltungsmitarbeiter einer Fluggesellschaft
dagegen oft auf die Abteilungsdaten einer anderen Fluggesellschaft zugreifen.
1. Pflegen Sie die Einstellungen zur Pufferung der Tabellen ZDEPMENT##
in den technischen Einstellungen.
Notiz: Da die Inhalte der Tabelle ZDEPMENT## nur selten

geändert aber häufig wiederholt gelesen werden, ist eine Pufferung
der Tabelle sinnvoll.
2. Pflegen Sie die Einstellungen zur Pufferung der Tabellen ZFLCREW##

Notiz: Die Daten der Tabelle ZFLCREW## werden häufig

wiederholt gelesen. Ändernde Zugriffe finden dagegen nur selten
statt. Daher ist eine Pufferung der Tabelle sinnvoll.

Auf einem Applikationsserver werden in der Regel nur die Daten zu einer
Fluggesellschaft benötigt. Deshalb soll die Tabelle generisch mit dem
generischen Schlüssel Mandant und Fluggesellschaft gepuffert werden.
Programm BC430_CHECK überprüft die Korrektheit Ihrer Lösungen und
füllt die neu angelegte Tabelle ZFLCREW## mit Beispieldaten, die für
spätere Übungen benötigt werden.
Achtung: Falls Sie die Zusatzübung bearbeiten, starten Sie dieses

Programm erst nach Ende der Zusatzübung.
Aufgabe 4: (optional)
Legen Sie für die Mitarbeitertabelle einen Index über die Bereiche einer
Fluggesellschaft an. Stellen Sie sicher, daß dieser Index nur auf den
Datenbanksystemen MAXDB und SQL-Server angelegt wird.
Notiz: Für den Zugriff auf die Mitarbeiterdaten bringt eventuell auch
ein Index über die Bereiche einen Performance-Gewinn, beispielsweise
wenn oft alle Piloten einer Fluggesellschaft selektiert werden. Bei
Performance-Messungen auf verschiedenen Datenbanksystemen hat
sich herausgestellt, daß dieser Performance-Gewinn nur bei den
Datenbanksystemen MAXDB und SQL-Server besteht.
1. Zeigen Sie Ihren angelegten Index an.

2. Legen Sie den neuen Index nur auf den Datenbanksystemen MAXDB und
SQL-Server.

Lösung 6: Performanceaspekte beim

Tabellenzugriff
Aufgabe 1:
Legen Sie einen Index an, der den Zugriff auf die Kombination aus Vornamen
und Nachnamen unterstützt. Sorgen Sie dafür, daß der Index auf der Datenbank
angelegt wird.
Die Personaldaten der Mitarbeiter werden in der Tabelle ZEMPLOY## verwaltet.
Für diese Tabelle ist daher der Index anzulegen.
1. Legen Sie einen Index für die Tabelle ZEMPLOY## an. Er muß die Felder
Mandant, Nachname, und Vorname enthalten. Ordnen Sie die Felder in
dieser Reihenfolge.
Notiz: Der Index ist sicher kein Unique-Index, da es Mitarbeiter

mit gleichem Vor- und Nachnamen geben kann. Weiterhin besteht
kein Grund, den Index nur auf bestimmten Datenbanksystemen
anzulegen.
a) Verzweigen Sie im Anzeigemodus in das Pflegebild der Tabelle

ZEMPLOY## und wählen Sie Indizes.
b) Bestätigen Sie im folgenden Dialogfenster, daß Sie einen Index anlegen
möchten.
c) Geben Sie auf dem nächsten Dialogfenster eine dreistellige
Indexkennung ein, und wählen Sie Weiter.
d) Im Pflegebild des Index, geben Sie einen Kurztext ein.
e) Wählen Sie Tabellenfelder. Es erscheint eine Liste aller in der Tabelle
vorhandenen Felder.
f) Markieren Sie die Felder Mandant, Nachname und Vorname, und
wählen Sie Übernehmen. Die Felder werden in der Reihenfolge aus
dem Dialogfenster in den Index übernommen.
Notiz: Falls das Feld Vorname vor dem Feld Nachname steht,
müssen Sie die Feldreihenfolge vertauschen. Stellen Sie dazu
den Cursor auf die Zeile mit dem Feld Vorname, und wählen
Sie Ausschneiden. Stellen Sie dann den Cursor in die erste freie
Zeile nach dem Feld Nachname, und wählen Sie Einsetzen.
g) Lassen Sie die Standardeinstellungen Non-Unique-Index und Index auf

allen Datenbanksystemen bestehen.

h) Aktivieren Sie den Index. Der Index wird dabei automatisch auf der
Datenbank angelegt.
Aufgabe 2:
Kopieren Sie die Tabelle SFLCREW auf die Tabelle ZFLCREW##. Aktivieren
Sie die Tabelle ZFLCREW## anschließend.
1. Kopieren Sie die Tabelle SFLCREW auf die Tabelle ZFLCREW##. Ersetzen
Sie das vorhandene Datenelement für die Mitarbeiternummer durch ein
eigenes Datenelement.
a) Geben Sie im Einstiegsbild des ABAP Dictionary im Feld
Datenbanktabelle SFLCREW ein. Wählen Sie kopieren.
b) Geben Sie im folgenden Dialogfenster im Feld nach Tabelle den
Namen ZFLCREW## ein, und wählen Sie Weiter.
c) Gehen Sie im Änderungsmodus in die Pflege der Tabelle, und ersetzen
Sie das Datenelement SEMP_NUM durch das von Ihnen angelegte
Datenelement für die Mitarbeiternummer.
d) Aktivieren Sie nun Ihre Tabelle.

Aufgabe 3:
Pflegen Sie die Einstellungen zur Pufferung der Tabellen ZDEPMENT## und
ZFLCREW#.
Überdenken Sie diese Einstellungen zur Pufferung der Tabellen ZDEPMENT##
und ZFLCREW##. Beachten Sie dabei folgende Informationen zur Nutzung
dieser Tabellen.
Die Fluggesellschaften haben zwischen 10 und 30 Abteilungen. Es werden nur
wenige Fluggesellschaften (maximal 3) in den Tabellen gemeinsam verwaltet. Die
Daten über die Mannschaften bereits beendeter Flüge werden alle drei Monate in
eine Archivdatei ausgelagert. Die Tabelle ZFLCREW## hat daher relativ wenige
Einträge (höchstens 5.000 pro Fluggesellschaft).
Auf die Tabellen ZDEPMENT## und ZFLCREW## wird sehr häufig zugegriffen.
Dabei werden Datensätze aus diesen Tabellen oft wiederholt gelesen.
Auf einem Applikationsserver arbeiten nur Verwaltungsmitarbeiter einer
Fluggesellschaft. Die Daten zur Besatzung eines Fluges sind nur innerhalb der
Fluggesellschaft von Interesse. Da die Fluggesellschaften einige Leistungen
gemeinsam erbringen, müssen Verwaltungsmitarbeiter einer Fluggesellschaft
dagegen oft auf die Abteilungsdaten einer anderen Fluggesellschaft zugreifen.
1. Pflegen Sie die Einstellungen zur Pufferung der Tabellen ZDEPMENT##
Notiz: Da die Inhalte der Tabelle ZDEPMENT## nur selten

geändert aber häufig wiederholt gelesen werden, ist eine Pufferung
der Tabelle sinnvoll.
a) Verzweigen Sie im Anzeigemodus in die Pflege der Tabelle

ZDEPMENT## und wählen Sie Technische Einstellungen. Sie
gelangen in das gewünschte Pflegebild, in dem Sie noch in den
Änderungsmodus wechseln müssen.
b) Markieren Sie Pufferung eingeschaltet. Da keine Einschränkungen
bezüglich des Zugriffs vorliegen und die Tabelle klein ist, markieren
Sie vollständig gepuffert.
c) Aktivieren Sie die technischen Einstellungen der Tabelle
ZDEPMENT##.
2. Pflegen Sie die Einstellungen zur Pufferung der Tabellen ZFLCREW##
Notiz: Die Daten der Tabelle ZFLCREW## werden häufig

wiederholt gelesen. Ändernde Zugriffe finden dagegen nur selten
statt. Daher ist eine Pufferung der Tabelle sinnvoll.

Auf einem Applikationsserver werden in der Regel nur die Daten zu einer
Fluggesellschaft benötigt. Deshalb soll die Tabelle generisch mit dem
generischen Schlüssel Mandant und Fluggesellschaft gepuffert werden.
a) Verzweigen Sie im Anzeigemodus in die Pflege der Tabelle
ZFLCREW## und wählen Sie Technische Einstellungen. Sie gelangen
in das gewünschte Pflegebild, in dem Sie noch in den Änderungsmodus
wechseln müssen.
b) Markieren Sie Pufferung eingeschaltet. Markieren Sie generische
Pufferung, und wählen Sie 2 als Anzahl der generischen Schlüsselfelder.
c) Aktivieren Sie die technischen Einstellungen der Tabelle ZFLCREW##.
Programm BC430_CHECK überprüft die Korrektheit Ihrer Lösungen und
füllt die neu angelegte Tabelle ZFLCREW## mit Beispieldaten, die für
spätere Übungen benötigt werden.
Achtung: Falls Sie die Zusatzübung bearbeiten, starten Sie dieses

Programm erst nach Ende der Zusatzübung.
Aufgabe 4: (optional)
Legen Sie für die Mitarbeitertabelle einen Index über die Bereiche einer
Fluggesellschaft an. Stellen Sie sicher, daß dieser Index nur auf den
Datenbanksystemen MAXDB und SQL-Server angelegt wird.
Notiz: Für den Zugriff auf die Mitarbeiterdaten bringt eventuell auch
ein Index über die Bereiche einen Performance-Gewinn, beispielsweise
wenn oft alle Piloten einer Fluggesellschaft selektiert werden. Bei
Performance-Messungen auf verschiedenen Datenbanksystemen hat
sich herausgestellt, daß dieser Performance-Gewinn nur bei den
Datenbanksystemen MAXDB und SQL-Server besteht.
1. Zeigen Sie Ihren angelegten Index an.

a) Wählen Sie auf diesem Dialogfenster Anlegen. Nehmen Sie die Felder
Mandant, Fluggesellschaft und Bereich in den Index auf.
Notiz: Auch hier handelt es sich nicht um einen Unique-Index.
Der Index wird nur dann auf der Datenbank angelegt, wenn Ihr
Schulungssystem auf einem der gewählten Datenbanksysteme läuft.

2. Legen Sie den neuen Index nur auf den Datenbanksystemen MAXDB und
SQL-Server.
a) Markieren Sie auf ausgewählten Datenbank-Systemen.
b) Wählen Sie dann das Pfeilsymbol in dieser Zeile. Wählen Sie
Auswahlliste. Wählen Sie über die F4-Hilfe in der Liste die Kennungen
der Datenbanksysteme ADA für Adabas und MSS für SQL-Server aus.
c) Wählen Sie Weiter.
d) Aktivieren Sie den Index.


Nun können Sie


Nun können Sie

Kapitel 4
Eingabeprüfungen

In diesem Kapitel werden Sie die Möglichkeiten kennenlernen, um
Eingabeprüfungen im Dictionary zu definieren.

• Festwerte anlegen und verwenden

• Definieren, was ein Fremdschlüssel ist
• Die Bedingungen bei der Feldzuordnung des Fremdschlüssels verstehen
und anwenden
• Den Unterschied zwischen Wertetabelle und Prüftabelle verstehen
• Fremdschlüssel anlegen
Inhalt des Kapitels

Lektion: Konsistenz durch Eingabeprüfungen ..............................104
Übung 7: Konsistenz durch Eingabeprüfungen ........................ 115

Kapitel 4: Eingabeprüfungen BC430
Lektion: Konsistenz durch Eingabeprüfungen

und anwenden
Bei der Eingabe von Werten in Ihren Applikationen, sollen bereits ohne
zusätzliches ABAP-Coding Werteprüfungen auf den Dynpros stattfinden.
Eingabeprüfung über die technische Domäne
Abbildung 44: Festwerte
Die Domäne beschreibt durch die Angabe von Datentyp und Feldlänge den
Wertebereich eines Feldes. Falls nur eine eingeschränkte Menge von Werten
zulässig ist, können diese als Festwerte angegeben werden.

BC430 Lektion: Konsistenz durch Eingabeprüfungen
Die Angabe von Festwerten bewirkt, dass der Wertebereich der Domäne durch
diese Werte beschränkt wird. Festwerte ziehen sofort als Prüfwerte bei Eingabe
auf dem Dynpro. Ebenso wird eine F4-Hilfe zur Verfügung gestellt.
Festwerte können entweder einzeln aufgelistet oder als Intervall angegeben
werden.
Abbildung 45: Wertetabelle
Der Wertebereich eines Feldes kann auch durch die Angabe einer Wertetabelle in
der Domäne bestimmt werden.
Im Gegensatz zu den Festwerten erfolgt jedoch durch die alleinige Angabe einer
Wertetabelle noch keine Eingabeprüfung. Eine F4-Hilfe ist ebenso nicht verfügbar.
Der Eintrag einer Wertetabelle bewirkt, dass das System bei der
Fremdschlüsseldefinition einen Vorschlag erstellen kann.
Eine Wertetabelle wird erst zur Prüftabelle durch die Definition eines
Fremdschlüssels. Wenn in einem Feld auf eine Dömane mit Wertetabelle
verwiesen wird, aber auf Feldebene kein Fremdschlüssel definiert wurde,
finden keine Prüfungen statt.

Abbildung 46: Einfügen eines Datensatzes
Eine Kunde möchte einen Flug bei der Fluggesellschaft American Airlines (AA)
buchen. Dieser Flug mit der Flugverbindungsnummer 0017 soll am 22.11.1997
stattfinden. Die Buchung soll am Verkaufsschalter 8 vorgenommen werden.
In der Tabelle SBOOK sind alle Flugbuchungen der Fluggesellschaften hinterlegt.
Die Tabelle SCOUNTER enthält alle gültigen Verkaufsschalter der
Fluggesellschaften.
Wird ein Eintrag in das Feld COUNTER der Tabelle SBOOK vorgenommen, so
muß sichergestellt werden, daß nur gültige Verkaufsschalter eingetragen werden
können. Das bedeutet, daß der Verkaufsschalter in der Tabelle SCOUNTER
hinterlegt sein muß.
Frage: Ist das Einfügen des oben angegeben Datensatzes in die Tabelle SBOOK
erlaubt ?

Abbildung 47: Verstoß gegen die Fremdschlüsselprüfung
Die Flugbuchung kann nicht erfolgen, da die Fluggesellschaft American Airlines

(AA) keinen Verkaufsschalter 8 hat.
Für die Eingaben aus dem Beispiel wird kein Datensatz in der Tabelle SCOUNTER
selektiert. Die Eingabe für die Tabelle SBOOK wird abgelehnt.
Im ABAP Dictionary werden solche Beziehungen zwischen zwei Tabellen
Fremdschlüssel genannt und müssen auf Feldebene explizit definiert werden.
Fremdschlüssel werden zur Konsistenzsicherung der Daten eingesetzt.
Eingegebene Daten werden gegen vorhandene Daten geprüft, um sicherzustellen,
daß sie nicht widersprüchlich sind.

Abbildung 48: Fremdschlüsselfeld / Prüffeld
BEISPIEL:
In diesem Beispiel ist die Fremdschlüsseltabelle die Tabelle SBOOK. Ziel des
Fremdschlüssels ist es zu gewährleisten, daß nur gültige Verkaufsschalter von
Fluggesellschaften einer Buchung zugeordnet werden können. Genau diese
Information enthält die Prüftabelle SCOUNTER. In dieser Tabelle wird jeder
Verkaufsschalter über drei Schlüsselfelder identifiziert: MANDT, CARRID und
COUNTNUM.
Zur Definition des Fremdschlüssels werden diese drei Felder Feldern der
Fremdschlüsseltabelle (Fremdschlüsselfeldern) zugeordnet, über die die zu
kontrollierenden Eingaben auf dem Dynpro gemacht werden. In der Tabelle
SBOOK sind dies die Felder: MANDT, CARRID, COUNTER. Stellt die Eingabe
in diese Felder eine gültige Verkaufsstelle dar, wird die Eingabe zugelassen,
andernfalls vom System abgelehnt.
Der Fremdschlüssel wird für das Feld SBOOK-COUNTER (Prüffeld) definiert,
d.h. die Prüfung findet nach der Eingabe in dieses Feld statt. Deshalb wird das
Feld COUNTER Prüffeld für diesen Fremdschlüssel genannt.
Für das Feld COUNTER, der Tabelle SBOOK wird ein Fremdschlüssel definiert,
der folgende Feldzuordnung herstellt:

Prüftabelle Fremdschlüsseltabelle
SCOUNTER-MANDT SBOOK-MANDT
SCOUNTER-CARRID SBOOK-CARRID
SCOUNTER-COUNTNUM SBOOK-COUNTER
Abbildung 49: Datenkonsistenz durch Fremdschlüssel
Eine Kombination von Feldern einer Tabelle wird als Fremdschlüssel bezeichnet,
wenn diese Feldkombination Primärschlüssel einer anderen Tabelle ist.
Ein Fremdschlüssel stellt eine Verbindung zwischen zwei Tabellen her.
Als Prüftabelle wird diejenige Tabelle bezeichnet, gegen deren Schlüsselfelder
verprobt wird. Synonym wird diese Tabelle auch referierte Tabelle genannt.
In die Fremdschlüsseltabelle soll ein Eintrag geschrieben werden. Dieser Eintrag
muß konsistent gegen die Schlüsselfelder der Prüftabelle sein.
Das Feld der Fremdschlüsseltabelle, auf dem die Prüfungen stattfinden, wird
als Prüffeld bezeichnet.
Fremdschlüssel sind nur auf Dynpros wirksam. Mittels eines ABAP Programms
können Datensätze ohne Verprobung in die Tabelle geschrieben werden.

Beispiel: In die Tabelle SPFLI (Flugplan) soll ein neuer Eintrag geschrieben
werden. Für das Feld SPFLI-CARRID wird geprüft, ob die eingetragene
Fluggesellschaft in der Tabelle SCARR (Fluggesellschaft) hinterlegt ist. Nur
wenn dies der Fall ist, wird der Satz in die Tabelle SPFLI (Fremdschlüssseltabelle)
aufgenommen. Für das Feld SPFLI-CARRID (Prüffeld) wurde ein Fremdschlüssel
definiert, d.h. auf diesem Feld finden die Verprobungen statt. Die zugehörige
Prüftabelle ist die Tabelle SCARR mit den Primärschlüsselfeldern MANDT und
CARRID.
Abbildung 50: Fremdschlüsseldefinition beim Prüffeld
Damit nicht Felder mit verschiedenen Datentypen und Feldlängen verglichen

werden, wird innerhalb des ABAP Dictionary die gleiche Domäne hinter Prüffeld
und referiertem Schlüsselfeld der Prüftabelle gefordert. Wesentlich ist die
Domänengleichheit. Es können unterschiedliche Datenelemente benutzt
werden, die auf die gleiche Domäne verweisen.
Die Voraussetzung der Domänengleichheit gilt nur für das Prüffeld. Bei allen
anderen Fremdschlüsselfeldern ist die Gleichheit des Datentyps und der Feldlänge
ausreichend. Trotzdem sollten Sie auf Domänengleichheit achten. Bei Änderungen
der Feldlänge bleibt in diesem Fall der Fremdschlüssel konsistent, weil die
zugeordneten Felder beide verändert werden. Bei unterschiedlichen Domänen
würde bei Änderung, z.B. der Feldlänge, der Fremdschlüssel inkonsistent.
Besitzt die Domäne des Prüffeldes eine Wertetabelle, so können Sie sich vom
System einen Vorschlag mit der Wertetabelle als Prüftabelle erstellen lassen. In
diesem Fall wird ein Vorschlag für die Feldzuordnung im Fremdschlüssel erzeugt.

ACHTUNG! Die Konstellation, daß hinter dem Feld SAIRPORT-ID eine

Domäne verwendet wird, die als Wertetabelle die Tabelle SAIRPORT selber
hat, ist richtig! Auf diesem Feld wird aber nie ein Fremdschlüssel definiert
(Vermeidung eines Kreisschlusses).
Abbildung 51: Prüftabelle ungleich Wertetabelle
Wenn die Wiederverwendbarkeit der Domänen auch an unpassenden Stellen

eingesetzt wird, kann der Vorschlag für die Prüftabelle unpassenden sein. Im
obigen Fall ist in mehreren Tabellen ein Primärschlusselfeld vorhanden, dass auf
der gleichen Domäne wie das Prüffeld basiert. Der Systemvorschlag lautet dann
auf die Wertetabelle der Domäne. Um dieses Problem von Vorneherein
Im obigen Beispiel für die Fremdschlüsseldefinition für das Feld
SBOOK-AGENCYNUM sieht der Systemvorschlag ausgehend von der
Wertetabelle in der Domäne wie folgt aus:
Prüftabelle: SBUSPART
Feldzuordnung:
Prüftabelle Fremschlüsseltabelle
SBUSPART-MANDT SBOOK-MANDT
SBUSPART-BUSPARTNUM SBOOK-AGENCYNUM
Dieser Vorschlag macht nicht das, was Sie wollen:

Die Tabelle SBUSPART enthält alle Geschäftspartner der Fluggesellschaften.

Für das Feld SBOOK-AGENCYNUM sind aber nur Reisebüros zulässig.
Damit enthält die Tabelle SBUSPART ungültige Daten für dieses Feld. Der
Systemvorschlag ist somit falsch! Die richtige Prüftabelle ist die Tabelle
STRAVELAG. Sie ist durch ihre Fremdschlüsseldefinition auf dem Feld
AGENCYNUM eine Teilmenge der Tabelle SBUSPART.
Sie müssen den Systemvorschlag mit der Tabelle STRAVELAG
überschreiben. Falls Sie die richtige Prüftabelle nicht kennen, hilft das
System durch die Angabe aller in Frage kommender Tabellen. Dies sind alle
Tabellen, die ein Schlüsselfeld mit der Domäne S_BUSPANUM besitzen.
Abbildung 52: Semantische Eigenschaften
Die Kardinalität beschreibt die Fremdschlüsselbeziehung im Hinblick

auf die Anzahl der Zuordnungen der Sätze der Prüftabelle zu Sätzen der
Fremdschlüsseltabelle. Die Kardinalität wird immer aus Sicht der Prüftabelle
definiert.
Die Art des Fremdschlüsselfeldes definiert, ob das Fremdschlüsselfeld einen
Tabelleneintrag identifiziert oder nicht. Das bedeutet, dass Fremdschlüsselfelder
entweder Schlüsselfelder oder Nichtschlüsselfelder oder aber ein Spezialfall sind,
nämlich die Schlüsselfelder einer Texttabelle.

Es sind folgende Angaben zur Art der Fremdschlüsselfelder möglich:

• Nicht spezifiziert: Es kann keine Aussage über die Art des
Fremdschlüsselfeldes gemacht werden
• Keine Schlüsselfelder/-kandidaten: Die Fremdschlüsselfelder sind weder
Primärschlüsselfelder der Fremdschlüsseltabelle noch identifizieren Sie
einen Satz der Fremdschlüsseltabelle eindeutig (Schlüsselkandidaten).
Die Fremdschlüsselfelder sind damit nicht (teil)identifizierend für die
Fremdschlüsseltabelle.
• Schlüsselfelder/-kandidaten: Die Fremdschlüsselfelder sind entweder
Primärschlüsselfelder der Fremdschlüsseltabelle oder sie identifizieren
einen Satz der Fremdschlüsseltabelle eindeutig (Schlüsselkandidaten).
Die Fremdschlüsselfelder sind damit (teil)identifizierend für die
Fremdschlüsseltabelle.
• Schlüsselfelder einer Texttabelle: Die Fremdschlüsseltabelle ist eine
Texttabelle der Prüftabelle; der Schlüssel der Fremdschlüsseltabelle
unterscheidet sich z.B. von dem der Prüftabelle in einem zusätzlichen
Sprachenschlüsselfeld. Dieser Fall ist ein Spezialfall der Art
Schlüsselfelder/-kandidaten.
Abbildung 53: Texttabelle
In der Tabelle SMEAL sind Mahlzeiten hinterlegt, die dem Flugkunden während
eines Fluges serviert werden. Die Bezeichnungen der Flugmahlzeiten sind in
der Tabelle SMEALT gepflegt.

Die Tabelle SMEALT ist Texttabelle zur Tabelle SMEAL, da sich der Schlüssel
von SMEALT aus dem Schlüssel der SMEAL und einem zusätzlichen
Sprachschlüsselfeld (Feld mit Datentyp LANG) zusammensetzt.
In der Tabelle SMEALT können damit zu jedem Schlüsseleintrag von SMEAL
erläuternde Texte in mehreren Sprachen erfaßt werden.
Um die Schlüsseleinträge mit den Texten zu verknüpfen, muß die Texttabelle
SMEALT mit der Tabelle SMEAL über einen Fremdschlüssel verbunden werden.
Hierbei muß Schlüsselfelder einer Texttabelle für die Art der Fremdschlüsselfelder
gewählt werden.
Die Fremdschlüsselbeziehung wird von der SMEALT zur SMEAL definiert.
Mit einer Tabelle kann nur eine Texttabelle verknüpft werden.

Übung 7: Konsistenz durch

Eingabeprüfungen
• Festwerte anlegen
• Wertetabellen im richtigen Kontext einsetzen
• Fremdschlüssel definieren
• Obige Mechanismen einsetzen, um die Konsistenz der Daten sicherzustellen
Beim Erfassen oder Ändern der Mitarbeiterstammdaten sollen nur konsistente
Daten, gültige Fluggesellschaften, Abteilungen, Bereiche zugelassen werden.
Die Mitarbeiter der Fluggesellschaften werden unterteilt in Administrationsper-
sonal (A), Flugpersonal (F) oder Servicepersonal (S). Entsprechend dieser
Einteilung werden sie den Tätigkeitsbereichen A, F oder S zugeordnet.
Aufgabe 1:
Unterteilen Sie die Mitarbeiter der Fluggesellschaften in Administrationspersonal
(A), Flugpersonal (F) oder Servicepersonal (S). Sorgen Sie dafür, daß in die
Tabelle ZEMPLOY## nur gültige Tätigkeitsbereiche eingetragen werden können.
1. Pflegen Sie Festwerte in der Domäne für das Feld AREA in ZEMPLOY##.

Aufgabe 2:
Definieren Sie geeignete Fremschlüssel für Tabellen ZEMPLOY##,
ZDEPMENT## and ZFLCREW##.
Verwenden Sie zur Fremdschlüsseldefinition außer Ihren Tabellen die Tabellen
des Flugmodells, die Tabellen T000 (Mandant) und SCURX (Währungscodes).
Zur Pflege der einzelnen Fremdschlüssel rufen Sie die Pflege der jeweiligen
Tabellen auf. Wählen Sie das Register Felder.
Definieren Sie jeweils eine Fremdschlüsselprüfung für folgende Felder:
Tabelle Feld
ZEMPLOY## Mandant
Fluggesellschaft
Abteilungskürzel
Währung
ZDEPMENT## Mandant
Fluggesellschaft
ZFLCREW## Mitarbeiternummer
1. Legen Sie den Fremdschlüssel ZEMPLOY##-Mandant an.

2. Legen Sie den Fremdschlüssel ZEMPLOY##-Fluggesellschaft an.
Notiz: Da Sie für das Feld Fluggesellschaft in ZEMPLOY##

die Domäne S_CARR_ID benutzen, steht Ihnen zur
Fremdschlüsseldefinition die Wertetabelle SCARR zur Verfügung.
3. Legen Sie den Fremdschlüssel ZEMPLOY##-Abteilungskürzel an.

Tragen sie in der Domäne zum Feld Abteilungskürzel in ZEMPLOY## die
Wertetabelle ZDEPMENT## ein, und aktivieren Sie die Domäne.
Notiz: Um bei der Fremschlüsseldefinition einen Vorschlag

zu erhalten, müssen Sie für das Feld Abteilungskürzel in
ZEMPLOY## die Domäne verändern. Dies ist zur späteren
Fremdschlüsseldefinition nicht zwingend notwendig, erleichtert
aber die Definition.

4. Legen Sie den Fremdschlüssel ZEMPLOY##-Währung an.
Notiz: Da Sie für das Feld ZEMPLOY##-Währung die Domäne

S_CURR benutzen, steht Ihnen zur Fremdschlüsseldefinition die
Wertetabelle SCURX zur Verfügung.
5. Legen Sie den Fremdschlüssel ZDEPMENT##-Mandant an.

6. Legen Sie den Fremdschlüssel ZDEPMENT##-Fluggesellschaft an.
7. Legen Sie den Fremdschlüssel ZFLCREW##-Mitarbeiternummer an.
8. Pflegen Sie Daten für Ihre Tabelle ZEMPLOY## und testen Sie dabei die
Wirksamkeit Ihrer Fremdschlüsselbeziehungen.
Aufgabe 3:
Manche Mitarbeiter von Fluggesellschaften arbeiten in Reisebüros, um dort für
Ihre Gesellschaft Flüge zu verkaufen. Erweitern Sie Tabelle ZEMPLOY## um ein
Feld, das das Reisebüro dokumentiert, in dem der jeweilige Mitarbeiter arbeitet.
Erweitern Sie die Tabelle ZEMPLOY entsprechend und definieren Sie die
Fremdschlüsselbeziehung.
Hinweis: Die Tabelle aller Reisebüros heißt STRAVELAG.
1. Legen Sie nun ein neues Feld Reisebüro in Ihrer Tabelle ZEMPLOY## an.
Aufgabe 4:
Erweitern Sie die Tabelle ZDEPMENT## um ein Feld.
Jede Abteilung in einer Fluggesellschaft hat einen Abteilungsleiter. Die
Zuordnung zwischen Abteilung und Abteilungsleiter soll auch im Flugmodell
abgebildet werden.
1. Erweitern Sie die Tabelle ZDEPMENT## um ein Feld Abteilungsleiter.
Notiz: In unserem Modell identifiziert die Personalnummer eine

Person. Aus diesem Grund muß das neu zur Tabelle ZDEPMENT##
hinzuzufügende Feld Personalnummern enthalten. Das Feld sollte
also auf die Domäne für Personalnummern verweisen.
Da die Person, die in diesem Fall verwaltet wird, eine besondere
Rolle besitzt, sollten Sie aber nicht das bereits angelegte
Datenelement für die Personalnummer verwenden, sondern ein
neues anlegen.

Definieren Sie für dieses Feld einen geeigneten Fremdschlüssel.
Notiz: Nutzen Sie das zweistufige Domänenkonzept aus.
Aufgabe 5:
Legen Sie eine Texttabelle an.
1. Legen Sie eine Texttabelle ZDEPMENTT## zu der Tabelle ZDEPMENT##.
Notiz: Das wird das Abteilungskürzel für die Mitarbeiter der

Fluggesellschaft über alle Länder verständlich machen.
Verwenden Sie zur Felddefinition die Datenelemente SPRAS (Datentyp

LANG) und S_TEXT (Datentyp CHAR, 40).
2. Definieren Sie die Fremdschlüssel des Feldes Abteilungskürzel in der Tabelle
ZDEPMENTT##.
Notiz: Die Fremdschlüssel der Felder Mandant und Fluggesellschaft

in der Tabelle ZDEPMENTT## sind durch das Kopieren bereits
richtig definiert.
3. Definieren Sie die Fremdschlüssel des Feldes Sprache in der Tabelle

ZDEPMENTT##.
Notiz: Da Sie für das Feld ZDEPMENTT##-Sprache die Domäne

SPRAS benutzen, steht Ihnen zur Fremdschlüsseldefinition die
Wertetabelle T002 zur Verfügung.

Lösung 7: Konsistenz durch

Eingabeprüfungen
Aufgabe 1:
Unterteilen Sie die Mitarbeiter der Fluggesellschaften in Administrationspersonal
(A), Flugpersonal (F) oder Servicepersonal (S). Sorgen Sie dafür, daß in die
Tabelle ZEMPLOY## nur gültige Tätigkeitsbereiche eingetragen werden können.
1. Pflegen Sie Festwerte in der Domäne für das Feld AREA in ZEMPLOY##.
a) Verzweigen Sie aus dem Tabellenpflegebild auf das entsprechende
Datenelement und von dort zur Domäne.
b) Wählen Sie die Registerkarte Wertebereich und tragen Sie folgende
Festwerte ein:
Festwert Kurzbeschreibung
A Administrationspersonal
F Flugpersonal
S Servicepersonal
c) Aktivieren Sie Ihre Domäne.
Aufgabe 2:
Definieren Sie geeignete Fremschlüssel für Tabellen ZEMPLOY##,
ZDEPMENT## and ZFLCREW##.
Verwenden Sie zur Fremdschlüsseldefinition außer Ihren Tabellen die Tabellen
des Flugmodells, die Tabellen T000 (Mandant) und SCURX (Währungscodes).
Zur Pflege der einzelnen Fremdschlüssel rufen Sie die Pflege der jeweiligen
Tabellen auf. Wählen Sie das Register Felder.
Definieren Sie jeweils eine Fremdschlüsselprüfung für folgende Felder:
Tabelle Feld
ZEMPLOY## Mandant
Fluggesellschaft
Abteilungskürzel
Währung

Tabelle Feld
ZDEPMENT## Mandant
Fluggesellschaft
ZFLCREW## Mitarbeiternummer
1. Legen Sie den Fremdschlüssel ZEMPLOY##-Mandant an.

a) Positionieren Sie den Cursor auf das Feld Mandant in ZEMPLOY##.
Wählen Sie Springen → Fremdschlüssel.
Da Sie für das Feld Mandant in ZEMPLOY## die Domäne MANDT
benutzen, schlägt Ihnen das System die Wertetabelle T000 als
Prüftabelle vor.
b) Lassen Sie sich den Vorschlag zur Fremdschlüsseldefinition erstellen.
Kontrollieren Sie den Vorschlag. Folgende Felder müssen zugeordnet
sein:
Prüftabelle T000
PrüftabFeld FremdschlTab FremdschlFeld
MANDT ZEMPLOY## Mandant
c) Erfassen Sie eine Kurzbeschreibung und legen Sie die semantischen

Eigenschaften wie folgt fest:
Feld Wert
Art der Fremdschlüsselfelder Schlüsselfelder/-
kandidaten
Kardinalität 1:CN
d) Sichern Sie Ihren Fremdschlüssel.

2. Legen Sie den Fremdschlüssel ZEMPLOY##-Fluggesellschaft an.
Notiz: Da Sie für das Feld Fluggesellschaft in ZEMPLOY##

die Domäne S_CARR_ID benutzen, steht Ihnen zur
Fremdschlüsseldefinition die Wertetabelle SCARR zur Verfügung.
a) Positionieren Sie den Cursor auf das Feld Fluggesellschaft. Wählen

Sie Springen → Fremdschlüssel.
sein:
Prüftabelle SCARR
CARRID ZEMPLOY## Fluggesellschaft

Feld Wert
kandidaten
Kardinalität 1:CN

3. Legen Sie den Fremdschlüssel ZEMPLOY##-Abteilungskürzel an.

Tragen sie in der Domäne zum Feld Abteilungskürzel in ZEMPLOY## die

Wertetabelle ZDEPMENT## ein, und aktivieren Sie die Domäne.
Notiz: Um bei der Fremschlüsseldefinition einen Vorschlag

zu erhalten, müssen Sie für das Feld Abteilungskürzel in
ZEMPLOY## die Domäne verändern. Dies ist zur späteren
Fremdschlüsseldefinition nicht zwingend notwendig, erleichtert
aber die Definition.
a) Positionieren Sie den Cursor zunächst auf das Feld Abteilungskürzel in

ZEMPLOY## . Wählen Sie Springen → Fremdschlüssel.
Notiz: Da Sie für das Feld ZEMPLOY##-Abteilungskürzel die
Domäne des Feldes ZDEPMENT##-Abteilungskürzel benutzen,
steht Ihnen zur Fremdschlüsseldefinition die Wertetabelle
ZDEPMENT## zur Verfügung.

sein:
Prüftabelle ZDEPMENT##
CARRID ZEMPLOY## Fluggesellschaft
DEPARTMENT ZEMPLOY## Abteilungskürzel

Feld Wert
Art der Fremdschlüsselfelder keine Schlüs-
selfelder/-kandidaten
Kardinalität 1:CN

4. Legen Sie den Fremdschlüssel ZEMPLOY##-Währung an.
Notiz: Da Sie für das Feld ZEMPLOY##-Währung die Domäne

S_CURR benutzen, steht Ihnen zur Fremdschlüsseldefinition die
Wertetabelle SCURX zur Verfügung.
a) Positionieren Sie den Cursor auf das Feld ZEMPLOY##-Währung.

sein:
Prüftabelle SCURX
CURRKEY ZEMPLOY## Währung

Feld Wert
Kardinalität 1:CN

5. Legen Sie den Fremdschlüssel ZDEPMENT##-Mandant an.
a) Siehe Fremdschlüssel ZEMPLOY##-Mandant.
Feld Wert
kandidaten
Kardinalität 1:CN

6. Legen Sie den Fremdschlüssel ZDEPMENT##-Fluggesellschaft an.

a) Siehe Fremdschlüssel ZEMPLOY##-Fluggesellschaft.
Feld Wert
kandidaten
Kardinalität 1:CN
7. Legen Sie den Fremdschlüssel ZFLCREW##-Mitarbeiternummer an.

a) Positionieren Sie den Cursor auf das Feld Mitarbeiternummer in
ZFLCREW##. Wählen Sie Springen → Fremdschlüssel.
Notiz: Die Prüftabelle ist die Tabelle ZEMPLOY##. Wenn Sie
sie bei der Domäne für die Mitarbeiternummer als Wertetabelle
hinterlegt haben, wird ein entsprechender Vorschlag erzeugt.
Falls nicht, müssen Sie sie selbst eintragen.
b) Für die Feldzuordnung übernehmen Sie den Systemvorschlag.

Feld Wert
kandidaten
Kardinalität 1:CN

8. Pflegen Sie Daten für Ihre Tabelle ZEMPLOY## und testen Sie dabei die
Wirksamkeit Ihrer Fremdschlüsselbeziehungen.
a) In der Pflege der Tabelle ZEMPLOY##, wählen Sie Hilfsmittel →
Tabelleninhalt → Einträge erfassen.
b) Erfassen Sie Daten und überprüfen Sie über die F4-Hilfe die Funktion
Ihrer Fremdschlüssel.
Aufgabe 3:
Manche Mitarbeiter von Fluggesellschaften arbeiten in Reisebüros, um dort für
Ihre Gesellschaft Flüge zu verkaufen. Erweitern Sie Tabelle ZEMPLOY## um ein
Feld, das das Reisebüro dokumentiert, in dem der jeweilige Mitarbeiter arbeitet.

Erweitern Sie die Tabelle ZEMPLOY entsprechend und definieren Sie die
Fremdschlüsselbeziehung.
Hinweis: Die Tabelle aller Reisebüros heißt STRAVELAG.
1. Legen Sie nun ein neues Feld Reisebüro in Ihrer Tabelle ZEMPLOY## an.
a) Navigieren Sie zur Feldpflege der Tabelle ZEMPLOY##. Fügen Sie
ein neues Feld Reisebüro in die Feldliste ein (über Neue Zeilen).
Notiz: In der Pflege der Tabelle STRAVELAG können Sie
feststellen, daß das passende Datenelement S_AGNCYNUM
heißt.
b) Ordnen Sie das Datenelement S_AGNCYNUM Ihrem neuen Feld

ZEMPLOY##-Reisebüro zu.
c) Setzen Sie nun den Cursor auf das Feld Reisebüro, und lassen Sie sich
einen Vorschlag zur Fremdschlüsseldefinition erstellen.
d) Kontrollieren Sie den Vorschlag: Die Prüftabelle ist SBUSPART.
Diese Prüftabelle ist falsch, denn sie enthält alle Geschäftspartner von
Fluggesellschaften und nicht nur Reisebüros.
e) Die richtige Prüftabelle ist STRAVELAG, die die Reisebüros enthält,
mit denen die Fluggesellschaften zusammenarbeiten.
f) Zum besseren Verständnis können Sie sich die Definition der Tabelle
STRAVELAG in einem zweiten Modus anschauen. Das Feld
AGENCYNUM besitzt einen Fremdschlüssel mit der Prüftabelle
SBUSPART. Dies bedeutet, daß die Tabelle STRAVELAG eine
Teilmenge der Tabelle SBUSPART ist. Überschreiben Sie in der
Fremdschlüsseldefinition für ZEMPLOY##-Reisebüro den Eintrag
SBUSBART im Eingabefeld Prüftabelle durch STRAVELAG.
g) Wählen Sie Übernehmen. Das System erkennt die Änderung
der Prüftabelle und bietet Ihnen an, einen Vorschlag zu erstellen.
Akzeptieren Sie dies, und markieren Sie den Vorschlag. Folgende
Felder müssen zugeordnet sein:
Prüftabelle STRAVELAG
AGENCYNUM ZEMPLOY## Reisebüro

h) Erfassen Sie eine Kurzbeschreibung und legen Sie die semantischen

Feld Wert
Kardinalität 1:CN
i) Wählen Sie Übernehmen.

j) Aktivieren Sie nun Ihre Tabelle.
k) In der Pflege der Tabelle ZEMPLOY## wählen Sie Hilfsmittel
→ Tabelleninhalt → Einträge erfassen. Verifizieren Sie über die
angebotene F4-Hilfe Ihren Fremdschlüssel.
Aufgabe 4:
Erweitern Sie die Tabelle ZDEPMENT## um ein Feld.
Jede Abteilung in einer Fluggesellschaft hat einen Abteilungsleiter. Die
Zuordnung zwischen Abteilung und Abteilungsleiter soll auch im Flugmodell
abgebildet werden.
1. Erweitern Sie die Tabelle ZDEPMENT## um ein Feld Abteilungsleiter.
Notiz: In unserem Modell identifiziert die Personalnummer eine

Person. Aus diesem Grund muß das neu zur Tabelle ZDEPMENT##
hinzuzufügende Feld Personalnummern enthalten. Das Feld sollte
also auf die Domäne für Personalnummern verweisen.
Da die Person, die in diesem Fall verwaltet wird, eine besondere
Rolle besitzt, sollten Sie aber nicht das bereits angelegte
Datenelement für die Personalnummer verwenden, sondern ein
neues anlegen.
Definieren Sie für dieses Feld einen geeigneten Fremdschlüssel.
Notiz: Nutzen Sie das zweistufige Domänenkonzept aus.
a) Verzweigen Sie im Änderungsmodus in das Pflegebild der Tabelle

ZDEPMENT##. Wählen Sie das Register Felder.
b) Wählen Sie Neue Zeilen.

c) Tragen Sie direkt hinter den bereits vorhandenen Feldern das neue Feld
Abteilungleiter ein, indem Sie in die erste Spalte einen geeigneten
Feldnamen eingeben und in die Spalte Feldtyp einen Namen für das
anzulegende Datenelement eintragen.
d) Sichern Sie die Tabellendefinition.
e) Markieren Sie den Namen des neu anzulegenden Datenelements.
Bestätigen Sie, daß Sie das Datenelement anlegen möchten.
f) Erfassen Sie eine Kurzbeschreibung für das Datenelement. Geben Sie
dann in das Feld Domäne den Namen der Domäne ein, die Sie für die
Personalnummer bereits angelegt haben.
g) Wählen Sie die Registerkarte Feldbezeichner, und geben Sie dort
entsprechende Texte ein.
h) Aktivieren Sie das Datenelement. Gehen Sie dann mit Zurück in die
Pflege der Tabelle ZDEPMENT##.
i) Legen Sie den Fremdschlüssel zu dem neuen Feld wie gewohnt an. Die
Prüftabelle ist Tabelle ZEMPLOY##.
Notiz: Wenn Sie diese Tabelle als eine Wertetabelle für die
Domäne für die Personalnummer abgelegt haben, macht das
System diesen Vorschlag. Wenn nicht, müssen Sie sie selbst
eingeben.
j) Bei der Feldzuordnung des Fremdschlüssels übernehmen Sie den

Systemvorschlag.
k) Erfassen Sie eine Kurzbeschreibung und legen Sie die semantischen
Feld Wert
Kardinalität 1:C
l) Aktivieren Sie nun Ihre Tabelle.
Aufgabe 5:
Legen Sie eine Texttabelle an.
1. Legen Sie eine Texttabelle ZDEPMENTT## zu der Tabelle ZDEPMENT##.
Notiz: Das wird das Abteilungskürzel für die Mitarbeiter der

Fluggesellschaft über alle Länder verständlich machen.

Verwenden Sie zur Felddefinition die Datenelemente SPRAS (Datentyp

LANG) und S_TEXT (Datentyp CHAR, 40).
a) Kopieren Sie Tabelle ZDEPMENT## nach Tabelle ZDEPMENTT##.
b) Navigieren Sie zur Feldpflege der Tabelle ZDEPMENTT##. Löschen
Sie alle Felder, die keine Schlüsselfelder sind. Legen Sie folgende
neue Felder an:
Feld Datenele- Daten- Bedeutung

ment typ,
Länge
LANGUAGE SPRAS LANG Sprache
DESCR S_TEXT CHAR, Beschreibung
40
Notiz: Das ZDEPMENTT##-Feld Sprache muß ein

Schlüsselfeld sein.

2. Definieren Sie die Fremdschlüssel des Feldes Abteilungskürzel in der Tabelle

ZDEPMENTT##.
Notiz: Die Fremdschlüssel der Felder Mandant und Fluggesellschaft

in der Tabelle ZDEPMENTT## sind durch das Kopieren bereits
richtig definiert.
a) Positionieren Sie den Cursor zunächst auf das Feld Abteilungskürzel in

der Tabelle ZDEPMENTT##. Wählen Sie Springen → Fremdschlüssel.
Notiz: Da Sie für das Feld ZDEPMENTT##-Abteilungskürzel
die Domäne des Feldes ZDEPMENT##-Abteilungskürzel
benutzen, steht Ihnen zur Fremdschlüsseldefinition die
Wertetabelle ZDEPMENT## zur Verfügung.

sein:
Prüftabelle ZDEPMENT##
MANDT ZDEPMENT## Mandant
CARRID ZDEPMENT## Fluggesellschaft
DEPARTMENT ZDEPMENT## Abteilungskürzel

Feld Wert
Art der Fremdschlüsselfelder Schlüsselfelder einer
Texttabelle
Kardinalität 1:CN

3. Definieren Sie die Fremdschlüssel des Feldes Sprache in der Tabelle

ZDEPMENTT##.
Notiz: Da Sie für das Feld ZDEPMENTT##-Sprache die Domäne

SPRAS benutzen, steht Ihnen zur Fremdschlüsseldefinition die
Wertetabelle T002 zur Verfügung.
a) Positionieren Sie den Cursor auf das Feld ZDEPMENTT##-Sprache.

sein:
Prüftabelle T002
SPRAS ZDEPMENTT## Sprache

Feld Wert
Art der Fremdschlüs- Schlüsselfelder/-
selfelder kandidaten
Kardinalität 1:CN

e) Aktivieren Sie nun Ihre Tabelle.


Nun können Sie
und anwenden


Nun können Sie
und anwenden

Kapitel 5
Abhängigkeiten bei Objekten

In diesem Kapitel werden Sie die Abhängigkeiten kennen lernen, die zwischen
verschiedenen Dictionary-Objekten bestehen.

• die Funktionsweise des Repository Infosystems und des

Verwendungsnachweises für ABAP Dictionary Objekte erläutern
• den Mechanismus zur Behandlung von abhängigen Objekten im ABAP
Dictionary beschreiben
• zwischen aktiver und inaktiver Version eines ABAP Dictionary Objekts
unterscheiden
Inhalt des Kapitels

Lektion: Abhängigkeiten bei Objekten .......................................134
Übung 8: Abhängigkeiten bei ABAP Dictionary Objekten.............139

Kapitel 5: Abhängigkeiten bei Objekten BC430
Lektion: Abhängigkeiten bei Objekten

unterscheiden
Zwischen Dictionary-Objekten bestehen des öfteren gewisse Abhängikeiten, die
durch Veränderungen eines Objekts zum Tragen kommen. Wenn Sie z.B. eine
technische Domäne verändern, kann dies zur Folge haben, dass eine oder mehrere
Datenbanktabellen umgesetzt werden müssen (kann sehr zeitintensiv sein).
Aktivierung und Verwendungsnachweis
Abbildung 54: Aktive und inaktive Versionen

BC430 Lektion: Abhängigkeiten bei Objekten
Im Rahmen einer Entwicklung besteht oft der Bedarf, ein bereits vom System
genutztes (aktives) Objekt zu ändern. Solche Änderungen werden im ABAP
Dictionary durch die Trennung von aktiver und inaktiver Version unterstützt.
Die aktive Version eines ABAP Dictionary Objekts ist die Version, auf die die
Komponenten der Laufzeitumgebung (ABAP Prozessor, Datenbankschnittstelle
usw.) zugreifen. Diese Version bleibt von Änderungen zunächst unberührt.
Eine inaktive Version entsteht, wenn ein bereits aktives Objekt geändert wird.
Die inaktive Version kann ungeprüft gesichert werden. Sie beeinflußt das
Laufzeitsystem nicht.
Am Ende eines Entwicklungsprozesses kann die inaktive Version zur aktiven
Version gemacht werden. Dieses geschieht durch den Vorgang des Aktivierens.
Hierbei wird die inaktive Version des Objekts zunächst auf Konsistenz geprüft. Ist
diese gegeben, so ersetzt die inaktive Version die aktive. Von diesem Zeitpunkt an
benutzt das Laufzeitsystem die neue aktive Version.
Das obige Beispiel zeigt den Wechsel des Objektstatus. Eine aktive Struktur
enthält drei Felder. Im ABAP Dictionary wird ein Feld an diese Struktur angefügt.
Nach dieser Aktion sind eine aktive Version mit drei Feldern und eine inaktive
Version mit vier Feldern vorhanden. Beim Aktivieren wird die aktive Version mit
der inaktiven Version überschrieben. Die inaktive Version wird damit zur aktiven
Version. Nach dieser Aktion existiert also nur noch die aktive Version mit vier
Feldern.
Abbildung 55: Laufzeitobjekte

Die Informationen zu einer Struktur (bzw. Tabelle) sind im ABAP Dictionary auf
Domänen, Datenelemente und die Strukturdefinition verteilt. Das Laufzeitobjekt
(Nametab) faßt diese Informationen zu einer Struktur in einer für den Zugriff von
ABAP Programmen optimierten Form zusammen. Das Laufzeitobjekt wird bei
der Aktivierung der Struktur erzeugt.
Die Laufzeitobjekte der Strukturen werden gepuffert, so daß das ABAP
Laufzeitsystem schnell auf diese Informationen zugreifen kann.
Im Laufzeitobjekt sind Informationen zur Gesamtstruktur (z.B. Anzahl der Felder)
und zu den einzelnen Strukturfeldern (Feldname, Position des Feldes in der
Struktur, Datentyp, Länge, Anzahl Dezimalstellen, Referenzfeld, Referenztabelle,
Prüftabelle, Konvertierungsroutine usw.) enthalten.
Das Laufzeitobjekt einer Tabelle enthält zusätzlich Informationen, die die
Datenbankschnittstelle für den Zugriff auf die Daten der Tabelle benötigt
(Mandantenabhängigkeit, Pufferung, Schlüsselfelder usw.).
Laufzeitobjekte werden für alle ABAP Dictionary Objekte erzeugt, die in ABAP
Programmen als Typen verwendet werden können. Neben Strukturen und Tabellen
sind dies Datenelemente, Tabellentypen und Views.
Abbildung 56: Verwendungsnachweis
Wird ein bereits aktives Objekt modifiziert, so kann dies Auswirkungen auf
andere Objekte haben, die es (direkt oder indirekt) verwenden. Diese Verwender
werden als abhängige Objekte bezeichnet. Zum einen kann es nötig sein, die

Laufzeitobjekte dieser Abhängigen an die Änderungen anzupassen. Zum anderen

kann in manchen Fällen eine Änderung sogar dazu führen, daß ein abhängiges
Objekt inkonsistent wird.
Bei der Aktivierung eines bereits aktiven Objekts werden daher (falls nötig) die
abhängigen Objekte bestimmt und aktiviert. Dabei werden jeweils die aktiven
Versionen der Abhängigen erneut aktiviert. Insbesondere bleiben neue oder
inaktive Versionen von Objekten, die das geänderte Objekt verwenden, hierbei
unberührt.
Beispiel: Nach einer Änderung einer Domäne, z.B. einer Änderung des Datentyps,
müssen alle Datenelemente, Strukturen und Tabellen erneut aktiviert werden, die
auf diese Domäne verweisen. Diese Nachaktivierung wird bei der Aktivierung der
Domäne automatisch angestoßen. Damit ist sichergestellt, daß alle betroffenen
Laufzeitobjekte an die geänderten Typinformationen angepaßt werden.
Besitzt ein ABAP Dictionary Objekt eine Tabelle als Abhängige, so muß bei der
Abhängigenaktivierung eventuell nicht nur deren Laufzeitobjekt, sondern auch
deren Datenbankobjekt angepaßt werden. Die hierbei verwendeten Verfahren
sind Gegenstand des nächsten Kapitels.
Die Änderung eines ABAP Dictionary Objekts wirkt sich gegebenenfalls auf seine
abhängigen Objekte aus. Vor einer kritischen Änderung (z.B. Datentypänderung,
Feldlöschung) sollten Sie die Menge dieser Objekte bestimmen, um die Folgen
der geplanten Aktion abschätzen zu können.
Für jedes ABAP Dictionary-Objekt gibt es einen Verwendungsnachweis,
mit dessen Hilfe Sie alle Objekte suchen können, die sich auf dieses Objekt
beziehen. Der Verwendungsnachweis kann aus der Pflegetransaktion des Objektes
aufgerufen werden.
Mit dem Verwendungsnachweis können Sie nach direkten und indirekten
Verwendungen eines ABAP Dictionary Objekts suchen. Dabei müssen Sie noch
festlegen, welche Verwendungsobjekttypen bei der Suche berücksichtigt werden
sollen (z.B. alle Strukturen und Tabellen, die ein Datenelement verwenden). Sie
können auch nach Verwendungen suchen, die keine ABAP Dictionary Objekte
sind (z.B. alle Programm, die eine Tabelle verwenden). Die Suche kann über die
Entwicklungsklasse oder den Namensraum des Verwenders eingeschränkt werden.
Besitzt ein Objekt vermutlich viele Verwender, so sollten Sie die Suche im
Hintergrund durchführen.

Abbildung 57: Das Repository-Infosystem ABAP Dictionary
Das Repository-Infosystem ABAP Dictionary ist ein Teil des allgemeinen

Repository-Infosystems. Es ermöglicht die Suche nach ABAP Dictionary
Objekten und deren Verwendern.
Der Verwendungsnachweis für Repository Objekte kann vom Infosystem aus
aufgerufen werden. Außerdem bietet das Infosystem die Möglichkeit, Objekte
anhand ihrer Eigenschaften zu suchen.
Neben den objektspezifischen Suchkriterien (z.B. Pufferungsart für Tabellen)
können alle Objekte über die Entwicklungsklasse, über die Kurzbeschreibung
sowie über Autor und Datum der letzten Änderung gesucht werden.
Die vom Repository-Infosystem erzeugten Objektlisten sind vollständig in die
ABAP Workbench integriert. Sie ermöglichen eine direkte Navigation zu den
Pflegetransaktionen der gefundenen Objekte.

Übung 8: Abhängigkeiten bei ABAP

Dictionary Objekten
• Tabellen und Strukturen um Felder erweitern
• Das Repository Infosystem und den Verwendungsnachweis für ABAP
Dictionary Objekte bedienen
In der Mitarbeiterverwaltung sollen Informationen über die Abteilungsleiter
abgelegt werden. Außerdem soll die Änderungsprotokollierung verfeinert werden.
Die Änderungsprotokollierung an den Tabellen ZEMPLOY## und ZDEPMENT##
ist noch nicht präzise genug. Neben der Person, die die letzte Änderung
vorgenommen hat, und dem Datum dieser Änderung soll auch die Uhrzeit der
letzten Änderung vermerkt werden.
Aufgabe:
Erweitern Sie die beiden Tabellen ZEMPLOY## und ZDEPMENT## mit einem
Feld.
Notiz: Die für die Änderungsprotokollierung vorgesehenen Felder

befinden sich in der Include-Struktur ZCHANGE##. Daher sollte
das neue Feld auch in diese Struktur eingefügt werden. Über den
Include-Mechanismus wird das Feld dann automatisch in die Tabellen
ZEMPLOY## und ZDEPMENT## aufgenommen.
1. Sorgen Sie mit möglichst geringem Aufwand dafür, daß in die beiden
Tabellen ZEMPLOY## und ZDEPMENT## ein entsprechendes Feld zur
Änderungsprotokollierung aufgenommen wird. Verwenden Sie hierbei das
Datenelement S_TIME.

Include-Mechanismus wird das Feld dann automatisch in die
Tabellen ZEMPLOY## und ZDEPMENT## aufgenommen.
2. Überzeugen Sie sich, daß das Feld in die Tabellen ZEMPLOY##

und ZDEPMENT## aufgenommen wird. Kontrollieren Sie die
Aktivierungsprotokolle der beteiligten Tabellen und Strukturen.

3. Erstellen Sie eine Liste der folgenden ABAP Dictionary Objekte:

Alle Domänen mit Festwerten, deren Namen mit Z beginnt
Alle Tabellenfelder, die das Datenelement S_FNAME benutzen
Alle Tabellen des Flugmodells (Paket SAPBC_DATAMODEL), die die
Auslieferungsklasse A haben
Notiz: Alle Aufgaben können mit dem Repository Infosystem

gelöst werden.
4. Bestimmen Sie alle Programme, die die Tabelle SFLIGHT benutzen.

5. Wie heißen die von Ihren Nachbarn angelegten Datenelemente?
Hinweis: Die Datenelemente Ihrer Nachbarn können Sie entweder

durch eine Mustersuche über den Namen bestimmen (falls sich
Ihre Nachbarn konsequent an die vorgegebene Namenskonvention
gehalten haben) oder über den Letzten Änderer bestimmen.
6. Starten Sie das Programm BC430_CHECK in der Transaktion SE38. Dieses

überprüft die Korrektheit Ihrer Lösungen.

Lösung 8: Abhängigkeiten bei ABAP

Dictionary Objekten
Aufgabe:
Erweitern Sie die beiden Tabellen ZEMPLOY## und ZDEPMENT## mit einem
Feld.

Include-Mechanismus wird das Feld dann automatisch in die Tabellen
ZEMPLOY## und ZDEPMENT## aufgenommen.
1. Sorgen Sie mit möglichst geringem Aufwand dafür, daß in die beiden
Tabellen ZEMPLOY## und ZDEPMENT## ein entsprechendes Feld zur
Änderungsprotokollierung aufgenommen wird. Verwenden Sie hierbei das
Datenelement S_TIME.

Include-Mechanismus wird das Feld dann automatisch in die
Tabellen ZEMPLOY## und ZDEPMENT## aufgenommen.
a) Markieren Sie im Einstiegsbild des ABAP Dictionary Datentyp, und

geben Sie ZCHANGE## in das entsprechende Feld ein. Wählen Sie
Ändern.
b) Wählen Sie die Registerkarte Komponenten. Tragen Sie S_TIME, den
Namen für das neue Feld, in die erste freie Zeile der Komponentenliste
und in der Spalte Komponententyp ein.
c) Aktivieren Sie die Struktur.

2. Überzeugen Sie sich, daß das Feld in die Tabellen ZEMPLOY##

und ZDEPMENT## aufgenommen wird. Kontrollieren Sie die
Aktivierungsprotokolle der beteiligten Tabellen und Strukturen.
a) Unter Hilfsmittel → Aktivierungsprotokoll finden Sie das
Aktivierungsprotokoll der Struktur. Hier können Sie sehen, dass die
Tabellen ZEMPLOY## und ZDEPMENT## als abhängige Objekte
aktiviert sind und um das neue Feld erweitert wurden.
b) Verzweigen Sie im Anzeigemodus in das Pflegebild der Tabelle
ZEMPLOY## (oder ZDEPMENT##). Wählen Sie Hilfsmittel →
Tabelleninhalt → Einträge erfassen. Hier können Sie feststellen, daß
die Tabelle tatsächlich um das entsprechende Feld erweitert wurde.
3. Erstellen Sie eine Liste der folgenden ABAP Dictionary Objekte:
Alle Domänen mit Festwerten, deren Namen mit Z beginnt
Alle Tabellenfelder, die das Datenelement S_FNAME benutzen
Alle Tabellen des Flugmodells (Paket SAPBC_DATAMODEL), die die
Auslieferungsklasse A haben
Notiz: Alle Aufgaben können mit dem Repository Infosystem

gelöst werden.
a) Vom Einstiegsbild des ABAP Dictionary wählen Sie Umfeld →

Repository Infosystem. Expandieren Sie den Knoten für das ABAP
Dictionary.
b) Wählen Sie Domänen aus. Im Selektionsbild geben Sie im ersten Feld
Z* ein. Wählen Sie Alle Selektionen. Im erweiterten Selektionsbild
kreuzen Sie an Nur Domänen mit Festwerten. Mit Ausführen erzeugen
Sie die gewünschte Liste.
c) Durch zweimaliges Zurück gelangen Sie wieder auf das Eingangsbild
des Repository Infosystems. Expandieren Sie den Knoten Felder.
Wählen Sie Tabellenfelder aus. Wählen Sie Alle Selektionen und tragen
Sie S_FNAME im Feld Datenelement ein. Mit Ausführen erzeugen
Sie die gewünschte Liste.
d) Durch zweimaliges Zurück gelangen Sie wieder auf das Eingangsbild
des Repository Infosystems. Der Knoten Grundobjekte ist weiterhin
expandiert. Wählen Sie Datenbanktabellen aus.
e) Tragen Sie auf dem Selektionsbild das Paket SAPBC_DATAMODEL ein.
Wählen Sie Alle Selektionen und tragen Sie die Auslieferungsklasse A
ein. Mit Ausführen erzeugen Sie die gewünschte Liste.

4. Bestimmen Sie alle Programme, die die Tabelle SFLIGHT benutzen.

a) Gehen Sie in das Einstiegsbild des ABAP Dictionary. Wählen Sie
Datenbanktabelle und geben Sie im entsprechenden Feld SFLIGHT
ein. Wählen Sie Verwendungsnachweis.
b) Im folgenden Dialogfenster ist die Verwendung in Programmen bereits
(als einziges) angekreuzt. Mit Ausführen erzeugen Sie die gewünschte
Liste.
5. Wie heißen die von Ihren Nachbarn angelegten Datenelemente?
Hinweis: Die Datenelemente Ihrer Nachbarn können Sie entweder

durch eine Mustersuche über den Namen bestimmen (falls sich
Ihre Nachbarn konsequent an die vorgegebene Namenskonvention
gehalten haben) oder über den Letzten Änderer bestimmen.
a) Die gewünschte Liste können Sie wieder im Repository Infosystem

ABAP Dictionary erzeugen. Expandieren Sie den Knoten Grundobjekte
und wählen Sie Datenelemente aus. Zumindest im ersten Fall
(Namenskonvention) bietet es sich an, die Selektion auch noch über das
Datum der letzten Änderung einzuschränken (letzte Änderung sollte
frühestens mit Kursbeginn erfolgt sein).
b) Wählen Sie Alle Selektionen und suchen Sie den den Letzten Änderer.
Notiz: Falls Sie zwei Nachbargruppen haben, müssen Sie bei
beiden Möglichkeiten den Druckknopf Mehrfachselektion
nutzen.
6. Starten Sie das Programm BC430_CHECK in der Transaktion SE38. Dieses

überprüft die Korrektheit Ihrer Lösungen.
a) Starten Sie die Transaktion SE38 über das Eingabefeld. Starten Sie
das Programm BC430_CHECK.


Nun können Sie
unterscheiden


Nun können Sie
unterscheiden


Kapitel 6
Änderungen an Tabellen

In diesem Kapitel werden Sie erfahren, wie sie Änderungen an bestehenden
Tabellen durchführen können.

• Änderungen an Tabellen durchführen

• Einschätzen welche Auswirkungen diese Änderungen auf die Datenbank
haben
• Tabellen umsetzen
• Abgebrochene Umsetzungen fortsetzen
• Kundenfelder an SAP Standardtabellen durch Append-Strukturen
modifikationsfrei anhängen
Inhalt des Kapitels

Lektion: Änderungen an Tabellen.............................................148
Übung 9: Änderungen an Datenbanktabellen ..........................163
Übung 10: Datenbankutility (SE14) Problembehandlung (optional) .169

Kapitel 6: Änderungen an Tabellen BC430
Lektion: Änderungen an Tabellen

haben
Die Datenstrukturen einer Applikation müssen sich, genauso wie die Programme,
an geänderte Prozesse anpassen. Sie sollen für Ihr Projekt nun bestehende
Datenbanktabellen zu diesem Zwecke ändern.

BC430 Lektion: Änderungen an Tabellen
Datenbankänderungen an transparenten Tabellen
Abbildung 58: Änderungen an Tabellen
Damit ein korrekter Zugriff von ABAP Programmen auf eine Datenbanktabelle
möglich ist, muß das Laufzeitobjekt der Tabelle zur Struktur der Tabelle auf der
Datenbank konsistent sein. Bei jeder Änderung der Tabelle im ABAP Dictionary
muß somit bei der Aktivierung (bei der das Laufzeitobjekt neu geschrieben wird)
geprüft werden, ob die Datenbankstruktur der Tabelle an die geänderte ABAP
Dictionary Definition der Tabelle angepaßt werden muß.
Bei bestimmten Änderungen im ABAP Dictionary ist keine Änderung der
Datenbankstruktur notwendig. Zum Beispiel ist bei einer Änderung der
Feldreihenfolge (außer bei Schlüsselfeldern) im ABAP Dictionary keine
Änderung der Datenbankstruktur erforderlich. In diesem Fall wird einfach die
geänderte Struktur im ABAP Dictionary aktiviert und die Datenbankstruktur
bleibt unverändert.

Abbildung 59: Wie erfolgt die Strukturanpassung?
Die Anpassung der Datenbanktabelle an die geänderte Definition im ABAP

Dictionary kann auf drei verschiedene Arten erfolgen:
• Durch Löschen und Neuanlegen der Datenbanktabelle. Die auf der
Datenbank vorhandene Tabelle wird gelöscht, die inaktive Tabelle im ABAP
Dictionary aktiviert und die Tabelle auf der Datenbank neu angelegt. In der
Tabelle vorhandene Daten gehen hierbei verloren.
• Durch Änderung des Datenbank-Katalogs (ALTER TABLE). Hierbei wird
lediglich die Definition der Tabelle auf der Datenbank geändert. Vorhandene
Daten bleiben erhalten. Indizes zur Tabelle müssen aber unter Umständen
neu aufgebaut werden.
• Durch Umsetzen der Tabelle. Dies ist die aufwendigste Art der
Strukturanpassung.
Enthält die Tabelle keine Daten, so wird sie auf der Datenbank gelöscht und mit
ihrer neuen Struktur wieder angelegt. Sind Daten in der Tabelle vorhanden, so wird
versucht, die Strukturanpassung durch ALTER TABLE durchzuführen. Ist das
verwendete Datenbanksystem dazu nicht in der Lage, wird die Strukturanpassung
durch Umsetzen der Tabelle durchgeführt.

Abbildung 60: Umsetzprozeß 1
Das folgende Beispiel zeigtl die bei einer Umsetzung vom System ausgeführten
Schritte.
Ausgangssituation: Die Tabelle TAB wurde im ABAP Dictionary verändert.
Dabei wurde die Länge von Feld 3 von 60 auf 30 Stellen gekürzt.
Im ABAP Dictionary ist eine aktive (in der Feld 3 eine Länge von 60 Stellen
besitzt) und eine inaktive Version der Tabelle (in der Feld 3 noch 30 Stellen
besitzt) vorhanden.
Auf der Datenbank ist die Tabelle mit der aktiven Version angelegt, d.h. auf
der Datenbank hat Feld 3 momentan 60 Stellen. Für die Tabelle ist im ABAP
Dictionary ein Sekundärindex mit Kennung A11 definiert, der auf der Datenbank
ebenfalls angelegt wurde.
Die Tabelle enthält bereits Daten.

Schritt 1: Die Tabelle wird gegen weitere Strukturänderungen gesperrt. Falls die
Umsetzung aufgrund eines Fehlers abbricht, bleibt die Tabelle gesperrt. Dieser
Sperrmechanismus soll verhindern, daß eine neue Strukturänderung durchgeführt
wird, solange die Umsetzung noch nicht korrekt beendet ist. In einem solchen Fall
könnten Daten verlorengehen. Außerdem werden alle von der Tabelle abhängigen
Views inaktiviert und damit gesperrt.
Schritt 2: Die auf der Datenbank vorhandene Tabelle wird umbenannt. Alle
Indizes zur Tabelle werden dabei gelöscht. Der Name der neuen (temporären)
Tabelle setzt sich aus dem Präfix QCM und dem Tabellennamen zusammen. Der
Name der temporären Tabelle zur Tabelle TAB ist also QCMTAB.

Schritt 3: Die inaktive Version der Tabelle TAB wird im ABAP Dictionary
aktiviert. Dabei wird die Tabelle mit ihrer neuen Struktur unter dem Namen
QCM8TAB auf der Datenbank angelegt. Der Primärindex zur Tabelle wird
ebenfalls auf der Datenbank angelegt. Die Struktur der Datenbanktabelle
QCM8TAB entspricht also nach diesem Schritt der Struktur der aktiven Tabelle
im ABAP Dictionary. Die Datenbanktabelle enthält aber noch keine Daten.
Die Tabelle ist also während der Umsetzung unter ihrem Originalnamen nicht
auf der Datenbank vorhanden. Programme, die auf diese Tabelle zugreifen, sind
damit nicht lauffähig! Sie sollten deshalb stets sicherstellen, daß während der
Umsetzung keine Anwendungen auf die umzusetzende Tabelle zugreifen!

Schritt 4: Die Daten werden aus der Tabelle QCMTAB in die Tabelle QCM8TAB
zurückgeladen (mit MOVE-CORRESPONDING). Die Daten sind nach
diesem Schritt in beiden Tabellen vorhanden. Bei Feldverkürzungen werden
beispielsweise die überschüssigen Stellen beim Zurückladen abgeschnitten.
Da die Daten während der Umsetzung sowohl in der Tabelle QCM8TAB als auch
in der Tabelle QCMTAB vorhanden sind, entsteht bei der Umsetzung ein erhöhter
Platzbedarf. Sie sollten vor der Umsetzung größerer Tabellen deshalb prüfen, ob
im betreffenden Tablespace genügend Platz vorhanden ist.
Beim Kopieren der Daten aus der Tabelle QCMTAB in die Tabelle QCM8TAB
wird nach 16 MB ein Datenbank-Commit abgesetzt. Ein Umsetzprozeß
benötigt deshalb 16 MB Resourcen im Rollback-Segment. Die bestehende
Datenbanksperre wird beim Commit freigegeben und dann vor der Bearbeitung
des nächsten umzusetzenden Datenbereichs erneut angefordert.
Bei Schlüsselverkürzungen kann von mehreren Sätzen, die sich bzgl. des neuen
Schlüssels nicht mehr unterscheiden, nur einer zurückgeladen werden. Welcher
Satz dies ist, ist nicht vorhersehbar. Sie sollten in einem solchen Fall den
Datenbestand der Tabelle vor der Umsetzung bereinigen.

Schritt 5: Die Tabelle QCMTAB wird gelöscht.

Schritt 6: Die Tabelle QCM8TAB wird in TAB umbenannt. Die im ABAP
Dictionary zur Tabelle definierten Sekundärindizes werden neu angelegt. Die
im ersten Schritt der Umsetzung inaktivierten Views auf die Tabelle werden auf
der Datenbank wieder aktiviert.
Schritt 7: Die zu Beginn der Umsetzung gesetzte Sperre wird aufgehoben.
• Bricht die Umsetzung ab, so bleibt die Tabelle gesperrt und es wird ein
Aufsetzprotokoll geschrieben.
• Achtung: Die Tabelle existiert während der Umsetzung nicht unter ihrem
Originalnamen auf der Datenbank. Während die Umsetzung läuft, dürfen
Programme nicht auf die Tabelle zugreifen! Umsetzungen dürfen
nicht während des Produktivbetriebs laufen! Zumindest müssen alle
Anwendungen deaktiviert werden, die die umzusetzende Tabelle verwenden.
• Abgebrochene Umsetzungen müssen unbedingt bereinigt werden!
Programme, die auf die Tabelle zugreifen, laufen sonst nicht mehr korrekt.
Hierzu muß der Grund für den Abbruch (z.B. Überlauf des entsprechenden
Tablespace) ermittelt und bereinigt werden. Danach müssen Sie die
abgebrochene Umsetzung fortsetzen.

Abbildung 65: Mögliche Probleme bei Umsetzungen
Da die Daten während der Umsetzung sowohl in der Originaltabelle als auch in
der temporären Tabelle vorhanden sind, entsteht bei der Umsetzung ein erhöhter
Platzbedarf. Falls der Tablespace beim Zurückladen der Daten aus der temporären
Tabelle in die Originaltabelle überläuft, bricht die Umsetzung an dieser Stelle
ab. Sie müssen in diesem Fall den Tablespace erweitern und die Umsetzung im
Datenbank-Utility erneut starten.
Wird der Schlüssel einer Tabelle verkürzt (z.B. durch Entfernen oder Verkürzung
der Feldlänge von Schlüsselfeldern) können vorhandene Sätze der Tabelle sich
bzgl. des neuen Schlüssels nicht mehr unterscheiden. Beim Zurückladen der
Daten aus der temporären Tabelle kann nur einer dieser Sätze in die Tabelle
zurückgeladen werden. Welcher Satz das ist, ist nicht vorhersehbar. Falls Sie
bestimmte Sätze übernehmen wollen, müssen Sie die Tabelle vor der Umsetzung
bereinigen!
Bei einer Umsetzung werden die Daten mit dem ABAP Befehl
MOVE-CORRESPONDING aus der temporären Tabelle in die Datenbanktabelle
zurückkopiert. Daher sind nur solche Typänderungen möglich, die durch
MOVE-CORRESPONDING durchgeführt werden können. Bei anderen
Typänderungen, bricht die Umsetzung beim Zurückladen der Daten in die
Originaltabelle ab. In diesem Fall müssen Sie den alten Zustand vor der
Umsetzung wiederherstellen. Hierzu müssen Sie mit Datenbanktools die Tabelle
löschen, die QCM-Tabelle wieder auf den alten Namen umbenennen, das
Laufzeitobjekt rekonstruieren (im DB-Utility), die Tabellenstruktur im Dictionary
wieder auf den alten Stand bringen und abschließend die Tabelle aktivieren.

Abbildung 66: Fortsetzen abgebrochener Umsetzungen
Bricht eine Umsetzung ab, bleibt der im ersten Schritt gesetzte Sperreintrag für die
Tabelle stehen. Die Tabelle kann damit nicht mehr mit den Pflegewerkzeugen des
ABAP Dictionary (Transaktion SE11) bearbeitet werden.
Eine abgebrochene Umsetzung kann mit dem Datenbank-Utility (Transaktion
SE14) analysiert und fortgesetzt werden. Das Datenbank-Utility bietet ein
Analysetool an, mit dem Sie die Fehlerursache sowie den momentanen Zustand
aller an der Umsetzung beteiligten Tabellen ermitteln können.
Dem Objektprotokoll können Sie in der Regel die genaue Ursache des Abbruchs
entnehmen. Falls das Objektprotokoll keine Information über die Fehlerursache
liefert, müssen Sie den Syslog oder die vorhandenen Kurzdumps analysieren.
Liegt eine abgebrochene Umsetzung vor, so sind im Datenbank-Utility zwei
Optionen als Druckknöpfe eingeblendet
• Mit der Option Anpassung fortsetzen können Sie, nach Beseitigung der
Fehlerursache, die Umsetzung an der Abbruchstelle fortsetzen.
• Daneben gibt es noch die Option Tabelle entsperren. Diese Option löscht
aber lediglich den bestehenden Sperreintrag für die Tabelle. Sie sollten
für eine abgebrochene Umsetzung nie Tabelle entsperren wählen, wenn
die Daten nur noch in der temporären Tabelle vorhanden sind, also die
Umsetzung z.B. in Schritt 3 oder in Schritt 4 abgebrochen wurde.

Erweiterung von SAP-Standardtabellen
Abbildung 67: Append-Strukturen 1
Append-Strukturen erlauben es, Felder an SAP- Standardtabellen und -strukturen

anzuhängen, ohne die Definition der Tabelle selbst zu modifizieren.
Eine Append-Struktur ist eine Struktur, die genau einer Tabelle zugeordnet ist. Es
kann mehrere Append-Strukturen zu einer Tabelle geben.
Beim Aktivieren der Tabelle werden alle aktiven Append-Strukturen zur Tabelle
gesucht und deren Felder an die Tabelle angehängt. Wird eine Append-Struktur
angelegt oder geändert, so wird bei ihrer Aktivierung auch die Tabelle, der sie
zugeordnet ist, nachaktiviert und die Änderungen werden auch dort wirksam.
Wie jede andere Struktur definiert eine Append-Struktur einen Typ, der in ABAP
Programmen verwendet werden kann.
Ab Release 4.6C ist es möglich über eine Append-Struktur Fremdschlüssel
für bereits in der Tabelle vorhandene Felder zu definieren. Weiterhin können
Suchhilfen an bereits in der Tabelle vorhandene Felder angebunden werden.
Hinweis: Wird eine transparente Tabelle im Data Dictionary (DDIC)

kopiert, an die eine Append-Struktur angehängt wurde, so werden die
Felder der Append-Struktur zu gewöhnlichen Feldern der Zieltabelle.

Append-Strukturen werden vom Kunden in seinem Namensraum angelegt. Sie

sind damit gegen ein Überschreiben beim Upgrade oder Releasewechsel geschützt.
Beim Upgrade werden die neuen Versionen der Standardtabellen eingespielt. Bei
der Aktivierung der Standardtabellen werden die in aktiven Append-Strukturen
enthaltenen Felder an die neuen Standardtabellen angehängt. Beim Erweitern
einer Tabelle über Append-Strukturen ist beim Upgrade kein manueller Abgleich
(Transaktion SPDD) der Kundenmodifikationen mit der neuen SAP Version der
Tabelle notwendig.
Da die Feldreihenfolge im ABAP Dictionary seit Release 3.0 von der
Feldreihenfolge auf der Datenbank abweichen kann, ist beim Anhängen
einer Append-Struktur bzw. beim Einfügen von Feldern in eine bestehende
Append-Struktur keine Umsetzung der Datenbanktabelle notwendig.
Die notwendige Strukturanpassung erfolgt vielmehr durch Anpassen des
Datenbank-Katalogs (ALTER TABLE). Beim Aktivieren im ABAP Dictionary
wird die Definition der Tabelle verändert und das neue Feld wird an die
Datenbanktabelle angehängt.

Die neue Version der SAP Standardtabelle wird aktiviert und das neue Feld wird
an die Datenbanktabelle angehängt.
Hinweis: Beachten Sie bei Append-Strukturen bitte auch folgende Punkte:

• Für Pool- und Clustertabellen können keine Append-Strukturen
angelegt werden.
• Kommt in einer Tabelle ein langes Feld (Datentyp LCHR oder
LRAW) vor, so ist eine Erweiterung mit Append-Strukturen nicht
möglich. Denn solche langen Felder müssen in der Feldliste stets an
der letzten Position stehen (z.B. letztes Feld der Tabelle sein).
• Wenn Sie als Kunde eine SAP-Tabelle über eine Append-Struktur
erweitern, sollten die Felder in dieser Append-Struktur im
Kundennamensraum für Felder liegen, d.h. mit YY oder ZZ
beginnen. Damit werden Namenskollisionen mit von SAP in die
Standardtabelle eingefügten neuen Feldern vermieden.
• Wenn Sie als Partner einen eigenen reservierten Namensraum für ihre
Entwicklungen haben, sollten Sie die Felder in Append-Strukturen
stets in diesem Namensraum wählen.

Abbildung 70: Erweiterung von Tabellen
Strukturen und Tabellen, die von SAP im ABAP Dictionary definiert wurden,
können nachträglich durch Kunden auf folgende Weise erweitert werden:
Customizing-Includes
Bei dieser Variante sind bereits bestimmte Stellen innerhalb einer Struktur
oder Tabelle für Erweiterungen reserviert. Die zugehörigen Includes werden
jedoch erst vom Kunden angelegt.
Appends
Bei dieser Variante werden beliebige Felder ohne vorherige Reservierung an
das Ende von Strukturen oder Tabellen angehängt.
Achtung: Probleme durch Strukturerweiterungen

Von Erweiterungen dieser Art sind nicht nur die erweiterten Strukturen
und Tabellen selbst betroffen, sondern auch alle abhängigen Strukturen,
welche die Erweiterung als Include oder Unterstruktur übernehmen. So
können zum Beispiel Erweiterungen mittels Append, die sich bei der
Ausgangsstruktur nur am Ende auswirken, bei abhängigen Strukturen zu
Verschiebungen auch innerhalb dieser Strukturen führen
In Programmen ohne aktive Unicodeprüfung können
Strukturerweiterungen vor allem bei Typprüfungen und im
Zusammenhang mit tiefen Strukturen zu Syntax- und Laufzeitfehlern
führen. In Programmen mit aktiver Unicodeprüfung sind darüber hinaus

Zuweisungen, Operandenprüfungen und Zugriffe mit Offset und Länge

betroffen. Problematisch sind hier Änderungen, wenn zum Beispiel in eine
rein zeichenartige Struktur numerische oder tiefe Komponenten eingefügt
werden und dadurch die Struktur ihren zeichenartigen Charakter verliert.
Erweiterungen sind auch deshalb problematisch, weil die Fragmentsicht
verändert wird und darauf aufbauende Prüfungen bei Zuweisungen und
Vergleichen beeinflusst werden.
Damit die Auswirkungen von Strukturerweiterungen überhaupt erkennbar

sind, können Strukturen und Tabellen im ABAP Dictionary unter Zusätze ->
Erweiterungskategorie nach folgenden Schema klassifiziert werden:
Stufe Kategorie Bedeutung

1 Nicht klassifiziert Die Struktur hat keine Erweiterungskate-
gorie
2 Nicht erweiterbar Die Struktur darf nicht erweitert werden
3 Erweiterbar und Alle Strukturkomponenten und deren
zeichenartig Erweiterungen müssen zeichenartig sein
4 Erweiterbar und Die Struktur und deren Erweiterung darf
zeichenartig oder keine tiefen Datentypen enthalten
numerisch
5 Beliebig erweiterbar Die Struktur und deren Erweiterung darf
Komponenten enthalten, deren Datentyp
beliebig ist
Als zeichenartig werden an dieser Stelle die Elemetartypen C, D, N und T

bezeichnet, als numerisch die Elementartypen F, I, P und X. Nicht unterstützt
werden die tiefen Typen STRING und XSTRING.
Bei Strukturen und Tabellen mit Includes oder Unterstrukturen dürfen die
Erweiterungskategorien der Includes und Unterstrukturen nicht größer als
diejenigen der Ausgangsstruktur sein. Enthält die Ausgangsstruktur zum
Beispiel ein Include der Stufe 4, dann sind für die Ausgangsstruktur die darüber
hinausgehenden Stufen 2 und 3 nicht erlaubt.
Strukturerweiterungen im Dictionary können sich auch auf interne Strukturen in
ABAP-Programmen auswirken, wenn Dictionary-Strukturen im Quelltext als
Include oder Unterstruktur verwendet werden. Bei der ABAP-Programmprüfung
werden diese Abhängigkeiten implizit berücksichtigt. Dies schließt auch nicht
klassifizierte Strukturen ein, die erweiterbare Includes oder Unterstrukturen
enthalten.

Übung 9: Änderungen an Datenbankta-

bellen
• Änderungen an bestehenden Objekten durchführen
• Standardtabellen über Append-Strukturen modifikationsfrei erweitern
Das ursprüngliche Design der Mitarbeiterverwaltung ist nach einigen
organisatorischen Änderungen in den Fluggesellschaften nicht mehr angemessen.
Das Design der Tabelle ZFLCREW## ist nicht mehr angemessen. Das Feld für
die Rolle des Mitarbeiters während des Fluges ist zu lang.
Aufgabe 1:
Verkürzen Sie ein Feld in der Tabelle ZFLCREW##.
1. Reduzieren Sie die Feldlänge auf 15 Stellen.
Notiz: Legen Sie hierzu ein eigenes Datenelement ZROLE## an,

und ersetzen Sie das vorhandene Datenelement durch das neu
angelegte. Verwenden Sie bei der Definition des Datenelements
ZROLE## keine Domäne, sondern geben Sie Datentyp und Länge
direkt bei der Definition des Datenelements an. Aktivieren Sie nun
Ihre Tabelle.
Verzweigen Sie im Änderungsmodus in das Pflegebild der Tabelle

ZFLCREW##.
2. Lassen Sie sich das Aktivierungsprotokoll anzeigen. Dort werden Sie darauf
hingewiesen, daß die vorgenommene Feldverkürzung eine Umsetzung der
Tabelle ZFLCREW## erforderlich macht.

Aufgabe 2:
Die Mitarbeiter mit Verwaltungsfunktionen oder Wartungsfunktionen haben
ihren Arbeitsplatz auf einem Flughafen. Zeichnen Sie in Tabelle ZEMPLOY##
Informationen auf, wie Sie diese Mitarbeiter erreichen können: eine
Telefonnummer, unter der Sie Wartungspersonal auf dem Flughafen erreichen,
und ein Büro, in dem die Verwaltungsmitarbeiter arbeiten.
1. Legen Sie eine Append-Struktur zur Tabelle ZEMPLOY## an, die die
folgenden Informationen enthält:
Feld Datenelement
ZZFlughafen S_AIRPORT
ZZBueronummer S_BUREAUNO
ZZTelefon S_TELNO
Notiz: Die Feldnamen in einer Append-Struktur müssen im

Kundennamensraum für Felder liegen. Die Feldnamen müssen
deshalb mit ZZ oder YY beginnen.
Aufgabe 3:
Legen Sie für ein Feld Flughafen aus der Append-Struktur einen geeigneten
Fremdschlüssel an.
1. Definieren Sie den Fremdschlüssel in der Pflege der Append-Struktur.
Hinweis: Die Tabelle aller Flughäfen heißt SAIRPORT. Für eine

vollständige Definition des Fremschlüssels müssen Sie auch ein Feld
der anhängenden Tabelle (ZEMPLOY##) prüfen.
Aus der Pflege der Tabelle ZEMPLOY## wählen Sie Springen →

Append-Struktur.
2. Starten Sie das Programm BC430_CHECK mit der Transaktion SE38 . Das
Programm überprüft die Korrektheit Ihrer Lösungen.

Lösung 9: Änderungen an
Datenbanktabellen
Aufgabe 1:
Verkürzen Sie ein Feld in der Tabelle ZFLCREW##.
1. Reduzieren Sie die Feldlänge auf 15 Stellen.
Notiz: Legen Sie hierzu ein eigenes Datenelement ZROLE## an,

und ersetzen Sie das vorhandene Datenelement durch das neu
angelegte. Verwenden Sie bei der Definition des Datenelements
ZROLE## keine Domäne, sondern geben Sie Datentyp und Länge
direkt bei der Definition des Datenelements an. Aktivieren Sie nun
Ihre Tabelle.
Verzweigen Sie im Änderungsmodus in das Pflegebild der Tabelle

ZFLCREW##.
a) Überschreiben Sie in der Spalte Feldtyp das Datenelement
SEMP_ROLE durch den Namen ihres Datenelements ZROLE##.
Sichern Sie die Änderung.
b) Wählen Sie den Namen ZROLE## aus. Bestätigen Sie im folgenden
Dialogfenster, daß Sie das Datenelement anlegen möchten.
c) Im Pflegebild für Datenelemente erfassen Sie eine Kurzbeschreibung.
d) Wählen Sie das Register Definition. Markieren Sie Eingebauter
Datentyp. Geben Sie CHAR in das Feld Datentyp, 15 in das Feld
Länge, und 0 in das Feld Dezimalstellen ein.
e) Pflegen Sie auf der Registerkarte Feldbezeichner die Texte zum
Datenelement.
f) Aktivieren Sie das Datenelement.
2. Lassen Sie sich das Aktivierungsprotokoll anzeigen. Dort werden Sie darauf
hingewiesen, daß die vorgenommene Feldverkürzung eine Umsetzung der
Tabelle ZFLCREW## erforderlich macht.
a) Navigieren Sie in die Tabellenpflege zurück.
b) Navigieren Sie mit Hilfsmittel → Datenbank-Utility in das
Datenbank-Utility.
c) Wählen Sie Aktivieren und Datenbank anpassen. Bestätigen Sie die
folgende Sicherheitsabfrage. Das System führt nun die notwendige
Umsetzung durch.

Aufgabe 2:
Die Mitarbeiter mit Verwaltungsfunktionen oder Wartungsfunktionen haben
ihren Arbeitsplatz auf einem Flughafen. Zeichnen Sie in Tabelle ZEMPLOY##
Informationen auf, wie Sie diese Mitarbeiter erreichen können: eine
Telefonnummer, unter der Sie Wartungspersonal auf dem Flughafen erreichen,
und ein Büro, in dem die Verwaltungsmitarbeiter arbeiten.
1. Legen Sie eine Append-Struktur zur Tabelle ZEMPLOY## an, die die
folgenden Informationen enthält:
Feld Datenelement
ZZFlughafen S_AIRPORT
ZZBueronummer S_BUREAUNO
ZZTelefon S_TELNO
Notiz: Die Feldnamen in einer Append-Struktur müssen im

Kundennamensraum für Felder liegen. Die Feldnamen müssen
deshalb mit ZZ oder YY beginnen.
a) Verzweigen Sie im Anzeigemodus in das Pflegebild der Tabelle

ZEMPLOY##.
b) Wählen Sie Springen → Append-Struktur.
c) Tragen Sie im folgenden Dialogfenster den gewünschten Namen für die
Append-Struktur ein. Dieser muß den üblichen Namenskonventionen
genügen. Wählen Sie Weiter.
d) Sie verzweigen damit in das Pflegebild der Append-Struktur. Die
Pflege verhält sich völlig analog zur Pflege einer Struktur.
e) Erfassen Sie eine Kurzbeschreibung, und nehmen Sie die Felder
ZZFlughafen, ZZBueronummer und ZZTelefonnummer mit den
genannten Datenelementen auf.
f) Aktivieren Sie die Append-Struktur. Lassen Sie sich das
Aktivierungsprotokoll über Springen → Aktivierungsprotokoll
anzeigen.
g) Die Tabelle ZEMPLOY## wird automatisch angepasst, wenn Sie
die Append-Struktur aktivieren. Die neuen Felder werden auf der
Datenbank an die bereits vorhandenen Felder angehängt.

Aufgabe 3:
Legen Sie für ein Feld Flughafen aus der Append-Struktur einen geeigneten
Fremdschlüssel an.
1. Definieren Sie den Fremdschlüssel in der Pflege der Append-Struktur.
Hinweis: Die Tabelle aller Flughäfen heißt SAIRPORT. Für eine

vollständige Definition des Fremschlüssels müssen Sie auch ein Feld
der anhängenden Tabelle (ZEMPLOY##) prüfen.
Aus der Pflege der Tabelle ZEMPLOY## wählen Sie Springen →

Append-Struktur.
a) Stellen Sie den Cursor auf das Feld Flughafen. Wählen Sie die
Schlüsselikone. Übernehmen Sie den Systemvorschlag.
b) Sie gelangen auf das Pflegebild des Fremdschlüssels. Die Prüftabelle
und die Feldzuordnungen sind aufgrund des Systemvorschlags schon
gefüllt. Geben Sie eine geeignete Kurzbeschreibung ein.
Notiz: Der Fremdschlüssel kann allein mit der Append-Struktur
nicht vollständig angegeben werden, da der Schlüssel der
Prüftabelle SAIRPORT sowohl ein Mandantenfeld als auch ein
Flughafenkürzel enthält, während die Append-Struktur kein
Mandantenfeld enthält. Vergewissern Sie sich davon, dass
bei der Generierung aus dem Vorschlag das Mandantenfeld
tatsächlich aus der appendierenden Tabelle herangezogen wird.
c) Wählen Sie als Art der Fremdschlüsselfelder keine

Schlüsselfelder/-kandidaten (da das Feld Flughafen kein Schlüsselfeld
der Tabelle ZEMPLOY## ist) und als Kardinalität C (da nicht jeder
Mitarbeiter einem Flughafen zugeordnet ist) bis CN (da mehrere
Mitarbeiter dem gleichen Flughafen zugeordnet sein können).
d) Wählen Sie Übernehmen und aktivieren Sie danach die
Append-Struktur.
2. Starten Sie das Programm BC430_CHECK mit der Transaktion SE38 . Das
Programm überprüft die Korrektheit Ihrer Lösungen.
a) Starten Sie das Programm BC430_CHECK über die Transaktion SE38 .


Übung 10: Datenbankutility (SE14)

Problembehandlung (optional)
• auf Fehler bei der Umsetzung von Tabellen reagieren.
Durch Umsetzungen von bestehenden DB-Tabellen, können Daten verloren gehen
oder andere Probleme auftreten. Sie sollten für diesen Fall die Umsetzung wieder
Rückgägig machen können.
Aufgabe:
Sie sollen verhindern, daß Daten durch eine fehlerhafte Umsetzung verloren gehen.
1. Datenverluste vermeiden.
Achtung: Vor dem weiteren Vorgehen, müssen Sie auf jeden

Fall den Inhalt der Mitarbeiter- und der Abteilungstabelle in
entsprechende temporäre Tabellen kopieren.
2. Ändern Sie die Domäne für die Abteilungen von der Länge 4 auf die die
Länge 2 und aktivieren Sie die Domäne.
3. Lassen Sie auch die abhängigen Objekte (Tabellen) aktivieren.
4. Lassen Sie sich das Protokoll anzeigen.
Notiz: Obwohl in der Meldung zur Aktivierung nur Warnungen

erwähnt waren, finden Sie im Protokoll rot markierte
Fehlermeldungen und den Hinweis, daß die Tabellen umgesetzt
werden müssen.
5. Setzen Sie zunächst die Tabelle der Abteilungen mit Hilfe der Transaktion
SE14 um.
6. Setzen Sie nun auch die Tabelle der Mitarbeiter um und prüfen Sie den Inhalt
der Tabelle.
7. Sollte die Umsetzung fehlschlagen, versuchen Sie die Umsetzung wieder
rückgängig zu machen.

Lösung 10: Datenbankutility (SE14)

Problembehandlung (optional)
Aufgabe:
Sie sollen verhindern, daß Daten durch eine fehlerhafte Umsetzung verloren gehen.
1. Datenverluste vermeiden.
Achtung: Vor dem weiteren Vorgehen, müssen Sie auf jeden

Fall den Inhalt der Mitarbeiter- und der Abteilungstabelle in
entsprechende temporäre Tabellen kopieren.
a) Kopieren Sie die beiden Tabellen für die Mitarbeiter und die
Abteilungen über die SE11 oder die SE80.
b) Kopieren Sie den Inhalt der Tabellen mit Hilfe eines ABAP-Reports
(ABAP-Befehl INSERT)
c) Ändern Sie Ausserdem die Typdefinition für das Tabellenfeld der
Abteilung in beiden Tabellen und verwenden Sie den Datentyp CHAR
4 als Eingebauter Typ. Somit werden die Temporären Tabellen
unabhängig von der kommenden Änderung der Domäne.
2. Ändern Sie die Domäne für die Abteilungen von der Länge 4 auf die die
Länge 2 und aktivieren Sie die Domäne.
a) Gehen Sie wie in den vorangegangenen Übungen vor.
3. Lassen Sie auch die abhängigen Objekte (Tabellen) aktivieren.
a) Bestätigen Sie den folgenden Dialog mit der Schaltfläche Weiter.
.
4. Lassen Sie sich das Protokoll anzeigen.
Notiz: Obwohl in der Meldung zur Aktivierung nur Warnungen

erwähnt waren, finden Sie im Protokoll rot markierte
Fehlermeldungen und den Hinweis, daß die Tabellen umgesetzt
werden müssen.

5. Setzen Sie zunächst die Tabelle der Abteilungen mit Hilfe der Transaktion
SE14 um.
a) Geben Sie im Einstiegsbild des Datenbankutilities den Tabellennamen
ein.
b) Betätigen Sie die Schaltfläche Bearbeiten.
c) Starten Sie den Umsetzprozess mit der Schaltfläche Aktivieren und
Datenbank anpassen.
Notiz: Der Umsetzprozess endete ohne Fehlermeldung. Sie
sollten sich aber trotzdem das Protokoll genauer ansehen und
die Meldungen auswerten.
6. Setzen Sie nun auch die Tabelle der Mitarbeiter um und prüfen Sie den Inhalt
der Tabelle.
a) Geben Sie im Einstiegsbild des Datenbankutilities (SE14)den
Tabellennamen ein.
b) Betätigen Sie die Schaltfläche Bearbeiten.
c) Starten Sie den Umsetzprozess mit der Schaltfläche Aktivieren und
Datenbank anpassen.
Achtung: Der Umsetzprozess endete ohne Fehlermeldung.

Sie sollten sich aber trotzdem das Protokoll genauer ansehen
und die Meldungen auswerten.
7. Sollte die Umsetzung fehlschlagen, versuchen Sie die Umsetzung wieder

rückgängig zu machen.
a) Im Protokoll der Umsetzung ist höchst wahrscheinlich vermerkt, daß
im Primärschlüssel Dublikate aufgetaucht sind.
Ergebnis
Diskutieren Sie mit dem Referenten die Möglichkeiten, Ihre Daten wieder in den
Ursprungszustand zu versetzen.


Nun können Sie
haben


Nun können Sie
haben


Kapitel 7
Views und Pflegedialoge

In diesem Kapitel werden Sie die Möglichkeit kennen lernen, Views und
Pflegedialoge im SAP-System zu definieren.

• beurteilen, wie ein View durch Join, Projektion und Selektion aus Tabellen
erzeugt wird
• Datenbank-Views anlegen
• den Zusammenhang zwischen Fremdschlüsseln und Joinbedingungen
herstellen
• Views in Programmen zur Datenselektion einsetzen
• die Einsatzmöglichkeiten von Pflege-Views beurteilen
• den Unterschied zwischen Inner Join und Outer Join erkennen
• einen Pflegeview anlegen
• einfache Pflegedialoge erzeugen
• komplexe Pflegedialoge erzeugen
Inhalt des Kapitels

Lektion: Views ...................................................................176
Übung 11: Views............................................................187
Lektion: Pflegedialoge..........................................................192
Übung 12: Pflegedialoge ..................................................201

Kapitel 7: Views und Pflegedialoge BC430
Lektion: Views

erzeugt wird
herstellen
Um in Ihren Anwendungen vereinfachtes ABAP-Coding zu erzeugen, sollen Sie
Views als Ausschnitt oder als Kombination von Tabellen erzeugen.
Eingeschränke oder erweiterte Sichten (Views) auf

Datenbanktabellen
Abbildung 71: Wozu braucht man Views?

BC430 Lektion: Views
Daten zu einem Anwendungsobjekt sind oft über mehrere Datenbanktabellen

verteilt. Daher bieten Datenbanksysteme die Möglichkeit, anwendungsspezifische
Sichten auf Daten in mehreren Tabellen zu definieren. Diese
anwendungsspezifischen Sichten werden als Views bezeichnet.
Daten aus mehreren Tabellen können über einen View in sinnvoller Weise
(Join) zusammengestellt werden. Es ist auch möglich, nicht interessierende
Informationen auszublenden (Projektion) oder nur Datensätze anzuzeigen, die
bestimmten Bedingungen genügen (Selektion).
Die Daten eines Views können genau wie die Daten einer Tabelle in der
erweiterten Tabellenpflege angezeigt werden.
Abbildung 72: Aufbau eines Views - Ausgangssituation
Der Aufbau eines Views und die Datenselektion mit Hilfe dieses Views wird in
einem Beispiel gezeigt.
Gegeben sind die beiden Tabellen SCARR und SFLIGHT. Die Tabelle SCARR
enthält zwei Einträge, die Tabelle SFLIGHT vier Einträge.
Zuerst werden die Tabellen aneinander gehängt. Daraus ergibt sich das
Kreuzprodukt der zwei Tabellen, in dem jeder Satz der Tabelle SCARR mit jedem
Satz der Tabelle SFLIGHT kombiniert wird.

Abbildung 73: Aufbau eines Views - Join-Bedingung
Das gesamte Kreuzprodukt ist in der Regel keine sinnvolle Selektion. Deshalb
muß das Kreuzprodukt über eine Join-Bedingung eingeschränkt werden. Die
Join-Bedingung beschreibt, wie die Sätze der beiden Tabellen zusammenhängen.
In unserem Beispiel soll das Feld CARRID von SCARR mit dem Feld CARRID
von SFLIGHT verglichen werden. Die Join-Bedingung lautet also:
SCARR-CARRID = SFLIGHT-CARRID
Durch diese Join-Bedingung werden alle Sätze aus dem Kreuzprodukt entfernt,
bei denen der Eintrag in Feld 1 nicht mit dem Eintrag aus Feld 3 identisch ist. Die
Spalte für Feld 3 im View wird damit überflüssig.

Abbildung 74: Aufbau eines Views - Feldauswahl (Projektion)
Oft sind nicht alle Felder der an einem View beteiligten Tabellen von Interesse.
Die in den View eingehende Menge von Feldern kann explizit bestimmt werden
(Projektion).
In unserem Beispiel ist das Feld PLANETYPE nicht von Interesse und wird
deshalb ausgeblendet.

Abbildung 75: Aufbau eines Views - Selektionsbedingung
Über eine Selektionsbedingung kann die Menge der Sätze, die über den View
angezeigt werden können, weiter eingeschränkt werden.
In unserem Beispiel sollen nur solche Sätze über den View angezeigt werden, die
in Feld CARRID den Wert DL haben.
Eine Selektionsbedingung kann also auch über ein nicht im View enthaltenes
Feld formuliert werden.

Abbildung 76: Wie werden Tabellen (Basistabellen) zu Views verknüpft?
Beispiel: Reisebüros müssen in vielen Situationen prüfen, welcher Kunde auf

welchen Flügen gebucht ist. Die entsprechenden Daten sind auf mehrere Tabellen
verteilt:
SCUSTOM: Kundendaten, wie z.B. Kundennr., Name, Anschrift

SBOOK: Buchungsdaten, wie z.B. Fluggesellschaft, Flugnummer,
Passagier (Kundennr.)
SPFLI: Flugdaten, wie z.B. Abflugstadt, Ankunftsstadt
Für die erforderliche Sicht auf die Buchungsdaten muß ein View auf die Tabellen
SCUSTOM, SBOOK und SPFLI angelegt werden.
Die Join-Bedingungen lauten in diesem Fall:
• SBOOK-MANDT = SCUSTOM-MANDT
• SBOOK-CUSTOMID = SCUSTOM-ID
• SPFLI-MANDT = SBOOK-MANDT
• SPFLI-CARRID = SBOOK-CARRID
• SPFLI-CONNID = SBOOK-CONNID

Abbildung 77: Struktur des Views
Für einen Kunden erhält man die zugehörigen Buchungen, indem man die
zugehörigen Sätze zum Schlüssel MANDT und CUSTOMID aus der Tabelle
SBOOK selektiert.
Für jede Buchung aus der Tabelle SBOOK erhält man die Flugdaten aus der
Tabelle SPFLI, indem man den zugehörigen Satz zum Schlüssel MANDT,
CARRID und CONNID aus der Tabelle SPFLI selektiert.
Falls man nur die nicht stornierten Buchungen eines Kunden über den View
anzeigen will, kann man dies über die folgende Selektionsbedingung erreichen:
• SBOOK-CANCELED <> X
Die Join-Bedingungen können auch aus den bestehenden Fremdschlüssel-
beziehungen abgeleitet werden. In der Pflegetransaktion wird diese Übernahme
der Join-Bedingungen aus den bereits vorhandenen Fremdschlüsseln unterstützt.
Als Feldnamen im View werden in der Regel die Feldnamen der zugrundeliegenden
Tabellenfelder übernommen. Es kann im View aber ein anderer Feldname
gewählt werden. Dies ist z.B. notwendig, wenn zwei gleichnamige Felder aus
unterschiedlichen Tabellen in den View aufgenommen werden sollen. In diesem
Fall muß für eines der beiden Felder im View ein anderer Name als in der Tabelle
gewählt werden.

Abbildung 78: Datenselektion über Views
Sie können die Join-Bedingung auch direkt in OPEN-SQL formulieren.

Es wäre auch möglich das gleiche Ergebnis über einen Inner Join zu erzielen:
SELECT C~CARRID C~CARRNAME P~CONNID P~CITYFROM P~CITYTO

F~FLDATE F~SEATSMAX F~SEATSOCC
INTO TABLE ITAB_FLIGHTS
FROM ( SCARR AS C INNER JOIN SPFLI AS P
ON C~CARRID = P~CARRID )
INNER JOIN SFLIGHT AS F
ON F~CARRID = P~CARRID
AND F~CONNID = P~CONNID
WHERE CITYFROM IN SO_CITYF
AND CITYTO IN SO_CITYT
AND SEATSOCC < F~SEATSMAX
ORDER BY C~CARRID P~CONNID F~FLDATE.
Ein View hat Typcharakter und kann in Programmen wie alle anderen Typen
angesprochen und zur Definition von Datenobjekten verwendet werden.

Abbildung 79: Inner Join und Outer Join
Die Datenmenge, die über einen View selektiert werden kann, hängt entscheidend
davon ab, ob der View einen Inner Join oder einen Outer Join realisiert.
Beim Inner Join erhält man nur diejenigen Sätze, zu denen in allen der am View
beteiligten Tabellen ein Eintrag existiert. Beim Outer Join werden dagegen auch
solche Sätze selektiert, bei denen in einigen der am View beteiligten Tabellen kein
entsprechender Eintrag vorhanden ist.
Die über einen Outer Join ermittelte Treffermenge kann also eine echte Obermenge
der über einen Inner Join ermittelten Treffermenge sein.
Datenbank-Views realisieren einen Inner Join. Man erhält also nur solche Sätze,
zu denen in allen am View beteiligten Tabellen ein Eintrag vorhanden ist.
Pflege-Views realisieren einen Outer Join.

Abbildung 80: Datenbank-View
Ein Datenbank-View wird im ABAP Dictionary definiert und beim Aktivieren

automatisch auf der Datenbank angelegt. Zugriffe auf einen Datenbank-View
werden von der Datenbank-Schnittstelle direkt an die Datenbank weitergegeben.
Die Datenselektion erfolgt durch die Datenbanksoftware.
Wird die Definition eines Datenbank-Views im ABAP Dictionary verändert, so
muß der auf der Datenbank angelegte View an diese Änderung angepaßt werden.
Da ein View keine Daten enthält, erfolgt diese Anpassung durch Löschen der
alten Viewdefinition und erneutes Anlegen des Views mit seiner neuen Definition
im ABAP Dictionary.
Der Pflegestatus legt fest, ob auf den View nur lesende oder auch schreibende
Zugriffe erlaubt sind. Falls ein Datenbank-View über mehr als eine Tabelle
definiert wurde, sind über diesen View nur lesende Zugriffe erlaubt.
Die über einen Datenbank-View gelesenen Daten können gepuffert werden. Die
Pufferung der Viewdaten verhält sich völlig analog zur Pufferung von Tabellen.
Über die technischen Einstellungen eines Datenbank-Views kann gesteuert
werden, ob die Pufferung der Viewdaten erlaubt ist und wie diese vorgenommen
werden soll. Es gibt hier die gleichen Einstellungsmöglichkeiten (Pufferungsarten)
wie bei der Pufferung von Tabellen. Die gepufferten Viewdaten werden invalidiert,
sobald die Daten in einer der Basistabellen des Views verändert werden.

Abbildung 81: Dynamisches Einbinden von Tabellenfeldern in

Datenbank-Views
Für Datenbank-Views ist es möglich, ganze Tabellen in den View zu inkludieren.

In diesem Fall werden alle Felder der inkludierten Tabelle zu Feldern des Views
(wobei es möglich ist, bestimmte Felder explizit herauszunehmen). Werden in die
Tabelle neue Felder aufgenommen oder vorhandene Felder gelöscht, so wird
der View automatisch an diese Änderung angepaßt. Ein neues bzw. gelöschtes
Feld wird also in diesem Fall automatisch in den View aufgenommen bzw. aus
dem View gelöscht.
Wird eine in einen View inkludierte Tabelle durch eine Append-Struktur erweitert,
so werden die über die Append-Struktur angefügten Felder automatisch in den
View übernommen.
Um eine Tabelle in einen View zu inkludieren, müssen Sie in der Viewpflege im
Feld Viewfeld das Zeichen „*“, im Feld Tabelle den Namen der zu inkludierenden
Tabelle und im Feld Feldname erneut das Zeichen „*“ eintragen.
Falls Sie ein Feld der inkludierten Tabelle nicht in den View aufnehmen möchten,
müssen Sie im Feld Viewfeld ein „-“, im Feld Tabelle den Namen der inkludierten
Tabelle und im Feld Feldname den Namen des herauszunehmenden Feldes
eintragen.
Über einen Append-View können (ab Release 4.6C) Felder aus den Basistabellen
eines Datenbank-Views modifikationsfrei in den View aufgenommen werden.
Dies ist analog zur Erweiterung einer Tabelle durch eine Append-Struktur. Ein
Append-View ist genau einem Datenbank-View zugeordnet. Es können aber
mehrere Append-Views zu einem Datenbank-View angelegt werden.

Übung 11: Views

• Views anlegen
• Joinbedingungen definieren
• Datenbank-Views puffern
Die für einen Mitarbeiter vorhandenen Daten sind (dem relationalen Datenmodell
entsprechend) auf mehrere Tabellen der Mitarbeiterverwaltung verteilt. Für
manche Aufgaben müssen die entsprechenden Sachbearbeiter aber eine
übergreifende Sicht auf diese Daten haben. In dieser Übung sollen die
entsprechenden Sichten durch Anlegen von Views realisiert werden.
Für die Zusammenstellung der Mannschaft eines Fluges muß das fliegende
Personal (alle Piloten und Flugbegleiter) selektiert werden. Eventuell können
nicht alle Daten in Tabelle ZEMPLOY## beim Zugriff angezeigt werden; so
kann etwa der Mitarbeiter, der die Teams zusammenstellt, nicht die Gehälter der
Crew-Mitglieder sehen. Weiterhin soll für Nachfragen noch die Telefonnummer
der Abteilung des Mitarbeiters ausgegeben werden.
Aufgabe:
1. Legen Sie einen entsprechenden Datenbank-View ZEMPFLY## an, der
die Anforderungen erfüllt. Es sollen folgende Informationen zu einem
Mitarbeiter angezeigt werden:
Mandant
Fluggesellschaft
Personalnummer
Vorname
Nachname
Telefonnummer der Abteilung
Abteilungskürzel
Notiz: Der View sollte eine Sicht auf die Daten in den Tabellen
ZEMPLOY## und ZDEPMENT## ermöglichen. Der View sollte
Daten über Mitarbeiter (aus Tabelle ZEMPLOY##) und über
Abteilungen (aus Tabelle ZDEPMENT##) anzeigen.

2. Nehmen Sie Felder aus den Tabellen in den View über.

3. Sorgen Sie dafür, daß nur fliegendes Personal über den View selektiert werden
kann. Definieren Sie diese Einschränkung über eine Selektionsbedingung.
Es wird vermutlich häufig auf die Daten über den View zugegriffen. Die
selektierten Daten sollten deshalb zur Steigerung der Performance gepuffert
werden. Wählen Sie als Pufferungsart die vollständige Pufferung.
4. Puffern Sie den View.

Lösung 11: Views

Aufgabe:
1. Legen Sie einen entsprechenden Datenbank-View ZEMPFLY## an, der
die Anforderungen erfüllt. Es sollen folgende Informationen zu einem
Mitarbeiter angezeigt werden:
Mandant
Fluggesellschaft
Personalnummer
Vorname
Nachname
Telefonnummer der Abteilung
Abteilungskürzel
Notiz: Der View sollte eine Sicht auf die Daten in den Tabellen
ZEMPLOY## und ZDEPMENT## ermöglichen. Der View sollte
Daten über Mitarbeiter (aus Tabelle ZEMPLOY##) und über
Abteilungen (aus Tabelle ZDEPMENT##) anzeigen.
a) Markieren Sie im Einstiegsbild des ABAP Dictionary den Objekttyp

View, geben Sie den Objektnamen ZEMPFLY## ein und wählen Sie
Anlegen.
b) Es erscheint ein Dialogfenster, in dem Sie den Viewtyp wählen müssen.
Markieren Sie Datenbank-View und wählen Sie Auswählen.
c) Geben Sie auf dem Folgebild einen Kurztext ein.
d) Geben Sie zuerst ZEMPLOY## im Feld Tabellen ein.
e) Wählen Sie Beziehungen. Alle Fremdschlüsselbeziehungen von Tabelle
ZEMPLOY## zu anderen Tabellen werden aufgeführt. Markieren
Sie die Beziehung zur Tabelle ZDEPMENT## und wählen Sie
Übernehmen.
Damit werden die Join-Bedingungen aus dem Fremdschlüssel
übernommen.
f) Lassen sie sich in einem anderen Modus den Fremdschlüssel zwischen
beiden Tabellen anzeigen, und machen Sie sich klar, welche Beziehung
zwischen dem Fremdschlüssel und den Join-Bedingungen besteht.
g)

2. Nehmen Sie Felder aus den Tabellen in den View über.

a) Wählen Sie View-Felder aus.
b) Wählen Sie Tabellenfelder. Markieren Sie im folgenden Dialogfenster
die Tabelle ZEMPLOY## und wählen Sie Auswählen.
c) Es werden alle Felder der Tabelle ZEMPLOY## aufgelistet. Markieren
Sie die Felder Mandant, Fluggesellschaft, Personalnummer, Vorname
und Nachname. Wählen Sie Übernehmen. Die Felder werden damit in
den View aufgenommen.
d) Wählen Sie erneut Tabellenfelder. Wählen Sie im Dialogfenster die
Tabelle ZDEPMENT## und nehmen Sie die Felder Telefonnummer der
Abteilung und Abteilungskürzel wie oben beschrieben in den View auf.
e) Wählen Sie Selektionsbedingungen.
f)
3. Sorgen Sie dafür, daß nur fliegendes Personal über den View selektiert werden
kann. Definieren Sie diese Einschränkung über eine Selektionsbedingung.
Es wird vermutlich häufig auf die Daten über den View zugegriffen. Die
selektierten Daten sollten deshalb zur Steigerung der Performance gepuffert
werden. Wählen Sie als Pufferungsart die vollständige Pufferung.
a) Die Einschränkung, ob ein Mitarbeiter zum fliegenden Personal gehört,
ist im Feld Bereich in der Tabelle ZEMPLOY## enthalten. Tragen Sie
dieses in die Spalten Tabelle und Feldname ein.
b) Mitarbeiter des fliegenden Personals werden durch den Wert F im Feld
Bereich identifiziert. Tragen Sie deshalb EQ in die Spalte Operator und
'F' in die Spalte Vergleichswert (inklusive Hochkommas) ein.
c)
4. Puffern Sie den View.
a) Wählen Sie Springen → Technische Einstellungen. Sie gelangen in die
Pflege der technischen Einstellungen des Views. Das Bild ist bis auf
einige Attribute, die bei Views sinnlos sind und deshalb ausgeblendet
wurden, völlig analog zum entsprechenden Pflegebild bei Tabellen.
b) Markieren Sie Pufferung eingeschaltet und vollständig gepuffert.
c) Sichern Sie die technischen Einstellungen, und kehren Sie in die Pflege
des Views zurück.
d) Aktivieren Sie den View.


Nun können Sie
erzeugt wird
herstellen

Lektion: Pflegedialoge

In dieser Lektion lernen sie die Möglichkeit kennen, einfache Pflegedialoge für
Kunden- bzw. Customizingtabellen generieren zu lassen.

Sie Sollen in Ihrem Projekt zur schnellen Testdatengenerierung einfache Dialoge
zu den neuen DB-Tabellen anlegen.
Das Erzeugen von Pflegedialogen
Abbildung 82: Datenerfassung mit generierten Pflegemasken

BC430 Lektion: Pflegedialoge
Für den Anwender bilden auf mehrere Tabellen verteilte Daten oft eine logische
Einheit, d.h, ein Anwendungsobjekt. Die Daten eines solchen Anwendungsobjekts
sollen deshalb gemeinsam angezeigt, geändert und angelegt werden können. An
der technischen Realisierung des Anwendungsobjekts, d.h. der Verteilung der
Daten auf mehrere Tabellen, ist der Anwender in der Regel nicht interessiert.
Über Pflege-Views können auf einfache Weise Möglichkeiten für die Pflege
komplexer Anwendungsobjekte geschaffen werden. Die Verteilung der Daten auf
die unterliegenden Datenbanktabellen findet automatisch statt.
Alle in einem Pflege-View zusammengefaßten Tabellen müssen über
Fremdschlüssel verknüpft sein, d.h. die Joinbedingungen werden beim
Pflege-View immer aus dem Fremdschlüssel abgeleitet. Eine direkte Eingabe der
Joinbedingungen wie bei Datenbank-Views ist nicht möglich.
Aus der Definition eines Pflege-Views im ABAP Dictionary muß eine
Pflegeoberfläche generiert werden, über die die Daten des Views angezeigt,
geändert und angelegt werden können.
Beim Anlegen der Pflegeoberfläche werden automatisch Funktionsbausteine
generiert, die die über den View gepflegten Daten auf die zugrundeliegenden
Tabellen verteilen.
Die Generierung der Pflegeoberfläche erfolgt über die Transaktion Generierung
Tabellensicht (Transaktion SE54) oder aus der Viewpflege heraus über Hilfsmittel
→ Tab.pflegegenerator.
Abbildung 83: Pflegedialog aus einem Pflegeview

In einem einstufigen Pflegedialog werden die Daten der Tabellenzeilen als

TableControl dargestellt. Die Schlüsselfelder werden grau hinterlegt und sind
für Änderungen nicht vorgesehen. Die Funktionsfelder werden weiß hinterlegt
und können geändert werden.
Wenn Sie einen Pflegedialog zweistufig angelegt haben, kann durch einen
Doppelklick in eine Tabellenzeile ein weiteres Dynpro geöffnet werden, in dem
der ausgewählte Datensatz in übersichtlicher Form dargestellt wird.
Abbildung 84: Pflegeview definieren 1
Sie sollten beim Anlegen eines Pflege-Views auf folgendes achten:

Wählen Sie bei Views als Viewtyp Pflege-View.
Alle Schlüsselfelder der Primärtabelle müssen in der Viewdefinition
enthalten sein.
Bei mandantenabhängigen Tabellen/Views muß das Mandantenfeld
einbezogen werden. Das Feld wird im Pflegedialog jedoch nicht angezeigt.
Bei Texttabellen als Sekundärtabellen darf der Sprachenschlüssel
nicht aufgenommen werden, da er bei der Pflege automatisch mit der
Anmeldesprache gefüllt wird.
Die Schlüsselfelder müssen vor den Funktionsfeldern definiert werden.
Funktionsfelder und Schlüsselfelder dürfen nicht gemischt werden.
Mit der Option Pflegestatus können Sie für die gesamte Tabelle/View den
Pflegestatus festlegen. Sie haben die folgenden Möglichkeiten:
nur lesen

lesen, ändern, löschen und einfügen (Defaulteinstellung)

lesen und ändern
lesen und ändern (zeitabhängige Views)
Abbildung 85: Pflegeview definieren 2
Tragen Sie im Feld Kurzbeschreibung einen erläuternden Kurztext ein. Sie

können später beispielsweise mit dem Infosystem über diesen Kurztext nach dem
View suchen.
Tabellen aufnehmen
Geben Sie auf der Registerkarte Tabellen/Joinbedingungen unter Tabellen die
Primärtabelle des Views an. Es können nur solche Tabellen in den Pflege-View
aufgenommen werden, die mit der Primärtabelle (indirekt) über Fremdschlüssel
verbunden sind.
Nehmen Sie falls notwendig weitere Tabellen in den View auf. Sie können in
einen Pflege-View nur Tabellen aufnehmen, die über Fremdschlüssel miteinander
verbunden sind. Stellen Sie den Cursor auf die Primärtabelle und wählen Sie
Beziehungen. Es werden alle bestehenden Fremdschlüsselbeziehungen der
Primärtabelle angezeigt. Kreuzen Sie die gewünschten Fremdschlüssel an und
wählen Sie Übernehmen. Die an einem solchen Fremdschlüssel beteiligte
Sekundärtabelle wird in den View übernommen. Die aus den Fremdschlüsseln
abgeleiteten Join-Bedingungen (Fremdschlüsselbeziehung und Join-Bedingung)
werden angezeigt.

Sie können auch Tabellen aufnehmen, die mit einer der bisher aufgenommenen
Sekundärtabellen über einen Fremdschlüssel verbunden sind. Stellen Sie hierzu
den Cursor auf die Sekundärtabelle und betätigen Sie Beziehungen. Gehen Sie
dann wie oben beschrieben vor.
Fremdschlüsselbeziehungen die für eine Pflege-View nicht geeignet sind,
werden am Ende der Liste unter der Überschrift Beziehungen mit ungeeigneter
Kardinalität angezeigt.
Übernahme der Viewfelder
Wählen Sie auf der Registerkarte Viewfelder die Felder aus, die Sie in den View
übernehmen wollen.
Betätigen Sie die Drucktaste Tabellenfelder. In einem Dialogfenster werden
alle im View enthaltenen Tabellen angezeigt. Wählen Sie eine Tabelle aus. Die
Felder der Tabelle werden nun in einem Dialogfenster eingeblendet. Sie können
daraus Felder übernehmen, indem Sie diese in der ersten Spalte markieren und
Übernehmen wählen.
Alle Schlüsselfelder der Primärtabelle müssen in einen Pflege-View aufgenommen
werden. Zusätzlich müssen alle Schlüsselfelder von Sekundärtabellen, die nicht
am Fremdschlüssel beteiligt sind (d.h. nicht über eine Join-Bedingung mit einem
bereits in den View aufgenommenen Schlüsselfeld verbunden sind), in den View
aufgenommen werden.
Damit wird sichergestellt, daß die über einen Pflege-View eingefügten Sätze
korrekt in die im View enthaltenen Tabellen geschrieben werden können.
Selektionsbedingungen
Formulieren Sie (optional) auf der Registerkarte Selektionsbedingungen
Einschränkungen an die Datensätze, die über den View angezeigt werden können
(siehe Selektionsbedingung des Views pflegen). Die Selektionsbedingungen legen
fest, welche Datensätze über den View selektiert werden können.
Pflegestatus
Legen Sie auf der Registerkarte Pflegestatus den Pflegestatus des Views fest.
Der Pflegestatus bestimmt, wie Sie über die Standardviewpflege (SM30) auf die
Viewdaten zugreifen können.
Aktivieren
Bei der Aktivierung wird ein Protokoll geschrieben, das Sie sich über Hilfsmittel
-> Aktivierungsprotokoll anzeigen lassen können. Falls bei der Aktivierung
des Views Fehler oder Warnungen auftraten, wird das Aktivierungsprotokoll
automatisch angezeigt.
Pflegeoberflächen generieren

Verzweigen Sie über Umfeld -> Tab.pflegegenerator in die Transaktion SE54.

Dort können Sie aus der Viewdefinition Pflegebausteine und Pflegeoberflächen
generieren, die die Verteilung der über den View eingegebenen Daten auf die
Basistabellen des Views übernehmen.
Abbildung 86: Pflegedialog definieren
Sie erreichen die Generierungsumgebung für Pflegedialoge folgendermaßen:

• aus der SE11 in der Ansicht für Tabellen/Views über das Menüe Hilfsmittel
-> Tabellenpflegegenerator
• über die Transaktion SE54:
1. Wählen Sie Entwicklung -> Weitere Werkzeuge ->
Gen.Tab.-Pflegedialog. Sie gelangen in das Einstiegsbild der
Pflegetransaktion.
2. Geben Sie den Namen der Tabelle bzw. View ein
3. Markieren Sie die Option Generierte Objekte
4. Wählen Sie Anlegen/Ändern
5. Bestätigen Sie im darauffolgenden Dialogfenster, daß die
Pflegebausteine angelegt werden sollen
Bei der Definition des Pflegedialoges müssen Sie die folgenden Parameter
bestimmen:
Funktionsgruppe
Hier legen Sie fest, in welcher Funktionsgruppe die tabellen/viewindi-
viduellen Pflegedialogbestandteile generiert werden. Bei Bedarf wird die
Funktionsgruppe neu angelegt.

Berechtigungsgruppe
Hier bestimmen Sie, welche Benutzer zur Pflege der Tabellen/Viewinhalte
berechtigt sind
Pflegetyp
Hier legen Sie fest, ob der Dialog ein- oder zweistufig aufgebaut wird.
Einstufige Dialoge bestehen nur aus einem Übersichtbild, in dem alle Felder
enthalten sind. Bei zweistufigen Dialogen werden im Übersichtsbild nur die
Schlüsselfelder und Textfelder mit einer Länge von mehr als 20 Zeichen
angezeigt. Im Detailbild werden alle Felder angeboten.
Pflegebilder
Hier bestimmen Sie die interne Nummer jedes Pflegebildes. Über eine
Suchfunktion können Sie sich mögliche Werte vorschlagen lassen.
Aufzeichnungsroutine
Hier legen Sie fest, ob und wie die mit dem Dialog gepflegten
Tabellen/Viewinhalte in einen Transport aufgenommen werden.
Nach der Eingabe aller Werte wird die Generierung des Pflegedialoges gestartet.
Wenn dieser Vorgang fehlerfrei verläuft, kann der Dialog unmittelbar zur Pflege
der Tabellen/Viewinhalte benutzt werden. Starten Sie dazu die Transaktion SM30
und tragen sie im Feld Tabelle/Sicht die Tabelle oder View ein, für die Sie den
Pflegedialog generiert haben. Betätigen Sie die Schaltfläche Pflegen.
Abbildung 87: Vor- und Nachteile einer Pflegeview
Die Pflegeview und die Pflegedialoge sollte nicht für die Datenpflege im
Standardbetrieb verwendet werden, da die Gefahr von Dateninkonsistenzen
besteht.

Sie ist vielmehr zur einfachen Erfassung von mittleren Datenmengen in

Kundentabellen oder Customizingtabellen gedacht, bei denen es keine
Überschneidungen in den erfassten Daten geben kann.
Die Sekundärtabellen müssen zur Primärtabelle bzw. zur transitiv vorhergehenden
Sekundärtabelle in einer N:1-Abhängigkeit stehen (siehe oben).
Abbildung 88: Viewcluster und Pflegedialog
Wenn Sie einzelne Pflegedialoge für Tabellen/Views generiert haben, können Sie
diese zu einem Viewcluster verbinden.
Unter einem Viewcluster versteht man eine Gruppe von Pflegedialogen, die
aus betriebswirtschaftlichen oder technischen Gründen zu einer Pflegeeinheit
zusammengefaßt wurden.
Viewcluster bieten damit die Möglichkeit, inhaltlich zusammengehörige Daten,
die über eine Tabelle/einen View hinausgehen, konsistent zu pflegen.
Während sich in Pflegeviews (mit Ausnahme von sprachabhängigen Texten)
nur 1:1 Beziehungen verarbeiten lassen, können mit Viewclustern auch
Schlüsselerweiterungen und Beziehungen der Kardinalität N:M abgebildet
werden. Darüber hinaus lassen sich Pflegedialoge ohne Schlüssel- oder
Teilschlüsselabhängigkeit zu einem Viewcluster zusammenfassen.

Die Navigation innerhalb des Viewclusters orientiert sich i.d.R. an der Hierarchie
der den Einzeldialogen zugrundeliegenden Tabellen/Views. Master – Detail –
Beziehungen, auch über mehrere Ebenen hinweg eignen sich besonders gut für
einen Viewcluster.
Normalerweise besteht ein Viewcluster aus einem oder mehreren Wurzeldialogen
und den von ihm bzw. ihnen abhängigen, maximal 14 Pflegedialogen. Diese
Pflegedialoge können sowohl ein- als auch zweistufig sein.
Sie müssen zunächst über die SE54 für jede beteiligte Tabelle/View einen
Pflegedialog generieren, um sie dann ebenfalls in der SE54 zu einem Viewcluster
zusammenzufügen.
Die anschließende Pflege der Daten führen Sie mit der Transaktion SM34 und
der Angabe des Clusternames durch.
Abbildung 89: Vorteile

Übung 12: Pflegedialoge

• einfache und komplexe Pflegedialoge anlegen.
Sie sollen in Ihrem Projekt zur schnellen Testdatengenerierung einfache Dialoge
zu DB-Tabellen anlegen.
Aufgabe 1:
Legen Sie einen Pflege-View mit Namen ZPARTNER## an, mit dem Sie bequem
neue Geschäftspartner einpflegen können.
Notiz: Die Geschäftspartner sind in der Tabelle SBUSPART eingetragen.

Ein Geschäftspartner kann entweder ein Flugkunde oder ein Reisebüro
sein. Falls es sich um ein Reisebüro handelt, wird ein entsprechender
Eintrag in der Tabelle STRAVELAG vorgenommen.
Der View soll es Ihnen also erlauben, die Tabellen SBUSPART und
STRAVELAG gemeinsam zu pflegen. Nehmen Sie alle notwendigen
Felder der Tabellen in den View auf.
Sie wollen über den Pflege-View die Daten in den Tabellen SBUSPART
und STRAVELAG gemeinsam pflegen. Falls Sie einen neuen Partner
direkt eintragen würden, müßten Sie diesen zuerst in der Tabelle
SBUSPART eintragen. Erst danach könnten Sie (wegen der bestehenden
Fremdschlüsselprüfung zwischen SBUSPART und STRAVELAG) die
entsprechenden Daten in der Tabelle STRAVELAG eintragen.
1. Generieren Sie die Pflegeoberfläche. Verwenden Sie dabei folgende

Parameter:
Funktionsgruppe ZZBC430##
Berechtigungsgruppe SUNI
Pflegetyp Einstufig
Übersichtsbild 100
2. Nehmen Sie die Felder der beiden Tabellen in den View auf.
3. Genieren Sie eine Pflegeoberfläche für den View.

4. Pflegen Sie die Daten eines neuen Reisebüros über die erweiterte
Tabellenpflege ein. Wählen Sie System → Dienste → Tabellenpflege →
Erweit. Tab.pflege.
Aufgabe 2:
Pflegedialoge in einem Viewcluster bündeln.
Notiz: Sie wollen mehrere Pflegedialoge von abhängigen Tabellen

auf einem einzigen Tansaktionsbild bedienen. Dazu legen Sie einen
komplexen Pflegedialog über mehrere Kundentabellen an. In dieser
Übung verwenden Sie wieder Tabellen aus dem Flugdatenmodell. Sie
werden diese Tabellen inklusive deren Inhalt in den Kundennamensraum
kopieren.
1. Kopieren Sie zunächst die Tabellen SCARR, SPFLI und SFLIGHT in

den Kundennamensraum mit angehängter Monitornummer (ZCARR##,
ZPFLI## und ZFLIGHT##). Pflegen Sie die Fremdschlüssel in den neuen
Tabellen passend nach.
2. Kopieren Sie den Inhalt der Originaltabellen in die neu geschaffenen
Tabellen mit Hilfe eines Reports.
3. Legen Sie für jede der kopierten Tabellen einen zweistufigen Pflegedialog
(Dynpronummern z.B. 100 und 110) an.
4. Legen Sie einen Viewcluster mit der Bezeichnung ZPC_FLIGHT## an.
5. Vergeben Sie im Kopfeintrag eine sinnvolle Kurzbeschreibung.
6. Wechseln Sie zur Objektstruktur und geben Sie die folgenden neue Einträge
ein:
View/Tab. Kurzbeschreibung Vorgänger Abh Pos

ZCARR## Flugesellschaften ZCARR## R 1
ZPFLI## Flugverbindungen ZCARR## S 2
ZFLIGHT## Flüge der Verbindung ZPFLI## S 3
7. Erzeugen Sie zu jedem Eintrag in der Liste die Feldabhängigkeiten.

8. Aktivieren Sie den Viewcluster
9. Erzeugen Sie einen neuen Eintrag für eine Fluggesellschaft und legen Sie für
diese zwei neue Flugverbindungen mit jeweils zwei Flügen an. Geben Sie
die neuen Einträge über einen Report in einer Liste aus.

Lösung 12: Pflegedialoge

Aufgabe 1:
Legen Sie einen Pflege-View mit Namen ZPARTNER## an, mit dem Sie bequem
neue Geschäftspartner einpflegen können.
Notiz: Die Geschäftspartner sind in der Tabelle SBUSPART eingetragen.

Ein Geschäftspartner kann entweder ein Flugkunde oder ein Reisebüro
sein. Falls es sich um ein Reisebüro handelt, wird ein entsprechender
Eintrag in der Tabelle STRAVELAG vorgenommen.
Der View soll es Ihnen also erlauben, die Tabellen SBUSPART und
STRAVELAG gemeinsam zu pflegen. Nehmen Sie alle notwendigen
Felder der Tabellen in den View auf.
Sie wollen über den Pflege-View die Daten in den Tabellen SBUSPART
und STRAVELAG gemeinsam pflegen. Falls Sie einen neuen Partner
direkt eintragen würden, müßten Sie diesen zuerst in der Tabelle
SBUSPART eintragen. Erst danach könnten Sie (wegen der bestehenden
Fremdschlüsselprüfung zwischen SBUSPART und STRAVELAG) die
entsprechenden Daten in der Tabelle STRAVELAG eintragen.
1. Generieren Sie die Pflegeoberfläche. Verwenden Sie dabei folgende

Parameter:

Funktionsgruppe ZZBC430##
Berechtigungsgruppe SUNI
Pflegetyp Einstufig
Übersichtsbild 100
a) Markieren Sie im Einstiegsbild des ABAP Dictionary den Objekttyp

View. Geben Sie den Objektnamen ZPARTNER## ein und wählen
Sie Anlegen.
b) Im Dialogfenster wählen Sie den Viewtyp. Markieren Sie Pflege-View
und wählen Sie Auswählen.
c) Geben Sie auf dem Folgebild einen Kurztext ein. Bei der Definition
des Pflege-Views zuerst nehmen Sie die Tabelle SBUSPART auf.
d) Tragen Sie die Tabelle SBUSPART im Feld Tabellen ein. Die
Schlüsselfelder dieser Tabelle werden damit automatisch als Felder in
den View aufgenommen.
e) Stellen Sie den Cursor im Feld Tabellen auf den Eintrag SBUSPART.
Wählen Sie Beziehungen.
Es erscheint ein Dialogfenster, in welchem alle bestehenden
Fremdschlüsselbeziehungen der Tabelle SBUSPART zu anderen
Tabellen aufgelistet sind.
f) Markieren Sie im Dialogfenster die Fremdschlüsselbeziehung zur
Tabelle STRAVELAG, und wählen Sie Übernehmen.
g) Die Join-Bedingungen werden nun aus dem Fremdschlüssel erzeugt.
Die Join-Bedingungen haben folgende Form:
SBUSPART-MANDANT = STRAVELAG-MANDT
SBUSPART-BUSPARTNUM = STRAVELAG-AGENCYNUM
2. Nehmen Sie die Felder der beiden Tabellen in den View auf.
a) Wechseln Sie auf die Registerkarte Viewfelder. Stellen Sie den Cursor
auf die Tabelle SBUSPART und wählen Sie TabFelder. Es erscheint
eine Liste aller Felder der Tabelle. Wählen Sie Alle markieren und
danach Übernehmen.
b) Nehmen Sie nun auf die gleiche Art alle Felder der Tabelle
STRAVELAG mit Ausnahme der Felder MANDT und AGENCYNUM
in den View auf. Diese Felder sind über die Join-Bedingungen mit den
entsprechenden Feldern der Tabelle SBUSPART verbunden und sollten
deshalb nicht im View auftauchen.
c) Aktivieren Sie den View.

3. Genieren Sie eine Pflegeoberfläche für den View.

a) Wählen Sie Hilfsmittel → Tabellenpflegegenerator.
b) Geben Sie im Folgebild die Berechtigungsgruppe SUNI und die
Funktionsgruppe ZFP_BC430## ein.
c) Markieren Sie den Pflegetyp einstufig. Wählen Sie die Nummer 0100
als Pflegebildnummer des Übersichtsbildes.
d) Wählen Sie Anlegen. Sie werden dann nach der Entwicklungsklasse der
Funktionsgruppe und der generierten Pflegeobjekte gefragt. Wählen
Sie in beiden Fällen Lokales Objekt.
4. Pflegen Sie die Daten eines neuen Reisebüros über die erweiterte
Tabellenpflege ein. Wählen Sie System → Dienste → Tabellenpflege →
Erweit. Tab.pflege.
a) Geben Sie die Daten eines neuen Reisebüros ein.
b) Verifizieren Sie dann mit dem Data Browser (im Umfeld-Menü
des Einstiegsbild zum ABAP Dictionary), daß die Daten des neuen
Reisebüros in die Tabellen SBUSPART und STRAVELAG geschrieben
wurden.
Aufgabe 2:
Pflegedialoge in einem Viewcluster bündeln.
Notiz: Sie wollen mehrere Pflegedialoge von abhängigen Tabellen

auf einem einzigen Tansaktionsbild bedienen. Dazu legen Sie einen
komplexen Pflegedialog über mehrere Kundentabellen an. In dieser
Übung verwenden Sie wieder Tabellen aus dem Flugdatenmodell. Sie
werden diese Tabellen inklusive deren Inhalt in den Kundennamensraum
kopieren.
1. Kopieren Sie zunächst die Tabellen SCARR, SPFLI und SFLIGHT in

den Kundennamensraum mit angehängter Monitornummer (ZCARR##,
ZPFLI## und ZFLIGHT##). Pflegen Sie die Fremdschlüssel in den neuen
Tabellen passend nach.
a) Kopieren und aktivieren Sie die Tabellen mit Hilfe der SE11. Passen
Sie die Fremdschlüsselbeziehungen ZPFLI## (CARRID -> ZCARR##)
und ZFLIGHT## (CARRID -> ZCARR##, CONNID -> ZPFLI##) an.
2. Kopieren Sie den Inhalt der Originaltabellen in die neu geschaffenen
Tabellen mit Hilfe eines Reports.
a) siehe Quelltext der Musterlösung. Sie können den entsprechenden
Report auch im System finden und kopieren.

3. Legen Sie für jede der kopierten Tabellen einen zweistufigen Pflegedialog
(Dynpronummern z.B. 100 und 110) an.
a) Sie haben zwei Möglichkeiten in den passenden Bildschirm der
Transaktion SE54zu kommen:
1. Springen Sie in der Transaktion SE11 zur jeweiligen Tabelle
über den Menüpfad Hilfsmittel -> Tabellenpflegegenerator in
die Generierungsumgebung.
2. Starten Sie die Transaktion SE54 und geben Sie die entsprechende
Tabelle ein.
Wählen Sie Generierte Objekte und drücken Sie die Schaltfläche
Anlegen/Ändern.
b) Geben Sie im Folgebild die Berechtigungsgruppe SUNI und als
Funktionsgruppe den jeweiligen Tabellennamen mit dem Präfix ZFP_
ein.
c) Markieren Sie den Pflegetyp zweistufig. Wählen Sie die Nummer
0100 und 0110 als Pflegebildnummern des Übersichtsbildes und
des Einzelbildes.
d) Wählen Sie Anlegen. Sie werden dann nach der Entwicklungsklasse der
Funktionsgruppe und der generierten Pflegeobjekte gefragt. Wählen
Sie in beiden Fällen Lokales Objekt.
e) Verfahren Sie analog zu allen kopierten Tabellen
4. Legen Sie einen Viewcluster mit der Bezeichnung ZPC_FLIGHT## an.
a) Starten Sie Transaktion SE54 und wechseln Sie aus dem Einstiegsbild
über die Schaltfläche Bearb. Viewcluster in die Ansicht für das
Bearbeiten/Anlegen eines Viewcluster.
b) Geben Sie den Namen des Clusters im Feld Viewcluster an.
c) Drücken Sie die Schaltfläche Anlegen/Ändern.
d) Ignorieren Sie die die Meldung „Bitte keine Änderungen (Daten
gehören SAP)“. So lange Sie im Kundennamensraum (Z* bzw.
Y*) bleiben hat diese Meldung keine Bedeutung. Genauere Info im
SAP-Hinweis Nr.: 671067
5. Vergeben Sie im Kopfeintrag eine sinnvolle Kurzbeschreibung.
6. Wechseln Sie zur Objektstruktur und geben Sie die folgenden neue Einträge
ein:

View/Tab. Kurzbeschreibung Vorgänger Abh Pos

ZCARR## Flugesellschaften ZCARR## R 1
ZPFLI## Flugverbindungen ZCARR## S 2
ZFLIGHT## Flüge der Verbindung ZPFLI## S 3
a) Doppelklicken Sie im Navigationsfenster Dialogstrukturauf den

Knoten Objektstruktur
b) Drücken Sie die Schaltfläche Neue Einträge.
c) Tragen Sie die Werte entsprechend der Tabelle ein.
d) Wählen Sie die Tabelle ZCARR## als Einstiegsobjekt über die Spalte
START.
7. Erzeugen Sie zu jedem Eintrag in der Liste die Feldabhängigkeiten.
a) Markieren Sie jede Zeile der Objektstruktur einzeln und generieren Sie
jeweils die Feldabhängigkeiten über die Schaltfläche Feldabhängigkeit
8. Aktivieren Sie den Viewcluster
a) Wählen Sie per Doppelklick den Dialog für den Kopfeintrag und
drücken Sie die Schaltfläche Aktivieren
9. Erzeugen Sie einen neuen Eintrag für eine Fluggesellschaft und legen Sie für
diese zwei neue Flugverbindungen mit jeweils zwei Flügen an. Geben Sie
die neuen Einträge über einen Report in einer Liste aus.
a) Rufen Sie die Transaktion SM34 auf.
b) Geben Sie im Eingabefeld den Namen Ihres Viewclusters an und
betätigen Sie die Schaltfläche Pflegen.
c) Pflegen Sie die neuen Einträge ein, beginnend mit der ZCARR##.
Notiz: Auf der linken Seite des Dynpro's können Sie navigieren
und auf der rechten Seite die Daten erfassen bzw. ändern.
d) Durch die Schaltfläche Sichern werden die Daten in die Datenbank

weggeschrieben.
e) Schreiben Sie mit der SE38 oder den SE80 in ABAP einen Report, der
die Einträge für die neue Fluggesellschaft ausgibt.
Ergebnis
REPORT SAPBC430S_FILL_CLUSTER_TAB .
DATA wa_scarr TYPE scarr.

DATA wa_spfli TYPE spfli.

DATA wa_flight TYPE sflight.
DATA my_error TYPE i VALUE 0.
START-OF-SELECTION.
* Replace ## by Your user-number
DELETE FROM zcarr##.

DELETE FROM zpfli##.
DELETE FROM zflight##.
SELECT * FROM scarr INTO wa_scarr.

INSERT INTO zcarr## VALUES wa_scarr.
ENDSELECT.
IF sy-subrc = 0.
SELECT * FROM spfli INTO wa_spfli.
INSERT INTO zpfli## VALUES wa_spfli.
ENDSELECT.
IF sy-subrc = 0.
SELECT * FROM sflight INTO wa_flight.

INSERT INTO zflight## VALUES wa_flight.
ENDSELECT.
IF sy-subrc <> 0.
my_error = 1.
ENDIF.
ELSE.
my_error = 2.
ENDIF.
ELSE.
my_error = 3.
ENDIF.
IF my_error = 0.
WRITE / 'Datatransport successfully finished'.
ELSE.
WRITE: / 'ERROR:', my_error.
ENDIF.


Nun können Sie


Nun können Sie
erzeugt wird
herstellen

Kapitel 8
Suchhilfen

In diesem Kapitel werden Sie lernen SAP-Suchhilfen selbst zu definieren und
anzuwenden.

• über eine Suchhilfe einen Eingabehilfeablauf definieren

• eine Suchhilfe mit mehreren alternativen Suchpfaden definieren
• die verschiedenen Mechanismen der Suchhilfeanbindung nutzen, um eine
Suchhilfe einem Bildschirmfeld zuzuordnen
• für ein Bildschirmfeld feststellen, ob und welche Form der Eingabehilfe
vorliegt
• eine Sammelsuchhilfe mit Hilfe einer Append-Suchhilfe modifikationsfrei
erweitern
• einen Suchhilfe Exit programmieren
Inhalt des Kapitels

Lektion: Suchhilfen .............................................................212
Übung 13: Suchhilfen ......................................................231

Kapitel 8: Suchhilfen BC430
Lektion: Suchhilfen

vorliegt
erweitern
Sie wollen den Anwendern Ihres Unternehmens auf Dialogen einfache
Eingabehilfen zur Verfügung stellen.
Eingabehilfen
Abbildung 90: SAP-Standardfunktion: Wertehilfe

BC430 Lektion: Suchhilfen
Die Eingabehilfe (F4-Hilfe) iste eine Standardfunktion des SAP-Systems, die es

dem Benutzer ermöglicht, eine Liste der für ein Bildschirmfeld möglichen Werte
anzuzeigen. Für eingabebereite Felder kann ein Wert durch Auswahl aus der Liste
direkt in das Feld übernommen werden.
Die Felder mit Eingabehilfe werden im SAP-System durch die rechts am Feld
angebrachte Eingabehilfetaste visualisiert. Diese Taste erscheint, sobald der
Cursor im entsprechenden Bildschirmfeld steht. Die Hilfe kann entweder durch
Auswahl dieses Bildelements oder über die Funktionstaste F4 aufgerufen werden.
Ist die Anzahl möglicher Eingaben in einem Feld sehr groß, so kann der Benutzer
die Menge der angezeigten Werte durch zusätzliche Einschränkungen eingrenzen.
Die Anzeige der möglichen Eingaben wird noch um sinnvolle Zusatzinformationen
zu den angezeigten Werten erweitert. Diese Funktion ist besondert nützlich, wenn
das Feld die Eingabe eines formalen Schlüssels erfordert.
Da die Eingabehilfe eine Standardfunktion ist, soll sie sich in Aussehen und
Verhalten über das ganze SAP System möglichst einheitlich darstellen. Daher
stellt die Entwicklungsumgebung Hilfsmittel zur Verfügung, einem Bildschirmfeld
eine standardisierte Eingabehilfe zuzuordnen.
Die genaue Beschreibung der Eingabehilfe eines Feldes ergibt sich meistens aus
seiner Semantik. Daher wird die Eingabehilfe eines Feldes im Normalfall im
ABAP Dictionary definiert.
Abbildung 91: Anforderungen an die Wertehilfe

An die Eingabehilfe eines Bildschirmfelds (Suchfeld) werden eine Reihe von

Anforderungen gestellt:
• In der Eingabehilfe sollten dem System bereits bekannte Informationen (der
Kontext) berücksichtigt werden. Dies betrifft Eingaben, die der Benutzer
bereits auf der aktuellen Eingabemaske gemacht hat, sowie Informationen,
die in vorherigen Dialogschritten gewonnen wurden. Der Kontext wird von
der Eingabehilfe im Normalfall dazu genutzt, die Menge der möglichen
Werte einzuschränken.
• Die Eingabehilfe muß die Werte ermitteln, die sie dem Benutzer zur Auswahl
anbieten kann. Dabei müssen auch die Daten bestimmt werden, die dem
Benutzer auf der Liste der möglichen Werte als Zusatzinformation angezeigt
werden. Bei der Ermittlung der möglichen Werte sind die Einschränkungen
zu berücksichtigen, die sich aus dem Kontext sowie aus zusätzlichen vom
Benutzer spezifizierten Suchbedingungen ergeben.
• Die Eingabehilfe muß einen Dialog mit dem Benutzer führen. Dieser
beinhaltet auf jeden Fall die Präsentation der möglichen Werte (mit
Zusatzinformation) in einer Liste und die Möglichkeit, von dieser Liste
einen Wert auszuwählen. In vielen Fällen kommt die Darstellung einer
Suchmaske hinzu, in der der Benutzer Bedingungen an die anzuzeigenden
Werte festlegen kann.
• Hat der Benutzer einen Wert ausgewählt, so muß die Eingabehilfe diesen
Wert in das Suchfeld zurückstellen. In vielen Fällen befinden sich auf der
Eingabemaske weitere Felder (oft reine Anzeigefelder), die erläuternde
Zusatzinformationen zum Suchfeld enthalten. Die Eingabehilfe sollte dann
auch die Inhalte dieser Felder aktualisieren.
Abbildung 92: ABAP Dictionary Objekt-Suchhilfe

Das ABAP Dictionary Objekt Suchhilfe dient der Beschreibung einer

Eingabehilfe. Die Definition einer Suchhilfe enthält die Information, die das
System zur Erfüllung der beschriebenen Anforderungen benötigt.
Die Schnittstelle der Suchhilfe regelt die Übergabe von Daten aus der
Eingabemaske in die F4-Hilfe und zurück. In der Schnittstelle wird festgelegt,
welche Kontextdaten berücksichtigt und welche Daten bei Auswahl eines Wertes
auf die Eingabemaske zurückgestellt werden können.
Das interne Verhalten der Suchhilfe beschreibt den eigentlichen F4-Prozess.
Dazu gehören sowohl die Selektionsmethode, mit der die anzuzeigenden Werte
ermittelt werden sollten, als auch das Dialogverhalten, das die Interaktion mit
dem Benutzer beschreibt.
Wie bei der Definition eines Funktionsbausteins unterscheiden wir auch bei
Suchhilfen zwischen der Schnittstelle, über die die Suchhilfe den Datenaustausch
mit anderen Softwarekomponenten vornimmt, und dem internen Verhalten
(letzteres ist bei Funktionsbausteinen durch den Quelltext gegeben).
Die Definition von Suchhilfen ist nur dann sinnvoll, wenn ein Mechanismus zur
Verfügung steht, mit dem diese von einem Bildschirmbild aus angesprochen
werden können. Dieser Mechanismus wird als Suchhilfeanbindung bezeichnet
und später beschrieben.
Wie der Editor für Funktionsbausteine bietet auch der Editor für Suchhilfen die
Möglichkeit, ein Objekt zu testen. Damit können Sie das Verhalten einer Suchhilfe
prüfen, ohne sie einem Bildschirmfeld zugeordnet zu haben.

Abbildung 93: Selektionsmethode einer Suchhilfe
Die von der Eingabehilfe angezeigten möglichen Werte für ein Feld werden zur
Laufzeit durch eine Selektion von der Datenbank ermittelt. Bei der Definition einer
Suchhilfe ist durch Angabe einer Tabelle oder eines View als Selektionsmethode
festzulegen, aus welchem Datenbankobjekt die Daten selektiert werden sollen.
Die Benutzung eines Views als Selektionsmethode ist dann sinnvoll, wenn die für
die Eingabehilfe relevanten Daten zu den möglichen Werten über mehrere Tabellen
verteilt sind. Wenn diese Daten alle in einer Tabelle oder in der zugehörigen
Texttabelle sind, können Sie die Tabelle als Selektionsmethode verwenden. Das
System sorgt dann automatisch dafür, daß die Texte aus der Texttabelle in der
Anmeldesprache des Benutzers mit berücksichtigt werden.
Existiert noch kein View, der die für eine Eingabehilfe relevanten Daten
zusammenfaßt, so muß dieser zunächst im ABAP Dictionary angelegt werden.
Pflege-Views dürfen nicht als Selektionsmethoden für Suchhilfen benutzt werden.
Im Normalfall wird also ein Datenbank-View verwendet. Es ist allerdings zu
berücksichtigen, daß Datenbank-Views (im SAP System) immer über einen Inner
Join gebildet werden. Somit werden bei der Eingabehilfe nur die Werte angeboten,
für die in jeder beteiligten Tabelle ein Eintrag vorhanden ist. In manchen Fällen
sollen die Werte über einen Outer Join bestimmt werden. Als Selektionsmethode
ist dann ein Help-View zu wählen. Weitere Informationen zu Help-Views finden
Sie im Anhang.
Ist die Selektionsmethode einer Suchhilfe mandantenabhängig, so erfolgt die
Selektion der möglichen Werte immer nur im Anmeldemandanten des Benutzers.

Abbildung 94: Beschreibung des Dialogverhaltens
Die möglichen Werte werden in einem Dialogfenster, dem Popup zur Anzeige
der Treffermenge, als Liste präsentiert, aus der der Benutzer den gewünschten
Eintrag auswählt. Bestehen die möglichen Werte aus formalen Schlüsseln, so
sollten erläuternde Zusatzinformationen zu diesen angezeigt werden.
Ist die Treffermenge sehr groß, so sollte der Benutzer Zusatzbedingungen an
Attribute des auszuwählenden Eintrags stellen können. Eine solche Einschränkung
der zu verarbeitenden Datenmenge erhöht die Übersichtlichkeit der Liste und
verringert die Systembelastung. Die Zusatzbedingungen werden vom Benutzer auf
einem weiteren Dialogfenster, dem Popup zur Werteeinschränkung, eingegeben.
Der Dialogtyp einer Suchhilfe legt fest, ob das Popup zur Werteeinschränkung
angeboten wird, bevor die Treffermenge ermittelt wird.
Die Merkmale, die auf einem der beiden Popups (oder beiden) erscheinen sollen,
müssen Sie als Parameter in die Suchhilfe aufnehmen. Als Parameter können
Sie alle Felder der Selektionsmethode (bis auf das Mandantenfeld) sowie ggf. die
Nichtschlüsselfelder ihrer Texttabelle benutzen.
Welche Parameter auf welchem Popup (in welcher Reihenfolge) erscheinen,
legen Sie fest, indem Sie den Parametern Positionen auf den beiden Popups
zuweisen. Es ist also möglich, auf den beiden Popups verschiedene Parameter
(oder verschiedene Reihenfolgen) zu verwenden.
Suchhilfeparameter müssen durch Datenelemente typisiert sein. Diese legen
ihre Darstellung auf den beiden Popups fest. Wenn nicht anders festgelegt,
übernimmt ein Parameter das Datenelement des entsprechenden Feldes der
Selektionsmethode.

Abbildung 95: Schnittstelle einer Suchhilfe
Bei der Definition eines Parameters einer Suchhilfe müssen Sie festlegen, ob durch
ihn Daten in die Eingabehilfe übernommen werden sollen (IMPORT-Parameter)
und ob durch ihn Daten aus der Eingabehilfe zurückgestellt werden sollen
(EXPORT-Parameter).
Die IMPORT- und EXPORT-Parameter einer Suchhilfe bilden zusammen ihre
Schnittstelle. (Auch hier besteht die Analogie zu Funktionsbausteinen.)
Sie können auch Schnittstellenparameter definieren, die weder auf dem Popup
zur Anzeige der Treffermenge noch auf dem Popup zur Werteeinschränkung
erscheinen. Das ist z.B. sinnvoll, wenn bei Auswahl eines Wertes Bildschirmfelder
aktualisiert werden sollen, die auf keinem der beiden Popups erscheinen.
Woher die IMPORT-Parameter einer Suchhilfe ihre Werte beziehen und in welche
Bildschirmfelder die Inhalte der EXPORT-Parameter der Suchhilfe zurückgestellt
werden, wird bei der Suchhilfeanbindung festgelegt.
Für das Suchfeld gilt eine Sonderlogik. Sein Inhalt wird nur dann in der
Eingabehilfe verwendet, wenn es sich um ein Suchmuster handelt (das heißt, wenn
er ein * oder ein + enthält) und der mit dem Suchfeld verbundene Parameter ein
IMPORT-Parameter ist.
Parameter, die nur Zusatzinformation zum Suchfeld beinhalten, sollten Sie
nicht als IMPORT-Parameter definieren, da der Benutzer die entsprechenden
Dynprofelder sonst jedes Mal leeren muß, bevor er mit der Eingabehilfe einen
neuen Wert bestimmen kann.

Abbildung 96: Wie benutzt man Suchhilfen?
Eine Suchhilfe beschreibt den Verlauf einer Eingabehilfe. Damit sie bei einem
Eingabefeld wirksam wird, bedarf es noch eines Mechanismus, der die Suchhilfe
diesem Feld zuordnet. Dieser Mechanismus wird als Suchhilfeanbindung an das
Feld bezeichnet.
Die Anbindung einer Suchhilfe an ein Feld beeinflußt dessen Verhalten. Sie wird
daher als Teil der Definition dieses Feldes angesehen.
Die semantischen und technischen Eigenschaften eines Bildschirmfeldes (Typ,
Länge, F1-Hilfe...) werden im Normalfall nicht direkt bei der Definition der
Eingabemaske festgelegt. Vielmehr wird im Screen-Painter nur ein Verweis auf ein
(meist namensgleiches) ABAP Dictionary Feld angegeben. Das Bildschirmfeld
übernimmt dann die Eigenschaften dieses Feldes aus dem ABAP Dictionary. Das
selbe Prinzip wird auch für die Definition der Eingabehilfe eines Bildschirmfeldes
genutzt. Die Anbindung der Suchhilfe an das Suchfeld findet also nicht beim
Bildschirmfeld sondern beim zugeordneten ABAP Dictionary Feld statt.
Bei der Suchhilfeanbindung erfolgt eine Zuordnung zwischen den
Schnittstellenparametern der Suchhilfe und den Bildschirmfeldern, die Daten in
die Eingabehilfe eingehen lassen oder Daten aus der Eingabehilfe übergeben
bekommen sollen. Dabei muß das Suchfeld einem EXPORT-Parameter der
Suchhilfe zugeordnet werden. Es wird empfohlen, daß dieser Parameter
auch IMPORT-Parameter ist, damit vom Benutzer eingetragene Suchmustern
berücksichtigt werden.
Auch Felder ohne Suchhilfeanbindung können eine Eingabehilfe besitzen, da für
die F4-Hilfe noch weitere Mechanismen (z.B. Domänenfestwerte) benutzt werden.

Abbildung 97: Suchhilfeanbindung im ABAP Dictionary
Zur Anbindung einer Suchhilfe an ein Feld des ABAP Dictionary gibt es drei
Mechanismen:
1. Eine Suchhilfe kann direkt an ein Feld einer Struktur oder Tabelle
angebunden werden. Die Definition dieser Anbindung erfolgt weitgehend
analog zur Definition eines Fremdschlüssels. Insbesondere ist auch hier
eine Zuordnung zu definieren (zwischen den Schnittstellenparametern der
Suchhilfe und den Feldern der Struktur), für die das System einen Vorschlag
erzeugt.
2. Besitzt ein Feld eine Prüftabelle, so wird deren Inhalt automatisch als
mögliche Werte in der Eingabehilfe angeboten. Hierbei werden die
Schlüsselfelder der Prüftabelle angezeigt. Besitzt die Prüftabelle eine
Texttabelle, so wird noch deren erstes characterartiges Nichtschlüsselfeld
angezeigt. Ist die beschriebene Standarddarstellung des Datenbestandes
der Prüftabelle nicht zufriedenstellend, so kann an die Prüftabelle eine
Suchhilfe angebunden werden. Diese Suchhilfe wird dann für alle Felder
benutzt, die diese Tabelle als Prüftabelle besitzen. Bei der Anbindung ist
eine Zuordnung zwischen der Schnittstelle der Suchhilfe und dem Schlüssel
der Prüftabelle zu definieren.
3. Die Semantik eines Feldes und somit auch seine möglichen Werte sind bei
seinem Datenelement definiert. Es ist daher auch möglich, eine Suchhilfe
an ein Datenelement anzubinden. Die Suchhilfe steht dann für alle Felder
zur Verfügung, die auf dieses Datenelement verweisen. Bei der Anbindung
ist ein EXPORT-Parameter der Suchhilfe zu spezifizieren, über den die
Datenübertragung erfolgt.

Durch Anbindung einer Suchhilfe an eine Prüftabelle (oder ein Datenelement)

kann ein sehr hoher Wiederverwendungsgrad erreicht werden. Die Möglichkeit
der Übergabe zusätzlicher Werte über die Schnittstelle der Suchhilfe ist hier
allerdings stark eingeschränkt.
Abbildung 98: Überblick: Mechanismen für die Eingabehilfe
Um für möglichst viele Bildschirmfelder eine sinnvolle Eingabehilfe anbieten zu

können, verwendet das SAP-System eine Reihe von Mechanismen. Stehen für ein
Feld mehrere dieser Mechanismen zur Verfügung, so wird der in obiger Hierarchie
am weitesten links bzw. am weitesten oben stehende genutzt.
Außer den bereits vorgestellten Möglichkeiten, die Eingabehilfe eines Feldes im
ABAP Dictionary zu definieren, gibt es auch die Möglichkeit, die Definition am
Dynprofeld vorzunehmen. Diese Möglichkeit hat aber den Nachteil, daß keine
automatische Wiederverwendung erfolgt.
Mit Hilfe des Dynproereignisses POV kann die Eingabehilfe eines Feldes
vollkommen selbst programmiert werden. Das Aussehen einer solchen Hilfe kann
durch Verwendung der Funktionsbausteine F4IF_FIELD_VALUE_REQUEST
bzw. F4IF_INT_TABLE_VALUE_REQUEST an die Standardhilfe angepaßt
werden.
Es sollte aber geprüft werden, ob der selbstprogrammierte Anteil der Eingabehilfe
nicht besser über ein Suchhilfe-Exit (siehe Anhang) realisiert werden kann.
An ein Dynprofeld kann auch im Screenpainter eine Suchhilfe angebunden
werden. Diese Form der Anbindung besitzt aber gegenüber der Anbindung im
Dictionary funktionale Einschränkungen.

Die direkt in der Ablauflogik des Dynpro definierten Eingabeprüfungen, aus denen
ebenfalls Eingabehilfen abgeleitet werden, sollten nicht mehr verwendet werden.
Im Menü der rechten Maustaste auf der Trefferliste wird die Funktion Technische
Info angeboten. Hiermit kann ermittelt werden, welcher der genannten
Mechanismen im Einzelfall genutzt wird.
Abbildung 99: Performance der Eingabehilfe
Bei den im Rahmen einer Eingabehilfe anfallenden Selektionen muß oft ein
erheblicher Datenbestand durchsucht werden. Das kann zum einen dazu führen,
daß der einzelne Benutzer lange auf die Anzeige der möglichen Eingaben warten
muß, zum anderen wird dadurch die Belastung des Gesamtsystems gegebenenfalls
empfindlich erhöht.
Aus diesem Grund sollte bei der Definition einer Suchhilfe geprüft werden, ob
für die Selektionsmethode Maßnahmen zur Optimierung des Zugriffsverhaltens
getroffen werden müssen. Dies gilt insbesondere, wenn die Selektion über einen
View und somit über mehrere physische Tabellen erfolgt.
Ist die Anzahl der Einträge in der Selektionsmethode sehr groß, so sollte die
Treffermenge durch zusätzliche Bedingungen eingeschränkt werden. Dies erhöht
auch die Übersichtlichkeit der Trefferliste. Die zusätzlichen Bedingungen können
sich automatisch aus dem Kontext ergeben oder vom Benutzer im Popup zur
Werteeinschränkung erfragt werden. In vielen Fällen läßt sich die Performance
der Eingabehilfe entscheidend steigern, indem ein Index auf die Felder angelegt
wird, über die die entsprechenden Einschränkungen formuliert werden.
Ist die Anzahl der Einträge in der Selektionsmethode relativ klein, so sollte auf
jeden Fall geprüft werden, ob die Selektionsmethode gepuffert werden kann.

Abbildung 100: Alternative Suchpfade
Im relationalen Datenmodell sind Entitäten meist durch einen formalen Schlüssel

repräsentiert. In der Realität werden diese Entitäten aber oft durch eines oder
mehrere ihrer Attribute identifiziert. Zum Beispiel ist der Schlüssel für eine Person
die Personalnummer. Ein Mensch wird eine andere Person aber im allgemeinen
durch ihren Namen und eventuell noch ihre Adresse beschreiben.
Welche Attribute zur Identifikation einer Entität herangezogen werden, kann
von Benutzer zu Benutzer oder von Situation zu Situation verschieden sein.
Diese Attribute möchte ein Benutzer auch nutzen können, um im Rahmen einer
Eingabehilfe den gewünschten Wert für ein Feld bestimmen zu können, das die
Eingabe eines formalen Schlüssels verlangt.
Es besteht also Bedarf nach Suchpfaden, die einen Zugriff auf die Daten über
Nichtschlüsselfelder ermöglichen. Dabei sollte es möglich sein, für ein Feld
mehrere verschiedene Suchpfade anzubieten.
Ein Suchpfad zu einem Feld kann durch eine Suchhilfe der bisher beschriebenen
Form realisiert werden. Zur Beschreibung einer Eingabehilfe mit mehreren
alternativen Suchpfaden kann im SAP System eine Menge von Suchhilfen zu
einem neuen Objekt zusammengefaßt werden. Da dieses Objekt wieder die
Beschreibung der Eingabehilfe zu einem Feld ist, wird es ebenfalls als Suchhilfe
bezeichnet.
Im Unterschied zu den bisher beschriebenen elementaren Suchhilfen werden die
Suchhilfen, die zur Zusammenfassung mehrerer Suchpfade angelegt werden, als
Sammelsuchhilfen bezeichnet.
In manchen Fällen werden Sammelsuchhilfen auch genutzt, um eine Zerlegung der
möglichen Eingaben für ein Feld in mehrere (disjunkte) Datenbestände abzubilden.

Abbildung 101: Sammelsuchhilfen und elementare Suchhilfen
Genauso wie eine elementare Suchhilfe besitzt eine Sammelsuchhilfe eine

Schnittstelle aus IMPORT- und EXPORT-Parametern, über die sie ihren
Datenaustausch vornimmt. Über diese Schnittstelle kann die Sammelsuchhilfe
genau wie eine elementare Suchhilfe an Felder, Tabellen und Datenelemente
angebunden werden.
An ein Feld, eine Tabelle bzw. ein Datenelement kann immer nur eine Suchhilfe
angebunden werden. Die Anbindung mehrerer Suchpfade geschieht also immer
durch Anbinden einer Sammelsuchhilfe.
Die Bestandteile zur Beschreibung des Dialogverhaltens und der Datenselektion
entfallen bei der Definition einer Sammelsuchhilfe. An diese Stelle tritt die
Aufzählung der inkludierten Suchhilfen. Dabei ist bei jeder Inklusion noch
eine Zuordnung zwischen den Parametern der Sammelsuchhilfe und den
Schnittstellenparametern der inkludierten Suchhilfe vorzunehmen.
Eine Suchhilfe kann auch in mehrere Sammelsuchhilfen inkludiert werden und
zugleich noch selbst an Felder, Tabellen und Datenelemente angebunden werden.
Auch ist es erlaubt, eine Sammelsuchhilfe wieder in eine Sammelsuchhilfe zu
inkludieren.
Bei der Verwendung einer Sammelsuchhilfe werden dem Benutzer die in der
Sammelsuchhilfe enthaltenen elementaren Suchhilfen als parallele Registerkarten
angeboten. Wenn Sie eine Sammelsuchhilfe zum wiederholten Mal benutzen, so
ist automatisch die zuletzt verwendete Registerkarte aktiv. Dies trägt der Tatsache
Rechnung, daß die meisten Benutzer immer wieder den selben Suchpfad wählen.
SAP-Suchhilfen erweitern:

Abbildung 102: Append-Suchhilfen
Die Menge der für ein Objekt sinnvollen Suchpfade hängt stark von den
besonderen Gegebenheiten beim jeweiligen SAP-Kunden ab. Daher besteht
oft der Wunsch, Sammelsuchhilfen des SAP Standards um eigene elementare
Suchhilfen zu erweitern. Ab Release 4.6 steht eine Appendtechnik zur Verfügung,
die die modifikationsfreie Erweiterung von Sammelsuchhilfen erlaubt.
Eine Append-Suchhilfe ist eine Sammelsuchhilfe, die einer anderen
Sammelsuchhilfe (ihrer Appendierenden) fest zugeordnet ist und diese um die in
sie inkludierten Suchhilfen erweitert.
Die Append-Suchhilfe übernimmt die Schnittstelle ihrer Appendierenden. Die
Append-Suchhilfe liegt dabei im Namensraum des Kunden. Im Normalfall werden
die in die Append-Suchhilfe inkludierten Suchhilfen ebenfalls vom Kunden
angelegt und liegen in dessen Namensraum. Es ist aber auch möglich, daß die
benötigte elementare Suchhilfe schon von SAP bereit gestellt ist und vom Kunden
nur noch in seine Append-Suchhilfe aufgenommen werden muß.
Innerhalb der SAP werden Append-Suchhilfen benutzt, um eine bessere
Komponententrennung zu erreichen. Einige SAP-Sammelsuchhilfen
besitzen daher bereits im Standard eine oder mehrere Append-Suchhilfen.
Kundenerweiterungen sollten aber immer durch das Anlegen einer eigenen
Append-Suchhilfe vorgenommen werden.
SAP-Sammelsuchhilfen beinhalten oft elementare Suchhilfen, die nicht von allen
Kunden benötigt werden. Die nicht benötigten Suchhilfen können mit Hilfe
einer Append-Suchhilfe ausgeblendet werden. Dazu muß die entsprechende
Suchhilfe in die Append-Suchhilfe aufgenommen werden, wobei das Kennzeichen
ausgeblendet zu setzen ist.

Abbildung 103: View als Selektionsmethode einer Suchhilfe
Ist die Selektionsmethode einer Suchhilfe ein Datenbank-View, so werden in der

Eingabehilfe nur solche Sätze angezeigt, zu denen in allen am View beteiligten
Tabellen Einträge vorhanden sind (Inner Join). Es gibt Fälle, in denen die Menge
der möglichen Eingaben durch die Einträge in einer Primärtabelle beschrieben
wird, zu denen jeweils optionale Zusatzinformation aus weiteren Sekundärtabellen
hinzuzufügen ist. Diese Sicht auf die Daten kann im SAP System über einen
Help-View realisiert werden. Bei Help-Views wird die selbe Outer Join Logik
verwendet wie bei Pflege-Views.
Die Definition eines Help-Views erfolgt analog zur Definition eines Pflege-Views.
Help-Views können nur als Selektionsmethoden in Suchhilfen verwendet werden.
Das SAP System kann die Selektion auf einen Help-View nicht direkt an die
Datenbank weitergeben, sondern muß eigene Zugriffsroutinen generieren. Daher
ist der Datenbank-View dem Help-View als Selektionsmethode vorzuziehen.
Die Selektion über Tabelle und Texttabelle entspricht der Selektion über einen
virtuellen Help-View. Daher sollte für diesen Fall kein virtueller Help-View
angelegt werden.
Ausnahme: In der Tabelle ist ein Feld, das namensgleich zu einem
Nichtschlüsselfeld der Texttabelle ist. Wird dieses Feld der Texttabelle in der
Suchhilfe benötigt, so muß ein Help-View über die beiden Tabellen angelegt
werden, da das Feld in der Suchhilfe nicht direkt angesprochen werden kann.
Es ist üblich, die Namen von Help-Views mit dem Präfix H_ beginnen zu
lassen. Daher liegen Views, die mit den Präfixen H_Y oder H_Z beginnen, im
Kundennamensraum.

Abbildung 104: Weitere Optionen bei Suchhilfen
Durch die Zuordnung eines Defaultwerts kann ein Parameter mit einem Wert
vorbelegt werden. Der Parameter erhält diesen Wert dann immer, es sei denn, es
handelt sich um einen IMPORT-Parameter, der mit einem Feld des Dynpros,
seines Modulpools oder mit einem Parameter der inkludierenden Sammelsuchhilfe
verbunden ist.
Defaultwerte können sein: Literale, Systemfelder und GET-Parameter.
Ein Defaultwert kann auch genutzt werden, um eine einfache Selektionsbedingung
an ein Feld der Selektionsmethode zu formulieren.
Elementaren Suchhilfen kann ein einzelner Buchstabe oder eine Ziffer als
Kurzanwahl zugeordnet werden. Steht diese elementare Suchhilfe bei einem
Bildschirmfeld für die Eingabehilfe zur Verfügung und befindet sich in diesem Feld
bei Aufruf der Eingabehilfe die Kurznotation =<Kurzanwahl>.<SEL1>.<SEL2>,
so wird diese elementare Suchhilfe prozessiert. Dabei werden <SEL1>, <SEL2>
als Inhalte für die Felder des Popups zur Werteeinschränkung genommen (durch
ein * am Ende ergänzt) und dann direkt die Trefferliste angezeigt.
In einer Sammelsuchhilfe können einzelne Suchhilfeinklusionen ausgeblendet
werden. Somit besteht die Möglichkeit einzelne Suchpfade, die in einem System
nicht erwünscht sind, dort zu deaktivieren. Diese Ausblendung sollte aber im
Normalfall in einer Append-Suchhilfe vorgenommen werden, da sie dann ohne
Modifikation erfolgen kann.
Parameter einer elementaren Suchhilfe können auf dem Popup zur
Werteeinschränkung als reine Anzeigefelder ausgewiesen werden. Generell
werden IMPORT-Parameter, denen nicht änderbare Felder des Dynpros
zugeordnet sind, auf diesem Popup nicht änderbar angezeigt.

Abbildung 105: Abweichung vom Standard: Suchhilfe-Exit
Eine Suchhilfe ist ein Objekt, das eine Eingabehilfe im Rahmen eines
systemweiten Standards beschreibt. In manchen Fällen erfordert die spezielle
Semantik eines Feldes, in Details von diesem Standard abzuweichen. Eine solche
Abweichung kann durch ein Suchhilfe-Exit realisiert werden.
Ein Suchhilfe-Exit ist ein Funktionsbaustein, der eine genormte Schnittstelle
besitzt. Als Vorlage kann der Funktionsbaustein F4IF_SHLP_EXIT_EXAMPLE
verwendet werden. Besitzt eine Suchhilfe ein solches Suchhilfe-Exit, so wird
dieses vor jedem Einzelschritt des Ablaufs aufgerufen. Über die Schnittstelle
werden ihm dabei die Verwaltungsdaten des Hilfeprozessors übergeben. Das
Suchhilfe-Exit kann diese Daten manipulieren.
Insbesondere enthalten die Verwaltungsdaten auch die Information über den
nächsten durchzuführenden Schritt. Das Suchhilfe-Exit kann nun vorbereitende
Aktionen für diesen Schritt ausführen oder aber den Schritt vollkommen selbst
übernehmen (z.B. eine Datenselektion, die nicht über ein SELECT auf eine
Tabelle oder einen View realisierbar ist). Im zweiten Fall wird das Suchhilfe-Exit
dann auch die Information über den nächsten durchzuführenden Schritt verändern.
Mit dem Präfix F4UT_ sind bereits einige Funktionsbausteine definiert, die
als Suchhilfe-Exits verwendet werden können oder die zur Manipulation der
Verwaltungsdaten in Suchhilfe-Exits genutzt werden können. Suchhilfe-Exits
sollten nur in Ausnahmefällen verwendet werden.
Suchhilfe-Exits bergen die Gefahr einer unnötigen Abweichung vom Standard und
erschweren die Wartung der Eingabehilfe.

Abbildung 106: Alternativanzeigen der Eingabehilfe
Das SAP-System erkennt drei Darstellungsformen für die Eingabehilfe:

• Listbox
• Control (amodal)
• SAP-Dialog (modal)
Die Listbox erlaubt keine Eingabe zusätzlicher Selektionsbedingungen und keine
Anzeige zusätzlicher Spalten auf der Trefferliste. Für überschaubare einspaltige
Listen ist die Listbox aber die benutzungsfreundlichste Art der Eingabehilfe.
Die Entscheidung, ein Feld als Listbox anzubieten, wird vom Entwickler einer
Anwendung getroffen und im Screen Painter für das entsprechende Feld hinterlegt.
Wird die Listbox vom Benutzer aufgerufen, so erfolgt die Beschaffung der
anzuzeigenden Daten nach dem im ABAP Dictionary oder Screen Painter für das
Feld hinterlegten Mechanismus für die Eingabehilfe. Genauere Informationen
zur Verwendung der Listbox erhalten Sie im Kurs BC410 – Entwicklung von
Benutzerdialogen.
Bei Feldern, die nicht als Listbox angeboten werden, kann die Darstellung
alternativ über ein amodales Control oder über einen mit SAP-Dynprotechnik
realisierten modalen Dialog erfolgen. Über Hilfe → Einstellungen kann jeder
Benutzer festlegen, welche Variante er bevorzugt. Diese Präsentationsform wird
dann für diesen Benutzer bei allen Eingabehilfen verwendet. Welche Wahl hierbei
Deafult ist, kann vom Systemadministrator festgelegt werden.

Das Control ist vor allem dann nützlich, wenn (etwa in einem Table Control)
mehrere Felder mit gleicher Eingabehilfe nacheinander gefüllt werden sollen.
Mit der Funktion Liste halten kann das Control aus der modalen Hilfe heraus
gestartet werden.

Übung 13: Suchhilfen

• Eingabehilfen über elementare Suchhilfen realisieren
• Eingabehilfen mit mehreren Suchpfaden über Sammelsuchhilfen definieren
• Zu Sammelsuchhilfen modifikationsfrei Suchpfade hinzufügen oder aus
ihnen ausblenden
Für viele Verwaltungstätigkeiten müssen die entsprechenden Sachbearbeiter nach
Daten von Mitarbeitern suchen. Hierfür sollen Sie geeignete Suchmöglichkeiten
zur Verfügung stellen.
Aufgabe:
Sie sollen eine einfache Suchhilfe für ein Eingabefeld anlegen.
1. Gehen Sie in die Anzeige der Tabelle ZDEPMENT##, und rufen Sie hier die
Funktion Hilfsmittel ->Tabelleninhalt ->Einträge erfassen auf.
Sie gelangen auf eine Eingabemaske, in der Sie neue Einträge für die Tabelle
ZDEPMENT## (z.B. neue Abteilungen) anlegen können. Hierbei soll auch
der Leiter der neuen Abteilungen festgelegt werden. Der entsprechende
Eintrag erfolgt im Feld Abteilungsleiter. Zur Unterstützung der Pflege
dieses Feldes sollte für dieses eine Eingabehilfe zur Verfügung stehen, die
die (Personalnummern der) Mitarbeiter anzeigt. Verifizieren Sie, daß das
genannte Feld bereits eine Eingabehilfe besitzt. Stellen Sie fest, welcher
Mechanismus der Eingabehilfe an dieser Stelle wirksam ist.
Ziel dieser Aufgabe ist es nun, die zur Prüftabelle ZEMPLOY## gehörende
Eingabehilfe benutzungsfreundlicher zu gestalten. Sie können den Erfolg
durch erneuten Aufruf der oben beschriebenen Eingabehilfe später
kontrollieren. Um dies zu erreichen, müssen Sie eine elementare Suchhilfe
ZEMPLOY##_ESH1 anlegen. Auf der Trefferliste sollen dabei die
folgenden Merkmale in dieser Reihenfolge erscheinen:
Fluggesellschaft
Vorname
Nachname
Personalnummer

Wegen der großen Zahl der Mitarbeiter soll der Benutzer vor der Anzeige
der Treffermenge auf jeden Fall die Möglichkeit erhalten, die angezeigten
Werte durch Angabe von Nach- und/oder Vorname der gesuchten Person
einzuschränken. Berücksichtigen Sie dabei, daß die Einschränkung über den
Nachnamen wesentlich häufiger genutzt wird als die über den Vornamen.
Wurde vor dem Aufruf der Eingabehilfe bereits eine Fluggesellschaft
spezifiziert, so sollen auch nur deren Mitarbeiter angeboten werden.
Andernfalls soll ein eventuell auf der Eingabemaske befindliches
Eingabefeld für die Fluggesellschaft ebenfalls gefüllt werden, wenn Sie den
Mitarbeiter auswählen. Sorgen Sie dafür, daß die definierte Suchhilfe für die
Prüftabellenhilfe der Tabelle ZEMPLOY## genutzt wird, und kontrollieren
Sie den Erfolg wie oben beschrieben.
2. Damit die soeben angelegte Suchhilfe die Prüftabellenhilfe der
Tabelle ZEMPLOY## (und somit auch die Eingabehilfe des Feldes
ZDEPMENT##-Abteilungsleiter) verbessert, muß sie noch an die Tabelle
ZEMPLOY## angebunden werden.
3. Für die Suche nach Mitarbeitern sollen eventuell noch weitere Suchpfade
angeboten werden. Führen Sie dazu die folgenden vorbereitenden
Maßnahmen durch:
Kopieren Sie die Suchhilfe SAREA in Ihre neue Suchhilfe ZEM-
PLOY##_AREA. Ändern Sie die Parameter, die Selektionsmethodentabelle
und die Datenelemente in Ihrer Kopie so, dass sie sich auf die in Ihrer Tabelle
verwendeten Namen beziehen anstatt auf die Namen in der Originaltabelle.
Prüfen und aktivieren Sie die Suchhilfe. Kopieren Sie die Suchhilfe
SDEPT in Ihre neue Suchhilfe ZEMPLOY##_DEPT. Ändern Sie sie
entsprechend und aktivieren Sie sie (wie oben). Kopieren Sie die Suchhilfe
ZEMPLOY##_DEPT nach ZEMPLOY##_CSH und wandeln Sie die
neue Kopie in eine Sammelsuchhilfe um. Nehmen Sie die Suchhilfen
ZEMPLOY##_ESH1, ZEMPLOY##_AREA und ZEMPLOY##_DEPT als
Komponenten in die neue Sammelsuchhilfe auf.
Ändern Sie die für die Prüftabellenhilfe von Tabelle ZEMPLOY## definierte
Suchhilfe und überprüfen Sie Ihren Erfolg.
4. Ihre geschäftlichen Anforderungen haben sich geändert und machen die
Suche nach Mitarbeitern erforderlich. Der Suchpfad, mit dem Mitarbeiter
über ihre Abteilungen gesucht werden können, ist gegenwärtig nicht
erwünscht.
Verändern Sie die Eingabehilfe des Feldes ZDEPMENT##-Abteilungsleiter
entsprechend diesen Vorgaben, ohne die Suchhilfe ZEMPLOY##_CSH
(oder eine beteiligte Tabelle) zu modifizieren. Legen Sie dazu eine
Append-Suchhilfe für ZEMPLOY##_CSH an. Dieses Append sollte
die Suchhilfe ZEMPLOY##_DEPT als verborgene Suchhilfe enthalten.
Überprüfen Sie Ihren Erfolg.

Lösung 13: Suchhilfen

Aufgabe:
Sie sollen eine einfache Suchhilfe für ein Eingabefeld anlegen.
1. Gehen Sie in die Anzeige der Tabelle ZDEPMENT##, und rufen Sie hier die
Funktion Hilfsmittel ->Tabelleninhalt ->Einträge erfassen auf.
Sie gelangen auf eine Eingabemaske, in der Sie neue Einträge für die Tabelle
ZDEPMENT## (z.B. neue Abteilungen) anlegen können. Hierbei soll auch
der Leiter der neuen Abteilungen festgelegt werden. Der entsprechende
Eintrag erfolgt im Feld Abteilungsleiter. Zur Unterstützung der Pflege
dieses Feldes sollte für dieses eine Eingabehilfe zur Verfügung stehen, die
die (Personalnummern der) Mitarbeiter anzeigt. Verifizieren Sie, daß das
genannte Feld bereits eine Eingabehilfe besitzt. Stellen Sie fest, welcher
Mechanismus der Eingabehilfe an dieser Stelle wirksam ist.
Ziel dieser Aufgabe ist es nun, die zur Prüftabelle ZEMPLOY## gehörende
Eingabehilfe benutzungsfreundlicher zu gestalten. Sie können den Erfolg
durch erneuten Aufruf der oben beschriebenen Eingabehilfe später
kontrollieren. Um dies zu erreichen, müssen Sie eine elementare Suchhilfe
ZEMPLOY##_ESH1 anlegen. Auf der Trefferliste sollen dabei die
folgenden Merkmale in dieser Reihenfolge erscheinen:
Fluggesellschaft
Vorname
Nachname
Personalnummer
Wegen der großen Zahl der Mitarbeiter soll der Benutzer vor der Anzeige
der Treffermenge auf jeden Fall die Möglichkeit erhalten, die angezeigten
Werte durch Angabe von Nach- und/oder Vorname der gesuchten Person
einzuschränken. Berücksichtigen Sie dabei, daß die Einschränkung über den
Nachnamen wesentlich häufiger genutzt wird als die über den Vornamen.
Wurde vor dem Aufruf der Eingabehilfe bereits eine Fluggesellschaft
spezifiziert, so sollen auch nur deren Mitarbeiter angeboten werden.
Andernfalls soll ein eventuell auf der Eingabemaske befindliches
Eingabefeld für die Fluggesellschaft ebenfalls gefüllt werden, wenn Sie den

Mitarbeiter auswählen. Sorgen Sie dafür, daß die definierte Suchhilfe für die
Prüftabellenhilfe der Tabelle ZEMPLOY## genutzt wird, und kontrollieren
Sie den Erfolg wie oben beschrieben.
a) Wählen Sie Suchhilfe im Einstiegsbild des ABAP Dictionary, und
geben Sie in das entsprechende Feld den Namen ZEMPLOY##_ESH1
ein.
b) Wählen Sie Anlegen. Bestätigen Sie im folgenden Dialogfenster, daß
Sie eine elementare Suchhilfe anlegen möchten.
c) Erfassen Sie eine Kurzbeschreibung für Ihre Suchhilfe.
d) Die Suchhilfe soll die Suche nach Mitarbeitern unterstützen.
Diese werden in der Tabelle ZEMPLOY## verwaltet. Also ist als
Selektionsmethode diese Tabelle (oder ein View auf diese) zu wählen.
Für die beschriebene Aufgabe reicht die Tabelle aus. Tragen Sie diese
in das Feld Selektionsmethode ein.
e) Um das beschriebene Verhalten zu erreichen, müssen Sie den Dialogtyp
Dialog mit Werteeinschränkung wählen.
f) Wählen Sie die Suchhilfeparameter über die F4-Hilfe aus. Es empfiehlt
sich, die Trefferliste mit den möglichen Suchhilfeparametern mittels
Liste halten festzuhalten, da die Hilfe dann nicht mehrfach aufgerufen
werden muß. Wählen Sie als Parameter die Felder Fluggesellschaft,
Vorname, Nachname und Personalnummer aus.
g) Markieren Sie alle Parameter als EXPORT-Parameter (Spalte
EXP). Markieren Sie das Merkmal, nach dem gesucht wird,
(z.B. Personalnummer) sowie die hierarchisch darüber stehende
Fluggesellschaft als IMPORT-Parameter (Spalte IMP). Letzteres stellt
sicher, daß ein entsprechender Eintrag auf der Eingabemaske (wie in
der Aufgabe beschrieben) berücksichtigt wird.
h) Um die Trefferliste zu gestalten, müssen Sie in der Spalte LPos
entsprechende Positionsnummern (z.B. 1, 2, 3, 4, 5) vergeben.
i) Um das Dialogfenster zur Werteeinschränkung zu gestalten, müssen
Sie in der Spalte SPos Positionsnummern vergeben. Tragen Sie also
in diese Spalte bei den Parametern Vorname und Nachname positive
Zahlen ein, wobei der Wert bei Nachname kleiner sein soll als der
bei Vorname.
j) Aktivieren Sie Ihre Suchhilfe. Die Suchhilfe wirkt nun noch nicht beim
Feld ZDEPMENT##-Abteilungsleiter. Sie können die Suchhilfe aber
mit der Funktion Testen sofort ausprobieren.

2. Damit die soeben angelegte Suchhilfe die Prüftabellenhilfe der

Tabelle ZEMPLOY## (und somit auch die Eingabehilfe des Feldes
ZDEPMENT##-Abteilungsleiter) verbessert, muß sie noch an die Tabelle
ZEMPLOY## angebunden werden.
a) Gehen Sie im Änderungsmodus in die Pflege dieser Tabelle. Wählen
Sie hier Springen->Suchhilfe->für Tabelle. Geben Sie im folgenden
Dialogfenster den Namen der Suchhilfe ZEMPLOY##_ESH1 an.
Wählen Sie Weiter.
b) Der vom System erzeugte Vorschlag für die Zuordnung der
Suchhilfeparameter zu den Schlüsselfeldern der Tabelle ist vermutlich
bereits korrekt. Prüfen Sie dies, und übernehmen Sie die Definition.
c) Aktivieren Sie Tabelle ZEMPLOY##.
d) Rufen Sie nun erneut Einträge erfassen für die Tabelle ZDEPMENT##
auf. Die Eingabehilfe des Feldes Abteilungsleiter sollte sich nun wie
gewünscht verhalten.
3. Für die Suche nach Mitarbeitern sollen eventuell noch weitere Suchpfade
angeboten werden. Führen Sie dazu die folgenden vorbereitenden
Maßnahmen durch:
Kopieren Sie die Suchhilfe SAREA in Ihre neue Suchhilfe ZEM-
PLOY##_AREA. Ändern Sie die Parameter, die Selektionsmethodentabelle
und die Datenelemente in Ihrer Kopie so, dass sie sich auf die in Ihrer Tabelle
verwendeten Namen beziehen anstatt auf die Namen in der Originaltabelle.
Prüfen und aktivieren Sie die Suchhilfe. Kopieren Sie die Suchhilfe
SDEPT in Ihre neue Suchhilfe ZEMPLOY##_DEPT. Ändern Sie sie
entsprechend und aktivieren Sie sie (wie oben). Kopieren Sie die Suchhilfe
ZEMPLOY##_DEPT nach ZEMPLOY##_CSH und wandeln Sie die
neue Kopie in eine Sammelsuchhilfe um. Nehmen Sie die Suchhilfen
ZEMPLOY##_ESH1, ZEMPLOY##_AREA und ZEMPLOY##_DEPT als
Komponenten in die neue Sammelsuchhilfe auf.

Ändern Sie die für die Prüftabellenhilfe von Tabelle ZEMPLOY## definierte
Suchhilfe und überprüfen Sie Ihren Erfolg.
a) Geben Sie auf dem Einstiegsbild des Dictionary im Namensfeld der
Suchhilfe SAREA ein und wählen Sie Kopieren. Ändern Sie den
Suchhilfenamen im Feld nach auf ZEMPLOY##_AREA und wählen
Sie Weiter. Wählen Sie Ändern für die neue Suchhilfe.
b) Ändern Sie die Selektionsmethodentabelle in ZEMPLOY##. Ändern
Sie die Parameternamen so, dass Sie den Tabellenfeldern entsprechen,
indem Sie den Parameter und die Eingabehilfe auswählen. Auf diese
Weise wird auch der Datenelementbezug korrigiert. Korrigieren Sie
die anderen Angaben nach Bedarf, führen Sie eine Syntaxprüfung der
Definition durch und aktivieren Sie die Suchhilfe.
c) Wiederholen Sie Schritte a) und b) zum Anlegen der Suchhilfe
ZEMPLOY##_DEPT unter Verwedung der Vorlage SDEPT.
d) Kopieren Sie die Suchhilfe ZEMPLOY##_DEPT nach
ZEMPLOY##_CSH. Rufen Sie auf dem Suchhilfenpflegebild
Bearbeiten ® Suchhilfetyp ändern auf und bestätigen Sie die Änderung.
e) Fügen Sie einen Import-Parameter für den Bereich ein. Dieser muss
auf das Datenelement verweisen, das Sie für ZEMPLOY##-Bereich
verwendet haben.
f) Wählen Sie die Registerkarte Inkludierte Suchhilfen. Geben Sie die
Suchhilfe ZEMPLOY##_ESH1 ein.
g) Positionieren Sie den Cursor auf die soeben eingetragene Suchhilfe.
Wählen Sie Parameterzuordnung. Lassen Sie sich einen Vorschlag für
die Zuordnung erzeugen.
h) Der Vorschlag ist vermutlich bereits korrekt. Prüfen Sie den Vorschlag
zur Sicherheit und übernehmen Sie ihn dann.
i) Wiederholen Sie die Schritte 4 – 6 für die inkludierten Suchhilfen
ZEMPLOY##_AREA und ZEMPLOY##_DEPT.
j) Aktivieren Sie die Suchhilfe ZEMPLOY##_CSH.
k) Gehen Sie zum Pflegebild für Tabelle ZEMPLOY##, um die Suchhilfe
für die Tabelle zu ändern. Wählen Sie Springen->Suchhilfe->Für
Tabelle und ändern Sie den Suchhilfenamen in ZEMPLOY##_CSH.
Lassen Sie sich vom System einen Vorschlag erstellen, kontrollieren
und übernehmen Sie ihn. Aktivieren Sie Tabelle ZEMPLOY##.
l) Durch Aufruf der Eingabehilfe für das Feld ZDEPMENT##-
Abteilungsleiter können Sie feststellen, dass die Eingabehilfe
unverändert funktioniert und eine Sammelsuchhilfe jetzt wirksam ist.

4. Ihre geschäftlichen Anforderungen haben sich geändert und machen die

Suche nach Mitarbeitern erforderlich. Der Suchpfad, mit dem Mitarbeiter
über ihre Abteilungen gesucht werden können, ist gegenwärtig nicht
erwünscht.
Verändern Sie die Eingabehilfe des Feldes ZDEPMENT##-Abteilungsleiter
entsprechend diesen Vorgaben, ohne die Suchhilfe ZEMPLOY##_CSH
(oder eine beteiligte Tabelle) zu modifizieren. Legen Sie dazu eine
Append-Suchhilfe für ZEMPLOY##_CSH an. Dieses Append sollte
die Suchhilfe ZEMPLOY##_DEPT als verborgene Suchhilfe enthalten.
Überprüfen Sie Ihren Erfolg.
a) Da die gewünschten Änderungen ohne Modifikationen an bereits
bestehenden Objekten vorgenommen werden sollen, muß eine
Append-Suchhilfe zur Sammelsuchhilfe ZEMPLOY##_CSH angelegt
werden.
b) Gehen Sie im Anzeigemodus auf das Pflegebild für die Suchhilfe
ZEMPLOY##_CSH. Wählen Sie Springen->Append-Suchhilfen.
c) Im folgenden Dialogfenster wird Ihnen bereits ein Name für die
Append-Suchhilfe vorgeschlagen. Sie können diesen übernehmen.
d) Erfassen Sie eine Kurzbeschreibung für die Append-Suchhilfe.
e) Wählen Sie die Registerkarte Inkludierte Suchhilfen.
f) Tragen Sie ZEMPLOY##_DEPT in die Liste der inkludierten
Suchhilfen ein. Markieren Sie die Spalte Ausgeblendet für den Eintrag.
g) Positionieren Sie den Cursor auf den Namen der Suchhilfe
ZEMPLOY##_DEPT und wählen Sie Parameterzuordnung. Bestätigen
Sie im folgenden Dialogfenster, daß Sie sich einen Vorschlag für die
Parameterzuordnung erstellen lassen möchten.
h) Die vom System vorgeschlagene Parameterzuordnung ist vermutlich
schon korrekt. Kontrollieren Sie dies, und übernehmen Sie die
Zuordnung.
i) Aktivieren Sie Ihre Append-Suchhilfe.
j) Durch Aufruf der Eingabehilfe für das Feld ZDEPMENT##-
Abteilungsleiter können Sie den Erfolg kontrollieren.


Nun können Sie
vorliegt
erweitern


Nun können Sie
vorliegt
erweitern

Zusammenfassung der Schulung BC430
Zusammenfassung der Schulung

Nun können Sie
• Das ABAP Dictionary mit seinen Services verwenden und beschreiben
Weiterführende Informationen
• Für weitere Informationen verwenden Sie bitte die Onlinehilfe, oder den
Servicemarktplatz der SAP ( http://service.sap.com)

Feedback
Die SAP AG hat sich bei der Erstellung dieser Schulung um Genauigkeit
und Vollständigkeit bemüht. Wenn Sie Korrekturwünsche oder
Verbesserungsvorschläge zu dieser Schulung haben, notieren Sie diese bitte an der
entsprechenden Stelle auf dem Schulungsbewertungsbogen.

BC430 ABAP Dictionary

Hochgeladen von

Dokumentinformationen

Beschreibung:

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Beschreibung:

Copyright:

Verfügbare Formate

BC430 ABAP Dictionary

Hochgeladen von

Beschreibung:

Copyright:

Verfügbare Formate

BC430

An SAP course - use it to learn, reference it for work

Copyright © 2007 SAP AG. Alle Rechte vorbehalten.

Die von SAP AG oder deren Vertriebsfirmen angebotenen Software-Produkte können

Beispieltext Wörter oder Zeichen, die vom Bildschirmbild zitiert

Beispieltext Hervorgehobene Wörter oder Ausdrücke im Fließtext,

BEISPIELTEXT Namen von Systemobjekten. Dazu gehören

Beispieltext Ausgabe auf dem Bildschirmbild. Dazu gehören

Beispieltext Exakte Benutzereingabe. Dazu gehören Wörter oder

<Beispiel- Variable Benutzereingabe. Die Wörter und Zeichen in

2006/Q2 © 2007 SAP AG. Alle Rechte vorbehalten. iii

Für mehr Information, Hinweise oder Hintergründe

Bemerkung oder weitere Erklärung zum

Ausnahme oder Gefahr

Gibt an, dass der Abschnitt in der Präsentation des

iv © 2007 SAP AG. Alle Rechte vorbehalten. 2006/Q2

Kapitel 1: Einführung ins Dictionary .................................. 1

Kapitel 2: Datenobjekte im ABAP Dictionary........................ 9

Kapitel 3: Performance beim Tabellenzugriff...................... 77

Kapitel 4: Eingabeprüfungen......................................... 103

Kapitel 5: Abhängigkeiten bei Objekten ........................... 133

Kapitel 6: Änderungen an Tabellen ................................. 147

Kapitel 7: Views und Pflegedialoge................................. 175

Kapitel 8: Suchhilfen ................................................... 211

2006/Q2 © 2007 SAP AG. Alle Rechte vorbehalten. v

vi © 2007 SAP AG. Alle Rechte vorbehalten. 2006/Q2

• ABAP-Entwickler und Administratoren, die globale Datenobjekte,

Voraussetzungen für die Teilnahme

Ziele der Schulung

• die Funktion des ABAP Dictionary im R/3 System zu beschreiben

Lernziele der Schulung

2006/Q2 © 2007 SAP AG. Alle Rechte vorbehalten. vii

• Das ABAP Dictionary mit seinen Services verwenden und beschreiben

Informationen über die SAP-Softwarekomponenten

viii © 2007 SAP AG. Alle Rechte vorbehalten. 2006/Q2

Überblick über das Kapitel

Lernziele des Kapitels

• die Funktion des ABAP Dictionary im R/3-System nennen

Inhalt des Kapitels

2006/Q2 © 2007 SAP AG. Alle Rechte vorbehalten. 1

Lektion: Überblick der Funktionen des ABAP Dicitonary

Überblick über die Lektion

Lernziele der Lektion

Überblick der Funktionen

Abbildung 1: Funktion des ABAP Dictionary

2 © 2007 SAP AG. Alle Rechte vorbehalten. 2006/Q2

Abbildung 2: Datenbankobjekte im ABAP Dictionary

Im ABAP Dictionary können Tabellen und Datenbank-Views definiert werden.

2006/Q2 © 2007 SAP AG. Alle Rechte vorbehalten. 3

Abbildung 3: Typdefinitionen im ABAP Dictionary

Es gibt drei unterschiedliche Kategorien im ABAP Dictionary:

4 © 2007 SAP AG. Alle Rechte vorbehalten. 2006/Q2

Abbildung 4: Services des ABAP Dictionary

Das ABAP Dictionary unterstützt die Programmentwicklung durch eine Reihe

2006/Q2 © 2007 SAP AG. Alle Rechte vorbehalten. 5

Abbildung 5: Einbindung in Entwicklungs- und Laufzeitumgebung

Das ABAP Dictionary ist aktiv in die Entwicklungsumgebung und die

6 © 2007 SAP AG. Alle Rechte vorbehalten. 2006/Q2

Zusammenfassung der Lektion

2006/Q2 © 2007 SAP AG. Alle Rechte vorbehalten. 7

Zusammenfassung des Kapitels