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.
cancel
Showing results for 
Search instead for 
Did you mean: 
CarlosRoggan
Product and Topic Expert
Product and Topic Expert
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 ?
ehmmm
I guess I know why: you’re missing the explanations of what you were doing
bingo!
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)



















Products
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.
Correct?

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.

OK

 

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
Hihi
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

 

 
10 Comments