bloggers bloggers

Marco Napolitano
Messaggi: 68
Stelle: 0
Data: 15/11/17
Jader Jed Francia
Messaggi: 50
Stelle: 0
Data: 22/09/17
Ezio Lombardi
Messaggi: 9
Stelle: 0
Data: 23/06/17
Chiara Mambretti
Messaggi: 25
Stelle: 0
Data: 27/02/17
Serena Traversi
Messaggi: 3
Stelle: 0
Data: 21/07/16
Francesco Falanga
Messaggi: 8
Stelle: 0
Data: 14/06/16
Antonio Musarra
Messaggi: 2
Stelle: 0
Data: 18/11/13
Simone Celli Marchi
Messaggi: 6
Stelle: 0
Data: 09/07/13
marcello marangio
Messaggi: 4
Stelle: 0
Data: 05/07/13
Marco Mancini
Messaggi: 1
Stelle: 0
Data: 05/06/13
Indietro

Import / export Liferay lar con eccezione

Tutti avrete pensato che il meccanismo di import / export nativo di Liferay, quello che vi permette di trasferire all'interno di un file LAR (Liferay Archive) le vostre singole righe del database come file XML fosse una vera figata!

La possibilità di sviluppare su un database di test e poi "esportare e importare" su un database di produzione potenzialmente differente rispetto a quello dal quale avete esportato, senza preoccuparvi di nulla, è indubbiamente una funzionalità che chi, come noi, sviluppa progetti apprezza to-cour.

Peccato che molti lamentano che, al momento dell'import, vengano sollevate eccezioni incomprensibili anche quando esportano solamente qualche pagina di prova!

Lo so: la metà dei miei capelli bianchi è data dal meccanismo di import / export dei LAR di Liferay, soprattutto perché questo meccanismo è anche alla base della pubblicazione da staging verso active, sul quale ho già scritto qualche cosa in passato.. :)

Vorrei però condividere con voi un paio di cose che, nella versione 6.1 di Liferay, si deve considerare quando si fa questo tipo di operazione, così che voi possiate beneficiare dei miei capelli bianchi senza farvene troppi dei vostri! ;)

Queste sono le due regole auree che vi consiglio di controllare __SEMPRE__ quando il meccanismo di import si rompe:

  1. il portale dal quale avete esportato ha la lingua di default UGUALE al portale sul quale state cercando di importare
  2. tutte le strutture e i template dell'applicazione del CMS (il Journal..) NON contengono spazi all'interno dei nomi!

E badate bene: per il punto 2 intendo _in tutti i nomi_ anche quelli delle lingue tradotte!!

Escludo ovviamente che stiate provando ad esportare / importare da versioni diverse di Liferay, perché questo è un problema già noto.

Spero che con questi due accogimenti riusciate a importare / esportare contenuti senza diventare pazzi!!


Ovviamente se poi avete ancora eccezioni, il consiglio, aimè, è sempre il solito: attaccate il debugger e.. Buon lavoro! ;)

Alla prossima!

Precedente
Commenti
Aggiungi Commento
Fabio Collini
Ciao, molto interessante sia questo articolo che tutto il blog, grazie! Ho una domanda sull'export in generale, quale è il metodo migliore per esportare tutte le informazioni inserite tramite interfaccia di amministrazione? Per esempio i custom fields o i page template sono inclusi nel lar?
In pratica quale è la strategia migliore per gestire i dati? In pratica siamo più sviluppatori su questo progetto, ognuno aggiunge dati nella propria istanza locale di liferay. Come possiamo fare per avere dei "dati condivisi" fra le nostre installazioni e una installazione di certificazione/produzione? E' possibile committare i dati da qualche parte?
Grazie per l'aiuto e complimenti ancora per il sito!
Inviato il 09/07/15 14.02.
Jader Jed Francia
Ciao Fabio!
La domanda che mi fai è una di quelle più frequenti che mi vengono fatte durante i corsi che teniamo ai team che svilupperanno su Liferay! emoticon
La risposta è presto detta: per fare quello che chiedi si possono mettere in campo diverse strategie. Però, a mio avviso, vanno diversificate in funzione degli obiettivi che ci stiamo ponendo.
Nel tuo caso specifico, io spacchetterei la domanda in questi punti:
-> come facciamo a spostare dati che gestiamo attraverso tabelle custom?
-> come facciamo a spostare le parametrizzazioni?
-> come facciamo ad avere un unico ambiente di test / produzione se partiamo da n ambienti di sviluppo che, tra di loro, sono eterogenei?

Vediamo le risposte! emoticon

Come sposto i dati che gestisco attraverso tabelle custom?
La risposta e' semplice: PortletDataHandler!
Qui: http://www.liferay.com/community/wiki/-/wiki/Main/Portlet+DataHandlers trovi un tutorial -a dire la verità un po' datato..- che spiega come implementare il meccanismo.
In pratica e' il modo con cui Liferay popola il LAR. Se tu, per le tue tabelle custom, fornisci il tuo portletDataHandler allora anche i tuoi dati -intesi come record del db- finiscono dentro al LAR e puoi spostare i dati da una installazione ad un'altra come fa LR.
Rispondo qui anche alla domanda dei custom fields: con il portletDataHandler ti porti dietro anche i custom fields VALUES; per quanto riguarda la definizione sono abbastanza sicuro che vengano spostati già nativamente nei LAR; però ti chiederei di fare un controllo prima di prenderlo per vero.

Come facciamo a spostare le parametrizzazioni?
Anche qui ci sono diversi aspetti delle "parametrizzazioni" che andrebbero analizzati.
Per quanto riguarda le "preferenze" -di portlet, di pagina, etc- queste sono spostate nativamente dal LAR -anche sulle portlet custom-.
Quello che rimane fuori sono eventuali tue parametrizzazioni su tabelle custom ma, come dicevo prima, la risposta è PortletDataHandler.

Come facciamo ad avere un unico ambiente di test / produzione se partiamo da n ambienti di sviluppo che, tra di loro, sono eterogenei?
Beh, qui forse rimarrai un po' deluso dalla mia risposta perché attualmente LR non fornisce nessun meccanismo automatico per gestire questo caso funzionale.
Anche noi, internamente, lavoriamo con questo problema e lo affrontiamo nella maniera più semplice che c'è venuta in mente: abbiamo un "product owner" che ha il compito di mantenere la release pubblica "allineata". Quindi è lui che scarica, compila e fa deploy dei progetti e che si occupa di portarsi dietro le parametrizzazioni.
Tieni conto che con l'introduzione della 6 molte delle complessità di gestione di prima sono state superate: ora, infatti, è possibile fare deploy anche di configurazioni del file portal-ext attraverso del codice applicativo -hooks, per intenderci-; una volta tutto questo era da fare a mano prendendo i pezzetti dai singoli file di properties..

Spero d'esserti stato d'aiuto; se hai ancora dei dubbi / problemi, comunque, non esitare a contattarci! ;)

A presto, ciao, J.
Inviato il 09/07/15 14.02 in risposta a Fabio Collini.
Fabio Collini
Ciao, grazie per la risposta, molto utile!
Ormai che ci siamo approfitto della tua gentilezza e ti faccio qualche altra domanda sull'argomento:
- ho esportato un lar ma cercando nei vari xml non ho trovato nè i custom field che ho definito sulle entità User e Site nè i site template. Il posto giusto in cui esportare un lar è dal control panel -> Site Pages o c'è un altro modo?
- sicuramente metteremo tutto il possibile un un hook in modo da poterlo committare da qualche parte. Per il resto se anche voi fate qualcosa di "manuale" mi rassegno e smetto di cercare! Comunque sia facendo un export e import dell'intero db si duplica tutta la configurazione o c'è qualcosa che viene salvato in altri modi?
- invece il concetto di staging lo usate per qualcosa o è tutto un altro argomento?
Grazie ancora per l'aiuto, è da poco che abbiamo iniziato a usare Liferay e all'inizio siamo un po' spaesati (ma non molliamo perchè è Liferay è pensato molto bene!).
Ciao, Fabio
Inviato il 09/07/15 14.02 in risposta a Jader Jed Francia.
Jader Jed Francia
Ciao Fabio!
Si, il posto dove esportare i LAR è control panel -> site pages -> export.
Sicuro che non te li esporti? A me risulta che dentro al LAR, nel percorso "groups/<id del site>/expando-tables.xml" siano mappati per i singoli model i custom fields che si creano. Puoi controllare e darmi un feedback?
Ho fatto un testo su una LR611CEGA2 e in effetti a me li esporta.

Passo alla domanda dopo: "facendo un export e import dell'intero db si duplica tutta la configurazione o c'è qualcosa che viene salvato in altri modi?".
Quello che viene esportato / importato dipende da quello che tu selezioni quando fai una esportazione; nel pannellino dell'export ci sono una serie di spunte, alcune delle quali comprendono, ad esempio, le preferenze di portlet o altre che, invece, sono collegate alle singole entity.
Di default il portale ti esporta le pagine e le preferenze di tutte le portlet; il resto lo devi "spuntare" tu sul pannellino di export.
Tieni presente che se hai fatto anche delle parametrizzazioni a livello di permessi, devi andare a spuntare la voce in fondo, quella che proprio si riferisce ai permessi.
Per "parametrizzazioni" intendo se hai dato, sulle singole portlet o su dei ruoli che hai creato tu, delle particolari combinazioni di permessi; queste non vengono esportate in automatico ma devono essere spuntate direttamente.

Infine rispondo sullo staging.
Come avrai capito dall'ironia che celo nel post sul quale stiamo discutendo, lo staging è una funzionalità che usiamo soprattutto quanto il cliente ha necessità di ___contribuzione___ particolari.
Fino ad oggi non abbiamo mai dovuto sviluppare qualche cosa che "supportasse" lo staging ma abbiamo sempre sviluppato portlet che gestissero solamente l'ambiente live.
Per intenderci, è quello che fanno le portlet del forum o del blog: quando lo staging è attivo, quelle portlet __comunque__ ragionano su dati che sono solo live.
Ad essere del tutto onesti, noi lo staging lo proponiamo in pre-sale perché è una feature di prodotto molto interessante ma, al momento della realizzazione della soluzione, ragioniamo con il cliente sulla modalità con cui intende gestire il sistema e, insieme a lui, decidiamo se attivare o meno lo staging.
Quel che è certo è che:
1) quando dicono che non lo vogliono tiriamo tutti un sospiro di sollievo! ;)
2) quando dicono che lo vogliono lo attiviamo __SUBITO__; se aspetti ad attivarlo e cominci a popolare il portale allora avrai moooltissimi casini quando andrai ad attivarlo, quindi: o subito o mai più (questo per quanto ci riguarda, ma se sei uno coraggioso puoi fare come meglio credi.. ;))

Concludo dicendo che si, anche noi crediamo che Liferay sia un ottimo prodotto -tant'è che sono diversi anni che investiamo risorse e tempo su di esso! ;)-; però, siccome capisco la fatica e lo "spaesamento" che state avendo nell'approcciare un prodotto complesso come questo, se possiamo esservi d'aiuto in qualche modo ci fa solo piacere! ;)
E lo possiamo fare in tantissimi modi: con questo blog, sui forum del sito ufficiale o, se preferite, anche con della formazione tecnica mirata! emoticon

Fammi sapere se hai bisogno di altre info! emoticon
A presto, ciao, J.
Inviato il 09/07/15 14.02 in risposta a Fabio Collini.