Generate a Fiori app in an afternoon

“Add a maintenance screen for this table” used to mean days of Dynpro, a function group, and a transaction. On the Clean Core stack it’s a CDS view, a RAP behavior definition, a service definition and binding — and Fiori Elements renders the UI for you. With a generator doing the boilerplate, it’s an afternoon.

The four moving parts

1. CDS interface + projection view — the data model and the consumption layer the app binds to.
2. Behavior definition + implementation — managed RAP gives you create/update/ delete with draft handling almost for free.
3. Service definition + binding — exposes the projection as OData V4.
4. Fiori Elements app — a list report / object page generated from annotations; no hand-written UI5.

Where the generator helps

The tedious, error-prone part is the boilerplate — and it’s mechanical. Point a generator at the table and it emits the CDS, the behavior skeleton, and the service so you can focus on the business rules. That’s what ZCL_AU_FIORI_GEN in our open-source utilities does, including a bridge from an existing ALV field catalog.

Polish that matters

A generated app is the start, not the end. Add value help, draft enablement, authorization checks, and field-level validations in the behavior implementation. These are the things that make it feel like a real Fiori app rather than a table dump — and they’re exactly the patterns the Academy drills.

The payoff

Every screen you move off SM30 / Dynpro is one fewer ATC finding and one step closer to a cloud-ready core — delivered in a modern, mobile-friendly UI your key users will actually prefer.

Got a backlog of old maintenance screens and reports? Book an assessment and we’ll convert the highest-value ones first.