The use of external data sets for Group reporting is becoming more important, particularly as a result of increasingly detailed sustainability reporting. There are many possible sources for these data sets. On the one hand, there are commercial providers who make various data sets available via API for a fee, and on the other hand, there are official bodies that also provide data sets free of charge. In Germany, various authorities offer statistics on their respective subject areas. The Federal Statistical Office in particular provides a lot of data. An overview of many available APIs can be found at https://bund.dev/apis. The data can be retrieved via a query to the corresponding host and is often delivered in JSON format.
A web interface generally consists of three parts:
1. a host: usually a website (e.g. https://www. dashboard-deutschland.de)
2. a URI path: Provides the location of the interface (e.g.: "/api/tile/indicators")
3. a query: Parameters with which the interface is controlled are separated by a "?"
(e.g.: "?ids=tile_1663664545105")
All in all, this results in a simple interface query:
https://www.dashboard-deutschland.de/api/tile/indicators?ids=tile_1663664545105
If you enter this address in a browser (or use a corresponding program such as SoapUI), the response is a JSON string containing the corresponding data.
To be able to call the API in the code, a connection must first be set up in transaction SM59. The host and, if necessary, a path prefix must be stored. It is important that the SSL function is set to "Active" for https connections under "Logon & Security" in the "Security Options" area. The connection can be tested by clicking on "Connection Test".
To load the data into ABAP, an instance of the cl_http_client class can be used, which can be created via the create_by_destiantion method by specifying the created connection.
The appropriate URI as a combination of URI path and query can be created as a string. The parameters for this are usually provided by the framework (e.g. when using a custom entity, the interface if_rap_query_provider, see below). The static method set_request_uri of the cl_http_utility class is used to link the finished URI to the request.
If you use an API that is based on REST, you can create a REST client from the http client as an intermediate step. This is then used to execute the request.
In the best case scenario, you will now receive the JSON string from the API as a response. Otherwise, you still need to take care of error handling (return code not equal to 200).
The JSON string received can be converted into ABAP fragments using the class /ui5/cl_json_parser
and return them in the appropriate format.
If you pay attention to reusability when implementing the call, the ABAP code developed in this way can be used in all subsequent scenarios.
developed ABAP code can be used in all subsequent scenarios.
A custom entity can load data into a CDS view structure via ABAP. To do this, the
corresponding ABAP class must implement the interface if_rap_query_provider.
In addition, the if_rap_query_provider~select method must ensure that a filter, a TOP, a LIMIT and a GROUP BY command are executed on the data so that the custom entity is fully functional.
In the @ObjectModel annotation, the implementedBy parameter is set to the corresponding class name in the query area:
@ObjectModel: {
Query: {
implementedBy: 'ABAP:ZCL_MYCLASS'
}
}
In addition, annotations can be stored for consumption in a Fiori app. This can be used, for example, to set adjustable filters or split the data across several pages.
To be able to display the data in a Fiori app, a corresponding service definition with a suitable binding must be created. The service controls access to the custom entity, while the binding allows it to be used in Fiori.
Using the custom entity as a data source for another view, the BW or a query via ABAP is currently (as of 03.01.2024) unfortunately not possible.
A distinction should be made between two scenarios when connecting external data records to BW. The first scenario assumes that the data is to be replicated in BW so that it can be used later in the data model. The second scenario assumes that transaction data from other sources is to be enriched with corresponding information from external data records when it is loaded into BW. In the first case, the data record can be loaded via a custom DataSource (based on a function module) and linked to the existing data structure. In the second case, the API functions can be called in a transformation.
To set up a customer-specific data source, a structure must first be created (e.g. in the
transaction SE11) must first be created. The field names should - if possible - be taken from the API
if possible. In the generic DataSource (transaction SBIW), a function module can then be
function module can then be stored in the generic DataSource (transaction SBIW), which retrieves the data and makes it available in the previously created structure. If data is transferred to BW via this source, the function module and therefore the code for the API call are executed.
If transaction data from other sources is to be enriched with information from a web API, the corresponding methods / functions can be called from one of the three possible routines of a transformation. It should be noted that the data must be transferred to the corresponding structure of the transformation. In addition, as little code as possible should be written directly into the transformation in order to achieve the highest possible reusability. More complex functions are better placed in separate classes. They can also be tested there.