Skript Lektion 11

vhb-Kurs „SAP-Programmierung mit ABAP Objects“
Block B * Kapitel 6 * Lektion 11
In Lektion 11 lernen Sie die grundlegenden Kenntnisse über relationale Datenbanken kennen, die
notwendig sind, um mit ABAP erfolgreich Datenbankauswertungen zu programmieren. Der
Zusammenhang zwischen Daten, Datenbanktabellen, Datenbank und Dictionary wird erläutert. Sie lernen,
wie Sie mit in ABAP eingebetteten SQL-Befehlen auf Datenbankinhalte zugreifen können.
Über die Kombination von speziellen Eingabefeldern, den SELECT-OPTIONS, mit dem IN-Operator für einen
Mengenzugriff auf Daten, ist es möglich, mit minimalem Programmieraufwand eine flexible
Datenfilterung für den Programmnutzer anbieten zu können.
Hinweis: zugehörige weitere Quellen sind Screencast-Dateien (Videos), die inhaltlich relevant sind.
Lektion L11: Relationale Datenbanktabellen, SAP-Tabellen, Dictionary +
Datenmodelle, Datenbank-Zugriff über SQL-Befehle, Filtern mit SELECT-OPTIONS,
IN-Operator
Die Lektion L11 ist wie folgt gegliedert:
1. Relationale Datenbanktabellen
2. SAP-Tabellen, Dictionary + Datenmodelle
3. Datenbank-Zugriff über SQL-Befehle
4. Filtern mit SELECT-OPTIONS, IN-Operator
Übersicht über die Screencasts der Lektion L11
Die folgenden Screencasts ergänzen die in diesem Skript ausformulierten Texte.
Screencast
L11-01
L11-02
L11-03
L11-04
L11-05
Inhalt
Flugdatenmodell: ERM-Modell im Dictionary, Fremdschlüssel, Wertetabellen
SELECT-1: einfacher Select (Debugger)
SELECT-2: Select single (Debugger)
SELECT-3: mit WHERE (Debugger)
Filtern mit SELECT-OPTIONS und IN-Operator: mit Animation
Tabellen dienen im SAP-System nicht nur zur Datenspeicherung, sondern auch zur Steuerung, d.h. zur
Ausführung von Befehlen. Zentrale Steuerelemente des Systems sind über Tabellen realisiert. Selbst die
Programmiersprache ABAP Objects wird intern in einen Zwischencode umgewandelt, der wiederum
durch die Interpretation von Tabelleneinträgen entsteht. Wir gehen hier auf diese systeminternen
Zusammenhänge nicht näher ein, sondern beschränken uns bei den Erläuterungen auf das Konzept der
relationalen Datenbanken und Tabellen so, wie es für das Systemverständnis eines ABAP-Programmierers
notwendig ist.
Hinweis
Die folgenden Darstellungen ersetzen keine Vorlesung über Datenbanken und dienen nur zur
Vorbereitung für das Reporting und die datenbankorientierte SAP-Programmierung.
L11.1:
Relationale Datenbanktabellen
In diesem Abschnitt wird das Konzept der relationalen Datenbanktabellen erläutert. Das Schlüsselprinzip
sowie das Konzept der Fremdschlüsselprüfung wird beschrieben und Sie erfahren außerdem, wie Sie sich
mit Hilfe von Systemfunktionen Tabelleninhalte anzeigen lassen bzw. diese verändern können.
Relationale Datenbanken und Tabellen
Beim relationalen Datenbankmodell (Relationenmodell) werden Objekttypen und Beziehungen sowie
deren Attribute mittels Relationen abgebildet, die anschaulich durch Tabellen dargestellt werden können.
Lektion 11: Seite 1 von 18
vhb-Kurs „SAP-Programmierung mit ABAP Objects“
Block B * Kapitel 6 * Lektion 11
Beim Relationenmodell werden Daten entsprechend ihrer Beziehungen untereinander gespeichert. Die
Suche erfolgt über Schlüssel. Andere Datenmodelle sind z.B. das hierarchische Modell oder das
Netzwerkmodell.
Eine Datenbank ist eine Form der Datenspeicherung und enthält eine Menge von Informationen aus
einem abgegrenzten Informationsbereich. Die Daten werden hier mit Verweisen auf ihre Abhängigkeit
untereinander geprüft.
Eine Tabelle ist eine Anordnung von Daten in Tabellenform. Eine Tabelle besteht aus Spalten (Menge von
Datenwerten desselben Typs) und Zeilen (Datensätzen). Jede Tabellenzeile kann durch ein oder mehrere
Felder eindeutig identifiziert werden.
Beispiel: Bankkonto
Als erstes Beispiel betrachten wir die Daten eines Bankkontos und überlegen uns, wie wir die Datensätze
von allen Kontoinhabern abspeichern können. Abb. L11-01 zeigt den ersten Entwurf. Es handelt sich
hierbei um die so genannte 1. Normalform einer Tabelle.
Abb. L11-01: Bankkonten: Kundendaten in Tabellenform, erster Entwurf
Diese Tabelle enthält neben sogenannten Stammdaten auch aktuelle Daten wie den Kontostand. Die
Information, die man typischerweise bei einem Kontoauszug erhält, könnte wie in Abb. L11-02 dargestellt
werden. Diese Informationen werden oft als Bewegungsdaten bezeichnet: sie werden durch
Transaktionen (Abbuchungen, Gutschriften aufgrund von durchgeführten Geschäftsprozessen)
verursacht.
Abb. L11-02: Bankkonten: Bewegungsdaten in Tabellenform, erster Entwurf
Schlüsselprinzip
Datenelemente sind Datenfelder. Ein Datensatz besteht aus unterschiedlichen Datenelementen, die in
einem Datensatz zusammengefasst sind und als Ganzes angesprochen werden können.
Die Datenelemente in einem Datensatz können in Key-Felder (Schlüsselfelder, Argumentteil) und in NichtKey-Felder (Informationsfelder, Funktionsteil) eingeteilt werden:
Key-Felder
Funktionsfelder
Ein Schlüssel (Datenschlüssel, Key) ist eine Kombination von Datenelementen, mit der ein Datensatz
eindeutig identifiziert werden kann. Für relationale Datenbanktabellen gilt das Schlüsselprinzip:
Ein Datensatz ist eindeutig durch einen Schlüssel identifizierbar.
Beispiel
Das Autokennzeichen ist ein Schlüssel zur Identifizierung eines Datensatzes in der Datei “KFZ-Halter”. Die
Datenelemente Name und Vorname reichen in der Regel zur Identifizierung nicht aus, da es verschiedene
Personen mit übereinstimmenden Namen geben kann bzw. eine Person mehrere Autos besitzen kann.
Lektion 11: Seite 2 von 18
vhb-Kurs „SAP-Programmierung mit ABAP Objects“
Block B * Kapitel 6 * Lektion 11
3. Normalform
Zurück zum Beispiel „Bankkonto“: Wir überlegen uns jetzt, wie die erste Speicherversion (siehe Abb. L1101 und L11-02) verbessert werden kann. Es ist hier nicht sinnvoll, die Kontostände als kurzlebige Daten
zusammen mit allen langlebigen Daten (Adressdaten) in derselben Datei zu speichern. Hier wird man
einen Primärschlüssel suchen (z.B. Kontonummer und Bankleitzahl) und die Daten wie in Abb. L11-03 in
getrennten Tabellen speichern.
Um Daten so abzuspeichern, dass sie nicht unnötig mehrfach vorhanden sind, werden die Daten auf
mehrere Tabellen verteilt so, dass eine Information nur einmal in einem eigenen Datensatz gespeichert
wird und bei Verwendung in anderen Zusammenhängen darauf Bezug genommen wird. Dieses
„Bezugnehmen“, quasi ein Link, wird dadurch erreicht, dass zwischen Tabellen Relationen (Beziehungen)
definiert werden. Konkret sind dies Fremdschlüsselbeziehungen und Wertetabellen. Als Grundlage für
diese Konstrukte ist ein Datenmodell erforderlich, dass der sogenannten 3. Normalform genügt,
kurzgesagt: ein Modell mit redundanzfreier Datenhaltung. Für unser obiges Beispiel (Bankdaten) sehen
Sie in Abb. L11-03 einen ersten Entwurf. Die rot bzw. violett markierten Spalten sind Key-Felder, wobei
ein violettes Key-Feld andeutet, dass es über Fremdschlüssel auf eine Prüftabelle verweist (durch Pfeil
visualisiert). Blau markierte Spalten sind Informationsfelder, deren Inhalt aus einer Wertetabelle stammt,
wobei der Bezug durch ein Key-Feld hergestellt wird. In diesem Fall kommt der Kontoinhaber in der
Belegtabelle aus der Kundentabelle, der Bezug zum Eintrag in der Kundentabelle wird über die Kunden-ID
in der Belegtabelle hergestellt.
Abb. L11-03: Redundanzfreie Datenspeicherung: Bankdaten in der 3. Normalform
Aus fachlicher Sicht kann man Bankdaten (Name der Bank, Anschrift, ID), Kundendaten (Name, Anschrift,
Kunden-Nr.), Bankkunden (Konto-Nr., Kunden-ID, Bank-ID) und Kontobelege (Datum, Text, Betrag, und als
Belegkopf-Info: Bank-ID, Konto-Nr., Kontoinhaber) unterscheiden. Diese Betrachtungen sind bewusst
einfach gehalten, die Realität sieht noch etwas komplexer aus.
Damit z.B. die Kundendaten nicht unnötig oft gespeichert werden müssen, arbeitet man mit einer
eigenen Kundentabelle, in der jeder Kunde eindeutig über eine Kundennummer (Kunden-ID) identifiziert
werden kann.
Lektion 11: Seite 3 von 18
vhb-Kurs „SAP-Programmierung mit ABAP Objects“
Block B * Kapitel 6 * Lektion 11
Jede Bank wird über einen eindeutigen Schlüssel (innerhalb eines Landes die Bankleitzahl BLZ,
international: BIC) identifiziert und durch Bankbezeichnung und Anschrift ergänzt.
Jedes Konto wird über eine Kontonummer (bzw. IBAN), zusammen mit Bank-ID und Kunden-ID, eindeutig
festgelegt.
Jeder Kunde kann jetzt mehrere Konten bei verschiedenen Banken sowie bei der derselben Bank haben
und trotzdem sind sowohl Kundenanschrift als auch Bankanschrift nur jeweils einmal gespeichert.
Greift man sich jetzt ein Konto eines Kunden bei einer Bank heraus, müssen dazu Kontobewegungen,
verursacht durch Zahlungseingänge und -ausgänge, verbucht werden, d.h. diese Bewegungsdaten werden
als Datensätze in einer Belegtabelle (Kontoauszugsbeleg) gespeichert. Würden jetzt für jede
Kontobewegung alle zugehörigen Daten wie z.B. Adresse des Kunden, gespeichert, wäre dies nicht nur
eine Speicherplatzverschwendung, sondern bei Änderungen der Adressdaten müsste dies bei jedem
Belegsatz erfolgen. Bei redundanzfreier Datenhaltung muss eine Adressänderung nur an einer Stelle
geschehen und ist trotzdem für alle relevanten Datensätze verfügbar.
Damit kommen wir zu dem Datenmodell, dass in Abb. L11-03 abgebildet ist: Bankdaten, Kundendaten,
Konten (Bankkunden: welcher Kunde hat bei welcher Bank welche Konten?) und Bewegungsdaten
(welche Aktion wird wann für welches Konto durchgeführt?) werden erfasst. Dafür verwendet man hier 4
verschiedene Tabellen. Die Beziehungen (Relationen) zwischen diesen Tabellen, die notwendig sind,
damit man die fachlich geforderten Zusammenhänge gewährleisten kann, werden durch
Fremdschlüsselbeziehungen und Wertetabellen-Logik erreicht und sind hier durch einfache Pfeile
visualisiert.
Verbesserung des Datenmodells: Belegstruktur
In der Belegtabelle wird Bank-ID, Konto-Nr. und Kontoinhaber mehrfach angezeigt, was dem oben
erläuterten Prinzip der 3. Normalform widerspricht. Hierzu ist noch eine weitere Umformung notwendig,
die wir aus Gründen der Übersichtlichkeit getrennt in Abb. L11-04 darstellen:
Ein typischer Belegaufbau besteht aus Kopfinformationen (1 Datensatz) und mehreren Positionen (n
Datensätze). In unserem Beispiel bedeutet dies, dass ein Kontoauszug als betriebswirtschaftliches Objekt
gemäß einer 1:n-Relation (Beziehung) mit einer Belegkopf/Belegposition-Logik so abgebildet wird, dass
pro Beleg 1 Datensatz in einer Kopftabelle und n Datensätze in einer Positionstabelle gespeichert werden.
Damit man die Positionen dem richtigen Kopf zuordnen kann, ist es notwendig, dass in der Kopf- und
Positionstabelle je eine eindeutige Beleg-ID verwendet wird. Dies ist in Abb. L11-04 zu sehen.
Abb. L11-04: Belegkopf / - Positionslogik
Lektion 11: Seite 4 von 18
vhb-Kurs „SAP-Programmierung mit ABAP Objects“
Block B * Kapitel 6 * Lektion 11
Konsistenzprüfung
Falls versucht wird, im Kopf bei Kunden-ID 4720 und bei Konto-Nr. 2000 einzugeben, wird geprüft, ob für
diesen Kunden diese Konto-Nr. bereits in der Prüftabelle Bankkunden eingetragen ist. Falls nicht, gibt es
eine Fehlermeldung. Dadurch wird verhindert, dass auf Daten mit Schlüsselfunktion verwiesen wird, die
es noch nicht gibt.
L11.2:
SAP-Tabellen, Dictionary + Datenmodelle (
Screencast L11-1)
Die für diesen Kurs relevanten SAP-Tabellen sind relationale Datenbanktabellen, bei denen man sich
Gedanken über Fremdschlüssel, Prüf- und Wertetabellen machen muss. Im vorher erläuterten Beispiel
(Bankkonto) haben Sie einen ersten Einstieg in die Überlegungen erhalten, die notwendig sind, um ein
konsistentes Datenmodell erzeugen zu können. In diesem Kurs liegt der Fokus nicht auf dem Entwurf von
Datenmodellen, sondern auf der korrekten Interpretation der Datenmodelle, die hinter den realen
relationalen Datenbanktabellen liegen. Mit anderen Worten: Sie müssen nur lernen, diese Information
aus dem System herauszulesen und müssen diese nicht schreiben. Anhand des folgenden durchgängigen
Beispiels zeigen wir Ihnen, wo und wie Sie die notwendigen Informationen im System finden und wie Sie
diese für das Reporting einsetzen können.
SAP-Flugdatenmodell
Abb. L11-05 zeigt Ihnen das in diesem Kurs verwendete Flugdatenmodell in verkürzter Version, d.h. mit
der Beschränkung auf die wichtigsten 5 Tabellen des Modells. Die Datenbanktabellen des SAPFlugdatenmodells sind Bestandteil jedes SAP-Systems. In jedem SAP-Standard-System finden Sie dazu
geeignete Datensätze bzw. können diese mit einem ebenfalls zum Standard gehörenden ABAP-Programm
generieren. Kurzgefasst kann man den Aufbau des Flugdatenmodells wie folgt erläutern:
• Flüge (SFLIGHT) werden von einer Fluggesellschaft (SCARR) auf einer Flugverbindung (SPFLI, FlugNr., Flugroute) ausgeführt.
• Für jeden Flug gibt es Buchungen (SBOOK) von Kunden (SCUSTOM).
Abb. L11-05: vereinfachtes SAP-Flugdatenmodell mit Kardinalitäten
Die Realität ist natürlich etwas komplizierter, auch das SAP-Datenmodell enthält noch mehr
Informationen. So kann z.B. der Flugzeugtyp spezifiziert werden (Informationsfeld in der Tabelle SFLIGHT)
Lektion 11: Seite 5 von 18
vhb-Kurs „SAP-Programmierung mit ABAP Objects“
Block B * Kapitel 6 * Lektion 11
und hat dafür eine eigene Prüftabelle SAPLANE, in der Detaildaten zum Flugzeugtyp abgelegt sind. Ein
Ticket muss entweder über ein Reisebüro (STRAVELAG) oder am Schalter der Fluggesellschaft
(SCOUNTER) erworben werden, usw.
Fremdschlüsselbeziehungen und -prüfungen bei der Datenpflege
Damit alle Tabellen insgesamt eine konsistente Datenspeicherung ermöglichen, muss über so genannte
Fremdschlüssel festgelegt werden, welche Felder in anderen Tabellen auf Existenz geprüft werden sollen.
Wir gehen vom Beispiel in Abb. L11-05 aus. Es sollen weitere Flüge in der Tabelle SFLIGHT eingetragen
werden. Dazu muss geprüft werden, ob die dabei verwendeten Kürzel für CARRID und CONNID bereits in
der Tabelle SPFLI vorhanden sind. Falls Sie z.B. einen Flug für eine Fluggesellschaft mit dem Kürzel XY und
der Flugnummer 999 eingeben wollen, wird geprüft, ob für ‘XY 999‘ ein Datensatz in SPFLI vorhanden ist.
Dort musste beim Eintrag geprüft werden, ob ‘XY‘ bereits in SCARR gepflegt war. Falls diese Prüfung nicht
erfolgreich sein sollte, darf der Datensatz in SFLIGHT nicht eingefügt werden. Außerdem muss geprüft
werden, ob die Start- und Zielorte in SPFLI in der Prüftabelle SGEOCITY eingetragen sind, usw.
Bei Änderungen auf den Datenbanktabellen können folgende Probleme entstehen:
• Fall 1: Ein neuer (noch einzufügender) SCARR-Eintrag enthält ein Währungskürzel für die Hauswährung
der Fluggesellschaft, das in SCURX (Prüftabelle des Felds SCARR-CURRCODE) nicht existiert. Dies
würde in der weiteren Verarbeitung zu Widersprüchen führen, wenn z.B. die Währung benutzt
werden soll und dazu weitere Informationen aus der Währungstabelle zu dieser Währung abgerufen
werden. Dies passiert irgendwann später im System, wenn niemand mehr weiß, dass in SCARR ein
Eintrag eingefügt wurde, ohne die Prüftabelle vorher mit dem fehlenden Eintrag zu füllen.
• Fall 2: Ein Eintrag aus SCARR soll gelöscht werden (z.B. Insolvenz einer Fluggesellschaft). In SPFLI,
SFLIGHT und SBOOK wird aber auf diesen Eintrag Bezug genommen. Hier muss beim Löschen über
einen „Verwendungsnachweis“ geprüft werden, ob das Löschen zu Komplikationen führen würde.
Diese Prüfung ist aufwändiger als die Prüfung im Fall 1.
Eine Veränderung von Datenbankinhalten findet meistens über eine Dialogtransaktion statt. Hierbei
werden Werte in Eingabefelder auf einer Eingabemaske eingegeben. Das R/3-System führt über diese
Eingabefelder, falls für diese Felder im System eine Prüftabelle hinterlegt ist, eine Fremdschlüsselprüfung
durch, d.h., das System prüft für Sie, ob das eingegebene Feld (bzw. die eingegebene Wertekombination)
auf der Datenbank vorhanden ist. Im Fehlerfall sendet das System eine Nachricht, die Sie über diese
Fehleingabe informiert, gibt Ihnen die Möglichkeit zur Korrektur der Eingabe und verhindert die weitere
Verarbeitung. Beachten Sie aber, dass diese Systemreaktion nicht für alle Anwendungsprogramme
automatisch aktiviert ist.
Daraus ergeben sich für obige Problemfälle folgende Hinweise. Im 1. Fall besteht, sofern Sie die
betroffenen Daten nicht über Dynpro-Felder kontrollieren, die Notwendigkeit, die logischen
Abhängigkeiten manuell zu programmieren. Im 2. Fall müssen Sie dies immer selbst programmieren.
Im Dictionary können Sie die Fremdschlüsselprüfungen durch Prüftabellen erkennen, beispielsweise die
Tabelle SPFLI in Abb. L11-06. Dazu gehen Sie auf die Registerkarte Eingabeprüfungen: Sie können z.B.
erkennen, dass das Key-Feld CARRID (ID der Fluggesellschaft) gegen einen Eintrag in der Tabelle SCARR
(Fluggesellschaft) geprüft wird. Das Feld CITYFROM (Abflugstadt) und CITYTO (Ankunftsstadt) wird mit
einem Eintrag in der Tabelle SGEOCITY (Ortstabelle) verglichen.
In Abb. L11-07 sehen Sie die Möglichkeit, wie Sie sich die Details zur Fremdschlüsselprüfung anzeigen
lassen können: Bei der Tabelle SBOOK auf der Registerkarte Felder markieren Sie die Zeile mit dem
gewünschten Feld (hier: CUSTOMID) und drücken auf den Button mit dem Schlüssel-Symbol. Es erscheint
dann in einem Popup-Fenster (rechter Screenshot) die Information, über welcher Feldern welcher Tabelle
die Fremdschlüsselprüfung durchgeführt wird. Im unteren Bereich ist die Kardinalität angegeben, in
diesem Fall 1:CN, d.h. jedem Satz aus der SCUSTOM können keiner, einer oder mehrere Sätze in der
SBOOK zugeordnet sein. Über ein Icon auf diesem Popup erhalten Sie eine Anzeige der Bedeutung der
Lektion 11: Seite 6 von 18
vhb-Kurs „SAP-Programmierung mit ABAP Objects“
Block B * Kapitel 6 * Lektion 11
Notationsform für die Kardinalität, die hier verwendet wird. Über die F4-Taste bekommen Sie auch eine
kurze Erläuterung angezeigt.
Abb. L11-06: Fremdschlüsselabhängigkeiten beim Flugdatenmodell (auszugsweise)
Abb. L11-07: Fremdschlüsselabhängigkeiten beim Flugdatenmodell: Details zu SBOOK-CUSTOMID
Das Flugdatenmodell ist in Abb. L11-08 abgebildet, allerdings noch ohne Prüf- und
Fremdschlüsseltabellen. Sie erhalten dies, indem Sie im Dictionary die Funktion Grafik (siehe Abb. L11-07
das markierte Icon in der Symbolleiste) drücken, ausgehend von der Anzeige der Tabelle SBOOK. Es
werden alle Tabellen in der Grafik angezeigt, die sich hierarchisch darüber befinden. Durch Drücken der
Buttons Fremdschlüssel bzw. Prüftabelle können weitere abhängige Relationen angezeigt werden. Sie
können im rechten Navigationsbereich durch das Verändern der Größe des Ausschnitts (grüner Rahmen)
den gewünschten Modellteil im Hauptfensterbereich anzeigen. Sie schließen das Grafikfenster über die
SAP-Navigationstasten, z.B. über „Zurück“ (F3).
Lektion 11: Seite 7 von 18
vhb-Kurs „SAP-Programmierung mit ABAP Objects“
Block B * Kapitel 6 * Lektion 11
Abb. L11-08: Data Dictionary: Anzeige Datenmodell (Abb. 2-6)
Tabellen zur System- und Anwendungssteuerung, Customizing
Das R/3-System wird in allen Bereichen von Tabellen gesteuert. So genannte Steuertabellen (z.B. Länder,
Sprachen, Währungen) steuern indirekt die Abläufe, indem z.B. über das Länderkennzeichen
länderspezifische Gesetzesregelungen und über die Sprache die jeweiligen Texte in der Landessprache
prozessiert werden. Das Customizing erfolgt ebenfalls über Tabelleneinträge. In vielen Anwendungen
wird Anwendungslogik statt in Programmen in Tabellen abgelegt. Durch geschicktes Manipulieren dieser
Tabelleneinträge durch den Nutzer können Effekte erreicht werden, für die sonst das Erstellen von
eigenen Programmen notwendig wäre, d.h., es sind dann keine Programmierkenntnisse und berechtigungen notwendig.
Datenbanktabellen und interne Tabellen
Bei Datenbanktabellen handelt es sich um Speicherformen für eine dauerhafte Datenhaltung, die in allen
SAP-Programmen verfügbar ist. Die Veränderung des Aufbaus ist nur über das Dictionary möglich.
Eine interne Tabelle ist nur innerhalb des ABAP-Programms gültig und nur zur Laufzeit mit Werten gefüllt.
Es handelt sich um eine temporäre und lokale Datenhaltung und -verarbeitung im Hauptspeicher. Diese
internen Tabellen müssen im jeweiligen Programm deklariert werden.
Typischer Einsatzbereich für die interne Datenverarbeitung mit internen Tabellen ist das Sortieren von
Datenbeständen sowie die Gruppenstufenverarbeitung.
Tabellen anzeigen und bearbeiten
Es gibt anwendungsübergreifende Programme zur Anzeige bzw. Pflege von Tabelleneinträgen
(Datensätzen). Weitere Informationen finden Sie auch in Block A unter Systemfunktionen.
Erweiterte Tabellenanzeige / -pflege
Über System
Dienste
Erweiterte Tabellenpflege kommen Sie zu einem Einstiegsbild zur
Tabellenpflege (siehe Abb. L11-09 oben). Durch das Drücken einer Taste (z.B. Anzeigen) gelangen Sie auf
ein Bild mit der Anzeige der Datensätze (siehe Abb. L11-09 unten). Hier können auch so genannte Views
(Sichten auf Tabellen) bearbeitet werden.
Lektion 11: Seite 8 von 18
vhb-Kurs „SAP-Programmierung mit ABAP Objects“
Block B * Kapitel 6 * Lektion 11
Tipp
Mit etwas Übung können Sie diese Views über das Dictionary-Infosystem durch geschicktes
Maskieren des Tabellennamens herausbekommen. Dazu drücken Sie im Einstiegsbild des Dictionary
im Fall View den Werthilfebutton. Hier wählen Sie Infosystem und dann alle Selektionen. Bei
Primärtabelle geben Sie dann die Tabelle an, zu der Sie einen View suchen.
In Abb. L11-09 sehen Sie die Tabellenanzeige für die Mandanten-Tabelle T000.
Abb. L11-09: Erweiterte Tabellenanzeige bzw. -pflege: Einstiegsbild und Pflegebild (Abb. 2-7)
Lektion 11: Seite 9 von 18
vhb-Kurs „SAP-Programmierung mit ABAP Objects“
Block B * Kapitel 6 * Lektion 11
Data Browser
Mit dem Data Browser können Einträge von allen Tabellen angezeigt werden. Sie navigieren über
Werkzeuge
ABAP Workbench
Übersicht
Data Browser zu dieser Anwendung. Auf Abb. L11-10
sehen Sie die Schritte zur Anzeige von Tabelleninhalten anhand des Beispiels der Tabelle SPFLI aus dem
SAP-Flugdatenmodell.
Abb. L11-10: Data Browser: Einstiegsbild, Selektionsbild und Anzeige der Tabelleneinträge (Abb. 2-8)
Dictionary-Funktion
Ausgehend von der Tabellenpflege (hier: nicht Pflege der Inhalte, sondern Pflege des Aufbaus) im
Dictionary können Sie ebenfalls zum Data Browser verzweigen. Die Angabe der anzuzeigenden Tabelle ist
hier nicht mehr nötig. Es erscheint gleich ein Selektionsbild, auf welchem Sie eingrenzen können, wie viel
und welche Tabellensätze angezeigt werden sollen. Hier können nicht nur Datensätze angezeigt, sondern
auch interaktiv verändert werden. Sie gelangen vom Dictionary aus zum Data Browser entweder über
Hilfsmittel
Tabelleninhalt
Anzeigen oder über Umfeld
Data Browser. In letzterem Fall muss die
Tabelle angegeben werden.
Anwendungsspezifische Funktionen
Je nach betriebswirtschaftlicher Anwendung gibt es oft zusätzliche Möglichkeiten, sich aus den Menüs
der jeweiligen Anwendung heraus Tabelleneinträge anzeigen zu lassen. Hier finden Sie i.Allg. kein
einheitliches Layout. Dafür sind diese Funktionen angepasst an die spezifischen Bedürfnisse der
jeweiligen Tabelle oder Transaktion. Oft werden dabei mehrere Tabellen „im Verbund“ verändert, um
eine anwendungsspezifische Datenkonsistenz zu gewährleisten.
Lektion 11: Seite 10 von 18
vhb-Kurs „SAP-Programmierung mit ABAP Objects“
Block B * Kapitel 6 * Lektion 11
L11.3:
Datenbankzugriff über SQL-Befehle (
Screencast L11-2.. -4)
Der Zugriff auf Datenbanktabellen, um die gelesenen Daten aufbereitet auszugeben, ist eine Kernaufgabe
der betriebswirtschaftlichen Anwendungen.
ABAP verwendet dafür eine Untermenge der SQL-Sprachbefehle und lehnt sich in der Syntax an die SQLSyntax an (SQL = Structured Query Language, eine Datenbankabfragesprache). Der wichtigste Befehl hier
ist der SELECT-Befehl. Dazu gibt es zahlreiche Varianten und Zusätze, von denen wir für unsere jetzigen
Ziele nur einen Teil benötigen.
Abb. L11-11 zeigt die Vorgänge beim Prozessieren eines ABAP-Programms, das auf Daten einer
Datenbank zugreift. Der erste Teil des Codes (Nr. 1 in Abb. L11-11) sorgt dafür, dass auf einem
Selektionsbild Eingabefelder erscheinen, in die der Benutzer seine individuellen Eingrenzungen schreiben
kann. Der Datenbeschaffungsteil (Nr. 2 in Abb. L11-11) besteht hier aus dem Lesen von
Datenbanktabellen über eine SQL-Schnittstelle. Nach dem Lesen und u.U. Zwischenspeichern in einer
internen Tabelle werden die Daten weiterverarbeitet (Nr. 3 in Abb. L11-11). Zum Schluss werden die
aufbereiteten Daten auf einer Liste ausgegeben (Nr. 4 in Abb. L11-11).
Abb. L11-11: Datenbankzugriff – SQL-Befehle (Abb. 8-9)
Hinweis
Als Beispiel für die Datenverarbeitung werden in Abb. L11-11 interne Tabellen und bei der Ausgabe ein
PERFORM-Befehl verwendet. Diese beiden Features lernen Sie in Lektion 14 und 17 kennen. Hier
benötigen wir sie noch nicht.
Anforderung
Sie wollen auf Datenbankinhalte zugreifen durch ABAP-Code. Die Daten sollen aufbereitet
ausgegeben werden und falls eine Datenhierarchie vorliegt, soll diese bei der Ausgabe berücksichtigt
werden.
Lösung
Mit dem SQL-Sprachbefehl SELECT sowie TABLES und SELECT-OPTIONS.
Lektion 11: Seite 11 von 18
vhb-Kurs „SAP-Programmierung mit ABAP Objects“
Block B * Kapitel 6 * Lektion 11
Selektionsbild: Dateneingrenzung zur Laufzeit
Das Selektionsbild kann in der Grundform zwei Arten von Eingabefeldern, Parameters und Select-Options,
enthalten.
• Der PARAMETERS-Befehl wird für die Deklaration von Eingabefeldern genutzt, bei denen genau ein
Wert einzugeben ist.
• Bei SELECT-OPTIONS (Selektionsoptionen) ist es möglich, Eingabe-Intervalle, Bereiche, Muster oder
komplexe Wertebereiche anzugeben, nach denen im Programm aus der Datenbank selektiert
werden soll (s.u.). Die Angabe dieser komplexen Eingrenzungen muss nicht (!) kodiert werden. Sie
können dies zur Laufzeit auf dem Selektionsbild durch das Drücken von leicht verständlichen
Tasten erreichen (siehe unten in Abb. L11-13).
Sie können vom Selektionsbild aus die Programmausführung starten mit den von Ihnen eingegebenen
Werten. Hiermit wird die Verarbeitung und Datenbeschaffung vorgenommen in Abhängigkeit von Ihren
Eingabedaten aus dem Selektionsbild. Mit den Ausgabebefehlen wird dann entschieden, welche Daten in
welcher Form als Ergebnis nach außen weitergegeben werden. Diese Daten werden als Liste präsentiert.
Selektionsvarianten
Es ist auch möglich, so genannte Selektionsvarianten anzulegen bzw. abzurufen. Diese Varianten stellen
eine feste Zusammenstellung von Eingabewerten dar, die Sie z.B. beim letzten Aufruf des Programms
unter einem Namen abgespeichert haben. Sie sparen sich damit das wiederholte Eingeben derselben
Werte. Dies erleichtert die Bedienung, vor allem wenn die Anzahl der Eingabefelder groß und die
Eingabewerte komplizierte Schlüssel sind.
Eingrenzungsmöglichkeiten
Bei einer Tabelle, die ein Zeilen-/Spalten-Konstrukt darstellt, bei dem jede Zeile denselben Aufbau hat
und in Spalten aufgeteilt ist, können ohne jegliche Einschränkung alle Datensätze, alle Datensätze aber
nur für bestimmte Spalten, nur wenige Datensätze aber mit allen Spalten oder wenige Datensätze und ein
Teil der Spalten für eine Selektion gefordert werden. Oft wird auch explizit genau 1 Datensatz gesucht. Je
nach Situation sieht dann der SELECT-Befehl unterschiedlich aus. Sie finden hier die allgemeine Syntax,
Bedeutung sowie ein Beispiel ausprogrammiert.
Als Beispielszenario dient die Tabelle SPFLI, die die Flugverbindungen einer Fluggesellschaft enthält: die
Key-Felder sind CARRID (Fluggesellschaft) und CONNID (Fluglinie, Flug-Nr.). Informationsfelder sind z.B.
CITYFROM (Startort) und CITYTO (Zielort).
•
Alle Spalten, alle Zeilen: uneingeschränkter Mengenzugriff ( Screencast L11-2)
Beim Select-Statement muss im Prinzip nur die Tabelle angegeben werden (falls mit TABLES
gearbeitet wird und dadurch die INTO-Klausel wegfallen kann):
TABLES: <dbtab>.
SELECT * FROM <dbtab>.
„Anweisungen“
ENDSELECT.
Das Zeichen „*“ (Stern) steht für generische Selektion innerhalb einer Tabellenzeile, d.h., es werden
alle Spalten der selektierten Zeile ausgewählt. „<dbtab>“ steht für den Namen einer
Datenbanktabelle, die hier explizit angegeben werden muss. Dafür muss im Vorfeld eine so genannte
Workarea vereinbart werden über den TABLES-Befehl. Die Workarea ist eine Feldleiste für einen
einzelnen Datensatz. In diese Feldleiste wird bei der Verarbeitung sukzessive ein Datenbanksatz nach
dem anderen eingelesen, der dann über diese Workarea im ABAP-Programm weiterverarbeitet
werden kann. Wir nennen diese Workarea deshalb im Folgenden Arbeitszeile.
Lektion 11: Seite 12 von 18
vhb-Kurs „SAP-Programmierung mit ABAP Objects“
Block B * Kapitel 6 * Lektion 11
Auf das Feld aus der Tabelle wird zugegriffen, indem Sie es mit Bindestrich an das Präfix
<Datenbanktabellennname> hängen.
Beispiel
Es sollen alle Datensätze der Tabelle SPFLI gelesen und die Felder CARRID, CONNID, CITYFROM, CITYTO
und DISTANCE ausgegeben werden.
REPORT zdemo.
TABLES: spfli.
SELECT * FROM spfli.
WRITE: / spfli-carrid, spfli-connid, spfli-cityfrom, spfli-cityto, spfli-distance.
ENDSELECT.
•
Alle Spalten, 1 Zeile: Einzelsatzzugriff mit SELECT SINGLE ( Screencast L11-3)
Hier wird ebenfalls mit „*“ für „alle Spalten“ gearbeitet. Da explizit nur 1 Datensatz gesucht wird,
wird der Befehl SELECT SINGLE verwendet, gefolgt von einer WHERE-Klausel, deren logischer
Ausdruck so aufgebaut sein sollte, dass maximal genau ein Datensatz gefunden werden kann.
Typischerweise spezifiziert man deshalb alle Key-Felder mit „=“.
SELECT SINGLE * FROM <dbtab>
WHERE keyfeld1 = variable1
AND
keyfeld2 = variable2
AND … .
Unscharfe Eingrenzung beim SELECT SINGLE
Man kann aber auch mit Sekundär-Key-Feldern arbeiten – bzw. nicht eindeutig (= teilgenerisch) eine
WHERE-Klausel formulieren. In diesem Fall gibt es weder einen Syntax- noch einen Laufzeitfehler. Es
wird einfach der erste Datensatz von der Datenbank genommen, der die WHERE-Klausel erfüllt,
danach ist die Datenselektion beendet.
Beispiel
Es soll der Datensatz gesucht werden, der zur Fluglinie LH, 400 gehört.
TABLES: spfli.
REPORT zdemo.
TABLES: spfli.
DATA:
feld1 TYPE spfli-carrid VALUE 'LH',
feld2 TYPE spfli-connid VALUE '400'.
SELECT SINGLE * FROM spfli
WHERE carrid = feld1
AND
connid = feld2.
IF sy-subrc = 0.
WRITE: / spfli-carrid, spfli-connid, spfli-cityfrom, spfli-cityto, spfli-distance.
ELSE.
WRITE: / 'kein Datensatz gefunden'.
ENDIF.
Mit einer Abfrage auf das Systemfeld SY-SUBRC (liefert den Returncode 0, falls die Abfrage erfolgreich
war) können wir feststellen, ob ein Satz gefunden wurde.
•
Alle Spalten, n von m Zeilen: Mengenzugriff mit SELECT-Schleife ( Screencast L11-4)
Der Mengenzugriff auf mehrere Datensätze ist mit dem Befehl SELECT ... ENDSELECT möglich und hat
die Syntax
SELECT * FROM <dbtab> WHERE <log. Ausdruck>.
„Verarbeitung“
ENDSELECT.
Lektion 11: Seite 13 von 18
vhb-Kurs „SAP-Programmierung mit ABAP Objects“
Block B * Kapitel 6 * Lektion 11
Da <log. Ausdruck> logisch wahr sein muss, wird je nach Wert des Ausdrucks zur Laufzeit eine
Eingrenzung der Datenselektion durchgeführt. Als <log. Ausdruck> kann hier im Gegensatz zum SELECT
SINGLE auch eine Spezifizierung mit anderen Vergleichsoperatoren erfolgen, die als Ergebnis auch die
Möglichkeit zulassen, dass u.U. viele Datensätze diesen logischen Ausdruck erfüllen. Das nennt man
auch generische bzw. teilgenerische Qualifikation der Schlüsselfelder. Deshalb ist hier ein
Schleifenkonstrukt notwendig. Die Schleife SELECT ... ENDSELECT wird so oft durchlaufen und die
„Verarbeitung“ durchgeführt, wie auch Datensätze gefunden wurden. Als logische Ausdrücke sind fast
alle Ausdrücke erlaubt, die auch beim IF-Befehl zulässig sind. Details finden Sie unter SELECT in der F1Hilfe im Editor.
Beispiel
Falls die Tabelle SPFLI zwei Schlüsselfelder hat und wir nur das erste spezifizieren, werden wir i.Allg.
mehr als einen Datensatz dazu finden. Falls Sie Start- und Zielort spezifizieren, können auch mehrere
Datensätze gefunden werden, da i. allg. mehrere Fluggesellschaften Flüge auf derselben Fluglinie
anbieten. Diese werden mit dem folgenden ABAP-Code gelesen und ausgegeben:
REPORT zdemo.
TABLES: spfli.
DATA:
feld1 TYPE spfli-cityfrom VALUE 'FRANKFURT',
feld2 TYPE spfli-cityto
VALUE 'NEW YORK'.
SELECT * FROM spfli
WHERE cityfrom = feld1
AND
cityto
= feld2.
WRITE: / spfli-carrid, spfli-connid,
spfli-cityfrom, spfli-cityto, spfli-distance.
ENDSELECT.
IF SY-SUBRC <> 0.
WRITE: / 'kein Datensatz gefunden'.
ENDIF.
•
n von m Spalten: Teilzugriff auf Tabelle (nicht alle Attribute)
Wir erläutern diese Anforderung für den Fall, dass mehrere Datensätze gesucht werden. Die
Kombination mit der Suche nach allen Datensätzen bzw. nach nur einem Datensatz wird analog
programmiert.
Beachten Sie dabei, dass die Aufzählung der Tabellenfelder direkt nach SELECT ohne Klammern und
ohne Kommata erfolgt, während beim INTO mit Klammern und Kommata gearbeitet werden muss.
Vergessen Sie nicht, die Variablen zu deklarieren.
SELECT f1 f2 f3 FROM <dbtab> INTO (v1, v2, v3)
WHERE <log. Ausdruck>.
„Verarbeitung“
ENDSELECT.
Beispiel
Es sollen alle Datensätze, aber nur die Spalten CITYFROM und CITYTO gelesen und ausgegeben
werden.
REPORT zdemo.
TABLES: spfli.
DATA:
startort TYPE spfli-cityfrom,
zielort TYPE spfli-cityto.
SELECT cityfrom cityto FROM spfli INTO (startort, zielort)
WRITE: / spfli-cityfrom, spfli-cityto.
ENDSELECT.
Lektion 11: Seite 14 von 18
vhb-Kurs „SAP-Programmierung mit ABAP Objects“
Block B * Kapitel 6 * Lektion 11
Verwendung der Spalteneingrenzung
Bisher konnten Sie sich bei der Ausgabe immer auf wenige Spalten beschränken – auch dann, wenn
Sie alle Spalten gelesen haben. Aus funktionaler Sicht gibt es also keinen Unterschied, nur die
Performance wird sich verbessern, da nur eine Teilmenge der gesamten Daten gelesen werden muss.
Jetzt können Sie maximal die Spalten ausgeben, die über die dem SELECT folgende Aufzählung in die
passend vereinbarten Variablen hinter der INTO-Klausel geschrieben werden. Sie müssen selbst dafür
sorgen, dass die bei INTO aufgeführten Variablen gleich typisiert deklariert werden wie die zwischen
SELECT und FROM aufgeführten Tabellen-Spalten.
Diese Variante der SELECT-Programmierung wird meistens erst dann eingesetzt, wenn die
Funktionalität selbst endgültig ist, d.h. wenn sich die Anforderung an die Menge der benötigten
Tabellenspalten nicht mehr ändert. Ansonsten wäre der Änderungsaufwand deutlich höher.
Verwendung von TABLES bzw. DATA
Die als Beispiele im Folgenden aufgeführten ABAP-Programme verwenden das TABLES-Schlüsselwort. Sie
können stattdessen auch mit DATA arbeiten und müssen dafür wie folgt vorgehen:
Anstatt
TABLES: spfli.
schreiben Sie:
DATA: wa TYPE spfli.
Beim SELECT-Statement schreiben Sie anstatt
SELECT * FROM spfli
jetzt mit der INTO-Klausel:
SELECT * FROM spfli INTO wa
Sie lassen den Rest des SELECT-Statements unverändert, und ersetzen beim WRITE-Statement den Präfix
„spfli-“ durch „wa-“.
Wir haben hier mit der einfacheren TABLES-Anweisung gearbeitet, werden im Folgenden beim Reporting
mit DATA arbeiten, und kommen in Block D bei der Dialogprogrammierung wieder auf TABLES zurück.
Hinweise
• Es gibt auch ein Konstrukt ohne Schleife, bei dem alle gefundenen Datensätze auf einmal in eine so
genannte interne Tabelle (siehe Lektion 14 für die Erläuterung der internen Tabellen) geschrieben
werden.
• Für den Vergleich von Mustern werden in der SQL-Syntax andere Sonderzeichen verwendet als beim
IF-Statement (statt * und + verwenden Sie hier % und _).
• Oft haben wir die Situation, dass wir nicht Daten aus einer Tabelle benötigen, sondern aus mehreren,
die voneinander abhängen. Es liegen hierarchische Beziehungen vor, die sowohl bei der
Lesereihenfolge als auch bei der Ausgabe berücksichtigt werden müssen (siehe Lektion 12).
• Zur Erleichterung gibt es logische Datenbanken (LDB), die Ihnen sowohl das Lesen der Daten von der
Datenbank als auch die Ausgabe erleichtern (siehe Lektion 16).
L11.4:
Filtern mit SELECT-OPTIONS, IN-Operator (
Screencast L11-5)
Um generische Eingrenzungen (Mengen, Muster usw.) zu ermöglichen, gibt es die so genannten SELECTOPTIONS (Selektionsoptionen). Selektionsoptionen erlauben es Ihnen, mit dem Befehl SELECT-OPTIONS
Wertemengen einzugeben. Den Namen der Selektionsoption geben Sie nach dem Schlüsselwort an. Typ
und Länge wird jetzt aber nicht wie bei DATA oder PARAMETERS deklariert, sondern es wird durch FOR
<feldname> ein Bezug zu einem anderen bekannten Feld hergestellt. Dies kann auch ein Datenbankfeld
sein, dessen Eigenschaften aus dem Data Dictionary übernommen werden. Beachten sie dabei, dass
dieses Feld im Programm vorher (!) über TABLES bzw. DATA deklariert sein muss.
Lektion 11: Seite 15 von 18
vhb-Kurs „SAP-Programmierung mit ABAP Objects“
Block B * Kapitel 6 * Lektion 11
Beispiel
Sie wollen für die Fluggesellschaft eine Eingabemöglichkeit programmieren.
SELECT-OPTIONS flugges FOR spfli-carrid.
Auch hier können Defaultwerte vereinbart werden. Dies ist aber etwas komplizierter: Hinter einer
SELECT-OPTION versteckt sich nämlich eine so genannte interne Tabelle mit speziellem Aufbau und Logik
(siehe Abb. L11-12 und Lektion 14).
Folgende Anforderungen werden an Selektionsoptionen gestellt:
• Eingrenzung durch Angabe von Einzelwerten, die auf Gleichheit, kleiner bzw. größergleich oder
innerhalb eines Intervalls geprüft werden
• Auswahl von Werten gemäß eines Musters mit Platzhaltern für einzelne beliebige Zeichen oder für
Zeichenketten mit beliebigen und beliebig vielen Zeichen
• Einschließende und ausschließende Wertemengen
Beispiel
Sie suchen Flugverbindungen auf der Datenbank. Dabei sollen die Fluggesellschaften mit N beginnen
oder zwischen A und L liegen, der Zielort soll mit „S“ beginnen, nicht aber mit „ST“.
Um diese Anforderungen systematisch erfassen zu können, ist es notwendig, nach einem bestimmten
Schema vorzugehen. Dazu werden diese Bedingungen tabellarisch in einer bestimmten systemweit
einheitlichen Form gespeichert.
Jede einzelne Bedingung besteht aus Wert(en). Als Werte werden 1 bzw. 2 Werte zugelassen. Zwei Werte
sind bei „von – bis“-Angaben sinnvoll. Ansonsten brauchen wir nur einen Wert. Für Muster gibt es die
Maskierungszeichen
„*“
beliebige und beliebig viele Zeichen
„+“
genau ein beliebiges Zeichen
Selektions- Von
feld
Bis
Operator
I/E
FLUGGES
L
BT
I
N*
CP
I
S*
CP
I
ST*
CP
E
ZIELORT
A
Abb. L11-12: Aufbau der Selektionsbedingungen für den Datenbankzugriff (Abb. 8-10)
Die Vergleichsoperatoren beziehen sich auf das jeweilige Feld mit dem im Selektionsbild eingetragenen
Wert. Die Operatoren sind in der Onlinehilfe erläutert. BT heißt Between, CP steht für Contains Pattern.
Für die Entscheidung, ob es sich um eine einschließende oder ausschließende Suche handelt, ist ein
einzelnes Zeichen ausreichend: „I“ steht für Including, „E“ für Excluding.
Achtung
Realisieren Sie die letzte Zeile im Beispiel in Abb. L11-12 mit der Registerkarte Werte ausschließen
(Einzelwerte mit rotem Button) und dem einschließenden Operator. Falls Sie die Registerkarte Werte
einschließen (Einzelwerte mit grünem Button) verwenden mit ausschließendem Operator, erhalten Sie
falsche Ergebnisse (Übungsaufgabe: warum?).
Lektion 11: Seite 16 von 18
vhb-Kurs „SAP-Programmierung mit ABAP Objects“
Block B * Kapitel 6 * Lektion 11
Damit haben wir alle Informationen, um ein geeignetes SELECT-Statement aufzubauen. In der WHEREKlausel können obige Operatoren nahezu direkt umgesetzt werden. Deshalb wird das SELECT-OPTIONSStatement intern über eine Tabelle abgebildet mit obigem Aufbau. Zusammen mit dem IN-Operator
(siehe auch Onlinehilfe) können wir jetzt die Eingaben im Selektionsbild elegant auf den DatenbankLesebefehl SELECT übertragen.
Nehmen wir an, dass obige Daten aus der Tabelle SPFLI gelesen werden, welche u.a. die Felder carrid und
cityto enthält. Die SELECT-OPTIONS seien deklariert mit
SELECT-OPTIONS: flugges FOR spfli-carrid,
zielort FOR spfli-cityto.
Ein passender ABAP-Befehl würde dann so aussehen:
SELECT * from spfli
WHERE flugges IN carrid
AND
zielort iN cityto.
... Verarbeitung...
ENDSELECT.
Im ABAP-Code reicht der Operator „IN“ aus, um beliebig viele Teilbedingungen zu bearbeiten, die Sie auf
dem Selektionsbild eingegeben haben! Die Interpretation und logische Aufbereitung übernimmt der
ABAP-Prozessor für Sie. Zusätzlich können Sie noch den Befehl RANGES (siehe Onlinehilfe) verwenden.
In der Abb. L11-13 sehen Sie, wie Sie obige Beispieleingrenzungen auf einem konkreten Selektionsbild
vornehmen können.
Zuerst drücken Sie auf Mehrfachselektion (siehe Abb. L11-13 rechts oben). Dann erscheint das Popup zur
Mehrfachselektion mit mehreren Registerkarten. In Abb. L11-13 Mitte sehen Sie gerade die Registerkarte
für die Eingabe von Intervallen. Mit Übernehmen werden alle Einträge auf allen Registerkarten
übernommen und das Selektionsbild (siehe unterer Teil in Abb. L11-13) erscheint. Der rechte Knopf ist
jetzt farbig, was uns zeigt, dass Mehrfachselektionen eingegeben wurden. Die erste dieser Selektionen
wird auch direkt angezeigt, in diesem Fall eine Mustereingabe (alle Fluggesellschaften, die mit N
beginnen).
Tipp:
Screencast L11-5 zeigt eine Animation über die Funktionalität des IN-Operators mit SELECT-OPTIONS.
Lektion 11: Seite 17 von 18
vhb-Kurs „SAP-Programmierung mit ABAP Objects“
Block B * Kapitel 6 * Lektion 11
Abb. L11-13: Komplexe Selektionsmengen auf Selektionsbild eingeben (Abb. 8-11)
Lektion 11: Seite 18 von 18

Download Report