Datos de negocio expuestos como servicio
CDS & RAP
El problema
Necesitas exponer información de S/4HANA a otras aplicaciones sin duplicar datos, sin modificaciones al core y con un modelo de autorización que resista una auditoría.
Línea: Desarrollo e integración
Señales de que lo necesitas
- Hay procesos que replican datos de SAP en otra base de datos "porque era más rápido".
- Cada integración nueva abre una conexión directa a tablas de la base.
- Nadie sabe qué servicios OData están publicados ni quién los consume.
- Las autorizaciones se controlan en la interfaz y no en el servicio.
- El sistema tiene modificaciones al estándar que nadie se atreve a tocar.
Qué entregamos
- Modelado CDS y vistas de consumo
- Servicios OData V4 con ABAP RAP (managed y unmanaged)
- Extensiones side-by-side con CAP y Node.js
- Estrategia clean core y extensibilidad
Exponer datos de SAP es fácil. Exponerlos de forma que sigan siendo correctos dentro de tres años, tras dos upgrades y con auditoría de por medio, es el trabajo real.
Cómo lo abordamos
Modelado en capas. Separamos las vistas CDS de interfaz —cercanas a los datos, reutilizables— de las vistas de consumo, que se ajustan al caso concreto. Esa separación es la que permite reutilizar el modelo sin duplicarlo cuando aparezca el segundo consumidor.
RAP cuando la lógica pertenece al core. Si el comportamiento de negocio vive junto a los datos, lo natural es implementarlo en ABAP con RAP: definición de comportamiento, validaciones, determinaciones y acciones, expuesto como servicio OData V4 mediante service definition y service binding.
CAP cuando la extensión debe estar fuera. Cuando la lógica no pertenece al core, o el equipo que la mantendrá no es ABAP, la construimos side-by-side con CAP y Node.js sobre Cloud Foundry, consumiendo las APIs publicadas del sistema central.
Autorización en el servicio, no en la pantalla. El modelo de permisos se define donde no se puede eludir. Una app puede ocultar un botón; solo el servicio puede impedir la operación.
Qué recibes
- Servicios OData documentados, con su modelo de autorizaciones y sus dependencias.
- Modelo CDS en capas, versionado y desplegable por transporte o por pipeline.
- Criterio escrito de qué va en el core y qué va side-by-side, para que la próxima decisión no se improvise.
- Traspaso al equipo interno con la documentación del diseño.
Así se ve
Una vista CDS raíz para RAP: el modelo de datos con su control de acceso, listo para exponerse como servicio OData V4.
@AccessControl.authorizationCheck: #CHECK
@EndUserText.label: 'Pedidos de compra'
define root view entity ZR_Pedido
as select from zpedido
{
key pedido_uuid as PedidoUUID,
proveedor as Proveedor,
@Semantics.amount.currencyCode: 'Moneda'
importe as Importe,
moneda as Moneda,
estado as Estado
}Tecnologías
Core Data Services, ABAP RAP, ABAP Cloud, OData V4, SAP Cloud Application Programming Model, Node.js, SAP BTP ABAP Environment, Cloud Foundry.
Preguntas frecuentes
¿Cuál es la diferencia entre RAP y CAP?
ABAP RAP (RESTful Application Programming Model) se ejecuta en la pila ABAP, dentro de S/4HANA o en el ABAP Environment de SAP BTP, y es la vía natural cuando la lógica de negocio vive junto a los datos y el equipo que la mantendrá es ABAP. CAP (Cloud Application Programming Model) se ejecuta en Node.js o Java sobre Cloud Foundry o Kyma, y es la opción para extensiones side-by-side desacopladas del core. La decisión depende de dónde reside la lógica y de qué perfil tiene el equipo que va a mantenerla, no de cuál es más moderno.
¿Qué significa "clean core" y por qué importa?
Clean core es el principio de mantener el sistema central libre de modificaciones, construyendo las extensiones sobre interfaces publicadas y estables en lugar de tocar el código de SAP. Importa porque determina el coste de cada actualización: un core limpio se actualiza como un trámite, mientras que uno modificado obliga a revisar y ajustar cada desarrollo propio en cada upgrade.
¿Cuál es la diferencia entre un behavior managed y unmanaged en RAP?
En un escenario managed, el framework de RAP se encarga de la persistencia: crear, modificar y borrar registros se resuelve automáticamente contra las tablas subyacentes. En un escenario unmanaged, esa lógica la implementas tú, y es la opción cuando ya existe lógica de negocio heredada que debe reutilizarse o cuando la persistencia no es una tabla directa. Managed es el punto de partida recomendado para desarrollos nuevos.
¿Tienes este problema ahora mismo?
Reserva 30 minutos de análisis y te llevas una propuesta técnica formal con la estimación del esfuerzo. Descontable del proyecto si seguimos adelante.
Reservar sesión 1:1