Technology Blog Posts by SAP
cancel
Showing results for 
Search instead for 
Did you mean: 

Introduction

When developing a transactional app, you can use the singleton pattern for a draft enabled RAP BO to enable editing / inline create on the actual root entity.

In this blog, you will learn how the singleton pattern impacts performance and other advantages and disadvantages of this pattern in the context of Fiori elements.

This blog is relevant for

Further reading:

Example BO

Our data model consists of a table T1 and a corresponding text table T1_TXT.

@EndUserText.label : 'Tab1'
@AbapCatalog.enhancement.category : #NOT_EXTENSIBLE
@AbapCatalog.tableCategory : #TRANSPARENT
@AbapCatalog.deliveryClass : #C
@AbapCatalog.dataMaintenance : #ALLOWED
define table T1 {
  key client            : abap.clnt not null;
  key k1                : zpw_d1 not null;
  f1                    : abap.char(20);
  f2                    : abap.char(20);
  f3                    : abap.char(20);
  f4                    : abap.char(20);
  f5                    : abap.char(20);
  f6                    : abap.char(20);
  f7                    : abap.char(20);
  f8                    : abap.char(20);
  last_changed_at       : abp_lastchange_tstmpl;
  local_last_changed_at : abp_locinst_lastchange_tstmpl;
}
@EndUserText.label : 'Tab1 Text'
@AbapCatalog.enhancement.category : #NOT_EXTENSIBLE
@AbapCatalog.tableCategory : #TRANSPARENT
@AbapCatalog.deliveryClass : #C
@AbapCatalog.dataMaintenance : #ALLOWED
define table T1_TXT {
  key client            : abap.clnt not null;
  key langu             : abap.lang not null;
  @AbapCatalog.foreignKey.keyType : #TEXT_KEY
  @AbapCatalog.foreignKey.screenCheck : false
  key k1                : zpw_d1 not null
    with foreign key T1
      where client = T1_TXT.client
        and k1 = T1_TXT.k1;
  description           : abap.char(30);
  local_last_changed_at : abp_locinst_lastchange_tstmpl;
}

Therefore, the draft-enabled RAP BO with singleton pattern consists of the singleton root entity type, T1 entity type, and T1_TXT entity type, each with a draft table.

Singleton draft

When the Edit action is performed on a root entity, a corresponding draft entity including all subentities is created. In the singleton pattern, this basically means that a draft entity is created for all entities of the RAP BO.
Typically, the Edit action is performed when the user clicks the Edit button in the Fiori elements app. You can also use the following ABAP EML statement:

MODIFY ENTITY zi_t1_s
  EXECUTE edit
  FROM VALUE #( ( %cid = |CID1|  singletonid = 1 ) ).
COMMIT ENTITIES.

For our example BO, the Edit action therefore consists of three SQL statements in the form of INSERT INTO <draft table> SELECT FROM <entity type cds view>. No data is passed to the ABAP application server, only one statement per entity type, regardless of the number of entities.

The following measurement was performed in an ABAP Platform performance test system with respect to the above SQL statements as total:

#Rows T1#Rows T1_TXTHANA CPU time [ms]HANA max memory consumption [mb]
104071
100400753
100040001356
100004000081045
1000004000007600437

This table shows the performance impact of the singleton pattern compared to a RAP BO without a singleton pattern. It is linear, so you can extrapolate for a higher number of lines.

If you use ABAP EML to modify entities, you do not need to create a draft entity, so this penalty does not necessarily apply to ABAP EML statements.

The runtime behavior when changing a draft entity or in the action prepare is not affected by the singleton pattern.

During the activation action, the draft entities are discarded using a DELETE statement:

#Rows T1#Rows T1_TXTHANA CPU time [ms]HANA max memory consumption [mb]
104071
10040072
10004000274
100004000015510
10000040000043043

So you can add this to the performance impact.

Logically, these numbers depend on the table and CDS view design as well as the system. But the basic statement remains.

If the user changes more than about 10% of the entities in the interaction phase, the singleton pattern is more performant because draft entities do not always have to be created.

Singleton in Fiori Elements

Using a singleton RAP BO pattern in Fiori elements has the following characteristics:

  • Multi-line edit/inline creation for the actual root entity
  • The app can temporarily store global information in the singleton draft entity
  • All entities of the RAP BO are locked for a user
  • You cannot use selection fields as the filter bar is only available in the list report. Alternatively, you can add search capabilities to the entity. A search field is then available 

See link on how to create a Fiori Elements app for a RAP BO with singleton pattern.

Custom Business Configurations

When you create business configurations app using the ABAP RAP programming model, you use the Custom Business Configurations app and the business configuration maintenance object ADT wizard.

The RAP BO that this wizard generates always uses the singleton pattern for the following reasons:

  • For configuration tables, you want to have a spreadsheet like user experience with inline create and copy&paste from other spreadsheet applications
  • The customizing transport request can be selected once for all entities and stored in the singleton draft entity
    • In state save_modified, the RAP framework cannot provide the before image of a deleted entity. If the transport request is part of the deleted entity, it is not possible to read this information from the entity itself. You must store the transport request in the premodify operation in a database table and use/delete this information in state save_modified..
  • Locking the entire configuration for only one user is beneficial. You do not want multiple users to work on the same configuration table in parallel. However, with little effort, you can activate collaborative draft to enable multiple users to work on the same configuration table.
  • The performance penalty for the singleton pattern is acceptable because
    • Configuration tables rarely have more than 1000 rows, let alone more than 10000 rows
    • Most of the configuration takes place in the intended system/client, not in the production client
    • The frequency of configuration changes is low
    • There is no performance impact when using ABAP EML or the Upload Business Configurations app

The Custom Business Configurations app also supports RAP BO without singleton pattern:

  1. Create the RAP BO / Service binding without using the business configuration maintenance object ADT wizard
  2. Add the relevant transport related functionality to the RAP BO
  3. Create the business configuration maintenance object (SMBC) manually. Leave the option "Skip root entity list report" unchecked

Conclusion

Do not use the singleton pattern if the RAP BO handles more than 50000 entities and the app is used frequently.

Labels in this area