Il trattamento degli allegati ha rappresentato, in eXtraWay, un percorso complesso ed articolato.
Generato inizialmente come una costola di quanto fatto in HighWay, ha subito nel tempo proprie modifiche ed ampliamenti.
I capitoli seguenti descriveranno nel dettaglio quanto realizzato.
Il server eXtraWay ha ereditato da HighWay i metodi per la gestione degli allegati.
Internamente ad ogni unità informativa viene registrato il codice dell'allegato ovvero il numero progressivo ad esso assegnato dal server quando l'allegato viene salvato. Per mezzo di questo codice l'applicazione ha facoltà di reperire l'allegato ed ottenerne una copia dal server.
L'algoritmo che conduce all'allegato (su disco) a partire dal codice salvato nell'unità informativa è sempre stato il seguente:
Tutti gli allegati trovano posto nella directory nomearchivio.file. All'interno di questa directory esiste una ulteriore directory per ogni centinaia di file, il cui nome è il numero delle centinaia fillato a 6 cifre, ed entro di essa si trovano gli allegati, completi d'estensione, anche essi fillati a 6 cifre.
Per comprendere meglio, il file
19.tif
si trova su disco nella posizione
<nomearchivio>.file/000000/000019.tif
così come il file
1234.rtf
si trova su disco nella posizione
<nomearchivio>.file/000012/001234.rtf
L'eredità dal progetto HighWay finisce proprio qui in quanto presso il precedente server, quest'ultimo file si sarebbe chiamato diversamente.
<nomearchivio>.file/000012/000034.rtf
In seguito si è deciso di far intraprendere ad eXtraWay una diversa strada: Tutti gli allegati si sarebbero trovati in prossimità del file XML che ospita le unità informative a cui tali allegati appartengono. In questo modo ricostruire un archivio da un sottinsieme dei dati fisicamente su disco di un archivio esistente è più facile ed efficente non dovendo effettuare complesse operazioni di reperimento di quali siano gli allegati da recuperare.
Ora il comportamento precedentemente adottato è ancora accettato, quindi eXtraWay Server può accedere liberamente agli allegati distribuiti su disco sino all'ultima versione della serie 17, ma dalla serie 18 il comportamento cambia come segue:
Quando un allegato viene aggiunto il server lo dispone nella directory nomearchivio.file, nella radice di tale directory senza dislocarlo in directory ulteriormente nidificate. Non appena questo allegato viene associato ad un documento ed esso viene salvato, l'allegato viene spostato in una sub-directory di quella ove si torva l'XML che ospita l'unità informativa in esame. Tale subdirectory prende lo stesso nome del file XML ma acquisisce l'estensione file.
In breve, quindi, se un'unità informativa viene dislocata nel file
/xw/db/archivio/archivio/2005/document/gennaio.xml
e ad essa viene associato l'allegato codificato come
238.jpg
tale allegato saà disposto su disco nella posizione
/xw/db/archivio/archivio/2005/document/gennaio.file/000238.jpg
La presenza di file allegati nella directory nomearchivio.file indica che tali allegati sono stati assegnati all'archivio ma ancora mai associati ad una unità informativa. Se i files permangono per un tempo eccessivo possono quindi essere rimossi in quanto non è pensabile che verrà più associato ad un'unità informativa. Questo vale solo per i files che si trovano nella radice della directory nomarchivio.file.
Oltre agli allegati sino ad ora citati, ovvero quelli rappresentati da codici numerici sulla base dei quali si ricostruiscono i percorsi effettivi di tali files, un documento può essere associato ad un allegato avente una denominazione assoluta o relativa. In quest'ultimo caso, il percorso espresso deve considerarsi avente origine nella directory nomearchivio.file.
Variazioni a questi comportamenti possono essere ottenute operando su Configurazione degli allegati per archivio..
Gli allegati permangono su disco sino a quando essi risultano correttamente referenziati da un'unità informativa. Non appena il contenuto di quest'unità informativa cambia, perdendo il riferimento all'allegato, o la stessa viene cancellata, tutti gli allegati non più presenti nell'ultima copia del documento (ovvero tutti in caso di cancellazione) vengono rimossi. Ne consegue che non appena viene salvato il documento il server compie una verifica differenziale tra il contenuto del vecchio e (se disponibile) del nuovo documento e rimuove ogni allegato referenziato dal vecchio documento che non sia più presente in quello nuovo.
Prima di compiere la rimozione, comunque, si verifica che lo stesso allegato non sia referenziato da altre unità informative. Questo non dovrebbe essere possibile ma non potendo escludere interventi più o meno manuali sui contentui delle unità informative non è lecito escludere che ciò possa avvenire. Solo se l'allegato non viene referenziato da alcun altra unità informativa, esso viene rimosso. Questa verifica ha particolare peso sino alla versione 17.*.*.* del server, in cui gli allegati hanno una dislocazione comune ed è relativamente semplice porre in due unità informative il riferimento allo stesso allegato. Dalla versione 18.0.0.159 la verifica si compie ancora per quanto sia così improbabile doverne far uso che potrebbe essere evitata.
Quanto detto ha valore sino alla versione del server 19.4.2.5.
Dalla versione successiva vige quanto indicato nel prossimo paragrafo.
Dalla versione 19.5.0.29 il server cambia comportamento in materia di cancellazione degli allegati. Essi, anche se non più referenziati da alcun documento, rimangono esattamente dove si trovano (quindi nella diretory nomearchivio.file ovvero quella espressamente generata in affiancamento al file .xml che ospita le unità informative.
La loro presenza in quella dislocazione consente, in caso di roll back, di identificare chiaramente gli allegati del documento senza che essi vengano persi.
A parte quest'opportunità, in generale, il fatto che l'allegato non venga rimosso vuol'essere una garanzia ulteriore di fronte al rischio di perdita di informazioni soprattutto a seguito di operazioni maliziose effettuate ad esempio da utenti aventi diritti avanzati utilizzando tools che superino i controlli propri delle applicazioni.
Gli allegati non più referenziati da alcun documento vengono elencati in un file denominato unreferenced.log presente nella directory nomearchivio.file.
A partire dalla versione 19.5.7.60 il Server eXtraWay ammette anche una nuova modalità per il trattamento degli allegati, modalità in tutto e per tutto svincolata da quella appena descritta.
Il presupposto sul quale ci si basa in parte è comune a quanto detto ed in parte, invece, ne è completamente distinto.
Per meglio comprendere, il reperimento degli allegati sul file system segue le stesse regole descritte sino ad ora (per quanto non si prevede che venga realmente sviluppato il riferimento logico agli allegati) quindi i percorsi che identificano i files devono essere assoluti o relativi e, se relativi, la posizione nella quale vengono ricercati è quella, appunto, specifica d'archivio.
L'ipotesi di lavoro è quindi differente rispetto a quelle esposte ed, innanzitutto, non prevede la presenza dell'elemento xw:file.
Le unità informative saranno quindi corredate di uno o più elementi o attributi preposti allo scopo di consentire l'identificazione dell'allegato per mezzo del suo percorso assoluto o realtivo. Da essi deriva tutto il restante comportamento del server.
file system come gli altri ma mantenuti sempre nella directory nomearchivio.file. Questo comportamento non consentirebbe quindi una pulitura periodica di tale directory.Perché gli elementi o attributi vengano riconosciuti come portatori di nomi di allegati è necessario intervenire nel file nomerachivio.conf.xml aggiungendo, per il percorso che identifica la chiave di questi elementi o attributi, l'attributo attach con uno dei seguenti valori:
no: Valore di default che indica che questo XPath non corrisponde ad una componente da trattare al pari degli allegati standard. yes: Indica che i files in esame devono essere trattati come allegati e quindi, la dove fossero codificati e non in forma di percorsi relativi o assoluti, mantenuti in affiancamento ai documenti anche sul file system. Questi allegati non vengono sottoposti ad estrazione del testo ed indicizzazione. index: Esattamente lo stesso significato del valore yes ma con estrazione del testo ed indicizzazione del contenuto se possibile.In queste condizioni il server provvede trattare opportunamente gli allegati e, se ne è prevista l'indicizzazione, cerca di contattare il locale File Conversion Service per farsi tradurre in semplice testo il contenuto del documento allegato e quindi fare gli indici su di esso.
Se l'indicizzazione ha luogo il server alimenta, d'ufficio, la chiave...
XML,/<nome_unità_informativa>//xw:file
... come per gli allegati standard. Così facendo, un'applicazione che avesse allegati di tipo standard e di tipo personalizzato potrebbe comunque contare su un vocabolario comune.
Se un'installazione si avvale del dialogo con il File Conversion Service perché fa uso degli allegati nella modalità personalizzata appena descritta, il Server eXtraWay cercherà di prendere contatto con l'FCS sulla porta standard (4870 - Elenco dei numeri di porta Tcp/Udp utilizzati dai programmi HighWay/eXtraWay) e sulla macchina stessa.
Qualora le impostazioni fossero differenti si può agire sul file di configurazione del server (xw.conf.xml) introducendo una sezione fcs ed impostando i valori di porta socket ed indirizzo del server su cui pera FCS.
L'esempio che segue chiarisce un collegamento ad altro server pur mantenendo la porta standard.
<section name="fcs"> <!-- profile type="fcs.port" value="4870"/ --> <profile type="fcs.address" value="livio.bo.priv"/> </section>
La configurazione del trattamento degli allegati può variare da archivio ad archivio. Essa viene effettuata per mezzo del file nomearchivio.conf.xml e consente di personalizzare diversi aspetti del comportamento di eXtraWay Server.
La configurazione si effettua impostando nel suddetto file degli elementi profile aventi due attributi: type e value. Il primo indica il tipo di profilo, quindi di impostazione, il secondo ne indica il valore.
Vediamo di seguito ogni singolo valore di configurazione impostabile.
file system e di un'eventuale etichetta racchiusa tra parentesi quadre (il valore che verrà indicato al client quando si richiede di rendere disponibile quella risorsa la dove dovesse trattarsi di un supporto removibile). Di seguito un esempio:
... <profile type="attach.idhome" value="f:/no_backup/xdocwaydoc,g:/no_back/att/xdoc,e:/[CD Rom]"/> <!-- Elenco delle directory ove cercare gli allegati in sostituzione a "nomearchivio".file --> ...
Back to Indice delle voci