ABAP Cloud y RAP: cómo extender SAP sin tocar el core

ABAP Cloud y RAP permiten crear extensiones y servicios SAP con una regla clara: aprovechar el estándar sin convertir cada actualización en un proyecto de reparación. La clave no es dejar de personalizar, sino hacerlo con contratos estables, APIs liberadas y una arquitectura que separe el código propio del núcleo de S/4HANA.

En esta guía verás qué cambia respecto al desarrollo ABAP clásico, cómo encajan Clean Core, ABAP Cloud y RAP, y cuándo conviene diseñar una extensión dentro de S/4HANA o en SAP BTP.

Por qué el código Z ya no puede invadir el núcleo

El código Z sigue siendo una herramienta legítima para resolver necesidades específicas de negocio. El problema aparece cuando depende de objetos internos no liberados, altera comportamientos estándar o se mezcla sin límites con la lógica del ERP. En ese escenario, cada actualización exige volver a analizar compatibilidades y crece la deuda técnica.

El enfoque Clean Core busca que las extensiones permanezcan desacopladas del estándar. SAP plantea ABAP Cloud como su modelo para desarrollar aplicaciones, servicios y extensiones cloud-ready: limita el lenguaje a elementos aptos para cloud y exige utilizar APIs y objetos liberados. Así, el código propio puede evolucionar con más previsibilidad.

Qué es ABAP Cloud

ABAP Cloud es un modelo de desarrollo para construir soluciones estables durante el ciclo de vida del producto. Combina una versión de ABAP optimizada para cloud, CDS para el modelado de datos, RAP para aplicaciones y servicios transaccionales, ADT como entorno de desarrollo y APIs públicas liberadas por SAP.

La diferencia importante frente al desarrollo clásico es la disciplina: una extensión no debe depender de cualquier tabla, clase o función estándar. Debe consumir objetos que SAP haya liberado para ese uso. Esos contratos reducen el riesgo de romperse en un upgrade y aclaran qué es compatible dentro del alcance de cada producto.

APIs liberadas: el contrato que protege tu extensión

Las APIs liberadas pueden ser locales o remotas y se rigen por contratos de liberación. En la práctica, conviene buscar primero una API o un punto de extensión disponible para el escenario de negocio, y solo después diseñar el código. ADT ayuda a trabajar dentro de las restricciones de ABAP for Cloud Development.

RAP: del modelo de datos al servicio consumible

El ABAP RESTful Application Programming Model (RAP) es la arquitectura de SAP para desarrollar de extremo a extremo aplicaciones transaccionales y APIs web en ABAP Cloud. Parte de un modelo de negocio y permite exponerlo como servicio OData para una app Fiori u otro consumidor.

Un diseño RAP típico separa cuatro responsabilidades:

• Modelo de datos: entidades CDS con significado de negocio.
• Comportamiento: operaciones, validaciones, autorizaciones y acciones que puede ejecutar el objeto de negocio.
• Exposición del servicio: proyecciones y bindings que publican el modelo para su consumo.
• Aplicación: por ejemplo, una interfaz SAP Fiori Elements o una integración que consume la API.

RAP ofrece escenarios managed, en los que el framework gestiona gran parte del comportamiento estándar, y escenarios unmanaged, útiles cuando hay que integrar una lógica existente o un comportamiento más específico. La elección depende del proceso, no de una preferencia estética.

Ejemplo: gestionar proyectos especiales

Imagina que necesitas una aplicación para gestionar proyectos especiales que no existen en el estándar. En lugar de crear un programa de diálogo aislado, puedes modelar la entidad con CDS, definir su comportamiento en RAP y exponer un servicio OData. A partir de ahí, una aplicación Fiori Elements puede consumir el servicio con una base coherente para búsquedas, validaciones, autorizaciones y operaciones CRUD.

managed implementation in class zbp_i_specialproject unique;
strict;

define behavior for ZI_SpecialProject
persistent table zspecial_project
lock master
authorization master ( instance )
{
  create;
  update;
  delete;
}

Este fragmento es solo el comportamiento: el modelo CDS y la exposición del servicio completan el objeto de negocio. Antes de implementarlo en un sistema real, valida los objetos liberados disponibles para la versión y el alcance concreto de S/4HANA o SAP BTP.

On-stack o side-by-side: cómo elegir

La arquitectura empieza antes de escribir la primera línea de código. Hay dos patrones frecuentes que pueden coexistir:

• On-stack: la extensión se ejecuta en el entorno ABAP de S/4HANA y respeta las APIs y puntos de extensión liberados. Es útil cuando debe vivir cerca del proceso de negocio estándar.
• Side-by-side: la aplicación o integración vive fuera del core, por ejemplo en SAP BTP, y consume APIs, eventos o servicios remotos. Aporta desacoplamiento para casos que integran varios sistemas o evolucionan con un ciclo propio.

La pregunta correcta no es “¿dónde es más rápido desarrollar?”, sino: ¿qué dependencia del core necesita realmente esta capacidad? Si la respuesta es poca, el patrón side-by-side suele reducir el acoplamiento. Si el proceso exige una extensión próxima al negocio estándar, una extensión on-stack con ABAP Cloud puede ser adecuada.

Una ruta práctica para modernizar desarrollo ABAP

1. Clasifica el desarrollo existente: estándar, extensión, integración o deuda técnica.
2. Busca APIs, eventos y puntos de extensión liberados antes de acceder a objetos internos.
3. Diseña el objeto de negocio con CDS y RAP cuando el caso sea transaccional o exponga servicios.
4. Decide on-stack o side-by-side según el acoplamiento, los consumidores y el ciclo de vida.
5. Usa controles de calidad como ATC y pruebas automatizadas para evitar regresiones.

Conclusión

ABAP Cloud y RAP no eliminan la personalización: la convierten en una práctica más sostenible. Para equipos que trabajan con S/4HANA, SAP BTP y Fiori, dominar modelos de datos, APIs liberadas y servicios transaccionales es una forma directa de construir extensiones que sigan funcionando cuando el ERP evolucione.

Si quieres llevar estos conceptos a proyectos reales, explora la formación SAP de Logali y los itinerarios de ABAP Cloud, RAP y SAP BTP.

Preguntas frecuentes

¿ABAP Cloud sustituye por completo al ABAP clásico?

No de forma inmediata. SAP recomienda ABAP Cloud por defecto para nuevos desarrollos y extensiones cuando el escenario y las APIs liberadas lo permiten. Los sistemas existentes requieren una transición gradual y con prioridades de negocio.

¿RAP solo sirve para aplicaciones Fiori?

No. RAP permite modelar aplicaciones transaccionales y publicar APIs web. Una interfaz Fiori es un consumidor habitual, pero no el único.

¿Cuándo usar side-by-side?

Cuando la capacidad debe evolucionar de forma desacoplada, integrar varios sistemas o evitar dependencias directas con el core de S/4HANA. La decisión final depende de las APIs, eventos y requisitos operativos disponibles.

Fuentes oficiales

• SAP Help: ABAP Cloud Development Model
• SAP Help: ABAP RESTful Application Programming Model
• SAP Help: Public Released APIs