Skript Lektion 11

Transcript

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: . SELECT * FROM . „Anweisungen“ ENDSELECT. Das Zeichen „*“ (Stern) steht für generische Selektion innerhalb einer Tabellenzeile, d.h., es werden alle Spalten der selektierten Zeile ausgewählt. „“ 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 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 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 WHERE . „Verarbeitung“ ENDSELECT. Lektion 11: Seite 13 von 18 vhb-Kurs „SAP-Programmierung mit ABAP Objects“ Block B * Kapitel 6 * Lektion 11 Da logisch wahr sein muss, wird je nach Wert des Ausdrucks zur Laufzeit eine Eingrenzung der Datenselektion durchgeführt. Als 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 INTO (v1, v2, v3) WHERE . „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 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