The VDM is the foundational data model for all application types in SAP S/4HANA. The VDM is enhanced with BOPF or behavior definitions and is accessed via CDS views. Associations are used to define relationships between CDS views similarly to joins. Data access via CDS views can be restricted using DCL authorization objects. BOPF adds business logic to the VDM while still deriving the data model from the underlying VDM using hierarchy annotations.
The VDM is the foundational data model for all application types in SAP S/4HANA. The VDM is enhanced with BOPF or behavior definitions and is accessed via CDS views. Associations are used to define relationships between CDS views similarly to joins. Data access via CDS views can be restricted using DCL authorization objects. BOPF adds business logic to the VDM while still deriving the data model from the underlying VDM using hierarchy annotations.
The VDM is the foundational data model for all application types in SAP S/4HANA. The VDM is enhanced with BOPF or behavior definitions and is accessed via CDS views. Associations are used to define relationships between CDS views similarly to joins. Data access via CDS views can be restricted using DCL authorization objects. BOPF adds business logic to the VDM while still deriving the data model from the underlying VDM using hierarchy annotations.
The VDM is the foundational data model for all application types in SAP S/4HANA. The VDM is enhanced with BOPF or behavior definitions and is accessed via CDS views. Associations are used to define relationships between CDS views similarly to joins. Data access via CDS views can be restricted using DCL authorization objects. BOPF adds business logic to the VDM while still deriving the data model from the underlying VDM using hierarchy annotations.
Download as DOCX, PDF, TXT or read online from Scribd
Download as docx, pdf, or txt
You are on page 1/ 4
The VDM is the foundation for all application types in SAP S/4HANA and is enhanced with the
BOPF (earlier than SAP S/4HANA 1909) or behavior definitions (since SAP S/4HANA 1909)
The technological core enabler of the VDM is the CDS technology, which consists of a DDL, a query language, and a Data Control Language (DCL). CDS artifacts are new development objects in the ABAP stack that use the standard transport lifecycle management system of ABAP, although these development objects are executed in SAP HANA.
Associations are used to express relationships between different CDS views and resemble joins but are easier to read because they don’t directly program the joins.
Data access via CDS views can be restricted by using the data control language (DCL) of CDS. In a DCL file, authorizations are declared via standard ABAP authorization objects BOPF only adds the business logic of the application, the underlying data model is always derived from the VDM by making use of specific hierarchy annotations for modeling the BOPF node structure on the CDS level. BOPF has been aimed at stateful business applications, but a lot of effort has been put into optimizing BOPF for stateless data processing. Classic SAP Dynpro or Web Dynpro applications rely on an ABAP session along with application buffers that serve client requests until the user has finished his work and stored all the data changes. SAP Fiori applications, on the other hand, fetch data using RESTful OData services, which are stateless like the HTTP that is used as the data transfer protocol. Statelessness is also a core property of the RESTful paradigm and has some advantages over stateful applications:
You can also implement a stateful application scenario using stateless communication and BOPF, but instead of storing data in an in-memory ABAP session context, data must be stored on the database using draft tables, which are shadow tables of the original database tables. Users can work on the draft data for several interaction steps and roundtrips, and when finished editing the entity, the draft data can be activated and written to the actual database tables.
When a user is changing business data and jumps between the input fields on the screen, the changes are sent to the backend immediately via an OData request that updates the draft table(s) instead of the original database tables. Each draft update sent to the backend like this is called a roundtrip
Transactional Application Scenarios In general, the ABAP programming model for SAP Fiori, available since SAP S/4HANA 1610 SPS 03, supports four different transactional application scenarios based on BOPF and CDS: New application with draft enablement New application without draft enablement Draft enablement of existing application Read-only application with quick actions (BOPF is only used for actions but not for CRUD operations)
shows the different building blocks of the ABAP RESTful programming model. As in the previous programming model, a data model based on CDS views serves as the foundation. If only read access to the database is required, the query component takes over the data retrieval for an OData service. The transactional counterpart of a query is a business object with additional ABAP-based behavior definition and implementation. The service definition defines which CDS entities of the data model should be exposed as OData entities. The service binding then binds the exposed entities to a client communication protocol, as of now OData version 2.0. The business service can then be offered as an SAP Fiori UI, by adding an SAP Fiori elements UI or other UI clients to the service, or as a web API, for any consumer capable of consuming an OData REST API, for instance, freestyle OpenUI5 applications.
