Non per nulla ma mi sono accorto che avevo visite al blog di gente che cercava su Google cose tipo "il verso del dinosauro" .
Vero che a volte mi sento un dinosauro pero' credo che non fosse il target che volevo attrarre sul sito.
Vedremo se c'e' gente che cerca su Google "il verso di Notes".
15 feb 2012
14 nov 2011
Statistiche accessi per il vostro sito Domino
Come tutti ben sappiamo il domlog.nsf non e' esattamente un buon sistema per generare statistiche sugli accessi ad un sito fatto con domino . E' vero che registra tutto , ma aggregare le info per ottenere un risultato consolidato e' quasi impossibile.
Mi sono guardato un po' in giro ed alla fine ho trovato quella che mi sembrava la soluzione ideale.
Si tratta di AWSTATS , che oltretutto e' un software con licenza GNU e quindi ha il non trascurabile vantaggio di essere free.
Per poterlo utilizzare c'e' solo un punto da configurare in Domino ed e' la generazione dei log. Ovviamente Awstats legge i file di log in formato testuale e del domlog.nsf non sa che farsene.
Di conseguenza nel documento NAB del server di vostro interesse (tab Internet protocols \ HTTP ) si deve configurare la generazione dei log file (per il domlog.nsf fate quello che preferite , e' ininfluente) ed inoltre settare la voce Access Log Format a Extended Common .
Dopodichè installate AWSTATS e Perl e configurate il tutto come descritto qui .
Fondamentalmente dovrete creare un file di configurazione (o piu' di uno se avete piu server con log/statistiche diverse)
Prestate attenzione alla riga LogFormat che deve essere = 1 (# 1 - Apache or Lotus Notes/Domino native combined log format (NCSA combined/XLF/ELF log format) ) ed alla riga LogFile che dovrà avere una impostazione del tipo LogFile="d:\weblog\access%MM-0%DD-24%YYYY-0.log" - dove d:\weblog\ cambierà ovviamente per puntare alla directory dove salvate i log file .
Il piu' e' fatto. Normalmente Awstats legge i file di log una volta al giorno, potete farlo con un comando schedulato che lancia la procedura di aggiornamento con un comando
perl awstats.pl -config=xxxxx -update
e poi genera i file Html relativi con il comando
perl awstats_buildstaticpages.pl -config=xxxxx -dir=D:\Domino\data\domino\html
Le statistiche possono essere anche salvate in formato PDF per riferimenti futuri (io lo faccio ad ogni fine mese e poi le carico in .nsf in modo da avere sempre lo storico suddiviso per mese)
Attenzione : tutto questo vale per un sito che non richieda login. Se invece stiamo parlando di una intranet o comunque di un sito che richiede l'autenticazione cambia un punto importante e cioe' la riga LogFormat che non e' piu' come descritta sopra ma prende un formato custom che io ho codificato in questo modo :
LogFormat = "%host %virtualname %lognamequot %time1 %methodurl %code %bytesd %refererquot %uaquot %other %otherquot %otherquot
Naturalmente non garantisco sia perfetto od il migliore...a me funziona per quelle che sono le mie necessità
Ultimo suggerimento: questa procedura genera dei file html sul server ed averla sul server di produzione esposto ad internet non e' il massimo : chiunque potrebbe vedere le vostre statistiche.
Io ho fatto un piccolo .nsf che ogni mattina cerca il log del giorno prima e se lo carica in un nuovo documento. Poi replica con un altro server, interno e non esposto ad internet, su cui ho installato Awstats . Qui il file viene scaricato e poi elaborato. In questo modole mie statistiche non risiedono sul server esposto e sono accessibili solo dall'interno.
Leggendo la documentazione di Awstats troverete decine di altre opzioni configurabili che non sto qui ad elencarvi . Inoltre dell'utile documentazione aggiuntiva potete trovarla sul sito nsftools a questo link , mentre altra , in italiano, e' reperibile qui .
Mi sono guardato un po' in giro ed alla fine ho trovato quella che mi sembrava la soluzione ideale.
Si tratta di AWSTATS , che oltretutto e' un software con licenza GNU e quindi ha il non trascurabile vantaggio di essere free.
Per poterlo utilizzare c'e' solo un punto da configurare in Domino ed e' la generazione dei log. Ovviamente Awstats legge i file di log in formato testuale e del domlog.nsf non sa che farsene.
Di conseguenza nel documento NAB del server di vostro interesse (tab Internet protocols \ HTTP ) si deve configurare la generazione dei log file (per il domlog.nsf fate quello che preferite , e' ininfluente) ed inoltre settare la voce Access Log Format a Extended Common .
Dopodichè installate AWSTATS e Perl e configurate il tutto come descritto qui .
Fondamentalmente dovrete creare un file di configurazione (o piu' di uno se avete piu server con log/statistiche diverse)
Prestate attenzione alla riga LogFormat che deve essere = 1 (# 1 - Apache or Lotus Notes/Domino native combined log format (NCSA combined/XLF/ELF log format) ) ed alla riga LogFile che dovrà avere una impostazione del tipo LogFile="d:\weblog\access%MM-0%DD-24%YYYY-0.log" - dove d:\weblog\ cambierà ovviamente per puntare alla directory dove salvate i log file .
Il piu' e' fatto. Normalmente Awstats legge i file di log una volta al giorno, potete farlo con un comando schedulato che lancia la procedura di aggiornamento con un comando
perl awstats.pl -config=xxxxx -update
e poi genera i file Html relativi con il comando
perl awstats_buildstaticpages.pl -config=xxxxx -dir=D:\Domino\data\domino\html
Le statistiche possono essere anche salvate in formato PDF per riferimenti futuri (io lo faccio ad ogni fine mese e poi le carico in .nsf in modo da avere sempre lo storico suddiviso per mese)
Attenzione : tutto questo vale per un sito che non richieda login. Se invece stiamo parlando di una intranet o comunque di un sito che richiede l'autenticazione cambia un punto importante e cioe' la riga LogFormat che non e' piu' come descritta sopra ma prende un formato custom che io ho codificato in questo modo :
LogFormat = "%host %virtualname %lognamequot %time1 %methodurl %code %bytesd %refererquot %uaquot %other %otherquot %otherquot
Naturalmente non garantisco sia perfetto od il migliore...a me funziona per quelle che sono le mie necessità
Ultimo suggerimento: questa procedura genera dei file html sul server ed averla sul server di produzione esposto ad internet non e' il massimo : chiunque potrebbe vedere le vostre statistiche.
Io ho fatto un piccolo .nsf che ogni mattina cerca il log del giorno prima e se lo carica in un nuovo documento. Poi replica con un altro server, interno e non esposto ad internet, su cui ho installato Awstats . Qui il file viene scaricato e poi elaborato. In questo modole mie statistiche non risiedono sul server esposto e sono accessibili solo dall'interno.
Leggendo la documentazione di Awstats troverete decine di altre opzioni configurabili che non sto qui ad elencarvi . Inoltre dell'utile documentazione aggiuntiva potete trovarla sul sito nsftools a questo link , mentre altra , in italiano, e' reperibile qui .
2 feb 2011
Gestione documentale
In uno dei post precedenti avevo scritto della necessità di creare una gestione ed archivio dei documenti utilizzando notes e db2 ma non ho mai descritto come gira l'applicazione.
(questo oltretutto e' il motivo per cui ho passato un bel po' di tempo a giocare con Db2 , Uselsx "*lsxlc" , Sql e cosi' via )
Il concetto e' semplice e il tutto si divide in tre parti:
Supponiamo una qualunque lettera che chiede informazioni: il sistema deve prenderla in carico, archiviarla in modo che sia facilmente ricercabile e segnalare a chi di dovere che è arrivata e bisogna fare qualcosa. Questa persona a sua volta deve prendersi in carico l'attività e poi chiuderla.
Il tutto, come ho gia scritto, con domino e Db2.
L'idea di base e' stata di utilizzare Db2 per l'archiviazione dei file con le immagini dei documenti mentre Notes e Domino mi servono per tutta la parte di gestione, ricerca e smistamento dei flussi .
In effetti e' stata quasi una scelta obbligata : gestire milioni di documenti (con attachment! ) in Notes non e' esattamente il top per le performance , Db2 se la cava molto meglio in questo .
(questo oltretutto e' il motivo per cui ho passato un bel po' di tempo a giocare con Db2 , Uselsx "*lsxlc" , Sql e cosi' via )
Il concetto e' semplice e il tutto si divide in tre parti:
- L'acquisizione di nuovi doc. da archiviare che possono essere file pdf, jpg, doc ecc. e che possono provenire da diverse fonti : scanner, email , videate ecc.
- Poi serve ovviamente un sistema di ricerca e visualizzazione di questi documenti
- Ed infine una gestione di eventuali flussi di lavorazioni associati ai documenti acquisiti.
Supponiamo una qualunque lettera che chiede informazioni: il sistema deve prenderla in carico, archiviarla in modo che sia facilmente ricercabile e segnalare a chi di dovere che è arrivata e bisogna fare qualcosa. Questa persona a sua volta deve prendersi in carico l'attività e poi chiuderla.
Il tutto, come ho gia scritto, con domino e Db2.
L'idea di base e' stata di utilizzare Db2 per l'archiviazione dei file con le immagini dei documenti mentre Notes e Domino mi servono per tutta la parte di gestione, ricerca e smistamento dei flussi .
In effetti e' stata quasi una scelta obbligata : gestire milioni di documenti (con attachment! ) in Notes non e' esattamente il top per le performance , Db2 se la cava molto meglio in questo .
24 gen 2011
Cookie & Domino
Sono cascato su di una applicazione con interfaccia web in cui mi avrebbe fatto molto comodo leggere e scrivere cookie con Domino per salvare delle opzioni.
Sapevo che Domino gestisce i cookie ma non avevo mai usato quelle funzioni e quindi mi ci sono buttato allegramente ... per scoprire che la cosa non e' esattamente ben documentata.
Dopo qualche lite e un po' di test sono giunto a delle conclusioni e quella parte dell'applicazione sembra essere decollata.
Prima parte : scrivere un cookie
E' quella che ha funzionato subito e praticamente al primo colpo . Come da help di Notes si usa la funzione @SetHTTPHeader che viene scritta con la seguente sintassi :
@SetHTTPHeader("Set-Cookie"; "SHOP_CART_ID=4646")
Fin qui e' semplice , ma dipende poi dal modo in cui lo si vuole usare, a me faceva più comodo scrivere il cookie all' uscita della pagina e quindi sono passato a javascript utilizzando la onUnload della form e scrivendoci dentro
Set_Cookie( 'nomedelcookie', document.getElementById('campo').value , 30, '/', '', '' );
dove campo e' il campo della form da cui voglio prendere il valore, mentre il numero 30 e' la durata in giorni della validità del cookie.
Volendo era anche possibile intervenire sulla generazione del codice Html della pagina per inserire una riga del tipo:
meta equiv="Set-Cookie" content="..."
Seconda parte : leggere un cookie
Qui mi sono incasinato un po' di piu' . E' vero che esiste la funzione @GetHTTPHeader ma il come usarla era poco chiaro . Poichè mi serviva leggere il cookie ed averne il valore come default in un campo ho proseguito su questa strada ed ho trovato che il modo migliore era questo:
@Middle(@GetHTTPHeader("Cookie");"nomedelcookie=";";")
Anche perche' usando solo @GetHTTPHeader("Cookie")
mi ritornava come valore l'elenco di tutti i cookie cha avevo in quel momento . Cosi' isolavo il cookie che mi interessa e ne estraevo il valore.
Unica aggiunta un @ReplaceSubstring perche' nel caso il cookie contenesse uno o più spazi questi venivano salvati come "%20" e quiindi il tutto deve avere questo aspetto
@ReplaceSubstring(
@Middle(@GetHTTPHeader("Cookie");"nomedelcookie=";";");
"%20";" ")
giusto per evitare sorprese.
Per completezza, le info piu' utili le ho ricavate da qui , sul sito Codestore
Sapevo che Domino gestisce i cookie ma non avevo mai usato quelle funzioni e quindi mi ci sono buttato allegramente ... per scoprire che la cosa non e' esattamente ben documentata.
Dopo qualche lite e un po' di test sono giunto a delle conclusioni e quella parte dell'applicazione sembra essere decollata.
Prima parte : scrivere un cookie
E' quella che ha funzionato subito e praticamente al primo colpo . Come da help di Notes si usa la funzione @SetHTTPHeader che viene scritta con la seguente sintassi :
@SetHTTPHeader("Set-Cookie"; "SHOP_CART_ID=4646")
Fin qui e' semplice , ma dipende poi dal modo in cui lo si vuole usare, a me faceva più comodo scrivere il cookie all' uscita della pagina e quindi sono passato a javascript utilizzando la onUnload della form e scrivendoci dentro
Set_Cookie( 'nomedelcookie', document.getElementById('campo').value , 30, '/', '', '' );
dove campo e' il campo della form da cui voglio prendere il valore, mentre il numero 30 e' la durata in giorni della validità del cookie.
Volendo era anche possibile intervenire sulla generazione del codice Html della pagina per inserire una riga del tipo:
meta equiv="Set-Cookie" content="..."
Seconda parte : leggere un cookie
Qui mi sono incasinato un po' di piu' . E' vero che esiste la funzione @GetHTTPHeader ma il come usarla era poco chiaro . Poichè mi serviva leggere il cookie ed averne il valore come default in un campo ho proseguito su questa strada ed ho trovato che il modo migliore era questo:
@Middle(@GetHTTPHeader("Cookie");"nomedelcookie=";";")
Anche perche' usando solo @GetHTTPHeader("Cookie")
mi ritornava come valore l'elenco di tutti i cookie cha avevo in quel momento . Cosi' isolavo il cookie che mi interessa e ne estraevo il valore.
Unica aggiunta un @ReplaceSubstring perche' nel caso il cookie contenesse uno o più spazi questi venivano salvati come "%20" e quiindi il tutto deve avere questo aspetto
@ReplaceSubstring(
@Middle(@GetHTTPHeader("Cookie");"nomedelcookie=";";");
"%20";" ")
giusto per evitare sorprese.
Per completezza, le info piu' utili le ho ricavate da qui , sul sito Codestore
Iscriviti a:
Post (Atom)