SAP Composable Storefront: architettura, vantaggi, limiti e quando serve

Lo SAP Composable Storefront (in precedenza Spartacus) è il frontend Angular di SAP per Commerce Cloud e la scelta raccomandata da SAP per i nuovi progetti. È una buona scelta predefinita, ma non automatica: richiede competenze Angular, cambia il modo di lavorare del team e aggiunge un livello di rendering lato server da gestire. Per molte aziende ne vale la pena; per alcune un frontend headless su misura o un’altra strada è più adatta.

Questa guida spiega che cos’è lo storefront, come funziona l’architettura, che cosa serve a un progetto prima di partire, quali sono i vantaggi e i limiti reali e come prendere la decisione.

In sintesi: il Composable Storefront è un’applicazione Angular che comunica con SAP Commerce Cloud esclusivamente tramite le API REST OCC, con rendering lato server, pagine gestite da SmartEdit e componenti B2B e B2C. È incluso nella licenza di Commerce Cloud. Conviene sceglierlo quando si vogliono i componenti e il percorso di aggiornamento di SAP e si hanno (o si costruiscono) competenze Angular; un frontend su misura in React o Next.js è preferibile quando contano di più la libertà di design o uno stack frontend esistente. Il vecchio Accelerator basato su JSP è deprecato e la sua rimozione è prevista per settembre 2027.

Che cos’è lo SAP Composable Storefront?

Il Composable Storefront è il frontend headless di SAP Commerce Cloud. Molti sviluppatori lo chiamano ancora Spartacus, dal nome del progetto open source da cui deriva. Dalla release 5.0 SAP distribuisce le librerie ufficiali come «SAP Commerce Cloud, composable storefront» e dalla versione 2211.19 la numerazione segue quella di Commerce Cloud (SAP Help: About Composable Storefront).

Che cosa lo caratterizza:

• Angular, con NgRx per la gestione dello stato. SAP porta lo storefront a una nuova versione principale di Angular una volta l’anno, a febbraio.
• Headless: comunica con Commerce Cloud esclusivamente tramite le API REST OCC.
• Guidato dal CMS: i layout delle pagine arrivano da SmartEdit invece che da template scritti nel codice.
• Rendering lato server (SSR) per i motori di ricerca e un primo caricamento rapido, oltre a funzioni di progressive web app.
• Licenza: inclusa nella licenza di Commerce Cloud. I clienti cloud installano le librerie dal repository di SAP; il codice sorgente resta aperto su GitHub.

Sostituisce lo storefront Accelerator, cioè i template JSP generati sui server applicativi di Commerce Cloud e strettamente legati al backend. SAP ha deprecato i template UI dell’Accelerator e ne ha pianificato la rimozione e la fine della manutenzione mainstream per settembre 2027, con un periodo di adozione esteso fino a settembre 2028 (SAP Help: Deprecation of Accelerator UIs).

Come funziona l’architettura?

Tre livelli con una chiara divisione dei compiti:

1. Backend Commerce Cloud: carrello, checkout, prezzi, ordini, gestione prodotti e ricerca, tutto esposto tramite API. (I livelli del backend sono descritti nella nostra panoramica su SAP Commerce Cloud.)
2. Livello API OCC: gli endpoint REST che lo storefront richiama per ricerca prodotti, carrello, checkout e gestione dell’account. Lo storefront non accede mai direttamente al database.
3. Composable Storefront: l’applicazione Angular nel browser o, per l’SSR, su un server Node.js. Genera l’interfaccia, mantiene lo stato lato client e richiama le API OCC.

Questa separazione permette di rilasciare il frontend indipendentemente dal backend, servire più frontend (web, app, chioschi) da un unico backend e, se necessario, sostituire del tutto il frontend.

Come funziona l’integrazione con il CMS

1. I responsabili dei contenuti creano in SmartEdit pagine con slot di contenuto (intestazione, corpo, piè di pagina, barra laterale).
2. Ogni slot contiene componenti CMS: banner, caroselli di prodotti, blocchi di testo, navigazione.
3. Lo storefront carica la struttura della pagina dall’API del CMS.
4. Ogni tipo di componente CMS è associato a un componente Angular che lo visualizza.
5. Le modifiche in SmartEdit compaiono nello storefront senza un nuovo deployment.

È questo che rende lo storefront «componibile» nella pratica: le pagine si compongono di elementi che il marketing controlla direttamente.

Le funzioni che contano nei progetti

• SSR: il server genera la prima pagina, poi subentra il browser. I crawler ricevono HTML completo, gli utenti un primo rendering rapido.
• Lazy loading: i moduli si caricano quando servono, quindi l’elenco prodotti non si porta dietro il codice del checkout.
• Internazionalizzazione: file di traduzione per lingua, cambio di lingua tramite URL o preferenza dell’utente.
• Estendibilità: i componenti SAP si sostituiscono con i propri tramite la dependency injection di Angular, senza modificare il codice sorgente di SAP. All’inizio sembra un vincolo, ma è ciò che mantiene gestibili gli aggiornamenti.

Che cosa serve a un progetto prima di partire?

Prerequisiti tecnici

• Un ambiente Commerce Cloud con gli endpoint OCC attivi per prodotti, carrello, checkout, CMS e utenti.
• Versioni di Node.js e Angular CLI compatibili con la release dello storefront (SAP documenta la compatibilità; va verificata prima di scrivere codice).
• Accesso al repository di SAP per le librerie dello storefront.

Prerequisiti del team

• Esperienza con Angular, TypeScript e RxJS. Non è negoziabile: team con esperienza React convinti che Angular fosse abbastanza simile hanno perso settimane solo su RxJS e dependency injection.
• Conoscenza dell’autenticazione OCC (OAuth 2.0).
• Accesso a Backoffice e SmartEdit per la configurazione del CMS.

Configurazione in cinque passaggi: creare l’applicazione con gli schematics di SAP; configurare URL del backend, base site, lingua e valuta; associare i tipi di componente CMS ai componenti Angular (le associazioni standard le fornisce SAP, i componenti propri ne richiedono di proprie); configurare l’SSR; infine personalizzare grafica e funzioni. La SAP Community offre una guida passo dopo passo all’installazione delle release 2211 attuali.

Gli errori più frequenti

• Versioni incompatibili tra librerie dello storefront e backend. Verificare prima la compatibilità; altrimenti si rischia di perdere uno sprint intero.
• SSR introdotto tardi. L’SSR incide su prestazioni, anteprime sui social e comportamento di caricamento. Va configurato dall’inizio; aggiungerlo dopo è faticoso.
• Contenuti scritti nel codice invece di componenti CMS, con deployment necessari anche per semplici modifiche.
• Tutto caricato subito. Va verificato quali moduli si caricano in anticipo; su mobile la differenza si fa sentire.
• Prima il desktop. I componenti propri vanno testati su mobile fin dall’inizio.

Il codice proprio va tenuto in moduli funzionali, override dei componenti tramite dependency injection, moduli condivisi e override di stile con CSS custom properties. SAP aggiorna lo storefront regolarmente, e un codice intrecciato con quello di SAP trasforma ogni aggiornamento in un progetto.

Quali sono i vantaggi reali?

Rilasci indipendenti. Un banner promozionale, una modifica al checkout o una correzione di rendering vanno online senza un rilascio completo della piattaforma; il frontend segue un proprio ritmo di rilascio mentre il backend resta stabile.

Flessibilità del frontend. Poiché lo storefront comunica con Commerce Cloud solo tramite API, si possono integrare componenti di altre fonti: configuratori di prodotto, visualizzatori 3D, chat.

SEO. Con l’SSR le pagine di prodotto e di categoria sono indicizzabili senza dipendere dal JavaScript lato client.

Autonomia sui contenuti. Il marketing gestisce i layout delle pagine in SmartEdit senza ticket per lo sviluppo.

Roadmap di SAP. Lo sviluppo degli storefront di SAP confluisce nel Composable Storefront, mentre i template Accelerator sono in via di dismissione.

Quali sono i limiti reali?

Dipendenza da Angular. Il team frontend deve conoscere Angular, TypeScript e RxJS. La maggior parte dei team SAP Commerce è orientata a Java, quindi vanno previste assunzioni o formazione. Uno sviluppatore Java di solito impiega diversi mesi per diventare pienamente produttivo con lo storefront; il modello a componenti e i pattern reattivi di Angular hanno poco in comune con lo sviluppo JSP.

Impegno iniziale maggiore. SSR, pipeline di build, deployment e mappatura CMS richiedono più lavoro rispetto a partire dai template Accelerator. Conviene prevedere qualche settimana in più.

Un ambiente di esecuzione in più. Il server SSR va distribuito, monitorato e mantenuto stabile sotto carico.

Più codice per piccole modifiche. Sovrascrivere componenti Angular e lavorare con NgRx richiede più codice che modificare un template JSP.

I componenti sono un punto di partenza. I componenti di SAP coprono i processi standard, ma raramente corrispondono al marchio così come sono. Per un design distintivo se ne sovrascrive una buona parte.

Come decidere?

Criterio	Composable Storefront	Headless su misura (React, Next.js)	Accelerator
Framework	Angular	A scelta	JSP (legacy)
Tempo per uno storefront standard	Da quattro a otto settimane	Più lungo: checkout, account e rendering CMS da costruire	Solo installazioni esistenti
CMS	SmartEdit, integrato	Contenuti SmartEdit o CMS esterno da integrare	SmartEdit
Supporto SAP	Storefront e API	Solo API	Deprecato, rimozione prevista per settembre 2027
Libertà di design	Media	Totale	Limitata

Il Composable Storefront è la scelta giusta se si parte da zero, si hanno sviluppatori Angular o si vuole costruire questa competenza, si vuole SmartEdit già integrato e si dà valore al percorso di aggiornamento di SAP.

Un frontend headless su misura è la scelta giusta se il team è forte in React o Next.js, il marchio richiede un design interamente personalizzato o si è già scelto un CMS esterno. Il nostro confronto dettagliato tra Composable Storefront e React/Next.js analizza questo compromesso. Da Distrelec, il disaccoppiamento del frontend da SAP Commerce tramite un livello API pulito ha ridotto il time-to-market del 70%.

Restare sull’Accelerator ha senso solo come fase di transizione, e il passaggio va pianificato ora. La nostra guida alla migrazione dall’Accelerator al Composable Storefront descrive un approccio graduale. Se la scelta dello storefront fa parte di un cambio di piattaforma più ampio, vale la pena leggere che cosa succede davvero in un’implementazione di Commerce Cloud o parlare con il nostro team SAP Commerce Cloud.

Domande frequenti

Qual è la differenza tra Spartacus e lo SAP Composable Storefront?

È lo stesso prodotto con un nuovo nome. Dalla release 5.0 SAP pubblica le librerie ufficiali di Spartacus come «SAP Commerce Cloud, composable storefront». L’architettura è la stessa e dalla versione 2211.19 la numerazione segue quella di SAP Commerce Cloud.

Il Composable Storefront ha un costo aggiuntivo?

No. È incluso senza costi aggiuntivi nella licenza di SAP Commerce Cloud. I clienti cloud ottengono le librerie dal repository di SAP; il codice sorgente resta open source su GitHub. A costare è il team frontend che costruisce e mantiene lo storefront.

Si può usare React o Next.js al posto di Angular?

Sì. Le API REST OCC sono indipendenti dalla tecnologia, quindi si può realizzare un frontend headless su misura con React, Vue o Next.js. Si rinuncia ai componenti di storefront già pronti di SAP, al rendering CMS predefinito e al percorso di aggiornamento di SAP, in cambio di piena libertà di design e tecnologia.

Accelerator e Composable Storefront possono funzionare in parallelo?

Sì. Durante una migrazione entrambi gli storefront possono lavorare sullo stesso backend Commerce Cloud, con il traffico instradato per URL o dominio. Conviene pianificare il passaggio: SAP ha deprecato i template UI dell’Accelerator e ne ha previsto la rimozione per settembre 2027.

Quanto tempo richiede la realizzazione di un Composable Storefront?

Uno storefront di base funziona in pochi giorni. Uno storefront B2C standard pronto per la produzione, costruito con i componenti SAP, richiede in genere da quattro a otto settimane, da otto a dodici con personalizzazioni importanti, e le funzioni B2B aggiungono da due a quattro settimane. Queste stime presuppongono un team che conosce già Angular.

Il Composable Storefront supporta il commercio B2B?

Sì. Le funzioni B2B comprendono gestione di organizzazioni e budget, flussi di approvazione, checkout con ordine d’acquisto, inserimento rapido degli ordini e carrelli salvati. I moduli B2B e B2C possono stare nello stesso build o in build separati, se le esperienze sono molto diverse.