Skip to content
Dr. Patrick BitterFebruar 20244 min read

Offizielle Statistiken im Reporting

Nutzung von WEB API für Nachhaltigkeitsberichte

Insbesondere durch die immer detailliertere Nachhaltigkeitsberichterstattung wird die Nutzung externer Datensätze für das Konzernberichtswesen wichtiger. Für diese Datensätze gibt es viele mögliche Quellen. Zum einen gibt es kommerzielle Anbieter, die verschiedene Datensätze via API gegen Bezahlung zugänglich machen, zum anderen gibt es offizielle Stellen, die auch kostenlose Datensätze zur Verfügung stellen. In Deutschland bieten Verschiedene Ämter Statistiken zu ihren jeweiligen Fachgebieten an. Insbesondere das Statistische Bundesamt stellt viele Daten zur Verfügung. Eine Übersicht vieler verfügbarer APIs gibt es unter https://bund.dev/apis. Die Daten können über eine Query an den entsprechenden Host abgerufen werden und werden häufig im JSON-Format ausgeliefert.

Webinterfaces – genereller Aufbau

Ein Webinterface besteht generell aus drei Teilen:
1. Einem Host: In der Regel eine Webseite (z.B. https://www.dashboard-deutschland.de)
2. Ein URI-Pfad: Liefert den Ort des Interfaces (z.B.: „/api/tile/indicators“)
3. Einer Query: Parameter, mit denen das Interface gesteuert wird, werden durch ein „?“
abgesetzt (z.B.: „?ids=tile_1663664545105“)

Insgesamt ergibt sich also für eine einfache Interfaceabfrage:
https://www.dashboard-deutschland.de/api/tile/indicators?ids=tile_1663664545105

Gibt man diese Adresse in einen Browser ein (oder nutzt ein entsprechendes Programm wie z.B. SoapUI) erhält man als Antwort einen JSON-String zurück, der die entsprechenden Daten enthält.

Implementierung in ABAP

Um die API im Code abrufen zu können muss zunächst in der Transaktion SM59 eine Verbindung eingerichtet werden. Dabei ist der Host und ggf. ein Pfad-Präfix zu hinterlegen. Wichtig ist, dass für https-Verbindungen unter „Logon & Security“ im Bereich „Security Options“ die SSL-Funktion auf „Aktiv“ gesetzt wird. Mit einem Klick auf „Connection Test“ kann die Verbindung getestet werden.

Um die Daten in ABAP zu laden, kann eine Instanz der Klasse cl_http_client genutzt werden, die über die Methode create_by_destiantion unter Angabe der angelegten Verbindung erstellt werden kann.

Der passende URI als Kombination aus URI-Pfad und Query kann als String erstellt werden. Die Parameter dazu liefert in der Regel das Framework (z.B. bei der Nutzung einer Custom Entity das Interface if_rap_query_provider, siehe unten). Mit der statischen Methode set_request_uri der Klasse cl_http_utility wird die fertige URI mit dem Request verknüpft.

Nutzt man eine API, die auf REST basiert, kann man als Zwischenschritt noch einen REST-Client aus dem http-Client erzeugen. Mit diesem wird dann der Request ausgeführt.

Im besten Fall erhält man nun den JSON-String der API als Antwort. Ansonsten muss man sich noch um die Fehlerbehandlung kümmern (Return-Code ungleich 200).

Der erhaltene JSON-String kann mithilfe der Klasse /ui5/cl_json_parser in ABAP-Fragmente
umwandeln und im entsprechenden Format zurückgeben.
Achtet man bei der Implementierung des Abrufes auf Wiederverwendbarkeit, kann der so
entwickelte ABAP-Code in allen folgenden Szenarien weiter genutzt werden.

Wiedergabe in Fiori Apps via Custom Entity

Eine Custom Entity kann Daten per ABAP in eine CDS-View Struktur laden. Dafür muss die
entsprechende ABAP-Klasse das Interface if_rap_query_provider implementieren.
Darüber hinaus muss in der Methode if_rap_query_provider~select sichergestellt sein, dass auf die Daten ein Filter, ein TOP, ein LIMIT sowie ein GROUP BY Befehl ausgeführt werden, damit die Custom Entity voll funktionsfähig ist.
In der @ObjectModel Annotation wird im Bereich query der Parameter implementedBy auf den entsprechenden Klassennamen gesetzt:

@ObjectModel: {
           Query: {
               implementedBy: ‘ABAP:ZCL_MYCLASS‘
             }
}

Darüber hinaus können noch Annotationen für den Konsum in einer Fiori App hinterlegt werden. Damit lassen sich z.B. einstellbare Filter oder die Aufteilung der Daten auf mehrere Seiten einstellen.

Um die Daten in einer Fiori App anzeigen zu können, muss eine entsprechende Service Definition mit einem geeigneten Binding erstellt werden. Der Service regelt den Zugriff auf die Custom Entity, während das Binding die Verwendung in Fiori zulässt.

Eine Verwendung der Custom Entity als Datenquelle für einen anderen View, das BW oder eine Abfrage per ABAP ist aktuell (Stand 03.01.2024) leider nicht möglich.

Verwendung in BW

Bei der Anbindung von externen Datensätzen an das BW sollen zwei Szenarien unterschieden werden. Das erste Szenario geht davon aus, dass die Daten in das BW repliziert werden sollen, um sie später im Datenmodell verwenden zu können. Das zweite Szenario unterstellt, dass Transaktionsdaten anderer Herkunft beim Laden in das BW mit entsprechenden Informationen aus externen Datensätzen angereichert werden sollen. Im ersten Fall kann der Datensatz über eine Custom DataSource (basierend auf einem Funktionsbaustein) geladen und an die vorhandene Datenstruktur angebunden werden. Im zweiten Fall können die Funktionen der API in einer Transformation aufgerufen werden.

Custom DataSource

Um eine Kundenspezifische Datenquelle einzurichten muss zunächst eine Struktur (z.B. in der
Transaktion SE11) erstellt werden. Die Feldnamen sollten dabei - wenn möglich - aus der API
übernommen werden. In der generischen DataSource (Transaktion SBIW) kann dann ein
Funktionsbaustein hinterlegt werden, welcher die Daten abruft und in der zuvor angelegten Struktur bereitstellt. Werden Daten über diese Quelle in das BW übertragen, werden der Funktionsbaustein und damit der Code für den API-Abruf ausgeführt.

Aufruf aus einer Transformation

Sollen Transaktionsdaten aus anderen Quellen mit den Informationen einer Web-API angereichert werden, können die entsprechenden Methoden / Funktionen aus einer der drei möglichen Routinen einer Transformation aufgerufen werden. Dabei ist darauf zu achten, dass die Daten in die entsprechende Struktur der Transformation übertragen werden müssen. Außerdem sollte so wenig Code wie möglich direkt in die Transformation geschrieben werden, um eine möglichst hohe Wiederverwendbarkeit zu erreichen. Komplexere Funktionen sind in eigenen Klassen besser aufgehoben. Dort kann auch getestet werden.

VERWANDTE ARTIKEL