How to design managed RAP business objects with 3 or more levels of nodes

[Andre_Fischer]

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 clou...

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.