30. Juli 2021

OData V2 vs. OData V4 – Welches Model eignet sich für Ihre Anwendung?

Wenn Sie die Einrichtung eines OData Services planen, gilt es einige Aspekte für die Wahl des richtigen Models zu beachten. Um den optimalen Service für Ihre Anwendung zu finden, sollten Sie die Unterschiede und Vorteile der verschiedenen Versionen kennen. In diesem Artikel erfahren Sie, worin sich das neue V4 Model grundlegend von dem V2 unterscheidet und für welche Anwendungsfälle sich die Models eignen.

Was ist OData und wozu wird es eingesetzt?

Der OData Service stellt eine API-Schnittstelle dar, die Sie zur Kommunikation unterschiedlicher Systeme verwenden können. Der Service basiert auf den REST (Representational State Transfer)-Prinzipien “Client Server”, “Zustandslosigkeit”, “Caching”, “einheitliche Schnittstelle”, “mehrschichtige Systeme” und “Code on Demand”.

Somit können Sie über die HTTP-Anfragen GET, PUT, POST und DELETE auf Daten zugreifen.

Das OData Model bildet das Datenmodell des OData Services ab. Einzelne Bestandteile eines Models stellen auf Geschäftsebene logisch zusammenhängende Daten dar, für die die einzelnen HTTP-Anfragen ausgeführt werden können. Im Laufe der Zeit hat sich das Model weiterentwickelt. SAP unterstützt die Versionen V2 und V4. V4 wurde bereits 2014 veröffentlicht und in den letzten Jahren stark weiterentwickelt.

Unterschiede zwischen OData V2 und V4

Bereits vor der Implementierung des OData Services sollten Sie sich auf eine Version festgelegen, da sich die verschiedenen Versionen in einigen Bestandteilen unterscheiden und somit nicht synonym genutzt werden können.

OData V2 ist der ältere, langjährig etablierte Standard und wird in vielen Projekten eingesetzt. DasV2-Model ermöglicht Ihnen viele Funktionen, mit denen Sie die Basis-Operationen abdecken können. Dazu zählen unter anderem Features wie:

CRUD-Operationen mit Bezug zu Entitäten oder Entitätsmengen des OData Models
Batch Requests für die zeitgleiche Verarbeitung ganzer Datenmengen
Clientseitige Filterung und Sortierung
Cache der Daten im Model für schnelle Zugriffe
Automatisches Message Handling
Datenausgabe im JSON oder XML-Format

In OData V4 wird dagegen mit Hilfe einer leistungsfähigeren Abfragesprache, einem optimierten JSON –Protokoll, und einer Änderung des Metadaten-Konzepts die Datenmengen reduziert. Das OData V4 Model ist die neuere Version des etablierten Standardprotokolls zur Kommunikation unterschiedlicher Systeme und wird von SAP unterstützt. Viele Funktionen wurden ersetzt oder als deprecated (veraltet) markiert, sodass sich diese in einer Art “Wartungsmodus” befinden und keine weiteren Änderungen vorgenommen werden.

Datenausgabe bei OData V4

Eine dieser Funktionen ist bspw. der Support des XML-Formats. Die Auswahl zwischen dem XML- und JSON-Format ist in V4 nicht mehr möglich. Stattdessen wurde das JSON-Format weiter optimiert. Das neue JSON-Format bietet ein schlankeres Protokoll, sodass die Response lediglich aus einer Zeile für die Metadaten und dem eigentlichen Payload in Form von Namen-Werte-Paaren besteht. Außerdem werden die Datentypen im Gegensatz zu OData V2 entsprechend typisiert übertragen, sodass Zahlenwerte nicht länger als Strings übergeben werden.

Abbildung 1: JSON-Format

Lazy Loading

OData V4 verfolgt den Lazy-Loading-Ansatz, sodass beim Start einer Anwendung anstelle des gesamten Datenmodells lediglich die notwendigen Ressourcen geladen werden. Die einzelnen Teile des Servicemodells werden je nach Bedarf nachgeladen, sodass die Ladezeit deutlich kürzer ausfällt. Aus diesem Grund werden Methoden wie getData oder getObject nicht länger unterstützt, da sie mit synchroner Datenübertragung arbeiten, bei der die Daten direkt vom Server geladen werden müssen.

Da nicht bekannt ist, ob die Daten bereits vorliegen, ist ein synchroner Zugriff oftmals unpraktisch. Stattdessen bietet OData V4 eine Context API für den synchronen als auch asynchronen Zugriff auf Daten eines spezifischen Contexts an. Auch die CRUD-Methoden des Models (create, read, remove, update) werden nicht länger unterstützt. Stattdessen wird der Datenzugriff implizit über das Binding realisiert. Änderungen sind somit immer an Controls gebunden.

Abfrageoptionen

Die Möglichkeiten der Datenabfragen sind in OData V4 flexibler gestaltet und breiter aufgestellt – sowohl Lambda Ausdrücke (Funktionsschreibweise) als auch verschiedene System Query Options werden unterstützt. Mit der System Query Option $expand können bspw. Nested Filter umgesetzt werden.

Eine beispielhafte Abfrage könnte folgendermaßen aussehen:

Abbildung 2: Abfrage

Bei dieser Abfrage wird die Menge der Maschinen und die Menge der Schäden gemappt. Durch den Filterparameter der Erweiterung wird die Menge der Maschinen ausgegeben, die diesem entsprechen, sodass die Menge der Maschinen ausgegeben wird, die einen Motorschaden gehabt haben. Mit dem OData V2 Service wäre diese Abfrage deutlich komplizierter. Die Erweiterung mit $expand lässt viele weitere Queries zu. Beispielweise können Sie mit $select die konkreten Properties abfragen und mit $orderby eine sortierte Datenrückgabe schaffen.

Einige Datentypen des OData V2 Models können Sie weiterverwenden. Dazu zählen:

Binary
Boolean
Byte
Decimal
Double
Guid
Int16
Int32
Int64
Sbyte
String

Welche Datentypen nun anders genutzt werden, ersetzt werden oder neu hinzugekommen sind, ist in der folgenden Tabelle zu sehen.

V2	V4
DateTime	DateTimeOffset
Time	TimeOfDay
–	Date
Float	–

Das V4 Model weist aus technischer Sicht einige Unterscheide auf. Das Aufsetzen der Entitäten können Sie einfach über Annotationen in CDS Views steuern. In OData V2 wird die Implementierung in der Regel in der Transaktion SEGW durchgeführt. Es ist zwar seit NetWeaver 750 möglich, die Implementierung des OData V4 Services ebenfalls in der SEGW durchzuführen. Diese Vorgehensweise wird jedoch nicht mehr empfohlen.

Functions & Actions

Als weitere Ergänzung gibt es in OData V4 “Functions & Actions”. “Functions” beschreiben lesende Zugriffe, während “Actions” schreibende Zugriffe meinen. Diese Operationen ermöglichen es Ihnen, neben den entitätsbezogenen CRUD-Operationen, die ebenfalls in OData V2 abgebildet werden können, weitere Funktionen zu implementieren. In der View können Sie die Funktionen ähnlich wie entitätsbezogene Datenabfragen einbinden.

Fazit

Zusammenfassend zeigt sich, dass Sie die grundlegende Kommunikation in Standardanwendungsfällen mit der V2 Version abbilden können. Das OData V4 Model bietet Ihnen einige neue, sinnvolle Funktionen, die Ihren OData Service sowohl performanter als auch leistungsfähiger machen. Auch zukunftsweisende Technologien der SAP wie Fiori Elements unterstützen mittlerweile OData V4.

Derzeit setzen viele Unternehmen noch auf den OData V2 Service, da zu diesem mehr Erfahrungswerte existieren. Da die V4 Version stark von der V2 Version abweicht, wird von der SAP empfohlen, vor der Nutzung zu überprüfen, ob die V4 Version für Ihren speziellen Anwendungsfall geeignet ist. Für eine individuelle Beratung vereinbaren Sie hier gerne einen Termin für einen Workshop mit uns.

OData V2 vs. OData V4

Sollten Sie an einer bestimmten Stelle nicht weiter wissen oder Fragen zum Thema haben, dann vereinbaren Sie einfach eine kostenlose Websession und wir besprechen Ihre Herausforderungen und Möglichkeiten.