Avalados por :
Understanding the RESTful ABAP Programming Model (RAP) with CDS and Annotations for SAP Development
- Creado 01/03/2024
- Modificado 01/03/2024
- 21 Vistas
0
Cargando...
Hello Guys,
In this blog we will learn new programming model RAP in detail with an example, I would recommend to go through the theory as well before you start coding to understand RAP basics.I would like to thank my colleagues in SAP specially Kailash Satapathy and Gaurav Kumar for helping me in writing this blog.
Prerequisite:
Concepts of Core Data Services(CDS) and annotations.
Lets Start 🙂
RESTful ABAP Programming Model (RAP): The term RESTful ABAP Programming Model ( RAP ) is chosen to reflect its orientation towards a “stateless” REST architecture.
We will start with ABAP evolution over the years: -
Evolution of the ABAP Programming Model
We kick started our ABAP WORLD with classical ABAP programming using reports and module pool programs, then we moved to BSP/Webdynpro with FPM (for UI harmonization), then slowly shifted from ERP style developments to S/4 HANA model developments where our major programming consists of artifacts like CDS, BOPF, GW and Fiori.
ABAP Programming model for SAP Fiori (Current best practice) : -
This development model usually consists of CDS view, BOPF and GW where CDS is tightly coupled with BOPF and GW (using RDS Mapping or using @OData.Publish annotation).
Note : Issue with this model is flow is not well defined
Future Direction - New Programming Model (ABAP Restful Programming Model)
RESTful ABAP Programming model in detail: -
The ABAP RESTful programming model defines the architecture for efficient end-to-end development of intrinsically SAP HANA-optimized OData services (such as Fiori apps) in SAP Cloud Platform ABAP Environment. It supports the development of all types of Fiori applications as well as A2X services. It is based on technologies and frameworks such as Core Data Services (CDS) for defining semantically rich data models and a service model infrastructure for creating OData services with bindings to an OData protocol and ABAP-based application services for custom logic and SAPUI5-based user interfaces – as shown in the figure below
Understanding Concepts
A business object (BO) is a common term to represent a real-world artifact in enterprise application development such as the Product, the Travel, or the SalesOrder. In general, a business object contains several nodes such as Items and and common transactional operations such as for creating, updating and deleting data and additional application-specific operations, such as Approve in a SalesOrder business object.
From a formal point of view, a business object is characterized by
See the figure for more details.
1.1 Structure of a Business Object
From structural aspect, a business object consists of a tree of nodes ( SalesOrder , Items , ScheduleLines ) where the nodes are linked by means of a special kind of associations, the compositions. A composition is specialized association that defines a whole-part relationship. A composite part only exists together with its parent entity (whole).
Each node of this composition tree is an element that is modelled with a CDS entity . The root entity is of particular importance: This is considered in the source code of the CDS data definition with the keyword ROOT . The root entity serves as a representation of the business object and defines the top node in a business object's structure.
1.2 Behavior of a Business Object
Each entity of the business object can offer the standard CUD operations create(), update() and delete(). In addition, each entity can also offer specific operations with a dedicated input and output structure which are called actions. The offered CUD operations, actions as well some behavior-relevant properties, such as lock dependencies between the parent and
In this blog we will learn new programming model RAP in detail with an example, I would recommend to go through the theory as well before you start coding to understand RAP basics.I would like to thank my colleagues in SAP specially Kailash Satapathy and Gaurav Kumar for helping me in writing this blog.
Prerequisite:
Concepts of Core Data Services(CDS) and annotations.
Lets Start 🙂
RESTful ABAP Programming Model (RAP): The term RESTful ABAP Programming Model ( RAP ) is chosen to reflect its orientation towards a “stateless” REST architecture.
We will start with ABAP evolution over the years: -
Evolution of the ABAP Programming Model
We kick started our ABAP WORLD with classical ABAP programming using reports and module pool programs, then we moved to BSP/Webdynpro with FPM (for UI harmonization), then slowly shifted from ERP style developments to S/4 HANA model developments where our major programming consists of artifacts like CDS, BOPF, GW and Fiori.
ABAP Programming model for SAP Fiori (Current best practice) : -
This development model usually consists of CDS view, BOPF and GW where CDS is tightly coupled with BOPF and GW (using RDS Mapping or using @OData.Publish annotation).
Note : Issue with this model is flow is not well defined
Future Direction - New Programming Model (ABAP Restful Programming Model)
RESTful ABAP Programming model in detail: -
The ABAP RESTful programming model defines the architecture for efficient end-to-end development of intrinsically SAP HANA-optimized OData services (such as Fiori apps) in SAP Cloud Platform ABAP Environment. It supports the development of all types of Fiori applications as well as A2X services. It is based on technologies and frameworks such as Core Data Services (CDS) for defining semantically rich data models and a service model infrastructure for creating OData services with bindings to an OData protocol and ABAP-based application services for custom logic and SAPUI5-based user interfaces – as shown in the figure below
Understanding Concepts
- Business Object
A business object (BO) is a common term to represent a real-world artifact in enterprise application development such as the Product, the Travel, or the SalesOrder. In general, a business object contains several nodes such as Items and and common transactional operations such as for creating, updating and deleting data and additional application-specific operations, such as Approve in a SalesOrder business object.
From a formal point of view, a business object is characterized by
- a structure,
- a behavior and
- the corresponding runtime implementation.
See the figure for more details.
1.1 Structure of a Business Object
From structural aspect, a business object consists of a tree of nodes ( SalesOrder , Items , ScheduleLines ) where the nodes are linked by means of a special kind of associations, the compositions. A composition is specialized association that defines a whole-part relationship. A composite part only exists together with its parent entity (whole).
Each node of this composition tree is an element that is modelled with a CDS entity . The root entity is of particular importance: This is considered in the source code of the CDS data definition with the keyword ROOT . The root entity serves as a representation of the business object and defines the top node in a business object's structure.
1.2 Behavior of a Business Object
Each entity of the business object can offer the standard CUD operations create(), update() and delete(). In addition, each entity can also offer specific operations with a dedicated input and output structure which are called actions. The offered CUD operations, actions as well some behavior-relevant properties, such as lock dependencies between the parent and
Pedro Pascal
Se unió el 07/03/2018
Facebook
Twitter
Pinterest
Telegram
Linkedin
Whatsapp
Sin respuestas
No hay respuestas para mostrar
Se el primero en responder
contacto@primeinstitute.com
(+51) 1641 9379
(+57) 1489 6964
© 2024 Copyright. Todos los derechos reservados.
Desarrollado por Prime Institute
Hola ¿Puedo ayudarte?