CDS, RAP, Fiori y migración
Estos son los roles de construcción y migración del producto Desarrollo. Los roles de construcción (CDS, RAP, Fiori) crean y activan objetos, trabajando de abajo arriba a través de la cadena de dependencias. Los roles de migración se dividen por intención: Migración corrige interactivamente un objeto, mientras que Mapa de migración y Comprobación clean-core son análisis de solo lectura que no cambian nada.
Viven bajo el producto Desarrollo en el compositor del Chat; Mapa de migración y Comprobación clean-core también aparecen bajo Consultoría. Para el modelo de permisos detrás de cada rol, consulta Cómo funcionan los roles.
De un vistazo#
| Role | Read/Write | Use it to… |
|---|---|---|
| CDS | Escritura | Construir modelos de datos CDS VDM reales de abajo arriba. |
| RAP | Escritura | Construir un objeto de negocio RAP completo. |
| Fiori | Escritura | Preparar un servicio OData para Fiori Elements. |
| Migración | Escritura | Preparar interactivamente un objeto para ECC→S/4 / Clean-Core. |
| Mapa de migración | Solo lectura | Analizar un parque de código propio para planificar S/4. |
| Comprobación clean-core | Solo lectura | Auditar objetos en busca de cumplimiento clean-core. |
CDS#
Read/Write: Escritura.
CDS diseña y construye modelos de datos CDS VDM reales — objetos DDLS, DDLX y DCLS más sus tablas. Sigue la estratificación del Virtual Data Model: vistas de interfaz base ZI_ y vistas ZR_, vistas de texto, proyecciones de consumo ZC_ y controles de acceso. Construye de abajo arriba y activa sobre la marcha.
Nunca ejecuta el ABAP cleaner sobre CDS — el DDL de CDS lo normaliza el propio rol, no el cleaner.
Cuándo usarlo: para levantar un modelo de datos CDS correctamente estratificado en lugar de una vista aislada.
RAP#
Read/Write: Escritura.
RAP construye un objeto de negocio RAP completo de principio a fin: la tabla, DDLS (definición de datos), DDLX (extensión de metadatos), BDEF (definición de comportamiento), CLAS (implementación del comportamiento), SRVD (definición de servicio) y SRVB (binding de servicio). Su metodología es modelo de datos → comportamiento (managed) → proyección + servicio → verificar mediante EML.
Publicar el servicio OData es un paso humano — el rol construye y hace el binding, pero tú publicas.
Cuándo usarlo: para construir un objeto RAP transaccional (escenario managed) desde un modelo de datos hasta un servicio verificado.
Fiori#
Read/Write: Escritura.
Fiori prepara un servicio OData existente para Fiori Elements. Crea la capa de anotaciones @UI — extensiones de metadatos o @UI en línea — más anotaciones de ayuda de búsqueda (value help), texto y búsqueda, y expone el resultado mediante SRVD + SRVB.
El despliegue del app-shell de UI5 y la configuración del launchpad son traspasos manuales explícitos — el rol prepara el servicio y las anotaciones; tú despliegas la app y cableas el launchpad.
Cuándo usarlo: para convertir un servicio OData funcional en uno que una app de Fiori Elements pueda renderizar, sin escribir anotaciones a mano.
Migración#
Read/Write: Escritura.
Migración es la preparación interactiva ECC→S/4HANA / Clean-Core de un objeto (o un paquete pequeño). Su metodología es evaluar (una variante ATC de preparación para S/4 o un escaneo del fuente) → corregir hallazgo por hallazgo (una corrección mínima, en la dirección clean-core, señalando las trampas) → verificar → informar. Un humano aprueba cada cambio.
Cuándo usarlo: para corregir realmente un objeto concreto de cara a S/4, un hallazgo cada vez, con un humano en el bucle en cada edición.
Mapa de migración#
Read/Write: Solo lectura.
Mapa de migración es el análisis del parque de código propio (Z/Y) para la planificación de ECC→S/4. Toma una exportación de USAGE de producción y lee la estructura del código de DEV, calcula el cierre de alcanzabilidad desde los puntos de entrada usados y clasifica cada objeto en USED / REACHABLE / REVIEW / CANDIDATE, cada uno con su evidencia de respaldo. Entrega un CSV / informe.
Nunca toca producción y nunca declara código como "muerto" o "seguro de borrar" — los grupos REVIEW y CANDIDATE son insumos de decisión para un humano, no veredictos.
Cuándo usarlo: para dimensionar y priorizar un parque de código propio antes de una migración a S/4, con evidencia para cada clasificación.
Mapa de migración está disponible tanto en el producto Desarrollo como en Consultoría, de modo que puede alimentar tanto un esfuerzo de construcción como un entregable de consultoría.
Comprobación clean-core#
Read/Write: Solo lectura.
Comprobación clean-core audita objetos en busca de cumplimiento clean-core de S/4HANA. Busca lecturas directas de tablas estándar, llamadas a APIs no liberadas, modificaciones, sintaxis obsoleta y elusiones de interfaz, y agrupa cada objeto como COMPLIANT / EXTENSIBLE-VIA-RELEASED / NEEDS-REWORK / BLOCKER. No cambia nada.
Cuándo usarlo: para comprobar si objetos concretos están listos para clean-core, y ver exactamente qué lo impide.
Comprobación clean-core está disponible tanto en el producto Desarrollo como en Consultoría.
Páginas relacionadas#
- Cómo funcionan los roles — el modelo de permisos detrás de cada rol.
- Roles de desarrollo — el resto del producto Desarrollo.
- Roles de consultoría — donde también aparecen Mapa de migración y Comprobación clean-core.
- ABAP cleaner — lo que CDS omite deliberadamente.
- Chat — elige un rol y envía una tarea.
- Modo autónomo — el pipeline de aplicación con barrera humana para las escrituras.