RAP has a lot of moving parts
CDS data model, behavior definition, behavior implementation, service definition, service binding, Fiori UI — a first RAP object touches six or seven artifacts, and beginners drown in the wiring before they learn the concepts.
This checklist cuts through it: the minimum viable path from "never touched RAP" to a working Fiori app with draft handling. Follow it in order.
The checklist
- Get ADT running. ABAP Development Tools in Eclipse (or the ABAP extensions for VS Code) connected to a system — a BTP ABAP trial or a developer system. RAP is not a SE80 activity.
- Learn CDS basics first. Entities, associations, annotations. RAP's data model is CDS — if CDS is shaky, everything built on it wobbles.
- Build the data model. One root entity, one child entity. Keep it small — a sales order header and items, a classic. Get the associations right; behavior inherits the structure.
- Generate the behavior skeleton. Right-click the CDS entity → generate behavior definition. Start from the generated draft-enabled skeleton and trim it, rather than writing a BDEF from memory.
- Go managed with draft. Your first object should be
managed with draft— maximum framework support, minimum hand-written code. Unmanaged is for later. - Add one validation and one determination. A check on save (totals positive) and a derivation on modify (status from items). This teaches the two logic homes and the failed/reported pattern in one sitting.
- Create the projection and service. Behavior projection (
ZC_), service definition exposing it, service binding as OData V4 UI. Publish the binding. - Preview the Fiori app. Open the preview — list report and object page appear with draft handling working. Create, edit, activate, discard. Watch it work before writing more code.
- Add one custom action. An "approve" action: declare in BDEF, implement in the behavior pool, expose with
use actionin the projection. This is the full round trip. - Run ATC. Clean ABAP and RAP-specific checks on everything you wrote. Fix findings now, while the code is small.
The order matters: data model → behavior → service → UI → logic → polish. Every step is verifiable before the next begins. If step 8's preview works, your foundation is solid.
Traps for first-timers
- Starting unmanaged. The most common self-inflicted wound. Managed first, always.
- Skipping the projection. Exposing the base interface directly, or forgetting
use action— then wondering why the UI ignores your work. - Forgetting to publish the binding. Stale metadata, phantom bugs, an hour lost. Publish after every service change.
- Testing only with a developer user. Authorization and DCL issues hide until a restricted user tries. (There's a whole post on this.)
- Too big a first object. Three entities deep with actions on day one. Walk with header-items first.
What "done" looks like
A working Fiori app: list report, object page, draft handling, one validation, one determination, one custom action — all ATC-clean. That's a complete RAP education in miniature, and every later object is a variation on it.
From there, the natural next steps: EML for programmatic access, feature control for conditional UI, authorization for real users. Each has its own post on this blog.
Where are you on the checklist — and where did you get stuck? Tell me in the comments.