In questo ultimo anno ho avuto la fortuna di lavorare in modo continuativo sulla piattaforma Magento per la delivery dei progetti e-commerce: è davvero molto potente, permette di far girare più siti multilingua contemporaneamente in un'unica istanza con logiche commerciali localizzate differenti e condividendo un unico catalogo centralizzato...insomma tanta robba :-D

Questo post inaugura una serie di contenuti dove raccoglierò alcuni aspetti strutturali di Magento che possono essere sicuramente utili a colleghi che come sono coinvolti in qualche modo nella gestione ed impostazione di un progetto e-commerce.

1- Definisci bene l'architettura di Website, Store e Storeview

Uno degli aspetti fondamentali è quello di conoscere la struttura dell'architettura Magento ed in particolare i diversi livelli di scope con cui è possibile definire la visibilità dei dati e delle funzionalità principali dell'e-commerce.

Entriamo un po' nel dettaglio. Gli scope in Magento sono 4:

a) Global:

E' lo scope più ampio dove le informazioni sono comuni per tutta l'architettura del sito indipendentemente dalla lingua, dalle politiche commerciali, dalle tipologie di metodi di pagamento, ecc.

L'esempio classico di variabile global è lo SKU di un prodotto, infatti il codice identificativo del prodotto è sempre identico a seconda che il prodotto sia venduto in Italia o in America o che sia con una scheda prodotto a lingua inglese o italiana.

Un altro esempio è lo stock che, senza particolari customizzazioni del core, ad oggi è unico per ogni prodotto: Magento quindi nella sua versione nativa non permette la gestione multi stock e multi magazzino poichè lo stock è un dato con scope global.

b) Website:

Il website è il secondo livello di visibilità e raccoglie le informazioni tipiche per la costruzione di un sito unico e indipendente. La visibilità a livello di website può essere legata a:

• il metodo di pagamento;
• la valuta di acquisto e transazione (chiamata in Magentese base currency);
• i prezzi dei prodotti;
• le regole di definizione di promozioni sia a catalogo che a carrello;
• una customer base separata da un altro website;

c) Store:

Lo store, invece, ha principalmente la caratteristica di garantire una piena personalizzazione dell'albero di catalogo: all'interno di ogni singolo store di un'istanza Magento può essere definita una struttura ad hoc di categorie e la relativa visibilità dei prodotti appartenenti al catalogo.

d) Store View:

La store view definisce in gran parte del front-end del sito e-commerce e quindi la parte di layout e template con cui l'utente finale interagisce.

A livello di store view possono essere definite:

• le valute con cui l'utente può visualizzare i prezzi dei prodotti (display currency) che però sono definiti nel valore a livello di website;
• la lingua del sito;
• il nome e la descrizione dei prodotti;
• ecc.

Perchè un PM e-commerce dovrebbe conoscere gli scope?

Una gestione consapevole dei livelli degli scope permette di gestire al meglio un progetto senza sorprese dell'ultimo minuto evitando rework inutili di aspetti strutturali.

Due esempi su tutti:

Le promozioni e le regole di sconto possono essere definibili in maniera granulare a livello di "website". Pertanto se si vogliono applicare delle politiche commerciali diverse per 2 nazioni (sconti/promozioni), è necessario che queste nazioni sebbene condividano lo stesso database di prodotti siano all'interno di due store view differenti.

Se voglio avere un sito in 5 lingue con 10 politiche commerciali diverse, sono costretto ad avere ben 50 store view diverse. Questo significa la necessità di disporre di un'infrastruttura server molto più complessa e sovradimensionata, senza contare l'impatto drammatico sui tempi di gestione dello store. Insomma, se un cliente vuole avere molte combinazioni di lingue e mercati, beh tentate di dissuaderlo e farlo rinsavire. :-)

2- Struttura del database: il modello EAV

La classica struttura di tabella prodotti per il database di un e-commerce che tutti hanno in mente è quella dell'immagine sottostante, ovvero una bella tabellona dove ciascun prodotto ha una serie di attributi definiti serie ed in modo leggibile.

Magento ha una struttura diversa definita come modello EAV (l'acronimo di Entity, Attribute e Value) ed è composta da 3 elementi:

• l'Entity è l'oggetto che si desidera descrivere attraverso il database (nel caso di un e-commerce potrebbero essere ordini, clienti, prodotti, ecc.);
• l'attributo è la proprietà dell'entità (ad es. il prezzo, il nome del prodotto, l'indirizzo e-mail di un cliente, ecc.) ;
• il valore è il valore che assume l'attributo per la singola entità (ovvero € 200.00, oppure "tavolo in legno massiccio").

Facciamo un esempio per capire meglio come funziona il modello EAV: ipotizziamo di descrivere due palloni da calcio con 3 principali dimensioni che lo descrivono: Nome, Prezzo e Valuta.

I palloni sono due: uno Nike ed uno Adidas, uno che costa 60 € ed uno che costa 80€.

L'entità che desideriamo descrivere è un prodotto, pertanto la tabella entity che avrà il solo record "prodotto".

Lo svantaggio di questa struttura è che richiederebbe molto tempo computazionale perché il database riesca a raccogliere e consolidare tutti gli attributi relativi ad un prodotto/cliente/ordine/categoria/ecc.: eseguire delle join in maniera così massiccia sarebbe sicuramente molto dispendioso. Di base quindi la struttura dell'EAV funziona per il risparmio nei dati e scalabilità ma peccherebbe di performance nella velocità di accesso ai dati, specie per richieste concorrenti.

Per questo esistono Magento prevede una funzionalità detta di "re-index: si tratta di operazioni a livello di database che si occupano di accorpare i dati in diverse "flat table", che permettono di costruire una struttura dati ausiliaria di veloce accesso, una sorte di cache di database.

Le flat table che costruisce Magento sono legate alle informazioni di più frequente accesso e dispendiose come ad esempio: i dati delle schede prodotto, della riscrittura delle URL, ecc.

La flat table non viene aggiornata ad ogni modifica eseguita da backend ai prodotti. Questo può avere delle conseguenze "disastrose" se ad esempio cambio il prezzo di un prodotto, poichè non è detto che i miei utenti lo vedano corretto.

Quindi ad ogni modifica importante sarebbe necessario eseguire un "reindex".

Dico "sarebbe" perchè le operazioni di "reindex" possono essere piuttosto "stressanti" per il database, pertanto è necessario pensare ad una vera e propria strategia per il re-index.

La strategia dipende da:

• quanto spesso avvengono aggiornamenti su prodotti e categorie;
• qual'è la dimensione dei dati all'interno del database;
• quanto è il carico sul server in termini generali e a seconda delle diverse fasce orarie.

Dopo aver analizzato le necessità si capirà se vale la pena optare per un aggiornamento in automatico dei dati durante gli orari "a basso carico" oppure se optare per un reindex manuale valutando di volta in volta il momento migliore.

In ogni caso per una re-index strategy serve :

• avere una grande condivisione e consapevolezza da parte del cliente;
• una conoscenza dei processi di aggiornamento dell'e-commerce;
• disporre di una pianificazione commerciale e di una definizione di regole;
• non pensare alla comodità degli isterismi, ma pensare alle performance ed alle vendite.

3- Qualche risorsa utile:

Concludo il primo post con qualche risorsa utile:

• How Multiple Websites & Stores Work: un esempio pratico di configurazioni Website, Store e Storeview;
• Magento Database Diagram, che mostra nel dettaglio la complessità dell'architettura del database e l'applicazione pratica del modello EAV descritta sopra;
• un video che raccoglie alcuni consigli utili ai PM per la gestione di un progetto con Magento - Presentazione svoltasi al Magento Live UK 2014.