In dem vorherigen Teil der Blog-Serie habe ich über den technologischen Wandel auf der Hardware- und Software-Ebene im SAP-Umfeld erzählt und erläutert, was für einen Einfluss er auf die Entwicklung der OData-Services hat. In diesem Teil möchte ich in die technische Detail gehen und erklären, wie man anhand CDS-Views einen oData-Service erstellt.

Die Core Data Services gliedern die Datenbanktabellen als VDMs (Virtual Data Model) ein. Dadurch strukturiert man die Daten als logische Einheiten aus einer geschäftlichen Perspektive. Das liefert einen konsistenten Datenmodel und hilft uns einen Überblick auf die Daten zu schaffen. Die VDMs basieren auf 4 Schichten:

• Datenbanktabellen (1.Schicht)
• Basic Interface Views (2.Schicht)
• Composite Interface Views (3.Schicht)
• Consumption Views (4.Schicht)

In diesem Blog-Eintrag konzentrieren wir uns auf den obersten Schicht des VDMs, da die oData-Services in den Consumption Views bereitgestellt werden.

Consumption Views:

Consumption-Views werden auf die Composite Interface Views gebaut und bilden den obersten Schicht des VDMs. Im Gegensatz zu Basic und Composite Views sind die Consumption Views für Wiederverwendung nicht geeignet. Sie sind erstellt, um die benötigten Daten für eine Anwendung oder ein System bereitzustellen. Es gibt 3 Arten von Consumption Views:

• transkationale Consumption View
• analytische Consumption Views (CUBE)
• Web Service API für remote APIs

Um Eine Consumption View als oData-Service freizugegeben, öffnet man zuerst im ABAP Deveopement Tools die relevante DDL-Source. In der DDL-Source fügt man vor DEFINE die Annotation „@OData.publish: true“ hinzu:

Wenn DDL-Source aktiviert wird, schickt ADT eine Aktivierungsanfrage an SADL-Framework und generiert SADL-Framework die benötigten SAP Gateway Artefakte für die Aktivierung des oData-Services.

Ab diesem Punkt kann man wie gewöhnt  den oData-Service in der Transaktion /IWFND/MAINT_SERVICE aktivieren.