Skip to Content
Technical Articles
Author's profile photo Andre Fischer

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.

SAP-samples/abap-platform-code-samples-cloud: Collection of sample code to demonstrate ABAP for cloud development. (github.com)

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.

 

 

 

 

 

 

 

 

Assigned Tags

      3 Comments
      You must be Logged on to comment or reply to a post.
      Author's profile photo Jorge Carvalho
      Jorge Carvalho

      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

      Author's profile photo Aman Garg
      Aman Garg

      Thanks Andre Fischer for sharing this blog. This is very helpful.

      Regards,

      Aman Garg

      Author's profile photo Florian Kube
      Florian Kube

      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?