TAW12_1 - ABAP Workbench Konzepte
March 3, 2017 | Author: Darren Giles | Category: N/A
Short Description
Download TAW12_1 - ABAP Workbench Konzepte...
Description
TAW12 ABAP Workbench Konzepte (1/3)
TAW12 1/3 ABAP Workbench Konzepte © SAP AG 2002 © SAP AG
R/3 System Release 4.6D oder höher Dezember 2002 Materialnummer 5006 0756
© SAP AG
TAW12
0-1
Copyright
Copyright 2003 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. Alle Rechte vorbehalten.
© SAP AG 2002
Warenzeichenvermerke Die von SAP AG oder deren Vertriebsfirmen angebotenen Software-Produkte können SoftwareKomponenten auch anderer Software-Hersteller enthalten. ® ® ® ® ® ® ® Microsoft , WINDOWS , NT , EXCEL , Word , PowerPoint und SQL Server sind eingetragenen 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. ® ® TM INFORMIX -OnLine for SAP und INFORMIX Dynamic Server sind eingetragene Marken der Informix Software Incorporated. ® ® ® ® UNIX , X/Open , OSF/1 und Motif sind eingetragene Marken der Open Group. ® 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.
© SAP AG
TAW12
0-2
Development Consultant mySAP Technology – ABAP Workbench
TAW10
10 Tage
mySAP Technology ABAP Workbench Grundlagen
TAW12
15 Tage
mySAP Technology - ABAP Workbench Konzepte
Zertifizierung zum Development Consultant – mySAP Technology – ABAP Workbench
© SAP AG 2002
© SAP AG
TAW12
0-3
Voraussetzungen für Teilnehmer
Erforderlich z TAW10: mySAP Technology - ABAP Workbench Grundlagen oder vergleichbare Kenntnisse
© SAP AG 2002
© SAP AG
TAW12
0-4
Zielgruppe
Zielgruppe
?
z Entwicklungsberater und Entwickler, die für die Anpassung und Entwicklung von betriebswirtschaftlichen Anwendungen in ABAP/ABAP Objects verantwortlich sind
Dauer z 15 Tage
?
© SAP AG 2002
© SAP AG
TAW12
0-5
Zielsetzungen
Nach dem Besuch dieser Schulung können Sie: z Die Konzepte der Programmiersprache ABAP
beschreiben z Die Programmiersprache ABAP sowie die
Werkzeuge der ABAP Workbench anwenden, um eigene betriebswirtschaftliche Anwendungen zu entwickeln oder um individuelle Anpassungen an SAP-Standardsoftware vorzunehmen z Ihr Wissen als Junior-Berater in einer ersten
Praxisphase direkt anwenden
© SAP AG 2002
© SAP AG
TAW12
0-6
Inhaltsverzeichnis: mySAP Technology – ABAP Workbench Grundlagen
Vorspann Komplex
mySAP.com Technologien
Komplex
ABAP Workbench Grundlagen
Komplex
ABAP Objects Fallstudie
© SAP AG 2002
Diese Schulung der SAP Consultant Education beinhaltet verschiedene Einzelkurse (Abschnitte), welche jeweils ein separates Thema behandeln. Jeder Einzelkurs (Abschnitt) ist jeweils in verschiedene Kapitel unterteilt.
© SAP AG
TAW12
0-7
Inhaltsverzeichnis: mySAP Technology – ABAP Workbench Konzepte
Vorspann Komplex
ABAP Dictionary
Komplex
Datenbankänderungen prorammieren
Komplex
Techniken der Listenerstellung
Komplex
Solution Manager
Entwicklung von Benutzerdialogen
Komplex
Erweiterungen und Modifikationen
Komplex
Fallstudie
© SAP AG 2002
Diese Schulung der SAP Consultant Education beinhaltet verschiedene Einzelkurse (Abschnitte), welche jeweils ein separates Thema behandeln. Jeder Einzelkurs (Abschnitt) ist jeweils in verschiedene Kapitel unterteilt.
© SAP AG
TAW12
0-8
Komplex: ABAP Dictionary
© SAP AG 1999
© SAP AG
TAW12
1-1
Inhaltsverzeichnis: ABAP Dictionary
Kapitel
Einführung
Kapitel
Abhängigkeiten bei ABAP Dictionary Objekten
Kapitel
Tabellen im ABAP Dictionary
Kapitel
Änderungen an Tabellen
Kapitel
Performance beim Tabellenzugriff
Kapitel
Views
Kapitel
Suchhilfen
Kapitel
Konsistenz durch Eingabeprüfungen
Anhang
© SAP AG 2002
© SAP AG
TAW12
1-2
Einführung
z Funktion des ABAP Dictionary im R/3 System z Definition von Datenbankobjekten z Benutzerdefinierte Typen z Services im ABAP Dictionary z Einbindung in die Entwicklungsumgebung und die
Laufzeitumgebung
© SAP AG 1999
© SAP AG
TAW12
2-1
Lernziele des Kurses
Nach Durcharbeiten dieses Kapitels können Sie: z Die Funktion des ABAP Dictionary im R/3-System
definieren z Die Möglichkeiten zur Definition von Datenobjekten
und Datentypen beschreiben z Die vom ABAP Dictionary angebotenen Services
beschreiben z Die Einbindung des ABAP Dictionary in die
Entwicklungsumgebung und die Laufzeitumgebung erläutern
© SAP AG 2002
© SAP AG
TAW12
2-2
Funktion des ABAP Dictionary
DB-Objekte
Typdefinitionen Struktur
Tabelle
DB-Tabelle Datenelemente
Tabellentyp
Services Mögl. Werte Dynpro F4
© SAP AG 2002
Das ABAP Dictionary ermöglicht die zentrale Verwaltung aller im R/3 System verwendeten Datendefinitionen. Im ABAP Dictionary können benutzerdefinierte Typen (Datenelemente, Strukturen und Tabellentypen) zur Verwendung in ABAP Programmen oder in Schnittstellen von Funktionsbausteinen angelegt werden. Auch Datenbankobjekte wie Tabellen und Datenbank-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.
© SAP AG
TAW12
2-3
Datenbankobjekte im ABAP Dictionary
View
Tabelle 1
Objekte werden automatisch auf der DB angelegt und an Veränderungen angepaßt
Tabelle 2
ABAP Dictionary
Datenbank © SAP AG 1999
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.
© SAP AG
TAW12
2-4
Typdefinitionen im ABAP Dictionary
Mitarbeiter Name
Vorname
Nachname
PLZ Ortsname
Anschrift Telefon
Ort
Anschrift
Nummern
Straße Hausnr
© SAP AG 2002
Es gibt drei unterschiedliche Kategorien im ABAP Dictionary: y Datenelemente: Beschreiben durch Angabe von Datentyp, Länge und gegebenenfalls Dezimalstellen einen elementaren Typ. y Strukturen: Bestehen aus Komponenten, die einen beliebigen Typ haben können. y 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.
© SAP AG
TAW12
2-5
Services des ABAP Dictionary
Fluggesellschaft LH Nr.
Pflege von Flügen Fluggesellschaft
Ankunftsort
0400
Frankfurt
New York
0402
Frankfurt
New York
2402
Frankfurt
Berlin
...
LH
Abflugort
...
...
F4
Flugnummer
... F1 Code der Flugverbindung Code, der eine Flugverbindung zwischen zwei Städten definiert, z.B. 0400 Frankfurt - New York.
© SAP AG 2002
Das ABAP Dictionary unterstützt die Programmentwicklung durch eine Reihe von Services: y Über Suchhilfen können Eingabehilfen (F4-Hilfen) für Dynprofelder definiert werden. y Dynprofeldern kann durch Erfassen einer Dokumentation zum Datenelement auf einfache Weise eine Feldhilfe (F1-Hilfe) zugeordnet werden. y Über Fremdschlüssel kann für Dynprofelder auf einfache Art eine Eingabeprüfung definiert werden, die die Konsistenz eingegebener Werte sicherstellt. y 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. y Für Datenbankobjekte (Tabellen, Views) kann über Einstellungen zur Pufferung die Performance beim Zugriff auf deren Daten erhöht werden. y Über die Protokollierung kann eine automatische Aufzeichnung von Änderungen an Tabelleneinträgen eingeschaltet werden.
© SAP AG
TAW12
2-6
Einbindung in Entwicklungs- und Laufzeitumgebung Entwicklungsumgebung Screen Painter
liest Struktur der Datenbankobjekte
DatenbankSchnittstelle
ABAP Werkzeuge Lesen Typdefinitionen
ABAP Dictionary
Laufzeitumgebung DynproInterpreter ABAP Interpreter © SAP AG 1999
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: y 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. y 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. y Die Datenbank-Schnittstelle nutzt die im ABAP Dictionary abgelegten Informationen zu Tabellen bzw. Datenbank-Views für den Zugriff auf die Daten dieser Objekte.
© SAP AG
TAW12
2-7
Zusammenfassung (des Kapitels)
z Das ABAP Dictionary dient zur Verwaltung von
Datendefinitionen. z Im ABAP Dictionary können benutzerdefinierte Typen
angelegt werden. Diese können z.B. in ABAP Programmen verwendet werden. z Tabellen und Datenbank-Views werden im ABAP Dictionary
definiert und mit dieser Definition dann automatisch auf der unterliegenden Datenbank angelegt. z Das ABAP Dictionary stellt eine Reihe von Services zur
Verfügung, die die Programmentwicklung unterstützen. z Das ABAP Dictionary ist aktiv in Entwicklungs- und
Laufzeitumgebung integriert.
© SAP AG 2002
© SAP AG
TAW12
2-8
Tabellen im ABAP Dictionary
z Zweistufiges Domänenkonzept z Abbildung im relationalen Datenbanksystem z Include-Strukturen z Technische Einstellungen Datenart Größenkategorie Pufferung Protokollierung
© SAP AG 1999
© SAP AG
TAW12
3-1
Lernziele des Kurses
Nach Durcharbeiten dieses Kapitels können Sie: z Tabellen anlegen z Das zweistufige Domänenkonzept verwenden z Die technischen Einstellungen einer Tabelle
definieren z Include-Strukturen anlegen und verwenden
© SAP AG 2002
© SAP AG
TAW12
3-2
Tabelle - Feld
Tabelle Schl. 1 Schl. 2 Schl. n
F1
F2
Fn
Zeile
. . .
. . .
Schlüssel
. . .
. . .
. . .
. . .
Funktionsfelder
© SAP AG 2002
Die Struktur der Objekte der Anwendungsentwicklung werden in Tabellen auf der unterliegenden relationalen Datenbank abgebildet. Die Attribute dieser Objekte entsprechen Feldern der Tabelle. Eine Tabelle besteht aus Spalten (Felder) und Zeilen (Einträgen). Sie hat einen Namen und verschiedene 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.
© SAP AG
TAW12
3-3
Grundobjekte des ABAP Dictionary
Tabelle Tabellenfeld
verwendet Datenelement verwendet
Domäne Domäne
© SAP AG 2002
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 (F1Doku) 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.
© SAP AG
TAW12
3-4
Zweistufiges Domänenkonzept: Beispiel
Tabelle SPFLI MANDT CARRID CONNID ... AIRPFROM ... AIRPTO
Datenelement S_FROMAIRP
Datenelement S_TOAIRP
Domäne Domäne S_AIRPID
© SAP AG 2002
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.
© SAP AG
TAW12
3-5
Transparente Tabellen und Strukturen
ABAP Dictionary
Tabelle
Struktur Feld 1 Feld 2 Feld 3 Feld 4
Feld 1 Feld 2 Feld 3 Feld 4
Datenbank Tabelle Feld 1 Feld 2 Feld 3 Feld 4
physische Definition der Tabelle © SAP AG 2002
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.
© SAP AG
TAW12
3-6
Include-Strukturen
Tabelle 1 Feld 1
Feld 2
Feld A
Tabelle 2 Feld B
Feld 3
Feld A
Feld B
Feld A
Feld B
Feld 4
Include-Struktur
Datenbank
Feld 1
Feld 2
Feld A
Feld B
Feld 3
Feld A
Feld B
Feld 4
© SAP AG 1999
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.
© SAP AG
TAW12
3-7
Technische Einstellungen In welchen physischen Bereich der Datenbank soll die Tabelle abgelegt werden?
Datenart Größenkategorie Wieviele Sätze enthält die Tabelle vermutlich?
Pufferung
R/3 Tabellenpuffer
Sollen die Sätze der Tabelle gepuffert werden?
Protokollierung
Änderungen an den Datensätzen protokollieren?
© SAP AG 1999
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.
© SAP AG
TAW12
3-8
Datenart
Tabellen im ABAP Dictionary Stammdaten Organisationsdaten Bewegungsdaten
Systemdaten
Tabelle 1 Tabelle 3
Tabelle 2
Tabelle 5
Tabelle 7
Tabelle 4
Tabelle 6
Tabelle 9
Tabelle 8
Datenbank Tablespace Stammdaten
Tablespace Org.daten
Tablespace Beweg.daten
Tablespace Systemdaten
Tabelle 3
Tabelle 2
Tabelle 5
Tabelle 7
Tabelle 4
Tabelle 6
Tabelle 9
Tabelle 8
Tabelle 1
© SAP AG 1999
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 R/3-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.
© SAP AG
TAW12
3-9
Größenkategorie Technische Einstellungen Größenkategorie
Initial Extent
First Second Extent Extent
TABA
1
TABB
3
TABC
4
Datenbank
TABA TABB TABC © SAP AG 2002
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 ExtentGröß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.
© SAP AG
TAW12
3-10
Protokollierung ABAP Dictionary TAB protokollieren
Anwendungstransaktion TAB Feld 2 Feld 3 Feld 5
Verändern eines Satzes
Datenbank
System-Profile
... rec/client =ALL
...
TAB Feld 1
Protokolltabelle Feld 2
Feld 3
© SAP AG 2002
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 R/3-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 können über die Transaktion Tabellenhistorie (SCU3) anzeigen. Durch die Protokollierung schaffen Sie sich einen Flaschenhals im System: y Zusätzliche Schreibzugriffe, um jede Tabellenmodifikation zu protokollieren. y Die Protokollierungstabelle ist eine Tabelle auf die viele Benutzer parallel zugreifen wollen, dadurch entstehen Sperrsituationen, obwohl die User auf verschiedene Anwendungstabellen zugreifen!
© SAP AG
TAW12
3-11
Zusammenfassung (des Kapitels)
z Alle betriebswirtschaftlichen Daten werden in Form von
Tabellen verwaltet, deren Definition im ABAP Dictionary abgelegt ist. z Zur Tabellendefinition wird ein zweistufiges
Domänenkonzept benutzt. Die semantische Definition wird über Datenelemente und die technische über Domänen realisiert. z Die Felder von Include-Strukturen können in Tabellen
inkludiert werden. z 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.
© SAP AG 2002
© SAP AG
TAW12
3-12
Übungsdaten Erklärung der Symbole in den Übungen und Lösungen
Übungen Lösungen Lernziele des Kurses
Unternehmensszenario
Tips & Tricks
Warnung oder Achtung
Daten in den Übungen Art der Daten
Daten im Schulungssystem
Datenmodell BC_TRAVEL
ja
Alle Objekte aus Entwicklungsklasse BC_DATAMODEL
ja
Alle Objekte aus Entwicklungsklasse BC430
ja
Bitte beachten Sie beim Anlegen von ABAP Dictionary-Objekten im Rahmen dieses Kurses folgende Vereinbarungen: • Ihre Objektnamen für Tabellen, Datenelemente und Domänen sollten mit Z beginnnen und mir Ihrer zweistelligen Gruppennummer (xx) enden. • Für die Tabellenfelder sollten sowohl eigene Datenelemente bzw. Domänen (Zxx), als auch SAP-Standard-Objekte benutzt werden. • Alle Objekte sollten als lokale Objekte (Entwicklungsklasse $tmp) angelegt werden. Informationen zu dem in den Schulungen verwendeten Flugdatenmodell finden Sie im Anhang.
© SAP AG
TAW12
3-13
Tabellen im ABAP Dictionary Übungen Kapitel: Tabellen im ABAP
Dictionary
Am Ende dieser Übungen können Sie: Tabellen anlegen und das zweistufige Domänenkonzept verwenden Die technischen Einstellungen sinnvoll festlegen Felder dokumentieren Include-Strukturen anlegen und verwenden 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 (z.B. Name, Personalnummer, Gehalt, Abteilung, etc.) 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. Diese Tabellen werden in den folgenden Übungen dann Schritt für Schritt erweitert. 1-1
Legen Sie die zwei transparenten Tabellen ZEMPLOY## und ZDEPMENT## an und bestimmen Sie deren Schlüsselfelder. Beim Aktivieren der Tabellen definieren Sie die technischen Einstellungen. Beachten Sie dabei folgende Informationen: 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.
© SAP AG
TAW12
3-14
2-1-1 Legen Sie Tabelle ZEMPLOY## an. Hier werden die Daten zu den Mitarbeitern gepflegt. Neben Namen und Adressen sind hier auch die Gehälter der Mitarbeiter hinterlegt. Tabelle ZEMPLOY## Feldname
Datenelement
Domäne
Typ, Länge
Mandant
S_MANDT
MANDT
Fluggesellschaft
S_CARR_ID
S_CARR_ID
Personalnummer
eigenes
eigenes
Vorname
S_FNAME
S_FNAME
Nachname
S_LNAME
S_LNAME
Abteilungskürzel
eigenes
eigenes
CHAR, 4
Bereich
eigenes
eigenes
CHAR, 1
Gehalt
eigenes
eigenes
CURR, 10
NUMC, 10
2 Dezimalstelle n Währung
S_CURRCODE S_CURR
2-1-2 Legen Sie Tabelle ZDEPMENT## an. In dieser Tabelle sind die Abteilungen der Fluggesellschaften hinterlegt. Jede Abteilung ist über eine Telefon- und Faxnummer erreichbar. Tabelle ZDEPMENT## Feldname
Datenelement
Domäne
Typ, Länge
Mandant
S_MANDT
MANDT
Fluggesellschaft
S_CARR_ID
S_CARR_ID
Abteilungskürzel
eigenes
eigenes
CHAR, 4
Telefon
eigenes
S_PHONE
CHAR, 30
Faxnummer
eigenes
S_PHONE
CHAR, 30
2-2
Dokumentieren Sie die Felder Personalnummer und Abteilungskürzel.
2-3
Ä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. 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. Legen Sie für das Feld letzter Änderer ein neues Datenelement an, verwenden Sie aber eine bereits vorhandene Domäne. Benutzen Sie S_CHDATE als Datenelement für das Datum der letzten Änderung. Welche Aktionen werden beim Aktivieren auf der Datenbank ausgeführt?
© SAP AG
TAW12
3-15
Hinweis: 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 wollen wir im Rahmen dieses Kurses immer annehmen, daß alle Benutzer diese Felder in der Standardtabellenpflege selber (korrekt) füllen. Starten Sie nun das Programm BC430_CHECK in der Transaktion SE38. Dieses ü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.
© SAP AG
TAW12
3-16
Tabellen im ABAP Dictionary Lösungen Kapitel: Tabellen im ABAP Dictionary
1-1
Über den Pfad Werkzeuge → ABAP Workbench → Entwicklung → Dictionary oder die Transaktion SE11 gelangen Sie in das Übersichtsbild des ABAP Dictionary. 1-1-1 So legen Sie Tabelle ZEMPLOY## an: 1) Markieren Sie Datenbanktabelle, und geben Sie den Tabellennamen ZEMPLOY## im entsprechenden Eingabefeld an. 2) Wählen Sie Anlegen. 3) Erfassen Sie im Pflegebild der Tabelle eine Kurzbeschreibung. 4) Wählen Sie die Auslieferungsklasse A, und markieren Sie Tabellenpflege erlaubt. 5) Wählen Sie nun die Registerkarte Felder, um in die Pflege der Felddefinitionen zu springen. Geben Sie die Feldnamen (müssen nicht im Kundennamensraum liegen) an. 6) 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. 7) Für die Felder Personalnummer, Abteilungskürzel, Bereich und Gehalt sollen Sie eigene Datenelemente anlegen. Geben Sie in der Spalte Feldtyp einen Namen (Z##) für das Datenelement an. Markieren Sie den Namen des Datenelements. Sie gelangen nun zur Datenelementdefinition. 8) Vergeben Sie eine Kurzbeschreibung (Bestandteil der F1-Hilfe). Wählen Sie nun die Registerkarte Feldbezeichner und hinterlegen Sie dort die Texte für die Feldbezeichner. 9) 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##) für Ihre Domäne ein. Falls die Domäne vorgegeben ist, aktivieren Sie das Datenelement und kehren Sie (mit F3 oder Å) zum Pflegebildschirm der Tabellenfelder zurück. Ansonsten markieren Sie den Domänennamen. Sie gelangen dann zur Domänendefinition. 10) Dort legen Sie die Kurzbeschreibung, den Datentyp (z.B. NUMC) und die Feldlänge (z.B. 10) fest. Aktivieren Sie die Domäne. 11) Gehen Sie ein Bild zurück (mit F3 oder Å) zur Datenelementdefinition und aktivieren Sie Ihr Datenelement.
© SAP AG
TAW12
3-17
12) Navigieren Sie nochmals ein Bild zurück zur Felddefinition. Beginnen Sie wieder bei 7), bis alle Felder der Tabelle definiert sind. Sichern Sie anschließend Ihre Tabelle. 13) 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: Referenztabelle: ZEMPLOY## Referenzfeld: Währung 14) Definieren Sie die Schlüsselfelder für Tabelle ZEMPLOY##. Die Felder Mandant, Fluggesellschaft und Personalnummer identifizieren einen Eintrag eindeutig. Sie müssen deshalb als Schlüsselfelder gekennzeichnet werden. Dies tun Sie, indem Sie hinter den Feldnamen die Spalte Key ankreuzen. Die Schlüsselfelder müssen in dieser Reihenfolge am Anfang der Feldliste stehen. 15) Aktivieren Sie nun Ihre Tabelle. Dadurch gelangen sie automatisch in das Pflegebild für die technischen Einstellungen: Da sich die Inhalte der Tabelle ZEMPLOY## selten ändern, muß als Datenart APPL0 (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. 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 oder Å). Die Tabelle wird nun aktiviert.
© SAP AG
TAW12
3-18
1-1-2 So legen Sie Tabelle ZDEPMENT## an: 1) bis 12) siehe Lösung 1-1-1 13) Definieren Sie die Schlüsselfelder für Tabelle ZDEPMENT##. Die Felder Mandant, Fluggesellschaft und Abteilungskürzel identifizieren einen Eintrag eindeutig. Sie müssen deshalb als Schlüsselfelder gekennzeichnet werden. Dies tun Sie, indem Sie hinter den Feldnamen die Spalte Key ankreuzen. 14) Aktivieren Sie nun 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. ZDEPMENT##
1-2
Datenart
APPL0 (Stammdaten)
Größenkategorie
0
Pufferung
nicht erlaubt
Protokollierung
keine Protokollierung
Gehen Sie wie folgt vor, um die Felder Personalnummer und Abteilungskürzel zu dokumentieren: 1) Markieren Sie das Datenelement, um auf dessen Datenelementdefinition zu gelangen. Wechseln Sie mit Anzeigen Ändern in den Änderungsmodus. Markieren Sie Dokumentation oder wählen Sie Springen Æ Dokumentation. 2) Geben Sie den Feldern einen Text mit, und sichern Sie anschließend Ihre Eingaben.
1-3
Legen Sie die Struktur ZCHANGE## wie folgt an: 1) Markieren Sie im Einstiegsbild des ABAP Dictionary Datentyp, und geben Sie ZCHANGE## in das entsprechende Feld ein. Wählen Sie Anlegen. 2) Markieren Sie Struktur im folgenden Dialogfenster. 3) Geben Sie in der Spalte Komponente die Feldnamen und in der Spalte Komponententyp die zugehörigen Datenelemente an. 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. Legen Sie Ihr eigenes Datenelement für das erste Feld an, so wie in Übung 2-1. Verwenden Sie die Domäne, die Sie für die Personalnummer in Tabelle ZEMPLOY## angelegt haben. 4) Aktivieren Sie die Struktur ZCHANGE##. Fügen Sie nun ZCHANGE## als Include in die Tabellen ZEMPLOY## und ZDEPMENT## wie folgt ein: 1) Verzweigen Sie in die Pflege der Tabelle ZEMPLOY##.
© SAP AG
TAW12
3-19
2) Betätigen Sie die Druckknopf Neue Zeilen, und stellen Sie den Cursor auf das erste neue Feld. 3) Wählen Sie Bearbeiten → Include → Einfügen. 4) Geben Sie im folgenden Dialogfenster den Namen ZCHANGE## ein und wählen Sie Weiter. 5) Aktivieren Sie nun Ihre Tabelle. 6) Über Hilfsmittel → Aktivierungprotokoll können Sie sich anzeigen lassen, welche Aktionen auf der Datenbank durchgeführt wurden. 7) Beginnen Sie bei Schritt 1), um die Unterstruktur ZCHANGE## in die Tabelle ZDEPMENT## aufzunehmen.
© SAP AG
TAW12
3-20
Performance beim Tabellenzugriff
z Indizes Primärindex und Sekundärindex Struktur eines Index Zugriff auf Daten über einen Index z Pufferung von Tabellen Vorteile der Pufferung Lokale Tabellenpuffer Pufferungsarten Synchronisation der Puffer Welche Tabellen sollte man puffern?
© SAP AG 1999
© SAP AG
TAW12
4-1
Lernziele des Kurses
Nach Durcharbeiten dieses Kapitels können Sie: z beurteilen, in welchen Fällen Sie Tabellenzugriffe
durch Indizes beschleunigen können z Indizes im ABAP Dictionary anlegen z die verschiedenen Pufferungsarten
unterscheiden z beurteilen, wann die Pufferung einer Tabelle
sinnvoll ist und welche Pufferungsart Sie wählen müssen z die Pufferung einer Tabelle über die technischen
Einstellungen vornehmen
© SAP AG 2002
© SAP AG
TAW12
4-2
Struktur eines Index
Tabelle SCOUNTER SELECT * FROM SCOUNTER WHERE AIRPORT = ‘LHR’.
Binäre Suche
MANDT AIRPORT P
001 001 001 001 001 001 001 001 001 001 001 001 001 001
ACA ACE BER BER DEN FRA HAM LCY LCY LGW LHR LHR MUC RTM
1 2 3 6 7 8 14 4 9 10 5 11 12 13
MANDT CARRID COUNTNUM AIRPORT
001 001 001 001 001 001 001 001 001 001 001 001 001 001
LH BA UA LH BA LH AA LH BA LH LH BA LH LH
00000005 00000004 00000001 00000002 00000003 00000007 00000001 00000003 00000001 00000001 00000004 00000002 00000006 00000008
ACA ACE BER LCY LHR BER DEN FRA LCY LGW LHR MUC RTM HAM
Index über AIRPORT
© SAP AG 2002
Ü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: y 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. y In einem Index sind nur solche Felder sinnvoll, deren Werte die Datenmenge stark einschränken. y 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. y Achten Sie darauf, daß die Indizes zu einer Tabelle möglichst disjunkt sind.
© SAP AG
TAW12
4-3
Zugriff über Indizes
Programm
SELECT * FROM TAB WHERE F2 = `10´.
Optimizer Index 0 F1 Z
Index A F2 Z
TAB F1 F2 F3
10 A3 10 Text
© SAP AG 2002
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.
© SAP AG
TAW12
4-4
Zugriff auf Daten über den Puffer
ABAP-Programm SELECT * FROM SBOOK WHERE ...
R/3-Tabellenpuffer
Datenbankschnittstelle
Datenbank
Kommunikationssystem
DatenbankProzesse
DatenbankPuffer
© SAP AG 2002
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.
© SAP AG
TAW12
4-5
Pufferung von Tabellen
Applikationsserver 1
Applikationsserver 2
Programm Tabellenpuffer
Sätze werden in den Puffer geladen
Programm Tabellenpuffer
Programm liest Daten einer gepufferten Tabelle
TAB
Datenbank © SAP AG 2002
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. 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.
© SAP AG
TAW12
4-6
Vollständige Pufferung
Datenbanktabelle SCOUNTER
Pufferinhalt
MANDT CARRID COUNTNUM AIRPORT
001 001 001 001 001 001 001 001 001 001 001 001 001 001
AA BA BA BA BA LH LH LH LH LH LH LH LH UA
00000001 00000001 00000002 00000003 00000004 00000001 00000002 00000003 00000004 00000005 00000006 00000007 00000008 00000001
001 001 001 001 001 001 001 001 001 001 001 001 001 001
ACA ACE BER LCY LHR BER DEN FRA LCY LGW LHR MUC RTM HAM
AA BA BA BA BA LH LH LH LH LH LH LH LH UA
00000001 00000001 00000002 00000003 00000004 00000001 00000002 00000003 00000004 00000005 00000006 00000007 00000008 00000001
ACA ACE BER LCY LHR BER DEN FRA LCY LGW LHR MUC RTM HAM
Applikationsserver SELECT * FROM SCOUNTER WHERE CARRID = 'LH' AND COUNTNUM = '00000004'.
© SAP AG 2002
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-TableScan im Puffer. Unter diesen Umständen kann ein direkter Zugriff auf die Datenbank effizienter sein, falls dort ein geeigneter Sekundärindex vorhanden ist.
© SAP AG
TAW12
4-7
Generische Pufferung
Datenbanktabelle SCOUNTER
Pufferinhalt
MANDT CARRID COUNTNUM AIRPORT
001 001 001 001 001 001 001 001 001 001 001 001 001 001
AA BA BA BA BA LH LH LH LH LH LH LH LH UA
00000001 00000001 00000002 00000003 00000004 00000001 00000002 00000003 00000004 00000005 00000006 00000007 00000008 00000001
001 001 001 001 001 001 001 001
ACA ACE BER LCY LHR BER DEN FRA LCY LGW LHR MUC RTM HAM
LH LH LH LH LH LH LH LH
00000001 00000002 00000003 00000004 00000005 00000006 00000007 00000008
BER DEN FRA LCY LGW LHR MUC RTM
Applikationsserver SELECT * FROM SCOUNTER WHERE CARRID = 'LH' AND COUNTNUM = '00000004'.
generischer Schlüssel © SAP AG 2002
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.
© SAP AG
TAW12
4-8
Pufferung von Einzelsätzen
Datenbanktabelle SCOUNTER
Pufferinhalt
MANDT CARRID COUNTNUM AIRPORT
001 001 001 001 001 001 001 001 001 001 001 001 001 001
AA BA BA BA BA LH LH LH LH LH LH LH LH UA
00000001 00000001 00000002 00000003 00000004 00000001 00000002 00000003 00000004 00000005 00000006 00000007 00000008 00000001
001
ACA ACE BER LCY LHR BER DEN FRA LCY LGW LHR MUC RTM HAM
LH
00000004
LCY
Applikationsserver SELECT SINGLE * FROM SCOUNTER WHERE CARRID = 'LH' AND COUNTNUM = '00000004'. © SAP AG 2002
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.
© SAP AG
TAW12
4-9
Synchronisation von Puffern 1 Puffer
Puffer TAB
Server 2
Server 1
SELECT * FROM TAB WHERE FIELD = ‘X’.
11
22 TAB
Synchronisationstabelle
© SAP AG 2002
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 TAB zugegriffen. Die Tabelle ist deshalb noch nicht in den lokalen Puffern der beiden Server enthalten. Zeitpunkt 1: Server 1 liest Sätze aus der Tabelle TAB auf der Datenbank. Zeitpunkt 2: Die Tabelle TAB wird vollständig in den lokalen Puffer von Server 1 geladen. Für Zugriffe von Server 1 auf die Daten der Tabelle TAB wird nun der lokale Puffer dieses Servers verwendet.
© SAP AG
TAW12
4-10
Synchronisation von Puffern 2 Puffer
Puffer TAB
TAB
Server 2
Server 1
SELECT * FROM TAB WHERE FIELD = ‘Y’.
44 33
TAB
Synchronisationstabelle
© SAP AG 2002
Zeitpunkt 3: 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 TAB wird in den lokalen Puffer von Server 2 geladen. Server 2 verwendet daher auch seinen lokalen Puffer, um beim nächsten Lesen von Tabelle TAB auf deren Daten zuzugreifen.
© SAP AG
TAW12
4-11
Synchronisation von Puffern 3 Puffer
Puffer 77
TAB
Server 2
TAB
Server 1 DELETE * FROM TAB WHERE FIELD = ‘X’.
55
66 TAB von Server 1 modifiziert
TAB
Synchronisationstabelle
© SAP AG 2002
Zeitpunkt 5: Server 1 löscht Sätze aus der Tabelle TAB und aktualisiert die Datenbank. Zeitpunkt 6: Server 1 schreibt einen Eintrag in die Synchronisationstabelle. Zeitpunkt 7: Server 1 aktualisiert seinen lokalen Puffer.
© SAP AG
TAW12
4-12
Synchronisation von Puffern 4
Puffer 88
Puffer
TAB
TAB
Server 2
Server 1
SELECT * FROM TAB WHERE FIELD = ‘X’.
TAB von Server 1 modifiziert TAB
Synchronisationstabelle
© SAP AG 2002
Zeitpunkt 8: Server 2 greift auf die gelöschten Datensätze zu. Da sich die Tabelle TAB in seinem lokalen Puffer befindet, erfolgt der Zugriff über diesen lokalen Puffer. y Server 2 findet also die Sätze, obwohl diese in der Datenbanktabelle nicht mehr vorhanden sind. y 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.
© SAP AG
TAW12
4-13
Synchronisation von Puffern 5 Puffer 10 10
Puffer
TAB
TAB
Server 2
Server 1 Synchronisation
99
99 TAB von Server 1 modifiziert TAB
Synchronisationstabelle
© SAP AG 2002
Zeitpunkt 9: Der Synchronisationszeitpunkt ist erreicht. Beide Server sehen in der Synchronisationstabelle 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 TAB 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 TAB geht deshalb über die Datenbank. Server 1 muß die Tabelle in seinem Puffer nicht invalidieren, da er selbst der einzige Änderer der Tabelle TAB ist. Server 1 greift also beim nächsten Zugriff auf Sätze der Tabelle TAB erneut über seinen lokalen Puffer zu.
© SAP AG
TAW12
4-14
Synchronisation von Puffern 6
Puffer
Puffer
TAB
TAB
Server 2
Server 1
SELECT * FROM TAB WHERE FIELD = ‘Y’.
12 12 11 11
TAB
Synchronisationstabelle
© SAP AG 2002
Zeitpunkt 11: Server 2 greift erneut auf Sätze der Tabelle TAB zu. Da TAB im lokalen Puffer von Server 2 invalidiert ist, erfolgt der Zugriff über die Datenbank. Zeitpunkt 12: Die Tabelle wird erneut un den loaklen Puffer von Server 2 geladen. Die Informationen über Tabelle TAB sind nun wieder konsistent auf den Servern und der Datenbank. Vor- und Nachteile dieses Verfahrens zur Puffersynchronisation: y 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. y Nachteil: Die lokalen Puffer der Applikationsserver können zwischen den Synchronisationszeitpunkten veraltete Daten enthalten. Daraus folgt: y 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. y 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.
© SAP AG
TAW12
4-15
Zusammenfassung (des Kapitels)
z 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. z Die Tabellenpuffer befinden sich lokal auf den
Applikationsservern. z Die Pufferung kann die Performance beim Zugriff auf
Daten einer Tabelle erheblich steigern. Die Wahl der richtigen Pufferungsart ist wichtig. z Die Tabellenpuffer werden in festen Zeitintervallen an
Änderungen der Tabelleneinträge angepaßt. z 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. © SAP AG 2002
© SAP AG
TAW12
4-16
Performanceaspekte beim Tabellenzugriff Übungen Kapitel: Performanceaspekte beim Tabellenzugriff
Am Ende dieser Übungen können Sie: 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.
1-1
Auf die Personaldaten eines Mitarbeiters wird oft über die Kombination aus Vorund Nachnamen zugegriffen. Dabei ist der Nachname häufiger bekannt (d.h. beim Zugriff spezifiziert) als der Vorname. Legen Sie einen Index an, der diesen Zugriff unterstützt. Sorgen Sie dafür, daß der Index auf der Datenbank angelegt wird.
1-2
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. Eine Tabelle mit der entsprechenden Struktur ist im System schon vorhanden. Kopieren Sie diese Tabelle SFLCREW auf die Tabelle ZFLCREW##. Ersetzen Sie das vorhandene Datenelement für die Mitarbeiternummer durch ein eigenes Datenelement. Vergessen Sie nicht, die Tabelle ZFLCREW## anschließend zu aktivieren.
1-3
Überdenken Sie die 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.
© SAP AG
TAW12
4-17
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. Starten Sie nun das Programm BC430_CHECK in der Transaktion SE38. Dieses ü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. Falls Sie die Zusatzübung bearbeiten, sollten Sie dieses Programm erst nach Ende der Zusatzübung starten. 1-4
Ergänzende Übung: Für den Zugriff auf die Mitarbeiterdaten bringt eventuell auch ein Index über die Bereiche einen Performance-Gewinn, beispielsweise wenn oft alle Piloten selektiert werden. Bei Performance-Messungen auf verschiedenen Datenbanksystemen hat sich herausgestellt, daß dieser Performance-Gewinn nur bei den Datenbanksystemen ADABAS und SQL-Server besteht. Legen Sie den Index an, und stellen Sie sicher, daß dieser nur auf den Datenbanksystemen ADABAS und SQL-Server angelegt wird.
© SAP AG
TAW12
4-18
Performanceaspekte beim Tabellenzugriff Lösungen Kapitel: Performanceaspekte beim Tabellenzugriff
1-1
Die Personaldaten der Mitarbeiter werden in der Tabelle ZEMPLOY## verwaltet. Für diese Tabelle ist daher der Index anzulegen. Er muß die Felder Mandant, Nachname und Vorname enthalten. Da der Nachname bei Zugriffen häufiger spezifiziert ist und auch wesentlich selektiver ist als der Vorname, muß er im Index vor diesem stehen. Die Feldreihenfolge ist also Mandant, Nachname und dann Vorname. Gehen Sie wie folgt vor, um den Index anzulegen: 1) Verzweigen Sie im Anzeigemodus in das Pflegebild der Tabelle ZEMPLOY## und wählen Sie Indizes. 2) Bestätigen Sie im folgenden Dialogfenster, daß Sie einen Index anlegen möchten. 3) Geben Sie auf dem nächsten Dialogfenster eine dreistellige Indexkennung ein, und wählen Sie Weiter. 4) Sie gelangen in das Pflegebild des Index. Geben Sie einen Kurztext ein. 5) Betätigen Sie den Druckknopf Tabellenfelder. Es erscheint eine Liste aller in der Tabelle vorhandenen Felder. Markieren Sie die Felder Mandant, Nachname und Vorname, und drücken Sie Übernehmen. 6) Die Felder werden in der Reihenfolge aus dem Dialogfenster in den Index übernommen. 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. 7) Der Index ist sicher kein Unique-Index, da es Mitarbeiter mit gleichem Vorund Nachnamen geben kann. Weiterhin besteht kein Grund, den Index nur auf bestimmten Datenbanksystemen anzulegen. Lassen Sie deshalb die Standardeinstellungen Non-Unique-Index und Index auf allen Datenbanksystemen bestehen. 8) Aktivieren Sie den Index. Der Index wird dabei automatisch auf der Datenbank angelegt.
1-2
Gehen Sie wie folgt vor, um die Tabelle SFLCREW zu kopieren: 1) Geben Sie im Einstiegsbild des ABAP Dictionary im Feld Datenbanktabelle SFLCREW ein. Wählen Sie Übernehmen. 2) Geben Sie im folgenden Dialogfenster im Feld nach Tabelle den Namen ZFLCREW## ein, und wählen Sie Weiter.
© SAP AG
TAW12
4-19
3) 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. 4) Aktivieren Sie nun Ihre Tabelle. 1-3
Die Einstellungen zur Pufferung der genannten Tabellen pflegen Sie in deren technischen Einstellungen. Um diese zu erreichen, verzweigen Sie im Anzeigemodus in die Pflege der jeweiligen Tabelle und betätigen den Druckknopf Technische Einstellungen. Sie gelangen in das gewünschte Pflegebild, in dem Sie noch in den Änderungsmodus wechseln müssen. Da die Inhalte der Tabelle ZDEPMENT## nur selten geändert aber häufig wiederholt gelesen werden, ist eine Pufferung der Tabelle sinnvoll. Markieren Sie Pufferung eingeschaltet. Da keine Einschränkungen bzgl. des Zugriffs vorliegen und die Tabelle klein ist, ist hier vollständige Pufferung zu wählen. Markieren Sie vollständig gepuffert. Aktivieren Sie die technischen Einstellungen der Tabelle ZDEPMENT##. Die Daten der Tabelle ZFLCREW## werden häufig wiederholt gelesen. Ändernde Zugriffe finden dagegen nur selten statt. Daher ist eine Pufferung der Tabelle sinnvoll. Markieren Sie Pufferung eingeschaltet. Auf einem Applikationsserver werden aber 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. Markieren Sie generische Pufferung, und wählen Sie 2 als Anzahl der generischen Schlüsselfelder. Aktivieren Sie die technischen Einstellungen der Tabelle ZFLCREW##.
1-4
Wenn Sie wie in 3.1 beschrieben vorgehen, zeigt Ihnen das Sytem in einem Dialogfenster Ihren bereits angelegten Index an. Wählen Sie auf diesem Dialogfenster die Funktion Anlegen. Nehmen Sie die Felder Mandant, Fluggesellschaft und Bereich in den Index auf. Auch hier handelt es sich nicht um einen Unique-Index. Gehen Sie wie folgt vor, um den Index nur auf den Datenbanksystemen Adabas und SQL-Server anzulegen: 1) Markieren Sie auf ausgewählten Datenbank-Systemen. 2) 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 Adabas (ADA) und SQL-Server (MSS) aus. 3) Wählen Sie Weiter. 4) Aktivieren Sie den Index. Der Index wird nur dann auf der Datenbank angelegt, wenn Ihr Schulungssystem auf einem der gewählten Datenbanksysteme läuft.
© SAP AG
TAW12
4-20
Konsistenz durch Eingabeprüfungen
z Festwerte z Wertetabelle z Was ist ein Fremdschlüssel? z Feldzuordnung über das Prüffeld z Fremdschlüsseltabelle / Prüftabelle z Semantische Eigenschaften des
Fremdschlüssels z Texttabelle
© SAP AG 2002
© SAP AG
TAW12
5-1
Lernziele des Kurses
Nach Durcharbeiten dieses Kapitels können Sie: z Festwerte anlegen und verwenden z Definieren, was ein Fremdschlüssel ist z Die Bedingungen bei der Feldzuordnung des
Fremdschlüssels verstehen und anwenden z Den Unterschied zwischen Wertetabelle und Prüftabelle
verstehen z Fremdschlüssel anlegen
© SAP AG 2002
© SAP AG
TAW12
5-2
Festwerte Dictionary: Domäne S_CLASS anzeigen: Festwerte Domäne
S_CLASS
Kurzbeschreibung
Flugklasse
Festwert C Y
Kurzbeschreibung
F
Business Class Economy Class First Class
Untergrenze
Obergrenze
Kurzbeschreibung
© SAP AG 2002
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.
Der Typ 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. Wenn man über die Art des Fremdschlüsselfeldes keine Aussage möchte, wählt man 'nicht spezifiziert'.
© SAP AG
TAW12
5-3
Wertetabelle
Dictionary: Domäne S_CARR_ID anzeigen
Domäne
S_CARR_ID
Kurzbeschreibung
Kurzbezeichnung der Fluggesellschaft
Format Datentyp
CHAR
Zahl der Stellen
Tabelle SCARR MANDT 401 401 401 410
Characterstrings 3
CARRID AA BA LH UA
CARRNAME American Airlines British Airways Lufthansa United Airlines
CURRCODE USD GBP DEM USD
Zulässige Werte
Wertetabelle
SCARR
© SAP AG 2002
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.
Der Typ 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. Wenn man über die Art des Fremdschlüsselfeldes keine Aussage möchte, wählt man 'nicht spezifiziert'.
© SAP AG
TAW12
5-4
Einfügen eines Datensatzes
Datenbanktabelle SCOUNTER (Verkaufsschalter) MANDT CARRID 001 AA 001 BA 001 BA 001 BA 001 BA 001 LH 001 LH 001 LH 001 LH 001 LH 001 LH 001 LH 001 LH 001 UA
COUNTNUM 00000001 00000001 00000002 00000003 00000004 00000001 00000002 00000003 00000004 00000005 00000006 00000007 00000008 00000001
AIRPORT ACA ACE BER LCY LHR BER DEN FRA LCY LGW LHR MUC RTM HAM
Eingaben auf Felder der Tabelle SBOOK (Flugbuchung): CARRID (Fluggesellschaft) AA CONNID (Flugverbindung)
0017
FLDATE (Flugdatum)
25.07.2000
CUSTOMID (Kunde)
00000148
COUNTER (Verkaufsstelle) 00000008
Kann dieser Flug am Verkaufsschalter 8 gebucht werden?
© SAP AG 1999
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 ?
© SAP AG
TAW12
5-5
Verstoß gegen die Fremdschlüsselprüfung
Datenbanktabelle SCOUNTER MANDT CARRID 001 AA 001 BA 001 BA 001 BA 001 BA 001 LH 001 LH 001 LH 001 LH 001 LH 001 LH 001 LH 001 LH 001 UA
COUNTNUM 00000001 00000001 00000002 00000003 00000004 00000001 00000002 00000003 00000004 00000005 00000006 00000007 00000008 00000001
AIRPORT ACA ACE BER LCY LHR BER DEN FRA LCY LGW LHR MUC RTM HAM
Eingaben auf Felder der Tabelle SBOOK: CARRID (Fluggesellschaft) AA CONNID (Flugverbindung)
0017
FLDATE (Flugdatum)
25.07.2000
CUSTOMID (Kunde)
00000148
COUNTER (Verkaufsstelle) 000000008
Einfügen Verboten ! Wirkung der Fremdschlüsseldefinition: Ein Datensatz mit der Belegung: MANDT = '001', CARRID = 'AA', COUNTNUM = '000000008' ist nicht in Tabelle SCOUNTER vorhanden.
© SAP AG 1999
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.
© SAP AG
TAW12
5-6
Fremdschlüsselfeld / Prüffeld
Fremdschlüsselfelder
Fremdschlüsseltabelle SBOOK MANDT CARRID CONNID FLDATE CUSTOMID ... COUNTER ... CANCELLED
Prüffeld Prüftabelle SCOUNTER MANDT
CARRID
COUNTNUM
AIRPORT
Schlüsselfelder © SAP AG 2002
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
© SAP AG
TAW12
5-7
Datenkonsistenz durch Fremdschlüssel SCARR: Prüftabelle = ref. Objekte SPFLI: Fremdschlüsseltabelle = abhäng. Objekte MANDT CARRID
...
MANDT CARRID CONNID
800
AA
800
AA
0017
800
AC
800
AA
0064
800
AF
800
Rome
0555
800
Rome
800
Rome
0788
SPFLI-MANDT
...
SPFLI-CARRID
Fremdschlüsselfelder Detailpflege Fluggesellschaft
AB
Flugnummer
0020
STOP
Prüffeld
© SAP AG 2002
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.
© SAP AG
TAW12
5-8
Fremdschlüsseldefinition beim Prüffeld
Fremdschlüsselbeziehung zum Prüffeld Abflughafen mit Prüftabelle: SAIRPORT Tabelle SAIRPORT MANDT
Flughafen
Tabelle SPFLI
......
MANDT
Abflughafen
...
Schlüsselfelder Datenelement S_AIRPORT
Datenelement S_FROMAIRP
Domäne Domäne S_AIRPID Wertetabelle SAIRPORT © SAP AG 2002
Damit nicht Felder mit veschiedenen 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 wird 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-Flughafen 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).
© SAP AG
TAW12
5-9
Prüftabelle ungleich Wertetabelle
Fremdschlüsseltabelle SBOOK MANDT CARRID
... AGENCYNUM ...
CANCELLED
Tabelle STRAVELAG MANDT
AGENCYNUM ...
Tabelle SBUSPART MANDT
BUSPARTNUM ...
Domäne Domäne S_BUSPANUM Wertetabelle SBUSPART © SAP AG 2002
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 SBOOKAGENCYNUM 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.
© SAP AG
TAW12
5-10
Semantische Eigenschaften
Kardinalität C
F
1:1
C
F
..........
C
F
..........
1:N
C
1:C
..........
F
..........
1:CN
© SAP AG 2002
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. Der Typ 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: y Nicht spezifiziert: Es kann keine Aussage über die Art des Fremdschlüsselfeldes gemacht werden y 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. y 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. y 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üftablle in einem zusätzlichen Sprachenschlüsselfeld. Dieser Fall ist ein Spezialfall der Art Schlüsselfelder/kandidaten.
© SAP AG
TAW12
5-11
Texttabelle Texttabelle
Fremdschlüsselbeziehung mit Prüftabelle SMEAL Typ der Fremdschlüsselfelder: Schlüsselfelder einer Texttabelle
Tabelle SMEAL MEALMANDT CARRID MEALNUMBER TYPE
Texttabelle SMEALT MANDT CARRID MEAL- SPRACHE NUMBER
Schlüsselfelder
TEXT
Schlüsselfelder
© SAP AG 2002
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. Zu einer Tabelle kann nur eine Texttabelle angelegt werden.
© SAP AG
TAW12
5-12
Zusammenfassung (des Kapitels)
z In diesem Kapitel wurden zwei Möglichkeiten zur Konsistenzsicherung der Daten vorgestellt:
Festwerte (statisch)
Fremdschlüssel (dynamisch)
z Die Festwerte werden in der Domäne hinterlegt. z Der Fremdschlüssel erlaubt es eingegebene Werte gegen vorhandene Daten zu prüfen. z Für das Prüffeld (Feld der Fremdschlüsseltabelle) wird die Fremdschlüsselbeziehung gepflegt. z Das Prüffeld muss einem Prüftabellenschlüsselfeld zugeordnet sein, das dieselbe Domäne hat.
© SAP AG 2002
© SAP AG
TAW12
5-13
Konsistenz durch Eingabeprüfungen Übungen Kapitel: Konsistenz durch Eingabeprüfungen
Am Ende dieser Übungen können Sie: 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, d.h. gültige Fluggesellschaften, Abteilungen, Bereiche usw. zugelassen werden. Dies soll in der folgende Übung realisiert werden.
1-1
Die Mitarbeiter der Fluggesellschaften werden unterteilt in Administrationspersonal (A), Flugpersonal (F) oder Servicepersonal (S). Entsprechend dieser Einteilung werden sie den Tätigkeitsbereichen A, F oder S zugeordnet. Sorgen Sie dafür, daß in die Tabelle ZEMPLOY## nur gültige Tätigkeitsbereiche eingetragen werden können.
1-2
Definieren Sie geeignete Fremschlüssel für Ihre Tabellen ZEMPLOY## und ZDEPMENT##. Verwenden Sie zur Fremdschlüsseldefinition außer Ihren Tabellen die Tabellen des Flugmodells bzw. die Tabellen T000 (Mandant) und SCURX (Währungscodes). Definieren Sie jeweils eine Fremdschlüsselprüfung für folgende Felder: ZEMPLOY##-Mandant ZEMPLOY##-Fluggesellschaft ZEMPLOY##-Abteilungskürzel ZEMPLOY##-Währung sowie ZDEPMENT##-Mandant ZDEPMENT##-Fluggesellschaft Pflegen Sie Daten für Ihre Tabelle ZEMPLOY## und testen Sie dabei die Wirksamkeit Ihrer Fremdschlüsselbeziehungen.
© SAP AG
TAW12
5-14
1-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.
Die Tabelle aller Reisebüros heißt STRAVELAG.
1-4
Jede Abteilung in einer Fluggesellschaft hat einen Abteilungsleiter. Die Zuordnung zwischen Abteilung und Abteilungsleiter soll auch im Flugmodell abgebildet werden. Erweitern Sie die Tabelle ZDEPMENT## um ein Feld Abteilungsleiter. Definieren Sie für dieses Feld einen geeigneten Fremdschlüssel.
Nutzen Sie das zweistufige Domänenkonzept aus.
1-5
Um das Abteilungskürzel für die Mitarbeiter der Fluggesellschaft über alle Länder verständlich zu machen, soll zu der Tabelle ZDEPMENT## eine Texttabelle ZDEPMENTT## angelegt werden. Legen Sie eine enstprechende Tabelle an, und verwenden Sie zur Feldefinition die Datenelemente SPRAS und S_TEXT. Definieren Sie die notwendigen Fremdschlüsselbeziehungen.
© SAP AG
TAW12
5-15
Konsistenz durch Eingabeprüfungen Lösungen Kapitel: Konsistenz durch Eingabeprüfungen
1-1
Rufen Sie die Pflege der Domäne für das Feld ZEMPLOY##-Bereich auf. Dazu verzweigen Sie aus dem Tabellenpflegebild auf das entsprechende Datenelement und von dort zur Domäne. Wählen Sie die Registerkarte Wertebereich, und tragen Sie folgende Festwerte ein: Festwert
Kurzbeschreibung
A
Administrationspersonal
F
Flugpersonal
S
Servicepersonal
Aktivieren Sie Ihre Domäne. 1-2
Zur Pflege der einzelnen Fremdschlüssel rufen Sie die Pflege der jeweiligen Tabellen auf. Wählen Sie das Register Felder. Legen Sie den Fremdschlüssel ZDEPMENT##-Mandant wie folgt an: 1) Positionieren Sie den Cursor auf das Feld ZEMPLOY##-Mandant. Markieren Sie Fremdschlüssel oder wählen Sie Springen → Fremdschlüssel. 2) Da Sie für das Feld ZEMPLOY-Mandant die Domäne MANDT benutzen, schlägt Ihnen das System die Wertetabelle T000 als Prüftabelle vor. 3) Lassen Sie sich den Vorschlag zur Fremdschlüsseldefinition erstellen. Kontrollieren Sie den Vorschlag: Folgende Felder müssen zugeordnet sein: Prüftabelle
PrüftabFeld
FremdschlTab
FremdschlFeld
T000
MANDT
ZEMPLOY##
Mandant
4) Erfassen Sie eine Kurzbeschreibung und legen Sie die semantischen Eigenschaften wie folgt fest: Art der Fremdschlüsselfelder: Kardinalität:
Schlüsselfelder/-kandidaten
1:CN
5) Sichern Sie Ihren Fremdschlüssel. Legen Sie den Fremdschlüssel ZEMPLOY##-Fluggesellschaft wie folgt an: 1) Positionieren Sie den Cursor auf das Feld ZEMPLOY##-Fluggesellschaft. Markieren Sie Fremdschlüssel oder wählen Sie Springen → Fremdschlüssel. 2) Da Sie für das Feld ZEMPLOY-Fluggesellschaft die Domäne S_CARR_ID benutzen, steht Ihnen zur Fremdschlüsseldefinition die Wertetabelle SCARR zur Verfügung. © SAP AG
TAW12
5-16
3) Lassen Sie sich den Vorschlag zur Fremdschlüsseldefinition erstellen. Kontrollieren Sie den Vorschlag: Folgende Felder müssen zugeordnet sein: Prüftabelle
Prüftabfeld
FremdschlTab
Fremdschlfeld
SCARR
MANDT
ZEMPLOY##
Mandant
SCARR
CARRID
ZEMPLOY##
Fluggesellschaft
4) Erfassen Sie eine Kurzbeschreibung und legen Sie die semantischen Eigenschaften wie folgt fest: Art der Fremdschlüsselfelder: Kardinalität:
Schlüsselfelder/-kandidaten
1:CN
5) Sichern Sie Ihren Fremdschlüssel. Legen Sie den Fremdschlüssel ZEMPLOY##-Abteilungskürzel wie folgt an: 1) Um bei der Fremschlüsseldefinition einen Vorschlag zu erhalten, müssen Sie für das Feld ZEMPLOY##-Abteilungskürzel die Domäne verändern. Dies ist zur späteren Fremdschlüsseldefinition nicht zwingend notwendig, erleichtert aber die Definition. Tragen sie in der Domäne zu diesem Feld die Wertetabelle ZDEPMENT## ein, und aktivieren Sie die Domäne. 2) Positionieren Sie den Cursor zunächst auf das Feld ZEMPLOY##Abteilungskürzel. Markieren Sie Fremdschlüssel oder wählen Sie Springen Æ Fremdschlüssel. 3) 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. 4) Lassen Sie sich den Vorschlag zur Fremdschlüsseldefinition erstellen. Kontrollieren Sie den Vorschlag: Folgende Felder müssen zugeordnet sein: Prüftabelle
Prüftabfeld
FremdschlTab
Fremdschlfeld
ZDEPMENT##
Mandant
ZEMPLOY##
Mandant
ZDEPMENT##
Fluggesellschaft
ZEMPLOY##
Fluggesellschaft
ZDEPMENT##
Abteilungskürzel
ZEMPLOY##
Abteilungskürzel
5) Erfassen Sie eine Kurzbeschreibung und legen Sie die semantischen Eigenschaften wie folgt fest: Art der Fremdschlüsselfelder: Kardinalität:
keine Schlüsselfelder/-kandidaten
1:CN
6) Sichern Sie Ihren Fremdschlüssel. Legen Sie den Fremdschlüssel ZDEPMENT##-Währung wie folgt an: 1) Positionieren Sie den Cursor auf das Feld ZEMPLOY##-Währung. Markieren Sie Fremdschlüssel oder wählen Sie Springen → Fremdschlüssel. 2) 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. 3) Lassen Sie sich den Vorschlag zur Fremdschlüsseldefinition erstellen. Kontrollieren Sie den Vorschlag: Folgende Felder müssen zugeordnet sein: © SAP AG
TAW12
5-17
Prüftabelle
PrüftabFeld
FremdschlTab
FremdschlFeld
SCURX
CURRKEY
ZEMPLOY##
Währung
4) Erfassen Sie eine Kurzbeschreibung und legen Sie die semantischen Eigenschaften wie folgt fest: Art der Fremdschlüsselfelder: Kardinalität:
keine Schlüsselfelder/-kandidaten
1:CN
5) Sichern Sie Ihren Fremdschlüssel. Legen Sie den Fremdschlüssel ZDEPMENT##-Mandant wie folgt an: Siehe Fremdschlüssel ZEMPLOY##-Mandant. Legen Sie den Fremdschlüssel ZDEPMENT##-Fluggesellschaft wie folgt an: Siehe Fremdschlüssel ZEMPLOY##-Fluggesellschaft. Wählen Sie nun wieder in der Pflege der Tabelle ZEMPLOY## Hilfsmittel → Tabelleninhalt → Einträge erfassen. Erfassen Sie Daten, und überprüfen Sie über die F4-Hilfe die Funktion Ihrer Fremdschlüssel. 1-3
Legen Sie nun ein neues Feld Reisebüro in Ihrer Tabelle ZEMPLOY## wie folgt an: 1) Navigieren Sie zur Feldpflege der Tabelle ZEMPLOY##. Fügen Sie ein neues Feld Reisebüro in die Feldliste ein (über Neue Zeilen). In der Pflege der Tabelle STRAVELAG können Sie feststellen, daß das passende Datenelement S_AGNCYNUM heißt. Ordnen Sie dieses Datenelement Ihrem neuen Feld ZEMPLOY##-Reisebüro zu. 2) Setzen Sie nun den Cursor auf das Feld Reisebüro, und lassen Sie sich einen Vorschlag zur Fremdschlüsseldefinition erstellen. 3) 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. 4) Die richtige Prüftabelle ist STRAVELAG, die die Reisebüros enthält, mit denen die Fluggesellschaften zusammenarbeiten. 5) 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. 6) 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:
© SAP AG
Prüftabelle
PrüftabFeld
FremdschlTab
FremdschlFeld
STRAVELAG
MANDT
ZEMPLOY##
Mandant
STRAVELAG
AGENCYNUM
ZEMPLOY##
Reisebüro
TAW12
5-18
7) Geben Sie eine Kurzbeschreibung an. Tragen Sie die Kardinalität 1:CN ein, und markieren Sie, daß die Fremdschlüsselfelder keine Schlüsselfelder/-kandidaten sind. Wählen Sie Übernehmen. 8) Aktivieren Sie nun Ihre Tabelle. 9) Wählen Sie nun wieder in der Pflege der Tabelle ZEMPLOY## Hilfsmittel → Tabelleninhalt → Einträge erfassen. Verifizieren Sie über die angebotene F4-Hilfe Ihren Fremdschlüssel. 1-4
In unserem Modell wird eine Person durch ihre Personalnummer identifiziert. Aus diesem Grund muß das neu zur Tabelle ZDEPMENT## hinzuzufügende Feld Personalnummern enthalten (und nicht etwa Namen). Das Feld sollte also auf die Domäne für Personalnummern verweisen, die Sie in der ersten Übung angelegt haben. 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. Es ist sowohl möglich, das Datenelement zunächst anzulegen, um dann die Tabelle zu pflegen, als auch das Datenelement aus der Tabellenpflege durch Vorwärtsnavigation anzulegen. Im folgenden wird die zweite Möglichkeit beschrieben: 1) Verzweigen Sie im Änderungsmodus in das Pflegebild der Tabelle ZDEPMENT##. Wählen Sie das Register Felder. 2) Wählen Sie Neue Zeilen. 3) Tragen Sie direkt hinter den bereits vorhandenen Feldern das neue Feld ein, indem Sie in die erste Spalte einen geeigneten Feldnamen eingeben und in die Spalte Feldtyp einen Namen für das anzulegende Datenelement eintragen. 4) Sichern Sie die Tabellendefinition. 5) Markieren Sie den Namen des neu anzulegenden Datenelements. Bestätigen Sie, daß Sie das Datenelement anlegen möchten. 6) 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. 7) Wählen Sie die Registerkarte Feldbezeichner, und geben Sie dort entsprechende Texte ein. 8) Aktivieren Sie das Datenelement. Gehen Sie dann mit Zurück wieder in die Pflege der Tabelle ZDEPMENT##. 9) Legen Sie den Fremdschlüssel zu dem neuen Feld wie gewohnt an. Die Prüftabelle ist Tabelle ZEMPLOY##. 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. Bei der Feldzuordnung des Fremdschlüssels können Sie den Systemvorschlag übernehmen. Die Kardinalität ist 1:CN, und die Fremdschlüsselfelder sind keine Fremdschlüsselfelder/-kandidaten. 10) Aktivieren Sie nun Ihre Tabelle.
1-5
Legen Sie Ihre Texttabelle ZDEPMENTT## wie folgt an: 1) Kopieren Sie Tabelle ZDEPMENT## nach Tabelle ZDEPMENTT##. 2) Navigieren Sie zur Feldpflege der Tabelle ZDEPMENTT##. Löschen Sie alle Felder, die keine Schlüsselfelder sind. Legen Sie folgende neue Felder an:
© SAP AG
TAW12
5-19
Feldname
Datenelement
Datentyp, Länge
Sprache
SPRAS
LANG
Beschreibung
S_TEXT
CHAR40
Das Feld ZDEPMENT##-Sprache muß ein Schlüsselfeld sein. 3) Die Fremdschlüssel der Felder ZDEPMENTT##-Mandant und ZDEPMENTT##-Fluggesellschaft sind durch das Kopieren bereits richtig definiert. Sie müssen also noch die Fremdschlüssel der Felder ZDEPMENTT##- Abteilungskürzel und ZDEPMENTT##-Sprache definieren. 4) Positionieren Sie den Cursor zunächst auf das Feld ZDEPMENT##Abteilungskürzel. Markieren Sie Fremdschlüssel oder wählen Sie Springen Æ Fremdschlüssel. 5) 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. 6) Lassen Sie sich den Vorschlag zur Fremdschlüsseldefinition erstellen. Kontrollieren Sie den Vorschlag: Folgende Felder müssen zugeordnet sein: Prüftabelle
PrüftabFeld
FremdschlTab
FremdschlFeld
ZDEPMENTx
Mandant
ZDEPMENTT## Mandant
ZDEPMENT##
Fluggesellschaft
ZDEPMENTT## Fluggesellschaft
ZDEPMENT##
Abteilungskürzel ZDEPMENTT## Abteilungskürzel
7) Erfassen Sie eine Kurzbeschreibung und legen Sie die semantischen Eigenschaften wie folgt fest: Art der Fremdschlüsselfelder: Kardinalität:
Schlüsselfelder einer Texttabelle
1:CN
8) Sichern Sie Ihren Fremdschlüssel 9) Positionieren Sie den Cursor auf das Feld ZDEPMENTT##-Sprache. Markieren Sie Fremdschlüssel oder wählen Sie Springen → Fremdschlüssel. 10) Da Sie für das Feld ZDEPMENTT##-Sprache die Domäne SPRAS benutzen, steht Ihnen zur Fremdschlüsseldefinition die Wertetabelle T002 zur Verfügung.
© SAP AG
TAW12
5-20
11) Lassen Sie sich den Vorschlag zur Fremdschlüsseldefinition erstellen. Kontrollieren Sie den Vorschlag: Folgende Felder müssen zugeordnet sein: Prüftabelle
Prüftabfeld
FremdschlTab
Fremdschlfeld
T002
SPRAS
ZDEPMENTT## Sprache
12) Erfassen Sie eine Kurzbeschreibung und legen Sie die semantischen Eigenschaften wie folgt fest: Art der Fremdschlüsselfelder: Kardinalität:
Schlüsselfelder/-kandidaten
1:CN
13) Sichern Sie Ihren Fremdschlüssel. 14) Aktivieren Sie nun Ihre Tabelle.
© SAP AG
TAW12
5-21
Abhängigkeiten bei ABAP Dictionary Objekten
z Aktivierung von ABAP Dictionary Objekten z Behandlung abhängiger Objekte z Verwendungsnachweis und Repository Infosystem
aus Sicht des ABAP Dictionary
© SAP AG 1999
© SAP AG
TAW12
6-1
Lernziele des Kurses
Nach Durcharbeiten dieses Kapitels können Sie: z zwischen aktiver und inaktiver Version eines ABAP
Dictionary Objekts unterscheiden z den Mechanismus zur Behandlung von abhängigen
Objekten im ABAP Dictionary beschreiben z die Funktionsweise des Repository Infosystems und des
Verwendungsnachweises für ABAP Dictionary Objekte erläutern
© SAP AG 2002
© SAP AG
TAW12
6-2
Aktive und inaktive Versionen
aktive Version Feld 1 Feld 2 Feld 3
Anfügen von Feld 4 im ABAP Dictionary
aktive Version
inaktive Version
Feld 1 Feld 2 Feld 3
Feld 1 Feld 2 Feld 3 Feld 4
Aktivieren
aktive Version Feld 1 Feld 2 Feld 3 Feld 4
© SAP AG 2002
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.
© SAP AG
TAW12
6-3
Laufzeitobjekte
Struktur Informationen über die Struktur Laufzeitobjekt zur Struktur
Feld 1 Feld 2 Feld 3
Datenelemente DatenDatenDatenDatenelement 1 element 2
DatenDatenelement 3 Feldinformation
Domäne Domäne 1
Domäne Domäne 2
Domäne Domäne 3
ABAP Interpreter
© SAP AG 2002
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.
© SAP AG
TAW12
6-4
Behandlung abhängiger Objekte Tabelle 2
enthält Struktur 1
Struktur 2
Datenelement 1
© SAP AG 2002
Tabelle 1
Datenelement 2
Struktur 3
Datenelement 3
Domäne Domäne
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.
© SAP AG
TAW12
6-5
Verwendungsnachweis Verwendung Programm 1
Struktur 1
Struktur 2
Datenelement 1
© SAP AG 2002
Programm 2
Tabelle 1
Datenelement 2
Domäne Domäne
Tabelle 2
Struktur 3
Datenelement 3
Verwendungsnachweise
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.
© SAP AG
TAW12
6-6
Das Repository-Infosystem ABAP Dictionary
?
?
Suche anhand von Eigenschaften
Zeige alle Objekte vom Typ X mit Eigenschaft Y
Informationen über Beziehungen zwischen Tabellen
Zeige alle Tabellenfelder mit Prüftabelle X
© SAP AG 1999
Verwendungsnachweise Zeige alle Objekte vom Typ X, die das Objekt Y verwenden
ABAP Dictionary
Änderungsnachweise Zeige alle Objekte vom Typ X, die vom Benutzer Y, zum Zeitpunkt TTMMJJJJ geändert wurden
?
?
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.
© SAP AG
TAW12
6-7
Zusammenfassung (des Kapitels)
Im ABAP Dictionary unterscheidet man zwischen aktiver und inaktiver Version eines Objekts. Die aktive Version wird vom Laufzeitsystem genutzt, die inaktive im Entwicklungsprozeß bearbeitet. z Beim Aktivieren eines Objekts wird die inaktive Version (nach einer Prüfung) zur aktiven Version. Die alte aktive Version wird überschrieben. z Bei der Aktivierung eines bereits aktiven Objekts werden ggf. alle aktiven abhängigen Objekte nachaktiviert. Hierbei werden Laufzeitobjekt und Datenbankobjekt dieser Abhängigen aktualisiert. z Über den Verwendungsnachweis können Sie zu einem ABAP Dictionary Objekt alle Repository Objekte ermitteln, die dieses verwenden. z Im Repository-Infosystem können Sie ABAP Dictionary Objekte über ihre Eigenschaften suchen. © SAP AG 2002
© SAP AG
TAW12
6-8
Abhängigkeiten bei ABAP Dictionary Objekten Übungen Kapitel: Abhängigkeiten bei ABAP Dictionary Objekten
Am Ende dieser Übungen können Sie: 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. In dieser Übung werden entsprechende Erweiterungen an den Tabellen und Strukturen durchgeführt.
1-1
Jede Abteilung in einer Fluggesellschaft hat einen Abteilungsleiter. Die Zuordnung zwischen Abteilung und Abteilungsleiter soll auch im Flugmodell abgebildet werden. Erweitern Sie die Tabelle ZDEPMENT## um ein Feld Abteilungsleiter. Definieren Sie für dieses Feld einen geeigneten Fremdschlüssel.
Nutzen Sie das zweistufige Domänenkonzept aus.
1-2
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. Sorgen Sie mit möglichst geringem Aufwand dafür, daß in die beiden Tabellen ein entsprechendes Feld aufgenommen wird. Verwenden Sie hierbei das Datenelement S_TIME. Überzeugen Sie sich, daß das Feld in die beiden genannten Tabellen aufgenommen wird. Kontrollieren Sie die Aktivierungsprotokolle der beteiligten Tabellen und Strukturen. Starten Sie nun das Programm BC430_CHECK in der Transaktion SE38. Dieses überprüft die Korrektheit Ihrer Lösungen.
© SAP AG
TAW12
6-9
1-3
Erstellen Sie jeweils eine Liste der folgenden ABAP Dictionary Objekte: 1-3-1 Alle Domänen mit Festwerten, deren Namen mit Z beginnt. 1-3-2 Alle Tabellenfelder, die das Datenelement S_FNAME benutzen. 1-3-3 Alle Tabellen des Flugmodells (Entwicklungsklasse BC_DATAMODEL), die die Auslieferungsklasse A haben.
1-4
Bestimmen Sie alle Programme, die die Tabelle SFLIGHT benutzen.
1-5
Wie heißen die von Ihren Nachbarn angelegten Datenelemente? _______________________________________________________________ _______________________________________________________________ _______________________________________________________________
© SAP AG
TAW12
6-10
Abhängigkeiten bei ABAP Dictionary Objekten Lösungen Kapitel: Abhängigkeiten bei ABAP Dictionary Objekten
1-1
In unserem Modell wird eine Person durch ihre Personalnummer identifiziert. Aus diesem Grund muß das neu zur Tabelle ZDEPMENT## hinzuzufügende Feld Personalnummern enthalten (und nicht etwa Namen). Das Feld sollte also auf die Domäne für Personalnummern verweisen, die Sie in der ersten Übung angelegt haben. 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. Es ist sowohl möglich, das Datenelement zunächst anzulegen, um dann die Tabelle zu pflegen, als auch das Datenelement aus der Tabellenpflege durch Vorwärtsnavigation anzulegen. Im folgenden wird die zweite Möglichkeit beschrieben: 1) Verzweigen Sie im Änderungsmodus in das Pflegebild der Tabelle ZDEPMENT##. Wählen Sie das Register Felder. 2) Wählen Sie Neue Zeilen. 3) Tragen Sie direkt hinter den bereits vorhandenen Feldern das neue Feld ein, indem Sie in die erste Spalte einen geeigneten Feldnamen eingeben und in die Spalte Feldtyp einen Namen für das anzulegende Datenelement eintragen. 4) Sichern Sie die Tabellendefinition. 5) Wählen Sie den Namen des neu anzulegenden Datenelements aus. Bestätigen Sie, daß Sie das Datenelement anlegen möchten. 6) 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. 7) Wählen Sie die Registerkarte Feldbezeichner, und geben Sie dort entsprechende Texte ein. 8) Aktivieren Sie das Datenelement. Gehen Sie dann mit Zurück wieder in die Pflege der Tabelle ZDEPMENT##. 9) Legen Sie den Fremdschlüssel zu dem neuen Feld wie gewohnt an. Die Prüftabelle ist Tabelle ZEMPLOY##. 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. Bei der Feldzuordnung des Fremdschlüssels können Sie den Systemvorschlag übernehmen. Die Kardinalität ist 1:CN, und die Fremdschlüsselfelder sind keine Fremdschlüsselfelder/-kandidaten. 10) Aktivieren Sie nun Ihre Tabelle.
1-2
© SAP AG
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 TAW12
6-11
in die Tabellen ZEMPLOY## und ZDEPMENT## aufgenommen. Gehen Sie dazu wie folgt vor: 1) Markieren Sie im Einstiegsbild des ABAP Dictionary Datentyp, und geben Sie ZCHANGE## in das entsprechende Feld ein. Wählen Sie Ändern. 2) Wählen Sie die Registerkarte Komponenten. Tragen Sie in die erste freie Zeile der Komponentenliste den Namen für das neue Feld, sowie in der Spalte Komponententyp S_TIME ein. 3) Aktivieren Sie die Struktur. 4) 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. 5) 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. 1-3
Alle Aufgaben können mit dem Repository Infosystem gelöst werden. Dieses erreichen Sie aus dem Einstiegsbild des ABAP Ditionary über Umfeld → Repository Infosystem. Expandieren Sie hier den Knoten für das ABAP Dictionary. 1) Expandieren Sie den Knoten Grundobjekte. 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. 2) Durch zweimaliges Zurück gelangen Sie wieder auf das Eingangsbild des Repository Infosystems. Expandieren Sie hier 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. 3) Durch zweimaliges Zurück gelangen Sie wieder auf das Eingangsbild des Repository Infosystems. Der Knoten Grundobjekte ist weiterhin expandiert. Wählen Sie Datenbanktabellen aus. Tragen Sie auf dem Selektionsbild die Entwicklungsklasse BC_DATAMODEL und (nach Betätigen von Alle Selektionen) die Auslieferungsklasse A ein. Mit Ausführen erzeugen Sie die gewünschte Liste.
1-4
© SAP AG
Gehen Sie in das Einstiegsbild des ABAP Dictionary. Wählen Sie Datenbanktabelle, und geben Sie im entsprechenden Feld SFLIGHT ein. Betätigen Sie nun den Druckknopf Verwendungsnachweis. Im folgenden Dialogfenster ist die Verwendung in Programmen bereits (als einziges) angekreuzt. Mit Ausführen erzeugen Sie die gewünschte Liste.
TAW12
6-12
1-5
© SAP AG
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. 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 (nach Betätigung von Alle Selektionen). Falls Sie zwei Nachbargruppen haben, müssen Sie bei beiden Möglichkeiten den Druckknopf Mehrfachselektion nutzen. 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).
TAW12
6-13
Änderungen an Datenbanktabellen
z Änderungen an Datenbanktabellen z Auswirkungen von Änderungen der Tabellenstruktur z Umsetzung einer Tabelle z Mögliche Probleme bei Umsetzungen z Append-Strukturen
© SAP AG 1999
© SAP AG
TAW12
7-1
Lernziele des Kurses
Nach Durcharbeiten dieses Kapitels können Sie: z Änderungen an Tabellen durchführen z Einschätzen welche Auswirkungen diese
Änderungen auf die Datenbank haben z Tabellen umsetzen z Abgebrochene Umsetzungen fortsetzen z Kundenfelder an SAP Standardtabellen durch
Append-Strukturen modifikationsfrei anhängen
© SAP AG 2002
© SAP AG
TAW12
7-2
Änderungen an Tabellen
ABAP Dictionary Feld 1 Feld 2 Feld 3
aktive Version
inaktive Version Feld 1 Feld 2 Feld 3 Feld 4
Feld 1 Feld 2 Feld 3
Datenbank © SAP AG 1999
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.
© SAP AG
TAW12
7-3
Wie erfolgt die Strukturanpassung?
Feld 1 Feld 2 Feld 3
Welche Änderung wurde vorgenommen?
aktive Version Feld 1 Feld 2 Feld 3 Feld 4
inaktive Version Enthält die Tabelle Daten?
Löschen, neu Anlegen oder Katalogänderung auf der DB (ALTER TABLE)
Welches Datenbanksystem wird verwendet?
oder Umsetzen der Tabelle
Feld 1 Feld 2 Feld 3
© SAP AG 1999
Die Anpassung der Datenbanktabelle an die geänderte Definition im ABAP Dictionary kann auf drei verschiedene Arten erfolgen: y 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. y 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. y 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.
© SAP AG
TAW12
7-4
Umsetzprozeß 1
Feld 1 Feld 2 Feld 3 NUMC,6 CHAR, 8 CHAR, 60
aktive Version von TAB Feld 3 Feld 1 Feld 2 NUMC,6 CHAR, 8 CHAR, 30
inaktive Version von TAB
TAB
Feld 1 Feld 2 Feld 3 NUMC, 6 CHAR, 8 CHAR, 60 000100 001200 003000
1111A00 0222B10 0030B20
Text1... Text2 ... Text3 ...
TAB ~ 0 TAB ~ A11
© SAP AG 1999
Das folgende Beispiel soll die bei einer Umsetzung notwendigen Schritte verdeutlichen. 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.
© SAP AG
TAW12
7-5
Umsetzprozeß 2
TAB gesperrt
Feld 1 Feld 2 Feld 3 NUMC,6 CHAR, 8 CHAR, 60
11
aktive Version von TAB Feld 1 Feld 2 Feld 3 NUMC,6 CHAR, 8 CHAR, 30
TAB wird gesperrt
inaktive Version von TAB
Löschen der Indizes
Umbenennen von TAB in QCMTAB QCMTAB
TAB
Feld 1 Feld 2 Feld 3 NUMC, 6 CHAR, 8 CHAR, 60 000100 001200 003000
1111A00 0222B10 0030B20
Text1... Text2 ... Text3 ...
22
Feld 1 Feld 2 NUMC, 6 CHAR, 8
Feld 3 CHAR, 60
000100 001200 003000
Text1... Text2 ... Text3 ...
1111A00 0222B10 0030B20
TAB ~ 0 TAB ~ A11
© SAP AG 2002
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. 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.
© SAP AG
TAW12
7-6
Umsetzprozeß 3
TAB gesperrt
Feld 1 Feld 2 Feld 3 NUMC,6 CHAR, 8 CHAR, 60
aktive Version von TAB Feld 1 Feld 2 Feld 3 NUMC,6 CHAR, 8 CHAR, 30
inaktive Version von TAB
33 Aktivieren im
33
ABAP Dictionary TAB wird unter dem Namen QCM8TAB auf der DB angelegt
Feld 1 Feld 2 Feld 3 NUMC, 6 CHAR, 8 CHAR, 60
QCMTAB
000100 001200 003000
1111A00 0222B10 0030B20
Feld 1 Feld 2 Feld 3 NUMC, 6 CHAR, 8 CHAR, 30
Text1... Text2 ... Text3 ...
TAB ~ 0
QCM8TAB
© SAP AG 1999
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!
© SAP AG
TAW12
7-7
Umsetzprozeß 4
TAB gesperrt
Feld 1 Feld 2 Feld 3 NUMC,6 CHAR, 8 CHAR, 30
aktive Version von TAB Daten werden in QCM8TAB zurückgeladen
QCMTAB
Feld 1 Feld 2 NUMC, 6 CHAR, 8 000100 001200 003000
1111A00 0222B10 0030B20
QCM8TAB
Feld 3 CHAR, 60 Text1... Text2 ... Text3 ...
44
Feld 1 Feld 2 Feld 3 NUMC, 6 CHAR, 8 CHAR, 30 000100 001200 003000
TAB ~ 0
1111A00 Text1... 0222B10 Text2 ... 0030B20 Text3 ...
© SAP AG 1999
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.
© SAP AG
TAW12
7-8
Umsetzprozeß 5
Feld 1 Feld 2 Feld 3 NUMC,6 CHAR, 8 CHAR, 30
TAB gesperrt
aktive Version von TAB
77 Sperre löschen
Tabelle QCMTAB löschen
Tabelle umbenennen und Indizes anlegen
QCMTAB
QCM8 TAB
Feld 1 Feld 2 Feld 3 NUMC, 6 CHAR, 8 CHAR, 60 000100 001200 003000
1111A00 0222B10 0030B20
Text1... Text2 ... Text3 ...
66
Feld 1 Feld 2 Feld 3 NUMC, 6 CHAR, 8 CHAR, 30 000100 001200 003000
1111A00 Text1... 0222B10 Text2 ... 0030B20 Text3 ...
55
TAB ~ 0 TAB ~ A11
© SAP AG 2002
Schritt 5: 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 gelöschten Views auf die Tabelle werden auf der Datenbank ebenfalls wieder angelegt. Schritt 6: Die Tabelle QCMTAB wird gelöscht. Schritt 7: Die zu Beginn der Umsetzung gesetzte Sperre wird gelöscht. y Bricht die Umsetzung ab, so bleibt die Tabelle gesperrt und es wird ein Aufsetzprotokoll geschrieben. y 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. y 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.
© SAP AG
TAW12
7-9
Mögliche Probleme bei Umsetzungen
Überlauf des Tablespace Datenverlust bei Schlüsselverkürzungen Unzulässige Typänderung
© SAP AG 2002
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.
© SAP AG
TAW12
7-10
Fortsetzen abgebrochener Umsetzungen
Objektprotokoll
Syslog
Dumps
Was Sie tun sollten
Was Sie nicht tun sollten © SAP AG 2002
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: y Mit der Option Anpassung fortsetzen können Sie, nach Beseitigung der Fehlerursache, die Umsetzung an der Abbruchstelle fortsetzen. y 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.
© SAP AG
TAW12
7-11
Append-Strukturen 1
Feld A Feld B
Append -Struktur
Tabelle Feld 1 Feld 2 Feld 3
Feld 1 Feld 2
Feld 3
Feld A Feld B
© SAP AG 1999
Append-Strukturen erlauben es, Kundenfelder an eine SAP Standardtabelle 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.
© SAP AG
TAW12
7-12
Append-Strukturen 2
Feld A Feld B
Tabelle
Append -Struktur
Feld 1 Feld 2 Feld 3
Neue SAP-Version wird importiert Feld 1 Feld 2 Feld 3 Feld 4
Feld 1 Feld 2
Feld 3
Feld A Feld B
© SAP AG 2002
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. The order of the fields in the ABAP Dictionary can differ from the order of the fields in the database. Beim Anhängen einer Append-Struktur bzw. beim Einfügen von Feldern in eine bestehende AppendStruktur ist keine Umsetzung der Tabelle notwendig. Die neuen Felder werden einfach auf der Datenbank an die Tabelle angehängt. Eine solche Strukturanpassung kann immer durch Anpassen des Datenbank-Katalogs (ALTER TABLE) erfolgen.
© SAP AG
TAW12
7-13
Append-Strukturen 3
Feld A Feld B
Append -Struktur
Tabelle Feld 1 Feld 2 Feld 3
Feld 4
Anhängen des Feldes auf der Datenbank
Aktivieren
Feld 1 Feld 2
Feld 3
Feld A Feld B Feld 4
© SAP AG 2002
Die neue Version der SAP Standardtabelle wird aktiviert und das neue Feld wird an die Datenbanktabelle angehängt. Beachten Sie bei Append-Strukturen bitte auch folgende Punkte: y Für Pool- und Clustertabellen können keine Append-Strukturen angelegt werden. y 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). y 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. y 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.
© SAP AG
TAW12
7-14
Zusammenfassung
z Laufzeitobjekt und Datenbankdefinition einer Tabelle
müssen stets konsistent sein. Deshalb muß bei Änderungen an einer Tabelle im ABAP Dictionary die zugehörige Datenbanktabelle angepaßt werden. z Es wird stets versucht Strukturänderungen an Tabellen
durch eine Änderung des Datenbank-Katalogs (ALTER TABLE) durchzuführen. Falls dies nicht möglich ist, wird eine Umsetzung vorgenommen. z Bei einer Umsetzung werden die Daten kurzzeitig in einer
temporären Tabelle zwischengespeichert und dann in die Tabelle mit neuer Struktur zurückkopiert. z Kundenfelder sollten an SAP Standardtabellen stets über
Append-Strukturen angehängt werden.
© SAP AG 2002
© SAP AG
TAW12
7-15
Änderungen an Datenbanktabellen Übungen Kapitel: Änderungen an Datenbanktabellen
Am Ende dieser Übungen können Sie: Änderungen an bestehenden Objekten durchführen Tabellen umsetzen Standardtabellen über Append-Strukturen modifikationsfrei erweitern Das ursprüngliche Design der Mitarbeiterverwaltung ist nach einigen organisatorischen Änderungen in den Fluggesellschaften nicht mehr angemessen. Deshalb sind kleinere Änderungen an den bereits in den vorhergehenden Übungen angelegten Objekten notwendig geworden. Diese Änderungen sollen in dieser Übung durchgeführt werden. 1-1
Das Design der Tabelle ZFLCREW## ist nicht mehr angemessen. Das Feld für die Rolle des Mitarbeiters während des Fluges ist zu lang. Korrigieren Sie diesen Fehler, indem Sie die Feldlänge auf 15 Stellen reduzieren. 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.
1-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. Legen Sie eine Append-Struktur zur Tabelle ZEMPLOY## an, die die folgenden Informationen enthält:
Feld
Datenelement
Flughafen
S_AIRPORT
Büronummer
S_BUREAUNO
Telefon
S_TELNO Hinweis: Die Feldnamen in einer Append-Struktur müssen im Kundennamensraum für Felder liegen. Die Feldnamen sollten daher mit ZZ oder YY beginnen.
© SAP AG
TAW12
7-16
1-3
Legen Sie für das Feld Flughafen aus der Append-Struktur einen geeigneten Fremdschlüssel an. 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.
Starten Sie nach dieser Übung das Programm BC430_CHECK mit der Transaktion SE38. Das Programm überprüft die Korrektheit Ihrer Lösungen.
© SAP AG
TAW12
7-17
Änderungen an Datenbanktabellen Lösungen Kapitel: Änderungen an Datenbanktabellen
1-1
Verzweigen Sie im Änderungsmodus in das Pflegebild der Tabelle ZFLCREW##. Führen Sie dann die folgenden Schritte aus: 1) Überschreiben Sie in der Spalte Feldtyp das Datenelement SEMP_ROLE durch den Namen ihres Datenelements ZROLE##. Sichern Sie die Änderung. 2) Wählen Sie den Namen ZROLE## aus. Bestätigen Sie im folgenden Dialogfenster, daß Sie das Datenelement anlegen möchten. 3) Sie verzweigen damit in das Pflegebild für Datenelemente. Erfassen Sie eine Kurzbeschreibung. 4) Wählen Sie das Register Definition. Markieren Sie Eingebauter Datentyp. Geben Sie nun Werte für die Felder Datentyp, Länge und Dezimalstellen ein. Geben Sie CHAR als Datentyp und 15 als Länge ein. 5) Pflegen Sie auf der Registerkarte Feldbezeichner die Texte zum Datenelement. 6) Aktivieren Sie das Datenelement. 7) Lassen Sie sich das Aktivierungsprotokoll anzeigen. Dort werden Sie darauf hingewiesen, daß die vorgenommene Feldverkürzung eine Umsetzung der Tabelle ZFLCREW## erforderlich macht. 8) Navigieren Sie in die Tabellenpflege zurück. 9) Navigieren Sie mit Hilfsmittel → Datenbank-Utility in das Datenbank-Utility. 10) Wählen Sie Aktivieren und Datenbank anpassen. Bestätigen Sie die folgende Sicherheitsabfrage. Das System führt nun die notwendige Umsetzung durch.
1-2
Gehen Sie wie folgt vor, um die Append-Struktur zur Tabelle ZEMPLOY## zu definieren: 1) Verzweigen Sie im Anzeigemodus in das Pflegebild der Tabelle ZEMPLOY##. 2) Wählen Sie Springen → Append-Struktur. 3) 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. 4) Sie verzweigen damit in das Pflegebild der Append-Struktur. Die Pflege verhält sich völlig analog zur Pflege einer Struktur. 5) Erfassen Sie eine Kurzbeschreibung, und nehmen Sie die Felder Flughafen, Büronummer und Telefonnummer mit den genannten Datenelementen auf. 6) Hinweis: Alle Felder einer Append-Struktur müssen im Kundennamensraum liegen. Die Feldnamen müssen deshalb mit ZZ oder YY beginnen.
© SAP AG
TAW12
7-18
7) Aktivieren Sie die Append-Struktur. Lassen Sie sich das Aktivierungsprotokoll über Springen → Aktivierungsprotokoll anzeigen. Die Tabelle ZEMPLOY## wird automatisch angepasst, wenn Sie die AppendStruktur aktivieren. Die neuen Felder werden auf der Datenbank an die bereits vorhandenen Felder angehängt. 1-3
Der Fremdschlüssel muß in der Pflege der Append-Struktur definiert werden. Diese erreichen Sie entweder, indem Sie im Einstiegsbild des ABAP Dictionary deren Namen als Datentyp angeben und die Funktion Ändern wählen, oder über Springen → Append-Struktur aus der Pflege der Tabelle ZEMPLOY##. Führen Sie hier folgende Schritte aus: 1) Stellen Sie den Cursor auf das Feld Flughafen. Wählen Sie die Schlüsselikone. Übernehmen Sie den Systemvorschlag. 2) 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. 3) 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 AppendStruktur 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. 4) 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). 5) Wählen Sie Übernehmen und aktivieren Sie danach die Append-Struktur.
© SAP AG
TAW12
7-19
Views
z Wozu braucht man Views? z Erzeugen eines Views durch Join, Projektion und
Selektion z Joinbedingungen und Fremdschlüssel z Selektion von Daten über Views z Datenbank-Views z Pflege-Views z Inner Join und Outer Join
© SAP AG 2002
© SAP AG
TAW12
8-1
Lernziele des Kurses
Nach Durcharbeiten dieses Kapitels können Sie: z beurteilen, wie ein View durch Join, Projektion und
Selektion aus Tabellen erzeugt wird z Datenbank-Views anlegen z den Zusammenhang zwischen Fremdschlüsseln und
Joinbedingungen herstellen z Views in Programmen zur Datenselektion einsetzen z die Einsatzmöglichkeiten von Pflege-Views beurteilen z den Unterschied zwischen Inner Join und Outer Join
erkennen
© SAP AG 2002
© SAP AG
TAW12
8-2
Wozu braucht man Views?
View auf die Tabellen F1
Sicht auf Daten, die auf mehrere Tabellen verteilt sind
F1 F2 F3
Tabelle 1
F2
F3
F4
F5
Tabelle 2
F5
F8
F6 F7 F8
Tabelle 3
© SAP AG 1999
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.
© SAP AG
TAW12
8-3
Aufbau eines Views - Ausgangssituation
Tabelle Feld 1 Feld 2 TABA Text 1 1 Text 2 2
Feld 3
Feld 4 Feld 5 A B A B
1 1 2 2
Feld 1
Feld 2
Feld 3
1 1 1 1 2 2 2 2
Text 1 Text 1 Text 1 Text 1 Text 2 Text 2 Text 2 Text 2
1 1 2 2 1 1 2 2
Text 3 Text 4 Text 5 Text 6
Feld 4 Feld 5 A B A B A B A B
Text 3 Text 4 Text 5 Text 6 Text 3 Text 4 Text 5 Text 6
Tabelle TABB
Kreuzprodukt der Tabellen TABA und TABB
© SAP AG 2002
Der Aufbau eines Views und die Datenselektion mit Hilfe dieses Views wird in einem Beispiel gezeigt. Gegeben sind die beiden Tabellen TABA und TABB. Die Tabelle TABA enthält zwei Einträge, die Tabelle TABB vier Einträge. Zuerst werden die Tabellen aneinander gehängt. Daraus ergibt sich das Kreuzprodukt der zwei Tabellen, in dem jeder Satz der Tabelle TABA mit jedem Satz der Tabelle TABB kombiniert wird.
© SAP AG
TAW12
8-4
Aufbau eines Views - Join-Bedingung
Join-Bedingung: TABA - Feld 1 = TABB - Feld 3 Feld 1
Reduzieren des Kreuzprodukts
1 1 1 1 2 2 2 2
Feld 2
Feld 3
Text 1 Text 1 Text 1 Text 1 Text 2 Text 2 Text 2 Text 2
1 1 2 2 1 1 2 2
Feld 4 Feld 5 A B A B A B A B
Text 3 Text 4 Text 5 Text 6 Text 3 Text 4 Text 5 Text 6
© SAP AG 1999
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 Feld 1 von TABA mit Feld 3 von TABB identifiziert werden. Die JoinBedingung lautet also: TABA-Feld 1 = TABB-Feld 3 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.
© SAP AG
TAW12
8-5
Aufbau eines Views - Feldauswahl (Projektion)
Feld 1 1 1 2 2
Feld 2 Feld 4 Feld 5 Text 1 Text 1 Text 2 Text 2
A B A B
Text 3 Text 4 Text 5 Text 6
Projektion Feld 1 1 1 2 2
Feld 2
Feld 5
Text 1 Text 1 Text 2 Text 2
Text 3 Text 4 Text 5 Text 6
© SAP AG 1999
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 Feld 4 nicht von Interesse und wird deshalb ausgeblendet.
© SAP AG
TAW12
8-6
Aufbau eines Views - Selektionsbedingung
Feld 1 1 1 2 2
Feld 2
Feld 5 Feld 4
Text 1 Text 1 Text 2 Text 2
Text 3 Text 4 Text 5 Text 6
A B A B
Selektionsbedingung: TABB - Feld 4 = ‘A’. Feld 1 1 1 2 2
Feld 2
Feld 5
Text 1 Text 1 Text 2 Text 2
Text 3 Text 4 Text 5 Text 6
© SAP AG 2002
Ü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 4 den Wert A haben. Eine Selektionsbedingung kann also auch über ein nicht im View enthaltenes Feld formuliert werden.
© SAP AG
TAW12
8-7
Wie werden Tabellen zu Views verknüpft? MANDT
ID
NAME
CITY
...
001
122356
Smith
New York
...
MANDT CARRID
SCUSTOM
CONNID FLDATE BOOKID CUSTOMID ...
001
AA
48
...
3689
122356
...
001
LH
324
...
3690
122356
...
MANDT CARRID CONNID ... CITYFROM ... CITYTO ... 001
AA
48
... New York ... Berlin
001
LH
324
...
Berlin
...
SBOOK
SPFLI
...
Tokyo ...
© SAP AG 2002
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
© SAP AG
TAW12
8-8
Struktur des Views
View SCUS_BOOK für die Buchungen der Kunden MANDT
ID
NAME
CITY
001
122356
Smith
New York
001
122356
Smith
New York
CARRID CONNID
AA LH
FLDATE
BOOKID CITYFROM CITYTO
48
4.9.1999
3689
324
9.9.1999
3690
New York Berlin
Berlin Tokyo
© SAP AG 2002
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üsselbeziehungen 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.
© SAP AG
TAW12
8-9
Datenselektion über Views
REPORT SAPBC430_FLIGHTS. DATA: WA_FLIGHTS TYPE LINE_TYPE_FLIGHTS, ITAB_FLIGHTS TYPE TABLE OF LINE_TYPE_FLIGHTS. SELECT CARRID CARRNAME CONNID CITYFROM CITYTO FLDATE SEATSMAX SEATSOCC INTO TABLE ITAB_FLIGHTS FROM SV_FLIGHTS WHERE CITYFROM IN SO_CITYF AND CITYTO IN SO_CITYT AND SEATSOCC < SV_FLIGHTS~SEATSMAX ORDER BY CARRID CONNID FLDATE.
IF SY-SUBRC 0. WRITE: / ‘Keine Buchungen vorhanden’. ENDIF.
© SAP AG 2002
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.
© SAP AG
TAW12
8-10
Inner Join und Outer Join Tabelle TABA
Tabelle TABB
Feld 1
Feld 2
A B C
Text 1 Text 2 Text 5
Feld 3 Feld 4 A B
Text 3 Text 4
Join-Bedingung
Was wird über den View angezeigt? Feld 1
Feld 2
Feld 4
Feld 1
Feld 2
Feld 4
A B
Text 1 Text 2
Text 3 Text 4
A B C
Text 1 Text 2 Text 5
Text 3 Text 4
Inner Join
Outer Join
© SAP AG 1999
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.
© SAP AG
TAW12
8-11
Datenbank-View
ABAP Programm Viewdefinition im ABAP Dictionary F1
F2
F3
F5
F8 Datenbank-Schnittstelle
Wird beim Aktivieren auf der DB angelegt
F1
F1 F2 F3
Tabelle 1
F2
F4
F3
F5
F5
Tabelle 2
F8
Viewdefinition auf der Datenbank
F6 F7 F8
Tabelle 3
© SAP AG 1999
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.
© SAP AG
TAW12
8-12
Includes in Datenbank-Views
Datenbank-View auf TABA, TABB und TABC F1
F3
F4
F5
F6
F8
TABB in View inkludiert
F1
TABA
F2
F3
F4
F5
TABB
F6
F 7
F8
TABC
© SAP AG 1999
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 DatenbankViews 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.
© SAP AG
TAW12
8-13
Pflege-Views
Anwendungsobjekt
Pflege-View auf die Tabellen
F1
F2
F3
F5
F8 Datenaustausch über den Pflege-View
Tabelle 1 F1 F2 F3
Tabelle 2 F4 F5
Fremdschlüssel
Tabelle 3 F6 F7 F8
Fremdschlüssel
© SAP AG 1999
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.
© SAP AG
TAW12
8-14
Zusammenfassung (des Kapitels)
z Über einen View können auf verschiedene Tabellen
verteilte Datensätze zusammengeführt werden. z Ein View wird durch die relationalen Operatoren Join,
Projektion und Selektion aus den beteiligten Tabellen abgeleitet. z ABAP Programme können Daten über einen View
selektieren. Die Selektion über einen Datenbank-View ist in der Regel schneller als die direkte Selektion aus den Tabellen über ein geschachteltes SELECT-Statement. z Ein Pflege-View erlaubt es, Datensätze aus mehreren
Tabellen gemeinsam zu pflegen.
© SAP AG 2002
© SAP AG
TAW12
8-15
Views Übungen Kapitel: Views
Am Ende dieser Übungen können Sie: 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.
1-1
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 CrewMitglieder sehen. Weiterhin soll für Nachfragen noch die Telefonnummer der Abteilung des Mitarbeiters ausgegeben werden. 1-1-1 Legen Sie einen entsprechenden Datenbank-View ZEMPFLY## an, der diese Anforderungen erfüllt. Es sollen folgende Informationen zu einem Mitarbeiter angezeigt werden: Mandant Fluggesellschaft Personalnummer Vorname Nachname Telefonnummer der Abteilung Abteilungskürzel 1-1-2 Sorgen Sie dafür, daß nur fliegendes Personal über den View selektiert werden kann. 1-1-3 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.
1-2 © SAP AG
Ergänzende Übung: Legen Sie einen Pflege-View mit Namen ZPARTNER## an, mit dem Sie bequem neue Geschäftspartner einpflegen können. Die TAW12
8-16
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. Generieren Sie die Pflegeoberfläche. Verwenden Sie dabei folgende Parameter: Funktionsgruppe:
ZZBC430##
Berechtigungsgruppe: Pflegetyp: Übersichtsbild:
SUNI
Einstufig 100
Pflegen Sie dann die Daten eines neuen Reisebüros über die erweiterte Tabellenpflege (System → Dienste → Tabellenpflege → Erweit. Tab.pflege) ein.
© SAP AG
TAW12
8-17
Views Lösungen Kapitel: Views
1-1
Der View sollte eine Sicht auf die Daten in den Tabellen ZEMPLOY## und ZDEPMENT## ermöglichen. Gehen Sie wie folgt vor, um diesen View anzulegen: 1) Markieren Sie im Einstiegsbild des ABAP Dictionary den Objekttyp View, geben Sie den Objektnamen ZEMPFLY## ein und wählen Sie Anlegen. 2) Es erscheint ein Dialogfenster, in dem Sie den Viewtyp wählen müssen. Markieren Sie Datenbank-View und wählen Sie Auswählen. 3) Geben Sie auf dem Folgebild einen Kurztext ein. Der View sollte Daten über Mitarbeiter (aus Tabelle ZEMPLOY##) und über Abteilungen (aus Tabelle ZDEPMENT##) anzeigen. 4) Geben Sie zuerst ZEMPLOY## im Feld Tabellen ein. 5) 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. 6) Damit werden die Join-Bedingungen aus dem Fremdschlüssel übernommen. 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! 7) Nun müssen noch Felder aus den Tabellen in den View übernommen werden. Wählen Sie View-Felder aus. 8) Betätigen Sie den Druckknopf Tabellenfelder. Markieren Sie im folgenden Dialogfenster die Tabelle ZEMPLOY##, und wählen Sie Auswählen. 9) 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. 10) 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. Es soll nur fliegendes Personal über den View selektiert werden. Diese Einschränkung kann über eine Selektionsbedingung definiert werden. 11) Wählen Sie Selektionsbedingungen. 12) Die Einschränkung, ob ein Mitarbeiter zum fliegenden Personal gehört, ist im Feld ZEMPLOY##-Bereich enthalten. Tragen Sie dieses in die Spalten Tabelle und Feldname ein. 13) Mitarbeiter des fliegenden Personals werden durch den Wert F im Feld Bereich identifiziert. Tragen Sie deshalb in der Spalte Operator EQ und in der Spalte Vergleichswert 'F' (inklusive Hochkommas) ein.
© SAP AG
TAW12
8-18
Der View muß nun noch gepuffert werden. 14) 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. 15) Markieren Sie Pufferung eingeschaltet und vollständig gepuffert. 16) Sichern Sie die technischen Einstellungen, und kehren Sie in die Pflege des Views zurück. 17) Aktivieren Sie den View. 1-2
Gehen Sie dazu wie folgt vor: 1) Markieren Sie im Einstiegsbild des ABAP Dictionary den Objekttyp View, geben Sie den Objektnamen ZPARTNER## ein und wählen Sie Anlegen. 2) Es erscheint ein Dialogfenster, in dem Sie den Viewtyp wählen müssen. Markieren Sie Pflege-View und wählen Sie Auswählen. 3) Geben Sie auf dem Folgebild einen Kurztext ein. 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. Aus diesem Grund müssen Sie auch bei der Definition des Pflege-Views zuerst die Tabelle SBUSPART aufnehmen. 4) Tragen Sie die Tabelle SBUSPART im Feld Tabellen ein. Die Schlüsselfelder dieser Tabelle werden damit automatisch als Felder in den View aufgenommen. 5) Stellen Sie den Cursor im Feld Tabellen auf den Eintrag SBUSPART. Wählen Sie Beziehungen. 6) Es erscheint ein Dialogfenster, in welchem alle bestehenden Fremdschlüsselbeziehungen der Tabelle SBUSPART zu anderen Tabellen aufgelistet sind. Markieren Sie dort die Fremdschlüsselbeziehung zur Tabelle STRAVELAG, und wählen Sie Übernehmen. 7) Die Join-Bedingungen werden nun aus dem Fremdschlüssel erzeugt. Die JoinBedingungen haben folgende Form: SBUSPART-MANDANT = STRAVELAG-MANDT SBUSPART-BUSPARTNUM = STRAVELAG-AGENCYNUM 8) Jetzt müssen die Felder der beiden Tabellen in den View aufgenommen werden. Wechseln Sie hierzu 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. 9) 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. 10) Aktivieren Sie den View. Sie müssen nun noch eine Pflegeoberfläche für den View generieren.
© SAP AG
TAW12
8-19
11) Wählen Sie Hilfsmittel → Tabellenpflegegenerator. 12) Geben Sie im Folgebild die Berechtigungsgruppe SUNI und die Funktionsgruppe ZZBC430## ein. 13) Markieren Sie den Pflegetyp einstufig. Wählen Sie die Nummer 0100 als Pflegebildnummer des Übersichtsbildes. 14) 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. 15) Rufen Sie die erweiterte Tabellenpflege über den angegebenen Menüpfad auf, und geben Sie die Daten eines neuen Reisebüros ein. 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.
© SAP AG
TAW12
8-20
Suchhilfen
z Eingabehilfe im R/3 System z ABAP Dictionary Objekt Suchhilfe
Selektionsmethode einer Suchhilfe
Dialogverhalten einer Suchhilfe
Schnittstelle einer Suchhilfe
z Anbindung von Suchhilfen an Felder z Sammelsuchhilfen und elementare Suchhilfen z Append-Suchhilfen
© SAP AG 1999
© SAP AG
TAW12
9-1
Lernziele des Kurses
Nach Durcharbeiten dieses Kapitels können Sie: z über eine Suchhilfe einen Eingabehilfeablauf definieren z eine Suchhilfe mit mehreren alternativen Suchpfaden
definieren z die verschiedenen Mechanismen der Suchhilfeanbindung
nutzen, um eine Suchhilfe einem Bildschirmfeld zuzuordnen z für ein Bildschirmfeld feststellen, ob und welche Form
der Eingabehilfe vorliegt z eine Sammelsuchhilfe mit Hilfe einer Append-Suchhilfe
modifikationsfrei erweitern
© SAP AG 2002
© SAP AG
TAW12
9-2
SAP R/3-Standardfunktion: Eingabehilfe
Fluggesellschaft LH Nr.
Pflege von Flügen Fluggesellschaft Flugnummer
Ankunftsort
0400
Frankfurt
New York
0402
Frankfurt
New York
2402
Frankfurt
Berlin
...
LH
Abflugort
...
...
F4
...
© SAP AG 2002
Die Eingabehilfe (F4-Hilfe) iste eine Standardfunktion des R/3-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 R/3 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 R/3 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.
© SAP AG
TAW12
9-3
Anforderungen der Eingabehilfe
Festlegen der Werte
Kontext einbeziehen
Dialog mit dem Benutzer
Rückgabewerte
© SAP AG 2002
An die Eingabehilfe eines Bildschirmfelds (Suchfeld) werden eine Reihe von Anforderungen gestellt: y 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. y 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. y 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. y 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.
© SAP AG
TAW12
9-4
ABAP Dictionary Objekt-Suchhilfe
Selektionsmethode
Dialogverhalten
Suchhilfe
Schnittstelle
© SAP AG 2002
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.
© SAP AG
TAW12
9-5
Selektionsmethode einer Suchhilfe
Pflege von Flügen Fluggesellschaft
LH
Flugnummer
F4
...
SELECT * FROM SPFLI
WHERE CARRIER = 'LH'.
SPFLI © SAP AG 2002
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ß DatenbankViews (im R/3 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.
© SAP AG
TAW12
9-6
Beschreibung des Dialogverhaltens
F4
Fluggesellschaft LH Nr
Abflugstadt
Ankunftstadt
0400
Frankfurt
New York
0402
Frankfurt
New York
2402
Frankfurt
Berlin
...
...
Fluggesellschaft
=
LH
Verbindungs-Nummer
[*]
0*
...
Abflugstadt Ankunftstadt Anzahl beschränken auf
500
keine Beschränkung
© SAP AG 1999
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 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.
© SAP AG
TAW12
9-7
Schnittstelle einer Suchhilfe
F4 Fluggesellschaft LH Nr.
Abflugort
Ankunftsort
0400
Frankfurt
New York
0402
Frankfurt
New York
Import und Export
Fluggesellschaft
LH
Flugnummer
0*
F4
...
Export
© SAP AG 2002
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 IMPORTParameter definieren, da der Benutzer die entsprechenden Dynprofelder sonst jedes Mal leeren muß, bevor er mit der Eingabehilfe einen neuen Wert bestimmen kann.
© SAP AG
TAW12
9-8
Wie benutzt man Suchhilfen? Suchhilfe Internes Verhalten
Schnittstelle
Anbindung im DDIC
Eingabemaske Feld 1
Feld 3
Feld 3
...
Tabelle/Struktur
Feld 1 Suchfeld
Suchfeld
F4 Definitionen im Screen Painter
© SAP AG 2002
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 IMPORTParameter 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.
© SAP AG
TAW12
9-9
Suchhilfeanbindung im ABAP Dictionary
SuchhilfeInternes Verhalten Schnittstelle
Prüftabelle MANDT
Datenelement
Schlüssel Schlüssel Datenteil 1 2
MANDT
Feld 1
Suchfeld
Feld 3
...
Tabelle/Struktur © SAP AG 2002
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.
© SAP AG
TAW12
9-10
Überblick: Mechanismen für die Eingabehilfe Eingabehilfe aus Dynpro vorhanden
Suchhilfe zum Feld
nicht vorhanden
PROCESS ON VALUE-REQUEST
Prüftabellenhilfe Suchhilfe zum Dynprofeld
Prüfung der Ablauflogik
Suchhilfe für Prüftabelle Prüftabelle mit Texttabelle
Schlüsselwerte der Prüftabelle
Suchhilfe zum Datenelement
Festwerte
Uhrzeit- oder Kalenderhilfe
© SAP AG 2002
Um für möglichst viele Bildschirmfelder eine sinnvolle Eingabehilfe anbieten zu können, verwendet das R/3-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.
© SAP AG
TAW12
9-11
Performance der Eingabehilfe
Pflege von Flügen Fluggesellschaft Flugnummer
LH F4
... © SAP AG 1999
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.
© SAP AG
TAW12
9-12
Alternative Suchpfade
Welche Buchungen wurden über unser Reisebüro abgewickelt?
Wie lautet die Buchungsnummer für meinen Flug nach New York?
© SAP AG 2002
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 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 R/3 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.
© SAP AG
TAW12
9-13
Sammelsuchhilfen und elementare Suchhilfen
Sammelsuchhilfe Inkludierte Suchhilfen
Internes Verhalten
Internes Verhalten
Schnittstelle
Schnittstelle
Schnittstelle
© SAP AG 2002
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 AG
TAW12
9-14
Append-Suchhilfen
Append (SAP) Sammelsuchhilfe
Inkludierte Suchhilfen
Inkludierte Suchhilfen
...
...
(Kunden-) AppendSuchhilfe
© SAP AG 2002
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.
© SAP AG
TAW12
9-15
Zusammenfassung
z Die Eingabehilfe (F4-Hilfe) ist eine Standardfunktion
des R/3 Systems z Suchhilfen ermöglichen eine bequeme und flexible
Beschreibung von Eingabehilfen z Als Selektionsmethode einer Suchhilfe können
Tabellen und Views verwendet werden z Das Aussehen der Eingabehilfe wird über die
Parameter der Suchhilfe gesteuert z Suchhilfen können an Felder, Tabellen und
Datenelemente abgebunden werden z Eingabehilfen mit alternativen Suchpfaden werden
über Sammelsuchhilfen realisiert z Mit Append-Suchhilfen können modifikationsfrei
Suchhilfen zu Sammelsuchhilfen des SAP-Standard hinzugefügt oder aus ihnen ausgeblendet werden © SAP AG 1999
© SAP AG
TAW12
9-16
Suchhilfen Übungen Kapitel: Suchhilfen
Am Ende dieser Übungen können Sie: 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 müssen ihnen geeignete Suchmöglichkeiten zur Verfügung gestellt werden. In dieser Übung sollen solche Suchmöglichkeiten realisiert werden.
1-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
© SAP AG
TAW12
9-17
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. 1-2
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 ZSRCH99_AREA in Ihre neue Suchhilfe ZEMPLOY##_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 ZSRCH99_DEPT 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.
1-3
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.
© SAP AG
TAW12
9-18
Eingabehilfen Lösungen Kapitel: Suchhilfen
1-1
Rufen Sie, ausgehend von der Pflegetransaktion der Tabelle ZDEPMENT##, die F4-Hilfe wie beschrieben auf. Gehen Sie in die Tabellenpflege für Tabelle ZDEPMENT##, markieren Sie das Feld für den Abteilungsleiter und wählen Sie Springen → Suchhilfe → für Feld, um sicherzustellen, dass keine Suchhilfe zugeordnet wurde. Durch einen Doppelklick auf den Prüftabellennamen für das Feld gelangen Sie auf das Tabellenpflegebild für Tabelle ZEMPLOY##. Wählen Sie Springen → Suchhilfe → für Tabelle, um sicherzustellen, dass keine Suchhilfe zugeordnet ist. Sie finden die Information, dass die Eingabehilfe die Prüftabellenhilfe zur Tabelle ZEMPLOY## ist und dass es sich um die reine Prüftabellenhilfe (ohne Suchhilfe und ohne Texttabelle) handelt. So legen Sie die Suchhilfe ZEMPLOY##_ESH1 an: 1) Wählen Sie Suchhilfe im Einstiegsbild des ABAP Dictionary, und geben Sie in das entsprechende Feld den Namen ZEMPLOY##_ESH1 ein. 2) Wählen Sie Anlegen. Bestätigen Sie im folgenden Dialogfenster, daß Sie eine elementare Suchhilfe anlegen möchten. 3) Erfassen Sie eine Kurzbeschreibung für Ihre Suchhilfe. 4) 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. 5) Um das beschriebene Verhalten zu erreichen, müssen Sie den Dialogtyp Dialog mit Werteeinschränkung wählen. 6) 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. 7) 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. 8) Um die Trefferliste zu gestalten, müssen Sie in der Spalte LPos entsprechende Positionsnummern (z.B. 1, 2, 3, 4, 5) vergeben. 9) 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.
© SAP AG
TAW12
9-19
10) 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. 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. Dies können Sie wie folgt durchführen: 1) 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. 2) 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. Aktivieren Sie Tabelle ZEMPLOY##. 3) 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. 1-2
Gehen Sie dazu wie folgt vor: Geben Sie auf dem Einstiegsbild des Dictionary im Namensfeld der Suchhilfe ZSRCH99_AREA 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. Ä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. Wiederholen Sie den obigen Vorgang zum Anlegen der Suchhilfe ZEMPLOY##_DEPT. 3) Kopieren Sie die Suchhilfe ZEMPLOY##_DEPT nach ZEMPLOY##_CSH. Rufen Sie auf dem Suchhilfenpflegebild Bearbeiten → Suchhilfetyp ändern auf und bestätigen Sie die Änderung. 4) Wählen Sie die Registerkarte Inkludierte Suchhilfen. Geben Sie die Suchhilfe ZEMPLOY##_ESH1 ein. 5) Positionieren Sie den Cursor auf die soeben eingetragene Suchhilfe. Wählen Sie Parameterzuordnung. Lassen Sie sich einen Vorschlag für die Zuordnung erzeugen. 6) Der Vorschlag ist vermutlich bereits korrekt. Prüfen Sie den Vorschlag zur Sicherheit und übernehmen Sie ihn dann. 7) Wiederholen Sie die Schritte 4 – 6 für die inkludierten Suchhilfen ZEMPLOY##_AREA und ZEMPLOY##_DEPT. 8) Aktivieren Sie die Suchhilfe ZEMPLOY##_CSH. 9) 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
© SAP AG
TAW12
9-20
System einen Vorschlag erstellen, kontrollieren und übernehmen Sie ihn. Aktivieren Sie Tabelle ZEMPLOY##. 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. 1-3
Da die gewünschten Änderungen ohne Modifikationen an bereits bestehenden Objekten vorgenommen werden sollen, muß eine Append-Suchhilfe zur Sammelsuchhilfe ZEMPLOY##_CSH angelegt werden. Gehen Sie dazu wie folgt vor: 1) Gehen Sie im Anzeigemodus auf das Pflegebild für die Suchhilfe ZEMPLOY##_CSH. Wählen Sie Springen → Append-Suchhilfen. 2) Im folgenden Dialogfenster wird Ihnen bereits ein Name für die AppendSuchhilfe vorgeschlagen. Sie können diesen übernehmen. 3) Erfassen Sie eine Kurzbeschreibung für die Append-Suchhilfe. 4) Wählen Sie die Registerkarte Inkludierte Suchhilfen. 5) Tragen Sie ZEMPLOY##_DEPT in die Liste der inkludierten Suchhilfen ein. Markieren Sie die Spalte Ausgeblendet für den Eintrag. 6) 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. 7) Die vom System vorgeschlagene Parameterzuordnung ist vermutlich schon korrekt. Kontrollieren Sie dies, und übernehmen Sie die Zuordnung. 8) Aktivieren Sie Ihre Append-Suchhilfe. Durch Aufruf der Eingabehilfe für das Feld ZDEPMENT##-Abteilungsleiter können Sie den Erfolg kontrollieren.
© SAP AG
TAW12
9-21
Anhang
z Flugmodell z Entscheidungsbaum zur Pufferung z ergänzende Informationen über Suchhilfen z Wichtige Menüpfade z Schlagwortverzeichnis
© SAP AG 1999
© SAP AG
TAW12
10-1
Flugdatenmodell der ABAP-Schulungen
Startort
Startflughafen
Aufgaben des Reisebüros: Zielflughafen • mögliche Flughäfen • mögliche Fluglinien zur gewünschten Zeit • mögliche Flüge zum gewünschten Datum • weitere Informationen zu den Flügen: Preise, Buchungen, ... Zielort
© SAP AG 2002
In den ABAP-Schulungen wird einheitlich ein Flugdatenmodell verwendet. Hier genügt es, einen einfachen Ausschnitt dieses Datenmodells zu zeigen; bei Bedarf kann dies dann noch verfeinert werden. Wollen Sie als Kunde von einem Ort zum anderen gelangen, so ist Ihre Anforderung an ein Reisebüro herauszubekommen: y über welche Flughäfen sich der Reisewunsch am geschicktesten realisieren läßt y wann am gewünschten Tag, zu einer akzeptablen Zeit, Flüge angeboten werden y in Abhängigkeit von individuellen Optimierungsbedingungen die optimale Lösung herauszufinden, z.B. den günstigsten Flug, die schnellste Verbindung, diejenige Verbindung, die am nächsten am gewünschten Ankunftszeitpunkt liegt. Diese Sichtweise unterscheidet sich von der eines Reisebüros: Die Daten sind dort nach rein technischen Kriterien im Datenmodell in Tabellen in einer zentralen Datenbank abgelegt. In der Regel ist der Kunde nicht an allen erforderlichen Daten interessiert (z.B. müssen Sie eingeben, welcher Kunde welchen Flug buchte, wann die Buchung gemacht wurde, wie viel der Kunde bezahlte, usw.). Über Programme müssen die Daten nach den Anforderungen der Anwender zusammengestellt werden.
© SAP AG
TAW12
10-2
Datenmodell BC_TRAVLAG T CR
Reisebüro BC_GEOCITY T
Stadt BC_CITAIRP
A
BC_AIRPORT
T
Verkaufsstelle
StadtFlughafenzuordnung
A
Flughafen
BC_COUNTER T
T
CR
R
BC_CUSTOM T
R
Flugkunde H
BC_CARRIER T
Fluggesellschaft
BC_PLANFLI H
Flugplan
T
BC_SFLIGHT H
Flug
T
BC_BOOKING T H
Buchungen
Zeit © SAP AG 2002
Für alle logisch zusammengehörenden Informationen können Entitäten definiert werden: Das Flugdatenmodell enthält daher je eine Entität für: y alle Städte y alle Fluglinien y alle Fluggesellschaften y alle Flughäfen y alle Flüge y Die Entitäten stehen in einer gewissen Beziehung zueinander: y Fluglinien starten und enden an einem Flughafen. y Eine Fluglinie wird durch Fluggesellschaft, Startflughafen, Zielflughafen sowie die Abflugzeit eindeutig charakterisiert. y Zu jeder Fluglinie können Flüge an mehreren Tagen im Jahr angeboten werden, aber ein Flug kann nur zu einer bestehenden Fluglinie existieren. y Den Städten müssen alle nahegelegenen Flughäfen zugeordnet werden. y Dieses Datenmodell verwaltet alle benötigten Daten ohne unnötige Redundanzen und ermöglicht es dem Reisebüro, die aus Kundensicht gewünschten Daten zu erhalten.
© SAP AG
TAW12
10-3
Realisierung im ABAP-Dictionary:
SCARR
SPFLI
Fluggesellschaft
Flugplan
MANDT CARRID CARRNAME .....
MANDT CARRID CONNID AIRPFROM AIRPTO DEPTIME .....
SFLIGHT:
SBOOK
Flug
Flugbuchung
MANDT CARRID CONNID FLDATE SEATSMAX SEATSOCC .....
MANDT CARRID CONNID FLDATE BOOKID CUSTOMID COUNTER AGENCYNUM .....
H 11001
Fluggesellschaft
11001 H
Flugplan
11001 H
Flug
11001 H
Buchungen
Zeit © SAP AG 2002
Die Beispiele und Übungen der ABAP Schulungen sowie der ABAP Dokumentation beziehen sich auf das Flugdatenmodell der SAP. Die Repository-Objekte zum Flugdatenmodell befinden sich in der Entwicklungsklasse SAPBC_DATAMODEL. Folgende Tabellen des Flugdatenmodells werden in den ABAP-Schulungen vorwiegend verwendet: - SPFLI: Tabelle der Flugverbindungen - SFLIGHT: Tabelle der Flüge - SBOOK: Tabelle der Flugbuchungen - SCARR: Tabelle der Fluggesellschaften - SBUSPART: Tabelle der Fluggeschäftspartner - STRAVELAG: Tabelle der Reisebüros - SCUSTOM: Tabelle der Flugkunden - SCOUNTER: Tabelle der Verkaufsschalter
© SAP AG
TAW12
10-4
Entscheidungsbaum zur Pufferung Start Sind temp. Inkonsistenzen der gelesenen Daten akzeptabel? Wird überwiegend lesend zugegriffen?
Nein
Tabelle darf nicht gepuffert werden.
Ja Tabelle darf gepuffert werden
Ist die erwartete Tabellengröße kleiner als 8KB?
Ja
Vollständige Pufferung
Nein Wird überwiegend mit SELECT SINGLE auf die Tab. zugegriffen? Nein Ist die erwartete Tabellengröße größer als 1MB (>> 1000 Sätze)?
Ja
Ja
Nein Ja Ist beim Zugriff auf die Tabelle in der Regel ein linksbündiger Teil des Schlüssels spezifiziert?
Nein
Pufferung von Einzelsätzen Pufferung abhängig von Inatallation. Weitere Überlegungen sind erforderlich: Vollständige oder generische Pufferung möglich? Sekundärindizes oder Pufferung? Generische Pufferung mit geeigneter Zahl generischer Schlüsselfelder Vollständige Pufferung
© SAP AG 2002
© SAP AG
TAW12
10-5
View als Selektionsmethode einer Suchhilfe
Basistabelle 1
Basistabelle 2
DB-View
Primärtabelle
Sekundärtabelle
Help-View © SAP AG 2002
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 R/3 System über einen HelpView realisiert werden. Bei Help-Views wird die selbe Outer Join Logik verwendet wie bei PflegeViews. Die Definition eines Help-Views erfolgt analog zur Definition eines Pflege-Views. Help-Views können nur als Selektionsmethoden in Suchhilfen verwendet werden. Das R/3 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.
© SAP AG
TAW12
10-6
Weitere Optionen bei Suchhilfen
Defaultwerte
Suchhilfe
Ausblenden von inkludierten Suchhilfen
Kurzanwahl
Anzeigefelder im Dialogfenster zur Werteeinschränkung
© SAP AG 2002
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 =.., so wird diese elementare Suchhilfe prozessiert. Dabei werden , 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.
© SAP AG
TAW12
10-7
Abweichung vom Standard: Suchhilfe-Exit Fluggesellschaft
Pflege von Buchungen
Nr
Abflugstadt
Alitalia ...
Frei
Fluggesellschaft AZ
0555
Rom
...
147
Flugnummer
0555
Rom
...
198
...
...
...
F4
Flugdatum
...
... SuchhilfeSuchhilfe-Exit SAPBC_GLOBAL_F4_SFLIGHT
Abflugstadt
Rom SELECT * FROM SFLIGHTS...
Ankunftstadt
... © SAP AG 1999
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.
© SAP AG
TAW12
10-8
Migration bestehender Eingabehilfen gehört zu
Help-View H_NAME
Release 3.x
Sekundärtab. 1 ...
gehört zu
Tabelle T
Selektionsmethode
oder
© SAP AG 2002
Release 4.x
Suchhilfeanbindung
el. Suchhilfe H_NAME
Help-View H_NAME Primärtabelle T
DB-View generiert M_ABCDA
MC-Id 1
generiert
MC-Objekt ABCD
Primärtabelle T
MC-Id A
Sammelsuchh. ABCD Suchhilfeinklusionen
el. Suchhilfe ABCDA Selektionsmethode el. Suchhilfe ZABCD1
DB-View M_ABCD1
DB-View M_ABCDA
DB-View M_ABCD1
Selektionsmethode
Sekundärtab. 1 ...
Suchhilfen wurden zu Release 4.0 neu eingeführt. Zuvor konnten Eingabehilfen durch das Anlegen von Matchcodes und Help-Views gestaltet werden, die aber deutlich weniger Funktionalität besaßen. Beim Upgrade auf 4.x werden aus diesen Objekten Suchhilfen mit gleichem Namen erzeugt (ggf. wird dem Namen noch ein Y oder Z vorangestellt). Die Ursprungsobjekte verbleiben aber vorerst im System, auch wenn sie bedeutungslos geworden sind. Ein Help-View war vor Release 4.0 eine vollwertige Beschreibung einer Eingabehilfe, die automatisch an seine Primärtabelle (und nur an diese) angebunden war. Aus jedem Help-View wird eine elementare Suchhilfe erzeugt. In vielen Fällen kann dabei die Primärtabelle des Help-Views als Selektionsmethode eingetragen werden, in den übrigen wird der Help-View verwendet. Die erzeugte Suchhilfe wird an die Primärtabelle des Help-Views angebunden. Eine elementare Suchhilfe wird aus einer Matchcode-ID erzeugt. Die zugeordnete Selektionsmethode ist der generierte Datenbank-View (für eine transparente ID) oder die generierte Pool-Tabelle (für eine nicht transparente ID) der Matchcode-ID. Im ersten Fall wird der erzeugte View als unabhängiges Objekt im ABAP Dictionary verwaltet. Im zweiten Fall hängt die Pooltabelle weiterhin an ihrer Matchcode-Id, da die Matchcodetechnik zur Aktualisierung der Daten in dieser Tabelle verwendet wird. Aus einem Matchcode-Objekt wird eine Sammelsuchhilfe erzeugt. Die Anbindung von Matchcodes an Eingabefelder erfolgte auf Dynproebene. Diese Anbindungen werden in Anbindungen der erzeugten Sammelsuchhilfen an die entsprechenden Dynprofelder umgewandelt. Obiges Bild illustriert die Migration für Help-Views und für transparente Matchcodes.
© SAP AG
TAW12
10-9
Alternativanzeigen der Eingabehilfe
Eingabehilfe-Control
Listbox
© SAP AG 2002
Das R/3-System erkennt drei Darstellungsformen für die Eingabehilfe: - Listbox - Control (amodal) - R/3-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 R/3-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.
© SAP AG
TAW12
10-10
Wichtige Menüpfade und Transaktionen ABAP Dictionary Pflege/Anzeige Werkzeuge Æ ABAP Workbench Æ Entwicklung Æ Dictionary - Dictionary Pflege (SE11) - Dictionary Anzeige (SE12) Repository Infosystem Data Dictionary
1. Werkzeuge Æ ABAP Workbench Æ Entwicklung Æ Dictionary (Dictionary-Objekt, Objektname eingeben und Operation wählen) Umfeld Æ Repository Infosystem oder 2. Werkzeuge Æ ABAP Workbench Æ Übersicht Æ Infosystem - Repository Infosystem (SE84) / Repository Infosystem Data Dictionary (SE15) Datenanzeige/-pflege (Data Browser) 1. Werkzeuge Æ ABAP Workbench Æ Entwicklung Æ Dictionary (Dictionary-Objekt:Tabelle, Tabellenname eingeben und Operation wählen) Hilfsmittel Æ Tabelleninhalt Æ Anzeigen bzw. Tabelleninhalt Æ Einträge erfassen oder 2. Werkzeuge Æ ABAP Workbench Æ Übersicht Æ Data Browser Datenanzeige/-pflege (Data Browser) (SE16) Index Werkzeuge Æ ABAP Workbench Æ Entwicklung Æ ABAP Dictionary (Dictionary Objekt: Tabelle; eingeben und Operation wählen) Springen Æ Indizes oder wählen Sie Indizes... Technische Einstellungen Werkzeuge Æ ABAP Workbench Æ Entwicklung Æ ABAP Dictionary (Dictionary Objekt: Tabelle, eingeben und Operation wählen) Springen Æ Technische Einstellungen oder wählen Sie Technische Einstellungen (SE13) Datenbank-Utility Werkzeuge Æ ABAP Workbench Æ Entwicklung Æ Dictionary (Dictionary-Objekt, Objektname eingeben und Operation wählen) Hilfsmittel Æ Datenbank-Utility - Datenbank-Utility (SE14) Speicherparameter Werkzeuge Æ ABAP Workbench Æ Entwicklung Æ Dictionary (Dictionary-Objekt, Objektname eingeben und Operation wählen) Hilfsmittel Æ Datenbank-Utility Springen Æ Speicherparameter oder wählen Sie Speicherparameter - Datenbank-Utility (SE14) Æ Springen Æ Speicherparameter Festwerte Werkzeuge Æ ABAP Workbench Æ Entwicklung Æ Dictionary (Dictionary-Objekt:Domäne, Domänenname eingeben und Operation wählen) Registerkarte Wertebereich Pflegeview Werkzeuge Æ ABAP Workbench Æ Entwicklung Æ weitere Werkzeuge Æ Gen.Tab.-Pflegedialog - Gen.Tab.-Pflegedialog (SE54) Erweiterte Datenanzeige SystemÆ Hilfsmittel Æ Tabellenpflege Æ Erw. Tabellenpflege - Erweiterte Tabellenpflege (SM30)
© SAP AG
TAW12
10-11
Schlagwortverzeichnis Abhängige Objekte 5-5 Aktivieren 5-3 ALTER TABLE 6-4, 6-13 Analysetool 6-11 Anpassung fortsetzen 6-11 Append-Struktur 6-12, 6-13, 6-14, 7-12 Append-Suchhilfe 8-15 Aufsetzprotokoll 6-9 Clustertabelle 6-14 Datenart 2-8, 2-9 Kunden 2-9 Datenbank 1-4, 2-3, 3-4 Datenbankobjekte 1-3, 1-7 Datenbanksystem 3-4, 6-4, 7-11 Datenbanktabelle 1-3, 2-6 Datenbank-Schnittstelle 1-7, 3-5 Datenbank-View 1-3, 1-4, 7-11, 7-14 Datenelement 1-3, 1-5, 2-4 Dokumentation 1-6 Domäne 2-4, 4-3, 4-10 Gleichheit 4-9 Domänenkonzept Zweistufiges 2-5 Dynpro 1-3 Eingabehilfe 1-3, 1-6, 8-3, 8-4, 11-10 Eingabeprüfung 1-6 Entwicklungsumgebung 1-7 Extent 2-10 Feldhilfe 1-3, 1-6 Feldzuordnung 4-7 Festwerte 4-3 Fremdschlüssel 1-6, 4-6, 4-7, 4-8, 4-10, 7-9, 7-13 Fremdschlfeld Art der 4-11 Fremdschlüsselbeziehung 4-11 Fremdschlüsseltabelle 4-7, 4-8 Generierung Tabellensicht 7-13 Größenkategorie 2-8, 2-10 Pflege-View 11-6, 11-9 Include Strukturen 2-7, 5-5 © SAP AG
TAW12
10-12
in Datenbank-View 7-12 Index 1-4, 3-3, 3-4, 8-12 Indexeintrag 3-3 Indexkennung 3-4 Infosystem 5-7 Join 7-3 Inner Join 7-14 Outer Join 7-14 Joinbedingung 7-5, 7-9, 7-10, 7-13 Katalogänderung 6-4 Kardinalität 4-11 Komponente 1-5 Kreuzprodukt 7-4, 7-5 Kundenfelder 6-12 Kundenmodifikation 6-13, 8-15 Laufzeitobjekt 5-4, 6-3 Laufzeitumgebung 1-7 Matchcode 11-9 Objektprotokoll 6-11 Optimizer 3-4 Pooltabelle 6-14 Performance 1-6, 3-5, 3-8, 8-12 Pflegestatus 7-11 Pflege-View 7-13, 7-14 Primärindex 3-4 Primärschlüssel 2-3, 3-8, 4-8 Projektion 7-3, 7-6 Protokollierung 1-6, 2-8, 2-11 Prüffeld 4-7, 4-8, 4-9 Prüftabelle 4-4, 4-7, 4-8 Puffer 3-5, 3-6, 3-7, 3-8, 3-9 Pufferung 1-6, 2-8 vollständige 3-6, 3-7, 3-8, 3-9 generische 3-6, 3-8 von Einzelsätzen 3-6, 3-9 von Datenbank-Views 7-11 Pufferungsart 3-6, 3-8, 7-11 Puffersynchronisation 3-10, 3-11, 3-12, 3-13, 3-14, 3-15 Releasewechsel 6-13 rdisp/bufreftime 3-10 Semantische Eigenschaften 4-11 Schlüssel 3-7 generisches 3-8 © SAP AG
TAW12
10-13
Verkürzung eines 6-8 Schlüsselfeld 3-4, 4-8 generisches 3-8 Sekundärindex 3-4, 3-7 Selektion 7-3, 7-4 Selektionsbedingung 7-7, 7-9 SE54 7-13 SPDD 6-13 Speicherbereich 2-10 Sperrobjekt 1-6 Struktur 1-3, 1-5, 2-3 Strukturanpassung 6-4 Suchfeld 8-4, 8-9 Suchhilfe 1-6, 8-5, 11-7 Suchhilfeanbindung 8-9, 8-10, 8-11, 8-14 elementare 8-14 Sammelsuchhilfe 8-14, 8-15 Append-Suchhilfe 8-15 Dialogverhalten einer Suchhilfe 8-5, 8-7 Suchhilfeparameter 8-7, 8-8 Schnittstelle einer Suchhilfe 8-5, 8-8, 8-9, 8-10, 8-14 Selektionsmethode einer Suchhilfe 8-5, 8-6, 11-6 Suchhilfe-Exit 11-8 Synchronisationstabelle 3-10, 3-11, 3-12, 3-13, 3-14, 3-15 Synchronisationszeitpunkt 3-14, 3-15 Tabelle 1-3, 1-6, 2-3 transparente 2-6 Texttabelle 4-12 entsperren 6-11 Tabellenpuffer 3-5, 3-6 Tabellentyp 1-3, 1-5 Tabellenpflegegenerator 7-13 Tablespace 6-9, 6-10 Technische Einstellungen 2-8 Typen strukturierte 2-6 benutzerdefinierte 1-3, 1-5 Typdefinitionen 1-3, 1-5, 1-7 Umsetzung 6-4 abgebrochene 6-9, 6-10 Umsetzprozeß 6-5, 6-6, 6-7, 6-8, 6-9 Unique-Index 3-4 Upgrade 6-13 © SAP AG
TAW12
10-14
Verdrängung 3-5 Version aktive 5-3, 6-3, 6-5, 6-6, 6-7, 6-8, 6-9 inaktive 6-3, 6-3, 6-5, 6-6, 6-7 Verwendungsnachweis 5-6 View 1-4, 1-6, 7-3, 7-4, 7-5, 7-6, 7-7, 7-8, 7-9, 7-10, 7-11, 7-12, 7-13, 7-14, 11-6 Wertetabelle 4-4, 4-9, 4-10 $TAB 3-5
© SAP AG
TAW12
10-15
Komplex: Techniken der Listenerstellung
© SAP AG 1999
© SAP AG
TAW12
11-1
Inhaltsverzeichnis: Techniken der Listenerstellung
Kapitel
Einführung
Kapitel
Datenaufbereitung und Gruppenstufenverarbeitung
Kapitel
Datenausgabe auf Listen
Kapitel
Selektionsbild
Kapitel
Ablage von Listen und Hintergrundverarbeitung
Kapitel
Logische Datenbank
Kapitel
Grundlegende Techniken bei interaktiven Listen
Kapitel
Programmeigene Datenbeschafung
Kapitel
SAP Grid Control
Anhang
© SAP AG 2002
© SAP AG
TAW12
11-2
Einführung
z Grobziel des Kurses z Lernziele des Kurses z Inhaltsverzeichnis z Übersichtsdiagramm z Gesamtunternehmensszenario z Einführung des Kurses
© SAP AG 1999
© SAP AG
TAW12
12-1
Grobziel des Kurses
Dieser Kurs ermöglicht es Ihnen: z Listen mit Hilfsmitteln zu erzeugen. z Drucklisten zu erzeugen. z Einfache und interaktive Listen zu erzeugen.
© SAP AG 2002
© SAP AG
TAW12
12-2
Lernziele des Kurses
Dieser Kurs vermittelt Ihnen folgende Kenntnisse: z
Listen formatiert gestalten
z
Selektionsbild gestalten und Benutzereingaben auswerten
z
Daten aus der Datenbank lesen und logische Datenbanken einsetzen
z
Datenaufbereitung mit Hilfe von internen Tabellen und Extrakdatenbeständen durchführen
z
Einfache interaktive Listen erzeugen
z
SAP Grid Control nutzen
© SAP AG 2002
© SAP AG
TAW12
12-3
Übersichtsdiagramm
Verbindungen der Fluggesellschaft LH CAR Id
Abflug
Ankunft
AA AA LH LH
New York San Francisco Frankfurt Frankfurt
San Fancisco New York New York Berlin
Werkzeuge
0017 0064 0400 0402
1
einfache Listen
AZ AZ AZ DL DL LH LH LH LH
ROME TOKYO
TOKYO ROME
AZ 0789 29.12.01 09.12.01
2.667.445 ITL 2.667.445 ITL
Interaktive Listen
SAP Grid Control
© SAP AG 2002
© SAP AG
TAW12
12-4
Business-Szenario
z Sie sind Angestellte(r) eines Reiseveranstalters. z Der Reiseveranstalter möchte sein Angebot erweitern. z Das Unternehmen benötigt eine Liste der häufigsten Flüge, um eine Zunahme der Buchungen einzukalkulieren. z Sie müssen ein Programm schreiben, das die angeforderten Flugdaten in einer Liste anzeigt.
© SAP AG 2002
© SAP AG
TAW12
12-5
Demos, Kopiervorlagen und Lösungen
z
Entwicklungsklasse BC405 mit folgender Namenskonvention:
Demos
SAPBC405_xxxD_...
Kopiervorlage
SAPBC405_xxxT_...
Lösungen
SAPBC405_xxxS_...
xxx
Kürzel der einzelnen Kapitel
© SAP AG 2002
Kürzel einzelner Kapitel: •FOL Kapitel 2: Datenausgabe auf Listen •SSC Kapitel 3: Selektionsbild •LDB Kapitel 4: Logische Datenbank •GDA Kapitel 5: Datenbeschaffung programmieren •DAP Kapitel 6: Datenaufbereitung und Gruppenstufenverarbeitung •STL Kapitel 7: Ablage von Listen und Hintergrundverarbeitung •ILB Kapitel 8: Grundlegende Techniken bei interaktiven Listen •ALV Kapitel 9: ALV Grid Control
© SAP AG
TAW12
12-6
Übungsaufgaben und Kapiteleinteilung
z Ohne LDB (mit Kopiervorlage)
z With LDB (F1S)
Datenausgabe auf Listen
Logische Datenbank
Selektionsbild
Datenaufbereitung und Gruppen-
programmeigene Datenbeschaffung
stufenverarbeitung mit
Datenaufbereitung und Gruppen-
Extraktdatenbeständen Ablage von Listen und
stufenverarbeitung mit internen Tabellen
Hintergrundverarbeitung
Grundlegende Techniken bei
interaktiven Listen
© SAP AG 2002
Viele der Kapitel enthalten Übungen. Für jede Übung existiert eine Musterlösung, auf der jederzeit für die Folgeübung aufgesetzt werden kann.
© SAP AG
TAW12
12-7
Datenausgabe auf Listen
Inhalt z einfache Listen z Listenformate z Seitengestaltung z Ausgabegestaltung z Werkzeuge
© SAP AG 2002
© SAP AG
TAW12
13-1
Datenausgabe auf Listen: Lernziele des Kapitels
Am Ende dieses Kapitels können Sie: z eine einfache Liste aufbauen z Ihre eigene Liste entwerfen:
Gestaltung des Listenformats
Layout der Seite
Entwurf der Ausgabe
© SAP AG 2002
© SAP AG
TAW12
13-2
Erzeugen einer Liste
REPORT
sapbc405_fold_list_creation .
DATA: wa_spfli LIKE spfli. START-OF-SELECTION. SELECT carrid connid cityfrom cityto FROM spfli INTO (wa_spfli-carrid, ….. DEMO: Erzeugung einer Liste 1 WRITE: / wa_spfli-carrid, wa_spfli-connid, wa_spfli-cityfrom, wa_spfli-cityto. AA 0017 NEW YORK SAN FRANCISCO AA 0064 SAN FRANCISCO NEW YORK ENDSELECT. AZ 0555 ROM FRANKFURT IF sy-subrc 0. … ENDIF. AZ 0788 ROM TOKYO : :
© SAP AG 2002
Die erste WRITE-Anweisung in einem ABAP-Programm löst die Erzeugung einer Liste aus. Die Ausgabe wird in einen Listenpuffer geleitet und, sobald der Puffer vollständig aufgebaut ist, erzeugt das System das Bild aus dem Listenpuffer. Das System erzeugt standardmäßig zwei Kopfzeilen (Standardüberschrift). In der ersten Kopfzeile erscheint links oben der Programmtitel aus dem Programmattributen und rechts oben die Seitennummer. Die zweite Kopfzeile besteht aus einer durchgezogenen Linie. Diese beiden Zeilen bleiben auch beim Blättern der Liste im Fenster stehen. Beim Ausdrucken von Listen sieht die erste Zeile der Überschrift folgendermaßen aus: links oben: Systemdatum in der Mitte: Listenüberschrift rechts oben: Seitennummer Mit Transaktion LIBS zeigen Sie die Formatvorschläge für Listen im SAP-System an. Wenn Sie das Aussehen Ihrer Listen so weit wie möglich an SAP-Listen anpassen, haben Ihre Benutzer eine konsistente Oberfläche sowohl bei Ihren eigenen Listen als auch bei SAP-Listen.
© SAP AG
TAW12
13-3
Festlegen des Listenformats
REPORT LINE-SIZE LINE-COUNT .
.LINELINE-SIZE 50 LINELINE-COUNT 12. 12
REPORT sapbc405_fold_list_layout ... WRITE: ...
50 DEMO: Listenformatgestaltung
AT LINE-SELECTION. CHECK NOT…. NEW-PAGE LINE-SIZE 122
:
:
12
:
DEMO: Listenformatgestaltung LINE-COUNT 65(3). WRITE …...
1
2
:
© SAP AG 2002
Die Standardbreite einer Reportzeile beträgt 83 Spalten. Die Standardseitenlänge beträgt 60.000 Zeilen. Um diese Vorschlagswerte zu überschreiben verwenden Sie die ZusätzeLINE-SIZE und LINE-COUNT Datenbankzugriffe, Datenbankzugriffe, EingabeEingabe- und Berechtigungsprüfungen Berechtigungsprüfungen
sapdb
FORM FORM init. ... ENDFORM init. ENDFORM
FORM FORM put_spfli. ... ENDFORM put_spfli. ENDFORM
FORM FORM put_sflight. ... ENDFORM put_sflight. ENDFORM © SAP AG 2002
Die logischen Datenbakprogramme heißen SAPLDB für logische Datenbank . Die Programme bestehen aus einer Sammlung von Unterprogrammen, von denen jedes bei einem bestimmten Ereignis ausgeführt wird. Beispielsweise wird das Unterprogramm einmal zu Beginn des Datenbankprogrammes prozessiert. In diesem Programm können Vorschlagswerte für das Selektionsbild der LDB festgelegt werden. Es existieren weitere Unterprogramme, die zu den Zeitpunkten PBO (Process Before Output) und PAI (Process After Input) des Selektionsbildes prozessiert werden. Zum Zeitpunkt PAI finden typischerweise Prüfungen statt, wie z.B. Berechtigungsprüfungen (AUTHORITY-CHECK). In den Unterprogrammen put_ sind die Datenbankzugriffe (SELECT-Anweisungen) programmiert. Diese Unterprogramme werden u.U mehrfach prozessiert, je nachdem, welche Selektionskriterien der Anwender angegeben hat. Die Reihenfolge, in der die Unterprogramme prozessiert werden, hängt von der Struktur der logischen Datenbank ab..
© SAP AG
TAW12
15-14
Wechselwirkung: LDB und Programm
Struktur Struktur der der F1S F1S
PROGRAM SAPDBF1S DEFINING DATABASE F1S. ... FORM PUT_SPFLI. SELECT * FROM SPFLI ... PUT PUT SPFLI. SPFLI. ENDSELECT. ENDFORM.
SPFLI
SFLIGHT
SBOOK
FORM PUT_SFLIGHT. SELECT * FROM SFLIGHT . PUT PUT SFLIGHT. SFLIGHT. SFLIGHT. ENDSELECT. ENDFORM. FORM PUT_SBOOK. SELECT * FROM SBOOK ... PUT SBOOK. SBOOK. PUT . SBOOK ENDSELECT. ENDFORM.
REPORT sapbc405_ldbd_ldb. NODES: spfli, sflight, sbook.
* Processing of SPFLI records GET SPFLI FIELDS ... Datenverarbeitung Datenverarbeitung * Processing of SFLIGHT records GET SFLIGHT FIELDS ... Datenverarbeitung Datenverarbeitung
* Processing of SBOOK records GET SBOOK FIELDS ... Datenverarbeitung Datenverarbeitung
© SAP AG 2002
Wird ein Programm gestartet, das eine logische Datenbank verwendet, so geht zunächst die Kontrolle an das Datenbankprogramm der logischen Datenbank. Zu jedem Ereignis finden Sie entsprechende Unterprogramme in dem Datenbankprogramm (zum Ereignis INITIALIZATION gibt es z.B. das passende Unterprogramm init). Das Zusammenspiel zwischen der LDB und dem angebundenen Report funktioniert nun so, daß immer zuerst das Unterprogramm prozessiert wird und dann das Ereignis (falls im Report vorhanden). Das Datenbankprogramm einer logischen Datenbank liest gemäß der Struktur die Daten von der Datenbank: beginnend beim Wurzelknoten werden die einzelnen Äste nacheinander von oben nach unten abgearbeitet. Die logische Datenbank liest die Daten in den Unterprogrammen put_. Bei dem PUT Ereignis wechselt die Kontrolle von dem Datenbankprogramm zu dem GET Ereignis des angebunden Reports. Die Daten werden im Report in den entsprechenden Arbeitsbereichen zur Verfügung gestellt. Der zum GET Ereignis definierte Verarbeitungsblock wird ausgeführt. Dann geht die Kontrolle zurück an die logische Datenbank. PUT stößt das gemäß der Struktur folgende Unterprogramm an. Dieser Ablauf findet so lange statt, bis dem Report alle Daten zur Verfügung gestellt wurden. Die Lesetiefe in der Struktur hängt von den angegebenen GET Ereignissen im Programm ab. Die logische Datenbank liest bis zu dem der Struktur entsprechenden tiefsten GET Ereignis. Im Programm werden nur die GET Ereignisse angegeben, zu denen auch eine Verarbeitung stattfinden soll. Die logische Datenbank liest alle Datensätze, die auf dem direkten Zugriffsweg liegen.
© SAP AG
TAW12
15-15
Prüfen einer programmeigenen Selektion
Selektionen der LDB
Tabelle für dynamische Selektionen (freie Abgrenzungen) vorgesehen?
Abflugzeit
08:00:00
23:00:00
SPFLI
JA
Flugpreis
500,00
1000,00
SFLIGHT
NEIN
REPORT
sapbc405_ldbd_check_sel.
NODES: spfli, sflight, sbook. SELECT-OPTIONS: SELECTSELECT-OPTIONS: OPTIONS: sdepart FOR spfli-deptime DEFAULT '08000' TO '230000', sprice FOR sflight-price DEFAULT '500' TO '1000'. GET spfli FIELDS ... GET sflight FIELDS fldate price currency. * check of selection criteria sprice CHECK sprice. sprice. CHECK . sprice ... GET sbook FIELDS ...
CHECK .
SFLIGHT
SBOOK
© SAP AG 2002
SFLIGHT
SBOOK
CHECK negativ CHECK positiv
Falls Sie in Ihrem Programm in den Attributen eine logische Datenbank angegeben haben und zusätzliche Selektionen deklarieren, die sich auf Felder eines Knoten beziehen, der von der logischen Datenbank nicht für dynamische Selektionen vorgesehen ist, muß im Programm über die Anweisung CHECK geprüft werden, ob der aktuelle Datensatz den Selektionskriterien genügt. Ist das Ergebnis der Prüfung negativ, so wird die Bearbeitung des aktuellen Verarbeitungsblocks beendet.
© SAP AG
TAW12
15-16
Logische Datenbank: Zusammenfassung
Sie können nun: z
die Vorteile logischer Datenbanken verstehen
z
logische Datenbanken einsetzen
z
programmspezifische Merkmale in einer logischen Datenbank identifizieren
z
Daten mit Hilfe einer logischen Datenbank lesen
© SAP AG 2002
© SAP AG
TAW12
15-17
Logische Datenbank Übungen Kapitel: Logische Datenbanken Thema: GET-Ereignisse
Am Ende dieser Übungen können Sie: • eine Liste erzeugen, deren Daten mittels logischer Daten gelesen werden
1-1
Legen Sie das Programm Z##LDB1_... mit TOP-Include (Z##LDB1_...TOP) an und tragen Sie in den Programmeigenschaften die logische Datenbank F1S ein. Achten Sie darauf, daß als Programmtyp Ausführbares Programm eingetragen ist. Dazu müssen Sie den Programmtyp ändern. Musterlösung zur Aufgabe: SAPBC405_LDBS_1. 1-1-1 Die logische Datenbank soll für die Knoten SPFLI, SFLIGHT und SBOOK die Daten dem Programm zur Verfügung stellen. 1-1-2 Erzeugen Sie eine Liste, die folgenden Daten anzeigt: Tabelle SPFLI: CARRID, CONNID, CITYFROM, AIRPFROM, CITYTO, AIRPTO. Tabelle SFLIGHT: FLDATE, PRICE, CURRENCY, PLANETYPE, SEATSMAX, SEATSOCC,FREE_SEATS. Tabelle SBOOK: BOOKID, CUSTOMID, SMOKER, LUGGWEIGHT, WUNIT. Das Feld FREE_SEATS ist kein Tabellenfeld, sondern muß im Programm berechnet werden. Der Price und das Gepäckgewicht sollen gemäß der passenden Einheit ausgegeben werden. 1-1-3 Erzeugen Sie eine dreizeilige Liste, bei der in jeder Zeile die Informationen eines Knoten ausgeben werden (s.o.). 1-1-4 Die Liste soll 83 Spalten besitzen. Pflegen Sie die Spaltenüberschriften (Standardlistenüberschrift). 1-1-5 Formatierung der Liste (optional) Die erste Zeile soll in der Farbe COL_HEADING, nicht intensiv, die zweite Zeile in COL_NORMAL, intensiv und die dritte Zeile in COL_NORMAL, nicht intensiv ausgeben werden. Rahmen Sie die Liste.
Hinweis Nutzen Sie zur Ausgabe der Felder die Musterfunktionalität im ABAP Editor.
© SAP AG
TAW12
15-18
Übungen Kapitel: Logische Datenbanken Thema: GET LATE Ereignisse und Prüfungen von programmeigenen Selektionen Am Ende dieser Übungen können Sie: • eine Liste erzeugen, deren Daten mittels logischer Daten gelesen werden • Programmeigene Selektionen auf ihre Gültigkeit überprüfen
2-1
Erweitern Sie das Programm Z##LDB1_... oder kopieren Sie die Musterlösung SAPBC405_LDBS_1 auf das Programm Z##LDB2_... . Musterlösung zur Aufgabe: SAPBC405_LDBS_2. 2-1-1 Erweitern Sie das Selektionsbild um eine weitere SELECT-OPTIONS für das Buchungsdatum (SBOOK-ORDER_DATE). Rahmen Sie die Selektion und pflegen Sie den Selektionstext. 2-1-2 Stellen Sie sicher, daß nur die Buchungen auf der Liste ausgegeben werden, die den angegebenen Selektionskriterien entsprechen. Geben Sie das Buchungsdatum mit auf der Liste aus. 2-1-3 Pflegen Sie die Spaltenüberschrift (Standarlistenüberschrift). Auf der Liste soll eine durchgezogenen Linie ausgegeben werden, wenn alle Buchungen zu einem Termin ausgegeben wurden und wenn eine Flugverbindung komplett ausgegeben wurde. Jede neue Flugverbindung soll auf einer neuen Seite erscheinen.
2-2
Optional Musterlösung zur Aufgabe: SAPBC405_LDBS_2_OPT.
2-3
Erweitern Sie ihr Programm. 2-3-1 Erweitern Sie das Selektionsbild um eine Auswahlknopfgruppe mit zwei Auswahlknöpfen. Rahmen Sie diese Gruppe und pflegen Sie die Selektionstexte. Die Gruppe muss folgende Funktionalität abbilden: Der Benutzer kann nur in der Liste zwischen Charterflügen und Linienflügen wählen. Ob es sich um einen Charter- oder Linienflug handelt, wird im Feld SPFLI –FLTYPE festgelegt: Charterflug: SPFLI-FLTYPE = 'X'. 2-3-2 Stellen Sie sicher, daß nur die Termine und Buchungen auf der Liste ausgegeben werden, die den angegebenen Selektionskriterien entsprechen.
© SAP AG
TAW12
15-19
Logische Datenbank Lösungen Kapitel: Logische Datenbanken Thema: GET-Ereignisse
*&---------------------------------------------------------------------* *& Report
SAPBC405_LDBS_1
*
*& * *&---------------------------------------------------------------------* *&
*
*&
*
*&---------------------------------------------------------------------*
INCLUDE bc405_ldbs_1top.
*&---------------------------------------------------------------------* *&
Event GET SPFLI
*&---------------------------------------------------------------------* GET spfli. * Data output SPFLI FORMAT COLOR COL_HEADING WRITE:
INTENSIFIED OFF.
/ sy-vline, spfli-carrid, spfli-connid, spfli-cityfrom, spfli-airpfrom, spfli-cityto, spfli-airpto, AT line_size sy-vline.
*&---------------------------------------------------------------------* *&
Event GET SFLIGHT
*&---------------------------------------------------------------------* GET sflight. * Calculate free seats free_value = sflight-seatsmax - sflight-seatsocc.
* Data output SFLIGHT FORMAT COLOR COL_NORMAL
INTENSIFIED ON.
WRITE: / sy-vline, sflight-fldate, sflight-price CURRENCY sflight-currency, © SAP AG
TAW12
15-20
sflight-currency, sflight-planetype, sflight-seatsmax, sflight-seatsocc, free_seats, AT line_size sy-vline.
*&---------------------------------------------------------------------* *&
Event GET SBOOK
*&---------------------------------------------------------------------* GET sbook. FORMAT COLOR COL_NORMAL INTENSIFIED OFF. WRITE: / sy-vline, sbook-bookid, sbook-customid, sbook-smoker, sbook-luggweight UNIT sbook-wunit, sbook-wunit, AT line_size sy-vline.
*&---------------------------------------------------------------------* *& Include BC405_LDBS_1TOP
*
*& * *&---------------------------------------------------------------------*
REPORT
sapbc405_ldbs_1 LINE-SIZE 83.
* Used nodes of the structure of the logical database F1S NODES: spfli, sflight, sbook.
* Variables DATA: free_seats LIKE sflight-seatsocc.
* Constants CONSTANTS: line_size LIKE sy-linsz VALUE 83.
© SAP AG
TAW12
15-21
SAP Query - Listenerstellung Lösungen Kapitel: Logische Datenbanken Thema: GET LATE Ereignisse und Prüfungen von programmeigenen Selektionen
*&---------------------------------------------------------------------* *& Report
SAPBC405_LDBS_2
*
*& * *&---------------------------------------------------------------------* *&
*
*&
*
*&---------------------------------------------------------------------*
INCLUDE bc405_ldbs_2top.
*&---------------------------------------------------------------------* *&
Event GET SPFLI
*&---------------------------------------------------------------------* GET spfli. * Data output SPFLI FORMAT COLOR COL_HEADING WRITE:
INTENSIFIED OFF.
/ sy-vline, spfli-carrid, spfli-connid, spfli-cityfrom, spfli-airpfrom, spfli-cityto, spfli-airpto, AT line_size sy-vline.
*&---------------------------------------------------------------------* *&
Event GET SFLIGHT
*&---------------------------------------------------------------------* GET sflight. * Calculate free seats free_value = sflight-seatsmax - sflight-seatsocc.
* Data output SFLIGHT FORMAT COLOR COL_NORMAL © SAP AG
INTENSIFIED ON. TAW12
15-22
WRITE: / sy-vline, sflight-fldate, sflight-price CURRENCY sflight-currency, sflight-currency, sflight-planetype, sflight-seatsmax, sflight-seatsocc, free_seats, AT line_size sy-vline.
*&---------------------------------------------------------------------* *&
Event GET SBOOK
*&---------------------------------------------------------------------* GET sbook.
* Check select-option CHECK so_odat.
FORMAT COLOR COL_NORMAL INTENSIFIED OFF. WRITE: / sy-vline, sbook-bookid, sbook-customid, sbook-smoker, sbook-luggweight UNIT sbook-wunit, sbook-wunit, sbook-order_date, AT line_size sy-vline.
*&---------------------------------------------------------------------* *&
Event GET SPFLI LATE
*&---------------------------------------------------------------------* GET spfli LATE. ULINE. NEW-PAGE.
*&---------------------------------------------------------------------* *&
Event GET SFLIGHT LATE
*&---------------------------------------------------------------------* GET sflight LATE. ULINE.
*&---------------------------------------------------------------------* *& Include BC405_LDBS_2TOP
*
*& * © SAP AG
TAW12
15-23
*&---------------------------------------------------------------------*
REPORT
sapbc405_ldbs_2 LINE-SIZE 83.
* Used nodes of the structure of the logical database F1S NODES: spfli, sflight, sbook.
* Additional selections SELECTION-SCREEN BEGIN OF BLOCK order WITH FRAME. SELECT-OPTIONS: so_odat FOR sbook-order_date. SELECTION-SCREEN END OF BLOCK order.
* Variables DATA: free_seats LIKE sflight-seatsocc.
* Constants CONSTANTS: line_size LIKE sy-linsz VALUE 83.
Ablage von Listen Optional Übungen *&---------------------------------------------------------------------* *& Report
SAPBC405_LDBS_2_OPT
*
*& * *&---------------------------------------------------------------------* *&
*
*&
*
*&---------------------------------------------------------------------*
INCLUDE BC405_LDBS_2_OPTTOP.
*&---------------------------------------------------------------------* *&
Event GET SPFLI
*&---------------------------------------------------------------------* GET spfli.
*++++++++++++++++++++++++++++++++> optional * Check radio button group using a help variable * Flight type charter or scheduled)
© SAP AG
TAW12
15-24
CLEAR check_negative. IF pa_fty1 = 'X'. IF NOT spfli-fltype = pa_fty1. check_negative = 'X'. ENDIF. ELSEIF pa_fty2 = 'X'. IF NOT spfli-fltype = space. check_negative = 'X'. ENDIF. ENDIF.
CHECK check_negative = space.
*
p1
text
*
p1
text
*
p1
text
*
p1
text
*
View more...
Comments