Cosa è SAP CAP

Cosa è SAP CAP

L’articolo in questione tratterà i seguenti argomenti:

• Definizione contesto di SAP Cloud Application Programming (CAP)
• la sua integrazione con SAP S/4 HANA;
• l’utilizzo dei principali linguaggi supportati (Node.js e Java);
• approfondimenti su CDS, servizi OData e deployment su SAP BTP.

L’articolo “Cosa è SAP CAP” includerà esempi pratici di codice, analisi tecnica del framework, punti di forza e debolezza, concludendo con considerazioni utili per sviluppatori e consulenti ABAP.

SAP CAP (Cloud Application Programming Model): Guida dettagliata

Definizione e contesto di SAP CAP

SAP Cloud Application Programming Model (CAP) è un framework SAP per sviluppare applicazioni enterprise di nuova generazione in cloud. Fornisce un “percorso aureo” di best practice già consolidate, integrando linguaggi e librerie in un unico modello di sviluppo. CAP mette al centro il dominio del business: permette di modellare dati e servizi in modo dichiarativo tramite Core Data Services (CDS), automatizzando gran parte dei compiti ripetitivi (CRUD, autenticazione, draft, localizzazione, ecc.). L’approccio è “cloud-native”: CAP si allinea perfettamente alla SAP Business Technology Platform (BTP) e promuove architetture modulari e basate su microservizi, pur consentendo una rapida prototipazione in locale. Secondo la documentazione ufficiale, CAP è talvolta scherzosamente definito “come ABAP per il mondo non-ABAP”, sottolineando come SAP CAP renda disponibili agli sviluppatori cloud molti concetti familiari di SAP (come CDS e OData), pur essendo fondamentalmente diverso da ABAP tradizionale.

Integrazione SAP CAP con SAP S/4 HANA

SAP CAP è pensato per integrarsi strettamente con l’ecosistema SAP. In particolare, si presta a scenari di estensione side-by-side di SAP S/4HANA Cloud (e S/4 HANA on-premise) sulla BTP. Ad esempio, una CAP application può consumare i servizi OData esposti da S/4 HANA e combinarli con logica di business custom. La libreria CAP fornisce API dedicate per importare definizioni di servizio remote, interrogare sistemi esterni e “mash-up” di dati. In pratica, un’app CAP può definire entità locali (gestite dal proprio database) e collegarle via associazioni ad entità ospitate in S/4 HANA. La documentazione ufficiale descrive un caso d’uso di estensione S/4 dove i dati dei fornitori (supplier) sono gestiti in S/4 HANA Cloud e vengono consumati da un’applicazione CAP che gestisce i rischi associati. In questo scenario l’applicazione CAP chiama i servizi OData di S/4 HANA Cloud per ottenere l’elenco dei fornitori e aggiornare il loro stato, integrando così perfettamente i due ambienti. In sintesi, CAP offre tutti gli strumenti per integrare e ampliare S/4 HANA tramite servizi OData: supporta sia chiamate in lettura che in scrittura sui servizi remoti, e consente di arricchire le operazioni OData di S/4 con logica aggiuntiva locale.

Linguaggi supportati: Node.js e Java

Il runtime di SAP CAP è disponibile sia in Node.js che in Java. Entrambi gli ambienti offrono funzionalità analoghe e aiutano lo sviluppatore a focalizzarsi sul dominio di business. In pratica si sceglie uno dei due stack all’avvio del progetto: la scelta non influisce sul modello dati (CDS) o sulle interfacce (OData), che rimangono identiche. Entrambi i runtime forniscono implementazioni generiche per compiti ricorrenti (es. gestire query, associazioni, transazioni, autenticazione). Ad esempio, in Node.js si utilizza il pacchetto @sap/cds per definire servizi e connettersi al database; in Java si usa il CAP Java SDK, generalmente basato su Spring Boot. Un tipico esempio in Node.js è implementare un servizio CAP estendendo cds.ApplicationService:

class BooksService extends cds.ApplicationService {
  init() {
    const { Books, Authors } = this.entities;
    this.before('READ', Authors, req => { /* ... logica prima della lettura ... */ });
    return super.init();
  }
}
module.exports = BooksService;

Questo codice (presente nella documentazione SAP) dimostra come registrare eventi (before, after, on) su entità CAP. In modo analogo, in Java si definisce una classe @SpringBootApplication che inizializza il contesto CAP; le entità CDS vengono trasformate automaticamente in tabella (HANA o altra DB) e i servizi CDS in endpoint OData. In entrambi i casi, gran parte della logica CRUD è auto-generata: lo sviluppatore implementa soltanto il codice custom aggiuntivo, come negli esempi sopra.

Core Data Services (CDS)

CDS è il motore di modellazione alla base di CAP. Con CDS si definiscono in modo dichiarativo le entità di dominio (e loro relazioni, composizioni, enumerazioni) nonché i servizi che le espongono. Ad esempio in un file schema.cds si può scrivere:

using { cuid, managed } from '@sap/cds/common';
namespace my.company;

entity Customers : managed {
  key ID        : String;
  firstName     : String;
  lastName      : String;
  email         : String;
}

Questo codice (estratto da un tutorial ufficiale) crea un’entità Customers con attributi e una chiave, facendo uso di tipi e comportamenti gestiti (ad es. managed aggiunge campi di audit). CDS consente anche associazioni tra entità (ad es. collegare ordini e clienti) e composizioni nidificate. La definizione in CDS viene compilata automaticamente in schemi di database (tabella, viste) e contratti di servizio OData. In pratica, definendo poche righe in CDS si ottiene di default un servizio OData completo con endpoint CRUD e metadata. Il modello CDS è flessibile: supporta validazioni tramite annotazioni (ad es. @assert.format), enumerazioni, liste di scelta (CodeList), e persino il concatenamento di stringhe o riferimenti a tipi comuni (vedi snippet). Al tempo di esecuzione, SAP CAP mantiene il modello CDS come oggetti JSON (CSN – Core Schema Notation), permettendo estensioni dinamiche e integrazione con altri servizi. In breve, CDS è il punto di partenza: serve a descrivere i dati e le API dell’applicazione in modo dichiarativo, semplificando molto lo sviluppo rispetto all’approccio tradizionale di definire manualmente tabelle e viste.

Esposizione e gestione di servizi OData

Un aspetto chiave di CAP è l’esposizione automatica di API OData basate sul modello CDS. Per ogni servizio definito in CDS, CAP genera un servizio OData (tipicamente V4) con supporto nativo a funzionalità di query ($select, $filter, $expand, $orderby, ecc.). Come sottolinea la documentazione SAP, “una semplice definizione di servizio in CDS è tutto ciò che serve per far girare un server REST o OData a pieno titolo”. Ad esempio, dichiarando in CDS:

service CatalogService { 
  entity Products as projection on my.company.Products;
}

si ottiene subito un endpoint /CatalogService/Products che espone le entità Products come risorsa OData V4, con tutte le operazioni CRUD standard già implementate. CAP gestisce anche annotazioni OData standard e SAP, mappandole dal modello CDS. È possibile esporre anche OData V2 usando l’adapter apposito nei progetti Node.js o Java, se necessario. In sintesi, CAP riduce al minimo il codice boilerplate per esporre dati e logica via OData: basta modellare il servizio in CDS e il framework si occupa di tutto il resto (sequenze di avvio, registrazione endpoint, gestione delle richieste, ecc.).

Deployment su SAP BTP (Cloud Foundry)

Le applicazioni sviluppate con CAP sono progettate per essere distribuite sulla SAP BTP Cloud Foundry (oltre che, opzionalmente, su Kyma). La distribuzione avviene tipicamente tramite un pacchetto Multi-Target Application (MTA) che incapsula i vari componenti dell’app (modulo Node.js/Java, servizio di database SAP HANA Cloud, configurazione di autenticazione XSUAA, ecc.). La guida ufficiale sottolinea i passi principali: prima di tutto si prepara il modello CAP per la produzione (configurazione di SAP HANA, sicurezza, ecc.) e poi si esegue la build e il deploy sulla CF. CAP mette a disposizione il comando cds add mta per generare automaticamente il file mta.yaml con i moduli e le risorse necessarie. Ad esempio, dopo aver configurato i servizi VCAP di HANA e UAA, con:

cds add mta

si crea il descriptor mta.yaml che definisce moduli (app, servizio, app router, ecc.) e destinazioni. In seguito si usa il Cloud MTA Build Tool (mbt) o i comandi cf per compilare e distribuire l’applicazione. CAP prevede inoltre la possibilità di includere un App Router come gateway singolo per gestire autenticazione e routing verso i vari moduli, oppure utilizzare il gateway gestito di SAP Fiori Launchpad. Tutto il processo di deploy su BTP è supportato dalla documentazione SAP, che spiega anche come automatizzarlo con pipeline CI/CD. In sintesi, SAP CAP fornisce un percorso di deployment standardizzato su BTP: il framework si integra con i servizi cloud SAP (HANA, UAA, Portal, Event Mesh, ecc.) e genera i metadati necessari affinché l’applicazione sia pronta per la produzione su Cloud Foundry.

Esempi di codice per SAP CAP

Di seguito alcuni snippet tratti dalla documentazione ufficiale che illustrano gli aspetti principali di CAP:

• Definizione del modello dati (CDS). In un file .cds si dichiara il dominio, per esempio: entity Customers : managed { key ID : String; firstName : String; lastName : String; email : String; } Questo definisce un’entità Customers con campi e chiave primaria. CAP creerà la tabella corrispondente e l’esporrà come servizio OData.
• Implementazione di un servizio in Node.js. Estendendo cds.ApplicationService si possono intercettare gli eventi sulle entità. Ad esempio (dalla doc): const cds = require('@sap/cds'); module.exports = class BooksService extends cds.ApplicationService { init() { const { Books } = this.entities; this.before('READ', Books, req => { /* custom logic */ }); return super.init(); } }; Questo codice registra un handler before sul servizio Books, che viene eseguito prima di ogni operazione di lettura. Il modulo esportato viene automaticamente collegato al servizio CDS corrispondente.
• Deploy su BTP (MTA). Una volta pronti i moduli, si esegue in shell il comando: cds add mta come indicato dalla guida. Questa istruzione genera il file mta.yaml con la configurazione di tutte le risorse (modulo applicazione, servizio HANA, autenticazione, app router, ecc.), pronto per il deployment su Cloud Foundry.

(Questi esempi sono tratti dalla documentazione SAP e mostrano le convenzioni base di CAP per definire dati, logica di servizio e deployment.)

Punti di forza e debolezze

Punti di forza: CAP è un framework maturo e allineato alle tecnologie cloud emergenti. Grazie a CDS e OData integrati, accelera molto lo sviluppo di servizi enterprise complessi, riducendo il codice boilerplate. Supportando Node.js e Java, permette ai team di scegliere lo stack più adatto senza limitazioni imposte da SAP. I meccanismi “out-of-the-box” di CAP (autenticazione con XSUAA, multi-tenancy, event handling, integrazione con Fiori e connettività a SAP Event Mesh) rappresentano best practice provate, il che migliora sicurezza, scalabilità e consistenza del codice. Inoltre, CAP facilita l’estendibilità del modello dati e dei servizi sia verticalmente (via estensioni CDS) sia orizzontalmente (sviluppando microservizi separati), mantenendo un approccio modulare.

Punti di debolezza: CAP è relativamente nuovo e richiede ai professionisti ABAP di acquisire competenze in JavaScript/Node o Java/Spring Boot, oltre a familiarizzare con i concetti di cloud e microservizi. Alcune funzionalità tipiche dell’ambiente ABAP classico (come gestioni specifiche di transazioni ABAP o CDS di ABAP in S/4) non sono presenti in CAP, quindi soluzioni esistenti devono essere ripensate. Dal lato tecnico, alcune complessità nascoste (ad es. la gestione del modello OData o dettagli di sicurezza) possono generare una curva di apprendimento ripida. Infine, essere vincolati alla piattaforma BTP significa valutare costi e limiti di run-time tipici di ambienti cloud SAP (es. limiti di dimensione DB in HANA Cloud, configurazione di strumenti CI/CD, ecc.).

Novità rispetto ad approcci precedenti (es. ABAP puro)

Rispetto al modello tradizionale ABAP su S/4 HANA, CAP introduce diversi cambiamenti paradigmatici. Innanzitutto, CAP è basato su tecnologie open (JavaScript/Java, Node.js, Spring Boot) e standard aperti (CDS, OData, JSON), mentre ABAP è un linguaggio proprietario SAP. CAP è pensato nativamente per il cloud, con supporto integrato per scalabilità multi-tenant e servizi gestiti, mentre ABAP si concentra su soluzioni on-premise o ABAP-as-a-Service su BTP. Con CAP si lavora principalmente in un ambiente esterno (BTP Cloud Foundry) anche quando si estendono processi S/4; in ABAP classico ci si trova nel core S/4HANA. CAP favorisce un’architettura a microservizi e lo sviluppo parallelo (ad es. separando logica di backend generica e custom), mentre l’approccio ABAP storicamente era più monolitico (anche se RAP in S/4 sta cambiando questa dinamica). In definitiva, CAP rappresenta la “nuova frontiera” SAP per lo sviluppo cloud: incorpora concetti e API SAP consolidate ma su un modello di sviluppo molto diverso dall’ABAP puro, dando agli sviluppatori cloud una piattaforma moderna e aperta, ottimizzata per la Business Technology Platform di SAP.

(fonte)

Innovaformazione, scuola informatica specialistica promuove la cultura dei sistemi SAP fra privati ed aziende ed affianca i team IT delle società informatiche nella formazione continua del personale. Nell’offerta formativa per il mondo SAP trovate una serie di corsi SAP sul nostro sito QUI.

Per i privati trovate i principali corsi SAP QUI.

INFO: info@innovaformazione.net – tel. 3471012275 (Dario Carrassi)