“modeling application data” table of contents index the ... · 202 6 modeling application data...

Browse the BookIn this chapter, you’ll learn how essential application data is mo-deled, using SAP S/4HANA as an example. You’ll see how to put together key pieces of metadata, including field labels, foreign key relations, text relations, and more.

Renzo Colle, Ralf Dentzer, and Jan Hrastnik

Core Data Services for ABAP490 Pages, 2019, $79.95 ISBN 978-1-4932-1798-4

www.sap-press.com/4822

First-hand knowledge.

“Modeling Application Data”

Table of Contents

Index

The Authors

https://www.sap-press.com/core-data-services-for-abap_4822/?utm_source=AWS&utm_medium=readingsample&utm_campaign=Browse%20the%20Book&utm_content=1798

199

6

Chapter 6

Modeling Application Data

Core data services (CDS) support modeling of semantic properties of

application data that far exceed the capabilities of traditional database

views. Together with a modern technical infrastructure, this simplifies the

development of new applications.

In previous chapters, you’ve learned how to define CDS views and use them

in ABAP programs. With that knowledge, you can execute SQL mass opera-

tions and complex calculations directly in SAP HANA and benefit from SAP

HANA’s processing capabilities for large data sets. Moreover, you can con-

veniently formulate your requests with associations and their path nota-

tion. With this approach, you’re still within the scope of the classical

programming model for applications where you must repeatedly imple-

ment many details anew via individual programming.

However, new infrastructure components in the SAP NetWeaver Applica-

tion Server for ABAP (SAP NetWeaver AS for ABAP) and semantic metadata

of CDS views enable a new programming model, in which individual pro-

gramming is reduced to a minimum. Instead, error-prone recurring pro-

gramming tasks are handled generically by the infrastructure and controlled

by business-motivated semantic annotations of CDS views.

Chapter structureSection 6.1 gives a short overview of the application architecture and the

programming model in SAP S/4HANA. The following sections present sev-

eral types of meta information for application data that are evaluated by the

new application infrastructure. They cover the following aspects:

� Field labels (Section 6.2)

� Field properties, such as quantities and amounts, aggregation behavior,

system times, and texts in natural language (Section 6.3)

� Foreign key relations (Section 6.4)

� Text relations (Section 6.5)

� Composition relations (Section 6.6)

200

6 Modeling Application Data

� Time-dependent data (Section 6.7)

� Hierarchical data (Section 6.8)

Later in this book, we’ll discuss analytical and transactional applications

(Chapter 8 and Chapter 9, respectively) in more detail and present further

powerful metadata for CDS views that control their processing by the infra-

structure.

6.1 Application Architecture in SAP S/4HANA

The core task of a business application is to read data, prepare it for display,

present it to a user, receive new input or data changes by the user, check its

consistency, process its impact, and finally persist the new data.

SAP Fiori UIs In modern user interfaces (UIs), such as SAP Fiori, that are completely

geared to the needs of the user, the first part of the user interaction plays an

important role in that many different types of information are relevant for

the user’s task and should be directly available to support his decisions. The

preparation of the required data and its display create substantial develop-

ment efforts and require knowledge in different application areas.

However, for the second part of the user interaction—checking and pro-

cessing data—proven program parts can be reused in most cases.

Read access Experience shows that more than 90% of data accesses are read accesses.

Write access happens less frequently. To reduce development effort, pro-

gram complexity, and maintenance effort, the programming model of SAP

S/4HANA was optimized for read accesses. It uses CDS views that prepare

the raw data in a reusable way and add semantic metadata. The metadata is

evaluated by infrastructure components, thus reducing the volume of indi-

vidual programming.

Programming

models in

comparison

You can see the difference in programming models when comparing the

classical SAP Fiori architecture in Figure 6.1 with the latest architecture in

Figure 6.2, optimized for read accesses.

In the much-simplified representation of the two programming models,

you see the common base structure: SAP Fiori apps use OData services that

are provided by the ABAP application server, which in turn accesses data via

SQL. The technical provisioning is done by the service infrastructure in

both models.

201


6

Figure 6.1 Classical SAP Fiori Architecture

Figure 6.2 New Architecture for Read Access

SAP HANA

ABAP

ImplementedProvider for

the App

SAP Fiori App

OData

SQL

ServiceInfrastructure

SAP HANA

ABAP

GenericApplication

Infrastructure

OData

SQL

CDSInfrastructure

ImplementedApplication

LogicOpt.


SAP Fiori App

202


OData service

provider

Differences exist in the implementation of the service provider of the

OData service and in the definition of the OData service itself. In the classi-

cal model, the OData service and its service provider are both individually

implemented. In the new model, CDS views selected for a service provider

define the structure of the OData service and its components. Moreover, a

generic application infrastructure serves as a generic service provider for

retrieving data via CDS views. Therefore, the definition of CDS views is the

essential step in the development of a new OData service.

As the structure of the OData service corresponds to the structure of the

CDS views, a read request to the OData service can be translated to SQL

selections from these CDS views. The result of the SQL SELECT request is

translated into corresponding entity sets of the OData service and returned

as a response to the read request.

Special cases that, for example, need a special logic for the implementation

of individual fields, can optionally be implemented in supplied extension

methods.

Metadata Metadata of the CDS views controls how the OData service for the CDS

views is formed and how an OData request is translated into a SQL request.

Some CDS metadata is translated into corresponding metadata of the

OData service and thus exposed to the service consumers.

SAP Fiori elements This creates further potential to simplify the development of SAP Fiori apps

with SAP Fiori elements. SAP Fiori elements allow the construction of an

SAP Fiori app from reusable smart templates and smart controls, whose con-

crete layout is controlled by the used OData service and its annotations. As

the UI annotations needed for this can already be defined in the CDS views

in use, the essential parts of an SAP Fiori app can be defined completely in

CDS. We’ll show a concrete example for this in Chapter 9, Section 9.4.4.

New architecture In Figure 6.3, we added write access to data as well as the option to use other

communication channels. This completes the conceptual model of the

application architecture in SAP S/4HANA.

For changes of data, often existing application logic for checking and pro-

cessing data and updating the database is connected. Therefore, the devel-

opment effort in this programming model is mainly spent on defining CDS

views with appropriate metadata, which is the central topic of this book.

203


6

Figure 6.3 Overview of the New Architecture

Infrastructure

components

The major piece of the generic application infrastructure is the ABAP appli-

cation infrastructure, a new component of the ABAP application server

introduced with SAP NetWeaver 7.5. It’s complemented for analytic appli-

cations by the analytic engine, a component of SAP Business Warehouse

(SAP BW), which is also available in SAP S/4HANA. The service infrastructure

mainly consists of SAP Gateway, but it also uses components for other com-

munication protocols, such as for analytic applications.

Benefits of the new

architecture

The CDS-based application architecture of SAP S/4HANA offers the follow-

ing benefits:

� Speed in the selection and preparation of big data sets for the UI as CDS

views execute these steps directly in SAP HANA

� Simplified development and high consistency in the offered OData ser-

vices through model-driven development based on a unified data model

(the virtual data model [VDM], introduced in Chapter 7)

� Flexibility by optionally using implemented ABAP logic if needed

General benefits of the ABAP platform, such as the integrated development

and transport environment, as well as general application services, such as

user management and integrated authorization checks, are also available.

SAP HANA

ABAP

GenericApplication

Infrastructure

SAP Fiori App

OData

SQL

CDSInfrastructure

ImplementedApplication

Logic


Update

Opt.

App

204


6.2 Field Labels

In this and the following sections, we’ll present some metadata used in CDS

models. We start with field labels. Every data field in a table or a CDS view

needs not only a field name but also a description in the language of a user,

that is, a field label. Field names in CDS views should be understandable as

well but are only expressed in one language—usually English. Field labels,

though, are supposed to be translated to many languages.

Origin of field labels Field labels provide important semantic information about a data field. SAP

applications have always offered the option to reuse field labels from the

data type of the field or from the data element, or to define them individu-

ally for a UI. In the SAP S/4HANA programming model, field labels also can

be derived from data elements or can be directly defined in the UI. Addi-

tionally, it’s possible to define a field label by a field annotation in a CDS

view: @EndUserText.label: '<field label>'. An annotated field label can be

translated like other short texts.

The field label from the data element guarantees identical field labels for all

usages of the data field. This avoids multiple translations and ensures con-

sistent terminology in all UIs and apps with that data field.

Sometimes a UI has to use an individual field label. This always takes prece-

dence over a field label from the data element of an annotation. The logic

behind when the data element and when an annotation is used is more

complex and will be presented in Section 6.2.1. Next, Section 6.2.2 covers

variants of labels with different text lengths.

6.2.1 Determination of a Field Label

Data element or

annotation?

In a CDS view, a field label can be determined by a data element or by an

annotation. In simple cases, an annotation takes precedence over a data

element. The situation is more complex if the field’s data type is changed

to a data element by a cast function or if the annotation is propagated

from a data source. Table 6.1 shows a stack of views that demonstrates the

precise rules.

View Annotation Cast to Data Element Field Label

V5 – – D2 C

Table 6.1 Determination of a Field Label

205

6.2 Field Labels

6

The field labels are determined as follows:

1. Starting point is CDS view V1 with field F having data element D1 as the

type. The data element defines the field label A.

2. View V2 selects field F from V1. In view V2, field F also has data element

D1 as the type. However, in view V2, field F also has annotation @EndUser-

Text.label: 'B' and therefore gets field label B as the annotation takes

precedence over the data element.

3. In view V3 that selects field F from view V2, field F still has data element

D1 but also field label B as the annotation is propagated to view V3.

4. In view V4 that selects field F from view V3, the data type of field F is

changed to data element D2 by a cast function. Then field F gets field

label C from data element D2. The cast has higher priority than a propa-

gated annotation @EndUserText.label. In fact, propagation of this anno-

tation is stopped by the cast, and it’s not propagated to field F in view V4.

An explicit annotation in view V4 would have taken precedence over the

cast data element, however.

5. In view V5 that selects field F from view V4, the data element and the

field label are kept.

The technical realization of this logic treats the field label of the data ele-

ment like a propagated @EndUserText.label annotation. Therefore, the de-

velopment environment shows for all these views an active annotation

@EndUserText.label with the respective field label. You can verify this with

the Active Annotations function from the context menu of the CDS view in

the ABAP Development Tools (ADT).

V4 – D2 D2 C

V3 (propagated) – D1 B

V2 @EndUserText.label: 'B' – D1 B

V1 – – D1 A

View Annotation Cast to Data Element Field Label

Table 6.1 Determination of a Field Label (Cont.)

206


6.2.2 Length of a Field Label

Text variants of a

field label

A data element can cover many situations as it offers field labels in three

lengths as well as a label for column headings and a short description text.

Conversely, in a CDS view, only two label text variants can be defined by

annotations:

� The field label by @EndUserText.label

� A short description called quick info by @EndUserText.quickInfo

The UI technology and the communication channel to the UI determine

which of these text variants can be used in a UI. Most SAP Fiori apps use the

OData protocol for their communication. The OData standard offers three

variants of field labels: label, quickInfo, and heading. The first two labels

exactly correspond to the CDS annotations. This isn’t by chance: several

CDS annotations were introduced to correspond to OData annotations. The

heading variant isn’t available, however.

The selection of field labels for a data element is more complex. The map-

ping between the data element Short Description and quickInfo is clear, as

is the correlation between the data element Heading and heading. More dif-

ficult, however, is the choice between the Short, Medium, or Long texts for

the label. Figure 6.4 shows an example of a typical data element.

Figure 6.4 Field Label Texts of a Data Element

Field labels from

data elements

In earlier releases, the SAP Gateway component had always preferred the

medium text of the data element as the field label in the OData service, even

if its length was quite short. This often led to cryptic abbreviations. On the

other hand, field labels should not be too long. Therefore, the logic was

207

6.2 Field Labels

6

adapted for SAP S/4HANA and now selects the longest field label with a

maximum length of 20 characters. With that approach, most cases can be

handled. Only in some cases, labels with length 20 are still too short to

express the field semantics properly. An alternative is to use CDS annota-

tions that support distinctly longer label texts.

It’s also possible to define a data element without short or medium label

texts, as shown in Figure 6.5. Then the single remaining text is used as the

field label. In this approach, 40 characters are available for the label text.

Figure 6.5 Data Element with a Long Field Label

Field labels in OData

and analytics

All three variants of OData field labels are provided by the application infra-

structure in the metadata of an OData service. Analytic applications sup-

port a single field label only. This is determined like the label text in OData

and either taken from annotation @EndUserText.label or from the data ele-

ment according to the same logic.

Parameter labelsCDS view parameters also have labels. Like field labels, they can be taken

from the data element of the parameter, according to the same logic, or

defined by annotation @EndUserText. There is no propagation logic for

parameter annotations, however.

Parameter Annotations

Like fields, you can also annotate parameters of CDS views. You’ve already

seen an example of this in our initial discussion in Chapter 3, and more

examples will follow when we look at analytical application modeling in

Chapter 8.

208


Besides the labels, you can define further language-dependent texts in CDS

views, such as a label for the CDS view itself, or some UI texts by UI annota-

tions. However, these texts can’t be derived from data elements—only

from CDS view annotations.

6.3 Field Semantics

Usually, developers specify the technical type of a data field. This informa-

tion is far from sufficient, however, to express all business semantics of the

field and execute functions for it that depend on these semantics. The field

documentation, which often doesn’t exist, addresses human readers and is

too informal to be a reliable source for automated processing.

Formalized

semantics

To address this problem, the ABAP Data Dictionary (ABAP DDIC) introduced

formalized descriptions of some semantic aspects of fields in addition to the

data type, for example, to identify amount fields and their related currency.

These enable automated processing by the ABAP infrastructure.

CDS takes several steps forward. Annotations at CDS view fields can formal-

ize any semantic aspect of a data field. This method is applied in various

ways, and you’ll see many examples throughout this book. In this section,

we’ll present several frequently used field annotations.

6.3.1 Quantities and Amounts

Unit and currency Every quantity field has a unit field, and every amount field has a currency

field. The ABAP DDIC can store these semantic properties and relations for

tables and structures. For CDS views, they can be expressed as the following

CDS annotations:

� Unit field

A unit field is characterized by annotation @Semantics.unitOfMeasure:

true.

� Quantity field

When indicating a quantity field, the related unit field is provided as

@Semantics.quantity.unitOfMeasure: '<unit field>'.

� Currency field

A currency field is characterized by @Semantics.currencyCode: true.

209

6.3 Field Semantics

6

� Amount field

For amount fields, again the related currency field is indicated as @Seman-

tics.amount.currencyCode: '<currency field>'.

By specifying the reference field at the quantity or amount field, multiple

fields can reference the same unit or currency field.

ExamplesListing 6.1 shows some examples for these annotations from SAP standard

view I_SalesOrderItem.

@Semantics.unitOfMeasure: trueOrderQuantityUnit,@Semantics.quantity.unitOfMeasure: 'OrderQuantityUnit'OrderQuantity,@Semantics.amount.currencyCode: 'TransactionCurrency'NetAmount,@Semantics.currencyCode: trueTransactionCurrency,

Listing 6.1 Quantity and Unit, Amount and Currency

Service metadataThe CDS annotations for quantities, units, amounts, and currencies are

translated by the application infrastructure into analogous annotations of

an OData service. They are available to consumers of the OData service.

Analytic applications leverage these CDS annotations as well, as you’ll see

in Chapter 8.

6.3.2 Aggregation Behavior

SQL SELECTS from CDS views can explicitly specify the desired aggregation

of a data field. This is done for the following purposes:

� For numeric fields, a summation or an average calculation

� For sortable fields, the determination of a maximum or a minimum

� For any fields, the counting of different values

Standard

aggregation

Some data fields in a CDS view are often aggregated and have a preferred

method of aggregation. The net amounts of sales order items, for exam-

ple, are usually summed up but not the net prices. For net prices, some-

times a minimum of maximum determination is useful, but mostly they

serve as additional information. You can assign to such fields a standard

aggregation that fits its semantics. This enables the infrastructure to

210


request aggregated data without explicitly specifying the type of aggrega-

tion. By default, fields are aggregated according to their annotated standard

aggregation.

Aggregating

selection

Assume, for example, that field NetAmount in the sales order items view is

annotated for standard aggregation summation. In this case, an aggregating

selection of the business field division and the net amount results in a list of

all divisions together with the sum of the net amounts of all sales order items

with that division. Such a result is already a simple analysis of business data.

Two annotation

versions

Due to a change in the taxonomy for CDS annotations, there are two vari-

ants for specifying a standard aggregation: the older variant @DefaultAggre-

gation and the current variant @Aggregation.default. Possible types for the

standard aggregation are shown in Table 6.2.

Listing 6.2 shows some examples of this annotation from SAP standard

view I_SalesOrderItem.

@DefaultAggregation: #SUMOrderQuantity,@DefaultAggregation: #SUMNetAmount,@DefaultAggregation: #NONENetPriceAmount,

Listing 6.2 Standard Aggregation

Aggregation Type Description

#AVG Average calculation: Sum of all values, divided by the

number of values

#COUNT_DISTINCT Number of distinct values

#FORMULA Special form for analytic queries (see Chapter 8 for more

details)

#MAX Maximum of all values

#MIN Minimum of all values

#NONE No standard aggregation

#SUM Sum of all values

Table 6.2 Supported Aggregation Types

211

6.3 Field Semantics

6

No aggregationFields without a standard aggregation annotation won’t be aggregated. This

is equivalent to standard aggregation #NONE. This annotation at field NetPr-

iceAmount in view I_SalesOrderItem (see Listing 6.2) therefore isn’t neces-

sary. The developers nevertheless annotated this field to emphasize that it

should not be aggregated.

Measures and

aggregation

The annotation for a standard aggregation (except #NONE) has a big impact

on the consumers of a view. In analytic views, this leads to the interpreta-

tion of the annotated field as an analytic measure. You’ll find more details

on this in Chapter 8.

In the metadata of an OData version 2.0 service based on a CDS view, a field

with annotated standard aggregation is marked as a measure. A read

request for the entity set corresponding to the CDS view is performed as an

aggregating selection. The type of aggregation is determined by the anno-

tated standard aggregation. For executing the request, the application

infrastructure uses a SQL SELECT with the standard aggregation of the anno-

tated fields, grouped by the other requested fields. The aggregation is

finally executed by SAP HANA. With this method, OData services can be lev-

eraged for simple analytics.

6.3.3 System Times

Creation time and

last change time

Applications usually store the creation date/time of a data record, as well as

the date it was last changed, in database tables together with the applica-

tion data. This is important semantic information. The point in time of the

last change, for example, can be used in data replication or for optimistic

locking mechanisms. A prerequisite is the reliable determination and stor-

age of this information at creation and at every change. CDS annotations

can be used to identify fields with this information as system times (see

Table 6.3).

Annotation Field Semantics

@Semantics.systemDateTime.createdAt

Point in time of creation (ABAP type TIME-STAMP or TIMESTAMPL)

@Semantics.systemDateTime.lastChangedAt

Point in time of the last change (ABAP type

TIMESTAMP or TIMESTAMPL)

Table 6.3 CDS Annotations for System Times

212


System times in

CDS views

Fields with system times not only exist in tables but also in CDS views. For

views that combine data from multiple tables, you must carefully consider

which fields should be annotated as system times using the following rules:

� Only a single point in time of creation is reasonable; it should relate to

the main data source of the view.

� The point in time of the last change must consider possible changes of all

data fields of the CDS view, independent of their origin.

Listing 6.3 shows examples of system times from SAP standard view I_Sales-

Order.

@Semantics.systemDate.createdAt: true

CreationDate,

@Semantics.systemTime.createdAt: true

CreationTime,

@Semantics.systemDate.lastChangedAt: true

LastChangeDate,

@Semantics.systemDateTime.lastChangedAt: true

LastChangeDateTime,

Listing 6.3 System Times

@Semantics.systemDate.createdAt

Date of creation (ABAP type DATS)

@Semantics.systemDate.lastChangedAt

Date of last change (ABAP type DATS)

@Semantics.systemTime.createdAt

Clock time of creation (ABAP type TIMS); only

reasonable in combination with a creation

date

@Semantics.systemTime.lastChangedAt

Clock time of the last change (ABAP type

TIMS); only reasonable in combination with a

last change date


Table 6.3 CDS Annotations for System Times (Cont.)

213

6.3 Field Semantics

6

6.3.4 Text and Languages

Texts in natural

language

Fields that contain a text in natural language should be distinguishable

from codes or other technical information. They should preferably be dis-

played to a human user, but they are usually irrelevant for technical pro-

cessing. For this purpose, CDS annotation @Semantics.text is available.

Natural language texts are usually written in a certain language; there are a

few exceptions, such as names of humans or organizations. If this language

is provided in another field of a view, this field is annotated with @Seman-

tics.language. An explicit connection between the fields, such as quantities

or amounts, isn’t possible, however. Usually, all text fields of a view share

the same language.

Listing 6.4 shows examples for this from SAP standard view I_CountryText.

This is a language-dependent text view that we’ll introduce in Section 6.5.

@Semantics.languagekey spras as Language,@Semantics.text: truecast(landx50 as fis_landx50 preserving type ) as CountryName,

Listing 6.4 Annotations for Text and Language

6.3.5 Information for the Fiscal Year

Fiscal yearCDS annotations can also express application-specific semantics. An exam-

ple is the information for a fiscal year in financial accounting and its peri-

ods. A fiscal year can deviate from a calendar year and consists of flexibly

defined periods. The indication of fiscal year information enables an appro-

priate formatting of the data. The annotations are shown in Table 6.4.


@Semantics.fiscal.yearVariant Fiscal year variant; defines the properties

of the fiscal year

@Semantics.fiscal.period Fiscal period given by three digits

@Semantics.fiscal.year Fiscal year given by four digits

Table 6.4 Information for the Fiscal Year

214


Listing 6.5 shows examples from SAP standard view I_JournalEntryItem.

@Semantics.fiscal.year: trueryear as LedgerFiscalYear,@Semantics.fiscal.period: truepoper as FiscalPeriod,@Semantics.fiscal.yearVariant: trueperiv as FiscalYearVariant,@Semantics.fiscal.yearPeriod: truefiscyearper as FiscalYearPeriod,

Listing 6.5 Information for the Fiscal Year

6.4 Foreign Key Relations

You may be familiar with the concept of foreign keys from the ABAP DDIC.

The basic target is to restrict the possible values for a data field of a foreign

key table to the available values of a key field in a check table. This may

sound complex but quickly becomes clear with an example (see Figure 6.6).

In the example, the data record for an address has field Country for a coun-

try. Only countries from a country table should be allowed as admissible

values for this field. Therefore, the address table plays the role of foreign

key table and the Country field is the foreign key field. The table of countries

plays the role of check table with the Country as key field. This relation

@Semantics.fiscal.yearPeriod Fiscal year period; the combination of fis-

cal year and period

@Semantics.fiscal.quarter Fiscal quarter given by one digit

@Semantics.fiscal.yearQuarter Combination of fiscal year and quarter

@Semantics.fiscal.week Fiscal week given by two digits

@Semantics.fiscal.yearWeek Combination of fiscal year and week

@Semantics.fiscal.dayOfYear Number of a day in a fiscal year


Table 6.4 Information for the Fiscal Year (Cont.)

215


6

between the tables and the relevant fields can be stored as a foreign key in

the ABAP DDIC.

Figure 6.6 Foreign Keys in the ABAP DDIC

Foreign keys in CDSForeign key relations can exist between CDS views as well. The relationship

between the foreign key view and the value view or entity view can be

defined neatly by an association. In CDS, we avoid the term “check view”

because the foreign key relationship alone doesn’t define a consistency

check but only expresses the semantic relationship between the persisted

data. The entity view provides possible field values or, more precisely, rep-

resents the list of instances to which the foreign key field can reference (see

Figure 6.7).

Listing 6.6 shows an example of such an association from view I_Profit-

Center to view I_Country.

define view I_Country as select from t005{ key cast(land1 as land1_gp preserving type ) as Country,…

define view I_ProfitCenter as select distinct from cepcassociation[0..1] to I_Country as _Countryon $projection.Country = _Country.Country

Name City Country …

Schmidt Hamburg DE

Miller Boston US

…

Country …

DK

DD

DE

DG

Foreign Key Table

Check Table

Foreign Key Field

Foreign Key Relation …

…

216


{ …land1 as Country,…

Listing 6.6 Association Used by a Foreign Key Relation

Figure 6.7 Foreign Keys in CDS

Foreign key

annotation

The definition of an association doesn’t yet establish a foreign key relation.

Its foreign key character, as well as the identification of the foreign key field,

is defined by CDS annotation @ObjectModel.foreignKey.association at the

foreign key field (see Listing 6.7). The association given in the annotation is

called the foreign key association for this field.


{ …@ObjectModel.foreignKey.association: '_Country'land1 as Country,…

Listing 6.7 Annotation of a Foreign Key Association

Name City Country …

Schmidt Hamburg DE

Miller Boston US

…

Country …

DK

DD

DE

DG

Foreign Key View

Entity View

Foreign Key Field

Foreign Key Association …

217


6

CardinalityThe cardinality of a foreign key association must be either [0..1] or [1..1];

that is, either at most one country or exactly one country exists for a profit

center. The cardinality for the reverse direction of the association can be

[0..*], meaning that for a country, there can be no profit centers or any

number of profit centers.

Multiple key fieldsThis way of defining a foreign key association also works for entity views

with more than one key field. Listing 6.8 shows such an example for regions

(federal states, provinces, etc.).

define view I_Region as select from t005sassociation [1..1] to I_Country as _Countryon $projection.Country = _Country.Country

{@ObjectModel.foreignKey.association: '_Country'key t005s.land1 as Country,key t005s.bland as Region,…

}


association[0..1] to I_Region as _Region on $projection.Country = _Region.Countryand $projection.Region = _Region.Region

{ …@ObjectModel.foreignKey.association: '_Country'land1 as Country,@ObjectModel.foreignKey.association: '_Region'regio as Region,…

}

Listing 6.8 Foreign Key Association with Two Key Fields

Figure 6.8 shows how the three views from the listings are connected by

foreign key associations.

218


Figure 6.8 Foreign Key Associations

Representative

key field

For CDS, the foreign key concept of ABAP DDIC was enhanced by a useful

aspect: the indication of a representative key field by annotation @Object-

Model.representativeKey. The motivation for this can be seen in the preced-

ing example. In Listing 6.8, it’s clear from the semantics and the naming

that field Country has association _Country as the foreign key association

and not association _Region.

From a technical perspective, you could also specify association _Region at

field Country as the foreign key association. This has the following disadvan-

tages, however:

� Not all countries are available as values but only those for which regions

are recorded.

� For a consumer of the foreign key view, it’s not possible to retrieve fur-

ther information about the country via the foreign key association.

This second point, in particular, is an import benefit of the data model: fol-

lowing an association reveals further details of the starting point, that is,

the foreign key field. Foreign key associations in CDS are meant to serve

this purpose and retrieve further data of the entity represented by the for-

eign key field.

Consistency

condition

By indicating the representative key field of an entity view, usage of a

wrong association as the foreign key association can be detected. The for-

eign key association always must bind the foreign key field to the represen-

tative key field of the entity view; that is, the two fields must be equal in the

ON condition of the association definition. In a consistent modeling, both

annotations must be in place.

I_ProfitCenter

I_Country

I_Region

Country

Country

CountryRegion

219


6

Listing 6.9 shows annotation @ObjectModel.representativeKey in views I_

Country and I_Region.

@ObjectModel.representativeKey: 'Country'define view I_Country as select from t005{ key cast(land1 as land1_gp preserving type ) as Country,…

@ObjectModel.representativeKey: 'Region'define view I_Region as select from t005sassociation [1..1] to I_Country as _Countryon $projection.Country = _Country.Country

{@ObjectModel.foreignKey.association: '_Country'key t005s.land1 as Country,key t005s.bland as Region,…

}

Listing 6.9 Representative Key Fields

The representative key field of an entity view is the part of the key that

semantically represents an entity (row) of the view. In the view of regions,

this is key field Region, not key field Country. Because the view name also

reflects the semantics of the entity, the name of the representative key and

the view name are usually very similar.

Modeling patternNot every CDS view needs a representative key field. Views with a represen-

tative key field represent discrete entities that can be connected by foreign

keys to enrich a data model semantically. Foreign key relations are an ele-

mentary modeling pattern in CDS.

Foreign key associations are used to do the following:

� Serve as standard source of value help if no other explicit value help is

defined (see Chapter 10, Section 10.1).

� Define dimensions in the analytic model (see Chapter 8, Section 8.2.4).

� Mark the view that provides detailed information for a data field.

� Provide automated input checks in transactional applications.

220


6.5 Text Relations

Many data fields contain codes or IDs to represent an entity of the business

world, for example, a country code or customer ID. While computers are

very good at processing such codes, a human consumer wants to see a

name or description in natural language. Such texts are stored in different

fields or even different tables, so a connection between the coded field and

the text field must be created in the data model, also known as a text rela-

tion. This enables the infrastructure to automatically detect and use the

texts. If texts exist in multiple languages, the logon language of the user, or

an appropriate substitute, would be chosen for filtering the text to be dis-

played.

CDS supports two variants of text relations: within a view or between two

views. Both variants are based on annotations: @ObjectModel.text.element

for within a view or @ObjectModel.text.association for between views.

Text relation within

a view

You can see an example for the first variant in SAP standard view I_Bank for

banks. A relevant extract is shown in Listing 6.10.

define view I_Bank as select frombnka

{ …@ObjectModel.foreignKey.association: '_Country'key banks as BankCountry,@ObjectModel.text.element: [ 'BankName' ]key bankl as BankInternalID,

@Semantics.text: truebanka as BankName,

…}

Listing 6.10 Text Relation within a View

In this example, BankInternalID is a coded representation of a bank, and

BankName is a text field for the name of the bank. In addition, take note of

field annotation @Semantics.text from Section 6.3.4. Annotation @Object-

Model.text.element at the field with the coded representation references a

list of fields that contain a descriptive text. If the list contains text fields,

the first one is used as standard text. Note that this variant doesn’t support

language-dependent texts.

221

6.5 Text Relations

6

Text relations

between views

An example for the second variant is the view for countries, I_Country, and

its text view, I_CountryText, with the related country names in different

languages. Listing 6.11 shows the relevant parts.

define view I_Country as select from t005association [0..*] to I_CountryText as _Texton $projection.Country = _Text.Country

{ @ObjectModel.text.association: '_Text'key cast(land1 as land1_gp preserving type ) as Country,…

}

@ObjectModel.dataCategory: #[email protected]: 'Country'define view I_CountryText as select from t005t{ key land1 as Country,@Semantics.language: truekey spras as Language,@Semantics.text: truecast(landx50 as fis_landx50 preserving type )as CountryName,

…}

Listing 6.11 Text Relation to a Text View

Text associationView I_Country has coded field Country and its text—actually, its name—

CountryName is language dependent and stored in view I_CountryText. The

relation between the views is established by association _Text. Annotation

@ObjectModel.text.association: '_Text' characterizes the association as

text association for field Country, and the description of this field can be

found in the associated view.

In associated view I_CountryText, field CountryName is annotated as a text

field and therefore used as the description. If there are multiple text fields

in the view, the first text field will be the standard text.

Text viewsViews that essentially contain only textual descriptions should be marked

as text views by view annotation @ObjectModel.dataCategory: #TEXT.

To clarify which field the text view provides the text for, one of the

view’s key fields is marked as the representative key field by annotation

222


@ObjectModel.representativeKey. This clearly defines the semantics of the

view in case there are multiple key fields.

Text associations always bind the annotated field in the source view with

the representative key field of the text view. Usually a text view is language

dependent. The field with the language of the texts must be a key field and

must be annotated with @Semantics.language: true. The infrastructure usu-

ally filters on the logon language of the user when retrieving a language-

dependent text.

Use the foreign key

association

View I_ProfitCenter from the preceding section (see Listing 6.7) doesn’t

have a text association for its field Country. Still, the infrastructure can auto-

matically determine a text field for it by first following the foreign key asso-

ciation to view I_Country. Its representative key field Country has a text

association that leads to a text (see Figure 6.9).

Figure 6.9 Foreign Key and Text Association

6.6 Composition Relations

Many types of related business data are distributed in a normalized form to

multiple tables, for example, the header data and items of a sales or pur-

chase order. CDS views for analytics often combine such data into a single

view, but CDS views for transactional applications reflect a normalized dis-

tribution of data to multiple views. In the data model, we want to express

which views belong together and form a well-defined (business) object.

Parent-child

relations

For this purpose, composition relations are introduced that bring the re-

lated views into hierarchical parent-child relations. A view can have at most

one superordinate parent view but any number of subordinate child views.

A composition relation implies an existential dependency, meaning that a

data row in a child view can only be created if a related row in its parent

view exists, and the deletion of a data row forces the deletion of all related

rows in child views.

Root view Besides the parent-child relations, for every group of related views, one

view is marked as a root view. This is the only view in the group without a

I_ProfitCenter I_Country I_CountryText

Foreign KeyAssociation Text Association

223

6.6 Composition Relations

6

parent view. In the sales order object, for example, the view for the order

header data is the root view.

ObjectThe group of related views is often called the object or business object. It can

be identified by its root view.

Composition

associations

Composition relations between views are defined as usual by associations.

Annotation @ObjectModel.association.type assigns a type to the associa-

tions that marks them as composition associations. Three types of composi-

tion associations are distinguished:

� #TO_COMPOSITION_PARENT

The association points to the parent view.

� #TO_COMPOSITION_CHILD

The association points to a child view.

� #TO_COMPOSITION_ROOT

The association points to the root view of the object.

An association can simultaneously have types #TO_COMPOSITION_PARENT and

#TO_COMPOSITION_ROOT. The root view is identified by annotation @Object-

Model.compositionRoot: true.

Sales order exampleThe sales order model of SAP consists of CDS views I_SalesOrder for the

order header, I_SalesOrderItem for the items, and I_SalesOrderSchedule-

Line for the schedule lines. It has the composition associations shown in

Figure 6.10.

Figure 6.10 Composition Associations

I_SalesOrder

I_SalesOrderItem

I_SalesOrderScheduleLine

TO_COMPOSITION_CHILD

TO_COMPOSITION_CHILD

TO_COMPOSITION_ROOT

TO_COMPOSITION_ROOT

TO_COMPOSITION_PARENT

TO_COMPOSITION_PARENT

224


The relevant parts of the view definitions are shown in Listing 6.12.

@ObjectModel.compositionRoot: truedefine view I_SalesOrder …association [0..*] to I_SalesOrderItem as _Itemon $projection.SalesOrder = _Item.SalesOrder

{ …@ObjectModel.association.type: [#TO_COMPOSITION_CHILD]_Item,…

}

define view I_SalesOrderItem …association [1..1] to I_SalesOrder as _SalesOrderon $projection.SalesOrder = _SalesOrder.SalesOrder

association [0..*] to I_SalesOrderScheduleLineas _ScheduleLineon $projection.SalesOrder = _ScheduleLine.SalesOrderand $projection.SalesOrderItem =

_ScheduleLine.SalesOrderItem{ …@ObjectModel.association.type:

[#TO_COMPOSITION_PARENT, #TO_COMPOSITION_ROOT]_SalesOrder,@ObjectModel.association.type: [#TO_COMPOSITION_CHILD]_ScheduleLine,…

}

define view I_SalesOrderScheduleLine …association [1..1] to I_SalesOrder as _SalesOrderon $projection.SalesOrder = _SalesOrder.SalesOrder

association [1..1] to I_SalesOrderItem as _SalesOrderItemon $projection.SalesOrderItem =

_SalesOrderItem.SalesOrderItemand $projection.SalesOrder = _SalesOrderItem.SalesOrder

{ …@ObjectModel.association.type: [#TO_COMPOSITION_ROOT]_SalesOrder,@ObjectModel.association.type: [#TO_COMPOSITION_PARENT]

225

6.7 Time-Dependent Data

6

_SalesOrderItem,…

}

Listing 6.12 Views with Composition Relations

In Chapter 9, Section 9.3, you’ll see in more detail how compositions are

used.

6.7 Time-Dependent Data

Time-dependent data or temporal data in business applications are mainly

attributes of master data objects that change their value over time, usually

at a certain calendar day. Typical examples are the salary of an employee or

the value-added tax percentage of a country.

Business time-

dependency

This is a business-driven planned time-dependency, not a versioning of

data specifying the point in time of a change. That second versioning is called

system time-dependency and is usually applied for change-tracking or revi-

sion purposes. Business time-dependency is usually described by dates and

therefore has the granularity of days. Time-dependent data is usually stored

in separate tables that have an additional key field for the time dimension.

Modeling patternWith CDS views, business time-dependent data can be described by a com-

mon modeling pattern as follows:

� A business time-dependent view has two date fields for the validity period

of the time-dependent attributes. These date fields are annotated with

@Semantics.businessDate.from: true and @Semantics.businessDate.to:

true, respectively.

� The validity period comprises the from date and the to date.

� At least one of the date fields is part of the view’s key. The remaining

fields of the key are called entity keys.

� The validity periods of two view rows with the same entity key must not

overlap.

� The combined timeline of validity periods of all rows with the same

entity key can have multiple gaps between periods.

Both date fields should be stored on the database for efficient access.

226


Annotate Only Time-Dependent Views

When using annotations @Semantics.businessDate.from and @Semantics.businessDate.to, take care that the view really has all qualities of a busi-

ness time-dependent view.

The infrastructure recognizes a business time-dependent view at its anno-

tations and key. When processing the view data, it can use an appropriate

key date as the filter in this case.

Example Listing 6.13 shows how view I_CostCenter is annotated as a business time-

dependent view.

define view I_CostCenter as select …{ key kokrs as ControllingArea,key kostl as CostCenter,

@Semantics.businessDate.to: truekey datbi as ValidityEndDate,

@Semantics.businessDate.from: truedatab as ValidityStartDate,

…}

Listing 6.13 Business Time-Dependent View

6.8 Hierarchies

Business data is often structured hierarchically; for example, there are hier-

archies of organization units, reporting hierarchies of employees, hierar-

chies of financial accounts in the balance sheet, hierarchies of products and

product types, and many more. Hierarchical structures help users survey

and process large amounts of data. In analytical applications, measures can

be aggregated at hierarchy nodes and selectively expanded to greater

detail.

Hierarchies in CDS You can formalize hierarchical relationships between data objects in CDS

and model them with views and annotations. This model can be processed

by a generic hierarchy engine. Two basic types of hierarchies are distin-

guished: leveled hierarchies and parent-child hierarchies. In the following

227

6.8 Hierarchies

6

sections, we’ll go through both types, walk through an example, and dis-

cuss how to determine and test a hierarchy.

6.8.1 Leveled Hierarchies and Parent-Child Hierarchies

Leveled hierarchiesIn leveled hierarchies every hierarchy level has a separate data field. A sim-

ple example is the two-level hierarchy of countries and regions, which is

represented by view I_Region with key fields Country und Region for the lev-

els. As explicit fields are available for every hierarchy level, standard SQL

requests are sufficient for executing typical hierarchy requests such as

aggregating all value in a subtree. You can, for example, determine all

regions of a country via a simple SQL request and aggregate their values.

Special hierarchy functions aren’t necessary. Therefore, we’ll focus on a dif-

ferent type of hierarchy, the parent-child hierarchy.

Parent-child

hierarchies

Parent-child hierarchies have an important advantage over leveled hierar-

chies: the hierarchy levels are independent from the view’s fields and their

number is theoretically unlimited. Figure 6.11 shows an example.

Figure 6.11 Parent-Child Hierarchy

This unlimited number of levels requires programming loops or recursive

processing of the hierarchy. Unfortunately, this isn’t possible with standard

requests in SQL. For using parent-child hierarchies, additional support by

the infrastructure is necessary. Until ABAP release 7.52, only the analytic

engine was available for that purpose (refer to Section 6.1). In ABAP release

7.53, the first steps were made to leverage the SAP HANA hierarchy engine

in CDS. However, as this approach isn’t yet completely integrated into the

1

62 7

3 4 8

5

228


SAP S/4HANA programming model and not much practical experience is

available yet, we focus on the annotation-based parent-child hierarchies

and their processing by the analytic engine.

Base entity and

hierarchy nodes

The starting points for defining a hierarchy are the hierarchy base entity

instances, for example, employees or cost centers, which will be structured

hierarchically. For that purpose, hierarchy nodes are used. These nodes can

belong to the base entity (e.g., in an employee-manager hierarchy) or to an

entity with different business semantics, or the hierarchy can be structured

as a pure node.

The hierarchy nodes get their structure by a relation to a parent node. Every

node is either related to a single parent node or has no parent. Nodes with-

out parent are called root nodes. The parent relation defines a parent-child

hierarchy on the hierarchy nodes. The hierarchical structure on the base

entity originates from the assignment of hierarchy nodes to (at most) one

instance of the base entity. The base entity instance obtains its position in

the hierarchy from this assignment.

Distinguishing between the base entity and the hierarchy nodes allows for

the definition of multiple different hierarchies that consist of different sets

of nodes for the same base entity. You can use these in parallel for different

purposes. The different hierarchies are administered by a hierarchy direc-

tory.

CDS views for

hierarchies

In CDS, the following views for hierarchies are used:

� A view for the hierarchy base entity

� A view for hierarchy nodes

� Optionally views for other entities that are represented as nodes in the

hierarchy

� An optional view for the hierarchy directory

� Optional text views for the base entity, for the hierarchy nodes, for other

entities, and for the hierarchy directory

These views are connected by associations, as shown in Figure 6.12. The

types of the associations are shown as well.

In simple cases, the same view represents the base entity and the hierarchy

nodes, and there are no other views. The employee-manager is an example.

The relationship of the hierarchy base entity to its hierarchy node view is

229

6.8 Hierarchies

6

established by an association. It’s modeled by annotation @Object-

Model.hierarchy.association at the representative key field of the base

entity.

Figure 6.12 CDS Views for Hierarchies

Hierarchy structureThe essential information for the definition of the hierarchy structure is

the view of the hierarchy nodes. If it’s not identical to the view of the base

entity, it’s marked as a hierarchy node view by annotation @ObjectModel.data-

Category: #HIERARCHY. Structured view annotation @Hierarchy.parentChild

defines the hierarchy structure. The details are shown in Table 6.5.

TextText

Directory

Hierarchy

Foreign KeyForeign Key

Hierarchy Directory

Hierarchy NodeBase Entity

Base Entity Text

Other Entity

Hierarchy Node Text

Annotation Semantics

@Hierarchy.parentChild.name Specifies a technical name for the hier-

archy. It’s mandatory if no hierarchy

directory is used.

@Hierarchy.parentChild.label Description of the hierarchy (optional).

@Hierarchy.parentChild.recurseBy Used as an alternative to annotation

recurse.parent and recurse.child.

The relation to the parent node is

defined by an association of the view

to the view itself, a self-association.

Table 6.5 Annotations for Defining the Hierarchy Structure

230


Relation to the

parent node

The most important information is the relationship to a parent node. For

its definition, using a self-association in annotation @Hierarchy.parent-Child.recurseBy is most elegant. It must have cardinality [0..1] and bind

the key fields of the target. Alternatively, the key fields of the view are spec-

ified after annotation @Hierarchy.parentChild.recurse.child, and the view

fields that identify the parent node are specified after annotation @Hierar-chy.parentChild.recurse.parent in a sequence corresponding to the key

fields.

6.8.2 Example of a Parent-Child Hierarchy

Cost center

hierarchy

Now, we’ll use the cost center hierarchy as an example. Listing 6.14 shows

the relevant part of base entity I_CostCenter. Note association _CostCen-terHierarchyNode to the hierarchy node view.

@ObjectModel.representativeKey: 'CostCenter'define view I_CostCenter as select …association[0..*] to I_CostCenterText as _Texton $projection.ControllingArea = _Text.ControllingAreaand $projection.CostCenter = _Text.CostCenterand $projection.ValidityEndDate = _Text.ValidityEndDate

association[0..*] to I_CostCenterHierarchyNode as _CostCenterHierarchyNode

@Hierarchy.parentChild.recurse.parent@Hierarchy.parentChild.recurse.child

Used as an alternative to annotation

recurseBy. The relation to the parent

node is defined by specifying corre-

sponding fields.

@Hierarchy.parentChild.siblingsOrder.by

Specifies a field that is used to define

the order of siblings.

@Hierarchy.parentChild.siblingsOrder.direction

Direction for ordering siblings; can be

'ASC' (ascending) or 'DESC' (descend-

ing), with 'ASC' as default.

@Hierarchy.parentChild.directory Association to the hierarchy directory

(optional).

Annotation Semantics

Table 6.5 Annotations for Defining the Hierarchy Structure (Cont.)

231

6.8 Hierarchies

6

on $projection.ControllingArea = … .ControllingArea and $projection.CostCenter = … .CostCenter{ key kokrs as ControllingArea,@ObjectModel.text.association: '_Text'

@ObjectModel.hierarchy.association: '_CostCenterHierarchyNode'key CostCenter,@Semantics.businessDate.to: truekey ValidityEndDate,@Semantics.businessDate.from: trueValidityStartDate,…

}

Listing 6.14 Hierarchy Base Entity for the Cost Center

Example: Node view Related node view I_CostCenterHierarchyNode is shown in Listing 6.15. Note

that identical key fields of the child and parent node can be left out in the

definition of the parent-child relation via recurse.

@ObjectModel.dataCategory: #[email protected]:{ recurse: { parent: 'ParentNode', child: 'HierarchyNode' }, siblingsOrder: { by: 'SequenceNumber', direction: 'ASC' }, directory: '_Hierarchy'}define view I_CostCenterHierarchyNode …association [0..*] to I_CostCenterHierarchyNodeT as _Texton $projection.CostCenterHierarchy =

_Text.CostCenterHierarchyand $projection.HierarchyNode = ….HierarchyNodeand $projection.ControllingArea = ….ControllingAreaand $projection.CostCenter = ''

association [0..*] to I_CostCenter as _CostCenteron $projection.CostCenter =

_CostCenter.CostCenterand $projection.ControllingArea = ….ControllingArea

association [1..1] to I_CostCenterHierarchy as _Hierarchyon $projection.CostCenterHierarchy =

232


_Hierarchy.CostCenterHierarchyand $projection.ControllingArea = ….ControllingAreaand $projection.ValidityEndDate = ….ValidityEndDate

association [0..1] to I_ControllingArea as_ControllingArea

on $projection.ControllingArea = ….ControllingArea{@ObjectModel.foreignKey.association: '_ControllingArea'key ControllingArea,

@ObjectModel.foreignKey.association: '_Hierarchy' key CostCenterHierarchy,@ObjectModel.text.association: '_Text'

key HierarchyNode,key ValidityEndDate,

ParentNode,ValidityStartDate,@ObjectModel.foreignKey.association: '_CostCenter'CostCenter,SequenceNumber,_Text,_CostCenter,_Hierarchy,_ControllingArea…

}

Listing 6.15 Hierarchy Node View of the Cost Center Hierarchy

Example: Hierarchy

directory

The related hierarchy directory, view I_CostCenterHierarchy, is shown in

Listing 6.16.

define view I_CostCenterHierarchy …{ key ControllingArea,key CostCenterHierarchy,

@Semantics.businessDate.to: truekey ValidityEndDate,

@Semantics.businessDate.from: trueValidityStartDate,…

}

Listing 6.16 Hierarchy Directory for Cost Center Hierarchies

233

6.8 Hierarchies

6

Figure 6.13 shows the views of the example.

Figure 6.13 Hierarchy Example with Association Types

6.8.3 Determination of a Hierarchy

Evaluate the

hierarchy definition

Using the view definitions, the infrastructure (or a developer) can derive

how the hierarchy is formed. For the cost center hierarchy, this happens as

follows:

1. In the hierarchy annotation of the node view, an association to a hierar-

chy directory is provided that must be considered. The user must there-

fore select a specific cost center hierarchy row from the directory.

The hierarchy directory is time dependent (see Section 6.7), so the selec-

tion of the entry is done for a key date.

2. Now, all hierarchy nodes for the selected cost center hierarchy are read.

When doing so, filters are used on fields ControllingArea, CostCenterHi-

erarchy, and ValidityEndDate with the values of the selected cost center

hierarchy, as on these fields the association to the hierarchy directory is

defined.

3. All selected nodes have identical values on key fields ControllingArea,

CostCenterHierarchy, and ValidityEndDate. Therefore, key field Hierar-chyNode is the effective key of these nodes.

TextText

Directory

Hierarchy

Foreign Key

Hierarchy DirectoryI_CostCenterHierarchy

Hierarchy NodeI_CostCenterHierarchyNode

Base EntityI_CostCenter

Hierarchy Node TextI_CostCenterHierarchyNodeT

Base Entity TextI_CostCenterText

234


As specified in the hierarchy annotation, data field ParentNode points to

the parent node that is uniquely identified by HierarchyNode now. By

this, the nodes are ordered in a hierarchical structure. The infrastructure

creates an optimized hierarchy representation that enables the efficient

processing of hierarchical requests.

4. In the next step, the individual cost centers (the instances of the base

entity) must be assigned to the hierarchy nodes. This vital assignment is

done according to a complex logic. For every single hierarchy node, a

node type is determined. With the help of the node type, mixed hierar-

chies can be processed. These can have multiple types of entities as

nodes, for example, cost centers, profit centers, and company codes, in

the same hierarchy.

Every possible node type is represented by a corresponding association

from the hierarchy node view. For every node of the hierarchy and every

association, the ON condition of the association definition is checked in

sequential order according to their definition. The first association with

a valid ON condition defines the type of the node, and no further associa-

tions are checked.

In the node view of the cost center, the definition of the text association

has additional condition $projection.CostCenter = ''. Therefore, all nodes

with an initial cost center get node type _Text. All nodes with a not-initial

cost center get the type of the association checked next, _CostCenter.

Hierarchy Definition Error

The association to the hierarchy directory is excluded from this logic, and

the association to the controlling area doesn’t play a role because it’s

defined last. If it were defined as the first association, all nodes would have

gotten type _ControllingArea. All nodes would get the same text in the

following step, the description of the controlling area, and the hierarchy

functionality would not work as expected. This is a typical error source for

hierarchy definitions.

5. Now, all nodes get a text because the node key alone isn’t very meaning-

ful. This text depends on the node type and is determined via the associ-

ation belonging to the node type. For type _Text, this is standard

behavior. For other node types, the association is expected to be a for-

eign key association. Then the text can be determined via the related

entity. For the cost center, this is the related cost center text.

235

6.8 Hierarchies

6

Now the hierarchy is sufficiently described for the infrastructure. A user

interface can request the hierarchy in a form suitable for displaying from

the infrastructure, drilling into child nodes, or retrieving sums calculated

over subtrees for analytic applications.

Hierarchy

infrastructure

Only the analytic engine as part of the ABAP infrastructure can process a

hierarchy defined by CDS annotations. Hierarchies are commonly used in

analytical applications. The use of hierarchies in transactional applications

isn’t yet fully supported.

6.8.4 Test a Hierarchy

Analytic test

environment

The easiest way to test a hierarchy definition is the test environment for an-

alytic views, Transaction RSRTS_ODP_DIS, in SAP GUI. Its use is explained

in detail in Chapter 8, Section 8.2.2; therefore, only a short instruction fol-

lows here:

1. Ensure that the hierarchy base entity is marked as an analytic dimension

view by annotation @Analytics.dataCategory: #DIMENSION.

2. Start Transaction RSRTS_ODP_DIS, and enter the SQL view name of the

base entity, for example, “IFICOSTCENTER”, in ODP-Name for the cost

center view. Execute the transaction.

Analytic model3. You’ll see the analytic model of view I_CostCenter in Figure 6.14. In the

lower-right corner, beside the line for the cost center field, a tree-like

green icon signifies that a hierarchy definition exists for this field.

Figure 6.14 Analytic Model of View I_CostCenter

The cost center field is the representative key field of the view; therefore,

this information refers to the view itself—it possesses a hierarchy.

4. Start an analytic test of the view with the Standard Query function.

5. In the multidimensional analysis shown in the next screen that appears,

group by cost center in rows.

236


6. Open the Properties tab in the context menu of the Cost Center field.

You’ll see the properties screen shown in Figure 6.15.

Figure 6.15 Analytic Properties of the Cost Center Field

Select a hierarchy 7. When you change to the Hierarchy tab, you can choose an entry from the

hierarchy directory (see Figure 6.16). The example shows two versions of

the standard hierarchy for cost centers in controlling area 0001 with dif-

ferent validity periods.

Note that this tab is only shown if hierarchy directory entries exist.

Figure 6.16 Hierarchy Directory

8. After confirming the chosen hierarchy, the list of cost centers is dis-

played hierarchically (see Figure 6.17).

237

6.9 Summary

6

Figure 6.17 Cost Center Hierarchy

Note the artificial root node with the Not Assigned Cost Center(s) descrip-

tion, which is added by the infrastructure. It has all instances of the hierar-

chy base entity as children, which aren’t assigned to any node of the

selected hierarchy. That way, all selected cost centers are shown in the hier-

archical presentation.

6.9 Summary

We started with a high-level overview of the programming model of SAP

S/4HANA and showed the central role played by CDS. We then provided

many examples of how semantic properties of the data can be captured in

CDS metadata, which then controls the generic processing of data by the

infrastructure. The example of hierarchy annotations showed how combi-

nations of annotations, which are quite simple by themselves, can model a

complex matter.

In the following chapters, in particular Chapter 8 and Chapter 9 on model-

ing analytical and transactional applications, you’ll learn about even more

options for defining applications by CDS views, their associations, and their

annotations. But first, let’s take a closer look at SAP S/4HANA’s virtual data

model in the next chapter.

7

Contents

Preface ............................................................................................................................... 15

1 Modeling Your First CDS View 21

1.1 Define the Data Model of the Application ......................................... 22

1.2 Implement the Data Model of the Application ................................ 25

1.2.1 Create Database Tables ................................................................ 26

1.2.2 Create a CDS View .......................................................................... 30

1.2.3 Edit a CDS View ............................................................................... 38

1.2.4 Create a Hierarchy of CDS Views ............................................... 42

1.3 Summary ........................................................................................................... 54

2 Fundamentals of CDS Data Modeling 55

2.1 Overview of CDS Syntax ............................................................................. 56

2.2 Key Fields ........................................................................................................... 59

2.3 Cast Operations .............................................................................................. 61

2.4 Case Statements ............................................................................................ 63

2.5 Session Variables ........................................................................................... 64

2.6 Client Handling ............................................................................................... 66

2.7 Union Views ..................................................................................................... 68

2.8 Joins ..................................................................................................................... 76

2.9 SQL Aggregation Functions ....................................................................... 82

2.10 Associations ..................................................................................................... 85

2.10.1 Association Definitions ................................................................. 85

2.10.2 Expose Associations ....................................................................... 88

2.10.3 Model M:N Relations ..................................................................... 89

2.10.4 Use Associations in CDS Views .................................................. 92

2.10.5 Use Associations in ABAP Code .................................................. 105

8

Contents

2.11 Parameters ....................................................................................................... 106

2.12 Conversion Functions for Currencies and Quantity Units ........... 112

2.13 Performance Aspects ................................................................................... 116

2.13.1 Static View Complexity ................................................................ 117

2.13.2 Calculated Fields ............................................................................. 120

2.13.3 Functions and Calculations ......................................................... 122

2.13.4 Persistency Models ........................................................................ 122

2.13.5 CDS Models in ABAP Code ........................................................... 122

2.13.6 Performance Tests ......................................................................... 123

2.14 Summary ........................................................................................................... 123

3 Annotations 125

3.1 Annotation Definitions ............................................................................... 126

3.1.1 Annotation Names ......................................................................... 128

3.1.2 Type Definitions .............................................................................. 132

3.1.3 Enumeration Values ...................................................................... 133

3.1.4 Default Values ................................................................................. 134

3.1.5 Scope Definitions ............................................................................ 135

3.2 Effects of Annotations ................................................................................. 136

3.3 Propagation Logic of Element Annotations ....................................... 139

3.3.1 Basic Principles ................................................................................ 140

3.3.2 Consistency Aspects ...................................................................... 144

3.4 CDS Metadata Extensions ......................................................................... 146

3.5 Active Annotations ....................................................................................... 150

3.6 Summary ........................................................................................................... 152

4 Access Controls 153

4.1 Fundamentals of Access Controls .......................................................... 154

4.2 Mode of Action of Access Controls ........................................................ 157

9

Contents

4.3 Implementation Patterns for Access Controls .................................. 162

4.3.1 Inherit Implementation of Access Controls ........................... 162

4.3.2 Implement Access Controls with Path Expressions ............ 167

4.3.3 Implement Access Controls without Using

Authorization Objects ................................................................... 173

4.3.4 Implement Access Controls for Analytical Queries ............. 175

4.3.5 Implement Access Controls on the Field Level ..................... 178

4.3.6 Change Access Controls of SAP-Delivered CDS Models ..... 179

4.3.7 Block Standard Data Selections from CDS Models .............. 180

4.3.8 Decouple Access Controls from User Input ........................... 182

4.4 Test Access Controls ..................................................................................... 183

4.5 Summary ........................................................................................................... 186

5 Native SAP HANA Functions in CDS 187

5.1 Implementation of a CDS Table Function ........................................... 188

5.2 Application Scenarios .................................................................................. 195

5.3 Aspects for Consideration .......................................................................... 196

5.4 Summary ........................................................................................................... 197

6 Modeling Application Data 199

6.1 Application Architecture in SAP S/4HANA ......................................... 200

6.2 Field Labels ....................................................................................................... 204

6.2.1 Determination of a Field Label ................................................... 204

6.2.2 Length of a Field Label .................................................................. 206

6.3 Field Semantics ............................................................................................... 208

6.3.1 Quantities and Amounts .............................................................. 208

6.3.2 Aggregation Behavior ................................................................... 209

6.3.3 System Times ................................................................................... 211

6.3.4 Text and Languages ....................................................................... 213

6.3.5 Information for the Fiscal Year .................................................. 213

6.4 Foreign Key Relations .................................................................................. 214

10

Contents

6.5 Text Relations ................................................................................................. 220

6.6 Composition Relations ................................................................................ 222

6.7 Time-Dependent Data ................................................................................. 225

6.8 Hierarchies ........................................................................................................ 226

6.8.1 Leveled Hierarchies and Parent-Child Hierarchies .............. 227

6.8.2 Example of a Parent-Child Hierarchy ....................................... 230

6.8.3 Determination of a Hierarchy .................................................... 233

6.8.4 Test a Hierarchy .............................................................................. 235

6.9 Summary ........................................................................................................... 237

7 The Virtual Data Model in SAP S/4HANA 239

7.1 Why a Virtual Data Model? ....................................................................... 239

7.2 Structure of the Virtual Data Model ..................................................... 241

7.2.1 Basic Interface Views .................................................................... 242

7.2.2 Composite Interface Views ......................................................... 245

7.2.3 Consumption Views ...................................................................... 246

7.2.4 Other Types of VDM Views ......................................................... 248

7.3 Naming in the Virtual Data Model ........................................................ 249

7.3.1 Field Names ...................................................................................... 249

7.3.2 Names of VDM Views ................................................................... 252

7.3.3 Parameter Names ........................................................................... 254

7.3.4 Association Names ........................................................................ 254

7.4 Basic Interface View for the Sales Order ............................................. 254

7.4.1 View Annotations ........................................................................... 255

7.4.2 Structure of the Sales Order View ............................................ 258

7.4.3 Specialization ................................................................................... 259

7.4.4 Field Annotations ........................................................................... 260

7.5 Tips for Finding Virtual Data Model Views ........................................ 262

7.5.1 View Browser Application ........................................................... 262

7.5.2 Search in the ABAP Development Tools ................................. 265

7.5.3 Search Views with Specific Annotations ................................ 268

7.5.4 ABAP Where-Used List .................................................................. 269

7.6 Summary ........................................................................................................... 270

11

Contents

8 Modeling Analytical Applications 271

8.1 Analytics in SAP S/4HANA ......................................................................... 272

8.2 Analytic Views ................................................................................................. 273

8.2.1 First Analytic Cube View .............................................................. 273

8.2.2 Test Environment for Analytic Views ....................................... 275

8.2.3 Analytic Cube Views ...................................................................... 279

8.2.4 Analytic Dimension Views ........................................................... 282

8.2.5 Analytic Model in the Test Environment ................................ 290

8.2.6 Consistency of the Analytic Model ........................................... 293

8.3 Analytic Queries ............................................................................................. 295

8.3.1 Definition of an Analytic Query ................................................. 296

8.3.2 Initial Layout of a Query ............................................................... 299

8.3.3 Filter, Select Options, Parameters ............................................. 302

8.3.4 Calculation of Measures .............................................................. 308

8.3.5 Restricted Measures ...................................................................... 311

8.3.6 Exception Aggregation ................................................................. 313

8.3.7 Analytic Query Selecting from Dimension Views ................ 319

8.4 Analytic Infrastructure ................................................................................ 321

8.5 Summary ........................................................................................................... 323

9 Modeling Transactional Applications 325

9.1 Transactional Applications ........................................................................ 325

9.2 Transactional Infrastructure in SAP S/4HANA ................................. 327

9.3 Transactional Object Models .................................................................... 331

9.3.1 Define Object Models .................................................................... 331

9.3.2 Define Transactional Object Models ........................................ 335

9.3.3 Define Static Properties ................................................................ 341

9.3.4 Set and Check Exclusive Locks .................................................... 348

9.3.5 Implement Data Determinations and Validations ............. 350

9.3.6 Model and Implement Actions .................................................. 358

9.3.7 Control Properties Dynamically ................................................. 361

9.3.8 Implement Authority Checks ...................................................... 364

9.3.9 Define Calculated Fields ............................................................... 368

12

Contents

9.4 Transactional Service Models ................................................................... 370

9.4.1 Define Transactional Service Models ....................................... 370

9.4.2 Generate an OData Service ......................................................... 375

9.4.3 Define Calculated Fields ............................................................... 377

9.4.4 Define an SAP Fiori Application ................................................. 379

9.5 Summary ........................................................................................................... 385

10 CDS-Based Search Functionality 387

10.1 Modeling Value Help Views ...................................................................... 388

10.1.1 Sample CDS Model and OData Exposure Overview ........... 388

10.1.2 CDS Value Help Modeling Details ............................................. 391

10.2 Free-Text Search Functionality in OData Services .......................... 396

10.3 Summary ........................................................................................................... 402

11 Extensions of CDS Views 403

11.1 Extension Options and Released CDS Views ..................................... 404

11.1.1 Key User Extensions ...................................................................... 404

11.1.2 Extend an On-Premise Installation .......................................... 405

11.1.3 Released CDS Views ....................................................................... 405

11.2 CDS Extend Views with Custom Fields ................................................ 407

11.2.1 Extension Field ................................................................................ 408

11.2.2 View Stack ......................................................................................... 410

11.2.3 Indirect CDS View Extensions .................................................... 412

11.2.4 Extend the Extension Include View .......................................... 414

11.2.5 Extension Association ................................................................... 416

11.2.6 Stability of Indirect CDS View Extension ................................ 417

11.3 Usage of CDS Extend Views ...................................................................... 417

11.3.1 Missing Extension Association .................................................. 418

11.3.2 Missing Extension Include View ................................................ 419

11.3.3 Missing Foreign Key Fields .......................................................... 420

11.3.4 Analytic Query Views .................................................................... 420

11.3.5 Extension with Standard Fields ................................................. 421

13

Contents

11.3.6 Extensions of Released CDS Views ........................................... 423

11.3.7 Extensions with Calculated Fields ............................................ 424

11.4 Summary ........................................................................................................... 425

12 Automated Testing 427

12.1 Fundamentals of the Test Double Framework ................................. 428

12.2 Overview of the Test Sample ................................................................... 429

12.3 Test CDS Views ................................................................................................ 432

12.3.1 Create a Test Design ...................................................................... 432

12.3.2 Implement ABAP Unit Tests ........................................................ 434

12.3.3 Test CDS Access Controls ............................................................. 440

12.3.4 Test CDS Views with Conversion Functions for

Currencies and Quantity Units .................................................. 443

12.3.5 Test Data Sources with Null Values ......................................... 446

12.4 Test ABAP Logic with SQL Accesses to CDS Views ........................... 448

12.5 Summary ........................................................................................................... 451

13 Troubleshooting 453

13.1 Troubleshoot Implementations of CDS Models ............................... 453

13.2 Troubleshoot Activation Issues ............................................................... 461

13.3 Summary ........................................................................................................... 466

Appendices 467

A CDS Annotation Reference ........................................................................ 467

B The Authors ...................................................................................................... 477

Index .................................................................................................................................. 479

479

Index

?= Operator .................................................. 174

@AbapCatalog.compiler.compare

Filter .............................. 103, 104, 256, 467

@AbapCatalog.preserveKey .......... 60, 467

@AbapCatalog.

sqlViewAppendName ................ 415, 467

@AbapCatalog.

sqlViewName ........... 33, 37, 58, 136, 467

@AccessControl.

authorizationCheck ......... 160, 179, 467

@AccessControl.

privilegedAssociations ...................... 182

@Aggregation ............................................ 210

@Aggregation.default ................... 279, 468

@Analytics.dataCategory ............ 176, 279,

282, 290, 468

#CUBE ....................................................... 274

@Analytics.query ................. 115, 175, 296,

387, 395, 468

@AnalyticsDetails.

exceptionAggregationSteps ... 316, 468

@AnalyticsDetails.query.

axis .................................................... 300, 468

@AnalyticsDetails.

query.display ................................ 301, 468

@AnalyticsDetails.

query.formula .............................. 310, 469

@AnalyticsDetails.

query.hidden ......................................... 469

@AnalyticsDetails.

query.sortDirection ................... 301, 469

@AnalyticsDetails.

query.totals ................................... 301, 469

@ClientHandling.algorithm ........ 68, 189,

469

@ClientHandling.type ................... 189, 469

@Consumption.

defaultValue .................................. 306, 469

@Consumption.derivation ......... 307, 469

@Consumption.deriviation.

lookupEntity .......................................... 177

@Consumption.filter ........... 306, 395, 469

@Consumption.hidden ...... 306, 401, 469

@Consumption.valueHelp .......... 394, 396

@Consumption.valueHelp

Definition .......... 177, 306, 393, 394, 396

@Consumption.valueHelpDefinition.

additionalBinding ................................ 395


additionalBinding.element .............. 469


additionalBinding.localElement .... 469


association .............................................. 469


entity.element ....................................... 470


entity.name ............................................ 470

@DefaultAggregation .......... 210, 280, 320

@EndUserText .............................................. 53

@EndUserText.label ..... 33, 142, 204, 205,

470

@EndUserText.quickInfo ............. 206, 470

@Environment.systemField ...... 110, 111,

138, 306, 470

@Hierarchy.parentChild ............... 229, 470

@Hierarchy.parentChild.directory .... 177

@MappingRole .......................................... 157

@Metadata.allowExtensions ..... 148, 149,

372, 471

@Metadata.

ignorePropagatedAnnotations ...... 140,

144, 146, 257, 471

@Metadata.layer .............................. 149, 471

@MetadataExtension.

usageAllowed ................................ 150, 471

@ObjectModel.alternativeKey ... 131, 132

@ObjectModel.alternativeKey.

element .................................................... 471

@ObjectModel.alternativeKey.id ....... 471

@ObjectModel.alternativeKey.

uniqueness ............................................. 471

@ObjectModel.association.type ........ 223,

331, 372, 471

@ObjectModel.compositionRoot ..... 223,

372, 471

480

Index

@ObjectModel.compositionRoot,

true ............................................................. 331

@ObjectModel.createEnabled ... 341, 471

@ObjectModel.dataCategory .... 177, 285,

472

#HIERARCHY .......................................... 229

#TEXT ........................................................ 221

@ObjectModel.deleteEnabled ............ 341,

362, 472

@ObjectModel.enabled .......................... 362

@ObjectModel.foreignKey.

association ................. 216, 391, 393, 472

@ObjectModel.hierarchy.

association .................................... 229, 472

@ObjectModel.mandatory ......... 362, 472

@ObjectModel.modelCategory ........... 472

@ObjectModel.readOnly .... 342, 362, 472

@ObjectModel.representativeKey .... 218,

222, 282, 285, 472

@ObjectModel.text .................................. 284

@ObjectModel.text.association ......... 220,

389, 391, 472

@ObjectModel.text.element ..... 220, 287,

472

@ObjectModel.transactionalProcessing

Delegated ....................................... 372, 472

@ObjectModel.transactionalProcessing

Enabled ........................................... 335, 472

@ObjectModel.updateEnabled .......... 341,

362, 473

@ObjectModel.usageType .................... 257

@ObjectModel.usageType.

dataClass ............................... 139, 257, 473


serviceQuality ..................... 138, 257, 473


sizeCategory ........................ 139, 257, 473

@ObjectModel.virtualElement .......... 377,

473

@ObjectModel.virtualElementCalculated

By ...................................................... 377, 473

@ObjectModel.writeActive

Persistence .................................... 335, 473

@OData.publish ........... 137, 388, 397, 473

true ............................................................. 375

@Search.defaultSearchElement ......... 397,

473

@Search.fuzzinessThreshold .... 397, 399,

473

@Search.ranking ............................. 399, 473

@Search.searchable ........................ 397, 474

@Semantics ................................................. 243

@Semantics.amount ............................... 209

@Semantics.amount.

currencyCode ............................... 115, 474

@Semantics.businessDate.

from ................................................. 225, 474

@Semantics.businessDate.to ..... 225, 474

@Semantics.currencyCode ........ 115, 208,

474

@Semantics.fiscal ..................................... 213

@Semantics.fiscal.period ....................... 474

@Semantics.fiscal.year ........................... 474

@Semantics.fiscal.yearPeriod .............. 474

@Semantics.fiscal.yearVariant ............ 474

@Semantics.language .......... 213, 222, 474

@Semantics.quantity .............................. 208

@Semantics.quantity.

unitOfMeasure ......... 114, 127, 135, 475

@Semantics.systemDate ....................... 212

@Semantics.systemDate.createdAt ... 475

@Semantics.systemDate.

lastChangedAt ........................................ 475

@Semantics.systemDateTime ............. 211

@Semantics.systemDateTime.

createdAt .................................................. 475

@Semantics.systemDateTime.

lastChangedAt ........................................ 475

@Semantics.systemTime ...................... 212

@Semantics.systemTime.createdAt ... 475

@Semantics.systemTime.lastChanged

At ................................................................. 475

@Semantics.text ............................. 213, 475

@Semantics.unitOfMeasure ........ 53, 114,

127, 135, 208, 475

@Semantics.user.createdBy ................. 475

@Semantics.user.lastChangedBy ....... 475

@UI.facet ............................................ 380, 475

@UI.fieldGroup ................................ 380, 475

@UI.headerInfo ................................ 380, 475

@UI.hidden .................................................. 475

481

Index

@UI.identification ................ 380, 381, 476

@UI.lineItem ........................... 380, 381, 476

@UI.lineItem.importance ............ 149, 476

@UI.selectionField .......................... 380, 476

@VDM.lifecycle.contract.type .... 247, 249

@VDM.private .................................. 248, 476

@VDM.viewExtension .................. 248, 476

@VDM.viewType .................. 242, 245, 246,

248, 476

#AVG ..................................................... 210, 313

#COUNT ....................................................... 313

#FIRST ........................................................... 313

#LAST ............................................................. 314

#MAX .................................................... 279, 313

#MIN ..................................................... 279, 313

#NONE .......................................................... 279

#NOP ............................................................. 279

#STD ............................................................... 313

#SUM .................................................... 279, 313

$parameters ................................................ 107

$session.client ............................................... 65

$session.system_date ................................ 65

$session.system_language ....................... 65

$session.user .................................................. 65

A

A2A communication ............................... 325

ABAP application infrastructure ....... 203,

241

ABAP application server ........................ 330

ABAP class ........................................... 338, 348

ABAP Data Dictionary

(ABAP DDIC) ........................ 137, 243, 338

ABAP Development Tools (ADT) ... 21, 26,

30, 154, 453

search ........................................................ 265

ABAP documentation ................................ 34

ABAP in Eclipse ................................. 339, 347

ABAP infrastructure .............. 355, 372, 380

ABAP Managed Database Procedures

(AMDP) ..................................................... 187

procedure ................................................ 191

ABAP platform ..... 328, 329, 330, 348, 370

ABAP RESTful programming

model ........................................................ 328

ABAP system field ..................................... 111

ABAP unit test ............................................ 429

implement ............................................... 434

ABAP Workbench ........................... 26, 28, 30

Access condition ..................... 154, 166, 169

literal values ........................................... 174

Access control ................... 66, 153, 167, 364

mode of action ...................................... 157

Access rule ................................................... 154

Action ................................ 325, 326, 331, 358

dynamic control .................................... 362

parameters .............................................. 359

Activation log ............................................. 461

Activation problem .............................. 41, 89

Active annotation ..................................... 260

Addition ................................................. 63, 100

Aggregation ................................................. 209

level ............................................................... 82

type ............................................................ 210

Alias function ................................................ 34

AMDP class method ................................. 190

Amount field ............................ 208, 209, 251

Analytic dimension view ....................... 282

Analytic engine ... 115, 175, 203, 227, 235,

322

value help ................................................ 395

Analytic interface ...................................... 322

Analytic measure ...................................... 211

Analytic model .................................. 290, 293

Analytic processor .................................... 322

Analytic query ......................... 175, 180, 295

calculate measures .............................. 308

define ......................................................... 296

define variables ..................................... 302

exception aggregation ....................... 313

layout ........................................................ 299

restricted measures ............................. 311

select from dimension views ............ 319

view ............................................................ 420

Analytical application ............................. 271

Analytics ....................................................... 271

data category ......................................... 279

modeling .................................................. 272

tools ........................................................... 322

Annotated formula .................................. 311

482

Index

Annotation .................................................. 244

active .... 53, 55, 125, 126, 142, 143, 146,

149, 150, 380

API .............................................................. 269

array ................................................ 131, 140

authorization ......................................... 161

consistency aspects ............................. 144

default value ................................. 134, 135

definition ....................................... 125, 126

document ................................................. 138

domain .................................. 127, 128, 149

effect .......................................................... 136

errors ......................................................... 456

explicit ...................................................... 205

field ............................................................. 208

fiscal year ................................................. 213

foreign key ............................................... 216

fully qualified annotation name .... 130

grouping ................................................... 130

main ........................................................... 130

name .......................................................... 128

propagation .................................. 204, 281

propagation logic ...... 53, 134, 136, 140,

459

root ............................................................. 130

runtime environment ......................... 137

scope .......................................................... 135

search ........................................................ 399

semantic ................................................... 243

subannotation ....................................... 130

system times ........................................... 211

transactional ................................ 342, 372

type ............................................................. 132

undefined ................................................. 454

value ................................................ 130, 132

value help ................................................ 394

API state ........................... 241, 256, 405, 406

Not released ............................................ 241

released ..................................................... 241

Application architecture ........................ 199

Application data modeling .................... 199

Application infrastructure .................... 199

Application programming interface

(API) ............................................................ 240

ASPECT USER ............................................... 173

Assert statement ....................................... 439

Association .................... 25, 55, 85, 244, 331

cardinality ................................................. 87

default filter .................................. 104, 105

define ........................................................... 74

define custom ......................................... 423

definition .................................................... 85

exposed ..................................................... 407

exposure ..................................................... 88

extension .................................................. 416

in ABAP code ........................................... 105

in CDS view ................................................ 92

name ................................................... 86, 254

remove ........................................................ 88

target ........................................................... 87

Authorization .................................... 153, 325

analytical queries ................................. 178

control ............................................. 326, 331

database level ........................................ 157

extension fields ...................................... 178

field ............................................................. 154

object ............................................... 154, 364

protection ................................................ 160

role .............................................................. 157

test .............................................................. 440

Authorization check .... 161, 184, 364, 368

change ....................................................... 179

test .............................................................. 440

Automated testing .................................... 427

Average calculation .................................. 209

B

Basic interface views ............. 242, 254, 332

redundancies .......................................... 244

Behavior modeling ................................... 329

BOPF editor .................................................. 328

Business logic ...... 325, 326, 327, 330, 331,

368, 370

Business object .............. 223, 326, 331, 370

BOPF ........................................ 328, 336, 346

Business Object Processing Framework

(BOPF) .............................................. 328, 338

runtime ........................................... 329, 347

service layer ......................... 329, 339, 368

synchronization .................................... 347

test environment ................ 339, 347, 349

483

Index

Business process .............................. 326, 370

Business time-dependent view ........... 225

C

C1 contract .................................................. 405

Calculated field ................................. 120, 325

extend ....................................................... 424

restrictions .............................................. 378

Camel case notation ................ 34, 189, 250

Cardinality ....... 23, 77, 86, 89, 97, 101, 172

foreign key association ...................... 217

TO ONE ..................................................... 103

TO ONE or TO MANY ............................. 79

Case statement ............................................. 63

Cast function .............................................. 204

Cast operation .................. 61, 140, 143, 400

nest ............................................................... 63

CDS access control ........................... 123, 256

analytics .................................................. 175

block standard data selection ......... 180

decoupling from input ....................... 182

disable ...................................................... 442

enable ....................................................... 441

field level .................................................. 178

implementation .................................... 162

inheritance ........................... 162, 165, 169

path expression .................................... 167

SAP-delivered CDS models ................ 179

testing .............................................. 183, 440

without authorization objects ........ 173

CDS editor ...................................... 32, 38, 188

auto-completion ...................................... 33

code completion ................................... 455

mass activation ....................................... 42

CDS element .................................................. 85

CDS entity ....................................................... 55

CDS extend view ... 55, 136, 178, 403, 405,

407, 414

activate .................................................... 415

calculated fields .................................... 424

components ............................................ 415

usage ......................................................... 417

CDS metadata extension ...... 55, 126, 146,

403, 456

create ........................................................ 147

layer assignment .................................. 149

names ....................................................... 147

CDS model ............................ 21, 56, 199, 328

activate ........................................................ 35

activation logic ..................................... 463

create ............................................................ 30

error message ........................................ 457

inconsistencies ...................................... 146

key .............................................................. 158

names .................................................... 34, 58

parameters .............................................. 107

reuse .......................................................... 117

SAP-delivered ......................................... 150

static complexity .................................. 117

template ...................................................... 32

transparency ............................................. 60

troubleshoot ........................................... 453

versions ....................................................... 41

CDS Navigator tab ..................................... 416

CDS role ......................................................... 154

can’t be fulfilled ..................................... 180

inheritance .............................................. 170

multiple roles ......................................... 161

path expressions ................................... 172

CDS session variable ............................ 64, 65

CDS syntax ...................................................... 56

embed conversion functions ............ 112

CDS table function ........... 55, 68, 106, 121,

187, 327

associations and annotations ........ 190

client-dependent ................................... 189

components ............................................ 189

implement ............................................... 188

test .............................................................. 192

CDS test double framework ........ 429, 432,

435

CDS view ......................................... 21, 55, 327

aggregating ............................................... 82

API .............................................................. 405

associations ............................................... 92

change ......................................................... 38

create .............................................. 30, 42, 47

direct extension ..................................... 410

explicit joins .............................................. 97

extend ....................................................... 407

extension ........................................ 196, 403

hierarchy ..................................................... 42

inconsistency ......................................... 458

indirect extension ............. 412, 414, 417

484

Index

CDS view (Cont.)

label ............................................................ 207

name .......................................................... 252

path expressions ..................................... 95

released extensions .............................. 423

search ........................... 262, 265, 268, 269

stack .......................... 48, 49, 140, 151, 434

test ................................................................ 43

test implementation ........................... 432

with inner join ......................................... 80

CDS_CLIENT ................................ 67, 189, 256

Characteristic .............................................. 277

Check function ........................................... 453

Check table ................................................... 214

Child view ..................................................... 222

CL_ABAP_UNIT_ASSERT ........................ 439

CL_CDS_TEST_ENVIRONMENT ........... 436

Class method ..................................... 190, 435

Class teardown method .......................... 439

Client ................................................................ 66

Client field ............................................... 61, 68

Client handling .......................... 66, 189, 255

harmonize ................................................. 68

Client-dependent data ............................ 255

Code ................................................................ 251

Code completion ....................................... 455

Comment ....................................................... 58

Complexity metrics .................................... 49

Composite interface view ...................... 245

Composition association ....................... 223

Composition relation .............................. 222

Compositional relationship ........ 326, 338

Consistency check ........................... 357, 359

analytic ..................................................... 274

Consistency condition ............................ 294

Consistency validation ........................... 357

Consumption view ................................... 246

compatability ........................................ 246

CONTAINS function ................................. 400

Conversion function ................................ 112

analytical queries ................................. 115

error handling ........................................ 115

parameters .............................................. 114

test .............................................................. 443

Cost center ................................................... 234

Cost center hierarchy .............................. 230

COUNT_DISTINCT ..................................... 210

Counter ....................................... 251, 314, 320

CREATE statement ................... 96, 102, 103

Creation Wizard ........................................... 27

CRUD operations ....................................... 326

Cube ................................................................ 280

Cube view ................................... 271, 273, 279

analytic ..................................................... 274

define ......................................................... 273

Currency conversion ...................... 113, 114

test .............................................................. 444

Currency field ............................................. 208

Custom field ................................................ 196

Custom query ............................................. 421

Customer namespace ................................ 25

D

Data control language (DCL) ................. 154

Data definition ................................. 407, 414

Data definition language source

(DDLS) ............................................ 31, 36, 58

Data definition name ............................... 252

Data element ........................................ 61, 204

field label .................................................. 206

medium text ........................................... 206

Data model ..................................................... 55

define ........................................................... 22

implement ................................................. 25

Data preview .................................................. 44

Data record ..................................................... 44

missing ........................................................ 87

Data redundancy ....................................... 172

Data selection ................................................ 55

privileged ....................................... 174, 181

test .................................................... 438, 441

Data source .................................................. 420

Database procedure .................................. 191

Database SQL view .................................... 464

Database table

create ........................................................... 26

editor ............................................................ 28

simplify ....................................................... 29

Decoupling option .......................... 433, 443

isolated CDS view .................................. 433

test double ............................................... 434

Default filter ...................................... 104, 105

DEFAULT TRUE ........................................... 165

DEFINE VIEW ................................................. 57

485

Index

Delegation approach ............................... 170

Denormalization ................................... 76, 98

Dependency Analyzer ................................ 48

Derivation .................................................... 307

Determination ........................ 351, 357, 359

dependency ............................................. 355

document number ............................... 352

execution times .................................... 351

Dimension .......................................... 277, 280

analytic .................................................... 282

consistency ............................................. 293

field ................................................... 280, 282

multiple key fields ................................ 295

replace ...................................................... 295

view ................................................... 271, 319

Display attribute ....................................... 301

Display authorization ............................. 155

DISTINCT statement ................................... 70

Duplicate record ........................................... 74

Duration ....................................................... 251

Dynamic control of properties ............ 325

Dynamic property .................................... 362

Dynamic variable ...................................... 306

E

Element annotation ................................. 279

Enqueue object ....................... 325, 348, 361

administration ...................................... 349

Entity key ..................................................... 225

Entity properties ....................................... 346

Entity relationship model (ERM) .... 25, 43

Entity view ................................................... 215

Enumeration value .................................. 133

Exception aggregation ......... 313, 318, 320

aggregation behavior ........................ 313

steps ........................................................... 316

exceptionAggregationBehavior .......... 313

exceptionAggregationSteps ................. 316

Exchange rate ............................................. 445

Exclusive lock .................................... 326, 331

Extensibility

CDS view .................................................. 403

on-premise .............................................. 405

standard field ........................................ 421

Extension association .......... 412, 414, 416

missing ..................................................... 418

Extension field ........................................... 408

Extension include view .................. 89, 180,

259, 412

extend ....................................................... 414

missing ..................................................... 419

F

F2 help .............................................................. 52

Fact view

analytic ..................................................... 290

Factory calendar ........................................ 195

Field

annotation ........................... 208, 243, 260

custom ...................................................... 407

enlargement ........................................... 407

properties ................................................. 346

rename ...................................................... 463

semantics ................................................. 208

Field label ..................................................... 204

determine ................................................ 204

length ........................................................ 206

Field name .................................................... 249

abbreviation ........................................... 250

Field variable ............................................... 306

Filter criteria ....................................... 120, 121

Fiscal year ..................................................... 213

Foreign key .................................................. 214

table ........................................................... 214

view ............................................................ 215

Foreign key association ...... 216, 218, 282,

286

define ......................................................... 217

use .............................................................. 219

Foreign key field ........................................ 215

missing ..................................................... 420

Formula in query ...................................... 310

Free-text search ...................... 387, 396, 397

Full access rule ............................................ 179

Function

FLTP_TO_DEC ........................................... 62

unit_conversion .................................... 114

Fuzziness ...................................................... 397

Fuzzy search ................................................ 387

G

Global test class ......................................... 434

GROUP BY statement .......................... 57, 83

486

Index

H

Helper field .................................................. 401

Hierarchy ...................................................... 226

association .............................................. 229

base entity ............................................... 228

create ........................................................... 42

determine ................................................. 233

directory ................................ 228, 233, 236

node ................................................. 228, 233

node view ................................................. 229

structure ................................................... 229

test .............................................................. 235

view ............................................................ 228

I

I_CalendarDate .......................................... 303

Identifier field ............................................. 250

InA protocol ................................................. 322

Inconsistency .................................... 144, 464

remove ...................................................... 145

technical ................................................... 145

Indicator ....................................................... 251

Infrastructure

analytic ..................................................... 321

analytics ................................................... 271

transactional .......................................... 327

Inheritance logic

side effects ............................................... 165

Instance authorization ........................... 153

Integration test ................................ 183, 434

Interface view ............................................. 245

Intermediate view ..................................... 413

J

Join ............................................................. 49, 76

cross ............................................................. 77

inner ................................... 76, 98, 101, 160

left outer ................................ 76, 78, 80, 98

multiple data sources ........................... 81

optimize logic ........................................ 104

right outer ................................................. 76

K

Key

alternative ............................................... 132

representative ........................................ 257

Key definitions ...................................... 34, 75

align ............................................................. 60

Key field ........................................................... 59

representative .............................. 282, 285

Key performance indicator (KPI) ......... 272

Key user ......................................................... 272

Key user extension ................................... 404

L

Label text ................................................. 53, 61

Leading model ............................................ 241

Leveled hierarchy ...................................... 227

Library functions ............................. 355, 357

Local unit test class ................................... 435

Lock ................................................................. 348

node level ................................................. 350

M

Manual test .................................................. 184

MappingRole ............................................... 470

Mass activation ............................................ 42

MAX ................................................................ 210

Maximum ..................................................... 209

Measure ............................................... 279, 315

analytic ..................................................... 274

calculate ................................................... 308

restricted .................................................. 311

Memory overflow ........................................ 84

Meta information ...................................... 199

Metadata ....................................................... 202

enhancement .......................................... 372

extension .................................................. 381

MIN .................................................................. 210

Minimum ..................................................... 209

M-N relationship .......................................... 89

Model consistency .................................... 293

Model transformation ............................. 242

Modeling pattern ....................................... 219

487

Index

N

Name list .................................................. 68, 71

Node type ..................................................... 234

NONE ............................................................. 210

NULL value ........ 63, 79, 115, 140, 143, 459

annotating .............................................. 134

handling ...................................................... 80

test ............................................................. 446

Number range ............................................ 353

O

Object ............................................................. 223

Object model .............................................. 331

Object type

STOB ............................................................. 59

VIEW ............................................................. 59

OData ................................. 322, 328, 329, 380

display parameter ...................... 392, 393

entity set .................................................. 390

entity type ............................................... 390

input and output parameter ........... 392

property ................................................... 391

protocol .................................................... 206

service metadata .................................. 391

OData service ........... 34, 137, 200, 370, 379

generate ................................................... 375

search ........................................................ 396

OLAP processor .......................................... 322

ON condition .......................................... 86, 96

Open dialog box ........................................ 265

Open SQL ......................... 21, 46, 66, 67, 110,

329, 364, 448

interface ....................... 123, 138, 157, 438

test double framework .............. 429, 448

P

Parameter .......................... 65, 106, 170, 302

annotations ............................................ 207

association definitions ...................... 110

name ......................................................... 254

names ....................................................... 107

variable .................................................... 306

Parent node ................................................. 230

Parent view .................................................. 222

Parent-child hierarchy ......... 227, 228, 230

Path expression ............... 46, 85, 86, 93, 96,

98, 105, 169, 182

CDS role .................................................... 172

parameters .............................................. 109

Performance aspects ................ 76, 84, 116,

158, 173

Persistency model .................................... 122

Placeholder .................................................. 193

Point in time ...................................... 211, 251

Prediction procedure ............................... 196

Predictive analytics .................................. 195

Prefix ..................................................... 253, 424

A_ ................................................................ 247

C_ ................................................................ 246

E_ ................................................................ 248

I_ ................................................................. 245

P_ ................................................................ 248

X_ ................................................................ 248

PRESERVING TYPE ....................................... 61

Privileged access ........................................ 161

Programming model ............................... 200

Project Explorer ..................................... 38, 39

Projection ..................................................... 370

Propagation logic ............................. 125, 139

Proxy object ................................................ 428

Q

Qualifier ............................................... 250, 251

Quantity field ..................................... 208, 251

Query

analytic .................................. 271, 295, 296

display attribute ................................... 177

layout ............................................... 299, 300

monitor .................................................... 297

settings ..................................................... 295

variable ..................................................... 177

Quick info ..................................................... 206

R

Read access ......................................... 156, 200

Redundancy ....................................... 244, 259

Reference data model ................................. 22

entities ......................................................... 23

implementation ....................................... 24

488

Index

Regression .................................................... 184

issue ................................................. 427, 434

Regular expression ................................... 195

Released ..................................... 404, 405, 406

Remote API view ........................................ 247

REPLACING ROOT WITH ......................... 165

Representation term ................................ 250

Representational State Transfer

(REST) ...................................... 325, 329, 348

Representative key field ............... 218, 221

Responsive design .................................... 380

Root node ..................................................... 228

Root view ...................................................... 222

Runtime behavior ..................................... 257

S

SAP Analysis for Microsoft Office ....... 298

SAP Cloud Platform .................................. 383

SAP Fiori ..................................... 200, 348, 383

architecture ............................................. 200

element ..................................................... 202

SAP Fiori application ............. 206, 240, 404

annotations ............................................ 380

define ......................................................... 379

SAP Fiori element ............................ 380, 395

SAP Gateway ............................. 203, 206, 376

client .......................................................... 377

hub .............................................................. 376

Service Builder ....................................... 376

SAP HANA ....................... 241, 256, 327, 330

conversion functions ............................. 62

execution plan ....................................... 116

native functions .................................... 187

SAP HANA optimizer ..................... 119, 197

SAP HANA SQL Console .......................... 256

SAP HANA Studio ...................................... 192

SAP HANA table function ... 106, 187, 191

SAP S/4HANA .............................................. 327

analytics ................................................... 272

architecture ................................... 200, 203

programming model ........................... 199

virtual data model ............................... 239

SAP S/4HANA Cloud ................................ 406

SAP Web IDE ................................................ 383

SAPUI5 ................................................. 348, 384

Scope .............................................................. 473

ELEMENT .................................................. 135

Search field ................................................... 397

Search functionality ................................. 387

check .......................................................... 401

Search request ............................................ 398

Search results .............................................. 399

Search scope ................................................ 401

SELECT FROM ................................................ 57

SELECT statement ................................. 45, 56

change ......................................................... 46

optimize .................................................... 119

SAP HANA database ............................ 122

test .............................................................. 438

SELECT-* statements ................................... 71

Selection result ........................................... 439

Selection statement .................................. 157

Self-join .......................................................... 417

Semantics ..................................................... 208

Service Adaptation Definition Language

(SADL) .......... 34, 182, 330, 387, 396, 457

text denormalization .......................... 391

Service infrastructure .............................. 203

Session variable ................................ 189, 194

CDS_CLIENT ............................................ 255

Setup method ................................... 436, 442

Side effect ........................ 325, 350, 359, 361

Smart control .............................................. 202

Smart template ........................................... 202

SQL aggregation function ........................ 82

performance aspects ............................. 84

SQL Console .......................................... 45, 194

SQL view ................................ 36, 60, 136, 160

ABAP Data Dictionary ........................ 465

access ........................................................... 38

generated ................................................. 465

implicit join ............................................... 96

key definition ............................................ 60

name .......................................................... 252

SQLScript .................................... 187, 192, 195

Stability contract ............................. 405, 406

Standard aggregation .............................. 209

behavior .................................................... 279

types ........................................................... 210

Standard query ........................................... 276

Standard selection ...................................... 66

Star schema .................................................. 293

Start authorization ................................... 153

489

Index

Statement .................................................... 251

Static complexity ...................................... 117

Static property .................................. 341, 362

STRING_AGG .............................................. 195

Structured query language

(SQL) ............................................ 21, 55, 187

CREATE statement .................................. 37

dependency graph .................................. 49

dependency tree ....................................... 48

functions .................................................. 368

operation ................................................. 327

select request ......................................... 202

Suffixes ......................................................... 252

SUM ................................................................ 210

Summation ................................................. 209

Syntax ............................................................... 34

error ........................................................... 461

System field ................................................. 306

System load ................................................. 257

System time-dependency ..................... 225

System times .............................................. 211

annotations ............................................ 211

T

Table definition ............................................ 28

Table function ............................................... 62

Temporal data ............................................ 225

Test ABAP code .......................................... 448

Test automation ..................... 184, 427, 433

Test design ................................................... 432

Test double ............ 428, 434, 437, 448, 449

delete ......................................................... 440

environment .......................................... 449

Test double framework ....... 427, 428, 433

access controls ...................................... 440

advantages ............................................. 429

decoupling option ....................... 433, 434

null values ............................................... 446

Test environment ..................................... 297

analytic views ........................................ 275

Test sample .................................................. 429

Text and languages .................................. 213

Text association ............................... 221, 285

Text relations ............................................. 220

Text view ......................... 221, 284, 285, 290

Time-dependent data .............................. 225

Transaction

/IWFND/MAINT_SERVICE ................. 376

PFCG .......................................................... 154

RSRT .................................................. 297, 298

RSRTS_ODP ............................................. 235

RSRTS_ODP_DIS ...... 235, 275, 287, 291

SA38 ........................................................... 276

SACMSEL .................................................. 184

SE11 ...................................................... 26, 341

SE38 ............................................................ 276

SEGW ......................................................... 376

SM12 ........................................................... 349

Transactional application ...................... 325

Transactional consistency ..................... 326

Transactional model ................................ 370

Transactional object model ................. 325,

331, 370

actions ...................................................... 358

add annotations ................................... 335

authority check ..................................... 364


control properties ................................. 361

data determinations and

validations ......................................... 350

define ......................................................... 335

define static properties ...................... 341

locks ........................................................... 348

restrict ....................................................... 371

Transactional service model ........ 325, 370

annotations ............................................ 372


define ......................................................... 370

generate OData service ...................... 375

SAP Fiori app .......................................... 379

Transactional view layer ........................ 332

Transport object ........................................... 31

Trigger condition ............................. 351, 357

Troubleshooting ........................................ 453

activation issues ................................... 461

incorrect annotation ........................... 455

propogation logic of

annotations ....................................... 458

490

Index

U

UI annotation ................................... 202, 380

UNION .............................................................. 68

UNION ALL logic .......................................... 74

Union views ................................................... 68

association definitions ......................... 74

two-layer construction ......................... 73

Unit conversion ............................... 112, 114

Unit field ....................................................... 208

Universally unique identifier

(UUID) ....................................................... 250

V

Value help .................................. 387, 388, 399

annotation .............................................. 393

annotations ............................................ 393

definitions ............................................... 391

foreign key-based ................................. 392

modeling .................................................. 388

optimize ................................................... 394

Value view .................................................... 215

ValueListParameterDisplayOnly ....... 392,

393, 395

ValueListParameterInOut ............ 392, 395

Variable ......................................................... 302

analytic ..................................................... 302

derivation ................................................ 307

values ........................................................ 305

VDM view ..................................................... 240

extension ................................................. 248

extension include ................................. 248

find ............................................................. 262

names ........................................................ 252

private ....................................................... 248

reuse ........................................................... 241

View

Active Annotations ................................ 53

analytic ........................................... 271, 273

CDS Navigator ......................................... 51

domain ...................................................... 408

extension .................................................. 248

I_SalesOrder ............................................ 258

Outline ........................................................ 51

Problems ................................................... 457

Properties ................................................... 40

reuse ............................................................. 98

Search .......................................................... 50

stack ........................................................... 410

static complexity .................... 97, 98, 172

structure ................................................... 258

View annotation ........................................ 255

propogate ................................................ 262

View Browser app ...................................... 262

Virtual data model (VDM) .... 25, 239, 273,

327, 331

layers .......................................................... 241

naming ............................................ 242, 249

principles .................................................. 241

structure ................................................... 241

types ........................................................... 248

Virtual element .......................................... 378

sort and filter .......................................... 379

W

Warnings ....................................................... 459

Where-used list .................................... 50, 269

WITH PARAMETERS .................................. 107

WITH PRIVILEGED ACCESS .................... 181

Wrapper view .............................................. 194

Write access ................................................. 200

First-hand knowledge.

We hope you have enjoyed this reading sample. You may recommend or pass it on to others, but only in its entirety, including all pages. This reading sample and all its parts are protected by copyright law. All usage and exploitation rights are reserved by the author and the publisher.

Renzo Colle is currently responsible for the SAP S/4HA-NA programming model in the central architecture group. He studied business mathematics at the Uni-versity of Karlsruhe and has worked at SAP for more than 20 years in a wide variety of areas and roles. As the inventor of the Business Object Processing Frame-work (BOPF), he has worked on model-driven software

development and transactional applications for more than 15 years.

Jan Hrastnik is a member of the SAP S/4HANA suite’s architecture team, where he focuses on the virtual data model and the use of Core Data Services in ABAP ap-plications. He has worked in various SAP development areas for over 15 years. Jan’s work initially focused on developing the master data required for the produc-tion processes, before he took on overarching expert

tasks in central architecture topics. He then worked on SAP SuccessFac-tors Employee Central and native SAP HANA application development.

Ralf Dentzer has been working for several years in the central architecture group of the SAP S/4HANA suite, with a focus on the use of Core Data Services in SAP S/4HANA. Ralf joined SAP more than 20 years ago, where he began by developing HR applications for SAP R/3, SAP ERP, and SAP Business ByDesign. After that, his tasks shifted to questions of overall architecture for

new solutions. Ralf studied mathematics and received his doctorate from the University of Heidelberg.

Renzo Colle, Ralf Dentzer, and Jan Hrastnik

Core Data Services for ABAP490 Pages, 2019, $79.95 ISBN 978-1-4932-1798-4

www.sap-press.com/4822

https://www.sap-press.com/core-data-services-for-abap_4822/?utm_source=AWS&utm_medium=readingsample&utm_campaign=Browse%20the%20Book&utm_content=1798

“modeling application data” table of contents index the ... · 202 6 modeling application data...

Documents