CDS, RAP, Fiori e migrazione
Questi sono i ruoli di sviluppo e migrazione del prodotto Development. I ruoli di sviluppo (CDS, RAP, Fiori) creano e attivano oggetti, lavorando bottom-up lungo la catena delle dipendenze. I ruoli di migrazione si dividono per intento: Migration rimedia interattivamente un singolo oggetto, mentre Migration Map e Clean-core check sono analisi in sola lettura che non cambiano nulla.
Vivono sotto il prodotto Development nel compositore della Chat; Migration Map e Clean-core check compaiono anche sotto Consulting. Per il modello dei permessi dietro ogni ruolo, vedi Come funzionano i ruoli.
In sintesi#
| Ruolo | Lettura/Scrittura | Usalo per… |
|---|---|---|
| CDS | Scrittura | Costruire veri modelli dati CDS VDM bottom-up. |
| RAP | Scrittura | Costruire un business object RAP completo. |
| Fiori | Scrittura | Rendere un servizio OData pronto per Fiori Elements. |
| Migration | Scrittura | Preparare interattivamente un singolo oggetto per ECC→S/4 / Clean-Core. |
| Migration Map | Sola lettura | Analizzare un parco di codice custom per la pianificazione S/4. |
| Clean-core check | Sola lettura | Verificare gli oggetti per la conformità clean-core. |
CDS#
Lettura/Scrittura: Scrittura.
CDS progetta e costruisce veri modelli dati CDS VDM — oggetti DDLS, DDLX e DCLS più le loro tabelle. Segue la stratificazione del Virtual Data Model: viste interface base ZI_ e viste ZR_, viste testo, proiezioni di consumo ZC_ e access control. Costruisce bottom-up e attiva man mano.
Non esegue mai il cleaner ABAP sul CDS — il DDL CDS è normalizzato dal ruolo stesso, non dal cleaner.
Quando usarlo: per allestire un modello dati CDS correttamente stratificato invece di una singola vista.
RAP#
Lettura/Scrittura: Scrittura.
RAP costruisce un business object RAP completo dall'inizio alla fine: la tabella, il DDLS (data definition), il DDLX (metadata extension), il BDEF (behavior definition), la CLAS (behavior implementation), il SRVD (service definition) e il SRVB (service binding). La sua metodologia è modello dati → comportamento (managed) → proiezione + servizio → verifica via EML.
Pubblicare il servizio OData è un passo umano — il ruolo costruisce e collega, ma sei tu a pubblicare.
Quando usarlo: per costruire un oggetto RAP transazionale (scenario managed) da un modello dati fino a un servizio verificato.
Fiori#
Lettura/Scrittura: Scrittura.
Fiori rende un servizio OData esistente pronto per Fiori Elements. Redige il livello di annotazioni @UI — metadata extension o @UI inline — più le annotazioni di value help, testo e ricerca, ed espone il risultato tramite SRVD + SRVB.
Il deploy dell'app-shell UI5 e la configurazione del launchpad sono espliciti passaggi di consegna manuali — il ruolo prepara il servizio e le annotazioni; sei tu a distribuire l'app e a collegare il launchpad.
Quando usarlo: per trasformare un servizio OData funzionante in uno che un'app Fiori Elements può renderizzare, senza scrivere a mano le annotazioni.
Migration#
Lettura/Scrittura: Scrittura.
Migration è la preparazione interattiva ECC→S/4HANA / Clean-Core di un singolo oggetto (o un piccolo package). La sua metodologia è valutare (una variante ATC di prontezza per S/4 o una scansione del sorgente) → rimediare risultato per risultato (una correzione minima, in direzione clean-core, segnalando le trappole) → verificare → riportare. Un umano approva ogni modifica.
Quando usarlo: per rimediare effettivamente un oggetto specifico per S/4, un risultato alla volta, con un umano nel ciclo su ogni modifica.
Migration Map#
Lettura/Scrittura: Sola lettura.
Migration Map è l'analisi del parco di codice custom (Z/Y) per la pianificazione ECC→S/4. Prende un export USAGE di produzione e legge la struttura del codice DEV, calcola la chiusura di raggiungibilità dai punti di ingresso usati e classifica ogni oggetto in USED / REACHABLE / REVIEW / CANDIDATE, ciascuno con prove a supporto. Consegna un CSV / report.
Non tocca mai la produzione e non dichiara mai il codice «morto» o «sicuro da cancellare» — i bucket REVIEW e CANDIDATE sono input decisionali per un umano, non verdetti.
Quando usarlo: per dimensionare e prioritizzare un parco di codice custom prima di una migrazione a S/4, con prove per ogni classificazione.
Migration Map è disponibile in entrambi i prodotti Development e Consulting, così può alimentare sia uno sforzo di sviluppo sia un deliverable di consulting.
Clean-core check#
Lettura/Scrittura: Sola lettura.
Clean-core check verifica gli oggetti per la conformità clean-core di S/4HANA. Cerca letture dirette di tabelle standard, chiamate ad API non rilasciate, modifiche, sintassi deprecata e bypass delle interfacce, e assegna ogni oggetto a un bucket COMPLIANT / EXTENSIBLE-VIA-RELEASED / NEEDS-REWORK / BLOCKER. Non cambia nulla.
Quando usarlo: per verificare se oggetti specifici sono pronti per il clean-core e per vedere esattamente cosa lo ostacola.
Clean-core check è disponibile in entrambi i prodotti Development e Consulting.
Pagine correlate#
- Come funzionano i ruoli — il modello dei permessi dietro ogni ruolo.
- Ruoli Developer — il resto del prodotto Development.
- Ruoli Consulting — dove compaiono anche Migration Map e Clean-core check.
- Cleaner ABAP — ciò che CDS salta deliberatamente.
- Chat — scegli un ruolo e invia un'attività.
- Modalità autonoma — la pipeline di applicazione con gate umano per le scritture.