“modeling transactional applications” contents index the

Browse the BookIn this chapter, you’ll learn how to develop transactional applications using CDS. You’ll see how the new ABAP RESTful application program-ming model provides the transactional infrastructure in SAP S/4HANA, and you’ll walk through step-by-step instructions for defining transactio-nal object models and behavior definitions.

Colle, Dentzer, Hrastnik

Core Data Services for ABAP525 pages, 2nd, updated and revised edition 2022, $89.95 ISBN 978-1-4932-2109-7

www.sap-press.com/5294

First-hand knowledge.

“Modeling Transactional Applications”

Contents

Index

The Authors

https://www.sap-press.com/core-data-services-for-abap_5294/?utm_source=AWS&utm_medium=readingsample&utm_campaign=Browse+the+Book&utm_content=2109

353

11

Chapter 11

Modeling Transactional Applications

This chapter explains how to use core data services (CDS) data models for

developing transactional applications, that is, applications that not only

read data but also change it based on the ABAP RESTful application pro-

gramming model.

In addition to modeling and executing data read accesses, CDS also pro-

vides the basis for modeling transactional aspects, thereby defining further

artifacts and the behavior of applications that change data. In general, data

can be created, changed, or deleted by direct user input via a user interface

(UI) or machine interfaces, for example, in application-to-application (A2A)

communication. Along with standard create, read, update, delete (CRUD)

operations, actions and functions also can be defined and exposed. Changes

explicitly requested by the consumer of one of these interfaces can result in

further implicit changes referred to as side effects in the context of this

chapter.

Chapter structureIn this chapter, you’ll learn how to define a transactional application. We’ll

cover what additional features need to be considered for transactional

applications in Section 11.1. In Section 11.2, you’ll learn about the transac-

tional infrastructure in SAP S/4HANA, which is based on the ABAP RESTful

application programming model works.

In Section 11.3 and Section 11.4, we describe how you can define transac-

tional object models and the related behavior definition with its static fea-

ture set and how you can implement the related business logic. The busi-

ness logic includes the implementation of drawing numbers; setting

enqueue locks, authorization checks, data derivations and data checks,

actions and functions; and the dynamic control of operations and properties.

The draft concept is also introduced and described in detail.

You’ll then use this sample application in various consumption-specific

scenarios using transactional service models as well as projection behavior

definitions in Section 11.5 and Section 11.6.

Finally, you’ll define specific OData services on top of these projections for

Web APIs in Section 11.7 and for SAP Fiori UI consumption with draft sup-

port in Section 11.8.

2109.book Seite 353 Mittwoch, 22. September 2021 7:13 19

354

11 Modeling Transactional Applications

11.1 Transactional Applications

In the previous chapters, we’ve shown how CDS can be used to model vari-

ous query and read accesses based on the capabilities of SQL. The question

that arises is whether and how this semantically rich model can now also be

used for supporting modifying accesses. Especially if you use these models

via Representational State Transfer-based (REST-based) interfaces on the

web, it becomes obvious that read and write operations should ideally be

based on the same model and resources. In this section, we discuss the

basics and specific aspects of transactional applications.

Business objects Business objects serve as the logical union of several entities. As an example

of a business object, we’ve already learned about the sales order, which con-

sists in our simplified example of header data, item data, and schedule lines.

These have a compositional relationship among themselves and are there-

fore existentially dependent on the respective parent entity. While busi-

ness objects play a rather subordinate role in querying and reading, they

form a context that is very important in modifying access. Usually, several

entities of a single business object are processed and modified together.

Other referenced or associated entities are often only read or have their

own implementation for modifying accesses.

Authorization

and lock

In addition to dedicated authorization controls, data modifications require

exclusive locks to ensure the transactional consistency of the data. In most

cases, both authorization control and locking behavior are implemented at

the business object level as a whole and not on the individual subentity

level of a business object. But there are also some use cases where a suben-

tity requires further dedicated authorization control or business objects

that support locking on the subentity level.

Business logic When modifying data entered by a user or transmitted via a machine inter-

face, the data usually isn’t simply taken over and persisted. Instead, the data

entered is checked, other data is determined and calculated that depends

on changed data or the business configuration, and so on. This is generally

referred to in this book as business logic. Not only is data of the directly

addressed business object changed, but, in many cases, other business

objects or entire business processes or subsequent processes are also trig-

gered or processed.

Actions You can change data and business objects using elementary operations

such as create, change, or delete (supplemented by reading, also known as

CRUD operations). In REST-based consumptions such as OData, these oper-

ations also correspond to the related HTTP verb on a resource, that is,

HTTP GET, POST, PUT/PATCH/MERGE, and DELETE. However, the business logic


355

11.2 Transactional Infrastructure in SAP S/4HANA

11

addressed is also very often exposed in more comprehensive operations

containing several fine granular changes that ensure consistent processing

of operations. We call this type of operation in the following actions.

Actions help to ensure that the business logic or consistency of multiple

changes isn’t left to the end user or consumer. Instead, they offer better

convenience regarding recurring changes. If required, actions can also offer

explicit extended authorization control.

FunctionsFunctions are enhancements supported by ABAP RESTful application pro-

gramming model and OData compared to pure SQL query and read access.

By definition, functions aren’t related to modifying access and don’t mod-

ify data in the system. These also can be provided and are part of the busi-

ness object model and business logic. In addition, functions could require

further dedicated authorizations that are different from pure read authori-

zation.

Challenges with CDS

and SAP S/4HANA

There are some additional challenges in the context of ABAP CDS and the

features and functions it provides. First, ABAP CDS currently only offers

data definitions such as CDS views and CDS table functions for data model-

ing. These entities only support defining query and read accesses. Thus,

from a purely technical point of view, the corresponding SQL operations for

changing data must take place directly via or on the underlying database

tables. The infrastructure can only delegate modifying accesses to the CDS

models automatically if the CDS models represent a simple projection of

these database tables. When using more complex SQL logic within the CDS

models, tasks such as view building, writing, or finding what to write to

which database table are no longer easy or are sometimes not possible at all.

In fact, in the SAP S/4HANA virtual data model (VDM), which is exposed as

a semantically rich model, the data model is fundamentally simplified in

many places regarding the existing database tables and persistency model

so that unions, joins, and other functions are also used to define the basic

VDM CDS models.


Application server

or database

At this point, you may wonder at what level the business logic should be

implemented and integrated. In the ABAP environment, the answer is rela-

tively clear that the business logic (as we understand it here) runs on the

application server and is implemented in ABAP. Reasons for this include the

scalability of the application servers and the extensive existing business

logic in SAP S/4HANA, which should of course be accessible and reused. This

approach isn’t contradictory to the goal of shifting the data-intensive logic


356


to the database. Optimally, SAP HANA is used, of course, for all read opera-

tions, and transformations are mapped as far as possible using SQL when

reading data. This also applies especially to authorization checks leveraging

the CDS access control language to avoid transferring data to the applica-

tion server to just remove it again. This pushdown approach can also be

used in a reasonable way in transactional logic.

Leveraging the SAP HANA Database

Consider the following example: In sales order processing, before the sales

order can be confirmed, the credit limit of the customer should be checked

based on the current order and the open items. The open items are calcu-

lated using aggregation (total of open items) in the SAP HANA database.

Only the result of the calculation is transferred to the application server. In

the application server in the corresponding check, this value is added to the

current order value and compared with the customer’s credit limit. If this

limit is exceeded, a corresponding message is generated, and, if necessary,

a corresponding status is set in the document.

ABAP RESTful appli-

cation program-

ming model

The ABAP platform enables the use of CDS models as the basis for modeling

transactional applications. In this context, all the requirements defined in

the previous section for transactional applications or for a corresponding

infrastructure must be considered. For this purpose, the ABAP RESTful

application programming model has been introduced as the logical succes-

sor of the ABAP programming model for SAP Fiori.

The ABAP RESTful application programming model is the common founda-

tion that the programming model of SAP S/4HANA is based on. It fosters

the application architecture to clearly separate the database model and

database layer, the application logic (business logic), and the UI. While the

separation of the UI (and related user experience [UX]) is technically

ensured by following the SAP Fiori technology approach leveraging OData

as the protocol of choice, the ABAP RESTful application programming

model allows you to further clearly separate the model and implementa-

tion of the different layers: the common general base model and applica-

tion logic (business logic) on one side, and the service-specific model and

application logic on the other side, while leaving the protocol implementa-

tion to the infrastructure. Thus, the ABAP RESTful application program-

ming model ensures that the complete application implementation is pro-

tocol agnostic and can also be reused when switching to a different protocol

or protocol version.


357


11

As for CDS entities, all ABAP RESTful application programming model-

specific artifacts needed for implementing transactional applications can

be created and edited via ABAP in Eclipse (aka ABAP Development Tools

[ADT]).

The ABAP RESTful application programming model supports both green-

field and brownfield implementations, which is a major enhancement com-

pared to the ABAP programming model for SAP Fiori. The consumption of

the ABAP RESTful application programming model implementation is

completely integrated into the ABAP language, and the type of implemen-

tation is hidden from the consumers of the application, whether it’s within

ABAP or via different channels such as OData.

SADL and ODataWe’ll focus on consuming the application via REST and OData as a web stan-

dard because the ABAP platform already offers end-to-end support for

these standards. The infrastructure takes over the complete protocol han-

dling and automatically forwards all operations, that is, read and write

requests, to the database or the provider implementation. All nontransac-

tional read and analytical requests are delegated directly to the SAP HANA

database via the ABAP SQL interface by leveraging the related CDS data

model. Transactional requests for reading or writing data are passed to the

transactional runtime and the transactional buffer in the application

server. This combines efficient processing of all persistent data by the SAP

HANA database with the advantages of the transactional runtime being

executed on the ABAP application server and the possible reuse of the exist-

ing business logic.

The Service Adaptation Definition Language (SADL) of the ABAP platform is

used to translate OData GET requests to SQL queries. SADL is an infrastruc-

ture for model-based reading and processing of data.

Additional Resources

For more information about SADL, visit the SAP Help Portal at https://

help.sap.com, and search for “Consuming Business Entities with SADL”

(http://s-prs.co/v529412).

For a schematic representation of the ABAP infrastructure for transactional

applications with the most important runtime components, see Figure 11.1.


358


Figure 11.1 ABAP Infrastructure: Transactional Applications

11.3 Transactional Object Models

This section introduces the transactional object models. You’ll learn how to

define and implement a business object and its business logic. First, you’ll

define the data model and introduce an object structure. In the transac-

tional world, we consequently make use of the newer CDS entity types (aka

CDS V2 models). You’ll then enhance the business object defined in this way

to support transactional changes.

ABAP RESTful Application Programming Model Runtime

BusinessLogic

R

CDS Views

R

R

R

R

Query/ReadAccess

Transactional Read/Modify Access

Direct Query/ReadAccess via SQL

Database Tables

SADL Query Runtime

SAP Gateway (OData)

ABAP RESTful Application Programming Model OData Provider

ABAP RESTful ApplicationProgramming Model

Provider Buffer and Data Access

ABAP RESTful ApplicationProgramming Model

Provider Runtime


359


11

11.3.1 Object Models

Compositional

structure

As already mentioned, business objects are defined as tree or compositional

structures of entities. To describe business objects in the network of CDS

entities and associations, the root of the composition tree is defined as

such, and the relevant associations are defined as compositions. The com-

position root is defined via the following:

define root view entity …

The composition relationship to subentities is defined via the to-parent

association of these subentities. This ensures that the compositional model

isn’t disrupted, and an entity might end up with multiple parent entities.

The parent relationship is defined as follows:

define view entity …as select from …association to parent … as … on …

As the cardinality to the parent is always [1..1], the syntax doesn’t allow the

cardinality to be specified. The necessary join condition is defined in the

association definition to the parent. Here, as a constraint, all key fields of

the parent entity need to be bound in the on condition.

The reverse composition from the parent to its compositional child is then

defined via the following:

composition [0..*] of … as …

Here, the cardinality can be defined, but no (redundant) join conditions

may be specified.

Transactional View Layer

We recommend that you define dedicated CDS views for your transactional

application that are based on your basic interface views. This makes the

model and its use clearer while leaving the model open for further develop-

ments and new functions. We recommend that you add the suffix TP to the

underlying CDS view names as a naming convention for this kind of CDS

view.

Business object and

root entity

In spoken language, no distinction is usually made between the business

object (in our example, the sales order) and its root entity (in our example,

the sales order header), and the name of the business object is used synon-

ymously for each of them. In the following example, we retain the correct


360


definitions and terms to avoid conceptual confusion, making it clear when

the business object or the root entity of the business object is being referred

to.

Example:

Business object

Let’s define the model of the business object for the sales order. Because you

base the CDS views on the basic interface views already defined, known and

available annotations of the underlying fields, such as their semantics, are

automatically available using the annotation propagation logic. In addi-

tion, the field names already have a nice alias.

Inheriting Annotations

In part of our example, we still add some annotations to the CDS model

that may also be inherited.

Define the sales order header as shown in Listing 11.1. It already contains a

child association to the sales order item, which is defined in Listing 11.2.

@AccessControl.authorizationCheck: #[email protected]: 'Sales Order'define root view entity ZR_SalesOrderTP

as select from ZI_SalesOrdercomposition [0..*] of ZR_SalesOrderItemTP as _Itemassociation [0..1] to ZI_Customer as _SoldToPartyon $projection.SoldToParty = _SoldToParty.Customer

association [1] to I_User as _CreatedByUseron $projection.CreatedByUser = _CreatedByUser.UserID

association [1] to I_User as _LastChangedByUseron $projection.LastChangedByUser = _LastChangedByUser.UserID

{key ZI_SalesOrder.SalesOrder,

ZI_SalesOrder.SalesOrderType,ZI_SalesOrder.SalesOrganization,ZI_SalesOrder.SoldToParty,ZI_SalesOrder.DistributionChannel,ZI_SalesOrder.OrganizationDivision,@Semantics.amount.currencyCode: 'TransactionCurrency'ZI_SalesOrder.NetAmount,ZI_SalesOrder.TransactionCurrency,ZI_SalesOrder.DeliveryStatus,@Semantics.booleanIndicator: trueZI_SalesOrder.DeletionIndicator,@Semantics.user.createdBy: trueZI_SalesOrder.CreatedByUser,


361


11

@Semantics.systemDateTime.createdAt: trueZI_SalesOrder.CreationDateTime,@Semantics.user.lastChangedBy: trueZI_SalesOrder.LastChangedByUser,@Semantics.systemDateTime.lastChangedAt: trueZI_SalesOrder.LastChangeDateTime,_Item,_SoldToParty,_CreatedByUser,_LastChangedByUser

}

Listing 11.1 CDS View Entity: Sales Order Header

Listing 11.2 shows the sales order item that has associations to both the sales

order header and the schedule lines defined in Listing 11.3.

@AccessControl.authorizationCheck: #[email protected]: 'Sales Order Item'define view entity ZR_SalesOrderItemTPas select from ZI_SalesOrderItemassociation to parent ZR_SalesOrderTP as _SalesOrder

on $projection.SalesOrder = _SalesOrder.SalesOrdercomposition [0..*] of ZR_SalesOrderScheduleLineTP

as _ScheduleLineassociation [0..1] to ZI_Product as _Product

on $projection.Product = _Product.Productassociation [1] to I_User as _CreatedByUser

on $projection.CreatedByUser = _CreatedByUser.UserIDassociation [1] to I_User as _LastChangedByUser

on $projection.LastChangedByUser = _LastChangedByUser.UserID{

@ObjectModel.foreignKey.association: '_SalesOrder'key ZI_SalesOrderItem.SalesOrder,key ZI_SalesOrderItem.SalesOrderItem,

ZI_SalesOrderItem.Product,@Semantics.quantity.unitOfMeasure: 'OrderQuantityUnit'ZI_SalesOrderItem.OrderQuantity,ZI_SalesOrderItem.OrderQuantityUnit,@Semantics.amount.currencyCode: 'TransactionCurrency'ZI_SalesOrderItem.NetAmount,ZI_SalesOrderItem.TransactionCurrency,@Semantics.user.createdBy: trueZI_SalesOrderItem.CreatedByUser,@Semantics.systemDateTime.createdAt: true


362


ZI_SalesOrderItem.CreationDateTime,@Semantics.user.lastChangedBy: trueZI_SalesOrderItem.LastChangedByUser,@Semantics.systemDateTime.lastChangedAt: trueZI_SalesOrderItem.LastChangeDateTime,_SalesOrder,_ScheduleLine,_Product,_CreatedByUser,_LastChangedByUser

}

Listing 11.2 CDS View Entity: Sales Order Item

Listing 11.3 shows the sales order schedule line that has associations to the

sales order header as root entity and to the sales order items as parent

entity.

@AccessControl.authorizationCheck: #[email protected]: 'Sales Order Schedule Line'define view entity ZR_SalesOrderScheduleLineTP

as select from ZI_SalesOrderScheduleLineassociation [1..1] to ZR_SalesOrderTP as _SalesOrderon $projection.SalesOrder = _SalesOrder.SalesOrder

association to parent ZR_SalesOrderItemTPas _SalesOrderItemon $projection.SalesOrder = _SalesOrderItem.SalesOrder and

$projection.SalesOrderItem = _SalesOrderItem.SalesOrderItemassociation [1] to I_User as _CreatedByUseron $projection.CreatedByUser = _CreatedByUser.UserID


{key ZI_SalesOrderScheduleLine.SalesOrder,key ZI_SalesOrderScheduleLine.SalesOrderItem,key ZI_SalesOrderScheduleLine.SalesOrderScheduleLine,

ZI_SalesOrderScheduleLine.DeliveryDate,@Semantics.quantity.unitOfMeasure: 'OrderQuantityUnit'ZI_SalesOrderScheduleLine.OrderQuantity,ZI_SalesOrderScheduleLine.OrderQuantityUnit,@Semantics.user.createdBy: trueZI_SalesOrderScheduleLine.CreatedByUser,@Semantics.systemDateTime.createdAt: trueZI_SalesOrderScheduleLine.CreationDateTime,


363


11

@Semantics.user.lastChangedBy: trueZI_SalesOrderScheduleLine.LastChangedByUser,@Semantics.systemDateTime.lastChangedAt: trueZI_SalesOrderScheduleLine.LastChangeDateTime,_SalesOrder,_SalesOrderItem,_CreatedByUser,_LastChangedByUser

}

Listing 11.3 CDS View Entity: Sales Order Schedule Line

CDS View Activation

To avoid issues with CDS view activation, it’s recommended that you first

define and activate the CDS views without associations and add the associ-

ations in the second step. The definition of the associations to parent enti-

ties needs to be done up front to the definition of the related compositions.

11.3.2 Access Controls

Example: Access

control

Read access is controlled via the well-known access control (see Chapter 5)

and as we define the transactional layer on top of our basic layer, we can

simply inherit the access control from the underlying CDS entities. Listing

11.4 shows the inherited access control of the sales order header.

@EndUserText.label: 'Sales Order'@MappingRole: truedefine role ZR_SalesOrderTP {

grantselect

onZR_SalesOrderTP

whereinheriting conditions from entityZI_SalesOrder;

}

Listing 11.4 Access Control: Sales Order Header

The access control for the sales order item is shown in Listing 11.5.

@EndUserText.label: 'Sales Order Item'@MappingRole: truedefine role ZR_SalesOrderItemTP {


364


grantselect

onZR_SalesOrderItemTP

whereinheriting conditions from entity

ZI_SalesOrderItem;}

Listing 11.5 Access Control: Sales Order Item

The access control of the sales order schedule line is shown in Listing 11.6.

@EndUserText.label: 'Sales Order Schedule Line'@MappingRole: truedefine role ZR_SalesOrderScheduleLineTP {

grantselect

onZR_SalesOrderScheduleLineTP

whereinheriting conditions from entity

ZI_SalesOrderScheduleLine;}

Listing 11.6 Access Control: Sales Order Schedule Line

11.4 Behavior Definitions

In this section, you’ll learn how to add the transactional behavior to your

business object. First, you’ll define the provided operations and features.

Then, you’ll complete your application with advanced functions such as

numbering, exclusive locks, authorization control, business logic, actions,

and functions. Gradually, a complete application will be created by imple-

menting the necessary handlers.

11.4.1 Create Behavior Definition

To create a behavior definition, right-click on the CDS root view entity and

choose New Behavior Definition. The Name can’t be changed as it’s identical

to the CDS root view entity; you can change the Description and choose the

implementation type.


365


11

Implementation type Managed is for greenfield applications that imple-

ment or integrate their business logic natively into the ABAP RESTful appli-

cation programming model. When choosing this implementation type, by

default, the complete CRUD operations and the buffer handling are taken

over by the ABAP RESTful application programming model infrastructure.

Implementation type Unmanaged is for brownfield applications that want

to integrate their existing business logic into the ABAP RESTful application

programming model. CRUD operations and buffer handling are imple-

mented by the application.

We’ll discuss both options in the following sections.

MANAGED Implementation Type

Example: Imple-

mentation type

MANAGED

Keep the Implementation Type set to Managed for the first example, click

Next, and then click Finish (see Figure 11.2).

Figure 11.2 ADT: Create Behavior Definition

Example: Managed

behavior definition

for sales order

While creating the behavior definition, a template source is already pro-

vided based on the related CDS entities of the compositional hierarchy. The

source code of the behavior definition is shown in Listing 11.7. It already

contains certain syntax elements to ensure the current state is free of syn-

tax errors and can be activated. We’ll explain the syntax elements in the

next sections.

managed implementation in class zbp_r_salesordertp unique;strict;


366


define behavior for ZR_SalesOrderTP alias SalesOrderpersistent table zsalesorderlock masterauthorization master ( global ){

create;update;internal delete;

association _Item { create; }}

define behavior for ZR_SalesOrderItemTP alias SalesOrderItempersistent table zsalesorderitemlock dependent by _SalesOrderauthorization dependent by _SalesOrder{

update;delete;

association _SalesOrder;association _ScheduleLine { create; }

field ( readonly ) SalesOrder;}

define behavior for ZR_SalesOrderScheduleLineTP aliasSalesOrderScheduleLine

persistent table zsalesorderslinelock dependent by _SalesOrderauthorization dependent by _SalesOrder{

update;delete;

association _SalesOrder;association _SalesOrderItem;

field ( readonly ) SalesOrder;field ( readonly ) SalesOrderItem;

}

Listing 11.7 Behavior Definition: Sales Order


367


11

The first line defines the provider type (in our case, MANAGED) and a proposed

class name for the implementation. The addition unique is mandatory in

strict mode and ensures that each operation is only implemented once.

We’ll dig more into the implementation class in Section 11.4.2.

Strict Mode

The behavior definition always should be defined with the key word

strict; to ensure that the most recent syntax is used and that deprecated

syntax features and functions aren’t available.

Persistence and

mapping

Next, DEFINE BEHAVIOR indicates that for this entity, a behavior model and

implementation is defined. Here for each entity, you should give an ALIASthat is then also present in the runtime structures to make your code more

readable. In addition, element PERSISTENT TABLE names the related database

table of the entity. This information is needed for a MANAGED implementation

in which the buffering of transactional changes as well as all database oper-

ations are taken over by the infrastructure by default.

Sometimes, you’re not starting completely greenfield but still want to

leverage the full infrastructure functionality regarding buffer handling and

application implementation while keeping your existing database tables, or

you may even run the new implementation side by side to the existing one

until feature parity is reached. The ABAP RESTful application programming

model also offers out-of-the-box features for such an approach (sometimes

called the bluefield approach). By default, the defined persistent table needs

to have the same schema, that is, same fields names, as the CDS entity. If the

entity itself still follows the database table but just with different aliases, the

full infrastructure functionality can be used, and the aliasing can also be

done in the write accesses to the database by defining a related mapping in

the behavior definition. Such a mapping (not required in our use case) could

look like the following:

mapping for zsalesorder corresponding{SalesOrder = salesorder;

}

Here, the optional addition corresponding allows all fields with the same

name to be moved and allows a further exception list of fields via syntax

element except. We recommend adding corresponding to any defined map-

ping to ensure future enhancements of the entities work out of the box.


368


If the database schema looks completely different, for example, because the

new model combines multiple database tables into one CDS entity (via JOINor UNION), or you don’t even have relational storage, the database updates

can also be taken over completely by the application. This is done by adding

the syntax WITH UNMANAGED SAVE to the entity definition instead of the PER-SISTENT TABLE. By doing so, you’ll get a save handler into your implementa-

tion class (see Figure 11.3) where all changes are handed over during saving,

allowing you to call your own update task function module. Note that even

in these cases, you can leverage the mapping definitions declared in the

behavior definition in your own coding because the mapping is also used in

the ABAP CORRESPONDING operator.

Finally, there are also use cases where you’ll want to write additional data

to the database. This can also be achieved with the implementation type

ABAP RESTful application programming model MANAGED. A good example

for such a use case is writing change documents. To achieve this, you can

enhance the framework logic with your own implementation part instead

of taking over the complete save handling. This is achieved by adding WITHADDITIONAL SAVE to the behavior entity definition. In this case, you’ll get the

same handler method. Your handler implementation will run additionally

after the standard save handler.

The further syntax elements LOCK MASTER and LOCK DEPENDENT are described in

Section 11.4.6, AUTHORIZATION MASTER and AUTHORIZATION DEPENDENT are

described in Section 11.4.7, and FIELD is described in Section 11.4.2.

CUD operations Inside the behavior clause, you can now define the supported and imple-

mented operations and transactional enabled associations. By default, only

our compositions and to-parent associations are listed in the behavior defi-

nition. These are needed in any case and need to be transactional enabled.

Further we’ve enabled all standard operations, that is, CREATE, UPDATE, and

DELETE for each entity. Note that a direct CREATE operation is only possible on

the root entity, and the creation of instances for subentities is only possible

via a create by association operation. If an operation won’t be allowed and

implemented at all, then it won’t be declared. If it may be executed by your

own implementation only (and not by external consumers), it will be

declared as INTERNAL. In our example, we’ve defined the DELETE operation on

the sales order header level accordingly.

Behavior pool A syntax warning indicates that the proposed implementation class isn’t

yet available, but a quick fix is offered, as you can see in Figure 11.3, to not

only create the class but also to add all to-be-implemented handler classes

and methods after processing the well-known class creation and transport

request dialog. For more information on using the quick fix, refer to http://

s-prs.co/v529423.


369


11

Figure 11.3 ADT: Create Behavior Implementation Class via Quick Fix

Because we’ve chosen the MANAGED implementation scenario, currently

there is no handler yet to be implemented as the complete CRUD handling

is managed by the infrastructure. You can ignore the handler for global

authorization for now as we’ll look into that later in Section 11.4.7; the same

is true for the save handler if you added statement WITH UNMANAGED SAVE or

WITH ADDITIONAL SAVE for one of the entities. So, if you like you can jump to

Section 11.4.3 and consume this implementation programmatically or to

Section 11.6 to define the projection layer, add some UI annotations, and run

the SAP Fiori elements preview (see Section 11.8.2). In any case, you’ll find a

working application not only supporting read access to the persisted data

but also with full CRUD support.

At this stage, you may enter or change data not intended to be entered/

changed by the end user; there is no locking and no (modify) authorization

checks in place and no application logic, for example, to at least validate the

entered data. This is what we’re going to look at now in the further sections

to make the application complete and explain the concepts and syntax at

the same time.

UNMANAGED Implementation Type

Example: Imple-

mentation type

UNMANAGED

As most of the concepts and syntax elements apply both for implementa-

tion types MANAGED and UNMANAGED, in this section, we’ll just briefly introduce

a second data model and behavior definition of type UNMANAGED to explain

the differences on the implementation side and the further features com-

ing up in the next sections of this chapter.

Implementation Type

The implementation type is an implementation detail; that is, it’s hidden

from the consumers of the behavior definition independent of their access

whether programmatically or via OData services for Web APIs or UIs. Thus,

the syntax for everything defining the consumer API within the behavior


370


definition, such as available operations, is the same for either implementa-

tion type.

To keep it simple and comparable, just copy the three CDS entities of the

data model into a new data model with suffix _2, create a behavior defini-

tion as described previously, and this time choose type Unmanaged. Don’t

forget to also adjust the association targets, and keep in mind that usually

we would use such a suffix only for new versions because usually only one

implementation should be developed for every application. We just added

an example for the sales order root in Listing 11.8.

@AccessControl.authorizationCheck: #[email protected]: 'Sales Order'define root view entity ZR_SalesOrderTP_2

as select from ZI_SalesOrdercomposition [0..*] of ZR_SalesOrderItemTP_2 as _Itemassociation [0..1] to ZI_Customer as _SoldToPartyon $projection.SoldToParty = _SoldToParty.Customer

association [1] to I_User as _CreatedByUseron $projection.CreatedByUser = _CreatedByUser.UserID


{key ZI_SalesOrder.SalesOrder,

ZI_SalesOrder.SalesOrderType,ZI_SalesOrder.SalesOrganization,ZI_SalesOrder.SoldToParty,ZI_SalesOrder.DistributionChannel,ZI_SalesOrder.OrganizationDivision,@Semantics.amount.currencyCode: 'TransactionCurrency'ZI_SalesOrder.NetAmount,ZI_SalesOrder.TransactionCurrency,ZI_SalesOrder.DeliveryStatus,@Semantics.booleanIndicator: trueZI_SalesOrder.DeletionIndicator,@Semantics.user.createdBy: trueZI_SalesOrder.CreatedByUser,@Semantics.systemDateTime.createdAt: trueZR_SalesOrder.CreationDateTime,@Semantics.user.lastChangedBy: trueZR_SalesOrder.LastChangedByUser,@Semantics.systemDateTime.lastChangedAt: trueZR_SalesOrder.LastChangeDateTime,


371


11

_Item,_SoldToParty,_CreatedByUser,_LastChangedByUser

}

Listing 11.8 CDS View Entity: Sales Order (UNMANAGED)

Example: Unman-

aged behavior defi-

nition for sales order

The resulting behavior definition of type UNMANAGED then only differs in the

implementation type key word and the absence of the syntax element PER-SISTENT TABLE that is exclusive to the MANAGED implementation type (see Lis-

ting 11.9).

unmanaged implementation in class zbp_r_salesordertp_2 unique;strict;

define behavior for ZR_SalesOrderTP_2 alias SalesOrderlock masterauthorization master ( global ){create;update;internal delete;

association _Item { create; }}

define behavior for ZR_SalesOrderItemTP_2 alias SalesOrderItemlock dependent by _SalesOrderauthorization dependent by _SalesOrder{update;delete;

association _SalesOrder;association _ScheduleLine { create; }

field ( readonly ) SalesOrder;}

define behavior for ZR_SalesOrderScheduleLineTP_2 aliasSalesOrderScheduleLine

lock dependent by _SalesOrderauthorization dependent by _SalesOrder{


372


update;delete;

association _SalesOrder;association _SalesOrderItem;

field ( readonly ) SalesOrder;field ( readonly ) SalesOrderItem;

}

Listing 11.9 Behavior Definition: Sales Order (UNMANAGED)

Behavior handler

UNMANAGED

Although from a consumption point of view, now both behavior defini-

tions offer the same features and operations, on the implementation side,

it looks completely different. Now, creating the implementation class for

our new behavior definition via the quick fix reveals a couple of handlers to

be implemented. The resulting local class definition for the behavior han-

dler of the sales order should look like Listing 11.10. The related local class

definition for the saver handler should look like Listing 11.11.

CLASS lhc_SalesOrder DEFINITION INHERITING FROMcl_abap_behavior_handler.PRIVATE SECTION.METHODS get_global_authorizations FOR GLOBAL AUTHORIZATION

IMPORTING REQUEST requested_authorizations FOR SalesOrderRESULT result.

METHODS create FOR MODIFYIMPORTING entities FOR CREATE SalesOrder.

METHODS update FOR MODIFYIMPORTING entities FOR UPDATE SalesOrder.

METHODS delete FOR MODIFYIMPORTING keys FOR DELETE SalesOrder.

METHODS read FOR READIMPORTING keys FOR READ SalesOrderRESULT result.

METHODS lock FOR LOCKIMPORTING keys FOR LOCK SalesOrder.

METHODS rba_Item FOR READIMPORTING keys_rba FOR READ SalesOrder\_ItemFULL result_requested RESULT result LINK association_links.

METHODS cba_Item FOR MODIFYIMPORTING entities_cba FOR CREATE SalesOrder\_Item.

ENDCLASS.

Listing 11.10 Behavior Implementation: Sales Order Handler (UNMANAGED)


373


11

Behavior saver

UNMANAGED

Along with the handler method for the global authorization (as discussed

already in the MANAGED case) and the lock handler method that will be

described later, you can see that now all CRUD operations need to be imple-

mented accordingly, that is, read as well as the read by association for

defined associations, create, update, delete, and create by association for

create-enabled associations. Note that the delete operation is listed here

although it was defined as internal, that is, defined on the provider side, but

can only be consumed by the provider itself.

CLASS lsc_ZR_SALESORDERTP_2 DEFINITION INHERITING FROMcl_abap_behavior_saver.PROTECTED SECTION.

METHODS finalize REDEFINITION.METHODS check_before_save REDEFINITION.METHODS save REDEFINITION.METHODS cleanup REDEFINITION.METHODS cleanup_finalize REDEFINITION.

ENDCLASS.

Listing 11.11 Behavior Implementation: Sales Order Saver (UNMANAGED)

The saver handler, which you might know already from the MANAGEDscenario with a different handler method for the statement WITH UNMANAGEDSAVE or WITH ADDITIONAL SAVE, consists of multiple handler methods reflect-

ing the ABAP RESTful application programming model save sequence, as

we’ll describe in Section 11.4.5.

UNMANAGED Implementation

We won’t provide an implementation for the UNMANAGED scenario as it

would blow up the current scope of this book. So, the example implemen-

tation will focus on the MANAGED implementation and greenfield approach.

As stated, most of the things are agnostic to the implementation type, but

when a topic specific to one or the other scenario, we’ll mention it in the

related section.

11.4.2 Behavior Pool and Handler Implementation

As discussed in the previous section, the ABAP RESTful application pro-

gramming model provides dedicated handler methods that offer a typed

signature which then needs to be implemented by the application. We usu-

ally call this the provider implementation.


374


The implementation can be split across multiple global behavior pools,

multiple local handler classes, and multiple handler methods, which we will

explain now.

Global Behavior Classes (Behavior Pool)

Behavior implemen-

tation classes

In our example implementation, we’ll only work with one global imple-

mentation class (behavior pool) while the behavior handlers themselves

must be implemented in local classes. This global class usually implements

at least the saver handler because it isn’t specific to an entity. You can also

specify implementation classes on the entity level, for example, for every

entity similarly (see Listing 11.12).

define behavior for ZR_SalesOrderTP alias SalesOrderimplementation in class zbp_r_salesorderroottp_2 unique

…

Listing 11.12 Behavior Definition: Behavior Implementation Pool on the Entity

Level

Implementations can be distributed even further into separate behavior

pools by the group concept (see Listing 11.13). The group defines a bracket

around the to-be-implemented operations or handlers.

group <group_name> implementation in class <class_name> unique{

…}

Listing 11.13 Behavior Definition: Behavior Implementation Pool on the Group

Level

With this concept, you can distribute your implementation into separate

global behavior pools, for example, to distribute the implementation work

or reduce the size of the handler classes.

Local Handler Classes and Handler Methods

In addition, within one behavior pool, you can choose which local class and

method implement the operation. The operation implementation itself is

defined by the importing (and related exporting) parameters of the

method. So, you might implement every single operation in a separate

method and define for every method a dedicated local class; on the other

extreme, you might define one single local class and one single method for


375


11

all operations of the same type (i.e., all MODIFY or all READ operations). We rec-

ommend not combining multiple operations into the same method if it

isn’t necessary. But if, for example, the subsequent called internal legacy

API can handle multiple entities in one call, it makes sense to put these

operations into the same method to leverage this combined processing.

By default, the infrastructure proposes one handler class per entity and one

method for each operation to be implemented. Depending on how the

implementation looks, it might be better to define the classes and methods

differently. Especially if existing functionality (classes or function modules)

are reused and the behavior implementation mainly delegates to these, the

capabilities of these APIs predefine the reasonable combination of han-

dlers. Here, everything is possible, that is, putting everything into one class

as well as putting operations of the same type into the same method if it

makes sense.

Save Handlers

Besides the various behavior handlers, there is also always exactly one save

handler. The save handler needs to be implemented in the behavior pool

defined on behavior definition level.

Sequence of

behavior handlers

To control the invocation of the handler implementations at runtime if

multiple operations are invoked in one request within a behavior pool, the

implementations for different local handler classes can be enhanced with

syntax element BEFORE or AFTER another handler class (see Listing 11.14). This

defines a default sequence to optimize processing, especially for the modify

operations in ABAP RESTful application programming model UNMANAGED or

for determinations (see Section 11.4.10) in ABAP RESTful application pro-

gramming model MANAGED. In the latter case, however, this should not have

any functional impact as any validation and determination (see Section

11.4.10) is called if the trigger condition is met (independent of whether it

was called before already or not).

CLASS lhc_SalesOrderItem DEFINITION INHERITING FROMcl_abap_behavior_handlerAFTER lhc_SalesOrder.…

ENDCLASS.

Listing 11.14 Behavior Implementation: Before and After Syntax


376


Handler Signature

The signature of the different handlers is defined based on the handler type

and offers a dedicated and typed input and output that need to be declared

in the handler method definition. Some special output parameters can’t be

declared explicitly and are automatically present in related handlers.

FAILED FAILED is used to indicate the failure of any operation, whether because the

instances aren’t found, the user isn’t authorized, or the requested change

isn’t allowed. It consists of a structure with all entities and their keys, and it

provides a control structure to indicate the failed operation and a FAIL CAUSEto distinguish the different causes. Based on the key, the failure can be

assigned to the related incoming key. In the OData exposure, different fail

causes usually are also mapped to different HTTP status codes. FAILED is

available in any handler.

REPORTED REPORTED is used to provide additional messages, mainly for failures, but

warning or success messages also can be added. It consists of a structure of

all entities and their keys to allow messages to be assigned to concrete

instances. In addition, the messages can also be assigned to dedicated oper-

ations or fields. If messages can’t be assigned to an instance of an entity, this

can be indicated via indicator %global. Additionally, if messages can’t even

be assigned to an entity, general messages can be assigned to element %oth-ers. A message itself is defined as a T100 exception class and needs to imple-

ment interface IF_ABAP_BEHV_MESSAGE.

Messages as such belong to the current request, but often we want to assign

messages to the state of the instances and keep them persistent/buffered.

This can be achieved by filling element %state_area for a message, but this

is only possible for a message bound to an instance. In this case, the infra-

structure will buffer this message until the same state area is invalidated

again or provides new messages. Thus, it’s important to always invalidate

the relevant state area the handler is responsible for within a handler imple-

mentation by adding an empty message with this state area into REPORTED.

Note that REPORTED is available in any handler.

For our examples, we created an ABAP message class via NEW • Other ABAP

Repository Object • Message Class and added the message we need for our

application (see Figure 11.4). In addition, we created an ABAP exception class

that implements interface IF_ABAP_BEHV_MESSAGE via NEW • ABAP Class and

add the respective messages and variables. The code snippets are provided

in the download area.


377


11

Figure 11.4 ADT: Message Class

MAPPEDMAPPED is used to inform the consumer about the creation of new instances

that have been created based on the consumer request. Every %cid (aka con-

tent ID) that is provided in the incoming request needs to have a result in

either MAPPED or FAILED. MAPPED contains both field %cid and field %tky (con-

sists of temporary or transient instance key). MAPPED is technically available

in any modify handler but may only be used for create operations or factory

actions (see Section 11.4.8).

11.4.3 Consumption via EML

Entity manipulation

language

The runtime access in the ABAP RESTful application programing model to

the modeled entities and business objects is done via entity manipulation

language (EML). EML is an enhancement of the ABAP syntax to natively

consume ABAP RESTful application programming model–defined imple-

mentations. This allows a fully typed consumption of any ABAP RESTful

application programming model–based implementations (independent of

the provider internal implementation type). It’s used to access the opera-

tions of an implementation both internally, that is, within the handler (or

provider) implementations, and from the consumer side. Via EML, all avail-

able operations can be accessed, such as create, update, delete, any action,

any function, lock invocation, data retrieval, feature control, and authoriza-

tion information.

IN LOCAL MODEThe access within the handler implementation on the provider side usually

is done via addition IN LOCAL MODE because, in this case, usually certain things


378


should not be checked such as authorizations (see Section 11.4.7) or feature

controls (see Section 11.4.11). This also applies to static feature controls, as

you need to be able to also set static read-only fields from within your own

behavior implementation (see Section 11.4.4).

Mass-enabled

operations

Any of the read or modifying operations can also be bundled within one call

to, for example, invoke multiple actions, to create a complete document

with one request, or to read a complete document with one request. As

usual, in ABAP, the EML offers a static as well as a dynamic syntax variant.

The following operations are supported:

� READ

To access data from the (transactional) buffer directly, via association or

via function.

� MODIFY

To modify data in the transactional buffer via create, update, delete, or

actions.

� SET LOCKS

To set an enqueue lock.

� GET PERMISSION

To access authorization and feature control information, merged for

convenient consumer access, allowing consumers to specify which infor-

mation will be included.

Further Information

For detailed syntax and further information, check the official ABAP help

documentation: http://s-prs.co/v529413.

Based on the various example implementations, when enhancing the

model and its implementation in the next sections, you’ll understand how

the EML is working and see what the concrete syntax looks like.

11.4.4 Static Field Control

In the previous section, you’ve seen how to define operations, how to

expose them to consumers, and how to keep them internal. This is what we

call static operation control. Even if the creation or update of instances is

allowed, not all fields can be changed by the consumer, and certain fields

also might be mandatory for the consistency of an instance. The corre-

sponding restrictions are referred to as static field controls.


379


11

readonly,

readonly:update

You’ve seen statement field ( readonly ), which is enforced by the behavior

definition syntax for some of the fields. You’ll learn in the next section why

the key fields of the related parent entity are set to read only. In addition, we

also don’t want to allow our system administrative fields to be set from the

outside, so we also set these to read only, as follows:

field ( readonly ) CreatedByUser;field ( readonly ) CreationDateTime;field ( readonly ) LastChangedByUser;field ( readonly ) LastChangeDateTime;

You can also write multiple elements with the same settings into one line/

statement, but we recommend the use of settings per individual field to

increase readability and simplicity if the setting of one field is changed or

enhanced afterwards. The combined syntax would look as follows:

field ( readonly ) CreatedByUser, CreationDateTime,LastChangedByUser, LastChangeDateTime;

If a field value may only be supplied during a create operation and then is

fixed, this can be indicated with statement field ( readonly:update ). This

restriction and setting apply implicitly for any key field.

mandatory,

mandatory:create

We can also define whether fields are mandatory. There are two different

flavors of this setting. The field ( mandatory ) syntax indicates that a field

value needs to be provided for this field at the time of saving, that is, relates

to the consistency of the instance. The same should be accompanied by a

validation which checks that such fields are supplied (discussed in Section

11.4.10). The quite similar syntax field ( mandatory:create ), on the other

hand, defines that a field must be provided during the (technical) create

operation; that is, it’s not a validation of the data but an operation check.

This should usually only be used for key fields of an entity because, by defi-

nition, key fields can’t be changed afterward. While no infrastructure sup-

port is available as of now for the validation, the operation check is inte-

grated into the infrastructure. Thus, if the related fields aren’t provided

during a create operation, this will lead to a syntax error if it can be detected

during implementation time. Otherwise, it will result in a runtime error. As

in our sales order example, a sales order without a customer and without

products and their quantity to be ordered doesn’t make any sense, so we

define these fields as mandatory, for example, for the sales order header as

depicted here:

field ( mandatory ) SalesOrderType;field ( mandatory ) SalesOrganization;field ( mandatory ) SoldToParty;


380


We’ll also look at the other flavor of the mandatory setting when explaining

the numbering topic in the next section.

11.4.5 Numbering

For each entity within a behavior definition, the numbering defines at

which point in time the (final) key of an instance is determined and who can

define the key. Currently, we haven’t imposed any restrictions for setting

the key fields of our entities, which indicates that these can also be set from

the consumer side during a create operation, which is called external num-

bering. At the same time, we haven’t defined any means to adapt the key

value; that is, it’s fixed during the create operation, which is called early

numbering. This reflects the two aspects of numbering: on the one hand,

who defines the number, and on the other hand, at which point in time the

number is final. For the first aspect, the number could be given from the

consumer side (which is called external numbering) or from the provider

side (which is called internal numbering). This aspect is not “either or”, but

can also be combined, i.e., if no number is given from consumer side, the

provider generates one. For the second aspect, the number could be final

already with the create operation (which is called early numbering) or only

if the data is saved to the database the first time (which is called late num-

bering). “Late” refers to the fact that the number is not final during the

transaction in which the related instance is created. We’ll discuss the details

and examples further in the following sections.

Early Numbering

Because we haven’t defined any further static field controls, key field Sales-Order of our sales order header entity can be supplied during the create

operation but doesn’t necessarily need to be supplied. This means that if no

value is supplied externally, the number needs to be provided internally—

usually from a number range. With this, we see that a combination of exter-

nal and internal numbering for the same entity is also possible. For the

UNMANAGED implementation, this is completely fine because the create han-

dler is implemented by the application, and if no number is given, it’s

provided and set as part of this handler implementation. In the MANAGEDcase, this isn’t possible because the create handler isn’t implemented by the

application. Depending on the use case, there are two ways to solve this

issue.

If the scenario is pure external numbering, then we can indicate the need to

provide this field with static field control setting field ( mandatory:create ).

We might complement this setting with field ( readonly:update ), while


381


11

this would only be a documentary addition because key fields by definition

can never be changed. The same is valid similarly in the UNMANAGED imple-

mentation.

If the scenario is a mixture of external and internal numbering or pure

internal numbering indicated by the already known field ( readonly ), we

need an exit to provide the number in the MANAGED case. This can be achieved

by adding EARLY NUMBERING into the behavior definition of the entity.

Example: External

and internal num-

bering

In our example implementation, we define the sales order header to be pro-

vided externally, whereas for the sales order item and schedule line, we

choose internal numbering. To do this, we define the key field of the sales

order as follows:

field ( mandatory:create, readonly:update ) SalesOrder;

This states that the sales order header number needs to be given externally

during the create operation and can’t be changed afterward. For the other

two entity definitions, we enhance the definition with EARLY NUMBERING.

When doing so, the behavior definition reveals a warning Early Numbering

for create by association _ITEM is not implemented. A quick fix helps to add

the missing implementations to the behavior implementation class, and

here we can now provide a proper implementation as depicted in Listing

11.15. As input of the corresponding method, the complete create request is

provided. Thus, if the numbering depends on the incoming data (e.g., as

numbers are partially taken over externally if provided or as a different

number range interval is used based on some incoming data), this can be

achieved. For the schedule line, the same warning and a similar implemen-

tation method and implementation are provided.

CLASS lhc_SalesOrder DEFINITION INHERITING FROMcl_abap_behavior_handler.PRIVATE SECTION.

METHODS earlynumbering_Item FOR NUMBERINGIMPORTING entities FOR CREATE SalesOrder\_Item.

ENDCLASS.…CLASS lhc_SalesOrder IMPLEMENTATION.METHOD earlynumbering_Item.

READ ENTITIES OF ZR_SalesOrderTP IN LOCAL MODEENTITY SalesOrder BY \_Item

FIELDS ( SalesOrderItem )WITH CORRESPONDING #( entities )RESULT DATA(sales_order_items)

FAILED failed.


382


LOOP AT entities ASSIGNING FIELD-SYMBOL(<sales_order>)." get highest item from sales order items of a sales orderDATA(max_item_id) = REDUCE #( INIT max = CONV posnr( '000000' )

FOR sales_order_item IN sales_order_itemsSING KEY entityWHERE ( SalesOrder = <sales_order>-SalesOrder )NEXT max = COND posnr(

WHEN sales_order_item-SalesOrderItem > maxTHEN sales_order_item-SalesOrderItem

ELSE max )).

"assign sales order item idLOOP AT <sales_order>-%target ASSIGNINGFIELD-SYMBOL(<sales_order_item>).APPEND CORRESPONDING #( <sales_order_item> ) TO

mapped-salesorderitemASSIGNING FIELD-SYMBOL(<mapped_sales_order_item>).

IF <sales_order_item>-SalesOrderItem IS INITIAL.max_item_id += 1.<mapped_sales_order_item>-SalesOrderItem = max_item_id.

ENDIF.ENDLOOP.

ENDLOOP.ENDMETHOD.

ENDCLASS.

Listing 11.15 Behavior Implementation: Sales Order Item Early Numbering

numbering:

managed

A special feature of the managed implementation is managed numbering

with a globally unique identifier (GUID) known also from Business Object

Processing Framework (BOPF). Here the numbering is also taken over by the

infrastructure if the key is a GUID, and no dedicated exit implementation is

needed. To indicate that a number should be provided by the infrastruc-

ture, this can be defined via further field information:

field ( numbering:managed ) SalesOrderUUID;

The syntax check verifies that the related field is a GUID. Usually, in this

case, the field is also read only, and the combination with external number-

ing is supported even here.

Late Numbering

Often, in business applications, numbers are taken from a number range

rather late during the save sequence to avoid gaps in used numbers. The


383


11

same applies with external numbering if, for example, the number should

be editable in a UI unless the document is saved for the first time. The fea-

ture of late numbering is only available in the UNMANAGED implementation

type as of the time of writing. The envisioned handling is declared in the

behavior definition of an entity with syntax element LATE NUMBERING. Add-

ing it in our example of the unmanaged behavior definition on the sales

order header brings up some warnings that the other entities need to

declare the same as well. This occurs because, in our example, the key is

hierarchical; that is, the SalesOrder is also part of the key of the two child

entities. Therefore, these also need to be late numbering as the full key is

only given during a save.

With this enhancement in the behavior definition, a new method to draw

the numbers is also included in the save sequence, and we need to add a

redefinition into our local save handler class:

METHODS adjust_numbers REDEFINITION.

This completes the steps and methods of the save sequence.

As the number isn’t drawn during create at runtime, we need to distinguish

two created sales orders. To enable this for late numbering, the runtime

types for the entities are extended by a field named %PID (preliminary ID).

This is a GUID of type RAW 16, acts as a handle in all runtime accesses and

buffered instances, and is given back during create operations instead of

the final key. In the adjust numbers implementation during save, this pre-

liminary ID is mapped to the final key.

Example:

Number range

First, we define a new number range object by creating a new object. To do

so, press (Ctrl)+(N) and search for “number range”. Select the found entry,

and click Next. In the following dialog, enter a name and description to cre-

ate the number range object (see Figure 11.5). To complete the number range

definition in the source, you enhance the number length domain VBELN, and

activate the number range object (see Listing 11.16).

{"header": {

"description": "Sales Order Number Range","masterLanguage": "EN","abapLanguageVersion": "standard"

},"interval": {

"numberLengthDomain": "VBELN","percentWarning": 10.0,"subType": "","untilYear": false,


384


"rolling": true,"prefix": false

},"configuration": {"buffering": "none","bufferedNumbers": 0

}}

Listing 11.16 Number Range: Sales Order Header

Figure 11.5 ADT: Number Range Sales Order Header

In addition, you need to set up a number range interval for the newly cre-

ated number range object. This can be done via Transaction SNUM where

we’ve set up number range interval 01 for our example.

Example:

Adjust numbers

implementation

Now, we can add an implementation to draw the number late in the adjust

numbers handler. An example of the implementation is shown in Listing

11.17. Here it’s assumed that the transactional buffer of the sales order

header is kept in table MT_SALESORDER.

METHOD adjust_numbers.LOOP AT mt_salesorder ASSIGNING FIELD-SYMBOL(<ls_salesorder>)WHERE %pid IS NOT INITIAL.CALL FUNCTION 'NUMBER_GET_NEXT'

EXPORTINGnr_range_nr = '01'object = 'ZSALESORD'


385


11

IMPORTINGnumber = <ls_salesorder>-SalesOrder

EXCEPTIONSinterval_not_found = 1number_range_not_intern = 2object_not_found = 3quantity_is_0 = 4quantity_is_not_1 = 5interval_overflow = 6buffer_overflow = 7OTHERS = 8.

IF sy-subrc = 0.APPEND VALUE #( %pid = <ls_salesorder>-%pid

SalesOrder = <ls_salesorder>-SalesOrder) TO mapped-salesorder.

ELSE."error handling

ENDIF.ENDLOOP.

ENDMETHOD.

Listing 11.17 Behavior Implementation: Sales Order Header Late Numbering

11.4.6 Exclusive Locks

Next, we add an enqueue lock to our implementation. In MANAGED imple-

mentations, there is an enqueue functionality available out of the box, so

no implementation or definition of a custom enqueue object is needed. For

the UNMANAGED implementation, this is a mandatory handler to be imple-

mented. If required, the same can also be done similarly for RAP MANAGED by

adding UNMANAGED to the LOCK MASTER:

lock master unmanaged

Enhancing the syntax reveals a warning message that the lock operation

isn’t yet implemented. With the help of the quick fix, the necessary method

can be added automatically to the behavior handler class.

Using an Existing Enqueue Object

If you’re converting an existing application with an existing SAP enqueue

object, you can and should reuse this enqueue object to ensure interopera-

bility as well as data integrity between the new and old application imple-

mentation.


386


Example:

Lock object

To implement the enqueue functionality, we first create a new lock object.

To do so, open the context menu of your package, choose New ABAP Repos-

itory Object, and search for “lock” (see Figure 11.6). Choose Lock Object, and

click Next.

Figure 11.6 ADT: Lock Object Create Dialog

In the creation dialog, as shown in Figure 11.7, enter “EZSALESORDER” in the

Name field and a reasonable description in the Description field. Enter

“ZSALESORDER” in the Primary Table field to represent the database table of

the sales order header entity. Complete the creation by clicking Next.

Figure 11.7 ADT: Create Lock Object


387


11

In the detail screen, in the Lock Mode field, choose Write Lock, and then acti-

vate the lock object by clicking the Activate button. On activation, the

related enqueue function modules are generated.

Example: Lock

implementation

Now we can add the lock implementation into the related handler, as shown

in Listing 11.18. Note that our example lock implementation doesn’t per-

form an existence check as we only need the key field for the lock argu-

ments that is already provided by the input signature.

METHODS lock FOR LOCKIMPORTING keys FOR LOCK SalesOrder.

…METHOD lock.TRY.

DATA(lock) = cl_abap_lock_object_factory=>get_instance(iv_name = 'EZSALESORDER' ).

LOOP AT keys ASSIGNING FIELD-SYMBOL(<salesorder>).TRY.

lock->enqueue(it_parameter = VALUE #( ( name = 'SALESORDER'value = REF #( <salesorder>-SalesOrder ) ) )

).CATCH cx_abap_foreign_lock INTO DATA(lx_foreign_lock).

SELECT SINGLE FROM I_User FIELDS UserDescriptionWHERE UserID = @sy-msgv1 INTO @DATA(lv_user).

APPEND VALUE #( %key = <salesorder>%fail-cause = if_abap_behv=>cause-locked

) TO failed-salesorder.APPEND VALUE #( %key = <salesorder>

%msg = NEW zcm_salesorder(textid = zcm_salesorder=>lockedsalesorder = <salesorder>-SalesOrderuser = SWITCH #( lv_user WHEN space

THEN sy-msgv1 ELSE lv_user )severity =

zcm_salesorder=>if_abap_behv_message~severity-error)

) TO reported-salesorder.ENDTRY.

ENDLOOP.CATCH cx_abap_lock_failure INTO DATA(lx_exp).


388


RAISE SHORTDUMP lx_exp.ENDTRY.

ENDMETHOD.

Listing 11.18 Behavior Implementation: Sales Order Header Lock

Lock dependent The lock handler is invoked for any modifying instance-related operation

and expected to either set a lock or return proper fail cause LOCKED and an

appropriate error message. As seen in the behavior definition syntax, the

LOCK MASTER is stated only on the root entity, but obviously also an update of

the sales order item needs to ensure a proper lock; that is, in this case, it’s

expected that the sales order is locked. The same is supported out of the box

by the infrastructure with the following syntax:

lock dependent by _SalesOrder

This syntax points to an association from your own entity to the entity that

acts as the lock master. The infrastructure uses this association if a modify-

ing operation on the sales order item navigates to the sales order and

invokes the lock handler. If the target key is mapped by the ON condition of

the association, the navigation is omitted for performance reasons. In this

case, the lock is acquired by the infrastructure using the source informa-

tion. If the lock fails, the related FAILED information is also mapped auto-

matically by the infrastructure back to the incoming operations.

Lock Master on the Subentity Level

Currently, locks can only be modeled, implemented, and set at the root

entity level, that is, for the entire business object. In most cases, this is suf-

ficient. To avoid lock conflicts, however, it’s sometimes useful to set locks

on subentities of the business object if the application logic and processing

of a document allow this. Such a locking mechanism might be in the scope

of further enhancements.

11.4.7 Authorization Checks

While exclusive locks prevent data from being edited and overwritten

simultaneously, authorization checks control access to the data. The differ-

ent operations on the underlying documents, such as creating, reading,

changing, and deleting, as well as each specifically defined action, can be

authorized separately. Because authorizations are always application spe-

cific and depend on specific application data (organizational units, order

types, etc.), you must define the required authorization object yourself.


389


11

ImplementationAs you’ve already learned in Chapter 5, the read permission is modeled with

CDS access controls (data control language [DCL]) when accessing the data

via open SQL. These access controls are applied automatically when data is

selected using the CDS views. Such a locking mechanism is also applied

during transactional read access for a MANAGED ABAP RESTful application

programming model implementation. Because UNMANAGED implementation

handles read accesses itself, the read authorizations need to be imple-

mented explicitly in the read handlers of the UNMANAGED implementation.

Usually, an UNMANAGED implementation doesn’t access the data via CDS views

here, but via the existing buffer and direct access to the underlying legacy

database tables. In such cases, explicit authority checks may need to be

added to the ABAP code.

For the modifying access, you must always add an appropriate implemen-

tation of the authorization check because the granted authorizations are

different as not everybody that is allowed to read data is automatically

allowed to modify data or execute a specific action. For the implementation

of authorization checks for modifying operations, there are dedicated han-

dlers integrated into the ABAP RESTful application programming model

runtime orchestration. We recommend using these handlers also if there is

an UNMANAGED implementation, although theoretically the authorization

checks could also be done in the modify handlers (like the read authoriza-

tion in read handlers).

Authorization for Read Operations

The defined authorization handlers are only available for modifying opera-

tions. For read operations, the respective authority checks are either

expected to be invoked based on the data access via CDS and the related

access control or by implementing the same in the respective read han-

dlers. The same also applies for functions (see Section 11.4.9) where you

need to perform the authorization check in the function implementation.

Global

authorization

The already-implemented sample behavior definition specifies the global

authorization, that is, a not instance-related authorization check. This is

available for all modifying operations, especially noninstance-related oper-

ations such as create or static actions (introduced later in Section 11.4.8). But

global authorization can also be implemented for any instance-related

operation such as update or delete. The global authorization is invoked

before any instance-related operation in the runtime orchestration, such as

locking, thus it can reject requests early. But it’s also useful in use cases

where the authorization check, even for these operations, isn’t instance

specific.


390


The syntax in the behavior definition to define global authorization is as

follows:

authorization master ( global )

With this in the behavior implementation class, we get a handler to be

implemented. In the signature, all available modifying operations are listed

for which the authorization can be requested that should return a negative

result if the authorization isn’t granted. In addition, a corresponding mes-

sage should be returned if an operation isn’t permitted.

Example: Global

authorization

implementation

In the example, we reuse authorization object V_VBAK_AAT, which is part of

the SAP standard functionality, for the sales order processing. Listing 11.19

shows an example implementation of the static authorization check.

METHODS get_global_authorizations FOR GLOBAL AUTHORIZATIONIMPORTING REQUEST requested_

authorizations FOR SalesOrder RESULT result.…METHOD get_global_authorizations.

IF requested_authorizations-%create = if_abap_behv=>mk-on.AUTHORITY-CHECK OBJECT 'V_VBAK_AAT'

ID 'ACTVT' FIELD '01'ID 'AUART' DUMMY.

IF sy-subrc <> 0.result-%create = if_abap_behv=>auth-unauthorized.APPEND VALUE #( %global = if_abap_behv=>mk-on

%msg = NEW zcm_salesorder(textid = zcm_salesorder=>no_auth_createseverity =


) TO reported-salesorder.ENDIF.

ENDIF.IF requested_authorizations-%update = if_abap_behv=>mk-on.AUTHORITY-CHECK OBJECT 'V_VBAK_AAT'


IF sy-subrc <> 0.result-%update = if_abap_behv=>auth-unauthorized.APPEND VALUE #( %global = if_abap_behv=>mk-on

%msg = NEW zcm_salesorder(textid = zcm_salesorder=>no_auth_updateseverity =


391


11



ENDIF.IF requested_authorizations-%action-Delete = if_abap_behv=>mk-on.

AUTHORITY-CHECK OBJECT 'V_VBAK_AAT'ID 'ACTVT' FIELD '06'ID 'AUART' DUMMY.

IF sy-subrc <> 0.result-%action-Delete = if_abap_behv=>auth-unauthorized.APPEND VALUE #( %global = if_abap_behv=>mk-on

%msg = NEW zcm_salesorder(textid = zcm_salesorder=>no_auth_deleteseverity =



ENDIF.ENDMETHOD.

Listing 11.19 Behavior Implementation: Sales Order Header Global Authorization

Instance

authorization

In most cases, the authorization is controlled not only on the global level

but also on the instance level, for example, the sales area or order type in

our example. This is achieved by defining the authorization as follows:

authorization master ( global, instance )

You might also add only instance here and omit global for instance-related

operations. Again, now the related handler is missing, and the provided

quick fix adds an implementation method to our handler class. The signa-

ture of the method is similar to the global authorization but only contains

the instance-related operations and adds the keys for which the authoriza-

tions will be checked.

Example: Instance

authorizations

implementation

Listing 11.20 shows an example implementation of the instance authoriza-

tion check. Note that for the sake of simplicity, the example isn’t optimized

regarding executing the authority check only once for every order type but

is implemented straightforwardly, which adds some redundancy.

METHODS get_instance_authorizations FOR INSTANCE AUTHORIZATIONIMPORTING keys REQUEST requested_authorizations FOR

SalesOrder RESULT result.…


392


METHOD get_instance_authorizations.READ ENTITIES OF ZR_SalesOrderTP IN LOCAL MODEENTITY SalesOrderFIELDS ( SalesOrderType )WITH CORRESPONDING #( keys )RESULT DATA(salesorders)FAILED failed.

LOOP AT salesorders ASSIGNING FIELD-SYMBOL(<salesorder>).IF requested_authorizations-%update = if_abap_behv=>mk-onOR requested_authorizations-%action-Edit = if_abap_behv=>mk-on.

AUTHORITY-CHECK OBJECT 'V_VBAK_AAT'ID 'ACTVT' FIELD '02'ID 'AUART' FIELD <salesorder>-SalesOrderType.

IF sy-subrc <> 0.APPEND VALUE #( %tky = <salesorder>-%tky

%update = if_abap_behv=>auth-unauthorized) TO result.

APPEND VALUE #( %tky = <salesorder>-%tky%msg = NEW zcm_salesorder(

textid = zcm_salesorder=>no_auth_updatesalesorder = <salesorder>-SalesOrderseverity =



ENDIF.IF requested_authorizations-%action-Delete = if_abap_behv=>mk-on.



%action-Delete = if_abap_behv=>auth-unauthorized) TO result.

APPEND VALUE #( %tky = <salesorder>-%tky%msg = NEW zcm_salesorder(

textid = zcm_salesorder=>no_auth_deletesalesorder = <salesorder>-SalesOrderseverity =


) TO reported-salesorder.


393


11

ENDIF.ENDIF.

ENDLOOP.ENDMETHOD.

Listing 11.20 Behavior Implementation: Sales Order Instance Authorization

Privileged successAs you might have recognized in the signature, the delete operation of the

sales order header isn’t present. This is because we’ve declared this opera-

tion as internal, and thus it can only be called inside the provider with INLOCAL MODE where no authorization checks or feature control checks (see Sec-

tion 11.4.11) are part of the runtime orchestration (see Section 11.7).

Privileged Access from the Business Logic

The authorization checks just defined and implemented are executed via

standard EML. Programmatic access to the data via EML IN LOCAL MODE is

always privileged. The background to this is that the corresponding

accesses must also be executed successfully in the internal business logic,

for example, to write static read-only fields. Another example is the dupli-

cate check for external number assignment, which must be carried out

without authorization restrictions to find possible duplicates.

11.4.8 Actions

In addition to the standard operations, such as create, change, and delete,

we also want to provide higher-level operations in our applications that

offer more convenient functionalities and consistently bundle several basic

operations. These operations are referred to in the ABAP RESTful applica-

tion programming model as actions. Simply said, in UI-based consump-

tions, actions correspond to the buttons in the application’s UI. Like the

other operations, actions can be exposed to the consumers or can be

defined as internal to be consumed only within your own implementation.

Static and instance

actions

Actions can be defined with instance-related actions or as static actions (i.e.,

not instance related). Instance-related actions are invoked on instances

(similar to the instance-related operations: create by association, update, or

delete). Thus, instance-related actions automatically get a key parameter

inferred to the action handler signature while static actions only get a han-

dle into the signature (%CID) to correlate the result, failures, or messages

with the input.

We’ll further explore actions in the following sections, including locking,

key parameters, example implementations, and a look at a special type of

actions.


394


Action Locking and Authorization

Locking As you’ve seen, the infrastructure takes care to lock invoked instances for

the standard operations in implementation type managed. The same is also

done for (instance-related) actions automatically; that is, if an action is

invoked on an instance, this instance is locked up front. As static actions

have no instance relation, the lock handler isn’t called up front. If within the

actions, further modifying statements are invoked (in your own application

or a different one), related instances are locked accordingly.

If locking isn’t wanted up front, for example, for an action Copy, you don’t

want to exclusively lock the copy template. This can be stated via the follow-

ing:

action ( lock: none ) <ActionName> …;

Authorization Like locking, authorization checks are also integrated into the ABAP RESTful

application programming model runtime. Thus, when adding new actions,

the signature of the authorization handlers requested_authoriziatons is

also enhanced with the related action in parameter %action. Static actions

only appear in the signature of the global authorization handler as these

have no instance relationship while other actions appear in both the global

and the instance authorization handler.

In many cases, actions have no checks of their own or specific authorization

checks, but just check the standard update authorization. While this can be

easily achieved in the authorization handler implementation for actions

defined in the authorization master entity, this always requires your own

implementation for actions in the authorization dependent entities. If the

action doesn’t require special authorization, this can also be indicated via

the following:

action ( authorization: update ) <ActionName> …;

In this case, an action call invokes the standard update authorization check

similar to the standard operations on the authorization dependent entities.

In the rather unusual case that an action doesn’t require any authorization,

this can be expressed via the following:

action ( authorization: none ) <ActionName> …;

In this case, the authorization handler isn’t invoked at all if an action is

called.


395


11

Action Parameters

External action

name

The action name as an ABAP-related artifact can have up to 30 characters,

which sometimes requires abbreviations to be used for longer expressive

action names. Thus, the behavior definition also allows you to define an

external action name that can contain up to 128 characters:

action <ActionName> external '<ExternalActionName>' …;

This external action name is only used in the OData exposure (see Section

11.8) where the external name is used as the action name in the OData meta-

data. We recommend using the external action name to expand potential

abbreviations in the action name and omit the same if it’s not needed.

Action parametersUnlike standard operations, actions can also be further parameterized. This

allows consumers (e.g., the end user) to influence the behavior of an action

within a predefined frame. In a UI, this corresponds to a user dialog box

after clicking the corresponding button in which allowed values for the

defined parameters can be entered. An action parameter is defined as an

ABAP Data Dictionary structure that can contain multiple elements of dif-

ferent types or as a CDS abstract entity to define the parameter data type.

Action resultActions optionally also can provide a result with a defined result cardinal-

ity. The result can be either an entity indicated by key word entity (with

special notation $self for the entity the action is defined and bound at) or

any result data type of your choice. In the latter case, an action result is

defined as an ABAP Data Dictionary type or as a CDS abstract entity to

define the result data type.

Action Result Cardinality and Mass-Enablement

Cardinality should not be confused with mass-enablement, that is, invok-

ing an action on multiple instances within one request. The ABAP RESTful

application programming model is mass-enabled by design; that is, every

operation can be invoked on multiple instances, and multiple operations

can be bundled within one EML statement (see Section 11.4.3). If, for exam-

ple, a copy action provides a numeric parameter NumberOfCopies, and the

same is invoked on 2 instances A and B with a parameter value of 5, then the

result of a successful action will be 10 additional instances, 5 copies of A and

5 copies of B.

CDS-Based Typing

Action parameter

and result data

types

We’ll focus on the CDS approach to define action parameters and results,

that is, abstract entities, that are used for pure typing here, as then we can

leverage the CDS annotation feature set. An abstract entity is defined via


396


key words define abstract entity and defines the single fields and their typ-

ing via a built-in data type or data element. With this, we can define simple

structures for the parameter and the result (while the result can also have

multiple lines for one input based on the defined cardinality).

As known from the ABAP Data Dictionary, we may not only have simple

data types, but the action parameter or result may also contain structure or

table types. The same can also be achieved with CDS abstract entities with

the help of associations. A deep type is defined by adding an association,

and the defined cardinality [1..1] or [0..*] indicates whether the associated

abstract entity is representing a structure or table type. Usually, we define

the associated data types as part of this usage and use the composition asso-

ciation, but it’s also possible to reuse such a data type by using the key word

association. An example with the different options is shown in Listing 11.21.

We recommend following the naming convention and start such elements

with an underscore (_) here as well. Note that these abstract entities defined

for data types won’t define key fields. The data types themselves can again

be deep and contain structures and table types (i.e., associations).

@VDM.usage.type: [#ACTION_PARAMETER_STRUCTURE]define root abstract entity <NameOfDataType>{

…Field : <NameOfDataElement or Built-In Type>_Structure : composition [

1] of <NameOfUsedAbstractEntity1>;_Table : composition [

0..*] of <NameOfUsedAbstractEntity2>;_ReuseStructure : association [

1] of <NameOfReuseAbstractEntity>;_ReuseTable : association [

0..*] of <NameOfReuseAbstractEntity>;}

Listing 11.21 CDS Abstract Entity: Structured Data Type

To use such a deep type in the ABAP RESTful application programming

model, we also need to define a behavior definition for the data type. While

all further data types included as composition are defined in that same

behavior definition, the reuse data types defined as root abstract entities

via association need to provide their own behavior definition accordingly.

The behavior definition itself again is abstract and indicates the definition

of a type with the key word with hierarchy;. An example related to the pre-

viously defined CDS abstract entity is shown in Listing 11.22.


397


11

abstract;strict;with hierarchy;

define behavior for <NameOfDataType>{association _Structure;association _Table;

}define behavior for <NameOfUsedDataType1>{…

}define behavior for <NameOfUsedDataType2>{…

}

Listing 11.22 Behavior Definition: Structured Data Type

Control fieldsIn addition, for multiple or even deep parameters, the application might

want to define certain parameters as optional or might need to know if a

parameter has been provided or not. If the initial value is valid, this requires

certain control fields that are already widespread in the ABAP RESTful appli-

cation programming model and known via the %control structure. The

same can be defined on the entity level for each abstract entity, that is, can

also be achieved in deep types. An example related to the previously

defined CDS abstract entity is shown in Listing 11.23.


define behavior for <NameOfDataType> with control{…

}

Listing 11.23 Behavior Definition: Structured Data Type with Control

Scalar entityWith the given set, we can achieve any kind of deep structures as an action

result, but still the option to define a result of type data element via CDS is

missing. Here we require special behavior syntax scalar entity. The defini-

tion of the CDS root abstract entity is the same and usually should contain


398


exactly one field (see Listing 11.24). In fact, it doesn’t matter if there are fur-

ther elements defined in the CDS entity because in the related behavior

definition, the relevant fields need to be listed explicitly (see Listing 11.25).

@VDM.usage.type: [#ACTION_RESULT_STRUCTURE]define root abstract entity <NameOfDataType>{

Field : <NameOfDataElement or Built-In Type>}

Listing 11.24 CDS Abstract Entity: Scalar Data Type


scalar entity <NameOfDataType> field Field;

Listing 11.25 Behavior Definition: Scalar Data Type

Parameter and Result Data Types

While parameter and result data types can refer to any dictionary data type,

we recommend only using the CDS-based typing via abstract entities and

the provided deep types options via behavior definition. If dictionary types

are used, at least avoid using data references or boxed components as

these can’t be exposed via OData out of the box. Further general restric-

tions apply for OData V2 based on the available typing according to the

standard OData specification.

Example: Delete Action

Delete action Now let’s add an action to our example. We haven’t yet allowed direct dele-

tion of sales orders in the model. For enabling the deletion, we can now

implement an action that, depending on the delivery status of the sales

order, carries out a physical deletion or logical deletion by setting a deletion

indicator. To do this, define an action in the behavior definition. The action

has no parameter and no result (as the instance will be deleted as a result of

the successful action execution). In the behavior definition, add the follow-

ing action:

action Delete;


399


11

After saving and activating the behavior definition, the syntax warning

reveals that the action implementation is missing. We use the quick fix to

create the method definition automatically. Further, we can see that the

authorization handlers how have a new field in the requested_authorizia-tons: %action-delete. Thus, we enhance our authorization handler imple-

mentations accordingly to check the delete activity (see Listing 11.26 and

Listing 11.27). As the delete operation should be mapped to a separate activ-

ity (in our case, the standard activity 06), we call the authorization check in

case the delete operation is requested with activity 06.

…IF requested_authorizations-%action-Delete = if_abap_behv=>mk-on.AUTHORITY-CHECK OBJECT 'V_VBAK_AAT'


IF sy-subrc <> 0.result-%action-Delete = if_abap_behv=>mk-on.

ENDIF.ENDIF.…

Listing 11.26 Behavior Implementation: Global Authority Check for Action Delete

…LOOP AT salesorders ASSIGNING FIELD-SYMBOL(<salesorder>).…IF requested_authorizations-%action-Delete = if_abap_behv=>mk-on.



%action-Delete = if_abap_behv=>mk-on) TO result.

ENDIF.ENDIF.

ENDLOOP.…

Listing 11.27 Behavior Implementation: Instance Authority Check for Action

Delete


400


The method definition for the action implementation looks like the follow-

ing:

METHODS delete FOR MODIFYIMPORTING keys FOR ACTION salesorder~delete.

In the method implementation (see Listing 11.28), we now read the sales

orders handed over. LOCAL MODE is used because we’re inside our implemen-

tation, and authorization checks have already been done for the action.

Based on the status of the document, we decide to update the sales order

deletion indicator or physically delete the instance. As we haven’t defined a

result, the only result information is whether the operation failed or

whether there are error or success messages via REPORTED.

METHOD Delete.READ ENTITY IN LOCAL MODE ZR_SalesOrderTPFIELDS ( DeliveryStatus DeletionIndicator )WITH CORRESPONDING #( keys )RESULT DATA(salesorders)FAILED failed.

DATA update TYPE TABLE FOR UPDATE zr_salesordertp\\salesorder.DATA delete TYPE TABLE FOR DELETE zr_salesordertp\\salesorder.

LOOP AT salesorders ASSIGNING FIELD-SYMBOL(<salesorder>).IF <salesorder>-DeliveryStatus = space OR <salesorder>-

DeliveryStatus = 'A'."physically delete sales orders with delivery status space or AAPPEND VALUE #( %tky = <salesorder>-%tky ) TO delete.

ELSEIF <salesorder>-DeletionIndicator = abap_false."logically delete sales orders with delivery status B or CAPPEND VALUE #( %tky = <salesorder>-%tkyDeletionIndicator = abap_true%control-DeletionIndicator = if_abap_behv=>mk-on ) TO update.

ENDIF.ENDLOOP.

MODIFY ENTITY IN LOCAL MODE ZR_SalesOrderTPUPDATE FROM updateDELETE FROM deleteFAILED failedREPORTED reported.

ENDMETHOD.

Listing 11.28 Behavior Implementation: Sales Order Delete Action


401


11

Example: Copy Action

Example:

Copy item with

simple parameter

In our second example, we’ll now look at an action with a simple parameter

and specific result. We want to define a copy action on the item level that

creates new items as a copy from an existing item. As this is just a conve-

nience similar to creating an item and maintaining all the data, we also

leverage the feature to not define specific authorization checks for this

action and just refer to the update authorization. Within the behavior defi-

nition of the sales order item, we add the snippet shown in Listing 11.29.

action ( authorization : update ) Copyparameter ZD_SalesOrderItemCopyParameterresult [1..*] $self;

Listing 11.29 Behavior Definition: Sales Order Item Copy Action

We add a parameter here to define how many items should be created.

Thus, the resulting cardinality of the action is one to many, so we use the

predefined entity result $self to indicate that the action will return

instances of the entity the action is defined on.

The parameter itself is defined as an abstract entity with one simple integer

field, as shown in Listing 11.30.

@VDM.usage.type: [#ACTION_PARAMETER_STRUCTURE]define abstract entity ZD_SalesOrderItemCopyParameter{@EndUserText.label: ‘Number of Copies’NumberOfCopies : abap.int1;

}

Listing 11.30 CDS Abstract Entity: Parameter Data Type of Sales Order Item Copy

Action

Finally, in the implementation of the copy action (again created via quick

fix into the local handler class of the sales order item), we read the incoming

item(s) and create the requested number of copied items. As we’ve defined

the result as $self, the signature contains the complete item structure that

needs to be returned as a result (see Figure 11.8). This requires us to read the

created items from the buffer via EML. We could have defined a dedicated

result structure that only contains the item keys, which would have allowed

us to provide the result information already based on the returned data in

MAPPED of the create operation. A code example is provided in Listing 11.31.


402


Figure 11.8 Handler Signature: Action Result $self

METHOD Copy.READ ENTITY IN LOCAL MODE ZR_SalesOrderItemTPALL FIELDSWITH CORRESPONDING #( keys )RESULT DATA(salesorderitems)FAILED failed.

DATA create TYPE TABLE FOR CREATEzr_salesordertp\\salesorder\_item.

DATA cid TYPE string.

LOOP AT keys ASSIGNING FIELD-SYMBOL(<key>).READ TABLE salesorderitems

ASSIGNING FIELD-SYMBOL(<salesorderitem>)WITH KEY entity COMPONENTS %tky = <key>-%tky.

CHECK sy-subrc = 0.READ TABLE create ASSIGNING FIELD-SYMBOL(<create>)

WITH KEY cid COMPONENTS %cid_ref = <key>-%cid_refSalesOrder = <key>-SalesOrder.

IF sy-subrc <> 0.APPEND VALUE #( %cid_ref = <key>-%cid_ref

SalesOrder = <key>-SalesOrder ) TOcreate ASSIGNING <create>.

ENDIF.


403


11

DO <key>-%param-NumberOfCopies TIMES.cid = cid+1.APPEND VALUE #( %cid = cid

Product = <salesorderitem>-ProductOrderQuantity = <salesorderitem>-OrderQuantityOrderQuantityUnit =

<salesorderitem>-OrderQuantityUnitNetAmount = <salesorderitem>-NetAmountTransactionCurrency =

<salesorderitem>-TransactionCurrency%control-Product = if_abapbehv=>mk-on%control-OrderQuantity = if_abap_behv=>mk-on%control-OrderQuantityUnit = if_abap_behv=>mk-on%control-NetAmount = if_abap_behv=>mk-on%control-TransactionCurrency = if_abap_behv=>mk-on

) TO <create>-%target.ENDDO.

MODIFY ENTITY IN LOCAL MODE ZR_SalesOrderTPCREATE BY \_Item FROM createMAPPED DATA(mapped_local)FAILED failedREPORTED reported.

READ ENTITY IN LOCAL MODE ZR_SalesOrderItemTPFROM CORRESPONDING #( mapped_local-salesorderitem )RESULT DATA(new_salesorderitems).

LOOP AT new_salesorderitems ASSIGNINGFIELD-SYMBOL(<new_salesorderitem>).APPEND VALUE #( %cid_ref = <key>-%cid_ref

%tky = <key>-%tky%param = CORRESPONDING #( <new_

salesorderitem> ) ) TO result.ENDLOOP.

ENDLOOP.ENDMETHOD.

Listing 11.31 Behavior Implementation: Sales Order Item Copy Action

An example for deep parameters and results will be provided in the func-

tion examples (see Section 11.4.9).


404


Factory Actions

A special type of actions are factory actions, that is, actions that create new

instances. Different from any action that also is capable of creating new

instances, the specialty of factory actions is that these can be used to invoke

further operations on the resulting instance already within the same

request via content ID references (see EML consumption in Section 11.4.3).

Factory actions are restricted to the result $self (which therefore is omit-

ted) and have a restricted result cardinality of [1]. Other than these restric-

tions, everything else is similar to normal actions or static actions, that is,

factory actions also can be static or instance-bound and have any kind of

parameters. On the implementation side, the result parameter of the action

isn’t RESULT (as for any other actions) but MAPPED (similar to the create oper-

ation) to enable the mapping from the incoming content IDs to the pro-

vided instance keys and allow content ID reference operations. Conse-

quently, on the consumer side, factory actions have %CID in their request

signature.

Example: Static fac-

tory action with sca-

lar result table type

Let’s add a static factory action for the creation of a sales order based on a

predecessor document, for example, a sales quote, to our model. To define

the action, enhance the behavior definition by adding the following to the

sales order header entity:

static factory action CreateFromSalesQuote deep parameterZD_SalesOrderCreateFromQuoteP [1];

The referenced sales quotes are provided via the deep parameter structure.

Depending on the use case, multiple sales quotes could be combined into

one sales order, or single sales quote items can be taken over and thus split

into several sales orders. We restrict ourselves here to a simple example to

take over multiple sales quotes into one sales order. To achieve a simple

table-like parameter, we need to define a root abstract entity that contains

the relevant field (in our case, the SalesQuote) and with a “to many” compo-

sition and a substructure with one single field (see Listing 11.32 and Listing

11.33).

@VDM.usage.type: [#ACTION_PARAMETER_STRUCTURE]define root abstract entity ZD_SalesOrderCreateFromQuoteP{

key Dummy:abap.int1;_SalesQuotes: composition [0..*] of ZD_SalesOrderCreateFromQuotesP;

}

Listing 11.32 CDS Abstract Entity: Deep Type


405


11

@VDM.usage.type: [#ACTION_PARAMETER_STRUCTURE]define abstract entity ZD_SalesOrderCreateFromQuotesP{SalesQuote : vbeln;_DummyAssociation : association to parent ZD_

SalesOrderCreateFromQuoteP;}

Listing 11.33 CDS Abstract Entity: Deep Type Sub-Entity

Using this parameter definition in the behavior definition with addition

deep requires a related behavior definition of the type where we define the

entities (see Listing 11.34).


define behavior for ZD_SalesOrderCreateFromQuoteP{association _SalesQuotes;

field (suppress) Dummy;}

scalar entity ZD_SalesOrderCreateFromQuoteSP field SalesQuote;

Listing 11.34 Behavior Definition: Deep Parameter Type

As we’re only left with an association in this example, we need to define a

dummy field as of now for technical reasons. This field is then suppressed

in the related behavior definition via statement field ( suppress ) and isn’t

present in the runtime structures. An implementation example isn’t pro-

vided here because this is beyond the target of this book and adds no fur-

ther insights.

11.4.9 Functions

Parameters and

results

Like actions, functions also can be defined in the behavior definition via key

word function or static function. Functions are like read-only actions in

that you can’t invoke modifying operations within function. Thus, other

than actions, functions always need a result, or they won’t make any sense.

Parameters and results can be defined similar to actions. In addition, the

features of external names and the control fields are available for functions.


7

Contents

Preface ............................................................................................................................... 17

1 Modeling Your First CDS View 23

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

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

1.2.1 Create Database Tables ................................................................ 28

1.2.2 Create a CDS View .......................................................................... 32

1.2.3 Edit a CDS View ............................................................................... 37

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

1.3 Summary ........................................................................................................... 51

2 Fundamentals of CDS Data Modeling 53

2.1 Overview of CDS Models ............................................................................ 54

2.2 Overview of CDS View Syntax ................................................................. 57

2.3 Key Fields ........................................................................................................... 59

2.4 Cast Operations .............................................................................................. 61

2.5 Typed Literals .................................................................................................. 63

2.6 Case Statements ............................................................................................ 64

2.7 Session Variables ........................................................................................... 66

2.8 Client Handling ............................................................................................... 67

2.9 Union Views ..................................................................................................... 69

2.10 Joins ..................................................................................................................... 76

2.11 SQL Aggregation Functions ....................................................................... 82

2.12 Projection Fields ............................................................................................. 85

2.13 Parameters ....................................................................................................... 86

2.14 Reference Fields ............................................................................................. 91

2.15 Conversion Functions for Currencies and Quantity Units ........... 94

2.16 Summary ........................................................................................................... 97


8

Contents

3 Associations 99

3.1 Define Associations ....................................................................................... 100

3.2 Expose Associations ...................................................................................... 102

3.3 Model Compositional Relations .............................................................. 103

3.4 Model M:N Relations .................................................................................... 105

3.5 Project Associations ...................................................................................... 109

3.6 Use Associations in CDS Views ................................................................. 109

3.6.1 Define Path Expressions ............................................................... 110

3.6.2 Joins Resulting from Path Expressions .................................... 112

3.6.3 Cardinality Changes Resulting from Path Expressions ...... 115

3.6.4 Restrictions for Defining Path Expressions ............................ 118

3.7 Use Associations in ABAP Code ................................................................ 120

3.8 Summary ............................................................................................................ 121

4 Annotations 123

4.1 Annotation Definitions ............................................................................... 124

4.1.1 Syntax Overview .............................................................................. 124

4.1.2 Annotation Names ......................................................................... 128

4.1.3 Annotation Types and Values ..................................................... 131

4.1.4 Enumeration Values ...................................................................... 131

4.1.5 Annotation Default Values .......................................................... 132

4.1.6 Annotation Scopes ......................................................................... 133

4.2 Effects of Annotations ................................................................................. 135

4.3 Propagation Logic of Element Annotations ....................................... 137

4.3.1 Basic Principles ................................................................................. 137

4.3.2 Consistency Aspects ....................................................................... 142

4.4 CDS Metadata Extensions .......................................................................... 144

4.5 Active Annotations ........................................................................................ 148

4.6 Summary ............................................................................................................ 149


9

Contents

5 Access Controls 151

5.1 Fundamentals of Access Controls .......................................................... 152

5.2 Mode of Action of Access Controls ........................................................ 156

5.3 Implementation Patterns for Access Controls .................................. 161

5.3.1 Implement Access Controls with Path Expressions ............ 161

5.3.2 Inherit Implementation of Access Controls ........................... 170

5.3.3 Implement Access Controls without Using

Authorization Objects ................................................................... 178

5.3.4 Implement Access Controls for Analytical Queries ............. 183

5.3.5 Implement Access Controls on the Field Level ..................... 185

5.3.6 Change Access Controls of SAP-Delivered CDS Models ..... 186

5.3.7 Block Standard Data Selections from CDS Models ............. 189

5.3.8 Decouple Access Controls from User Input ........................... 191

5.3.9 Map CDS Fields onto Fields of Authorization

Objects Using Indirection ............................................................ 193

5.4 Test Access Controls ..................................................................................... 193

5.5 Summary ........................................................................................................... 196

6 Business Services 197

6.1 Projection Views ............................................................................................ 198

6.2 Service Definitions ........................................................................................ 201

6.3 Service Bindings ............................................................................................. 206

6.3.1 UI Services ......................................................................................... 206

6.3.2 Web API Services ............................................................................. 211

6.3.3 InA Services ....................................................................................... 212

6.4 Testing Business Services ........................................................................... 213

6.5 Summary ........................................................................................................... 215

7 Native SAP HANA Functions in CDS 217

7.1 Implementation of a CDS Table Function ........................................... 218

7.2 Application Scenarios .................................................................................. 226


10

Contents

7.3 Aspects for Consideration .......................................................................... 227

7.4 Summary ............................................................................................................ 228

8 Modeling Application Data 231

8.1 Application Architecture in SAP S/4HANA ......................................... 232

8.2 Field Labels ........................................................................................................ 235

8.2.1 Determination of a Field Label ................................................... 236

8.2.2 Length of a Field Label ................................................................... 237

8.3 Field Semantics ............................................................................................... 239

8.3.1 Quantities and Amounts .............................................................. 239

8.3.2 Aggregation Behavior .................................................................... 240

8.3.3 System Times ................................................................................... 242

8.3.4 Text and Languages ....................................................................... 243

8.3.5 Information for the Fiscal Year ................................................... 244

8.4 Foreign Key Relations ................................................................................... 245

8.5 Text Relations .................................................................................................. 249

8.6 Composition Relations ................................................................................ 252

8.7 Time-Dependent Data ................................................................................. 255

8.8 Summary ............................................................................................................ 256

9 The Virtual Data Model in SAP S/4HANA 257

9.1 Why a Virtual Data Model? ....................................................................... 257

9.2 Lifecycle, Release, and Stability ............................................................... 259

9.2.1 Release Contracts and Visibility ................................................. 260

9.2.2 Lifecycle .............................................................................................. 262

9.2.3 Deprecation ...................................................................................... 264

9.2.4 Supported Capabilities .................................................................. 266

9.3 Structure of the Virtual Data Model ...................................................... 270

9.3.1 Basic Interface Views ..................................................................... 270

9.3.2 Composite Interface Views .......................................................... 273

9.3.3 Consumption Views ....................................................................... 274

9.3.4 Other Types of VDMs ..................................................................... 276


11

Contents

9.4 Naming in the Virtual Data Model ........................................................ 277

9.4.1 Field Names ...................................................................................... 277

9.4.2 Names of VDM Views ................................................................... 279

9.4.3 Names of Parameters and Associations ................................. 282

9.5 Basic Interface View for the Sales Order ............................................. 282

9.5.1 View Annotations ........................................................................... 283

9.5.2 Structure of the Sales Order View ............................................ 286

9.5.3 Specialization ................................................................................... 287

9.5.4 Element Annotations .................................................................... 288

9.6 Tips for Finding Virtual Data Model Views ........................................ 289

9.6.1 Explore CDS Views in SAP API Business Hub ......................... 289

9.6.2 Search in the ABAP Development Tools ................................. 294

9.6.3 Search Views with Specific Annotations ................................ 296

9.6.4 ABAP Where-Used List .................................................................. 297

9.7 Summary ........................................................................................................... 298

10 Modeling Analytical Applications 299

10.1 Analytics in SAP S/4HANA ......................................................................... 299

10.2 Analytical Views ............................................................................................. 301

10.2.1 First Analytical Cube View ........................................................... 301

10.2.2 Test Environment for Analytical Views ................................... 302

10.2.3 Analytical Cube Views .................................................................. 306

10.2.4 Analytical Dimension Views ....................................................... 309

10.2.5 Analytical Model in the Test Environment ............................ 315

10.2.6 Consistency of the Analytical Model ....................................... 318

10.3 Analytical Queries ......................................................................................... 321

10.3.1 Definition of an Analytical Query ............................................. 321

10.3.2 Initial Layout of a Query ............................................................... 324

10.3.3 Filter, Select Options, Parameters ............................................. 327

10.3.4 Calculation of Measures .............................................................. 332

10.3.5 Restricted Measures ...................................................................... 336

10.3.6 Exception Aggregation ................................................................. 337

10.3.7 Currencies and Conversion ......................................................... 344

10.3.8 Analytical Query Selecting from Dimension Views ............ 347

10.4 Analytical Infrastructure ............................................................................ 348

10.5 Summary ........................................................................................................... 351


12

Contents

11 Modeling Transactional Applications 353

11.1 Transactional Applications ........................................................................ 354

11.2 Transactional Infrastructure in SAP S/4HANA .................................. 355

11.3 Transactional Object Models .................................................................... 358

11.3.1 Object Models .................................................................................. 359

11.3.2 Access Controls ................................................................................ 363

11.4 Behavior Definitions ..................................................................................... 364

11.4.1 Create Behavior Definition .......................................................... 364

11.4.2 Behavior Pool and Handler Implementation ......................... 373

11.4.3 Consumption via EML .................................................................... 377

11.4.4 Static Field Control ......................................................................... 378

11.4.5 Numbering ........................................................................................ 380

11.4.6 Exclusive Locks ................................................................................. 385

11.4.7 Authorization Checks .................................................................... 388

11.4.8 Actions ................................................................................................ 393

11.4.9 Functions ........................................................................................... 405

11.4.10 Data Determinations and Validations ..................................... 412

11.4.11 Dynamic Feature Control ............................................................. 421

11.4.12 Mappings ........................................................................................... 427

11.4.13 Calculated Fields ............................................................................. 428

11.4.14 Prechecks ........................................................................................... 429

11.4.15 HTTP ETags ........................................................................................ 431

11.4.16 Draft .................................................................................................... 433

11.5 Transactional Service Models ................................................................... 442

11.5.1 Service Models ................................................................................. 442

11.5.2 Access Control .................................................................................. 445

11.5.3 Localized Elements ......................................................................... 446

11.5.4 Calculated Fields/Virtual Elements .......................................... 446

11.6 Define Projection Behavior Definition ................................................. 451

11.6.1 Projection Behavior Definition ................................................... 451

11.6.2 Static Field Control ......................................................................... 452

11.6.3 Operations and Features .............................................................. 453

11.6.4 Actions and Functions ................................................................... 456

11.6.5 Prechecks ........................................................................................... 458

11.6.6 Augmentation .................................................................................. 458

11.6.7 Consumption via EML .................................................................... 461

11.7 Runtime Orchestration ................................................................................ 461

11.7.1 Interaction Phase Operation Flow ............................................. 462

11.7.2 Save Phase Operation Flow ......................................................... 463


13

Contents

11.7.3 Runtime Component Overview ................................................. 464

11.7.4 Consumption via OData ............................................................... 466

11.8 SAP Fiori and OData Consumption ........................................................ 466

11.8.1 OData Service for Web API Consumption .............................. 466

11.8.2 OData Service for UI Consumption .......................................... 468

11.9 Summary ........................................................................................................... 479

12 Hierarchies in CDS 481

12.1 Hierarchy Categories and Basics ............................................................. 481

12.2 Annotation-Based Parent-Child Hierarchies ..................................... 484

12.2.1 Example of a Parent-Child Hierarchy ....................................... 486

12.2.2 Determination of a Hierarchy .................................................... 488

12.2.3 Test a Hierarchy .............................................................................. 490

12.3 CDS Hierarchies .............................................................................................. 492

12.3.1 Data for an Example of a Reporting Line Hierarchy ........... 492

12.3.2 Define the CDS Hierarchy ............................................................ 496

12.3.3 Hierarchy Attributes ...................................................................... 498

12.3.4 Visualization of a Hierarchy ........................................................ 500

12.3.5 Hierarchy with an Orphaned Node .......................................... 503

12.3.6 Hierarchy with Multiple Parent Nodes ................................... 504

12.3.7 Hierarchy with Cycles .................................................................... 506

12.3.8 Further Options for Defining Hierarchies .............................. 507

12.3.9 CDS Hierarchies in ABAP SQL ...................................................... 508

12.4 Summary ........................................................................................................... 510

13 CDS-Based Search Functionality 511

13.1 Modeling Value Helps ................................................................................. 512

13.1.1 Modeling Value Help Views ........................................................ 512

13.1.2 Integrating Value Help Views .................................................... 515

13.1.3 Exposing Value Helps .................................................................... 517

13.1.4 Using Value Helps .......................................................................... 518

13.2 Free-Text Search Functionality in OData Services .......................... 529

13.3 Summary ........................................................................................................... 537


14

Contents

14 Extensions of CDS Views and View Entities 539

14.1 Extension Options ......................................................................................... 540

14.1.1 Key User Extensions ....................................................................... 540

14.1.2 Extensions Defined in ABAP Development Tools ................. 541

14.2 CDS Entity Extensions .................................................................................. 541

14.2.1 Extension of a CDS View Entity .................................................. 542

14.2.2 Extension of a CDS View Stack ................................................... 546

14.2.3 Indirect CDS View Extensions ..................................................... 547

14.2.4 Extend the Extension Include View .......................................... 549

14.2.5 Extension Association ................................................................... 551

14.2.6 Stability of Indirect CDS View Extension ................................ 551

14.3 Usage of CDS Entity Extensions ............................................................... 552

14.3.1 Missing Extension Association ................................................... 552

14.3.2 Missing Extension Include View ................................................ 553

14.3.3 Missing Foreign Key Fields ........................................................... 554

14.3.4 Analytical Query Views ................................................................. 554

14.3.5 Extension with Standard Fields ................................................. 555

14.3.6 Extensions of Released CDS Views ........................................... 556

14.3.7 Extensions with Calculated Fields ............................................. 558

14.4 Summary ............................................................................................................ 558

15 Automated Testing 561

15.1 Fundamentals of the Test Double Framework ................................. 562

15.2 Test Sample Overview ................................................................................. 563

15.3 Test Implementations of CDS Views ..................................................... 566

15.3.1 Create Test Design .......................................................................... 566

15.3.2 Implement ABAP Unit Tests ........................................................ 568

15.3.3 Test CDS Access Controls ............................................................. 573

15.3.4 Test CDS Views with Conversion Functions for

Currencies and Quantity Units ................................................... 576

15.3.5 Test Data Sources with Null Values .......................................... 579

15.4 Test ABAP Logic with SQL Accesses to CDS Views ........................... 580


15

Contents

15.5 Test Code Generation Functions ............................................................. 583

15.5.1 Create Test Classes ........................................................................ 583

15.5.2 Adapt Test Classes ......................................................................... 586

15.6 Summary ........................................................................................................... 587

16 Troubleshooting 589

16.1 Performance Aspects ................................................................................... 589

16.1.1 Static View Complexity ................................................................ 590

16.1.2 Calculated Fields ............................................................................. 593

16.1.3 CDS Models in ABAP Code ........................................................... 595

16.1.4 Performance Tests ......................................................................... 596

16.2 Pitfalls ................................................................................................................. 596

16.2.1 Null Values ........................................................................................ 596

16.2.2 Data Types ........................................................................................ 600

16.2.3 Decimal Shift Logic for Amounts .............................................. 604

16.3 Troubleshoot Implementations of CDS Models ............................... 606

16.3.1 Syntax Checks .................................................................................. 607

16.3.2 Consistency Checks of Frameworks ......................................... 611

16.4 Troubleshoot Activation Issues ............................................................... 613

16.4.1 Online Activation ............................................................................ 614

16.4.2 Mass Checks and Repairs ............................................................. 616

16.5 Summary ........................................................................................................... 618

Appendices 621

A CDS Annotation Reference ........................................................................ 621

B The Authors ...................................................................................................... 633

Index .................................................................................................................................. 635


635

Index

?= operator ................................................... 182

@AbapCatalog.compiler.compare-

Filter .......................................................... 621

@AbapCatalog.preserveKey ................. 621

@AbapCatalog.sqlViewAppend-

Name ................................................ 550, 621

@AbapCatalog.sqlViewName .............. 621

@AccessControl.auditing.

specification ........................................... 180

@AccessControl.auditing.type ........... 180

@AccessControl.authorization-

Check ............................. 160, 186, 611, 621

@AccessControl.privileged-

Associations ........................................... 191

@Aggregation ............................................ 241

@Aggregation.default ................... 307, 622

@Analytics.dataCategory ............ 184, 306,

309, 316, 622

#CUBE ....................................................... 302

@Analytics.internalName 289, 350, 351

@Analytics.query .......... 97, 183, 212, 321,

511, 622

@Analytics.technicalName ........ 303, 322,

323, 350

@AnalyticsDetails.

exceptionAggregationSteps ... 340, 623

@AnalyticsDetails.query.axis ..... 326, 623

@AnalyticsDetails.query.

display ............................................. 326, 623


formula ........................................... 335, 623

@AnalyticsDetails.query.hidden ....... 623


sortDirection ................................ 326, 623

@AnalyticsDetails.query.totals . 326, 623

@API.element.releaseState .................. 266

@API.element.successor ....................... 266

@ClientHandling.algorithm ................ 623

@ClientHandling.type ............................ 623

@Consumption.dbHints ....................... 593

@Consumption.defaultValue .... 330, 624

@Consumption.derivation ........ 268, 331,

332, 624

@Consumption.deriviation.

lookupEntity .......................................... 185

@Consumption.filter ........... 331, 511, 624

@Consumption.hidden ............... 136, 330,

534, 624

@Consumption.valueHelp ................... 513

@Consumption.valueHelpDefault.

binding.usage ............................... 514, 525

@Consumption.valueHelpDefault.

display .................................... 514, 523, 525

@Consumption.valueHelpDefinition .......

185, 201, 330, 511, 513

@Consumption.valueHelpDefinition.

additionalBinding ................................ 517


additionalBinding.element .............. 624


additionalBinding.localElement .... 624


association ..................................... 517, 624


entity.element .............................. 516, 624


entity.name ................................... 516, 624

@Consumption.

valueHelpDefinition… ........................ 513

@DefaultAggregation .......... 241, 307, 347

@EndUserText .............................................. 50

@EndUserText.label ........ 35, 72, 139, 214,

235, 236, 608, 624

@EndUserText.quickInfo ............. 237, 625

@Environment.systemField ........... 90, 91,

136, 330, 331, 625

@Hierarchy.parentChild ............... 485, 625

@Hierarchy.parentChild.directory .... 185

@MappingRole .......................................... 156

@Metadata.allowExtensions ..... 145, 147,

625

@Metadata.

ignorePropagatedAnnotations ......... 69,

138, 142, 144, 625

@Metadata.layer .............................. 146, 626

@MetadataExtension.

usageAllowed ................................ 147, 626

@ObjectModel.alternativeKey ... 130, 131

@ObjectModel.alternativeKey.

element .................................................... 626

@ObjectModel.alternativeKey.id ....... 626

@ObjectModel.alternativeKey.

uniqueness ............................................. 626

@ObjectModel.association.type ......... 253

@ObjectModel.compositionRoot ...... 253


636

Index

@ObjectModel.compositionRoot,

true ............................................................. 359

@ObjectModel.dataCategory ..... 132, 185,

312, 513, 626

#HIERARCHY ......................................... 485

#TEXT ........................................................ 251

@ObjectModel.filter.enabled ............... 626

@ObjectModel.filter.

transformedBy ...................................... 626

@ObjectModel.foreignKey.

association ........................... 247, 511, 626

@ObjectModel.hierarchy.

association ..................................... 484, 626

@ObjectModel.modelingPattern ...... 267,

627

@ObjectModel.representativeKey .... 248,

251, 309, 312, 513, 627

@ObjectModel.sort.enabled ................. 627

@ObjectModel.sort.transformedBy ... 627

@ObjectModel.

supportedCapabilities .............. 267, 285,

590, 627

@ObjectModel.text .................................. 311

@ObjectModel.text.

association ........................... 250, 312, 627

@ObjectModel.text.element ...... 250, 313,

627

@ObjectModel.usageType .................... 285

@ObjectModel.usageType.

dataClass ............................... 136, 285, 627


serviceQuality ..................... 136, 285, 627


serviceQuality… ..................................... 590


sizeCategory ........................ 136, 285, 627

@ObjectModel.virtualElement ........... 627

@ObjectModel.

virtualElementCalculatedBy ... 447, 627

@OData.entityType.name .. 135, 205, 206

@OData.publish ............................... 198, 628

@Scope .......................................................... 126

@Search ........................................................ 529

@Search.defaultSearchElement . 530, 628

@Search.fuzzinessThreshold .............. 531,

533, 628

@Search.ranking .............................. 533, 628

@Search.searchable ........................ 530, 628

@Semantics ................................................ 271

@Semantics.amount ............................... 240

@Semantics.amount.currencyCode ... 92,

93, 96, 333, 605, 628

@Semantics.booleanIndicator ... 602, 628

@Semantics.businessDate.from 255, 629

@Semantics.businessDate.to ..... 255, 629

@Semantics.currencyCode ......... 239, 629

@Semantics.dateTime ............................ 629

@Semantics.fiscal ..................................... 244

@Semantics.fiscal.period ....................... 629

@Semantics.fiscal.year ........................... 629

@Semantics.fiscal.yearPeriod .............. 629

@Semantics.fiscal.yearVariant ............ 629

@Semantics.language .......... 244, 251, 630

@Semantics.quantity .............................. 239

@Semantics.quantity.

unitOfMeasure .... 92, 96, 126, 127, 134,

139, 630

@Semantics.systemDate ....................... 242

@Semantics.systemDate.

createdAt ............ 126, 127, 133, 134, 630

@Semantics.systemDate.

lastChangedAt ........................................ 630

@Semantics.systemDateTime ............. 242

@Semantics.systemDateTime.

createdAt .................................................. 630

@Semantics.systemDateTime.

lastChangedAt ........................................ 630

@Semantics.systemTime ...................... 243

@Semantics.systemTime.

createdAt .................................................. 630

@Semantics.systemTime.

lastChangedAt ........................................ 630

@Semantics.text ............................. 243, 630

@Semantics.unitOfMeasure ...... 239, 630

@Semantics.user.createdBy ................. 630

@Semantics.user.lastChangedBy ....... 630

@Semantics.uuid ...................................... 602

@UI.facet ...................................................... 631

@UI.fieldGroup .......................................... 631

@UI.headerInfo .......................................... 631

@UI.hidden .................................................. 631

@UI.identification .......................... 469, 631

@UI.lineItem ......... 214, 468, 469, 517, 631

@UI.lineItem.importance ...................... 146

@UI.selectionField ....... 214, 468, 517, 631

@VDM.lifecycle.contract.type ............ 263,

275, 277

@VDM.lifecycle.status ............................ 266

@VDM.lifecycle.successor ........... 265, 266

@VDM.private ......................... 263, 276, 631

@VDM.viewExtension .................. 276, 631

@VDM.viewType . 270, 273, 274, 276, 632

\!@testing .......................................... 569, 587

#AVG .................................................... 241, 338


637

Index

#COUNT ....................................................... 338

#DEPRECATED ........................................... 266

#FIRST ........................................................... 338

#LAST ............................................................. 338

#MAX .................................................... 307, 338

#MIN ..................................................... 307, 338

#NONE .......................................................... 307

#NOP ............................................................. 307

#PUBLIC_LOCAL_API .............................. 263

#SAP_INTERNAL_API ............................. 263

#STD ............................................................... 338

#SUM .................................................... 307, 338

$node ............................................................. 498

$parameters ................................................... 87

$projection ..................................................... 85

$session.client .............................. 66, 68, 220

$session.system_date ................................ 66

$session.system_language ...................... 66

$session.user .................................................. 66

$session.user_date ...................................... 67

$session.user_timezone ........................... 67

A

A2A communication ............................... 353

ABAP application infrastructure 234, 259

ABAP application server ........................ 357

ABAP Data Dictionary .................... 245, 271

structure .................................................. 395

ABAP Development Tools (ADT) ... 23, 28,

32, 152, 357, 561, 606

CDS model lifecycle ............................. 260

editor ......................................................... 124

environment .......................................... 583

search ........................................................ 294

test classes .............................................. 583

ABAP documentation ................................ 49

ABAP host variable ...................................... 46

ABAP in Eclipse .......................................... 357

ABAP infrastructure ........................ 417, 468

ABAP logical unit of work ...................... 431

ABAP platform ........................... 17, 356, 357

ABAP Programming Model

for SAP Fiori ........................................... 356

ABAP RESTful application

programming model ......... 17, 197, 353,

356, 377, 431, 479

OData ....................................................... 466

orchestration ......................................... 461

runtime component ............................ 464

ABAP SQL ................ 23, 44, 67, 90, 357, 580

interface ............ 136, 156, 183, 189, 563,

572, 596

new syntax ................................................. 46

ABAP SQL test double

framework ...................................... 563, 580

ABAP system field ........................................ 90

ABAP unit test ................................... 563, 568

ABAP Workbench ........................... 28, 30, 32

ABAP-Managed Database

Procedures (AMDP) ............................. 217

class method .......................................... 220

procedure ................................................. 221

Access condition .................... 153, 163, 176

literal values ........................................... 182

Access control ........ 68, 105, 151, 162, 363,

389, 445

analytical queries ................................. 183

fields .......................................................... 185

implementation .................................... 161

inheritance .............................................. 172

mode of action ...................................... 156

path expression ..................................... 161

SAP-delivered models ......................... 186

unique key ............................................... 158

Access rule ................................................... 153

Action ................................ 353, 355, 364, 393

parameters .............................................. 395

Activation log ............................................. 609

Activation problem ........................... 40, 102

Active and inactive CDS models ............ 40

Addition ........................................................ 120

Aggregation ................................................. 240

hierarchical ............................................. 509

level ............................................................... 82

type ............................................................ 241

ALL quantifier ............................................. 167

ALV tree control ......................................... 500

Amount field ............................ 239, 240, 279

Analytic dimension view ....................... 309

Analytic engine ...... 97, 183, 235, 348, 481

Analytic interface ...................................... 349

Analytic model .................................. 315, 318

Analytic processor ........................... 348, 481

Analytic query .................. 99, 183, 189, 321

calculate measures .............................. 332

define ......................................................... 321

define variables ..................................... 327

exception aggregation ....................... 337

extension ................................................. 554

layout ........................................................ 324

restricted measures ............................. 336


638

Index

Analytic query (Cont.)

select from dimension views ............ 347

Analytical

application .............................................. 299

cube ............................................................ 273

measure .................................................... 242

ANALYTICAL_CUBE .................................. 268

ANALYTICAL_DIMENSION .................... 269

ANALYTICAL_PARENT_CHILD_

HIERARCHY_NODE ............................. 269

ANALYTICAL_PROVIDER ....................... 268

ANALYTICAL_QUERY ............................... 268

Analytics ....................................................... 299

data category ......................................... 306

modeling .................................................. 299

tools ........................................................... 350

Annotate view ........................... 55, 135, 145

Annotated formula ................................... 335

Annotation ........................................... 54, 272

active ........... 50, 123, 124, 139, 141, 144,

146, 148, 468

aggregation behavior ......................... 240

array ................................................. 130, 138

ARRAY OF ................................................ 130

artifacts .................................................... 135

authorization ......................................... 160

composition relations ........................ 253

consistency aspects ............................. 142

default value ................................. 132, 133

definition ................................................. 124

document ................................................ 136

domain ........................ 124, 126, 128, 147

effect .......................................................... 135

element ..................................................... 137

ENUM ........................................................ 132

errors ......................................................... 613

explicit ...................................................... 237

field ............................................................ 239

fiscal year ................................................. 244

foreign key ............................................... 246

fully qualified annotation name .... 128

grouping .................................................. 129

main ........................................................... 128

name .......................................................... 128

propagation logic ................ 50, 132, 134,

137, 236, 308

root ............................................................. 128

runtime environment ......................... 136

scope .......................................................... 134

search ........................................................ 533

semantic ................................................... 271

subannotation ....................................... 128

Annotation (Cont.)

system times ........................................... 242

text and language ................................ 243

text relations .......................................... 250

type ............................................................. 131

undefined ................................................. 608

value ................................................ 128, 131

Annotation-based hierarchy ................. 484

Application architecture ........................ 231

Application data modeling .................... 231

Application infrastructure ..................... 231

Application performance ....................... 589

testing ........................................................ 596

Application programming

interface (API) .............................. 211, 258

state ................................................. 260, 284

AS PARENT CHILD HIERARCHY

keyword .................................................... 496

Aspect ............................................................. 179

ASPECT PFCG_AUTH ................................ 193

ASPECT USER ............................................... 178

Aspect, self-defined .................................. 180

ASSERT statement ..................................... 572

Association .................... 27, 53, 99, 272, 359

annotations ............................................ 134

cardinality ............................................... 101

composition ............................................ 103

default filter .................................. 117, 118

define .................................................. 73, 100

define custom ......................................... 557

exposure ................................................... 102

extension .................................................. 551

in ABAP code ........................................... 120

in CDS view .............................................. 109

name ................................................ 100, 282

projected .................................................. 109

redirected to composition child ...... 200

redirected to parent ............................. 200

remove ...................................................... 102

target ......................................................... 101

to parent ................................................... 200

Audit ............................................................... 180

Augmentation ............................................ 458

Authorization ................................... 151, 353

control .................................... 151, 354, 364

database level ........................................ 156

extension fields ...................................... 186

field ............................................................. 153

map fields ................................................ 193

object ............................................... 153, 388

protection ................................................ 160

role .............................................................. 157


639

Index

Authorization check ............ 160, 184, 193,

389, 393

change ...................................................... 189

documentation ..................................... 160

Automated testing ................................... 193

Average calculation ................................. 240

AVG .................................................................... 84

B

Basic interface views ............ 270, 282, 359

redundancies ......................................... 272

Behavior definition ......................... 353, 364

Bluefield ........................................................ 367

Brownfield ................................................... 365

Business logic ............... 353–355, 357, 358,

364, 442

Business object .... 252, 354, 358, 359, 442

node ........................................................... 252

Business Object Processing

Framework (BOPF) ............... 18, 382, 412

Business process .............................. 354, 442

Business services

benefits ..................................................... 197

InA UI services ....................................... 212

testing ....................................................... 213

UI services ............................................... 206

Web API services ................................... 211

BYPASS WHEN statement ..................... 167

C

Calculated field .......................................... 353

extend ....................................................... 558

value .......................................................... 593

Camel case notation ................ 35, 219, 278

Cardinality ............... 25, 101, 105, 113, 115,

116, 169

foreign key association ...................... 247

CASE statement ........................... 64, 65, 600

CAST function ........... 61, 71, 138, 141, 236

nest ............................................................... 62

CDS .................................................................... 17

abstract entity ......................... 55, 56, 395

associations ............................................... 27

custom entities ........................ 54, 56, 429

data access in ABAP ............................... 45

element ....................................................... 99

hierarchies .............................................. 508

implementation errors ...................... 596

modeling ..................................................... 53

Navigator tab ........................................ 551

CDS (Cont.)

projection view .................................. 54, 55

release state ............................................ 262

service-specific views .......................... 197

session variable ................................. 66, 67

stability contract .................................. 260

stability contract restrictions .......... 261

supported capabilities ........................ 267

type conversions ...................................... 61

version 2 ................................................... 358

CDS access control ....... 284, 389, 566, 596

analytics ................................................... 183

block standard data selection ......... 189

decoupling from input ....................... 191

field level .................................................. 185

implementation .................................... 161

inheritance ..................................... 170, 172

language .................................................. 356

path expression ..................................... 161

redefine ..................................................... 187

SAP-delivered CDS models ................ 186

testing .............................................. 193, 573

without authorization objects ........ 178

CDS editor ...................................... 34, 36, 218

auto-completion ...................................... 40

code completion .......................... 127, 609

mass activation ........................................ 41

CDS entities

semantic names .................................... 204

specialized ............................................... 204

type ........................................................ 53, 54

CDS entity extension ............................... 541

calculated fields .................................... 558

CDS extend view ....... 54, 56, 134, 186, 539

activate ..................................................... 550

usage ......................................................... 552

CDS extend view entity ...................... 54, 56

CDS hierarchy ...................................... 55, 492

define ......................................................... 496

CDS hierarchy entity ................................... 56

CDS metadata extension ......... 55, 57, 123,

144, 539

create ......................................................... 145

layer assignment .................................. 146

names ........................................................ 145

permitted annotations ....................... 147

CDS model ............................. 23, 54, 231, 356

ABAP .......................................................... 595

activate ........................................................ 35

activation logic ..................................... 616

create ............................................................ 32

denormalize ............................................ 114


640

Index

CDS model (Cont.)

error message ........................................ 612

inconsistencies ...................................... 144

inheritance .............................................. 172

key .............................................................. 158

names .......................................... 35, 59, 161

parameters ................................................. 87

propogation logic ................................. 144

readability ............................................... 145

reuse .......................................................... 590

SAP-delivered ......................................... 147

SQL-friendly ............................................ 589

static complexity .................................. 590

template ...................................................... 34

transparency ............................................. 60

troubleshoot ........................................... 606

versions ....................................................... 39

CDS role ............................................... 152–154

can’t be fulfilled ..................................... 190

direct reference ...................................... 178

inheritance .............................................. 174

mapping role .......................................... 156

multiple roles ......................................... 161

optional elements ................................ 176

path expressions ................................... 169

redefinition ............................................. 187

CDS syntax ...................................................... 57

embed conversion functions ............... 94

CDS table function .............. 54, 56, 68, 217,

355, 595

associations and annotations ........ 220

client-dependent ................................... 220

components ............................................ 219

implement ............................................... 218

test .............................................................. 223

CDS test double framework ......... 563, 569

CDS view ................................................ 23, 355

activation ................................................ 363

aggregating ............................................... 82

client field ................................................... 60

create .............................................. 32, 41, 46

definition .................................................... 42

direct extension ..................................... 547

edit ................................................................. 37

explicit joins ........................................... 113

extension ........................................ 227, 539

fields ............................................................. 59

hierarchy ..................................................... 41

indirect extension ............. 547, 549, 551

internal logic ............................................. 99

model ........................................................... 59

path expressions ................................... 111

CDS view (Cont.)

projection ................................................. 198

released extensions .............................. 556

search ..................................... 294, 296, 297

stack ................................. 47, 138, 148, 567

static complexity .................................. 590

syntax .......................................................... 57

test ................................................................ 42

V1 ................................................................... 55

V2 .................................................................. 55

with inner join .......................................... 81

CDS view entities .................................. 54, 55

create ........................................................... 34

CDS view extension .................................. 549

components ............................................ 550

CDS_CLIENT ................................ 68, 219, 284

CDS_MODELING_ASSOCIATION_

TARGET ..................................................... 267

CDS_MODELING_DATA_SOURCE ...... 267

CDS_REPAIR ................................................ 616

Characteristic .............................................. 304

Check function ........................................... 606

Check table ................................................... 245

Child node .................................................... 252

CHILD TO PARENT ASSOCIATION ....... 496

CL_ABAP_UNIT_ASSERT ........................ 572

CL_CDS_TEST_DATA ................................ 577

CL_CDS_TEST_ENVIRONMENT ........... 569

Class method ............................................... 220

Class setup method .................................. 569

Class teardown method .......................... 572

Client ......................................................... 60, 67

field ............................................................... 68

handling ............................................ 67, 284

CLIENT SPECIFIED ........................................ 67

Client-dependent data ............................. 284

COALESCE ..................................................... 599

Code ................................................................ 278

completion .................................... 127, 609

COMBINATION MODE AND

statement ................................................. 188

COMBINATION MODE OR ...................... 188

Comment ........................................................ 59

COMMIT ENTITIES .................................... 464

COMMIT WORK ................................ 431, 464

Composite interface view ...................... 273

Composition

association .............................................. 253

hierarchy .................................................. 103

relationship ............................................. 354

restrictions ............................................... 105


641

Index

Composition relations ............................ 252

annotation-based ................................ 253

COMPOSITION...OF .................................. 103

Consistency check .................................... 393

analytic .................................................... 302

Consistency condition ............................ 320

Consistency validation ........................... 412

Consumption view ................................... 274

compatability ........................................ 274

not released ............................................ 274

CONTAINS function ................................. 533

Content ID references ............................. 404

Conversion exit .................................. 61, 603

Conversion function ........ 84, 94, 566, 576

analytical queries .................................... 97

error handling .......................................... 96

parameters ................................................ 95

performance aspects ............................. 84

Core Data Services Repair Tool ............ 616

Cost center ................................................... 489

hierarchy ................................................. 486

COUNT different values ......................... 240

COUNT DISTINCT ...................... 84, 241, 599

COUNT(*) .................................................. 58, 84

Counter ...................................... 279, 339, 347

CREATE statement ........................... 112, 116

Creation dialog ................................. 202, 206

Creation wizard ............................................ 29

Cross-client data access ............................. 68

CRUD operations ...................................... 354

Cube ............................................................... 307

Cube view .................................. 299, 301, 306

analytic .................................................... 302

define ........................................................ 301

CUKY ................................................................. 92

CURR .......................................................... 91, 92

fields ............................................................. 92

CURR_TO_DECFLOAT_AMOUNT .......... 93

Currency conversion ........ 95, 96, 344, 577

Currency field ............................................. 239

Currency shift ................................................ 92

Custom field ................................................ 227

Custom query ............................................. 555

Customer namespace ................................ 27

Cycle

breakup .................................................... 506

resolve ....................................................... 506

D

Data control language (DCL) ................ 152

Data definition .................................. 541, 549

Data definition language (DDL) .............. 53

Data definition language source

(DDLS) .............................. 32, 33, 36, 54, 59

Data element ........................................ 61, 235

field label ................................................. 237

medium text ........................................... 238

Data model

define ............................................................ 24

implement .................................................. 27

Data preview .................................................. 42

Data record ..................................................... 43

missing ..................................................... 101

Data redundancy ....................................... 169

Data selection ................................................ 53

privileged .............................. 182, 190, 191

Data source .................................................. 554

DATA_STRUCTURE ................................... 267

Database procedure ................................. 222

Database table

create ............................................................ 28

editor ............................................................ 30

simplify ........................................................ 31

Database view ................................................ 37

implicit join ............................................. 112

DCLS ............................................ 152, 161, 181

DDLA .............................................................. 124

DDLX ................................................................. 57

Decimal shift .................................................. 93

logic ........................................................... 605

DECOMMISSIONED .................................. 263

Default filter ....................................... 117, 118

DEFAULT TRUE ........................................... 173

Define abstract entity ................................. 55

DEFINE ACCESSPOLICY ........................... 181

Define custom entity .................................. 54

Define extend view ..................................... 54

Define extend view entity ........................ 54

Define hierarchy entity ............................. 55

DEFINE statement ........................................ 58

Define table function ................................. 54

Define view ..................................................... 54

entity ..................................................... 54, 58

Delegation approach ............................... 174

Denormalization ................................ 77, 114

Denormalized fields ................................. 458

DEPRECATED ..................................... 263, 265

Deprecation policy ................................... 264

Derivation .................................................... 331

DERIVATION_FUNCTION ...................... 268

Descendants ....................................... 482, 500

Design phase .................................................. 24


642

Index

Determination ........................ 412, 417, 429

execution times ..................................... 413

Determine action ...................................... 420

Development object

deprecation ............................................. 264

lifecycle ..................................................... 260

release contracts ................................... 260

release state ............................................ 262

stability ..................................................... 260

stability contracts ................................ 260

visibility .................................................... 260

Dimension .................................. 99, 304, 307

analytic ..................................................... 309

consistency .............................................. 318

field ................................................... 307, 310

multiple key fields ................................ 320

replace ....................................................... 320

view ................................................... 299, 347

Directory…filter by .................................... 507

Display attribute ........................................ 326

Display authorization ............................. 154

Display currency ........................................ 344

DISTINCT statement ................................... 70

Domain fixed value .................................. 542

Draft concept .............................................. 434

Draft table .................................................... 434

Duplicate record ........................................... 73

Duration ....................................................... 279

Dynamic control of properties ............ 353

Dynamic property .................................... 422

Dynamic variable ...................................... 331

E

Early numbering ........................................ 380

Element annotations ...................... 137, 307

Embedded analytics ................................. 300

Enhancement category ........................... 543

Enqueue object .................................. 353, 421

Entity key ..................................................... 255

Entity manipulation language

(EML) ....................................... 377, 461, 462

Entity relationship model (ERM) .... 27, 42

Entity view ................................................... 246

Enumeration value ................................... 131

EXCEPT element ........................................... 76

Exception aggregation ......... 337, 342, 347

aggregation behavior ......................... 338

steps ........................................................... 340

exceptionAggregationBehavior .......... 338

exceptionAggregationSteps ................. 341

Exchange rate type ................................... 344

Exclusive lock .................................... 354, 364

Extend database table .............................. 544

Extend type .................................................. 544

Extensibility

CDS view ................................................... 539

on-premise ............................................... 541

standard field ......................................... 555

Extension association .......... 547, 549, 551

missing ...................................................... 552

Extension include view ................ 103, 189,

287, 547

extend ........................................................ 549

missing ...................................................... 553

External numbering ................................. 380

EXTRACTION_DATA_SOURCE ............. 268

F

F2 help ................................................ 49, 62, 93

Fact view ........................................................ 316

Factory calendar ......................................... 226

Feature control ........................................... 422

Field

annotation ........................... 239, 271, 288

custom ...................................................... 541

denormalized ......................................... 458

suppression ............................................. 453

variable ..................................................... 331

Field label ...................................................... 235

determine ................................................. 236

length ............................................... 237, 238

Field name .................................................... 277

abbreviation ........................................... 278

Filter criteria ...................................... 593, 595

Fiscal year ..................................................... 244

fltp_to_dec ..................................................... 64

FOR TESTING ............................................... 570

Foreign key ......................................... 245, 246

missing ...................................................... 554

table ........................................................... 245

view ............................................................ 246

Foreign key association ............... 247, 248,

310, 312

define ......................................................... 247

use ............................................................... 249

Formula in query ....................................... 335

Free-text search ....................... 511, 529, 530

Full access rule ............................................ 188

Function ........................................................ 405

FLTP_TO_DEC .......................................... 61

unit_conversion ...................................... 96

Fundamental data model ......................... 24


643

Index

Fuzziness ...................................................... 531

Fuzzy search ................................................ 511

G

GET_NUMERIC_VALUE ............................. 92

Greenfield .................................................... 365

GROUP BY statement ................... 58, 83, 84

H

Helper field .................................................. 534

Hierarchy .................................. 268, 269, 481

ABAP SQL ................................................. 508

aggregation ............................................ 509

association ............................................. 484

attributes ................................................. 498

base entity ............................................... 484

cache ......................................................... 508

create ........................................................... 41

cycle ........................................ 482, 500, 506

data source ............................................. 496

depth ......................................................... 508

descendants ............................................ 508

determine ................................................ 488

directory ............ 483, 487, 488, 491, 507

error source ............................................ 489

generate spantree ................................ 508

load ............................................................ 508

mixed ........................................................ 489

multiple parent nodes ........................ 504

navigation functions .......................... 508

node ........................................................... 488

node type ................................................. 508

node view ................................................ 485

ordinal number ............................ 500, 505

orphaned node ...................................... 503

parameters ............................................. 507

relational data model ........................ 483

strict .......................................................... 483

structure .................................................. 485

syntax limitations ............................... 497

test ............................................................. 490

time-dependent .................................... 507

view ............................................................ 484

visualizations ........................................ 500

Hierarchy engine .......... 483, 497, 499, 508

cycle ........................................................... 506

Hierarchy node .......................................... 482

level ............................................................ 483

HIERARCHY_DESCENDANTS ............... 508

hierarchy_is_cycle ................................... 507

hierarchy_is_orphan ...................... 500, 504

hierarchy_level .......................................... 499

hierarchy_parent_rank .......................... 500

hierarchy_rank ................................. 500, 505

hierarchy_tree_size ................................. 500

HTTP ETag .................................................... 432

I

I_CalendarDate .......................................... 327

Identifier field ............................................. 278

Inconsistency .............................................. 142

remove ...................................................... 143

technical ................................................... 143

Indicator ....................................................... 279

InfoObject name ............................... 317, 350

local ........................................................... 289

Information Access (InA) ....................... 349

protocol .................................................... 349

UI services ................................................ 212

Infrastructure

analytics .......................................... 299, 348

transactional .......................................... 355

Inheritance mechanism ......................... 172

side effects ............................................... 172

Instance authorization ........................... 151

Integration test ................................. 193, 567

Interface view ............................................. 273

Intermediate view ..................................... 548

INTERSECT element .................................... 75

IS INITIAL ...................................................... 604

IS NOT NULL ................................................ 599

IS NULL .......................................................... 599

J

Join ..................................................................... 76

cardinality ........................................... 77, 80

cross .............................................................. 77

inner ................................. 77, 114, 115, 159

left outer .... 58, 77, 79, 81, 114, 580, 598

multiple data sources ............................ 81

performance aspects .............................. 77

right outer .................................................. 77

K

Key

alternative ............................................... 130

definitions .................................................. 74

representative ........................................ 285


644

Index

Key field ........................................................... 59

representative ............................... 309, 312

Key performance indicator (KPI) ........ 300

Key user ......................................................... 300

extension ................................................. 540

L

Label text ......................................................... 61

LANGUAGE_DEPENDENT_TEXT ......... 267

Late numbering ......................................... 380

Leading model ............................................ 259

Leaf of a hierarchy .................................... 482

node ........................................................... 483

Leveled hierarchy ...................................... 481

Localized .............................................. 200, 252

elements ................................................... 446

Lock, node level .......................................... 388

Logical unit of work (LUW) .................... 431

M

Machine learning ...................................... 226

Manual test .................................................. 193

MappingRole ............................................... 625

Mass activation ............................................. 41

MAX ......................................................... 84, 241

Maximum .................................................... 240

Measure ................................................ 307, 340

analytic ..................................................... 302

calculate ................................................... 332

restricted .................................................. 336

Memory overflow ........................................ 84

Meta information ..................................... 231

Metadata .............................................. 135, 233

extension ................................................. 469

MIN .......................................................... 83, 241

Minimum ..................................................... 240

M-N relationship ....................................... 105

Model consistency .................................... 318

Model transformation ............................ 270

Modeling errors ......................................... 133

Modeling pattern ............................. 249, 267

Multiple parents ........................................ 504

N

Naming rules .............................................. 204

Node

business object ...................................... 252

distance from root ............................... 483

object ......................................................... 252

Node (Cont.)

orphaned ........................................ 500, 503

type ............................................................. 489

view ............................................................ 486

node_id .......................................................... 499

NONE .............................................................. 241

Non-null preserving expression ........... 64

NOT_RELEASED .......................................... 263

NOT_TO_BE_RELEASED ......................... 263

NOT_TO_BE_RELEASED_STABLE ........ 263

NULL value .......... 64, 80, 97, 132, 138, 141,

182, 566, 579, 580, 596, 599

annotating .............................................. 132

handling ..................................................... 80

Number range ............................................. 380

object ......................................................... 383

Numbering ................................................... 353

O

Object ............................................................. 252

model ......................................................... 359

node ........................................................... 252

Object type

DDLX .......................................................... 144

STOB ............................................................. 59

OData .......................... 17, 349, 357, 431, 468

ABAP code exits ..................................... 594

activation ................................................. 210

protocol .................................................... 237

SADL-based ............................................. 594

SAP Fiori ................................................... 466

UI ................................................................. 468

UI definition ............................................ 213

version ....................................................... 208

Web API ..................................................... 466

OData entity ................................................ 135

property .................................................... 205

set ......................................................... 56, 204

type ................................................... 135, 205

OData navigation property ................... 208

OData service .................... 35, 135, 233, 468

search ........................................................ 529

OLAP processor .......................................... 348

ON condition ............................ 100, 104, 112

Open dialog box ......................................... 294

Open SQL ...................................................... 389

Operation flow

interaction phase .................................. 462

save phase ............................................... 463

Optional element ...................................... 176

Orphaned ...................................................... 500


645

Index

Output node ................... 497, 498, 500, 505

OUTPUT_EMAIL_DATA_PROVIDER ... 269

OUTPUT_FORM_DATA_PROVIDER .. 269

OUTPUT_PARAMETER_

DETERMINATION_DATA_

SOURCE .................................................... 269

P

Parameter ............................. 67, 86, 168, 327

association definitions ......................... 89

names ................................................ 87, 282

variable .................................................... 331

Parent association ........................... 495–497

Parent node ........................................ 252, 485

multiple .................................................... 504

Parent relation ........................................... 482

PARENT_CHILD_HIERARCHY_

NODE_PROVIDER ................................ 268

PARENT_ID .................................................. 499

Parent-child hierarchy ................... 482, 486

Path expression ....... 44, 99, 100, 109, 112,

114, 120, 163, 191

CDS role .................................................... 169

parameters ................................................ 89

Performance aspects ............ 158, 169, 589

testing ....................................................... 596

Period From…To ........................................ 507

Persisted field value ................................. 593

Persistency model .................................... 595

PFCG_MAPPING ........................................ 193

Placeholder .................................................. 224

Point in time ...................................... 242, 279

Prechecks ..................................................... 429

Prediction procedure .............................. 227

Predictive analytics .................................. 226

Prefix .................................................... 280, 558

C_ ................................................................ 274

E_ ................................................................ 276

P_ ................................................................ 276

R_ ................................................................ 273

X_ ............................................................... 276

PRESERVING TYPE ....................................... 62

statement ................................................... 61

Principle of least privilege ..................... 151

Privileged access ....................................... 160

Programming model ............................... 232

Project Explorer ..................................... 36, 38

Projected associations ............................ 109

Projection ..................................................... 442

field ............................................................... 85

view ......................................... 197, 198, 252

Projection behavior

actions ...................................................... 456

definitions ............................ 353, 451, 455

operations and features .................... 453

precheck ................................................... 458

static field control ................................ 452

Propagation logic ................... 123, 137, 144

Provider implementation ..................... 373

Proxy object ................................................ 562

Q

Qualifier ............................................... 278, 279

QUAN ................................................................ 91

Quantity field .................................... 239, 279

Query

analytic ............................................ 299, 321

display attribute ................................... 184

layout ............................................... 324, 325

monitor .................................................... 322

settings ..................................................... 321

variable ..................................................... 185

Quick Assist ................................................. 586

Quick info ..................................................... 237

R

Read access ......................................... 156, 232

Readability ................................................... 145

Redundancy ....................................... 272, 287

Reference data model ................................. 24

entities ......................................................... 25

implementation ....................................... 26

Reference fields ................................... 91, 240

Regression .................................................... 193

issue .................................................. 561, 567

Regular expression ................................... 226

Release contract ......................................... 260

Release state ................................................ 262

deprecated ............................................... 264

RELEASED statement ...................... 263, 541

RELEASED_WITH_FEATURE_

TOGGLE .................................................... 263

Remote API view ....................................... 275

REPLACEMENT WITH statement ........ 178

REPLACING ROOT WITH statement .... 173

REPLACING WITH statement ............... 178

Report RUTDDLSV2MIGRATION ........... 55

Representation term ............................... 278

Representational State Transfer

(REST) ..................................... 354, 357, 434

Representative key field ................ 248, 251


646

Index

Responsive design .................................... 469

Restricted reuse view ............................... 273

ROLLBACK WORK ...................................... 431

ROOT .............................................................. 103

Root node ............................................ 252, 482

Root view ...................................................... 103

Runtime behavior ..................................... 285

Runtime orchestration ........................... 461

S

SAP Analysis for Microsoft Office ....... 323

SAP API Business Hub ............................. 289

SAP application programming

model for SAP Fiori ................................. 18

SAP client ...................................................... 219

SAP Fiori ............................................... 232, 478

architecture ............................................ 232

element ..................................................... 234

OData ........................................................ 466

SAP Fiori application ..... 17, 237, 258, 540

annotations ............................................ 468

define ......................................................... 468

SAP Fiori elements ................ 213, 369, 421,

468, 525

SAP Gateway ...................................... 235, 238

SAP Gateway service builder

project ....................................................... 198

SAP HANA ................................. 259, 284, 356

conversion functions ............................. 61

database ..................................................... 17

execution plan ....................................... 589

native functions .................................... 217

optimizer .......................................... 65, 592

script ............................................................. 56

table function ............................... 217, 221

SAP HANA Studio ...................................... 223

SAP List Viewer ........................................... 500

SAP S/4HANA ............................. 17, 353, 355

analytics ................................................... 299

architecture ................................... 232, 235

programming model ........................... 231

virtual data model ...................... 257, 355

SAP Web IDE ................................................ 478

SAPUI5 ........................................................... 479

Scope .............................................................. 628

ELEMENT .................................................. 134

Search

field ............................................................ 530

request ...................................................... 532

results ........................................................ 533

scope .......................................................... 534

Search functionality ................................. 511

check .......................................................... 534

SEARCHABLE_ENTITY .............................. 268

SELECT FROM statement .......................... 58

SELECT statement .......... 44, 57, 60, 99, 156

associations .............................................. 99

change ......................................................... 45

optimize .................................................... 592

SAP HANA database ............................ 595

Self-join .......................................................... 551

Semantic node .................................. 497, 499

Service Adaptation Definition

Language (SADL) ............. 35, 54, 56, 135,

191, 198, 357, 511, 531

Service binding ................................. 197, 206

name .......................................................... 207

type ............................................................. 207

Service definition ............................ 197, 201

names ........................................................ 203

specialized CDS entities ...................... 204

Service endpoint ........................................ 209

Service infrastructure .............................. 235

Session variable ....................... 219, 220, 224

CDS_CLIENT ............................................ 284

Setup method ................................... 570, 575

SIBLINGS ORDER ........................................ 497

Siblings order .............................................. 500

Side effect .................................. 353, 412, 421

SITUATION_ANCHOR .............................. 269

SITUATION_DATACONTEXT ................. 269

SITUATION_TRIGGER .............................. 269

Smart control .............................................. 234

Smart element–based UI ........................ 517

Smart template ........................................... 234

SOURCE .......................................................... 496

SQL aggregation function ........................ 82

performance aspects ............................. 84

SQL Console .......................................... 44, 224

SQL_DATA_SOURCE ................................. 267

SQLScript ............................................. 217, 226

Stability contract ....................................... 260

C0 ...................................................... 260, 539

C1 ....... 260, 261, 270, 284, 539, 547, 556

C2 ................................................................. 260

Standard aggregation .............................. 241

behavior ................................................... 307

types ........................................................... 241

Standard query ........................................... 303

Standard selection ...................................... 67

Star schema .................................................. 318

Start authorization ................................... 151

Start condition ............................................ 496


647

Index

START WHERE ............................................ 496

STATEMENT INHERITING

CONDITIONS FROM SUPER .............. 187

Static complexity ...................................... 590

Static field control ........................... 378, 452

Static operation control ......................... 378

STRING_AGG .............................................. 226

Structured query language (SQL) ......... 23,

53, 217

CREATE statement .................................. 37

functions .................................................. 427

operation ................................................. 355

select request ......................................... 233

Subannotation ........................................... 128

Suffixes ......................................................... 279

SUM ......................................................... 84, 241

Summation ................................................. 240

Supported capability ............................... 267

SY-DATLO ........................................................ 67

SY-DATUM ...................................................... 66

SY-LANGU ....................................................... 66

SY-MANDT ...................................................... 66

System field ........................................ 136, 331

System load ................................................. 285

System time-dependency ..................... 255

System times .............................................. 242

SY-UNAME ...................................................... 66

SY-ZONLO ........................................................ 67

T

Table definition ............................................ 30

Table function ............................................... 61

Template CDS model .................................. 33

Temporal data ............................................ 255

Test ABAP code .......................................... 580

Test automation ........................................ 561

Test classes .................................................. 583

adaptation .............................................. 586

Quick Assist ............................................ 587

Test double framework ................ 561, 562,

566, 581

decoupling option ....................... 566, 567

Test environment ..................................... 322

analytic views ........................................ 302

Text

association .................................... 251, 312

denormalization ................................... 200

relations ................................................... 249

view ................................ 251, 311, 312, 315

Text and languages .................................. 243

Time-dependent data .............................. 255

TO MANY ......................................................... 80

TO ONE ............................................................. 80

TO PARENT association .......................... 104

Transaction

/IWFND/MAINT_SERVICE ................. 210

/IWFND/V4_ADMIN ............................ 210

PFCG .......................................................... 154

RSRT .................................................. 322, 323

RSRTS_ODP ............................................. 490

RSRTS_ODP_DIS ...... 302, 314, 317, 490

SA38 ........................................................... 303

SACMSEL .................................................. 193

SE11 ................................................................ 28

SE38 ............................................................ 303

Transactional application ...................... 353

Transactional consistency ..................... 354

Transactional object model ........ 353, 358,

429, 442

calculated fields .................................... 428

data determinations and

validations ......................................... 412

define static properties ...................... 379

locks ........................................................... 385

restrict ....................................................... 442

Transactional service model ................ 353,

429, 442

define ......................................................... 442

Transactional view layer ........................ 359

Transport object ........................................... 33

Trigger condition ............................. 413, 420

Troubleshooting ........................................ 589

activation issues ................................... 613

incorrect annotation .......................... 608

Typed literal ................................................... 63

Type-preserving cast ................................... 63

U

UI annotation .................................... 234, 468

UI services .................................................... 206

UNION ALL logic ........................................... 74

UNION statement ................................. 69, 73

Union views .................................................... 69

association definitions .......................... 73

two-layer construction .......................... 72

UNIT ................................................................... 92

Unit conversion ..................................... 94, 96

Unit field ....................................................... 239

Universally unique identifier

(UUID) ....................................................... 278

USING CLIENT ......................................... 66, 67


648

Index

V

Value help ........................................... 511, 535

associated view ..................................... 517

expose ....................................................... 517

integrate ................................................... 515

modeling ......................................... 511, 512

nested ............................................... 513, 522

OData ........................................................ 518

service binding type ............................. 518

usage ......................................................... 518

Value view .................................................... 246

VALUE_HELP_PROVIDER ...................... 268

ValueListMapping ..................................... 521

ValueListParameterDisplayOnly ....... 522,

523

ValueListParameterInOut ... 521, 523, 525

ValueListParameterOut .......................... 524

Variable ......................................................... 327

analytic ..................................................... 327

derivation ................................................ 331

values ........................................................ 329

Variant

extend abstract entity ........................ 542

extend custom entity .......................... 542

extend view ............................................. 542

extend view entity ................................ 542

VDM view ..................................................... 258

extension ................................................. 276

extension include ................................. 276

find ............................................................. 289

names ........................................................ 279

private ....................................................... 276

reuse .......................................................... 259

View

Active annotations ................................. 50

analytic ............................................ 299, 301

annotation .............................................. 283

CDS navigator ........................................... 48

extension ................................................. 276

View (Cont.)

I_SalesOrder ............................................ 286

migration ................................................... 55

outline ......................................................... 47

Problems tab ................................. 609, 612

Properties ................................................... 39

Relation Explorer .................................... 49

reuse ........................................................... 114

search .......................................................... 47

stack ........................................................... 546

static complexity ............... 113, 114, 169

structure ................................................... 286

View Browser ............................................... 289

View entity ......................................... 303, 322

extension .................................................. 545

Virtual data model (VDM) ....... 17, 26, 257,

301, 355

deprecation ............................................. 264

layers ......................................................... 270

lifecycle ..................................................... 260

naming ............................................ 270, 277

principles .................................................. 259

stability ..................................................... 260

structure ................................................... 270

types ........................................................... 276

visibility .................................................... 260

Virtual element .......................................... 447

Virtual field .................................................... 92

W

Web API

OData ........................................................ 466

services ...................................................... 211

WHERE statement ....................................... 58

Where-used list .................................... 47, 297

WITH PARAMETERS element ................. 86

WITH PRIVILEGED ACCESS .................... 190

WITH USER ELEMENT .............................. 181

Wrapper view .............................................. 225

Write access ................................................. 232


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 usa-ge and exploitation rights are reserved by the author and the publisher.

Renzo Colle is currently responsible for the programming model of SAP S/4HANA in the central architecture group. He studied business mathematics at the Karlsruhe Institute of Technology (https://www.kit.edu/english/) and has worked at SAP for more than 24 years in a wide variety of areas and roles. He started his

career at SAP as a developer in strategic customer 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. He joined SAP more than 20 years ago. He developed 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. He is married and has two sons.

Colle, Dentzer, Hrastnik

Core Data Services for ABAP525 pages, 2nd, updated and revised edition 2022, $89.95 ISBN 978-1-4932-2109-7

www.sap-press.com/5294

Jan Hrastnik is a member of the SAP S/4HANA suite’s architec-ture team, where he focuses on the virtual data model and the use of core data services in ABAP applications. He has worked in various SAP development areas for more than 15 years. At the beginning of his career, he supported numerous customer pro-

jects in the automotive industry. Subsequently, he worked in the supply chain management development of SAP Business ByDesign.

https://www.sap-press.com/core-data-services-for-abap_5294/?utm_source=AWS&utm_medium=readingsample&utm_campaign=Browse+the+Book&utm_content=2109

“modeling transactional applications” contents index the

Documents