Technology Blogs by SAP
Learn how to extend and personalize SAP applications. Follow the SAP technology blog for insights into SAP BTP, ABAP, SAP Analytics Cloud, SAP HANA, and more.
Showing results for 
Search instead for 
Did you mean: 
Product and Topic Expert
Product and Topic Expert
In the meantime, we’ve grown up to experienced OData service developers.

We know how to create an OData (V4) service which exposes data and creates and manipulates data, we know about the OData specification and how to stick to it when implementing the required code for a nice OData service.

See the overview of tutorials

All the time, we didn’t pay attention to the actual data. Few dummy mock data entries were enough to illustrate the OData behavior and implementation.

Now it is time to expose real data.
(Well, let’s be modest, it is time to expose real “sample data”.)



This blog aims to define the scope of data sources and the different libraries with which we're dealing while developing based on the SAP Cloud Platform SDK for service development.



We assume that some data is there, somewhere on some database, or somewhere on some system. Somewhere accessible via network.

We're assuming that at least during a couple of blogs.

So, the data is somewhere, we create an OData service which is supposed to exposed that data.
As such, we act as some man in the middle: The service-user calls our service, the maninthemiddle calls the somewhere-data, then the maninthemiddle sends that data to the service-user


Below diagram depicts how we’re located in the middle.
The user on the left side is just a user who uses a REST client (or anything else) to call our OData V4 service, which we’re exposing
The SAP Cloud Platform SDK for service provisioning receives the request and processes as much as possible.
Then our implementation code is invoked
Our code is responsible to fetch the desired data, which can be residing on the cloud or anywhere else.
The “Your Code” element represents the maninthemiddle.

Fortunately, there are the data source libraries, providing support for fetching data from specific data sources.
Fetching data is usually called consumption


Clarification on the APIs

So we have one basic distinction between the library which we use for provisioning, and the libraries which we can optionally use for consumption.

Provisioning: SAP Cloud Platform SDK for service provisioning
Consumption: Data Source libraries, SAP S/4HANA Cloud SDK



Obviously, the data sources mentioned here, are not enough to fulfill the needs for every developer.
But at least, for these data sources, some support is there.
The implementation code should be able to fetch the desired data from any other source, using any other libraries

We’re distinguishing between the SDK on the provisioning and Data Sources on the consumption side, which is correct from technical perspective
Delivery-wise, the Data Source APIs are delivered along with the SDK.
Whereas the S/4HANA SDK is delivered separately.


The different working sections

Going a bit more into details, we have to distinguish also different men-in-anywhere



On each level, there might be APIs or even SDKs to help the poor man with his work.

This one represents the end-user who uses a mobile device, or a browser or whatever. The device uses the OData service, which brings us to the next level
Here we really mean the end user, really a real human end user.

Who uses an OData service? It is usually an application running on a mobile device or a browser, like UI5/Fiori .
IN order to programatically call an OData service, there are client libraries, like e.g. the Olingo-client-library for java. But of course, an OData service can be called using any language and technology.
Or it can be a man directly calling the service and reading the json content. In this case, this man uses a REST client to call the OData service. That is what we’re doing along with our tutorials to test our service implementation

Man-exposing Service:
This is where we see ourselves.
And here we have the SAP Cloud Platform SDK for service provisioning

This is us as well.
At least during a couple of blogs.
We know that there’s data and we consume it. But in our case, we don’t consume it in order to visualize it in a UI5-application (e.g.) . Instead, we consume it and in turn we expose it as OData service.
When it comes to consuming data, there are several data source libraries to support this lucky man.
And even if there's no support by any dedicated data source library, the man is free to write his own code whenever he wants to connect to any data source and consume data from there

Well, we don’t care much about this poor working man.
He represents the backend, which can be e.g. an ABAP system with BAPIs etc handling data, but as well can be HANA or anything else which has data to serve.



Below diagram shows the flow:
The End User uses a device or a tool which fires a request on our OData V4 service.
The request is received by the SAP Cloud Platform SDK for service provisioning, which internally uses the Olingo library
The SDK calls our implementation code which programatically makes use of convenience APIs in order to fetch data.
These APIs take care of connecting to the data source and help in fetching the desired data.


More detailed differentiation

Going further into details, let’s have a closer look at each of the consumption use cases.


Use Case 1: OData V2 data source

There’s an OData V2 service somewhere accessible over the network.
This Service exposes data
As such, it can be directly consumed by applications like UI5 or apps on mobile devices
However, a service-developer may want to use exactly that data, but in different context.
As such, that man can go ahead and consume that data and expose it in his OData V4 service

Why would we want to create a service which consumes another service, instead of directly using that other service?
Give different names for properties and entities,
Remove properties
Add different properties with e.g. calculated values
More or less fine granularity
Systematic selection of specific parts of data (e.g. only BusinessPartners who are customers, not suppliers)
Mixing data coming from this service with other data from other data sources

We are service-developers who create an OData V4 service
We write the implementation based on the SAP Cloud Platform SDK for service development
We’re provisioning an OData V4 service
We have data to exposed
That data is available to everybody via an OData V2 service, but it doesn't fully suit our needs
We consume that OData V2 service and modify the structure, such that it fits to our exposure
For consuming the OData V2 service, there’s support available:
We use the data source API which is delivered within the SDK for service provisioning

In the code, it looks like this:



This API helps us e.g. in terms of connectivity, URI handling, request handling, response handling

ODataQueryResult result = ODataQueryBuilder
.withEntity("/V2/OData/OData.svc", "Products")

Example using POJO to receive the result of the call to the OData V2 service:
List<BusinessPartner> businessPartners  = ODataQueryBuilder
.withEntity("/sap/opu/odata/IWBEP/GWSAMPLE_BASIC", "BusinessPartnerSet")



Use Case 2: OData V2 APIs on S4HANA on Demand

There’s an S/4HANA on Demand system
It contains great amount of data.
It offers APIs to consume that data and do anything with it
For example, one could build extension apps for the purpose of the own particular needs, where no existing S4H app is suitable
These APIs can be OData V2 services

In order to programmatically call these OData V2 services, the S4HANA SDK is perfect.
Among other benefits, it offers the Virtual Data Model (VDM), an API of type-safe proxies, which allows to use those OData V2 services in a very convenient way
So easy that you’re not even aware that you’re calling a service.

Now, again, instead of building an application which uses the data which is retrieved using the S4H SDK, we can use that data in order to exposed it in our OData V4 service.
Similar like above.
The difference is that instead of the generic support for calling OData V2 services, here we have specific type-safe support for S/4HANA on Demand backend data

Summarizing the difference between the data source library and the S/4HANA SDK:
Data source library for OData V2 -> helps to call OData V2 services
S4HANA SDK -> helps even more, but specific to OData V2 APIs on S4HANA on Demand


This S/4HANA SDK allows to write code against an API and it is completely transparent that under the hood a service call is executed.
It is greatly convenient.

In the code, it looks like this:


List<BusinessPartner> businessPartners = new DefaultBusinessPartnerService()
.execute(new ErpConfigContext(DESTINATION));




Use Case 3: data source library for CDS

There’s a SAP Cloud Platform account, a SAP HANA database, SAP HANA HDI container, SAP HANA Core Data Services (CDS).
All that is there, including data, and it is known to us.
One could think of firing sql statements on a database in order to fetch the data that should be exposed via the OData service.
However, in case of CDS, the convenience API, the data source API for CDS consumption can be leveraged for easier access.

In the code, it looks like this:

We need a connection to the hdi-container instance
Based on that connection, we can obtain the DataSourceHandler for CDS
This handler supports us in executing operations on the database, like query or insert

CDSDataSourceHandler dsHandler = DataSourceHandlerFactory
.getCDSHandler(getConnection(), namespace);
CDSQuery cdsQuery = new CDSSelectQueryBuilder(fullyQualifiedName)
.orderBy("SalesOrderID", false)
List<EntityData> list = dsHandler.executeQuery(cdsQuery)


Use Case Note

Just for comparison, see here an example for the provisioning library:



Use Case What?

Time to answer the question: when to use which library?

  1. SAP Cloud SDK for service development:
    Create/expose OData services based on the framework

  2. SAP S/4HANA Cloud SDK :
    use this library if your data is stored on S/4 HANA system, and if it is exposed from there via an OData V2 service
    If you wish to create extensions and combine with 1)

  3. Data Source API for OData V2 consumption:
    This library is generic and is able to connect to any OData V2 service.
    It can be used of course to connect to S/4 HANA services as well, as long as they’re exposed as OData V2 service

  4. Data Source API for CDS consumption
    This library is used if you’re using a SAP HANA database and CDS (SAP HANA Core Data Services)



Detailed diagram

Below diagram shows how to reach out from our service-application to the consumed OData services.
As expected, a destination needs to be configured on Cloud Foundry, which contains the host-URL and authentication.
This destination is used by the code of our service-app.
The Data Source libs provide support for that.
When connecting to an on premise system, a SAP Cloud Connector instance is required which is connected to the SAP Cloud Platform Cloud Foundry Environment via the Connectivity Service
The diagram also shows that the Data Source API for V2 consumption can be used to connect to any OData V2 service, may it be in the internet, or on S/4HANA or any OData V2 service exposed via SAP Gateway on any ERP System
Whereas the S/4HANA SDK is used explicitly for S/4HANA systems




After going through this blog, all your confusion about different SDKs and libs should be gone. Forever.

The upcoming blogs will show the usage of data source consumption in detail.

First very simple example based on the OData reference service, showing the API in few lines