Preface – This post is part of the SAP CAPM series.
Introduction
A Domain Model in SAP CAP is a model which describes the static, data-related aspects of a problem domain in terms of entity-relationship models. In this article we will study the Domain Modelling in SAP CAP in detail.
Domain Modelling
In simple words, a CDS in SAP CAP produces domain model in such a way that it defines the business problem in terms of keys, fields and annotations. The code to generate a domain model is written in a CDS schema (db/schema.cds). These domain models can be used in Service Definitions, Persistence Models, Databases or even reused within another domain model.
Sample Example:
Namespace empInfo;
using {Currency, managed} from '@sap/cds/common';
entity Employees: managed {
key ID: Integer;
firstName: localized String (111);
lastName: localized String (1111);
manager: Association to Managers;
dateofJoining: Integer;
salary: Decimal (9,2);
currency: Currency;
}
In this example we have created a file schema.cds where we have created an entity Employees which includes basic details of an Employee
This whole schema has been given a namespace i.e. empInfo
This schema uses a standard data type i.e. Currency. Using the standard data type like this helps us to bring all the predefined value helps related to it.
We use CDS to create a Model. In that CDS, we use
- Entities to represent set of unique objects e.g.:
- Employee Basic Information
- Employee Communication Information
- Employee Salary Information
- Associations to define relationships
- Manager association to another entity Manager which will have all the Managers list
Naming Convention & Recommendations
- The name of entity should start with a capital letter and it should be human readable and self-explanatory – for example, Employees
- Start elements with a lowercase letter – for example, firstName
- It is recommended to use plural form of entities – for example, Employees
- It is recommended to use singular form of types – for example, Currency
- don’t repeat contexts – for example, Employees.name instead of Employees.EmployeeName
- prefer one-word names – for example, salary instead of salaryAmount
- use ID for technical primary keys – for example, ID for Employee ID
- You can use Namespace to make your entities unique. It is like client concept in SAP where you can have duplicate schemas (cds files) with unique Namespace to differentiate them. Namespaces are optional, use namespaces if your models might be reused in other projects. At the end of the day they’re just prefixes, which are automatically applied to all relevant names in a file. – for example,
namespace laptop;entity Dell {}
..… is equivalent to:
entity laptop.Dell {}
- You can use contexts for nested namespace sections. – for example,
namespace laptop;entity Dell {} //> laptop.Dellcontext Apple { entity MacBookPro {} //> laptop.Apple.MacBookPro entity MacBookAir {} }
Entities
Entities are like tables with primary keys. We can perform CRUD operation using these Entities. Keep it as flat as possible. Do not over Normalize it. Do not use non-reusable types. This section is only for modelling, only annotation related to individual fields should be added and no technical details (logics) should be added.
Types
Types are like Domain in SAP ABAP, it used to define the typed of Data elements.
Aspects
Aspects are the extensions of the Models and are mainly used to extend the existing definitions and annotations. Once a model is defined, we can use different cds files (Aspect) to add annotations on top of them for specific task.
For example-
- cds– your core domain model, kept clean, simple and understandable
- audit-model.cds– adds additional fields required for auditing in a file
- auth-model.cds– adds annotations for authorization.
Primary Keys
Like tables & CDS in SAP ABAP, we maintain Primary keys for Entity using keyword key.
A primary key can be reused across the model by using the methodology of common definitions.
We can create a common.cds Model where all the common definitions can be stored.
// common definitions
entity StandardEntity {
key ID : UUID;
}
Now these common definitions can be reused as below:
using { StandardEntity } from './common';
entity Employee : StandardEntity {
name : String;
...
}
entity Manager : StandardEntity {
name : String;
...
}
The common file is already created by default with a predefined entity named cuid.
Mapping UUIDs to OData
CDS maps UUIDs to Edm.Guid, by default, in all of the OData models. However, the OData standard puts up restrictive rules for Edm.Guid values – for example, only hyphenated strings are allowed – which may conflict with existing data. Therefore, we allow the default mapping to be overridden as follows:
entity Books {
key ID : UUID @odata.Type:’Edm.String’;
…
}
If necessary, you can also add the annotation @odata.MaxLength to override the corresponding property, too.
Association
It is used to define relationship between two entities. Like ABAP CDS, here too we use the word Association. Here, the keyword many indicates a 0..* cardinality. The restrictions for cardinality can be added as a constraint (where condition) – for example, using not null.
Compositions
Unlike Association where we associate a field of entity with the objects of an entire entity, the compositions just refer to specific field of another entity. It has extra advantage of self-managed deep operations(Insert/Update) and cascaded deletion(Multi Dependent table deletion).
// Define Orders with contained OrderItemsentity Orders { key ID : UUID; Items : Composition of many Order_Items on Items.parent=$self;}entity Order_Items { // shall be accessed through Orders only key parent : Association to Orders; key book : Association to Books; quantity : Integer;}
Best Practises
- Don’t add technical details in Models, we use Aspectsfor that
- Use short names and simple flat models
- Don’t over Normalize the entities in Models
- Use local integer sequences if you really deal with high loads and volumes. Otherwise, prefer UUIDs
Till now what we have learned: Creation of Model and Aspects on top of it .
