Technical Articles
How to design managed RAP business objects with 3 or more levels of nodes
Introduction
Based on a question that I was asked in the community about a RAP BO with more than three levels of nodes that have UUID based keys I saw that the answer section is to small to add all the information in a format that is nice to digest.
Therefore I thought to publish my answer as a blog post alongside with a working sample that I have published on GitHub.
The root node
When using UUID based tables you just need one UUID based key field for each table. Since UUID values are unique by definition we don’t need additional key fields for child tables as it is required for tables having semantic key fields (salesid, itemid, schedulingid, …).
For a table that is used as the datasource of the root node of our RAP BO we can use the following table.
@EndUserText.label : 'RAP Generator Business Object Header'
@AbapCatalog.enhancement.category : #NOT_EXTENSIBLE
@AbapCatalog.tableCategory : #TRANSPARENT
@AbapCatalog.deliveryClass : #A
@AbapCatalog.dataMaintenance : #RESTRICTED
define table zuuid_level_1 {
key client : abap.clnt not null;
key uuid_level_1 : sysuuid_x16 not null;
semantic_key_1 : abap.char(10);
description : abap.char(50);
local_created_by : abp_creation_user;
local_created_at : abp_creation_tstmpl;
local_last_changed_by : abp_locinst_lastchange_user;
local_last_changed_at : abp_locinst_lastchange_tstmpl;
last_changed_at : abp_lastchange_tstmpl;
}
For the table that is used as a root node you should define administrative fields such as local_created_by, local_created_at, local_last_changed_by, local_last_changed_at and finally last_changed_at so that all the information that is required for a draft enabled RAP BO can be stored.
Child nodes
Tables that are used for child nodes only need one additional administrative field, namely local_last_changed_at.
In addition to the UUID based key field we need one additional field sysuuid_x16 that will be used by the framework to store the UUID based value of the key field of the root entity.
@EndUserText.label : 'RAP Generator Business Object Header'
@AbapCatalog.enhancement.category : #NOT_EXTENSIBLE
@AbapCatalog.tableCategory : #TRANSPARENT
@AbapCatalog.deliveryClass : #A
@AbapCatalog.dataMaintenance : #RESTRICTED
define table zuuid_level_2 {
key client : abap.clnt not null;
key uuid_level_2 : sysuuid_x16 not null;
parent_uuid : sysuuid_x16;
semantic_key_2 : abap.char(10);
description : abap.char(50);
local_last_changed_at : abp_locinst_lastchange_tstmpl;
}
Grandchild nodes
Tables that are used for nodes on the third level (grandchild) also need only one administrative field local_last_changed_at.
Starting with the third and all higher levels we need a second UUID based non-key field that is used to store the UUID value of the key field of the root entity.
Storing the UUID based key field value of the root node is required to enable locking of grand-grand-child entities out of the box.
So we can use the following table for grandchild like items.
@EndUserText.label : 'RAP Generator Business Object Header'
@AbapCatalog.enhancement.category : #NOT_EXTENSIBLE
@AbapCatalog.tableCategory : #TRANSPARENT
@AbapCatalog.deliveryClass : #A
@AbapCatalog.dataMaintenance : #RESTRICTED
define table zuuid_level_3 {
key client : abap.clnt not null;
key uuid_level_3 : sysuuid_x16 not null;
parent_uuid : sysuuid_x16;
root_uuid : sysuuid_x16;
semantic_key_3 : abap.char(10);
description : abap.char(50);
local_last_changed_at : abp_locinst_lastchange_tstmpl;
}
4th level and deeper
A table that is used on the fourth level /grand-grand-child) looks the same as the ones used for grand-child-elements.
@EndUserText.label : 'RAP Generator Business Object Header'
@AbapCatalog.enhancement.category : #NOT_EXTENSIBLE
@AbapCatalog.tableCategory : #TRANSPARENT
@AbapCatalog.deliveryClass : #A
@AbapCatalog.dataMaintenance : #RESTRICTED
define table zuuid_level_4 {
key client : abap.clnt not null;
key uuid_level_4 : sysuuid_x16 not null;
parent_uuid : sysuuid_x16;
root_uuid : sysuuid_x16;
semantic_key_4 : abap.char(10);
description : abap.char(50);
local_last_changed_at : abp_locinst_lastchange_tstmpl;
}
Resulting RAP BO
Based on this four tables I have generated a managed RAP BO that I have published on GitHub (see link above).
The structure you can see here:
I used the latest version of my openSource RAP Generator and was able to quickly generate a RAP BO based on the four above mentioned tables.
The JSON file can be found here.
Fortunately the RAP BO can be tested with the Fiori Elements preview offered by ADT. And as you can see I am able to store values on the fourth level without having implemented a single line of code myself. Everything is handled by the RAP framework.
Thank you very much Andre Fischer ! It helped me a lot! Sadly, I had to create every artefact, but next time I'll give the RAP Generator a try 😉
Kind Regards,
Jorge Carvalho
Thanks Andre Fischer for sharing this blog. This is very helpful.
Regards,
Aman Garg
Andre Fischer Thanks for your blog.
In my approch I used root and parent also as key. It only workend in UI until level 3. Level 4 always failed. In the data preview it worked until level 4. Is there a limitation in the UI by the number of key fields?
Dear Andre ,
Thanks for this .
I was able to generate the artifacts using the Fiori app (RAP Generator).
Later I wrote the business logic , generating the semantic keys for Level 1 and L level 2 (with reference from Travel and booking example).
But not able to do the same for level 3 and Level 4, as I did not find any code in the reference example (of generating booking supplement ID), there was one method early numbering , but I was completely lost in that.
Would you please point me or help me for the semantic key generation for at least level 3.
Level 4 should be straight forward if level 3 works out.
Thanks and Regards ,
Shavneet Singh