Cheatsheet to develop maintenance dialogs using Fiori Elements

[christianjsosa]

SM30 maintenance dialogs have been around for almost as long as the SAP GUI exists and are still a very common way of maintaining custom tables in the Z* and Y* namespaces even in recent releases of SAP S/4HANA. This solution, although effective, is not very future-proof for two reasons:

1. SAP GUI solutions are slowly becoming rather legacy solutions


2. In the spirit of #KeepTheCoreClean, such ad-hoc custom dialogs should be avoided altogether

Still in some cases it might be unavoidable to have a custom table and its maintenance must be addressed.

Requirement

A maintenance dialog in Fiori is needed for a custom table without the need to access transaction SM30. The maintenance dialog must feature inline edition and draft handling capabilities.

Solution

Fiori offers many strategies to maintain customer configurations with varying degrees of coding needed. The solution of choice depends on the data structure of tables to maintain and also on the installed SAP product.

Decision matrix to choose a technical solution for maintenance dialogs under S/4HANA

Custom Business Configurations App: There is a very informative step-to-step guide provided by SAP [1]. It can be followed completely using only the SAP BTP trial environment.

RAP based Fiori Elements List Report [2]: There's even an open source table maintenance generator, which you can read more about here. This takes care of much of the technical objects that need to be created for a RAP based approach.

BOPF based Fiori Elements List Report: There's a specific training for this S4D435[3]

These requirements apply for both BOPF- and RAP-based maintenance dialogs

Data structure featuring a Root and a Child entity. The Root entity might be an actual entity or a singleton.

A Fiori Elements List Report with its corresponding Object Page.

Both the Root entity and the Child entity must be draft enabled. However, the draftEnabled annotation must only be set on the Root entity. This is validated by the automated checks at design-time in Eclipse with ADT/HANA Studio.

The underlying tables for both the Root and Child entities need to have some specific fields: a node_id of type snwd_node_key and the technical maintenance fields 'include /bobf/s_lib_admin_data'

The Object Page in Fiori must be configured with as "createMode": "inline" in the manifest.json[4].

Caveats

Fiori Elements Transactional List Reports only support inline maintenance within the Object Page. It is not possible to have only one entity (ie one table) and edit it inline directly in the List Report.

In case the data structure to be maintained is organized in two entities anyways, this is not an issue. Otherwise, if only one table is needed, SAP recommends using implementing a singleton as a workaround. The singleton is a 'dummy' root entity that is associated to the actual semantic child entity, which we want to maintain. At the moment of this writing (July 2023), there's no alternative to this using RAP.

A Fiori based maintenace dialog cannot be created for any existing table, in the same way a SM30 maitenance dialog can. To begin with, with Fiori at least two entities are needed (Root and Child), while SM30 dialogs can be created for single tables. Furthermore, both the Root and Child entities require specific fields.

In case these are not taken care of properly, the Fiori List Report[5] will simply fail to work as expected without an apparent cause[6]. Many design-time problems will not be apparent until loading the List Report. Even then, the error messages can be of little use in finding the cause of the problem and debugging quickly turns very time consuming. This can only be avoided by carefully following the steps and requirements described in the official documentation and checking the requirements listed above.

Final thoughts

The administrative structure that's needed for this approach increases the technical overhead without adding semantic value. The maintenance fields can only be used by the framework and for debugging, but they are not human readable. On top of that, the actual semantic keys need to be manually specified using the annotation 'ObjectModel.semanticKey' on ABAP CDS level [7].

Per default, empty entries can be created even though no semantic keys have been set up. Ideally, the key fields should be mandatory by default, but as explained earlier, only the GUIDs can be configured as key fields. All other validations need to be configured or developed explicitly.

The solution for SAP BTP, ABAP Environment is much more elegant and does not require any coding. The overhead of providing an App to maintain custom entities is then taken care of by the SAP standard 'Custom Business Configurations app'. This lowers the maintenance effort of our solution and is another benefit of considering ABAP in the cloud.