SAP ABAP CDS Views – Datenmodell der Moderne
Der Blick zurück
Schon die ersten R/3 Versionen zeigten sehr deutlich eine Stärke der SAP: die Fähigkeit, betriebswirtschaftliche Zusammenhänge in Datenmodelle zu gießen und darauf informatorische Funktionen zur Verfügung zu stellen. Erinnern wir uns an das ausgefeilte Modell zum Verkaufsbeleg:
(Bild zum Vergrößern anklicken)
Man erkennt sofort die Sorgfalt der SAP und den durchschlagenden Erfolg, alle Relationen und Zusammenhänge festzuhalten und zu dokumentieren. Der kundige Entwickler kann sich, wenn er denn Zugriff zu einem SAP ERP System hat, die gesamte Betriebswirtschaft aus dem Datenmodell erschließen. Aber das sorgfältige Ablegen der Modelle hat weitere Vorteile. So werden Eingaben automatisch auf Korrektheit überprüft und dem SAP GUI ist es möglich, Wertehilfen anzubieten und den Benutzer perfekt zu unterstützen. Schon vor mehr als 20 Jahren war es natürlich auch schon ein Traum, Oberflächen direkt auf das Datenmodell aufzusetzen, diese vielleicht sogar aus dem Modell heraus zu generieren. Aber es sollten viele Experimente scheitern, bevor man mit CDS Views relativ nahe am Ideal angekommen ist.
Was fehlt dem Datenmodell verglichen mit einer grafischen Oberfläche?
Betrachtet man all die Informationen, die im SAP Datenmodell abgelegt sind, so fragt man sich, warum man kein Programm zur Verfügung stellt, das direkt aus dem Modell eine grafische Oberfläche aka ein UI generieren kann. Die Antwort darauf ist vielschichtig:
Der erste Grund ist trivial: Es sind einfach wesentliche Informationen, die man für eine Oberfläche benötigt, nicht in den betriebswirtschaftlichen Modellen hinterlegt. Zum Beispiel ist nichts darüber ausgesagt, ob Detailinformation im selben Fenster, als Popup oder als unabhängiges weiteres Fenster erscheinen soll. Der Leser findet in der Transaktion PFCG Beispiele, welcher Ansatz gewählt wurde, diese Herausforderung zu lösen. Leider ist dies nicht immer optimal gelungen. Mir jedenfalls hat sich nie erschlossen, wie die Möglichkeit, das Navigationsverhalten zu beeinflussen, in die Rollenpflege gekommen ist:
Vermutlich fand die SAP, dass weder das betriebswirtschaftliche Datenmodell noch die Oberflächen Träger dieser Information werden soll. Die Rollenpflege bot sich an, weil diese Transaktion zusammen mit dem NWBC bzw. dem Portal auch Pflegeoberfläche für die OBN Navigation wurde. Das Hauptproblem mit diesem Vorgehen ist, dass neue aufkommende Interaktionsmodelle im User Interface auf einmal Widersprüche mit den Einträgen in der PFCG erzeugen.
Erschwerend kommt hinzu, dass die SAP Architektur ein 2-tier Setup ist. Der Datenbank mit ihren Modellen steht ein Applikationsserver zur Seite, der bis zu Fiori die Präsentationsschicht enthielt. Natürlich ist es nicht sinnvoll, alle Daten der Datenbank im Applikationsserver vorzuhalten. Der Datentransport von DB zum Applikationsserver ist jedoch performancetechnisch deutlich teurer als ein Datentransport innerhalb eines Servers. Um diesen Nachteil auszugleichen, müssen ausgefeilte Puffermechanismen implementiert sein. Ein besonders extremes Beispiel kann man in der Implementierung des CRM Systems sehen: die Grundidee hier ist es, einem Call Center Agent möglichst flüssiges Arbeiten zu ermöglichen. Daher lädt beim CRM der Applikationsserver beim Start sehr viele Daten in drei unterschiedliche Layer auf dem Applikationsserver. Ist dies geschehen, muss im weiteren Verlauf der Arbeit des Agenten wenig nachgelesen werden. Der Preis ist, dass das Startup Verhalten des CRM Systems in der Regel nicht mit ERP Systemen mithalten kann. Die Oberfläche im CRM kann jedoch deutlich eleganter formuliert werden und unterstützt den Anwender mit mächtigeren Zusatzfunktionen. Die Oberfläche wird jedoch auch nicht aus dem Datenbankmodell generiert und zwischen das betriebswirtschaftliche Datenmodell auf der Datenbank kommt ein Interaktionsdatenmodell, der sogenannte BOL/Genil. Es würde viel zu weit führen, dieses Modell hier zu erklären. Wichtig ist jedoch die Erkenntnis, dass dieses Modell explizit programmiert werden musste. Von einer Generierung aus der Datenbank heraus ist man hier also auch weit entfernt.
Einzug der objekt-orientierten Programmierung und die Auswirkungen
- Befeuert wurde der Glaube an parallele Modelle außerhalb der Datenbank zur Jahrtausendwende durch den Siegeszug der objekt-orientierten Programmierung. Die sogenannte „Gang of four“ hatte mit dem Buch „Design Patterns: Elements of Reusable Object-Oriented Software“ 1994 einen durchschlagenden und nachhaltigen Erfolg. Danach war die gesamte Welt überzeugt, dass Objekt-Orientierung viele, wenn nicht sogar alle, Probleme der Informatik lösen würde. Es wurde danach als ein Muss angesehen, die Datenbank durch Klassen oder Objekte zu verschalen und auch die Oberflächenelemente durch Klassen und Vererbung auszudrücken. Vieles musste erarbeitet werden und zumindest die Grundlagen konnten wieder nicht generiert werden, da zu viel Ingenieurs-Intelligenz in den OO-Modellen lag. Letztlich wurde der Weg von den sauberen betriebswirtschaftlichen Modellen auf der Datenbank hin zur Darstellung in einer Oberfläche in vielen Fällen sogar verworrener und indirekter.
Die Büchse der Pandora
Aus einem betriebswirtschaftlichen Modell waren spätestens durch Objektorientierung also zwei Modelle geworden. Neben die Relationen auf den Datenbanken traten Aggregation und Komposition im objektorientierten Modell. Aus unterschiedlichen Gründen kamen weitere Modelle hinzu, wie zum Beispiel bei Enterprise SOA und den ARIS Modellen von SAP ByD, weiter zu den OData RESTful Services für Fiori. Die Modelle der Enterprise Search sind dabei im hier diskutierten Zusammenhang besonders aufschlussreich, weil sie sehr schön alle Schritte von einem relationalen, betriebswirtschaftlichen Datenbankmodell zu einer Oberfläche in einer „Guided Procedure“ zusammenfassen:
Wie man sieht, ist das Dargestellte inhaltlich nicht weit entfernt von der Modellierung im R/3 im ersten Kapitel. Der Unterschied ergibt sich „nur“ durch die Tatsache, dass zusätzliche Informationen gesammelt werden, die eine automatische Darstellung in einem UI ermöglichen. Doch wie bringt man das alles wieder auf ein gemeinsames Fundament, ohne die zusätzlichen, notwendigen Möglichkeiten und Features aufzugeben?
Die Synthese oder der Zauber von SAP S/4HANA
Im Laufe der Jahre hatte man durch Experimente verstanden, dass es schädlich ist, die betriebswirtschaftlichen Modelle in den Relationen der Datenbank zusätzlich und redundant in objektorientierten Frameworks zu exponieren. Natürlich wusste man ebenfalls mittlerweile, dass Meta-Informationen notwendig wären, um Tools und Oberflächen optimal zu unterstützen. Wie jedoch bringt man das grundlegende betriebswirtschaftliche Modell zusammen mit den Mehrinformationen aus anderen Domänen?
Die Antwort wurde gefunden und befeuert durch eine neue Datenbank der SAP: HANA. Durch die Tatsache, dass diese Datenbank es ermöglicht, für viele, auch komplexere Funktionen auf den Applikationsserver zu verzichten, ist es natürlich, überbordende objektorientierte Frameworks über Bord zu werfen und das reine betriebswirtschaftliche Modell auf Datenbankebene anzureichern mit Informationen für das UI. Und dies ohne eine unübersichtliche Vermengung der Sachbereiche (Betriebswirtschaft, Usability …), wie in den schlechten Beispielen oben zur PFCG.
In Schulungsunterlagen der SAP zum Thema ABAP CDS Views wird das veränderte Paradigma folgendermaßen dargestellt:
SAP stellt dar, dass mit S/4HANA zu einem datenorientierten Ansatz zurückgekehrt wird. Als Interfaces in S/4HANA sind ABAP CDS Views zugelassen. Dies ist ein Vorgehen, welches in Hochzeiten der Objektorientierung vollkommen undenkbar gewesen wäre. Wie wir sehen werden, beherrschen CDS Views auch Vererbung. Daher ist in S/4HANA die Präsentationsschicht oft auf ABAP CDS Consumption Views aufgebaut und ein wesentlicher Vorteil der Objektorientierung lebt weiter auch ohne Modellierung in Klassen. Dies alles zusammengenommen bedeutet, dass die Applikationsserver an Bedeutung verlieren, die Datenbank und der Browser für die Präsentation jedoch deutlich an Gewicht gewinnen. Und es bedeutet auch, dass man direkt am betriebswirtschaftlichen Modell der Daten auch Annotationen für andere Domänen ablegen kann.
Die Dinge reduzieren sich und werden klar – Beispiele und S/4HANA
An einem einfachen Beispiel will ich jetzt zeigen, wie ABAP CDS Views die verschiedenen, auseinanderlaufenden Modelle zusammenbringen und was es heißt, die Betriebswirtschaft mit zusätzlichen Informationen anderer Domänen anzureichern.
Die SAP verwendet dabei den Begriff „Annotation“, der sehr gut beschreibt, was vor sich geht, nämlich die Anreicherung des betriebswirtschaftlichen Modells mit weiteren Informationen, die nichts mit Betriebswirtschaft zu tun haben, sondern mit Dingen wie dem User Interface, OData Services, transaktionalem Verhalten etc.
Das Beispiel ist das allgemein bekannte Flugdatenmodell der SAP:
Es kann in jedem neueren SAP System aufgerufen werden. Einfach im Eclipse Editor CTRL+Shift+A drücken und den Namen des CDS Views „S_Flights“ eingeben. Den Treffer wählen, der eine Datendefinition darstellt, dann öffnet sich die Ansicht oben.
Annotationen sind die blauen Zeilen, die mit @ beginnen. Sie stellen Meta-Informationen und zusätzliche Funktionen bereit. Das betriebswirtschaftliche Modell ist klar über die Assoziationen dargestellt. Aber auch die Informationen, die darüber hinausgehen, können über das @ Zeichen einfließen, ohne die Übersichtlichkeit zu zerstören und die Bereiche unnötig zu vermischen.
Wie mächtig das Konzept ist, zeige ich in diesem Artikel nur beispielhaft. Nehmen wir an, wir wollten die Daten des S_Flight CDS Views als OData Service zugänglich machen. Ob ihr es glaubt oder nicht, es genügt eine Zeile, um das zu erreichen. Fügt man nämlich als vierte Zeile oben die Zeile „@OData.publish: true“ hinzu, wird der View automatisch auch als OData Service zur Verfügung gestellt. Kaum zu glauben, dass jetzt die Betriebswirtschaft direkt in einen Web-Service umgewandelt wurde. Wenn ihr es selbst probieren wollt, müsst ihr den CDS View der SAP natürlich in einen eigenen CDS View einbetten (Vererbung), damit ihr ihn modifikationsfrei verwenden könnt:
Diese wenigen Zeilen genügen und wir haben einen OData Service zum Flugdatenmodell exponiert, in welchem wir auch gleich noch die freien Sitze in Business Class und First Class berechnen. Sehen wir uns das kurz in SAP Gateway Client an und rufen das $metadata File des Service auf, so sehen wir, dass die Assoziationen korrekt im OData Service zur Verfügung stehen. Wir könnten den Assoziationen des Modells im CDS View jetzt mit den RESTful Services von OData folgen.
Wie bereits erwähnt, sind CDS Views so klar und ausdrucksstark, dass S/4HANA in weiten Teilen auf diesen Views aufgebaut ist. Wir haben nur einen kleinen Teil der Möglichkeiten von ABAP CDS Views gesehen. Nach und nach decken annotierte CDS Views jedoch immer mehr Domänen ab, für die früher eigene Objektmodelle und Frameworks geschrieben wurden. Für S/4HANA gibt es sogar ein eigenes Programmiermodell für Fiori Apps, das auf CDS Views und Annotationen aufbaut:
Mittlerweile ist also das Zusammenspiel zwischen betriebswirtschaftlichem Modell und Annotationen so ausgereift, dass man über wenige Annotationen aus dem betriebswirtschaftlichen Modell ein transaktionales UI erzeugen kann.
Der alte Traum, aus dem Wissen über die Betriebswirtschaft die Anwendung automatisch zu generieren, ist damit ein großes Stück realistischer geworden.
Autor: Markus Kupke, Management-Beratung, CONITAS GmbH
Titelbild: bagotaj/iStock