Per estendere SAP mantenendo il clean core, la scelta preferibile è costruire estensioni side-by-side su SAP BTP, scegliendo il runtime in base alle competenze del team. Un team ABAP lavora meglio con l’ambiente ABAP Cloud e il pattern RAP. Un team abituato a Java o Node.js ottiene risultati più rapidi con CAP su Cloud Foundry o Kyma. Per esigenze citizen developer, SAP Build copre casi low-code senza toccare il codice del core.
- ABAP Cloud / RAP → team con competenze SAP consolidate
- CAP + Cloud Foundry o Kyma → team web/microservizi
- SAP Build → key user e automazioni leggere
Le comunicazioni tra estensioni e sistema ERP passano tramite API standard OData/REST ed eventi di business, un loose coupling che permette di aggiornare core ed estensione in modo indipendente.
Punti chiave
Le estensioni side-by-side su SAP BTP, scelte in base alle competenze del team, garantiscono aggiornabilità del core e riducono il debito tecnico rispetto alle modifiche dirette al sistema ERP.
| Punto | Dettagli |
|---|---|
| Pattern raccomandato | Side-by-side su BTP come prima scelta per preservare il clean core negli upgrade futuri. |
| Scelta del runtime | ABAP Cloud per team SAP, CAP su Cloud Foundry o Kyma per team web/Java. |
| Integrazione sicura | Usare API OData/REST ed eventi di business per un accoppiamento debole tra core ed estensione. |
| Assessment prima di migrare | Mappare le estensioni esistenti e decidere cosa mantenere, riprogettare o eliminare. |
| Supporto professionale | Greensharp offre assessment, progettazione architetturale e sviluppo di estensioni SAP BTP per aziende lusso e retail. |
Indice
- Cosa sono le estensioni SAP BTP e perché conta il clean core
- Quale pattern di estensione scegliere: in-app, ABAP Cloud o side-by-side
- Quali runtime e strumenti servono per costruire estensioni su SAP BTP
- Come integrare, proteggere e distribuire le estensioni in sicurezza
- Come gestire governance e ciclo di vita durante la migrazione al cloud
- Da dove iniziare con il primo progetto di estensione su BTP
- Checklist di assessment prima di costruire un’estensione
- La lezione pratica dietro il clean core
- Supporto specialistico Greensharp per le tue estensioni SAP BTP
- Fonti
Cosa sono le estensioni SAP BTP e perché conta il clean core
Un’estensione su SAP BTP è codice o logica che aggiunge funzionalità a S/4HANA senza modificare gli oggetti standard del sistema. Esistono due famiglie: le estensioni in-app, gestite dai key user dentro il sistema stesso con strumenti low-code, e le estensioni side-by-side, che girano su un ambiente separato e comunicano con il core tramite API o eventi.
Il principio clean core nasce proprio per proteggere questa separazione. Un core pulito porta vantaggi concreti:
- Aggiornabilità: gli upgrade di S/4HANA non richiedono retest massivo del custom code.
- Riduzione del debito tecnico: meno modifiche dirette al codice standard significano meno rischio a ogni release.
- Riuso e governance: le estensioni diventano moduli tracciabili, assegnabili a un owner, versionabili separatamente.
Schematicamente: il core S/4HANA resta intatto al centro, le estensioni vivono su SAP BTP, e i due mondi parlano attraverso API ed eventi, mai attraverso modifiche dirette al codice ABAP standard.
Quale pattern di estensione scegliere: in-app, ABAP Cloud o side-by-side
Non tutte le esigenze richiedono un’architettura complessa. L’estensibilità in-app gestita dai key user resta utile per modifiche leggere: campi personalizzati, piccole regole di validazione, adattamenti di interfaccia. Usarla per progetti più ampi porta a sovraingegnerizzazione o, al contrario, a soluzioni fragili quando la logica cresce.
Quando la logica di business è più corposa ma resta vicina al dominio ERP, l’ambiente ABAP per SAP BTP con il pattern RAP (Restful ABAP Programming) è la scelta naturale. Permette di scrivere estensioni ABAP cloud-compliant sfruttando strumenti di qualità del codice già noti al team.
Per tutto ciò che è indipendente dal core, o che richiede stack tecnologici diversi (Node.js, Java, integrazioni con sistemi terzi), il pattern side-by-side è la strada più solida. Le estensioni side-by-side sono indipendenti dalla versione di S/4HANA e si basano su API remote o eventi, riducendo i costi di ogni futuro aggiornamento.
| Pattern | Quando usarlo | Runtime/tool | Impatto su clean core |
|---|---|---|---|
| In-app / key-user | Campi custom, piccole regole | Strumenti low-code integrati | Minimo, se contenuto |
| ABAP Cloud (RAP) | Logica vicina al dominio ERP | ABAP environment su BTP | Alto, se ben governato |
| Side-by-side (CAP/CF/Kyma) | Nuovi servizi, integrazioni esterne | CAP, Cloud Foundry, Kyma | Massimo, core resta intatto |
| SAP Build | Automazioni, app leggere | SAP Build Apps/Process Automation | Alto, nessun tocco al core |
La checklist rapida: se il team conosce ABAP e la logica riguarda processi core, si va su RAP. Se serve velocità di delivery e lo stack è web, si sceglie CAP. Se il progetto ha vincoli stretti su upgrade-safety, il side-by-side vince quasi sempre.
Quali runtime e strumenti servono per costruire estensioni su SAP BTP
Lo sviluppo su SAP BTP copre sia opzioni pro-code (CAP, ABAP environment) sia opzioni low-code/no-code (SAP Build Apps, SAP Build Process Automation), e coprono esigenze molto diverse tra loro.
- SAP BTP ABAP environment (RAP): sviluppo ABAP cloud-compliant, ideale per estensioni vicine ai processi ERP.
- CAP (Cloud Application Programming Model): framework per modellare dati e servizi in Node.js o Java, alla base della maggior parte dei progetti side-by-side.
- Cloud Foundry runtime: piattaforma applicativa gestita, adatta a chi vuole deployare senza gestire infrastruttura Kubernetes.
- Kyma runtime: preferibile per scenari cloud-native avanzati che richiedono operator pattern Kubernetes e integrazione con servizi esterni.
- SAP Build: copre app leggere, automazione di processo e integrazione con l’intelligenza artificiale generativa lato citizen developer.
- SAP Fiori/UI5: framework di interfaccia standard per esporre le estensioni con la stessa coerenza visiva del core.
Una combinazione tipica: CAP su Kyma per architetture event-driven con più microservizi, oppure RAP quando l’estensione deve restare aderente ai dati e ai processi già presenti nel sistema ERP.
Come integrare, proteggere e distribuire le estensioni in sicurezza
I pattern di integrazione più usati su BTP sono tre: OData per servizi CRUD, REST per integrazioni generiche e business events per architetture event-driven. Un service mesh entra in gioco solo quando il numero di microservizi cresce e serve gestione centralizzata del traffico.
Sul fronte sicurezza, tre pratiche fanno la differenza: gestione centralizzata delle credenziali (mai hardcoded), identity propagation tra estensione e core per non duplicare le autorizzazioni, e logging strutturato per intercettare anomalie prima che diventino incidenti.
Per CI/CD, una pipeline minima prevede test unitari sul modello dati CAP o RAP, test di integrazione contro un ambiente ERP di staging, e test end-to-end sull’interfaccia Fiori. Il rollback deve essere pianificato prima del primo deploy, non durante l’emergenza.
Un consiglio: automatizza il test delle API fin dal primo sprint: un’estensione side-by-side che rompe silenziosamente il contratto OData con il core è molto più difficile da diagnosticare di un errore lato interfaccia.
Come gestire governance e ciclo di vita durante la migrazione al cloud
Nella migrazione verso il cloud, un assessment approfondito serve a decidere quali estensioni spostare, quali sostituire con standard e quali riprogettare su BTP, evitando di portare debito tecnico dentro l’ambiente nuovo.
- Mappa tutte le estensioni esistenti e classificale per criticità e frequenza d’uso.
- Verifica quali funzionalità sono ormai coperte dallo standard S/4HANA.
- Decidi caso per caso: mantenere, riprogettare su BTP, o eliminare.
- Assegna un owner e uno SLA di manutenzione (AMS) a ogni estensione superstite.
Da evitare: il “lift and shift” del custom code esistente senza revisione. Molte aziende dovrebbero ripensare l’architettura invece di limitarsi a spostare la logica esistente, perché il side-by-side impone regole diverse rispetto al codice ABAP tradizionale. Meglio puntare su moduli riusabili con versioning esplicito.
Da dove iniziare con il primo progetto di estensione su BTP
Il primo passo pratico è aprire un account SAP BTP, scegliere il runtime coerente con lo stack del team e configurare l’ambiente di sviluppo, che sia SAP Business Application Studio per CAP o gli strumenti ABAP Cloud per RAP. Serve poi una connessione di test verso il sistema ERP per validare l’integrazione fin dai primi giorni.
Per la formazione, le learning journeys su “Building Side-by-Side Extensions on SAP BTP” guidano passo passo dalla creazione di un’app CAP fino al deploy con Fiori elements. La community SAP offre inoltre percorsi pratici per chi parte da zero con il side-by-side, utili per strutturare un primo proof-of-concept in poche settimane.
Checklist di assessment prima di costruire un’estensione
Un assessment preliminare solido è il passaggio che evita di portare debito tecnico in cloud, distinguendo ciò che copre già lo standard da ciò che richiede davvero un’estensione custom.
- Mappa dei processi coinvolti e requisiti funzionali documentati.
- Analisi dell’impatto sull’upgrade e sul clean core.
- Design preliminare delle API esposte e consumate.
- Profilo di sicurezza e gestione delle autorizzazioni.
- Assegnazione dei ruoli: business owner, solution architect, lead developer, security owner, devops.
Un consiglio: stima l’effort con un template semplice, ore per componente più un fattore di rischio tecnico, prima ancora di scegliere il runtime.
La lezione pratica dietro il clean core
L’esperienza sul campo dice una cosa semplice: chi protegge il core oggi risparmia mesi di rework a ogni major release. Le architetture side-by-side non sono una moda, sono la differenza tra un upgrade di un weekend e uno di tre mesi. I progetti che hanno adottato questo approccio riportano meno debito tecnico e cicli di manutenzione più prevedibili.
Supporto specialistico Greensharp per le tue estensioni SAP BTP
Progettare un’estensione side-by-side che regge nel tempo richiede più della scelta del runtime giusto: serve un assessment che distingua standard e custom, un’architettura pensata per l’upgrade, e un partner che segua il progetto dal design al supporto post-deploy. Greensharp lavora esattamente su questi tre livelli per i clienti del settore lusso e retail che devono estendere S/4HANA senza comprometterne la manutenibilità.
I servizi coprono l’intero ciclo: assessment BTP per capire cosa serve davvero estendere, progettazione architetturale con i Business Technology Architects, sviluppo di estensioni ABAP Cloud e CAP, integrazione e pipeline CI/CD, fino al supporto applicativo continuativo tramite SAP xAMS. Se stai valutando come impostare il primo progetto di estensione o vuoi capire se la tua architettura attuale rispetta il clean core, richiedi un assessment iniziale su Business Technology Architects e definisci insieme al team Greensharp la roadmap tecnica più adatta.
Fonti
Raccomandati
