Architettura MACH in SAP Commerce Cloud: cosa significa nella pratica

MACH sta per Microservices, API-first, Cloud-native e Headless. Su una slide sono quattro riquadri. In un progetto sono scelte concrete, e SAP Commerce Cloud tratta ciascuno dei quattro principi in modo diverso. Sapere dove passa il confine evita di prendere decisioni architetturali sulla base delle slide dei fornitori.

In breve: Commerce Cloud è un ibrido. Tre principi sono integrati, il quarto arriva tramite estensioni.

In sintesi: SAP Commerce Cloud soddisfa API-first (API REST OCC), cloud-native (una piattaforma gestita da SAP per voi) e headless (Composable Storefront o qualsiasi frontend personalizzato). Il backend è un’unica applicazione Java, quindi non è basato su microservizi; SAP raccomanda di realizzare la nuova logica personalizzata come estensione side-by-side su SAP BTP. Per la maggior parte dei progetti B2B questo ibrido basta. Puntate su API-first e headless, date il cloud-native per acquisito e aggiungete microservizi solo dove un requisito specifico li richiede.

Cosa significa MACH?

MACH riunisce quattro principi promossi dalla MACH Alliance:

• Microservices: logica di business suddivisa in piccoli servizi distribuibili in modo indipendente
• API-first: ogni funzione esposta tramite API ben definite prima di qualsiasi interfaccia utente
• Cloud-native: progettato per l’esercizio in cloud, con scalabilità automatica, resilienza e servizi gestiti
• Headless: frontend disaccoppiato dal backend, comunicazione solo tramite API

Non è un tutto o niente. Una piattaforma può essere forte su alcuni principi e più debole su altri. Conta quale combinazione vi serve, più di qualsiasi marchio sul sito di un fornitore. Per la domanda di business su quando valga la pena comporre servizi specializzati, leggete la nostra guida al composable commerce nel B2B.

M come microservizi: un ibrido

Il backend di Commerce Cloud è un’unica applicazione Java. Carrello, checkout, calcolo dei prezzi, ricerca e gestione degli ordini girano nello stesso processo, e la piattaforma si distribuisce come un’unità, non modulo per modulo.

I microservizi compaiono tutt’intorno:

• Estensioni side-by-side su SAP BTP. È l’approccio raccomandato da SAP per la nuova logica personalizzata: realizzarla come servizio autonomo su SAP BTP (runtime Kyma o Cloud Foundry) e richiamarla tramite API, invece di estendere il nucleo.
• Servizi di terze parti. Pagamenti, imposte, ricerca o personalizzazione girano come servizi indipendenti richiamati da Commerce Cloud.

Nella pratica non potete distribuire i moduli commerce singolarmente, ma ottenete estensibilità tramite servizi esterni. Per la maggior parte delle implementazioni B2B basta, e il nucleo unico ha un vantaggio: prezzi contrattuali, promozioni e flusso degli ordini restano coerenti in un unico punto. Quando il nucleo ha davvero limitato un progetto, nel nostro lavoro la risposta è stata ogni volta la stessa: realizzare quella specifica funzione su BTP accanto a Commerce Cloud.

A come API-first: il principio più forte

Le API REST OCC (Omni Commerce Connect) espongono prodotti, categorie, carrelli, checkout, ordini, clienti, ricerca e contenuti CMS. Il Composable Storefront comunica con Commerce Cloud esclusivamente tramite queste API, la prova migliore che sono abbastanza complete per gestire un intero shop. SAP documenta l’architettura OCC basata su estensioni su SAP Help.

Cosa rende questo livello utilizzabile nei progetti:

• ampia copertura delle operazioni commerce, B2B compreso
• estensibile: endpoint personalizzati si aggiungono con estensioni proprie
• specifiche OpenAPI e autenticazione OAuth 2.0
• qualsiasi tecnologia frontend può utilizzarlo

Un limite: alcune attività di amministrazione e configurazione richiedono ancora il Backoffice. Le API sono pensate per il commerce, non per l’amministrazione completa del sistema.

C come cloud-native: gestito da SAP

SAP Commerce Cloud gira su un’infrastruttura gestita da SAP per voi. In pratica significa:

• scalabilità automatica in base al traffico
• una CDN integrata per contenuti statici e media
• deployment tramite Cloud Portal, senza accesso diretto ai server
• ambienti predisposti separatamente e artefatti di build immutabili
• log e metriche nel portale
• patch di sicurezza e update release cumulative fornite da SAP

Il prezzo è il controllo. Non potete scegliere il motore di database, regolare la JVM oltre quanto SAP consente né usare regioni che SAP non offre. Per la maggior parte dei carichi commerce è irrilevante, per alcuni casi particolari no. Da quando la manutenzione ordinaria del prodotto on-premise è terminata il 31 luglio 2026 (SAP Help), per SAP Commerce la strada è il cloud; il nostro articolo su cosa fare ora che il supporto on-premise è terminato presenta le opzioni.

H come headless: integrato

Il Composable Storefront (in precedenza Spartacus) è il frontend headless di SAP basato su Angular (SAP Help). Comunica con Commerce Cloud solo tramite OCC, e storefront e backend si distribuiscono in modo indipendente: rilasciate un aggiornamento Angular senza toccare il backend Java.

Cosa permette l’headless:

• qualsiasi framework frontend (Angular, React, Vue, Next.js)
• le stesse API per web, app mobili, chioschi e portali partner
• rilasci dello storefront indipendenti da quelli del backend
• rendering lato server per velocità e motori di ricerca

Spesso trascurato: anche in modalità headless, SmartEdit continua a gestire la composizione delle pagine. I responsabili dei contenuti creano pagine, slot e componenti in SmartEdit e il Composable Storefront li visualizza. Il marketing modifica i layout senza sviluppatori. Se preferite React o Next.js, il nostro confronto Composable Storefront o React/Next.js spiega i compromessi. Distrelec è un riferimento per la via headless: dopo che abbiamo disaccoppiato il suo frontend, il time-to-market delle modifiche frontend è sceso del 70%.

Conviene adottare MACH al completo?

Non necessariamente. MACH è un insieme di principi, non un credo. La domanda utile è quali principi risolvono i vostri problemi specifici.

API-first e headless valgono quasi sempre la pena. Offrono libertà nel frontend e una strategia di integrazione pulita, anche verso l’ERP.

Cloud-native per SAP Commerce è ormai un dato di fatto.

I microservizi sono il campo in cui il pragmatismo conta di più. Il backend unico funziona bene per la maggior parte delle implementazioni. Se per una funzione vi servono deployment indipendente o archivi dati separati, realizzatela su BTP accanto a Commerce Cloud. Non cercate di smontare la piattaforma stessa.

Se state valutando altre piattaforme, il nostro confronto tra SAP, Salesforce e Adobe Commerce mette a confronto le architetture. Oppure parlate con i nostri architetti commerce della vostra configurazione.

Domande frequenti

SAP Commerce Cloud è una piattaforma MACH?

In parte. Soddisfa bene tre principi su quattro: API-first tramite le API REST OCC, cloud-native come piattaforma gestita da SAP e headless tramite il Composable Storefront o un frontend personalizzato. Il backend è un’unica applicazione Java, quindi non soddisfa il principio dei microservizi; la risposta di SAP sono le estensioni side-by-side su SAP BTP.

Qual è la differenza tra MACH e composable commerce?

MACH descrive come è costruita la tecnologia: microservizi, API prima di tutto, esercizio cloud-native, frontend disaccoppiato. Il composable commerce è la strategia di comporre servizi specializzati in un’unica piattaforma commerce. Per un’architettura composable servono componenti di tipo MACH, ma usarli non vi rende automaticamente composable.

Posso costruire un frontend non Angular su SAP Commerce Cloud?

Sì. Le API OCC sono endpoint REST indipendenti dalla tecnologia, quindi React, Vue, Next.js o Svelte funzionano quanto il Composable Storefront di SAP basato su Angular. Rinunciate ai componenti di storefront predefiniti di SAP e ottenete il pieno controllo del frontend, manutenzione compresa.

L’architettura MACH migliora le prestazioni?

Può farlo. Un frontend headless consente il rendering lato server e il caching sull’edge, e una piattaforma cloud gestita scala con il traffico. Il rischio è una scomposizione eccessiva: molti servizi che si richiamano a vicenda aggiungono latenza che una piattaforma unica ben ottimizzata evita. Misurate i percorsi d’acquisto importanti prima e dopo ogni modifica.

Adottare MACH cambia i costi di SAP Commerce Cloud?

La licenza della piattaforma non dipende dall’architettura scelta. I costi di implementazione e di esercizio sì: servizi propri su SAP BTP o un frontend personalizzato aggiungono lavoro di sviluppo e manutenzione. Per molti progetti la piattaforma standard con il Composable Storefront è l’avvio più economico.