App: il formato di estensione cloud-ready di Shopware 6

Le app sono il formato di estensione che Shopware 6 ha sviluppato per il cloud: girano al di fuori dello shop, comunicano con esso tramite API e webhook e, grazie agli App Script, portano comunque logica nella richiesta. I plugin classici, invece, girano come codice PHP all’interno dello shop.

Con Shopware 6.4, accanto ai plugin, Shopware ha introdotto un secondo formato di estensione. Un’app consiste essenzialmente in un file manifest.xml, che descrive che cosa l’app può fare e dove interviene, e facoltativamente in template, script, schemi di configurazione e moduli admin. Il codice lato server dell’app non gira nello shop, ma su un server del fornitore dell’app, che richiama lo shop tramite la Admin API.

Il motivo di questo design è il Shopware Cloud: in un ambiente condiviso non si può eseguire codice PHP di terzi. Le app rendono comunque possibili le estensioni, in un formato che funziona allo stesso modo nel cloud e negli shop in self-hosting.

• Esecuzione: i plugin girano come PHP all’interno di Shopware, le app all’esterno (più gli App Script nello shop).
• Accesso: i plugin raggiungono tutti i servizi Symfony, gli eventi e il database. Le app usano Admin API, Store API, webhook e servizi di script definiti.
• Hosting: i plugin richiedono uno shop in self-hosting. Le app girano anche nel Shopware Cloud.
• Linguaggio: i plugin sono in PHP. Il server di un’app può essere scritto in qualsiasi linguaggio.
• Permessi: le app dichiarano nel manifest a quali entità accedono; il merchant lo conferma all’installazione.
• Aggiornamenti: le app aggiornano manifest e script tramite lo Store, la logica del server in modo indipendente.

Un manifest.xml minimo contiene metadati, permessi e l’URL di registrazione:

LaMiaApp
La mia app
1.0.0
solution25


https://app.example.com/register


order
product

Altri elementi sono i moduli admin (pagine proprie nell’amministrazione tramite iframe), action button, endpoint di pagamento per metodi di pagamento propri, campi personalizzati, condizioni di regola, azioni del Flow Builder, template dello storefront e App Script.

All’installazione Shopware richiama l’URL di registrazione dell’app e scambia i secret; l’app riceve un accesso API dedicato per ogni shop. Da quel momento la comunicazione avviene in entrambe le direzioni: Shopware invia webhook al verificarsi di eventi, l’app legge e scrive tramite la Admin API. Ogni richiesta è firmata, così entrambe le parti possono verificarne la provenienza. Per il lato app Shopware mette a disposizione un SDK PHP e un bundle Symfony che gestiscono registrazione, verifica delle firme e client API.

• L’estensione deve essere offerta nello Shopware Store anche ai clienti cloud.
• La logica vive comunque in un sistema esterno, ad esempio un ERP, un fornitore di pagamento o un servizio di AI.
• Vuole distribuire e aggiornare in modo indipendente dalle versioni PHP e dai deployment di Shopware.
• Più shop devono usare lo stesso servizio, gestito centralmente.

Un plugin resta la scelta migliore quando la logica interviene a fondo su checkout, calcolo dei prezzi o modello dati, richiede prestazioni elevate o non si vuole gestire un’infrastruttura esterna. Maggiori dettagli nella nostra pagina sullo sviluppo di plugin Shopware, che offriamo anche a merchant in Italia.

• Ridurre al minimo i permessi: richiedere solo le entità di cui l’app ha davvero bisogno; i merchant vedono l’elenco all’installazione.
• Elaborare i webhook in modo idempotente: le consegne possono ripetersi; usare eventId per la deduplicazione.
• Ricaricare il payload: i webhook forniscono solo ID; recuperare lo stato attuale tramite la Admin API.
• Versionamento: gestire con cura la versione del manifest, evitare breaking change, documentare i percorsi di migrazione.
• Garantire l’operatività: il server dell’app è parte dello shop. Monitoraggio, backup e disponibilità fanno parte dell’offerta.

App Script, plugin, Extension SDK, estensioni dello Store e PaaS su Platform.sh. Tutti i termini nel glossario Shopware.