Ein zentrales Thema in der ABAP RESTful Application Programming Model (RAP) Entwicklung ist die Frage, wie Abfragen für OData-Services umgesetzt werden sollen. Dabei stehen zwei Ansätze im Vordergrund: die reine CDS-Managed Query mit define view und die Custom Query auf Basis einer Klasse, die das Interface IF_RAP_QUERY_PROVIDER implementiert. Beide Varianten nutzen denselben End-to-End-Prozess von OData-Request bis zur Datenquelle, unterscheiden sich aber im Detail.
Bei der klassischen Managed Query beginnt der Datenfluss mit dem OData-Request. Dieser wird von der RAP-Fassade entgegengenommen und an das SADL-Framework übergeben. SADL ist dafür verantwortlich, die OData-Operationen wie $filter, $orderby oder $top in SQL zu übersetzen. Die CDS-View selbst ist der zentrale Dreh- und Angelpunkt: Sie definiert die Datenquelle, die zugehörigen Felder und über Annotationen auch Such- oder Autorisierungslogik. Die Daten werden schließlich per Open SQL von der Datenbank gelesen. Der Entwickler muss hierbei kaum eigenen Code schreiben, sondern arbeitet deklarativ mit CDS und Annotationen. Sicherheit über DCL-Regeln und optimale Performance durch Push-Down sind integraler Bestandteil.
Im Gegensatz dazu läuft die Verarbeitung bei einer Managed Custom Query über eine explizite Implementierung. Auch hier startet der Request bei OData und RAP, landet dann jedoch nicht direkt in SADL, sondern im Query-Provider. Dieser ist eine ABAP-Klasse, die das Interface IF_RAP_QUERY_PROVIDER implementiert. Der Entwickler erhält dadurch die volle Kontrolle über den Zugriff: Filter, Paging, Sortierung und Zählung müssen selbst implementiert werden. Statt sich auf eine einzelne CDS-View zu stützen, können beliebige Datenquellen angebunden werden – klassische Tabellen, mehrere CDS-Views, Funktionsbausteine oder sogar externe Services. Autorisierungslogik muss hier eigenständig berücksichtigt werden. Die Flexibilität ist hoch, gleichzeitig steigt aber auch die Verantwortung für korrekte Implementierung und Performance.
Der Unterschied zwischen den beiden Ansätzen liegt also im Grad der Steuerung und Automatisierung. Mit einer CDS-Managed Query erhält man out-of-the-box eine stabile, performante Lösung, die sich vor allem für klassische Entitäten mit klarer Datenbankgrundlage eignet. Eine Custom Query hingegen ist die richtige Wahl, wenn Anforderungen über das hinausgehen, was SADL und CDS leisten können, etwa bei dynamischen Feldern, Mehrquellen-Szenarien oder spezieller Filter- und Aggregationslogik. In diesem Fall wird der Entwickler jedoch zum aktiven Architekten der gesamten Abfragekette.
Der Datenfluss von OData über RAP, SADL, CDS bis zur Datenbank ist in beiden Fällen klar strukturiert, unterscheidet sich jedoch in der Frage, ob die Verarbeitung deklarativ durch CDS-Definitionen oder programmatisch über eine ABAP-Implementierung erfolgt. Während die Managed Query mit CDS auf maximale Einfachheit und Push-Down setzt, erlaubt die Custom Query über IF_RAP_QUERY_PROVIDER größtmögliche Flexibilität. Welcher Ansatz gewählt wird, hängt direkt von den funktionalen und technischen Anforderungen des Projekts ab.
ABAP Core Data Services (CDS) sind eine moderne Möglichkeit in SAP ABAP, Datenbankabfragen und Datenmodelle zu definieren.
Sie sind ein semantisches Schichtmodell auf der Datenbank, mit dem man Daten deklarativ beschreibt, statt rein prozedural in ABAP zu programmieren.