eXtraWay Server registra tutti i propri logs in una singola cartella collocata parallelamente alle altre.
Data la cartella principale di installazione del software, deniminata xw per la Standard Edition e xwee per l'Enterprise Edition, in essa si trovano altre cartelle, più volte descritte in altri punti della documentazione, tra le quali quella dei binari (bin), quella di configurazione (conf) e quella dei logs (logs).
Entro tale cartella si trovano logs di varia natura, ciascuno con un proprio scopo specifico.
Per i casi particolari riferiti a moduli a corredo del Server eXtraWay, ciascuno documenta sinteticamente i propri logs. Di seguito il dettaglio dei logs principali del Server.

eXtraWay Server ed i moduli ad esso correlati stilano una serie di logs ciascuno avente diversi scopi.
I logs possono essere suddivisi in logs ciclici, nei quali le informazioni più datate sono destinate ad essere scartate man mano che la loro stesura cresce, ed i logs statici, che sono invece concepiti per rimanere nel tempo a disposizione dei sistemtisti e degli amministratori dell'installazione della eXtraWay Platform.
Senza entrare nel merito di logs stilati dai moduli a corredo¹⁾ vediamo quali sono i principali logs stilati da eXtraWay Server.

• Logs Ciclici
  • xw.log, xw1.log, …
    Questi logs, detti Logs di Servizio contengono una descrizione capillare dei comandi effettuati, delle informazioni ad essi relative e dell'esito degli stessi. E' possibile definire il livello di dettagli delle informazioni aggiuntive, si consulti in proposito l'apposita documentazione.
  • bm.csv, bm1.csv, …
    Enterprise Only. Si affiancano ai Logs di Servizio e registrano informazioni sulle performance di ciascun comando, con particolare riguardo ai tempi effetivi del comando, tempi percepiti a causa delle sessioni critiche, I/O effettuato e diverse altre informazioni. Nella versione Standard queste informazioni sono presenti in righe di tipo [B] internamebte ai log di servizio xw.log etc. etc.
• Logs Statici
  • xreg<annomese>.log
    Questi logs sono chiamati Logs di Registro e mantengono una capillare registrazione delle principali attività svolte sugli archivi con particolare riguardo agli inserimenti e modifiche dei documenti. Per mezzo di queto log è possibile risalire nel tempo a qualsiasi forma abbia avuto un documento sin dalla sua origine.
  • xw<annomese>.log
    Questi logs sono chiamati Logs Giornale. In essi viene conservata la registrazione delle operazioni pricipali riguardanti i server²⁾, gli archivi³⁾ e gli allegati⁴⁾.

Ad eccezione dei Log di Registro che hanno un formato proprio, per tutti gli altri si fa uso del formato descritto nei paragrafi successivi.
Lo stesso formato si applica anche ai logs dei moduli a corredo del Server eXtraWay.

I files di log prodotti dal server eXtraWay e dai suo moduli accessori vengono tutti scritti dal modulo xwls (eXtraWay Log Server) che usa una forma standard per indicare il contenuto di quanto registrato e si trovano tutti nella directory logs delle installazioni eXtraWay, parallela alla directory che ospita i binari.
La riga del file è composta innanzitutto dalla data (espressa come anno, mese, giorno, ora, minuti, secondi ed i millisecondi, questi ultimi separti da un punto). Dopo un tabulatore viene indicato il PID del processo che ha provocato il log, un ulteriore tabulatore ed il vero messaggio di log. Questo messaggio è solitamente preceduto da un carattere maiuscolo racchiuso tra parentesi quadre. Tale carattere indica la natura dell'informazione loggata.
Di seguito l'elenco dei caratteri previsti:

Il codice che può seguire una segnalazione [E], [W] o [T] è composto da una sequenza (da uno a dieci componenti) di codici la cui forma è composto da queste componenti:

 <identificativo componente>:<numero di riga>:<corice d'errore>/<tipo errore esteso> 

Una o più parti possono essere assenti. La segnalazione a 3D Informatica di questi codici unitamente alle altre registrazioni, precedenti e seguenti, riconducibili quanto meno allo stesso PID è di grande utilità per la determinazione delle cause dei più importanti errori rilevabili dal server.

Attenzione:

Per una corretta lettura dei logs, in particolare del file xw.log (xw1.log, xw2.log e così via…) si deve tener presente che ogni comando inviato al server è riconoscibile in quanto identificato dall'etichetta [Q] al fianco della quale appare il codice del comando inviato.
Per identificare le sorti di quel comando vanno seguite tutte le successive righe del log aventi lo stesso PID. Infatti tutte le righe di registrazioni vengono scritte in ordine cronologico da tutti i server, tramite il modulo xwls, nello stesso file di log quindi le registrazioni di un singolo comando, che si potrebbe protrarre nel tempo, vanno cercate basandosi sul PID del processo invocato.
Il comando si considera completato quando si rileva, per lo stesso PID, una riga del file di log con l'etichetta [A]. Al fianco dell'etichetta viene riportato un codice numerico: se esso è pari a 0 il comando ha avuto correttamente esito mentre ogni altro valore numerico rappresenta un particolare codice d'errore. Oltre ad esso, tra parentesi tonde, ci sono altre informazioni di servizio che però non sono rappresentative del successo o del fallimento del comando.
La dove il codice numerico che affianca l'etichetta [A] non fosse 0, può essere particolarmente utile raccogliere tutte le righe che rappresentano quel comando (ed in alcuni casi anche le righe intermedie riconducibili ad altri server) con particolare attenzione alle righe aventi come etichetta [W] e [E].
Righe di tipo [W] o [E] possono essere presenti anche in caso di risposta positiva, vale a dire di risposta [A]0. In tal caso essi segnalano passaggi in cui il server ha riscontrato qualcosa da annotare ma che non hanno impatto reale sull'esito del comando. In questi casi il codice [E] può risultare ingannevole ma è sintomo che uno dei comandi (ad esempio un test sul record) effettuati ha dato esito negativo ed in quel caso il server ha intrapreso una diversa azione. Si possono considerare “segnalazioni fisiologiche”.

Nota:

Qualsiasi segnalazione d'errore che si avvalga o meno di una parte del file xw.log deve essere accompagnata dall'indicazione della versione del Server eXtraWay cui essa fa riferimento altrimenti l'interpretazione dei dettagli isolati nel file di log potrebbe risultare impossibile.

La presente documentazione si applica a partire dalla versione 22 del server eXtraWay. Da tale versione la stesura dei record del file di logs è stata arricchita secondo il seguente schema.
Ogni riga è composta, come in precedenza, dal timestamp di esecuzione dell'operazione, completo di millisecondi, il Process Id ed i dettagli dell'operazione. Queste tre componenti sono separate da un tabulatore.
Quando l'operazione è di tipo [Q] e quindi una question il contenuto della riga del comando va così interpretato.

[Q]Codice Comando-Codice Sub Comando<<User@Ip:Ops>> Dati supplementari

Il Codice Comando ed il Codice Sub Comando sono scarsamente comprensibili se non si conosce in dettagli le caratteristiche del server eXtraWay. Ecco perché sono stati introdotte alcune descrizioni oltre ai già esistenti Dati supplementari che possono rappresentare diverse informazioni tra le quali:

Vediamo ora cosa ci viene detto dalle descrizioni dei comandi
Esse sono brevi stringhe di testo, separate da un carattere '/' che possono essere interpretate tanto in modo posizionale che in modo formale.
L'interpretazione posizionale ci dice che la prima componente rappresenta l'area di competenza del comando, la seconda ci dice di che operazione si tratti in tale area mentre le successive ci indicano, indistintamente, dettagli o modificatori dell'operazione indicata.
L'interpretazione posiziona è semplificata da una formale che ci dice che l'AREA di competenza del comando viene espressa con caratteri tutti maiuscoli, l'Operazione viene indicata con l'iniziale maiuscola ed i restanti caratteri minuscoli mentre le parti destinate ai dettagli sono tutte minuscole.

Vediamo di seguito aree, operazioni e dettagli vari.

Il Procedimento di WatchDog comporta l'osservazione dal parte del “server master” delle directory indicate nel file di configurazione xwwd.conf.xml e per ognuna di tali directory (tipicamente una sola denominata 'wd') verifica la presenza di file con estensione “.xml”. Se esiste un file con tale estensione si determina dal nome del file l'archivio interessato e, se disponibile, l'utente “inseritore” da assegnare ai documenti che verranno identificati all'interno di tale file. Se esiste un file appartenente allo stesso archivio ma avente estensione “.xml.wrk” il server sa che è in esecuzione un'altra operazione di acquisizione per lo stesso archivio ed attende che essa sia finita. Quando invece non c'è alcun lavoro in corso per l'archivio in esame, il primo file ad esso relativo (rilevato in ordine alfabetico tra quelli contenuti nella directory) viene rinominato con estensione “.xml.wrk” e dato in pasto ad una nuova istanza del server che provvederà a rimuoverlo al termine dei propri compiti sbloccando quindi l'acquisizione da altri file per lo stesso archivio.
Il server che interpreta il file in esame deve verificare che in esso sia interpretabile il contenuto secondo le unità documentarie riconosciute dal server per l'archivio in corso di elaborazione e che nella sintassi interna non vi siano incongruenze. Una volta riconosciuti questi documenti passa al salvataggio di ognuno di essi, rispettando l'eventuale univocità e procedendo a saltare i documenti non salvabili registrandoli nel file “.xml.fail”. Il salvataggio di questi singoli documenti può anche fallire per questioni legate all'archivio (problemi di scrittura sullo strato fisico, spazio su disco completato, operazioni di indicizzazione on-line fallite per cause legate a difetti del vocabolario, ecc. ecc.). Completati i propri compiti, come detto, tale server rimuoverà il file “.xml.wrk” ed il file dei fallimenti (“.xml.fail”) a patto che non ce ne siano stati. Ogni operazione ed in particolare i difetti verranno registrati nel file wd_journal.log presente nell'apposita directory.

Questo file concentra in se le registrazioni significative delle operazioni svolte dal server, per mezzo di libxwwd.so, atte al caricamento negli archivi di nuove unità documentarie.
Negli esempi a seguire non verrà indicata la prima parte della riga di log contenente data e PID. Parimenti, i nomi dei file e degli archivi sono puri esempi. Il riconoscimento di un file da acquisire da parte del modulo libxwwd.so viene segnalato come segue…

…questa segnalazione informa che è stato attivato un nuovo lavoro che interessa il file “.xml.wrk” indicato e che coinvolge l'archivio indicato. La registrazione viene solitamente fatta dal PID del processo eXtraWay Server “padre” ovvero quello che genera tutti i server che dialogano con l'applicazione client. Tale server rinomina questo file con estensione “.xml.wrk” così da frenare ogni ulteriore procedimento che interessi lo stesso archivio e stabilirà che nome dare al file degli errori usando lo stesso nome file ma con estensione “.xml.fail”. Fatto questo creerà un ulteriore server “figlio” che svolgerà il lavoro vero e proprio.
Di seguito il server “figlio” preposto a questo compito registrerà di essersi accorto del lavoro da svolgere con un log come il seguente…

…in questa informazione viene ripetuta la richiesta di un nuovo lavoro sull'archivio indicato. Vengono inoltre indicati gli identificatori del nodo primario e del suo elemento contenitore ed i due archivi, quello di lavorazione e quello nel quale verranno scaricati gli errori. Al termine dell'operazione il primo file “.xml.srk” verrà rimosso così come il file “.xml.fail” a patto che non si siano rilevati problemi.
Il processo provvederà quindi alla verifica del contenuto del file “.xml.wkr” ed indicherà quanto scoperto con il log…

…di seguito, se non è stato indicato il nome dell'elemento contenitore ed esso risultasse indispensabile il server provocherebbe il seguente errore…

… e l'operazione sarebbe completata in questo punto.
Se invece il contenitore è presente ma l'operazione di riconoscimento del file “.xml.wrk” fallisce, allora il server indicherà il seguente errore…

…per indicare che nel file “.xml.fail” c'è il materiale non acqusito.
A questo punto, se non ci sono stai errori, il server procede determinando per ogni nodo primario la dislocazione che essi dovranno avere su disco (strato fisico). Qualora il file <nomearchivio>.conf.xml fosse stato maldestramente configurato il server presentarà il seguente errore…

…indicando tra parentesi quale regola di composizione del nome file abbia provocato il problema.
Ogni nodo primario viene verificato nella sua univocità. Se il documento non viola alcuna univocità esso viene accodato al catalogo e registrato sullo strato fisico nella nuova dilocazione, se invece esso viola l'univocità il comportamento varia. Se la configurazione del WatchDog è tale (per l'archivio corrente) perché si possa compiere update dei documenti già presenti (Vds. File di configurazione Xwwd.conf.xml), allora il server può sovrascrivere il singolo documento incontrato usando la sua locazione originaria o una nuova locazione (sullo strato fisico) a seconda di diversi fattori (non discussi in questa documentazione). Se però le univocità violate riguardano documenti duplicati (da catalogo totale ove l'univocità violata viene tollerata) allora il server rigetterà il documento (registrato nel “.xml.fail”) indicando la causa del fallimento. Ciò avviene per tutti i documenti che violano anche una singola univocità qualora per quest'archivio non sia previsto l'update.
Le segnalazioni d'errore sono le seguenti…

…oppure…

…oppure…

… dove XXX rappresenta il numero documento fisico che si potrebbe inserire se si andasse in coda e YYY il documento fisico esistente che viene violato da quello in esame. Il primo caso indica la violazione di univocità nei confronti di più documenti che quindi non vengono elencati. Il secondo caso indica la modifica di un documento esistente che non può essere effettuata perché il suo salvataggio comporterebbe la violazione di un altro documento (non pertinente nel caso di libxwwd.so ma potenzialmente presente nelle operazioni di modifica manuale) ed il terzo caso rappresenta il rifiuto del server ad accodare un nuovo documento (in archivi non designati all'update) per una singola violazione di univocità La violazione di univocità si verifica controllando il file <nomearchivio>.conf.xml nell'apposito elemento che la qualifica per ogni unità documentaria.
Se per contro il salvataggio del documento deve essere effettuat e va a buon fine avremo la segnalazione…

…dove XXX è il numero fisico del documento aggiunto al catalogo oppure…

…dove XXX è il numero fisico del documento del catalogo che è stato aggiornato con il documento appena salvato.
Se il salvataggio provoca errore (tipicamente negli vocabolario), la registrazione sarà…

…per gli aggiornamenti ovvero…

…per gli accoramenti. Il numero riportato da KKK è il codice d'errore rilevato.

Il ciclo di salvataggio procede quindi fino al completo esaurimento dei documenti rilevati nel file “.xml.wrk” ma se una delle precedenti condizioni d'errore ne impedisce il completamento il server segnalerà..

…dove KKK è l'ultimo codice di errore rilavato. Al termine, inoltre, essendo presente il file “.xml.fail” il server lo evidenzierà con il log…

…ed inoltre, che l'operazione fallisca o riesca, il server indica la fine delle “ostilità” con il log…

…dove SSS.MMM sono secondi e millisecondi complessivamente impiegati e KKK è '0' o il codice d'errore rilevato.

Se il difetto che dovesse essere rilevato nel file wd_journal.log riguarda la prima fase, quella in cui si deve interpretare il contenuto del file .xml.wrk o quella in cui si valuta la locazione dei files, il problema va studiato nel file rigettato o nella configurazione dell'archivio. Una validazione del primo ed un controllo della sintassi del secondo dovrebbero condurre alla soluzione del problema. I successivi errori di univocità sono da verificare manualmente. Ogni unità documentaria presente nel file .xml.fail porta ad una selezione da farsi secondo la regola di univocità espressa nel file di configurazione d'archivi (<nomearchivio>.conf.xml) e quindi alla determinazione del documento o dei documenti violati. A questo punto si dovrà intervenire in modifica di essi o cambiare quanto necessario nel file .xml.fail perché tale univocità non sia più motivo di violazione. Per errori riconducibili agli indici è opportuno verificare se il numero di documenti presenti in archivio ed il numero di documenti indicizzati è congruo (Vds. <nomearchivi>.stat.xml) e se essi sono disallineati procedere con una “indicizzazione incrementale”. Se il problema permane sarà necessario a ricostruire il vocabolario con un “indicizzazione complessiva”. Per chiarire questi due concetti vedere oltre la parte inerente i Tools.

I Logs di Registro, o Audit Logs, preservano tutte le attività svolte su ciascun DataBase riportando capillarmente ogni intervento effettuato su ciascun record. Per essi viene sempre tracciata la forma del record prima e dopo la modifica in modo da poter sempre compiere una ricostruzione degli eventi ed evidenziare anche l'eventuale presenza di interventi esterni al DataBase da parte di Utenti maliziosi che abbiano avuto accesso diretto ai file dell'archivio. La registrazione riporta l'identificativo dell'utente che è stato utilizzato per compiere l'operazione e, se disponibile, l'IP Address della postazione dalla quale egli ha operato.
Per questa ed altre ragioni è della massima importanza che le soluzioni realizzate impongano l'utilizzo di codici operatore personali e che si adottino tutti gli accorgimenti necessari per impedire l'uso improprio delle credenziali personali.
Il formato di questi file è semi-binario e la loro interpretazione può essere compiuta con software di 3D Informatica. Formato e software non vengono distribuiti e documentati per impedire la maliziosa manipolazione di questi file in modo non riconoscibile.

La condizione di default è che i Logs di Registro vengano stilati per qualsiasi archivio ma è possibile disabilitare questa funzionalità. Per farlo è necessario l'intervento di 3D Informatica che deve produrre per ciascun archivio una speciale chiave di disabilitazione, utilizzabile solo per il detto archivio, che inibisce questo comportamento. Non è facoltà degli amministratori di sistema disabilitarlo.

Nelle versioni più datate del server eXtraWay Standard Edition, i file di log erano denominati xreg<annomese>.log.
In seguito è stata realizzata una cartella con tale nome, priva dell'estensione, ed al suo interno un organizzazione in cartelle giornaliere con relativi contenuti che nel corso del tempo sono stati organizzati secondo alcuni criteri differenti finalizzati a ridurre ai minimi termini gli impatti prestazionali legati alla stesura di questi log.
In fine, per la Enterprise Edition, in ciascuna cartella mensile è presente un singolo file per ogni giorno solare per il quale sono state effettuate registrazioni.

La finalità principale dei Logs di Registro, come detto, è ricostruire il ciclo di vita di ciascun record, dalla sua nascita sino alla sua cancellazione (se e quando prevista ed ammessa dall'applicazione). In alcuni casi specifici è stato utilizzato anche per monitorare le operazioni di consultazione, vale a dire verificare chi abbia avuto accesso a quali documenti ed allegati. Per estendere il comportamento del Registro a queste funzionalità è necessaria una specifica configurazione d'archivio tenendo conto di una crescita considerevole delle registrazioni giornalmente effettuate.

La conservazione dei file redatti dai Logs di Registro è da considerarsi fondamentale per poter ricostruire l'intero ciclo di vita di un record, per tale ragione essi possono essere sottoposti ai più comuni procedimenti di backup nonché compressi e spostati su altri supporti/server una volta che essi siano completi, vale a dire una volta che tutte le registrazioni del periodo cui si riferiscono possano dirsi completate.

I benchmark vengono introdotti nella versione 24 del Server Standard Edition. Modificando il file di configurazione xw.conf.xml si possono avviare logs a fini di benchmark. Essi vengono scaricati sempre nel file xw.log (e precedenti) ed ha la conformazione tipica di una qualsiasi riga di log. Essa sarà quindi composta da un TimeStamp, un Process ID, l'etichetta [B] e, di seguito, una serie di valori rappresentati sotto forma di Comma Separated Values.

Tali valori sono di seguito elencati e raggruppati secondo questo criterio:

• Identificazione del comando e del suo esito, dell'archivio e dell'utente;
• Indicazioni cronologiche generali;
• Misure quantitative e cronologiche delle attività di I/O;
• Misure quantitative e cronologiche delle attività di Indicizzazione;
• Altre misure (memoria, etc. etc.).

Con l'adozione del server Enterprise Edition si è ritenuto opportuno e vantaggioso stilare un distinto set di file di log direttamente in forma di Comma Separated Values per renderlo di più semplice fruizione.
Nell'occasione il contenuto è stato arricchito e dettagliato con maggiori informazioni.

Versione adottata nei file bm.csv del Server Enterprise

Una valida Header per il file è la seguente:

ANNO;MESE;GIORNO;ORA;MINUTO;SECONDO;PID;RET;USER;IP;CMD_MAIN;CMD_LEVEL1;CMD_LEVEL2;CMD_LEVEL3;ARC;TOTAL_TIME;DRY_TIME;CRITICAL_TIME;MACHINE_TIME;OPEN_CNT;SEEK_CNT;SEEK_TIME;READ_CNT;READ_TIME;HDR_READ_CNT;HDR_READ_TIME;WRITE_CNT;WRITE_TIME;HDR_WRITE_CNT;HRD_WRITE_TIME;FLUSH_CNT;FLUSH_TIME;LCK_UNLCK_CNT;LCK_ULCK_TIME;READ_BYTES;WRITE_BYTES;NEW_KEYS;OLD_KEYS;IDX_TIME;PARSE_TIME;BTREE_TIME;REF_TIME;BIN_TREE_CYCLES;BIN_TREE_TIME;LOG_TIME;CLASH;PREAD_TIME;PWRITE_TIME;PDEL_TIME;MEMORY_WORKING_SET;MEMORY_WORKING_SET_DELTA

Di seguito il significato delle principali registrazioni che si incontrano nei files di log.

Sintomo:

In fase di apertura dell'archivio a seguito dello specifico comando o in corrispondenza di qualsiasi altro comando che debba accedere ad un archivio che sia stato chiuso si può presentare questa registrazione sotto forma di Warning. Essa non risulta essere bloccante.

Gli archivi eXtraWay possono essere di due tipi, per così dire. Esistono gli archivi generati regolarmente avvalendosi del Model DEsigner e altri che invece vengono generati editando manualmente il file di configurazione nome_archivi.conf.xml ed avvalendosi, evenutualmente, di una DTD prodotta da terzi o anch'essa generata a mano.
Il secondo caso descritto, quello manuale, è indubbiamente il più frequentemente utilizzato. Esso manca delle registrazioni compiute dal Model Designer per mezzo del Server eXtraWay che riguardano le diverse versioni del file di configurazione d'archivio e della DTD che lo descrive.
Nell'indicare l'indisponibilità del file nomearchivio.descrlst.xml il server sottolinea, in alcune occasioni, che l'archivio è stato generato manualmente e che quindi non è possibile compiere alcune operazioni avanzate, come ad esempio dare un valore di default agli attributi non citati e così via.

Soluzione:

Non è richiesto alcun particolare intervento a meno che l'archivio non sia stato generato con il Model Designer. In tal caso la congifurazione data da tale modulo è andata persa o danneggiata.

Sintomo:

Operazioni di inserimento di documenti o di caricamento in forma bloccata di documenti destinati alla modifica falliscono lasciando traccia di questa segnalazione nel log sotto forma di Error. Segnalazione bloccante.

Le installazioni di eXtraWay prevedono che, parallelamente alla directory degli eseguibili, siano presenti alcune altre directory. Una di queste è la directory context nella quale viene registrato lo stato degli eseguibili in uso, descritto in files nomeeseguibile.devhist.xml ed alcune altre informazioni di contesto. Per contesto si intende la fotografia corrente della struttura organizzativa che si occupa della gestione e manutenzione dei dati contenuti negli archivi che eXtraWay rende disponibili. Il contesto è composto da un insieme articolato di files (non descritti in questa sede) ma il principale di essi è il file context.stat.xml. In tale file vengono registrate tutte le versioni disponibili del contesto che si sono succedute nel tempo ma soprattutto, e questa è l'informazione che ci interessa in questa sede, una denominazione chiara e comprensibile di quale struttra abbia in carico questi archivi.
Questa denominazione viene usata da eXtraWay Server per siglare, con un'apposita Processing Instruction, ogni documento che il server provvederà ad inserire e modificare.
Il file context.stat.xml viene distribuito con un'etichetta fissa

 %NOMESTRUTTURA% 

al posto del vero nome della struttura e per lungo tempo, non essendoci un controllo esatto su questo valore, i documenti sono stati siglati con questa codifica inutile anziché con un valido nome di struttra.
Dalla versione 19.5.0.29 il server compie la verifica che l'etichetta di default sia stata sostituita da un valore valido e da questa segnalazione se la cosa non è avvenuta o se il file context.stat.xml non risulta disponibile.

Soluzione:

Bisogna verificare la presenza del file context.stat.xml nella directory contest. Se esso è assente va richiesto a 3D o recuperato da una procedura d'installazione. Se presente ne va verificato il contenuto ed i valori NOMESTRUTTURA% e VERSIONE% devono essere modificati con il nome della reale struttura che si occupa dei dati e le deve essere assegnata un valido numero di versione.

Sintomo:

Si presenta solitamente sotto forma di Warning in operazioni cicliche quali l'indicizzazione di un archivio o la generazione dei titoli. Può presentarsi anche in operazioni come esportazioni o presentazioni dei titoli.

La registrazione di un errore 819 (Vds. ErrorList: Elenco codici di errore e loro significato.) indica che il documento che ci si appresta a caricare risulta cancellato. Il server non può quindi procedere oltre per quanto riguada quel documento.

Soluzione:

Se la segnalazione si presenta in una delle operazioni cicliche, come ad esempio la ricostruzione di indici, di titoli o l'esportazione di un range (definito numericamente) di documenti, la segnalazione è normale, è fisiologica. In tal caso non c'è bisogno di compiere alcun intervento.
Se invece si presenta a seguito di una selezione (presentazione dei titoli, esportazione documenti selezionati) essa indica che gli indici del canale di ricerca utilizzato sono ancora in grado, erroneamente, di selezionare questo documento. Ciò può essere ricondotto, ragionevolmente, solo ad un danneggiamento degli indici. In tal caso si deve provvedere alla loro ricostruzione.

Sintomo:

Si presenta sotto forma di Error in inserimento documenti. E' un errore bloccante per gli inserimenti lasciando disponibile modifica e consultazione.

Il problema si verifica quando un inserimento scrive uno dei files dell'archivio, l'udp, e non scrive (esce con errore o va in crash prima di scrivere) il file stat.xml. Questo tipo d'errore non si dovrebbe teoricamente mai verificare ma l'esperienza ci dimostra che in alcune condizioni questo avviene.
Quando questo avviene si ha un disallineamento tra il contenuto di due files. Un'indagine accurata degli eventi può mostrare le cause dell'errore e la sua natura (questo stesso sintomo si manifesta per problematiche che hanno aspetti diversi) indicando agli tecnici preposti quali operazioni di manutenzione correttiva possano e debbano essere effettuati sull'archivio.
I dettagli inerenti questo tipo d'analisi sono riservati e non documentati in questa sede.

Soluzione:

L'intervento di allineamento è un'operazione delicata e complessa che deve essere eseguita esclusivamente dal personale 3D. Se, in alternativa a questo tipo di intervento, si ritiene utile rigenerare l'archivio in toto, annullando e rigenerando il catalogo, i titoli e gli indici, quest'operazione può essere compiuta ma non esclude che almeno uno dei files XML sia stato scritto in modo erroneo.

Sintomo:

Si presenta come Warning alla partenza di eXtraWay. Vedi XCrwlT: Nothing to do, libxcrwl unavailable or wrong configuration

Sintomo:

Si presenta come Error alla partenza di eXtraWay. Vedi XCrwlT: Nothing to do, libxcrwl unavailable or wrong configuration

Sintomo:

Si presenta alla partenza del server eXtraWay. Indica che il thread preposto a svolgere i compiti di eXtraWay Crawler non è stato eseguito a causa della mancanza della libreria dinamica libxcrwl.dll/so ovvero a causa della sua mancata o non corretta configurazione.
In caso contrario, se la libreria è presente e la sua configurazione corretta, il server avvia una thread che si occupa di compiere Crawling verso delle fonti di dati o su richiesta o a particolari intervalli di tempo.

Soluzione:

Dal momento che non è possibile sapere, a livello di server eXtaWay, se questo servizio supplementare sia voluto o meno, il server segnala comunque che la sua partenza non ha avuto luogo quando le condizioni richieste vengono meno.
In sostanza, quindi, ogni server in cui questa funzionalità non risulti installata segnalerà questo problema in partenza. In altre parole questo avviene nella stragrande maggioranza dei casi.
Se il servizio è richiesto e previsto bisogna prendere visione della configurazione dello stesso (xcrwl.conf.xml) e verificare la presenza della libreria dimanica suddetta. In ogni altro caso non è necessario compiere alcun intervento.

Sintomo:

Si presenta a seguito del caricamento di un documento quando in esso il contenuto non risulta corrispondente ad un particolare CheckSum calcolato su di esso all'atto del salvataggio. Non produce un errore vero e proprio in quanto il documento, se il riferimento della mappa del catalogo risulta comunque corretto, viene ugualmente caricato, ma deve far suonare un potenziale campanello d'allarme in quanto indica che, pur mantenendo invariate le dimensioni del documento nel file XML, il suo contenuto è stato modificato manualmente.
La CheckSum di cui si parla si può facilmente identificare in coda al documento. Essa è rappresentata da una Processing Instruction avente la forma…

<?xw-crc key32=...?> 

Soluzione:

Il sintomo può in realtà indicare due cose: che qualcuno ha manipolato il documento all'insaputa del server, pur mantenendo le sue dimensioni invariate e quindi il documento correttamente caricabile oppure che un'operazione di manutenzione ha modificato il suo contenuto al di fuori dell'operato diretto di eXtraWay.
Il primo caso è solitamente piuttosto raro in quanto si potrebbe verificare solo in caso di intervento malizioso d parte di un operatore esperto senza dare altri effetti. Se invece l'inervento è più gravoso oltre a questa segnalazione si avrà quindi un errore da parte del Client che riceverà un frammento XML che rappresenta il documento caricato che non è valido.
Il secondo caso, decisamente più frequente, si verifica quando si interviene con procedure di trasformazione sui files XML di un archivio, per cambiarne massivametne il contenuto (cambiare la struttura XML, sostituire un valore con un altro o altre operazioni simili). Dopo un simile intervento si deve compiere un nuovo catalogo ma la firma, il CheckSum di cui si parlava, non corrisponderà più al contenuto (essendo stato modificato senza l'ausilio del motore eXtraWay) ed esso, una volta caricato, non da più alcuna corrispondenza.
Nel primo caso, quindi, si dovrebbe risalire, tramite i logs di registro, alla versione precedente del documento per capire che intervento sia stato fatto e quale dato sia stato danneggiato.
Nel secondo caso, quando si modifica intenzionalmente il contenuto del file XML, è buona norma rimuovere la Processing Instruction che rappresenta questo CheckSum cosi che il server assuma il contenuto di questi documenti come non controllato, acquisito da costituzione catalogo, e non manifesti l'errore.