In this blog, we will deep dive into CDS views with respect to SAP Cloud Application Programming Model (CAP).

CDS stands for Core Data Services, but what exactly is CDS? CDS is a collection of Domain specific languages, helping developers to entirely focus on specifically on business domain model.

CDS is base of the SAP Cloud Application programming Model.

It provides the means to express service definitions and data models, as well as queries, and expressions, all of this in plain JavaScript object notations. It can parse from a variety of source languages and to compile them into various target languages.

The CDS models are plain JavaScript objects complying to the Core Schema Notation, in short CSN, which is an open specification derived from JSON Schema.

You can easily create or interpret these models, which fosters extensions by third-party contributions. Models are processed dynamically at runtime and can also be created dynamically.

Definition Language

CDL is a human-readable syntax for defining your models. Here are some of the available definitions of this language.

1)      Entities - Entities are structured types representing sets of persisted data that can be read and manipulated using CRUD operations.

2)    Views - Views are entities defined by projection on underlying entities or other views, like the views in SQL.

The element signatures are inferred from the projection. The projection can be any valid query.

3)      Associations -  Associations capture relationships between entities. They are like forward-declared joins added to a table definition in SQL.

4)      Aspects - Aspects help to separate concerns into partial definitions and, in this way, to avoid polluting your structure. They can be declared in the same or different files or even in different projects,

5)      Types -  You can declare custom types to reuse later on for example for elements in entity definitions.

6)      Service Definitions - Service definitions, service interfaces should be defined as collections of exposed entities enclosed in a service block. A service could also have, as members, actions and functions.

Core Scheme Notation(CSN)

The next member of the languages set we will take a look at is the CSN, or Core Schema Notation. It is notation for compact representations of data and service models, of data and service models, to share and interpret models with minimal footprint and dependencies.

It is like JSON Schema but goes beyond it with the ability to capture full- blown, entity-relationship models and extensions. This ability makes CSN models much more concise and closer to your conceptual thinking.

Let us see an example for the same.

On the slide's left-hand side, you can see an entity Books declared in the human-readable definition language, and on the right side, you see the CSN representation.

Both are not lengthy, but still capture all the needed information.

In the next example, on the left CDL snippet, we see a service definition with one unbound action as part of the service. On the right side, the respective CSN representation, an easily processable JSON object.

Query Language (CQL)

The next member of the group of languages is the query language, abbreviated as CQL or CDS QL. CDS QL is based on standard SQL, but upgrades it with some really handy features, like postfix projections, path expressions, CDL-style casts, and some more.

1)      Postfix Projections - CQL allows putting the SELECT clause behind the FROM clause, enclosed in curly braces. We see in the example that the elements list is put behind the "from Books" part of the statement.

In the postfix projections, the star operator queries in the postfix projections, the star operator queries compared to the plain SQL SELECT clauses. Queries like on the example here would result in duplicate element effects for author in SQL, but in CDS QL, explicitly defined columns following the star will replace equally named columns.

2)      Path Expressions -  One should use path expressions to navigate along associations and structured elements in any of the SQL clauses like FROM clauses, SELECT clauses, or WHERE clauses as is shown here in the example.

Path expressions in FROM clauses allow to fetch only those entries from a target entity that are associated to a parent entity. They unfold to semi-joins in plain SQL queries. The path expressions in all other clauses are very much like standard SQL column expressions, with table aliases as single prefixes.

3)      CDL – style casts - As an alternative of the SQL-type casts, you can use CDL-styled casts. This is done as in the element of an entity definition.   

 In this tutorial series, we will focus on learning SAP Cloud Application Programming Model (CAP).

CAP is a framework, that would not only guide developers, but also take away some of the more technical or foundational tasks to help them focus on their business logic. Business logic is the key differentiator for what you are developing.

SAP CAP is both open and opinionated. The programming model is a combination of tools, languages, and libraries that will help you build enterprise-grade services and applications.

The goal is to guide developers and minimize boilerplate content, so they can focus on what's important the business logic.

As you can see in this graphic, we support both open-source and SAP tools and technologies.

Components of CAP

    1) Core Data Services (CDS) is the data modelling infrastructure. CDS is known as the backbone of the programming model, as it provides the means to capture service definitions and data models, queries, and expressions in plain object notations.

    2) Service SDKs - It supports libraries available for both Java and Node.js, which can be used to provide and consume services through synchronous and asynchronous APIs. The SDKs include out-of-the-box integration to lower-level platform services, such as authentication and credential-flows or on and off-boarding of SaaS tenants.

    3) SAP BAS, Fiori Elements, SAP HANA - SAP BAS is the IDE of choice, there is Support for SAP HANA and SAP Fiori Elements.

Design Principles

When it comes to design principles, there is open and opinionated concept.

It's open because it gives you choice. You can choose which technology to use, you can select your architecture pattern, you can pick and choose the parts of the programming model that suit your development needs best. But it's also opinionated, because we provide but it's also opinionated, because we provide for you to follow SAP’s recommended approach.

Zero Lock-In

You can choose any technology of your choice, that there is no locked-in, mandatory path with this programming model. To build your UI, you can use SAP Fiori Elements, or you can use any other alternative technology as well.

Non-Intrusive

The programming model is non-intrusive, i.e. it is completely free of assumptions. Here the main goal here is to reduce boilerplate code, which would be the same regardless of the architecture or methodology you choose.

Platform-Agnostic

You can build applications in a way that is independent from the underlying cloud infrastructure. To achieve this by using an API-first approach that avoids hard wiring to any given technology.

Let’s understand with an example Hello World application using CDS and node.js using SAP BAS as IDE.

I hope you are well versed with the basics of SAP BAS. If you aren’t, please check my previous blog on introduction to SAP BAS and setting up.

Introduction to SAP BAS

Setting up SAP BAS

This is the home page of SAP BAS.

Now lets define a service in the srv folder and name it as say.cds

Now, we need to implement the service. To do so, we create another file say.js.

Now, go to the terminal and we can run our little hello world application.

So using cds run, we should get a running service.

We can edit the url to run our hello world request. 

 

And we'll see the value returned as "Hello world".So I hope you learned how to build a small HelloWorld application using CDS and node.js on SAP BAS. In the coming blogs, we will explore more about CDS and SAP CAP.