DDIC der Zukunft (Heute)
Wie geht es eigentlich mit dem DDIC in Zukunft weiter und können wir schon Heute die neuen Features für uns nutzen? In diesem Teil schauen wir auf den aktuellen Zustand des Dictionary in ABAP.
Inhaltsverzeichnis
In diesem Beitrag schauen wir uns den Zustand des Dictionaries im Alltag und vor allem in der heutigen Zeit an und betrachten verschiedene Punkte, wie teilweise immer noch modelliert wird.
Einleitung
Dabei spielt das Dictionary, oder kurz DDIC, eine besondere Rolle im ABAP-Universum. Kaum eine andere Programmiersprache verfügt über eine integrierte Bibliothek von wiederverwendbaren Typen, Strukturen und Tabellen, die man jederzeit direkt in Programmen einbinden kann. In anderen Sprachen musst du dafür meist zahlreiche Bibliotheken installieren, DDLs initialisieren, Pakete herunterladen oder andere Umwege gehen, um etwas Vergleichbares zu erhalten. Damit dreht sich beim Dictionary alles um das Thema Wiederverwendbarkeit und die Nutzung innerhalb unserer Anwendungen.
Doch das Dictionary ist im Wandel: War es in der Vergangenheit vor allem für die GUI-Entwicklung ausgelegt und musste entsprechende Kriterien erfüllen, hat sich das mittlerweile geändert. Heute benötigen wir Objekte, die vor allem mit dem Fiori Frontend interagieren und ähnliche Eigenschaften aufweisen, aber ohne den Overhead auskommen, den beispielsweise ein Datenelement in Kombination mit einer Domäne erzeugt.
Daher wird es Zeit für eine Modernisierung. In dieser dreiteiligen Serie schauen wir uns an, was sich bisher getan hat und wie es in Zukunft weitergeht.
Übersicht
Hier findest du einen groben Überblick der aktuellen Struktur und Objekte, die wir benötigen, wenn wir mit dem Dictionary arbeiten. Auf der linken Seite findest du die unterste Ebene, auf der rechten Seite bist du schon relativ weit oben im Stack. Grundsätzlich fangen wir eigentlich immer an, auf der Domäne zu modellieren. Wir können Domänen anlegen, welche die entsprechenden technischen Datentypen haben. Dazu legen wir meist ein Datenelement an, in dem die Texte definiert sind und das wiederum eine Domäne verwendet oder auch verschiedene Domänen wiederverwenden kann.
Darüber stehen die Datenbanktabellen. Tabellen haben Spalten, und diese Spalten wiederum verwenden meistens Datenelemente, da sie gleichzeitig auch die Attribute aus den Datenelementen erben. Wollen wir verschiedene Tabellen zusammenbringen und vielleicht einen Join bilden, können wir das über einen View machen, den wir ebenfalls im Dictionary anlegen.
Darunter gibt es zwei Hilfstypen. Zum einen die Struktur, die wiederum keine Daten enthält, aber eine Menge von Feldern abbildet. Diese Struktur kann auch verwendet werden, um sie zum Beispiel in verschiedene Tabellen zu integrieren, damit man die gleiche Struktur über mehrere Tabellen hinweg nutzen kann. Aus einer Struktur lässt sich auch ein Tabellentyp ableiten. Das heißt, wir definieren direkt einen Typen, der zum Beispiel auch einen Schlüssel, eine Sortierung und gewisse Schlüsselfelder hat. Diesen Typen können wir dann wiederverwenden, das passiert vor allem im Schnittstellenbereich von Funktionsbausteinen.
Elemente
Schauen wir uns die verschiedenen Ebenen und Artefakte einmal im Detail an und schauen auf die spezifischen Eigenschaften.
Domäne
In einer Domäne definieren wir erst einmal den grundlegenden Datentyp, den die Domäne haben soll. Dabei können wir zwischen verschiedenen Grundarten wie Character (CHAR), Numerisch Character (NUMC), Integer (INT4), Datum (DATS) und anderen Datentypen wählen. Viele Datentypen erfordern dann eine Längenangabe. Sind wir damit fertig, können wir dem Datentypen zum Beispiel auch Festwerte zuweisen. Diese verhalten sich ähnlich wie Konstanten, die aber nicht im Coding geprüft und validiert werden, sondern maximal im UI zur Auswahl aus einer Domäne heraus angeboten werden. Grundsätzlich hat das den charmanten Vorteil, dass wir einen Wert und einen entsprechenden Text dazu definieren und du später nicht die Arbeit in der GUI hast, diese mit Aufwand zur Anzeige zu bringen.
Ein zweiter Bestandteil von Domänen sind die Ausgabekriterien, also die Frage, wie wir am Ende den Wert auf dem Screen oder in einer Liste ausgeben. So haben wir zum einen die Ausgabelänge, die wir definieren können. Wir können zudem eine Konvertierungsroutine (Conversion Exit) hinterlegen, die zum Beispiel führende Nullen automatisch ergänzt (ALPHA). Darüber hinaus können wir festlegen, ob ein Text Groß- und Kleinschreibung erlauben soll, da ansonsten standardmäßig in Großbuchstaben konvertiert wird. Im unteren Bereich findest du noch die Wertetabelle. Diese dient vor allem dazu, dass automatisch eine Fremdschlüsselprüfung hinterlegt ist, wenn das entsprechende Element später in einer Tabelle verwendet wird.
Datenelement
Das Datenelement ist der Grundbestandteil, bevor es in die Tabellenentwicklung geht. Es enthält eine Domäne, welche den Datentyp des Datenelements definiert. Grundsätzlich kannst du in einem Datenelement aber auch vordefinierte Datentypen direkt angeben oder beispielsweise auf Interfaces und Klassen referenzieren. Hauptsächlich wird hier definiert, welche Feldbezeichnungen es für die Spaltenüberschriften und weitere Beschreibungstexte gibt. Unter den zusätzlichen Kriterien findest du noch weitere Elemente:
- Suchhilfe - Diese kannst du hier einbinden, damit sie später in der SAP GUI automatisch eine definierte Wertehilfe und Suchmöglichkeit bekommst.
- Parameter-ID - Wenn Felder bestimmten Memory-Parametern zugeordnet werden sollen, um Werte standardmäßig vorzubelegen.
- Änderungsbelege - Wenn die Tabelle protokolliert wird und du Änderungen an genau diesem Feld im System loggen möchtest, dann aktivierst du hier das entsprechende Flag im Element.
Tabelle
Die Tabelle ist der wichtigste Bestandteil im System, da sie die Daten speichert und für uns persistiert, damit wir beim nächsten Mal wieder auf die gleichen Daten zugreifen können. In einer klassischen Tabelle wird im Headerbereich auch definiert, um welche Auslieferungsklasse es sich handelt und ob die Tabellendaten über klassische Pflegewerkzeuge gepflegt werden dürfen. Bei den Feldern definieren wir, welche davon Schlüsselfelder sind. Wir können aber auch Fremdschlüsselbeziehungen zu unseren Prüftabellen definieren. Damit erhalten wir später eine konsistente Prüfung auf der Datenbank, ob das entsprechende Element überhaupt vorhanden ist, wenn wir einen neuen Eintrag hinzufügen wollen (FOREIGN KEY). Am Beispiel eines Counters sehen wir zudem, dass wir nicht zwingend ein Datenelement benötigen, sondern auch einen sogenannten eingebauten Typ verwenden können, in diesem Fall ein Integer-Feld vom Typ INT4.
Typen
Als nächstes definieren wir uns einen Hilfstypen, eine sogenannte Struktur. Die Struktur sieht einer Tabelle optisch relativ ähnlich. Wir benötigen hier allerdings keine technischen Einstellungen für die Datenbank. Sie benötigt auch kein Mandantenfeld, um die Daten abzugrenzen, sondern wir können direkt alle Felder angeben, die wir benötigen. Im Gegensatz zur Tabelle hält eine Struktur allerdings keine persistenten Daten auf der Datenbank, weshalb wir auch nicht per SELECT von ihr lesen können.
Zusätzlich dazu definieren wir uns noch einen Tabellentyp. Der Tabellentyp kann zum Beispiel unsere Struktur einbinden, das heißt, die Tabellenzeile sieht dann genauso aus wie die Struktur selbst. Einen Tabellentyp können wir direkt definieren und festlegen, dass er beispielsweise einen Primärschlüssel hat, vom Tabellentyp her eine sortierte Tabelle ist und mit verschiedenen Schlüsselkomponenten arbeitet. Wie du unten siehst, haben wir den Identifier als Schlüsselelement definiert, dieser grenzt die späteren Werte in der internen Tabelle ab.
Verwendung
In diesem Kapitel schauen wir uns zwei Szenarien für die Verwendung an und schauen direkt auf einen spezifischen Use-Case.
Selektion
Wie sieht es eigentlich mit dem Thema Datensicherheit aus? Schauen wir uns einmal einen Ausschnitt aus dem Coding an, das wir in der klassischen ABAP-Entwicklung eigentlich immer implementieren müssen, wenn wir auf die Daten zugreifen. Wir lesen die Daten aus der Tabelle und müssen im nächsten Schritt erst einmal prüfen, ob der aktuell angemeldete Nutzer überhaupt die erforderlichen Berechtigungen hat. In diesem Fall haben wir ein eigenes Berechtigungsobjekt angelegt und prüfen per AUTHORITY-CHECK gegen die Aktivität "03" (Anzeige). Zusätzlich prüfen wir, ob die Berechtigung für die entsprechende Aktion vorliegt. Dieser manuelle Schritt ist im klassischen DDIC-Umfeld essenziell, um sicherzustellen, dass keine unberechtigten Datenzugriffe auf der Anwendungsebene stattfinden.
SELECT FROM zbs_ddic_table
FIELDS *
INTO TABLE @DATA(found_ddics).
LOOP AT found_ddics INTO DATA(found_ddic).
DATA(table_index) = sy-tabix.
AUTHORITY-CHECK OBJECT 'ZBS_DDIC'
ID 'ACTVT' FIELD '03'
ID 'ZBSDDICACT' FIELD found_ddic-action.
IF sy-subrc <> 0.
DELETE found_ddics INDEX table_index.
ENDIF.
ENDLOOP.
Damit besteht eine sehr hohe Gefahr, dass wir diesen Berechtigungscode schlichtweg vergessen, sobald wir den Datenzugriff auf die Tabelle implementieren, da er nicht automatisch mitgezogen wird. Dies birgt ein erhebliches Sicherheitsrisiko bei der Verwendung von klassischen DDIC-Tabellen: Wir laufen Gefahr, im Coding Daten zu lesen, für die der User eigentlich gar nicht berechtigt ist.
Konstanten
In diesem zweiten Beispiel wollen wir einmal unsere Aktion verwenden und im Code vergleichen, ob ein Feld in einer lokalen Struktur einen gewissen Aktionscode enthält. Dazu definieren wir uns erst einmal eine lokale Konstantenstruktur, die alle Aktionen enthält, die auch in der Domäne definiert sind. Hier besteht die erste große Gefahr darin, dass wir vergessen, Werte im Coding nachzuziehen, wenn wir sie in der Domäne angepasst oder erweitert haben. Zudem wissen wir im Nachgang oft nicht, ob das die einzige zentrale Stelle ist oder nur eine von vielen Stellen im System, an denen diese Konstanten redundant definiert wurden.
CONSTANTS:
BEGIN OF actions,
no_action TYPE zbs_ddic_action VALUE '',
enhancement TYPE zbs_ddic_action VALUE 'E',
rollout TYPE zbs_ddic_action VALUE 'R',
END OF actions.
Wir definieren uns dann eine Variable, in diesem Fall vom Typ der Struktur, die wir vorher definiert haben. Anschließend können wir in einem IF-Statement prüfen, ob in einem Aktionsfeld zum Beispiel die Aktion ENHANCEMENT enthalten ist. Dies fühlt sich beim Schreiben relativ natürlich an: Wir können direkt auf die Konstantenstruktur zugreifen und daraus das Feld ENHANCEMENT wählen, welches unserem Wert in der Domäne entspricht. Eine automatische Prüfung durch den Compiler erfolgt hierbei jedoch nicht. Das bedeutet, dass innerhalb von Klassen und Interfaces auch jeder andere beliebige Wert übergeben werden kann, solange der technische Datentyp übereinstimmt. Ein echter typisierter Schutz, wie wir ihn uns für robuste Architekturen wünschen, fehlt beim klassischen DDIC-Ansatz an dieser Stelle komplett.
DATA local_structure TYPE zbs_s_ddic_info.
IF local_structure-action = actions-enhancement.
" TODO
ENDIF.
Vollständiges Beispiel
Alle erstellten Elemente und Beziehungen findest du in einem neuen GitHub Repository. Im Unterpaket ZBS_DEMO_DDIC_OLD findest du alle klassischen DDIC Elemente. Im Oberpaket haben wir übergreifende Elemente definiert, die wir verwenden.
Fazit
Das Dictionary ist und bleibt ein wichtiger Bestandteil der ABAP-Entwicklung, und die klassischen Objekte kommen seit Jahrzehnten zum Einsatz. Allerdings liegt der Fokus hier vor allem auf der GUI-Entwicklung, da viele Funktionalitäten wie Suchhilfen, Fremdschlüsselbeziehungen und Konvertierungsroutinen noch komplett auf das SAP-GUI-Zeitalter ausgelegt sind.
