Build composition tree with ABAP CDS views
Parent child relationship in CDS data modeling for ABAP RESTful application programming model (RAP)
The ABAP RESTful application programming model (RAP) 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 or Application Server ABAP.
For more detals refer to ABAP RESTful application programming model
- You are an ABAP developer and use CDS views for data modeling
- You are a newbie to ABAP RESTful programming model (RAP)
- You like to get few insights into RAP and build composition tree(parent-child) into CDS views
So, lets define a simple business use case and build composition tree with CDS
- ABAP Platform for S/4Hana 1909 or SAP Cloud Platform, ABAP environment
- ABAP Development Tools (ADT)
- Develop a business application for a travel agency with ABAP RESTful programming model
- The travel agency can book travel trips for customers
- The travel trip can include multiple bookings
- Each booking can include multiple booking supplements like refreshments during flight
- The relevant travel, booking and booking supplement data will be provided via UI (web IDE/BAS)
- The business object should represent a parent child hierarchy
- Travel is the root entity for the hierarchy.
- Booking is the child node of travel
- Booking supplement is grandchild node of travel
- A travel can exist without a valid booking – only root as single node is allowed
- A booking cannot exist without a valid travel – no orphans allowed
- A booking supplement cannot exist without a booking-– no orphans allowed
- Possibility to create, update and delete any node-no orphans allowed
- Perform calculations, validate input values and reject instance creation (if needed)
- Create database tables for data persistence and create parent-child relationship via foreign key associations
- In this scenario, primary keys-travel_id, booking_id and booking_supplement_id are sematic keys
- DB table for Travel entity has travel_id as primary key
- Any new travel(instance) created for travel entity will be identified with this primary key
- DB table for Booking entity has booking_id and travel_id as primary keys
- Any new booking(instance) created for entity booking should belong to entity set travel
- This means, travel is the parent entity and bookings are child entities
- Field travel_id of DB table for Booking entity has a foreign key relationship to field travel_id of DB table for travel entity
- Any new booking supplement(instance) created for entity booking supplement should belong to entity set travel
- Entity booking supplement has booking entity as parent and travel entity as root
- DB table for Booking supplement entity has a foreign key relationship to field booking_id and travel_id of DB table for booking entity
- Foreign key relation is not mandatory to build a composition tree
- It is recommended to have foreign key association
- For interface views, new version of CDS views-CDS view entities (DEFINE VIEW ENTITY…) are used (these currently only supported in SAP Cloud Platform, ABAP environment)
- You can also use existing CDS DDIC-managed views with DEFINE VIEW …. (you must use these in SAP S/4 HANA on premise systems, but it is planned to support view entities in future releases here as well)
- Create interface CDS view entities for corresponding database tables and build parent-child relationship via compositions to parent and child
- These interface views not service agnostic and reusable in multiple business applications
- Interface view for Travel is indicated with DEFINE ROOT VIEW ENTITY ZHB_I_TRAVEL_TCVE as Travel
- Usage of ROOT syntax makes Travel as entity set and parent node
- Interface view for Booking is indicated with DEFINE VIEW ENTITY ZHB_I_BOOKING_TCVE as Booking
- Usage of composition of ZHB_I_BOOKING_TCVE as _Booking syntax makes Travel as parent and booking as child
- Interface view for Booking supplement is indicated with DEFINE VIEW ENTITY ZHB_I_BOOKING_SUPPLEMENT_TCVE
- Usage of composition of ZHB_I_BOOKING_SUPPLEMENT_TCVE as _BookingSupplement syntax makes booking as parent and booking supplement as child
- When defining a parent child relationship, you have to perform changes in both the parent and the child entity.
- Since these changes depend on each other you have to use mass activation when you edit both sources at the same time.
- When you want to perform the changes in a sequential way you have to start with defining the association to parent in the child entity.
- After having activated your changes in the child entity you can then define the composition in the parent entity that points to the child entity.
- Example: It is preferred to define association to parent ZHB_I_TRAVEL_TCVE in entity booking and then composition of ZHB_I_BOOKING_TCVE in entity travel
- Create projection CDS view entities for corresponding interface views
- Via REDIRECTED TO syntax project the parent-child relationships defined in interface views
- These projection views are service agnostic and dedicated to a single business application
- Projection view for Travel as parent is indicated with DEFINE ROOT PROJECTION VIEW ENTITY ZHB_C_TRAVEL_TCVE
- Usage of redirected to composition child ZHB_C_BOOKING_TCVE syntax defines ZHB_C_TRAVEL_TCVE (Travel) as parent and ZHB_C_BOOKING_TCVE (Booking) as child
- Projection view for Booking is indicated with DEFINE PROJECTION VIEW ENTITY ZHB_C_BOOKING_TCVE
- Usage of redirected to parent ZHB_C_TRAVEL_TCVE syntax defines ZHB_C_TRAVEL_TCVE(Travel) as parent and ZHB_C_BOOKING_TCVE (Booking) as child
- Usage of redirection to composition child composition of ZHB_C_BOOKING_SUPPLEMENT_TCVE syntax defines ZHB_C_BOOKING_TCVE (Booking) as parent and ZHB_C_BOOKING_SUPPLEMENT_TCVE (Booking supplement) as child
- Projection view for Booking supplement is indicated with DEFINE PROJECTION VIEW ENTITY /DMO/C_BUKSU_CVE
- Usage of redirected to parent ZHB_C_BOOKING_TCVE syntax defines ZHB_C_BOOKING_TCVE(BOOKING) as parent and ZHB_C_BOOKING_SUPPLEMENT_TCVE (Booking supplement) as child
- In some cases, it is necessary for the grandchild (Booking supplement) or any node at the end of parent-child relation (for example nth node) to have a direct association with root node
- For this scenario, Usage of redirected to ZHB_C_TRAVEL_TCVE (root) syntax in projection entity ZHB_C_BOOKING_SUPPLEMENT_TCVE is used, when
- Interface view ZHB_I_BOOKING_SUPPLEMENT_TCVE (grandchild) has an association to ZHB_I_TRAVEL_TCVE (root) – association to ZHB_I_TRAVEL_TCVE as _Travel on $projection.travel_id = _Travel.Travel_ID
- In this case, usage of redirected to ZHB_C_TRAVEL_TCVE syntax in projection view defines association b/w nth node and root node
Next steps to continue with development of oData service:
- Create a service definition to define the service model that is generically derived from the previously created CDS-based data model
- Create a service binding to bind a service definition to a client-server communication protocol such as OData
Conclusion: After reading through this blog post, you will have
- a basic understanding of CDS based data model in ABAP
- creation of composition tree for existing CDS data model
For more technical details to CDS projection views, refer to blog post from Andrea Schlotthauer here
Getting started with ABAP RESTful programming model
Images and nomenclature:
- ABAP RESTful Application Programming Model Image from here,
- CDS views and Database tables-self
Thank you so much for the detailed blog.
Can you share the Odata URL and Json response for the above example.
And also could you confirm if the above example works with parameters. For example we need to get values of travel ID passed by the third party system or UI? Because i read that Projection view doesn't support parameters. Please correct me if my understanding is wrong.
Thanks & Best Regards,
It is not possible to use parameters in projections.
You could have an action with parameters which can be provided via UI popup.
Does "Deep create ( create option on suppliment ) is supported only with OData V4 but not OData V2 ?
I have published Service definition "/DMO/UI_TRAVEL_D_D" in both OData versions.
OData V4 : ZRK_UI_TRAVEL_D_D_O4
OData V2 : ZRK_UI_TRAVEL_D_D_O2.
Deep CREATE Available in OData V4
Deep CREATE not Available in OData V2
It is not supported in preview as mentioned by SAP in Constraints.
I got a solution ( tip ) for OData V2.
It seems CREATE is not enabled by default. But this can be enabled in fiori app manifest.json file.
you can go to the end of this blog post.
Thank you for the comment, it helped me.
Now with Business Application Studio you can just add the ObjectPage in the Page Map.
Hi Ramjee, i tried publish the service binding OData V4 but get a error, so i use transaction /n/IWFND/V4_ADMIN to do that and run the test preview for check, so all ok. But when i tried consume the service OData V4 in BAS or VScode it don't show in options of services, only OData V2, i don't know why. Had you some problem like this?
Have you faced this error while creating child projection views? (without keyword root).
Transactional Projection View must be part of a business object.