View
2
Download
0
Category
Preview:
Citation preview
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
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
2109.book Seite 354 Mittwoch, 22. September 2021 7:13 19
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.
11.2 Transactional Infrastructure in SAP S/4HANA
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
2109.book Seite 355 Mittwoch, 22. September 2021 7:13 19
356
11 Modeling Transactional Applications
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.
2109.book Seite 356 Mittwoch, 22. September 2021 7:13 19
357
11.2 Transactional Infrastructure in SAP S/4HANA
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.
2109.book Seite 357 Mittwoch, 22. September 2021 7:13 19
358
11 Modeling Transactional Applications
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
2109.book Seite 358 Mittwoch, 22. September 2021 7:13 19
359
11.3 Transactional Object Models
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
2109.book Seite 359 Mittwoch, 22. September 2021 7:13 19
360
11 Modeling Transactional Applications
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: #CHECK@EndUserText.label: '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,
2109.book Seite 360 Mittwoch, 22. September 2021 7:13 19
361
11.3 Transactional Object Models
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: #CHECK@EndUserText.label: '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
2109.book Seite 361 Mittwoch, 22. September 2021 7:13 19
362
11 Modeling Transactional Applications
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: #CHECK@EndUserText.label: '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
association [1] to I_User as _LastChangedByUseron $projection.LastChangedByUser = _LastChangedByUser.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,
2109.book Seite 362 Mittwoch, 22. September 2021 7:13 19
363
11.3 Transactional Object Models
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 {
2109.book Seite 363 Mittwoch, 22. September 2021 7:13 19
364
11 Modeling Transactional Applications
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.
2109.book Seite 364 Mittwoch, 22. September 2021 7:13 19
365
11.4 Behavior Definitions
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;
2109.book Seite 365 Mittwoch, 22. September 2021 7:13 19
366
11 Modeling Transactional Applications
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
2109.book Seite 366 Mittwoch, 22. September 2021 7:13 19
367
11.4 Behavior Definitions
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.
2109.book Seite 367 Mittwoch, 22. September 2021 7:13 19
368
11 Modeling Transactional Applications
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.
2109.book Seite 368 Mittwoch, 22. September 2021 7:13 19
369
11.4 Behavior Definitions
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
2109.book Seite 369 Mittwoch, 22. September 2021 7:13 19
370
11 Modeling Transactional Applications
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: #CHECK@EndUserText.label: '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
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,@Semantics.systemDateTime.createdAt: trueZR_SalesOrder.CreationDateTime,@Semantics.user.lastChangedBy: trueZR_SalesOrder.LastChangedByUser,@Semantics.systemDateTime.lastChangedAt: trueZR_SalesOrder.LastChangeDateTime,
2109.book Seite 370 Mittwoch, 22. September 2021 7:13 19
371
11.4 Behavior Definitions
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{
2109.book Seite 371 Mittwoch, 22. September 2021 7:13 19
372
11 Modeling Transactional Applications
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)
2109.book Seite 372 Mittwoch, 22. September 2021 7:13 19
373
11.4 Behavior Definitions
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.
2109.book Seite 373 Mittwoch, 22. September 2021 7:13 19
374
11 Modeling Transactional Applications
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
2109.book Seite 374 Mittwoch, 22. September 2021 7:13 19
375
11.4 Behavior Definitions
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
2109.book Seite 375 Mittwoch, 22. September 2021 7:13 19
376
11 Modeling Transactional Applications
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.
2109.book Seite 376 Mittwoch, 22. September 2021 7:13 19
377
11.4 Behavior Definitions
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
2109.book Seite 377 Mittwoch, 22. September 2021 7:13 19
378
11 Modeling Transactional Applications
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.
2109.book Seite 378 Mittwoch, 22. September 2021 7:13 19
379
11.4 Behavior Definitions
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;
2109.book Seite 379 Mittwoch, 22. September 2021 7:13 19
380
11 Modeling Transactional Applications
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
2109.book Seite 380 Mittwoch, 22. September 2021 7:13 19
381
11.4 Behavior Definitions
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.
2109.book Seite 381 Mittwoch, 22. September 2021 7:13 19
382
11 Modeling Transactional Applications
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
2109.book Seite 382 Mittwoch, 22. September 2021 7:13 19
383
11.4 Behavior Definitions
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,
2109.book Seite 383 Mittwoch, 22. September 2021 7:13 19
384
11 Modeling Transactional Applications
"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'
2109.book Seite 384 Mittwoch, 22. September 2021 7:13 19
385
11.4 Behavior Definitions
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.
2109.book Seite 385 Mittwoch, 22. September 2021 7:13 19
386
11 Modeling Transactional Applications
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
2109.book Seite 386 Mittwoch, 22. September 2021 7:13 19
387
11.4 Behavior Definitions
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).
2109.book Seite 387 Mittwoch, 22. September 2021 7:13 19
388
11 Modeling Transactional Applications
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.
2109.book Seite 388 Mittwoch, 22. September 2021 7:13 19
389
11.4 Behavior Definitions
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.
2109.book Seite 389 Mittwoch, 22. September 2021 7:13 19
390
11 Modeling Transactional Applications
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 =
zcm_salesorder=>if_abap_behv_message~severity-error)
) TO reported-salesorder.ENDIF.
ENDIF.IF requested_authorizations-%update = if_abap_behv=>mk-on.AUTHORITY-CHECK OBJECT 'V_VBAK_AAT'
ID 'ACTVT' FIELD '02'ID 'AUART' DUMMY.
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 =
2109.book Seite 390 Mittwoch, 22. September 2021 7:13 19
391
11.4 Behavior Definitions
11
zcm_salesorder=>if_abap_behv_message~severity-error)
) TO reported-salesorder.ENDIF.
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 =
zcm_salesorder=>if_abap_behv_message~severity-error)
) TO reported-salesorder.ENDIF.
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.…
2109.book Seite 391 Mittwoch, 22. September 2021 7:13 19
392
11 Modeling Transactional Applications
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 =
zcm_salesorder=>if_abap_behv_message~severity-error)
) TO reported-salesorder.ENDIF.
ENDIF.IF requested_authorizations-%action-Delete = if_abap_behv=>mk-on.
AUTHORITY-CHECK OBJECT 'V_VBAK_AAT'ID 'ACTVT' FIELD '06'ID 'AUART' FIELD <salesorder>-SalesOrderType.
IF sy-subrc <> 0.APPEND VALUE #( %tky = <salesorder>-%tky
%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 =
zcm_salesorder=>if_abap_behv_message~severity-error)
) TO reported-salesorder.
2109.book Seite 392 Mittwoch, 22. September 2021 7:13 19
393
11.4 Behavior Definitions
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.
2109.book Seite 393 Mittwoch, 22. September 2021 7:13 19
394
11 Modeling Transactional Applications
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.
2109.book Seite 394 Mittwoch, 22. September 2021 7:13 19
395
11.4 Behavior Definitions
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
2109.book Seite 395 Mittwoch, 22. September 2021 7:13 19
396
11 Modeling Transactional Applications
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.
2109.book Seite 396 Mittwoch, 22. September 2021 7:13 19
397
11.4 Behavior Definitions
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.
abstract;strict;with hierarchy;
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
2109.book Seite 397 Mittwoch, 22. September 2021 7:13 19
398
11 Modeling Transactional Applications
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
abstract;strict;with hierarchy;
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;
2109.book Seite 398 Mittwoch, 22. September 2021 7:13 19
399
11.4 Behavior Definitions
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'
ID 'ACTVT' FIELD '06'ID 'AUART' DUMMY.
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.
AUTHORITY-CHECK OBJECT 'V_VBAK_AAT'ID 'ACTVT' FIELD '06'ID 'AUART' FIELD <salesorder>-SalesOrderType.
IF sy-subrc <> 0.APPEND VALUE #( %tky = <salesorder>-%tky
%action-Delete = if_abap_behv=>mk-on) TO result.
ENDIF.ENDIF.
ENDLOOP.…
Listing 11.27 Behavior Implementation: Instance Authority Check for Action
Delete
2109.book Seite 399 Mittwoch, 22. September 2021 7:13 19
400
11 Modeling Transactional Applications
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
2109.book Seite 400 Mittwoch, 22. September 2021 7:13 19
401
11.4 Behavior Definitions
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.
2109.book Seite 401 Mittwoch, 22. September 2021 7:13 19
402
11 Modeling Transactional Applications
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.
2109.book Seite 402 Mittwoch, 22. September 2021 7:13 19
403
11.4 Behavior Definitions
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).
2109.book Seite 403 Mittwoch, 22. September 2021 7:13 19
404
11 Modeling Transactional Applications
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
2109.book Seite 404 Mittwoch, 22. September 2021 7:13 19
405
11.4 Behavior Definitions
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).
abstract;strict;with hierarchy;
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.
2109.book Seite 405 Mittwoch, 22. September 2021 7:13 19
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
2109.book Seite 7 Mittwoch, 22. September 2021 7:13 19
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
2109.book Seite 8 Mittwoch, 22. September 2021 7:13 19
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
2109.book Seite 9 Mittwoch, 22. September 2021 7:13 19
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
2109.book Seite 10 Mittwoch, 22. September 2021 7:13 19
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
2109.book Seite 11 Mittwoch, 22. September 2021 7:13 19
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
2109.book Seite 12 Mittwoch, 22. September 2021 7:13 19
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
2109.book Seite 13 Mittwoch, 22. September 2021 7:13 19
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
2109.book Seite 14 Mittwoch, 22. September 2021 7:13 19
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
2109.book Seite 15 Mittwoch, 22. September 2021 7:13 19
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
@AnalyticsDetails.query.
formula ........................................... 335, 623
@AnalyticsDetails.query.hidden ....... 623
@AnalyticsDetails.query.
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
@Consumption.valueHelpDefinition.
additionalBinding.element .............. 624
@Consumption.valueHelpDefinition.
additionalBinding.localElement .... 624
@Consumption.valueHelpDefinition.
association ..................................... 517, 624
@Consumption.valueHelpDefinition.
entity.element .............................. 516, 624
@Consumption.valueHelpDefinition.
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
2109.book Seite 635 Mittwoch, 22. September 2021 7:13 19
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
@ObjectModel.usageType.
serviceQuality ..................... 136, 285, 627
@ObjectModel.usageType.
serviceQuality… ..................................... 590
@ObjectModel.usageType.
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
2109.book Seite 636 Mittwoch, 22. September 2021 7:13 19
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
2109.book Seite 637 Mittwoch, 22. September 2021 7:13 19
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
2109.book Seite 638 Mittwoch, 22. September 2021 7:13 19
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
2109.book Seite 639 Mittwoch, 22. September 2021 7:13 19
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
2109.book Seite 640 Mittwoch, 22. September 2021 7:13 19
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
2109.book Seite 641 Mittwoch, 22. September 2021 7:13 19
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
2109.book Seite 642 Mittwoch, 22. September 2021 7:13 19
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
2109.book Seite 643 Mittwoch, 22. September 2021 7:13 19
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
2109.book Seite 644 Mittwoch, 22. September 2021 7:13 19
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
2109.book Seite 645 Mittwoch, 22. September 2021 7:13 19
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
2109.book Seite 646 Mittwoch, 22. September 2021 7:13 19
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
2109.book Seite 647 Mittwoch, 22. September 2021 7:13 19
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
2109.book Seite 648 Mittwoch, 22. September 2021 7:13 19
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.
Recommended