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 .
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
14 gen 2011
Ovi Maps e POI
Ritorno dopo un po' di silenzio (le feste natalizie hanno uno scotto da pagare) ma non per parlare di Notes o Domino.
Possiedo un telefono Nokia (di cui sono generalmente soddisfatto a parte un paio di problemini) dotato fra l'altro del software di navigazione Ovi Maps.
Anche questo non e' il top della gamma fra i software di navigazione ma comunque lo trovo funzionale e comodo, soprattutto apprezzo la comodità di averlo sempre in tasca , specialmente quando mi muovo a piedi in zone che non conosco.
Ad un certo punto mi e' saltato in mente di avere dei POI (o PDI , punti di interesse) in piu' rispetto a quelli forniti da Nokia . Vuoi mettere la soddisfazione di poter avere la posizione del McDonald's o Burgher King piu' vicino ?
Soluzione:
Per prima cosa scaricare il file dei POI che interessano: io l'ho fatto dal sito PoiGps ma immagino non sia l'unico. Naturalmente qui non trovi i file gia' in formato giusto per oviMaps ma nel generico formato CSV e quindi bisogna convertirli nel formato Lmx usato da Nokia.
Quindi ho trovato un sito Gps Data Team che offre un convertitore gratuito online per eseguire l'operazione.
Infine copio il file cosi' convertito sul mio telefonino e poi, tramite filemanager, lo apro. A questo punto mi chiede se voglio aggiungere tutti i luoghi contenuti nel file o selezionarne solo alcuni e quindi il gioco e' fatto.
A scriverlo mi rendo conto che sembra complicato ma in realtà e' stato semplice e veloce .
Unico neo dell'operazione : il convertitore aggiunge al nome del poi anche il nome del sito , tanto per fare pubblicità . Prima di portare il file Lmx sul telefonino potete fare un Cerca&Sostituisci usando un comune editor.
Aggiungo anche che OviMaps non gestisce al meglio le categorie dei luoghi e se si vuole categorizzare o spostare i POI per organizzarseli meglio qualche moccolo a chi ha progettato il software lo si tira, pero' il tutto funziona dignitosamente. Certo, non e' TomTom ma e' comunque valido e comodo , soprattutto in rapporto al prezzo che ha !
Possiedo un telefono Nokia (di cui sono generalmente soddisfatto a parte un paio di problemini) dotato fra l'altro del software di navigazione Ovi Maps.
Anche questo non e' il top della gamma fra i software di navigazione ma comunque lo trovo funzionale e comodo, soprattutto apprezzo la comodità di averlo sempre in tasca , specialmente quando mi muovo a piedi in zone che non conosco.
Ad un certo punto mi e' saltato in mente di avere dei POI (o PDI , punti di interesse) in piu' rispetto a quelli forniti da Nokia . Vuoi mettere la soddisfazione di poter avere la posizione del McDonald's o Burgher King piu' vicino ?
Soluzione:
Per prima cosa scaricare il file dei POI che interessano: io l'ho fatto dal sito PoiGps ma immagino non sia l'unico. Naturalmente qui non trovi i file gia' in formato giusto per oviMaps ma nel generico formato CSV e quindi bisogna convertirli nel formato Lmx usato da Nokia.
Quindi ho trovato un sito Gps Data Team che offre un convertitore gratuito online per eseguire l'operazione.
Infine copio il file cosi' convertito sul mio telefonino e poi, tramite filemanager, lo apro. A questo punto mi chiede se voglio aggiungere tutti i luoghi contenuti nel file o selezionarne solo alcuni e quindi il gioco e' fatto.
A scriverlo mi rendo conto che sembra complicato ma in realtà e' stato semplice e veloce .
Unico neo dell'operazione : il convertitore aggiunge al nome del poi anche il nome del sito , tanto per fare pubblicità . Prima di portare il file Lmx sul telefonino potete fare un Cerca&Sostituisci usando un comune editor.
Aggiungo anche che OviMaps non gestisce al meglio le categorie dei luoghi e se si vuole categorizzare o spostare i POI per organizzarseli meglio qualche moccolo a chi ha progettato il software lo si tira, pero' il tutto funziona dignitosamente. Certo, non e' TomTom ma e' comunque valido e comodo , soprattutto in rapporto al prezzo che ha !
Iscriviti a:
Post (Atom)