This is a test message to test the length of the message box.
Created by Software-Heroes

RAP - Draft (Part 2)


The second part on the subject of draft handling in RAP objects is about better displaying the draft status at the individual positions in the list.

In the last article we added draft handling to our app. However, you should also have noticed that the display of the current draft in the list was not very good, since the status of the sentence was not recognizable. In this article we will show you how the display can be made even better and more detailed.



After we activated and made the draft handling available, we could admire the first version of the list report:


Unfortunately, the draft status is still not displayed in this version and we can only find positions that have been changed but not yet saved via the filter. We want to change this with this article and take over the necessary components. In the last article we implemented the minimum for draft handling.



First of all, the partner table has to be adjusted again. At the end we add further information about the person who made the change, but also about the creator of the data record. The ZBS_DMO_PARTNER table now looks like this:

define table zbs_dmo_partner {
  key client       : abap.clnt not null;
  key partner      : abap.char(10) not null;
  name             : abap.char(60);
  street           : abap.char(80);
  city             : abap.char(60);
  country          : land1;
  payment_currency : abap.cuky;
  last_changed_at  : abp_locinst_lastchange_tstmpl;
  last_changed_by  : abp_locinst_lastchange_user;
  created_at       : abp_creation_tstmpl;
  created_by       : abp_creation_user;


For a clean management of the status, the implementation of all 5 fields is recommended. In the next step, the draft table must also be adjusted to include the new information. You should make sure that the field names correspond to the names in the interface view and thus differ from the table fields:

define table zbs_dmo_dpartner {
  key mandt         : mandt not null;
  key partnernumber : abap.char(10) not null;
  key draftuuid     : sdraft_uuid not null;
  partnername       : abap.char(60);
  street            : abap.char(80);
  city              : abap.char(60);
  country           : land1;
  paymentcurrency   : abap.cuky;
  lastchangedat     : abp_locinst_lastchange_tstmpl;
  lastchangedby     : abp_locinst_lastchange_user;
  createdat         : abp_creation_tstmpl;
  createdby         : abp_creation_user;
  "%admin"          : include sych_bdl_draft_admin_inc;


Core Data Service

As a next step, the call stack of the Core Data Services has to be expanded, for this the fields of the table are taken over. There is a corresponding annotation for each field, which we now assign so that the meta information can be properly derived in the app.

@Semantics.systemDateTime.lastChangedAt: true
last_changed_at  as LastChangedAt,
@Semantics.user.lastChangedBy: true
last_changed_by  as LastChangedBy,
@Semantics.systemDateTime.createdAt: true
created_at       as CreatedAt,
@Semantics.user.createdBy: true
created_by       as CreatedBy


Furthermore, the following objects still have to be adjusted, which we won't go into in detail here because they are small adjustments. You can find more information in the commit in the git repository:

  • Projection View - Adoption of the new fields in the projection layer and thus make them available in the app.
  • Behavior Definition - Extension of the mapping in the behavior definition to include the new fields.


Metadata Extension

After the adjustments, however, the information for the draft is still not visible in the positions. To do this, the metadata, specifically the header information, must be expanded. To do this, we add the following UI annotation in the header:

@UI.headerInfo.title: { type: #STANDARD, value: 'PartnerName' }


What exactly happened in the app? First of all, additional information was displayed in the header area on the detail screen when an entry was selected:


Furthermore, the draft status is now displayed in the list of entries. If you click on the entry, you will receive information about the last change. If you are the changer, then only "Draft" is displayed, if someone else is the changer, then information about the user is also displayed:



In addition to a better presentation of the draft information, your app now also has an automatic management of the technical information. Not even many changes are necessary to implement a certain standard in the apps.

Included topics:
RAPBTPDraftDraft Handling
Comments (0)

And further ...

Are you satisfied with the content of the article? We post new content in the ABAP area every Friday and irregularly in all other areas. Take a look at our tools and apps, we provide them free of charge.

RAP - Deep Action in OData v4

Category - ABAP

In this article we will look at actions with deep structures, how we can create them and pass data to an API endpoint.


BTP - Connect On-Premise (Consumption Model v2)

Category - ABAP

In this article we want to provide another update on the connection of on-premise systems and how this is done with a communication arrangement.


RAP - Show app count (Tile)

Category - ABAP

This example is about displaying a counter on the tile of a Fiori Elements application and how such a thing can be implemented.


RAP - Generator (Fiori)

Category - ABAP

In this article we will look at the more complex RAP generator as a Fiori Elements application and what advantages you have with it.


RAP - Generator (ADT)

Category - ABAP

Today, let's take a look at the RAP Generator, which is already integrated into ABAP Development Tools, and how you can use it to easily build new RAP apps.