- SAP Managed Tags
Update – 21 October 2025
The ABAP Generator component of the Fiori Programming Model Analyzer is now available on GitHub!
The project now consists of two complementary repositories:
ABAP Generator – the backend engine running directly on your S/4HANA system.
It analyzes themanifest.jsonof standard Fiori apps, cross-references them with CDS views and Service Definitions, and automatically classifies each app by programming model (RAP, BOPF, or Gateway Classic).
It produces JSON and CSV outputs ready to be consumed by the viewer.Viewer Application – the frontend visualization tool that lets you explore and compare the generated data interactively, including the “Compare” view for release-to-release analysis.
Introduction: the Idea
Last week at SAP Inside Track Rome 2025 I had the chance to present a session about a new tool I’ve been working on recently.
The goal of this tool is to support ABAP developers in identifying the programming model behind a given Fiori app, showing useful information such as:
- What programming model does this app use – BOPF or RAP?
- What’s the name of the Business Object ?
- Has the Fiori Elements app been extended with the Flexible Programming Model?
- For OData V2 apps – sometimes the OData name doesn’t match the SEGW project name: which one is the correct SEGW project?
You can explore the data directly here:
https://alespad.github.io/s4-fiori-model-analyzer/
The app can also be run locally, and all data files used by the Fiori viewer (in both JSON and CSV formats) are available in the GitHub project under:
https://github.com/alespad/s4-fiori-model-analyzer/tree/main/docs/data
Behind the story
How did this idea come up?
At Syscons, we regularly run internal and customer webinars we call “Fiori Enablement”, designed to help experienced ABAP developers modernize their skills and get ready to work on the latest S/4HANA releases (and even BTP-based developments).
Some time ago, @SergioFerrariIt2 suggested a session called “Anatomy of a Fiori App”. It wasn’t easy to prepare, since there’s no official end-to-end documentation on how to “dissect” a Fiori app. The goal was to show how an ABAP developer can look inside a standard app and understand what’s really happening behind an action button, a navigation, or any specific UI behavior.
To prepare the session, I chose the Fiori App F1048A – Process Purchase Requisition, and started documenting each step:
- Identify the main object: start from the OData service in the Fiori Library, or use Dev Tools (F12) to see which entity is called when pressing “Go”.
- Notice that there are three actions in the table – but only one action exists in the RAP object. Comparing ADT Preview with the actual Fiori App, there are no @UI actions, and even an extra column appears in the app. That means the app was extended with the Flexible Programming Model. We can download the app and inspect it locally in VS Code.
- This app, based on a RAP object, also navigates to other apps that use BOPF via specific actions. Which BOPF objects are they? Here, F12 helps only partially — we need to go one level deeper to find the true BO names.
Following this process made me realize how useful it would be to have a tool that automatically shows this information, starting from the app list in the Fiori Library.
ABAP Generator
If you’re only interested in browsing the analyzed data in the viewer or downloading the JSON/CSV files, then the Viewer Repository is all you need.
However, if you want to generate the results directly in your own S/4HANA system, improve the detection logic, or — in the near future — produce your own data for custom Fiori apps, then you’ll definitely want to explore the ABAP Repository.
For a deeper technical overview, you can refer directly to the README in that repository.
From a technical perspective, for each app the generator retrieves the corresponding BSP application and parses the manifest.json to identify the OData service and main entity.
The logic then checks the presence of Service Bindings (for RAP/V4) or SEGW projects (for BOPF/V2), inspects the DDL source of CDS views to trace consumption and interface layers, and classifies the app according to the detected programming model.
All results are consolidated into JSON and CSV output files that can be visualized directly through the Fiori Model Analyzer viewer.
What's next?
- Improve N/A classification logic
- Some SEGW Projects are not determined
- Validate accuracy across different S/4HANA releases
- Analyzing Custom Fiori Apps: Support detection of custom Fiori Elements apps built with SAP Fiori Tools
- Continue improving by learning and adopting modern ABAP and open-source tools — currently using abaplint and exploring best practices for clean and collaborative development.
I’ll keep posting updates about the progress — and if you have feedback, suggestions, or ideas, they’re very welcome!
Bluesky
