Fiori Elements Table Maintenance (SM30) using RAP Generators and Wizards
Co-author: Gregory Mayorga
Custom Table Maintenance
All SAP Developers have had to create custom tables and Maintenance Views to maintain them using SM30. This is a small, easy step; it takes a few minutes to improve processes and we all take it for granted.
Single tables are very easy to set up.
For multiple tables with a parent/child relationship, this requires an additional step called a View Cluster.
The Data Dictionary would ask us for a Function Group and screen details to generate the required objects for our Maintenance View.
View Clusters would require an additional layer of customizing.
This was in fact a Generator that no one paid much attention to, including Developers.
For customers choosing a pure Fiori frontend (no GUI), this process is now much more complicated.
A lot of technical objects are required to create an SAP Fiori App simply to maintain our table(s) the same way. This can sometimes be achieved from scratch using the BAS and Eclipse ADT on BTP, but the end result may vary by Developer. There are recent evolutions that make this process a lot faster, with uniform results, which we will cover in this blog, in a way we feel is the most efficient depending on different scenarios.
What you’ll need to start building tables with RAP generators
S/4 Hana On-premise(2020 for manual RAP Development, 2021 if using the open source wizard) [or]
S/4 Hana Private Cloud Edition (PCE) [or]
BTP ABAP environment
Knowledge of the SAP RAP model
Latest version of Eclipse
Latest version of ADT (ABAP Development Tools) for Eclipse
Access to git and knowledge of how to pull from it.
The purpose of this blog is not to recommend solutions for complex Fiori applications with specific business processes and/or exceptions in mind. It is strictly to provide an efficient replacement of the Maintenance Views we all know and love, while maintaining the same look and feel for all custom tables.
What is SAP RAP?
RESTful Application Programming model is a new ABAP programming model for building Fiori apps. RAP is comprised of:
CDS data model
Annotations (meat of the process) to control:
Services to expose the Model to the Consumption layer
Consumption layer (Fiori app in this case)
RAP Wizards and Generators
Some new generators/wizards have recently been made available to the ADT. Starting from our custom DB tables, these generators will create all the required objects (including CDS objects, annotations, and services) required for a fully functional Fiori Elements app.
There is also a new open source project, explained later, delivered unofficially by SAP, to cover more complex data models (parent-child). This is both interesting and disturbing, sowing doubt as to where SAP is going with this solution. It will certainly be worth keeping an eye on this topic in the future.
We need to choose the right generator based on the complexity of our customizing data model.
ADT-based generator for simple table maintenance:
A generator called Business Configuration Maintenance Objecthas been added to handle simple data models (single table, or table + text table for language-dependent customizing). These scenarios represent most of our customizing requirements and this generator should fulfill these needs.
On-premise / PCE / ABAP on BTP
View Cluster: open source RAP generator
Public Cloud (all data models):
When done properly on a Public Cloud environment, our custom table maintenance should integrate perfectly with the standard apps to “Manage/Configure Your Solution”, including the Change History of the table.
Public Cloud customizing
Open source generator:
The open source generator is available on GitHub here.
We need to select the right branch for our ABAP environment and pull it into the system.
This open source app is actually a RAP app, designed to generate new RAP apps — like robots building robots.
The open source app uses the new Fiori app called Application Jobs to generate our custom app in the background.
It’s available for S/4 2021 and 2022, as well as the ABAP environment on BTP.
When running the generator app, we build up our customizing data model from our custom tables, identifying our Root and adding Child tables.
We also need to configure our project to have the generator create the right components for us. In this case, a Managed solution with OData V4 Service Binding.
Our scenario has a default (root) table, with one Child table.
Like the ADT Generator, the open source app creates all the RAP components: CDS Entities (including Annotations), Behaviors and Services, ready to be consumed by a Fiori app.
Also like the ADT Generator, there are always a few things to tweak to make sure our app behaves professionally (labels, value help, annotations in metadata extensions, etc.).
As for naming standards, the generator also manages prefixes and suffixes for our generated objects. Anyone rigidly attached to typical naming standards will simply have to let go.
No matter the generator used, previewing the proper EntitySet from the ServiceBinding will show us what our Fiori app will look like. In either case, we get a draft-enabled customizing app with Transporting functionality.
Of course, this is just a preview app based on our OData service. We must now use the BAS service on the BTP to create a Fiori app, consuming our OData Service, and deploy it to the proper environment (on-premise, S/4 Hana Private Cloud Edition (PCE), BTP ABAP environment).
These tools are certainly a game-changer and will greatly accelerate the development of custom table maintenance while providing the user with consistent, standardized Fiori apps to blend in with the rest of their solution.
The perfectionist in me feels left behind and a little overwhelmed. Not everyone has had the chance to properly understand and assimilate all the pieces of a typical RAP application, and things are constantly evolving. I personally had only just started to scratch at the massive world of annotations and their full power, not to mention mastering all the other pieces of this complex puzzle.
The realist in me was patiently waiting for exactly this, and is very happy to see it, knowing it will continue evolving. Besides, who truly understood all the numerous pieces of the "maintenance dialog" generated by the Data Dictionary anyway?
A simple example of a maintenance dialog for a single custom table in an on-premise system contains:
two (2) Function Modules
~ 275 subroutines
~ 180 include programs.
I’m excited for these tools to exist and to see them evolve. These are only some of the tools we are using regularly to provide our customers with efficient professional results in the Createch SAP Dev team.