Da tempo in ufficio si utilizza una applicazione web, da me scritta, per la creazione di fax per la richiesta di visite fiscali alle ASL. Sebbene l'idea di partenza fosse quella di utilizzare direttamente Hylafax per l'invio dei fax, alla fine, per problemi puramente burocratici (firma "manuale" da apporre al documento e mancanza di una linea telefonica da utilizzare verso l'esterno), si è optato per la generazione di un file PDF da far stampare all'utente.
Tutto il servizio è basato su di una macchina virtuale GNU/Linux Mandriva 2009.1 su cui gira l'applicazione Rails per mezzo di Mongrel e Apache: ciò perché sussisteva già un'altra applicazione Rails che girava appoggiandosi al solo Mongrel. Impostando Apache in modalità revese proxy ero riuscito a far funzionare entrambe le applicazioni web come se fossero una sola.La generazione dei file avveniva in maniera alquanto macchinosa: si partiva da un modello in formato RTF, che veniva "riempito" con i dati presi da un database e convertito in PDF (tramite una antidiluviana applicazione, ted); il file risultante, a sua volta, veniva sovrapposto ad un altro contenente l'intestazione ed il piè di pagina con il necessario logo (tramite il mitico pdftk). Inoltre, per non appesantire troppo la macchina virtuale, ciascuna applicazione web girava in una singola istanza di Mongrel, invece che in cluster.
Morale della favola, vuoi per problemi di virtualizzazione (VMware), vuoi per problemi di carico su Mongrel, a volte al posto del PDF richiesto veniva mostrato un poco simpatico 504 Gateway Timeout.
Per risolvere il problema avevo pensato dunque di fare un doppio passaggio:
il passaggio a Phusion Passenger è stato alquanto semplice: è bastato installare la gem passenger (ora alla versione 2.2.11) e seguire le istruzioni per la corretta installazione dell'applicazione web.
Passaggio a Documatic ed unoconvL'utilizzo di Documatic è stato un po' più problematico per la fase di installazione dell'applicazione. Come prima, installiamo la gem documatic e assicuriamoci che sulla macchina server sia installato OpenOffice (attenzione, potrebbe essere necessario installare anche un desktop manager!). Predisponiamo anche unoconv ad essere eseguito ponendolo nella cartella /usr/bin od equivalente, purché sia nel path di root.
A questo punto il problema è che unoconv si rifiuta di funzionare, sebbene usandolo stand alone tutto sia a posto! Per risolverlo, è necessario un passaggio che ho scovato sul blog Blog of a LAMP Developer based near Guildford, Surrey, scorrendo il post Converting a Doc to PDF, txt or HTML using PHP and Linux, scritto per l'utilizzo di unoconv con PHP, si scopre che bisogna creare una home anche per l'utente apache:
[root@localhost home]# mkdir /home/apache
[root@localhost home]#chown apache:apache /home/apache
[root@localhost home]#usermod -d /home/apache apache
[root@localhost home]#chmd 755 /home/apache
In questo modo il funzionamento è assicurato.
Quello che non sono riuscito a fare, è predisporre un istanza di unoconv come listener e lanciare dalla applicazione web la connessione a quest'ultimo, in quanto dopo un po' di tempo (variabile di volta in volta) il listener sembrava fermarsi da solo, con unoconv che ti avvisava di andare in funzione in modalità stand-alone.
Morale della favola, vuoi per problemi di virtualizzazione (VMware), vuoi per problemi di carico su Mongrel, a volte al posto del PDF richiesto veniva mostrato un poco simpatico 504 Gateway Timeout.
Per risolvere il problema avevo pensato dunque di fare un doppio passaggio:
- utilizzare Phusion Passenger al posto di Mongrel per le applicazione web;
- sostituire i macchinosi script per la creazione del PDF con documatic (vedi pure su github per una versione più aggiornata) e unoconv.
il passaggio a Phusion Passenger è stato alquanto semplice: è bastato installare la gem passenger (ora alla versione 2.2.11) e seguire le istruzioni per la corretta installazione dell'applicazione web.
Passaggio a Documatic ed unoconvL'utilizzo di Documatic è stato un po' più problematico per la fase di installazione dell'applicazione. Come prima, installiamo la gem documatic e assicuriamoci che sulla macchina server sia installato OpenOffice (attenzione, potrebbe essere necessario installare anche un desktop manager!). Predisponiamo anche unoconv ad essere eseguito ponendolo nella cartella /usr/bin od equivalente, purché sia nel path di root.
A questo punto il problema è che unoconv si rifiuta di funzionare, sebbene usandolo stand alone tutto sia a posto! Per risolverlo, è necessario un passaggio che ho scovato sul blog Blog of a LAMP Developer based near Guildford, Surrey, scorrendo il post Converting a Doc to PDF, txt or HTML using PHP and Linux, scritto per l'utilizzo di unoconv con PHP, si scopre che bisogna creare una home anche per l'utente apache:
[root@localhost home]# mkdir /home/apache
[root@localhost home]#chown apache:apache /home/apache
[root@localhost home]#usermod -d /home/apache apache
[root@localhost home]#chmd 755 /home/apache
In questo modo il funzionamento è assicurato.
Quello che non sono riuscito a fare, è predisporre un istanza di unoconv come listener e lanciare dalla applicazione web la connessione a quest'ultimo, in quanto dopo un po' di tempo (variabile di volta in volta) il listener sembrava fermarsi da solo, con unoconv che ti avvisava di andare in funzione in modalità stand-alone.
Powered by ScribeFire.
Nessun commento:
Posta un commento