Clean Core con SAP CAP: estendere SAP CX senza il dolore degli aggiornamenti

Personalizzate SAP. Un anno dopo un aggiornamento rompe le vostre modifiche e il team passa settimane a ripararle. È una delle storie che sentiamo più spesso dalle aziende che arrivano da noi con un panorama SAP esistente.

È il costo del codice personalizzato nel core SAP. Cresce in silenzio: dopo qualche giro ogni rilascio diventa un piccolo progetto a sé, e il team comincia a temere le note di rilascio invece di leggerle.

Clean Core interrompe questo ciclo. Il core SAP resta standard e la logica su misura nasce accanto, non dentro, con il framework di estensione che SAP mette a disposizione.

In sintesi: Clean Core significa nessuna modifica nel core SAP. Costruiamo le estensioni side-by-side con il SAP Cloud Application Programming Model (CAP) su SAP BTP. Comunicano con SAP Sales Cloud V2, Service Cloud V2 o S/4HANA Public Cloud tramite API ed eventi rilasciati. Quando SAP pubblica un rilascio, si ritesta il contratto API delle estensioni invece di riparare codice modificato nel core.

Che cosa significa concretamente Clean Core?

Il principio: nessun codice personalizzato dentro SAP. La logica di business vive in estensioni separate che comunicano con SAP tramite API stabili e rilasciate. SAP ne ha fatto la propria indicazione esplicita per l’ERP in cloud; l’articolo SAP How to Extend SAP S/4HANA Cloud the Right Way spiega il modello. In SAP S/4HANA Public Cloud non è nemmeno facoltativo: la piattaforma consente solo punti di estensione rilasciati.

SAP Sales Cloud V2 e SAP Service Cloud V2 seguono la stessa impostazione. Offrono API REST, documentate nel SAP Business Accelerator Hub, e un sistema di eventi pensato per le estensioni side-by-side. SAP aggiorna il core secondo il proprio calendario e le vostre estensioni continuano a funzionare finché il contratto API regge.

Non è un espediente. I prodotti V2 sono stati progettati per tenere separati il core e la logica del cliente.

Come costruiamo le estensioni con SAP CAP?

Usiamo il SAP Cloud Application Programming Model (CAP), il framework SAP per creare servizi su SAP BTP, ed eseguiamo i servizi nell’ambiente Cloud Foundry di SAP BTP. È il nostro standard per le estensioni side-by-side su Sales Cloud V2, Service Cloud V2 e S/4HANA Public Cloud, per tre motivi:

• Poco lavoro infrastrutturale. Cloud Foundry gestisce scalabilità, routing e deployment. Il team scrive logica di business, non script operativi.
• Connettività SAP integrata. CAP lavora con XSUAA per l’autenticazione, con il Destination service e con la messaggistica di eventi SAP, e utilizza le API di Sales e Service Cloud V2 senza codice di raccordo.
• Uno stack standard. Node.js o Java, OData e REST, CDS per la modellazione dei dati. Gli sviluppatori conoscono già gli strumenti e non ci sono vincoli esotici.

Il risultato: estensioni che potete distribuire, testare e aggiornare indipendentemente dal calendario dei rilasci SAP. Descriviamo l’intera configurazione, dal subaccount al deployment, in estendere SAP Sales Cloud V2 con app Cloud Foundry personalizzate e, per il lato ERP, in estendere S/4HANA Public Cloud su BTP Cloud Foundry. Quando la logica deve stare vicino ai dati ERP, S/4HANA offre anche ABAP Cloud on-stack, di cui parliamo nell’articolo su embedded Steampunk.

Come funziona nella pratica?

Esempio Sales Cloud V2: un cliente ha bisogno di una validazione personalizzata sull’opportunità e di alcuni campi aggiuntivi per il proprio processo. Distribuiamo su Cloud Foundry un servizio CAP che contiene la logica di validazione e i dati aggiuntivi. Reagisce agli eventi dell’opportunità invece di interrogare il sistema o eseguire job pianificati. Un’interfaccia personalizzata è incorporata in Sales Cloud V2 come mashup, così i venditori lavorano in un’unica interfaccia.

Il core di Sales Cloud V2 resta intatto. Con il rilascio SAP successivo ritestiamo le chiamate API e gli eventi su cui si basa l’estensione; non c’è codice modificato nel core da riparare.

Esempio Service Cloud V2: regole di escalation personalizzate, dati dei casi arricchiti, collegamenti a strumenti di ticketing esterni. Tutte estensioni CAP su Cloud Foundry, tutte fuori dal core.

Esempio S/4HANA Public Cloud: lo stesso schema vale quando un processo CX ha bisogno di dati ERP, per esempio una verifica del credito prima di rilasciare un’offerta. L’estensione richiama API S/4HANA rilasciate e non tocca mai il core ERP. È così che un unico team mantiene standard sia il core ERP sia lo stack CX.

Perché Clean Core conta per il vostro budget?

Il codice personalizzato che si rompe durante gli upgrade è uno dei motivi più comuni per cui i progetti SAP sforano tempi e budget. Molti responsabili IT hanno vissuto un upgrade andato storto perché una modifica fatta anni prima non era mai stata documentata.

Senza Clean Core ogni rilascio SAP ha un costo: il team testa il codice personalizzato, lo adatta e ripara ciò che si è rotto, ogni volta. Con Clean Core un rilascio significa soprattutto ritestare le estensioni rispetto a un contratto API che SAP versiona e mantiene stabile. Quanto diventino più rapidi gli upgrade dipende da quanta logica spostate fuori dal core, ma lo sforzo passa dalla riparazione al test di regressione.

In tre-cinque anni questa differenza si accumula. Meno tempo per la manutenzione significa più tempo per le funzionalità che fanno crescere l’azienda.

Se state pianificando il passaggio a S/4HANA e volete sapere quanto codice personalizzato andrà ricostruito, il nostro S/4HANA readiness assessment risponde prima dell’avvio del progetto. Per scegliere un partner che costruisce le estensioni in questo modo, leggete la nostra panoramica dei migliori partner di sviluppo SAP BTP in Svizzera.

Domande frequenti

E se la mia estensione ha bisogno di dati dal core SAP?

Un’estensione CAP legge e scrive i dati tramite le API rilasciate di SAP Sales Cloud V2, Service Cloud V2 o S/4HANA Public Cloud. Delle modifiche, come una nuova opportunità, la informano le notifiche di eventi, per esempio tramite SAP Event Mesh. Non accede mai direttamente al database del core.

Le personalizzazioni esistenti si possono migrare a Clean Core?

Sì, ma è un lavoro di refactoring, non un semplice trasferimento. Il codice ABAP personalizzato o le modifiche nel core vengono ricostruiti come servizi side-by-side o come estensioni on-stack rilasciate. La logica di business resta la stessa; cambia l’architettura.

Clean Core funziona anche per SAP Commerce Cloud?

Il principio è lo stesso, il meccanismo è diverso. Commerce Cloud usa estensioni nel type system e punti di estensione definiti invece di modifiche al core. Sul frontend, SAP Composable Storefront (in precedenza Spartacus) separa le personalizzazioni tramite la dependency injection di Angular.

CAP è l’unica opzione per le estensioni Clean Core?

No. Funziona qualsiasi tecnologia che richiami le API rilasciate da SAP, per esempio Java, Node.js, Python o il low-code con SAP Build. Usiamo CAP perché integra autenticazione, modellazione dei dati e connettività SAP, ed è quindi la strada più breve verso estensioni pronte per la produzione.

Che effetto ha Clean Core sul supporto SAP?

SAP supporta il proprio prodotto standard. Le modifiche nel core possono complicare le segnalazioni, perché SAP deve prima escludere il codice personalizzato. Le estensioni side-by-side lasciano intatto lo standard, e il supporto delle vostre estensioni avviene separatamente.

Avviate un progetto Sales Cloud V2, Service Cloud V2 o S/4HANA Public Cloud? Parlate con i nostri architetti di un approccio Clean Core fin dal primo giorno.