SAP Cloud Application Programming Model (CAP)

Una aplicación CAP parte de declaraciones y añade código solo donde los valores predeterminados del framework no bastan:

1. Modelo de dominio: las entidades, los tipos y las asociaciones se escriben en archivos CDS, por ejemplo proveedores y franjas de entrega para una aplicación de logística de Alder Manufacturing.
2. Servicios: las service definitions exponen proyecciones de esas entidades, adaptadas a una UI o a una API.
3. Runtime: el runtime Node.js o el CAP Java SDK sirve los servicios y gestiona de forma genérica las operaciones estándar: lectura, escritura, paginación, ordenación y draft de SAP Fiori.
4. Lógica personalizada: los event handlers en JavaScript, TypeScript o Java, registrados para las fases before, on y after de una solicitud, añaden validaciones, cálculos y llamadas a otros sistemas.
5. Persistencia: el mismo modelo se ejecuta en SQLite o H2 durante el desarrollo y en SAP HANA Cloud o PostgreSQL en producción.
6. Despliegue: la aplicación se despliega en SAP BTP, en el runtime Cloud Foundry o Kyma.

Las aplicaciones SAP Fiori elements consumen los servicios CAP mediante anotaciones de UI escritas en los mismos archivos CDS. Una aplicación CAP es, por tanto, sobre todo modelo, con el código concentrado allí donde la lógica de negocio es específica.

No. Ambos provienen de la idea de Core Data Services de SAP, ambos usan una sintaxis declarativa similar y ambos incluyen anotaciones, pero son implementaciones separadas:

• ABAP CDS forma parte de la plataforma ABAP. Sus vistas son objetos del repositorio que se activan como vistas de base de datos dentro de un sistema ABAP y se transportan con transportes ABAP.
• CAP CDS es el lenguaje de modelado de CAP. Su compilador convierte los modelos en una representación basada en JSON llamada Core Schema Notation (CSN), a partir de la cual CAP genera artefactos de base de datos y metadatos de servicio.

Las anotaciones muestran la diferencia en la práctica. En CAP, las anotaciones de UI usan directamente los nombres de los términos OData, como UI.LineItem; en ABAP CDS, las notaciones a nivel de elemento como @UI.lineItem se traducen a esos términos cuando se expone el servicio. Un modelo no puede pasar de uno a otro sin cambios. CAP CDS y ABAP CDS comparten un nombre y una filosofía, no un runtime.

Elija CAP cuando:

• la aplicación debe estar junto a SAP S/4HANA y no dentro de él, como extensión side-by-side en SAP BTP;
• la aplicación tiene sus propios datos o combina datos de varios sistemas, SAP y no SAP;
• el equipo trabaja en JavaScript, TypeScript o Java en lugar de ABAP;
• la aplicación debe servir a varios clientes como oferta SaaS multitenant, que CAP admite con aislamiento de tenants y sus servicios MTX.

Prefiera RAP cuando la lógica debe ejecutarse en la misma transacción que los datos de SAP S/4HANA, cuando la extensión modifica un business object estándar, o cuando el equipo y el modelo de operación se basan en ABAP.

Muchos entornos usan ambos: RAP para la lógica cercana al núcleo, CAP para las aplicaciones a su alrededor. La pregunta decisiva para CAP es dónde deben residir los datos y la transacción.

Una aplicación CAP no se ejecuta dentro de SAP S/4HANA, por lo que accede a los datos de SAP mediante API:

1. La definición de API de un servicio OData de SAP S/4HANA, por ejemplo del SAP Business Accelerator Hub, se importa en el proyecto CAP con cds import, que lee archivos OData EDMX, OpenAPI y AsyncAPI.
2. Durante el desarrollo, CAP puede simular localmente el servicio importado, de modo que los equipos pueden trabajar antes de que exista la conexión.
3. En producción, las llamadas pasan por la conectividad de SAP BTP: destinations para el sistema de destino y, para los sistemas on-premise, el Cloud Connector.
4. Los eventos de SAP S/4HANA pueden desencadenar lógica CAP de forma asíncrona cuando el escenario lo admite, normalmente a través de un servicio de event broker de SAP.

El contrato entre CAP y SAP S/4HANA es la API liberada, no la tabla de base de datos. Esto mantiene la extensión desacoplada del núcleo, que es el propósito del enfoque side-by-side que sigue CAP.

Los puntos fuertes de CAP son la rapidez y la coherencia. Los handlers genéricos eliminan el código repetitivo, el desarrollo local funciona sin conexión a la nube gracias a los mocks y a SQLite, la compatibilidad con SAP Fiori y SAP HANA viene integrada, y la multitenancy forma parte del framework en lugar de ser un proyecto aparte.

Los límites se derivan de ejecutarse fuera del sistema de registro:

• Sin acceso directo a los elementos internos de SAP S/4HANA. Todo pasa por API liberadas; las API que faltan se convierten en bloqueos o requieren un complemento en el lado ABAP.
• Sin transacción compartida. Una actualización en CAP y una contabilización en SAP S/4HANA son transacciones separadas; el tratamiento de fallos debe diseñarse explícitamente.
• Más que operar. Una aplicación CAP añade al entorno un runtime de SAP BTP, una base de datos y conectividad, con su propia supervisión, actualizaciones y costes.
• Framework con convenciones marcadas. Trabajar en contra de las convenciones de CAP cuesta más que seguirlas.

CAP es la opción más sólida para las aplicaciones junto al núcleo; no sustituye la lógica que debe residir dentro de él.