Skip to Content
Technical Articles

SAP Cloud Platform Backend service: Tutorial [1.1]: Explaining CDS model

Dear friends of Backend service, welcome back to our tutorial series
You’ve successfully gone through the tutorial blog 1 easy API creation, haven’t you?
Yes, but ohhh…
You are somehow not fully satisfied ?
I guess I know why: you’re missing the explanations of what you were doing
Please read on, here comes an attempt to make you more happy


What is it, the CDS model?

CDS stands for Core Data and Services
How do I know that?
I’ve looked it up in the documentation
thanks, but that doesn’t help me

The CDS definition language allows to define models
Going further, CDS allows to define models in 3 aspects:

– Define data model
– Service definition
– Attach user interface information

We will completely ignore the third aspect here
Both other aspects, data model and service definition, were used in the tutorial sample

Let’s have a closer look


What about the data model?

Data model means we want to store data in a structured way.
In Backend service, a database is used, but you don’t really need to care about it.
I just think it is helpful to have a concrete idea of what we are doing.

In the data-model-part of our CDS file we say how we want to persist data in a database.
In our sample, we say that we want a “Products” – entity with properties “Name” and “Category” and “ProductId”

entity Products {
  key ProductId : Integer; 
  Name : String;
  Category : String;

With other words, we say that we want a database table (“Products”) with several columns (“Name”, Category, etc)

ProductId Name Category
1 Ergonomic Easy Trac Mice

With other words, we say that we want to execute an SQL statement like

CREATE TABLE Products (ProductId int, Name varchar(255), …);


OK, I understand, I need to learn CDS language, such that I will be able to describe the data model which I need for my application. The Backend service takes care of generating the database tables and filling the data into it.

Yes, I see you’re seriously following.
BTW, the Backend service does much more for you, in terms of maintaining the data and operating the database for you. But that’s a larger topic than what we’re discussing here.

Sounds promising.


What about the service definition?

CDS not only allows to describe a data model. It also allows to define services.
And it really means “services”, in the sense of REST services.
More concrete: In your CDS file you define a “service” element and as a result you get an OData service which you can use to read and create the data in the database.

In the service-definition-part of our CDS file, we say that we want data to be exposed as a service

In our sample, we say that we want a service to be generated with name “MyFirstService”, and moreover, we define which data should be exposed

service MyFirstService{
   . . .

The data to be exposed can refer to an existing data model.
Or, alternatively, it can be defined directly in the body of the service, that’s what we did in our sample in our tutorial.

With other words, while defining a “service” in CDS, we say that we want an OData service.
This OData service itself declares metadata containing
“Products” Entity Type
with Properties
and “Products” Entity Set
and “MyFirstService”-namespace
and other OData elements.

The metadata document of the OData service which we created in our tutorial [1] looks like this:

huh… it looks very similar to the CDS

Thank you for this comment, yes, indeed, CDS and HANA and SQL and OData are like brothers and sisters of the same family…


What about the third aspect?

We wanted ignore this one…
Just short summary:
CDS allows to attach UI annotations to every model element. The annotations can then be interpreted to generate user interfaces.
For example, a property can be declared (with annotation) to be used as phone number, such that in the user interface it can be represented with a phone icon and dialer
But we wanted to ignore this feature.



Why these 3 aspects?

The goal is to have one common and generic definition file which is fully protocol and database agnostic.
Like that, you can describe your application irrelevant of how the persistence would be realized.

Concrete: In a subsequent step, the CDS file is translated into the target formats.
In our case, roughly speaking, the database and the OData metadata (edmx)

Example: In your CDS, you define a service, but as you can see at the end, there’s no distinction between the version of OData (OData V2 or V4)


What else is happening under the hood?

Oh, let’s leave this for a future discussion
For the moment, I think it is enough to know that under the hood, the CDS model is parsed and transformed into artifacts which are then served to the infrastructure which is even more under the hood (like database, OData service runtime)


I’m confused, can you please summarize? 

We need to create a CDS file which defines a data model and a service.
Then we pass it to the Backend service
The Backend service reads this input and:

– based on the data model, it generates database tables, to store the data in a database
– based on the service definition, it generates an OData service, allowing standardized access to the data via internet

The Backend service provides you with access to the generated API (which is the OData service)


Why CDS at all? 

The Backend service wants to make life easy for you, so you don’t need to handle database and scaling and service implementation and all that stuff.
The intention is to allow the user to model the data in a human readable way.
As such, the input for Backend service is a model definition file.
Currently, 3 formats are supported

OpenAPI is a widely adopted standard, so it is good that it can be used.
EDMX is anyways used to define OData metadata
CDS, yeah, CDS is the best, because it is the most powerful.
You can attach meta-information to the data model definition and it will be automatically supported

Please refer to the overview page to see more CDS Tutorials with detailed examples


How to learn more about CDS?

Of course, following my blogs
More serous answer: the official SAP documentation


Do you still have questions?
I know you won’t hesitate to send me messages with questions and I will try to add answers to this blog posting



You must be Logged on to comment or reply to a post.
  • Great stuff Carlos Roggan , much needed for everyone working with CDS. I must admit when i started with CDS i was super confused and have to struggle a lot to have the better understanding. You blog series will help every CDS enthusiast in understanding the concepts in details.

    • Hi Carlos, Reading your blogs i realised here you calling API which you created in backend-service in SAP cloud cockpit. Please tell me is there any way where i Can write a node.js application which will call my data from backend which i exposed via a communication arrangement in my S4 system? Please reply if any more clarification needed. Thanks in advance ?



      I Posted in community also 


      • Hello Swastik Mukherjee ,
        Thanks very much for reading my Blogs, and for reaching the end and for writing a comment 😉
        Your Question isn't related to the blog Topic at all, so I'd like to ask you to send me a personal message, Maybe I can help a bit.
        Nevertheless, I'm Pretty sure that the SDK Folks are going to answer your Question very soon.
        Cheers, Carlos

    • Hello Mariam Id-Manssour Thanks very much for the feedback!
      I will give an example for the Fiori-annotations once they will be supported by Backendservice.
      In the meantime, you can go ahead with CAP application and use them.
      The annotations themselves: There are no specific CDS annotations for UI. Here we're talking about Fiori Elements, UI is described by annotations. For instance, you have a property and you declare that whenever it is displayed in a UI, the label for it will be "First Name". Such a "label" annotation is part of Fiori Elements, not CDzS. As such, in CDS you can just use the FE annotation. As such, there's no specific CDS documentation to be expected.
      You have to google for Fiori Elements docu and Blogs, you'll find them here in the Community
      Kind Regards,


      • Hi Carlos ,

        Thank you for your response .

        I followed the course from openSAp “Building Applications with SAP Cloud Application Programming Model” to build the back-end OData service using SAP Cloud Business Application Studio .

        Now I want to use the Fiori elements templates to Speed up development and build the front end of my app and bind it to my Odata  back-end service that I already created and deployed to SCP CF environment.

        I’m wondering how can I create my Fiori app project within my previous SAP Cloud Platform Business Application Project (srv db folder etc ..) and establish the data connection between my Odata service back-end and the Fiori app front-end .

        I tried to set destination in SCP using the URL of my OData service like is mentioned in those tutorials below using Northwind or ES5  OData service  but it’s not working is no such service “destination” in the drop down list.

        -using SAP WEB IDE ( step 4)

        -Using SAP Business Application Studio ( step 3  point number 8 ):

        So How can I create Fiori elements app from template wizard and point to the “Srv” folder with in workspace for services while using the Fiori create from template wizard ?

        Should I use SAP WEB IDE or SAP Business Application Studio to develop my front end ?


        I checked the official documentation on serving UIs:

        it was mentioned that for adding fiori apps to CAP model project i have to copy the the fiori apps folder from sap/samples project on github as a template and modify the content as appropriate. But it doesn’t work properly .

        I will greatly appreciate your help .

        Any pointers/ suggestions/ links would be helpful.

        Thank you .