CDS, RAP, Fiori & migration
These are the Development product's build and migration roles. The build roles (CDS, RAP, Fiori) create and activate objects, working bottom-up through the dependency chain. The migration roles split by intent: Migration interactively remediates one object, while Migration Map and Clean-core check are read-only analysis that change nothing.
They live under the Development product in the Chat composer; Migration Map and Clean-core check also appear under Consulting. For the permission model behind every role, see How roles work.
At a glance#
| Role | Read/Write | Use it to… |
|---|---|---|
| CDS | Write | Build real CDS VDM data models bottom-up. |
| RAP | Write | Build a complete RAP business object. |
| Fiori | Write | Make an OData service Fiori-Elements-ready. |
| Migration | Write | Interactively prep one object for ECC→S/4 / Clean-Core. |
| Migration Map | Read-only | Analyze a custom-code estate for S/4 planning. |
| Clean-core check | Read-only | Audit objects for clean-core compliance. |
CDS#
Read/Write: Write.
CDS designs and builds real CDS VDM data models — DDLS, DDLX, and DCLS objects plus their tables. It follows the Virtual Data Model layering: base ZI_ interface views and ZR_ views, text views, ZC_ consumption projections, and access controls. It builds bottom-up and activates as it goes.
It never runs the ABAP cleaner on CDS — CDS DDL is normalized by the role itself, not by the cleaner.
When to use it: to stand up a properly layered CDS data model rather than a one-off view.
RAP#
Read/Write: Write.
RAP builds a complete RAP business object end to end: the table, DDLS (data definition), DDLX (metadata extension), BDEF (behavior definition), CLAS (behavior implementation), SRVD (service definition), and SRVB (service binding). Its methodology is data model → behavior (managed) → projection + service → verify via EML.
Publishing the OData service is a human step — the role builds and binds, but you publish.
When to use it: to build a transactional RAP object (managed scenario) from a data model up to a verified service.
Fiori#
Read/Write: Write.
Fiori makes an existing OData service Fiori-Elements-ready. It authors the @UI annotation layer — metadata extensions or inline @UI — plus value help, text, and search annotations, and exposes the result via SRVD + SRVB.
The UI5 app-shell deploy and the launchpad setup are explicit manual handoffs — the role prepares the service and annotations; you deploy the app and wire up the launchpad.
When to use it: to turn a working OData service into one a Fiori Elements app can render, without hand-writing annotations.
Migration#
Read/Write: Write.
Migration is interactive ECC→S/4HANA / Clean-Core prep of one object (or a small package). Its methodology is assess (an S/4-readiness ATC variant or a source scan) → remediate finding by finding (a minimal fix, in the clean-core direction, calling out traps) → verify → report. A human approves each change.
When to use it: to actually remediate a specific object for S/4, one finding at a time, with a human in the loop on every edit.
Migration Map#
Read/Write: Read-only.
Migration Map is custom-code (Z/Y) estate analysis for ECC→S/4 planning. It takes a production USAGE export and reads the DEV code structure, computes the reachability closure from the used entry points, and classifies every object into USED / REACHABLE / REVIEW / CANDIDATE, each with supporting evidence. It delivers a CSV / report.
It never touches production, and it never declares code "dead" or "safe to delete" — the REVIEW and CANDIDATE buckets are decision inputs for a human, not verdicts.
When to use it: to size and prioritize a custom-code estate before an S/4 migration, with evidence for each classification.
Migration Map is available in both the Development and Consulting products, so it can feed either a build effort or a consulting deliverable.
Clean-core check#
Read/Write: Read-only.
Clean-core check audits object(s) for S/4HANA clean-core compliance. It looks for direct standard-table reads, calls to unreleased APIs, modifications, deprecated syntax, and interface bypasses, and buckets each object as COMPLIANT / EXTENSIBLE-VIA-RELEASED / NEEDS-REWORK / BLOCKER. It changes nothing.
When to use it: to check whether specific objects are clean-core ready, and to see exactly what stands in the way.
Clean-core check is available in both the Development and Consulting products.
Related pages#
- How roles work — the permission model behind every role.
- Developer roles — the rest of the Development product.
- Consulting roles — where Migration Map and Clean-core check also appear.
- ABAP cleaner — what CDS deliberately skips.
- Chat — pick a role and send a task.
- Autonomous mode — the human-gated apply pipeline for writes.