Capita quando bisogna sviluppare un’applicazione web/mobile di dover richiedere delle informazioni tramite delle API, l’ideale sarebbe avere già a disposizione questa risorsa prima di poggiare penna sul foglio per progettare l’applicazione. Purtroppo non siamo in un mondo ideale e la risorsa quasi mai risulta già sviluppata. (Se non avete problemi di questo tipo:

scendi giù e facci conoscere la tua esperienza)

Beh potremmo aspettare: inviamo email con un intervallo di polling di 30 secondi a chi ci deve fornire le API e lo pressiamo per ricevere aggiornamenti sullo sviluppo. Astuto no?

Oppure, anche se la prima risposta ci piace, possiamo tirar su un server di testing per simulare le nostre bramate API Rest.

Si va bene, “tirar su un server di testing…” meglio aspettare lo sviluppo delle API. Sarebbe noioso partire da zero e implementare la seconda soluzione, ma la community ci mette a disposizione tool che permette di farlo con un semplice JSON.

Il tool che suggeriamo in questo caso si chiama Json-Server, scaricabile tramite il repo git:

Scrivendo un solo file json e dandolo in pasto al tool possiamo tirare su le nostre API che permettono di usare i metodi http: POST, PUT, PATCH e DELETE; inoltre sono gestiti anche delle preziose feature come: i filtri, l’ordinamento, la paginazione, etc. li trovate tutti nella documentazione del modulo.

Vediamolo un po’ in funzione, Json-Server lo si può importare sia a livello globale sia nella directory dove aggiungeremo il nostro db, noi lo inseriremo nel progetto e lo vediamo subito.

Creiamo la nostra cartella del nostro server e aggiungiamo il modulo tramite un package manager, per questo esempio usiamo yarn ma anche npm va bene.

mkdir articleJsonServer
cd articleJsonServer
yarn init

compiliamo i vari campi richiesti e aggiungiamo la nuova risorsa al progetto

yarn scaricherà json-server nella cartella node_modules e lo aggiungerà come risorsa nel file package.json. Siamo quasi pronti ad avviare il nostro server con le nostre nuove API.

Controlliamo se è vero chiamando l’help del tool:

~ node_modules/json-server/bin/index.js --help

L’output utilizzato sopra ci mostra che il CLI di Json-Server funziona e quali sono le opzioni utilizzabili dal tool. (tra le opzioni è presente il delay nella risposta, molto interessante da poter testare con la nostra applicazione che svilupperemo)

Il passo successivo da eseguire è la creazione del nostro db in json, che definirà le risorse e i contenuti. Aggiungiamo il file db.json alla root del progetto (oppure dove meglio credete) e editatene il contenuto.

Noi come esempio metteremo un json con prodotti e categorie molto semplici:

Niente di trascendentale, ma voi potete dare sfogo alla fantasia se volete qualcosa di più articolato, di normalizzato (preferibilmente) o qualunque altra cosa vi possa servire. Inoltre è possibile usare Faker (o altre alternative) per generare attributi casuali in maniera molto veloce, esportando un oggetto tramite un file js e dandolo in pasto al nostro CLI al posto del file JSON.

Una volta stabilito il json abbiamo finito i compiti difficili (ricordiamoci che bisogna sempre mettersi d’accordo con il team che svilupperà le API reali, non facciamo il lavoro due volte)

Avviamo il nostro server dal terminale chiamando

~node_modules/json-server/bin/index.js db.json --watch

Le nostre risorse sono elencate sotto l’apposita voce e la home indicata è un’utile interfaccia di recap del nostro json-server. Il parametro watch aggiunto ci è utile per vedere in tempo reale le modifiche fatte al db, in particolare quando chiamiamo una risorsa che modifica o aggiunge elementi al json questa viene salvata sul file e le richieste successive restituiscono il risultato aggiornato senza riavviare il server.

Vogliamo fare una prova? Aggiungiamo un nuovo prodotto con postman, REST client suggerito da 

primi passi con l'utilizzo delle api di magento 2

Eseguiamo una chiamata POST all’endpoint dei prodotti, inserendo nel body della richiesta il json da aggiungere al db:

l’oggetto verrà aggiunto al nostro db e restituito nella chiamata POST effettuata.

Effettuando il GET sulla risorsa otterremo l’insieme di tutti i nostri prodotti aggiornati inclusi nel file json.

Non ci abbiamo messo molto a tirar su il nostro server di test funzionante, con questo possiamo iniziare lo sviluppo della nostra app senza indugiare sulle API mancanti.

L’esempio fatto è relativamente semplice, con il CLI di json-server possiamo aggiungere altre opzioni, quelle che abbiamo visto con –help per personalizzare: route, host, port, etc. Segnaliamo anche un altro repository su github con un wrapper del tool su gulp: 

 che consente di definire un task con alcune opzioni di json-server, senza dover scrivere il comando intero da zero ma inserendo tutte le info nel file gulp.

In questo articolo abbiamo visto un ottimo tool: Json-Server; per iniziare a sviluppare una nuova applicazione senza dover aspettare l’endpoint delle API REST. Con questo possiamo avvantaggiarci sui lavori da svolgere e testare l’applicazione legandola ad un server che fa il mockup dell’endpoint reale.

API REST per TEST

Migrare i dati dalle precedenti versioni di Magento al nuovo Magento 2 è un tema molto richiesto nella community, molte persone cercano consigli, suggerimenti e recensioni sull’uso del tool sviluppato e mantenuto nel


 (anche il team di Magento chiede a chi ha usato il tool di compilare un sondaggio per conoscerne i pareri e suggerimenti). In questo articolo ci occuperemo di scoprire, installare e dare qualche consiglio su questo strumento, così da avere una panoramica per utilizzarlo e avere qualche suggerimento da poter seguire. Non daremo spazio all’intero processo di porting di un ecommerce alla nuova piattaforma; migration plan, moduli proprietari, personalizzazioni e i temi sono tutti parte della guida alla migrazione che potrete trovare 

Come anticipato nell’introduzione, ci occuperemo della migrazione dei dati, ovvero giocheremo solo con i database dei nostri Magento, perciò come regola generale “diamoci dentro con le copie di sicurezza dei db”.

Come prerequisiti per questo articolo dovremmo avere un’installazione di base (funzionante) di Magento 2 e l’accesso ai database di Magento 1 e 2.

Nota: Personalmente per lo sviluppo della configurazione da usare nella mia migrazione ho preferito importare il database di Magento 1 sullo stesso DBMS di Magento 2, questo perché essendo su un’altra macchina avrei aggiunto dei tempi di esecuzione in più a discapito dello sviluppo.

Per prima cosa procuriamoci il tool da utilizzare nella nostra installazione. Per farlo ci basta seguire la 

. Da tener presente che ogni versione di Magento 2 può avere la sua versione di migration-tool, questo è dovuto alle modifiche fatte durante i vari upgrade dei moduli.

Io ho preferito installarlo tramite il repo github aggiungendo la dipendenza al file composer.json. Una volta installato potete verificare se è presente il comando migrate nell’output di bin/magento

$ bin/magento | grep migrate
migrate
 migrate:data                              Main migration of data
 migrate:delta                             Migrate the data is added into Magento after the main migration
 migrate:settings                          Migrate system configuration


Iniziamo a vedere l’organizzazione del modulo per farci un idea più precisa di come lavorare con il tool.

L’unica cartella realmente utilizzata da noi per effettuare la migrazione è 

 noterete subito le 3 sottocartelle dove dovrete scegliere il tipo di edizione a cui migrare partendo dalla vostra attuale. Passare alla community edition (CE) o alla enterprise edition (EE) non è l’unica scelta da fare, all’interno della cartella scelta troverete un’ulteriore diramazione dovuta a tutte le versioni di magento 1.X da qualche può essere eseguita la migrazione.

Supponiamo di partire da una Magento CE 1.9.1.0 e vogliamo migrare alla CE di Magento 2 sappiamo che dovremmo utilizzare i file presenti nel tool sotto


La guida di Magento 2 suggerisce di rinominare il file config.xml.dist per effettuare le dovute modifiche da utilizzare per la propria migrazione. Personalmente non ci piace molto l’idea di modificare/aggiungere un file all’interno di vendor di un namespace non nostro, così opteremo per creare all’interno di una differente cartella la struttura e i file necessari per poter proseguire.

Per la nostra prima migrazione abbiamo usato la cartella 

 per ospitare tutte le modifiche, ma per quelle future useremo un nuovo repository da importare con composer.

Seguendo sempre l’abitudine di conservare la struttura delle cartelle ci ritroviamo ad avere il nostro primo file per la migrazione così:

Aprendo il file config.xml come prima passo dovremmo sistemare il link al xsd.

e seguendo la struttura delle cartelle diventerà:

../../../../../vendor/magento/data-migration-tool/etc/config.xsd

Si è un po lungo, ma non possiamo usare l’urn come abbiamo visto nell'

 perché il tool non è né un modulo Magento né tanto meno appartiene al framework (arrangiamoci con questo, e ricordiamo che se creiamo un repository per la vendor dovremmo ulteriormente modificare questo path).

Il secondo passo da fare è cambiare i dati di accesso al database, aggiungere il prefisso se gestito da Magento1 e/o Magento2 ed inserire la crypt key che potete trovare nel file local.xml dell’installazione dei Magento1.

<source>
    <database host="127.0.0.1" name="db_magento1" user="mysqluser" password="mysqlpassword"/>
</source>
<destination>
    <database host="127.0.0.1" name="db_magento2" user="mysqluser" password="mysqlpassword"/>
</destination>
<options>
    <source_prefix>mage1prefix_</source_prefix>
    <dest_prefix>mage2prefix_</dest_prefix >
    ...
    <crypt_key>qwerty1234567890</crypt_key>
    ...
</options>
...

Le modifiche fatte fin ora al file config.xml permettono di migrare un installazione di Magento1 a Magento2 a condizione che non ci siano personalizzazioni. Se volete, potete provare a migrare un installazione di Magento1 con i sample data chiamando

$ php bin/magento migrate:data dev/magento2-migration-tool/etc/ce-to-ce/magento1.9.1.0/config.xml

Il comando riceve in input il file di config da utilizzare, una volta dato l’invio vedrete piano piano migrare tutti i data nel nuovo Magento2.

I tre nuovi comandi del tool di migrazione consentono di eseguire 3 distinte operazioni sul nostro database, queste sono chiamate 

Ognuno di questi mode è a sua volta diviso in 

, questi descrivono l’ordine di esecuzione dei passi per eseguire la migrazione nel mode richiesto. Nello specifico ogni step si occupa della migrazione di una unità logica all’interno di Magento 2, come possono essere le tabelle dei clienti o degli ordini.

Ogni step può essere composto a sua volta da 

La composizione di mode, step e stage la possiamo vedere nel file config.xml:

<steps mode="settings">
    <step title="Settings Step">
        <integrity>Migration\Step\Settings\Integrity</integrity>
        <data>Migration\Step\Settings\Data</data>
    </step>
    ...
</steps>
<steps mode="data">
    <step title="EAV Step">
        <integrity>Migration\Step\Eav\Integrity</integrity>
        <data>Migration\Step\Eav\Data</data>
        <volume>Migration\Step\Eav\Volume</volume>
    </step>
    ...
</steps>
<steps mode="delta">
    <step title="Customer Attributes Step">
        <delta>Migration\Step\Customer\Delta</delta>
        <volume>Migration\Step\Customer\Volume</volume>
    </step>
    ...
</steps>

Qui possiamo intervenire modificando gli step e aggiungendone dei nuovi a seconda delle nostre personalizzazioni

Note: Nei prerequisiti abbiamo fatto notare che per lo sviluppo abbiamo preferito avere i due db sullo stesso DBMS, ma è opportuno (una volta terminato lo sviluppo) effettuare la migrazione dal database di produzione. Questo perché l’esecuzione del mode data inserisce delle nuove tabelle e trigger all’interno di magento1 per popolarle durante il periodo di transazione dalla prima versione alla seconda. Le “operazioni” effettuate dopo la prima migrazione dei dati saranno importate nel nuovo Magento2 con l’esecuzione della migrazione con mode delta.

Come abbiamo fatto notare prima, con la sola aggiunta delle informazioni dei database potremmo migrare un Magento 1 con i sample data senza problemi, mentre per poter effettuare la migrazione delle installazioni personalizzate abbiamo bisogno di effettuare altre modificare. È possibile intervenire sulla migrazione modificando i file xml dichiarati all’interno del file config.xml.

Per questo articolo vedremo solo due esempi di modifica dei file xml: setting.xml e map.xml.

Quando abbiamo eseguito la prima volta la migrazione dei settings abbiamo notato un incredibile rallentamento di Magento2, questo era dovuto alla grande mole di configurazioni portata all’interno del database.

Quindi uno dei primi file che abbiamo dovuto modificare è stato settings.xml, per rimuovere tutti le configurazioni non più indispensabili nel nuovo ecommerce. Anche per questa modifica abbiamo preferito copiare il file in una nuova posizione al posto di modificare quello esistente.

Le modifiche che si possono effettuare permettono di aggiungere tre diverse tipologie di tag:

Se ad esempio volessimo ignorare tutte le config del tema, ci basterebbe aggiungere la nuova regola prendendo d’esempio una già inserita e modificando il relativo path della config:

<ignore>
    <path>design/theme/*</path>
 </ignore>

Una volta capito come aggiungerne una, possiamo andare avanti con l’aggiunta di tutte le vecchie config che non ci servono e che occuperebbero solo spazio inutile. Una volta terminate le modifiche al file, è importante dichiarare il suo path nel config.xml. Nel nostro caso modificheremo 

<options>
    ...
    <settings_map_file>../../../dev/magento2-migration-tool/etc/ce-to-ce/magento1.9.1.0/settings.xml</settings_map_file>
    ...
</options>

Lo stesso può essere fatto per il file del map.xml che si occupa della migrazione della maggior parte dei dati. Qui le operazioni possibile sono molte di più ed è possibile vederle nella 

. Come per settings.xml rivediamo il tag ignore che permette di ignorare sia tabelle che colonne.

Per aggiungere una regola di ignore in questo file è necessario tener conto di entrambi i database, quello sorgente e destinazione. Ad esempio se volessimo ignorare la tabella 

<source>
    <document_rules>
        <ignore>
            <document>newsletter_subscriber</document>
        </ignore>
        ...
    </document_rules>
    ...
</source>
<destination>
    <document_rules>
        <ignore>
            <document>newsletter_subscriber</document>
        </ignore>
        ...
    </docuemnt_rules>
    ...
</destination>

L’aggiunta in entrambi i punti è necessaria perché il controllo sui database restituirebbe un errore per la mancata gestione della tabella.

Suggeriamo in questo file l’aggiunta di una regola di trasformazione per risolvere un bug non ancora gestito dal tool ma 

. Il bug in se non blocca l’esecuzione della migrazione ma inserisce un dato errato all’interno di Magento2, in particolare riguarda l’attributo 

 salvato nella colonna value della tabella 

. La regola da aggiungere è la seguente:

...
<transform>
    <field>catalog_product_entity_varchar.value</field>
    <handler class="Bitbull\MagentoPatch\Handler\Catalog\Product\Attribute\Type\Price\ConvertMsrpPriceType"/>
</transform>
...

\Magento\Msrp\Model\Product\Attribute\Source\Type\Price::TYPE_USE_CONFIG

 uguale a 0 mentre la stessa costante ha valore 4 in Magento 1 ed è questo il valore che viene importato erroneamente.

La nostra trasformazione permette di sostituire il valore inesistente al corretto valore della costante. Potrete vedere il codice della classe nel 

, dove si evince che la trasformazione di questo attributo deve controllare tutte le righe della tabella per verificare quale riga rappresenta l’attributo 

Noi abbiamo provato il tool per migrare una versione 1.9.1.0 sulla versione 2 di Magento, funziona decisamente bene e si presta in modo positivo alle modifiche fatte sugli ecommerce esistenti.

Logicamente non permette di portare le personalizzazioni sviluppate sulla prima versione, e se queste non devono essere integrate possiamo escluderne in modo semplice e veloce le tabelle e/o colonne interessate.

Il tool presenta sicuramente altri bug oltre quelli risolti, quindi aiutiamo la comunità e, come nel nostro caso, segnaliamo e nel caso proviamo a risolverli.

Migrazione dati da Magento 1 a Magento 2

Nel mondo delle piattaforme di ecommerce open-source Magento è una soluzione che garantisce sicurezza e affidabilità; la sua natura open-source ha permesso lo sviluppo da parte di terzi dei moduli per personalizzare il normale comportamento della piattaforma. Se seguono le opportune logiche di strutturazione, i moduli vengono integrati autonomamente nel sorgente di Magento. Questo ci consente di integrare il nostro codice nel normale flusso di controllo.

La logica di strutturazione dei moduli è il motivo di questo articolo. Con l’avvento di Magento 2 dobbiamo armarci di tutte le nostre conoscenze e andare alla scoperta del nuovo framework.

In questo articolo vedremo la struttura di base dei moduli su Magento 2 e lo faremo con l’aiuto di un esempio; creeremo un modulo che non fa nulla di che se non essere “visto” da Magento 2.

Diamo per scontato di avere a disposizione un installazione di Magento 2, nel caso è possibile trovare informazioni a riguardo sulla  

Per creare un nuovo modulo su Magento 2 è necessario creare due file 

. Se supponiamo di voler creare il modulo 

, una volta stabilito il Namespace (il nostro sarà 

) ci basta creare la seguente struttura nel progetto

Magento 2 non utilizza più il code pool (community, core e local) come sulla precedente piattaforma, tutti i moduli dei vari vendor vengono inseriti all’interno di 

 creato va dichiarato il tipo di componente sviluppato; le possibili dichiarazioni utilizzabili sono presenti come costanti nella classe 

\Magento\Framework\Component\ComponentRegistrar

Noi dobbiamo dichiarare un modulo e nel file 

<?php
use \Magento\Framework\Component\ComponentRegistrar; 
ComponentRegistrar::register(
ComponentRegistrar::MODULE,
    ‘Bitbull_Example’,
    __DIR__
);

In questo file abbiamo definito il nuovo componente come modulo, con nome ‘

’ e path del sorgente uguale alla posizione attuale del file (

, questo definisce il modulo stesso, ogni modulo deve autodichiararsi specificando il suo nome, la versione e le possibili dipendenze.

<?xml version="1.0"?>
<config xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
        xsi:noNamespaceSchemaLocation="urn:magento:framework:Module/etc/module.xsd">
<module name="Bitbull_Example" setup_version="1.0.0"/>
</config>

Magento per la sua seconda versione ha aggiunto dei file per la definizione degli schema per XML ( i file xsd, XML Schema Definition) in modo da poter validare i file e dichiarare il contenuto degli stessi.

 il componente può definire le dipendenze da altri moduli, questo è permesso all’interno del tag sequence. Ecco un esempio direttamente da Magento

Con questo sistema è possibile definire l’ordine di caricamento del modulo, in particolare il modulo 

 non può essere caricato prima degli altri definiti nel tag 

Torniamo a noi, Magento 2 a differenza del predecessore ha suddiviso le configurazioni di un modulo all’interno di diversi file xml, quindi non è più presente un monolitico 

 con tutte le definizioni all’interno. Ora ogni singola tipologia di configurazione ha un suo file xml con il suo file xsd definito.

Una piccola nota sui file xsd: possiamo definire due tipologie diverse di inclusione

La prima permette di utilizzare i file xsd dichiarati all’interno dei moduli utilizzando la seguente struttura:

urn:magento:module:Magento_Flow:flows/content.xsd

Nell’esempio troveremo il file xsd all’interno del path 

” (il path è quello dichiarato nel file 

La seconda permette di usare i file xsd presenti nel framework magento

urn:magento:framework:Api/etc/extension_attributes.xsd

La logica del path è come nel precedente esempio con l’unica differenza che i file si trovano sotto il namespace 

” è stata sostituita al path relativo degli xsd per ragioni di inclusione; dato che i moduli possono essere installati con composer e stare nella cartella vendor questo portava a dei link non validi (per maggiori dettagli sull’argomento consultare 

, da notare anche l’utile commando per aggiungere la gestione dei urn xsd a PhpStorm).

Torniamo al nostro esempio, una volta creati i nostri due file dovremo abilitare il modulo, per farlo useremo la command line interface (CLI) di magento che si trova sotto 

Questa contiene molti utili comandi, tra i quali citiamo l’installazione di Magento 2, gestione della cache, gestione degli indici, generazione automatica di classi (sì, Magento 2 ne fa tanto uso, ma dato l’argomento troppo vasto per questo articolo ci limitiamo a citarlo senza approfondire) e tanto altro. Possiamo visualizzare la lista dei comandi disponibili chiamando dalla root del progetto:

dall’elenco possiamo notare un comando per vedere lo stato dei moduli installati, lo eseguiremo a breve. Prima di farlo, come buona norma durante lo sviluppo, occupiamoci di disabilitare la cache (se abilitata) tramite il comando:

Non indugiamo oltre, il nostro primo modulo sta per nascere

una volta eseguito, saranno elencati in una prima parte i moduli abilitati e nell’ultima quelli non attivi

List of enabled modules:
Magento_Store
...
List of disabled modules
Bitbull_Example

bin/magento module:enable Bitbull_Example

a questo punto il comando eseguito ci chiede di chiamare 

, questo esegue una serie di operazioni necessarie tra le quali quella di installazione/aggiornamento degli script di setup dei moduli. Se non eseguiamo il comando richiesto verrà visualizzato un messaggio d’errore (sia sull admin che sul frontend) al quale non potremmo dire di no.

possiamo aver conferma dell’effettiva abilitazione guardando il file 

, dove al suo interno troveremo (come uno degli attributi chiave dell’array modules) il nostro modulo con valore 1 ad indicare l’abilitazione. Inoltre possiamo vedere il modulo anche dall’admin accedendo tramite il menu a Store > Configuration > Advanced – Advanced, apparirà la lista dei moduli con in nostro 

In questo articolo abbiamo dato uno sguardo alle basi di partenza per costruire i moduli su Magento 2. Inizializzando la struttura che permette di riconoscere il nostro codice all’interno della piattaforma e di caricarlo al momento opportuno a seguito delle sue dipendenze. Il framework è tutto nuovo e da studiare un passo alla volta. Fortunatamente per noi Magento 2 mette a nostra disposizione una documentazione, per guidarci sui vari aspetti dello sviluppo. Spero l’articolo sia stato utile e vi invito a seguirci ancora per addentrarci ancora di più alla scoperta del nuovo framework.

Bitbull

Mirko Cesaro

Posts written by Mirko Cesaro

API REST per TEST

Migrazione dati da Magento 1 a Magento 2

Creiamo il nostro primo modulo su Magento 2