CDS views in SAP Cloud Application Programming Model (CAP)

 

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.   

4) Excluding clause - To exclude elements from your SELECT list, the excluding clauses come to help. Combined with the SELECT star of all elements, it gives the chance to get rid of the elements listed in the curly braces.

5) Query – local mixins – It is used to logically add elements to the source of your query. Later on, those elements can be used and propagated in the query's projection.


In our previous blog, we saw how to create a hello world project using CDS and node.js in SAP BAS.

Previous
Next Post »