Con la versione Enterprise di eXtraWay Server è stato introdotto l'utilizzo di Storage Esterni.
Essi assolvono a tre diversi compiti:

• Conservazione di informazioni riferite ai singoli utenti, con particolare accezione dei loro eventuali diritti applicativi e funzionali.
• Conservazione degli allegati d'archivio su Storage Server al posto del file system usato di default.
• Conservazione dei record di Metadati al posto dei file XML di default.

Vediamo i seguenti casi e le relative configurazioni.

Per la registrazione delle informazioni utente, il server eXtraWay si avvale di un semplice LMBD che trova collocazione in una delle cartelle di servizio di eXtraWay. Anche se si tratta di una componente pressoché fissa, essa è configurata come tutti gli altri Storage, perché possa essere sostituita al bisogno.

Rientra nella configurazione delle caches usate da eXtraWay, e non in quella degli storages.

La configurazione di caches e storages utilizzati da eXtraWay si trova nel file storage.conf.xml collocato nella cartella…
/opt/3di.it/extraway/xwee/conf
<drive>:\3di.it\extraway\xwee\conf

Esso si compone di diverse sezioni.

Gli Storage utilizzati assolvono a due scopi: Fungere da cache di dati utili ad eXtraWay ovvero essere veri e propri contenitori di metadati o allegati.

Per la prima tipologia, le caches esiste un apposita sezione che contiene uno o più elementi cache.
Per ciascuno di essi si deve compilare una configurazione:

• '@id': Identificatore che consente ad eXtraWay Server di riconoscere la configurazione di quale cache sta accedendo. Obbligatorio
• '@persistor': Identificatore del persistor che si utilizzerà per questa cache. Obbligatorio
• '@expiry_secs': numero di secondi trascorsi i quali il dato conservato nella cache si considera non più valido. Facoltativo. Default: 24 ore

La seconda tipologia, gli storages, racchiude uno o più elementi storage.
Per ciascuno di essi si deve compilare una configurazione:

• '@id': Identificatore dello storage che si desidera utilizzare. Il legame che si costituisce con questi storage è registrato nei file di configurazione d'archivio. Obbligatorio
• '@persistor': Identificatore del persistor che si utilizzerà per questo storage. Obbligatorio

Si vedano gli esempi per maggior dettaglio.

È l'elenco di tutti i persistor e quindi di ciascuno strumento di storage. La forma assunta da ciascuno di essi, vale a dire le impostazioni in esso contenute sotto forma di elementi ed attributi, varia a seconda della sua tipologia.

Ciascun persistor si caratterizza per mezzo di tre attributi:

• '@name': il nome del persistor così come utilizzato nella sezione delle cache e degli storages
• '@class': la classe del persistor da utilizzare per questo storage, da essa dipendono le configurazioni di dettaglio
• '@policy': il comportamento atteso per il persistor, riferito principalmente a come i record debbano essere salvati e così via.

Le classi attualmente disponibili sono:

• xw::strg::persistor_lmdb: Persistor basato su LMBD.
• xw::strg::persistor_mongo:Persistor basato su MongoDB.

Si vedano gli esempi per maggior dettaglio.

Elenco delle diverse tipologie comportamentali per i vari persistors.
Ciascuna policy è riconosciuta per mezzo di un attributo '@name' che la qualifica. Al suo interno avremo alcuni elementi atti ad indicare le diverse caratteristiche.

• update_existing_only: Quando si richiede l'aggiornamento di un record nello Storage, ma il record con la chiave indicata non esiste, lo Storage deve:
  • Tornare errore in quanto la chiave richiesta non esiste quando il valore dell'attributo è true.
  • Consentire il salvataggio del record con la chiave indicata quando il valore dell'attributo è false.
• generate_auto_key: Quando si procede al salvataggio di un record nuovo senza indicare una chiave per il detto record, lo Storage deve:
  • Tornare errore in quanto la chiave non è stata indicata quando il valore dell'attributo è false.
  • Consentire il salvataggio del record generando (e tornando) una chiave univoca quando il valore dell'attributo è true.

Il più classico degli esempi è il seguente:

• Per uno storage di tipo cache è necessario che la chiave con la quale si registra un record sia sempre esplicitata mentre l'aggiornamento di una chiave inesistente è tollerabile e si trasforma, in pratica, in inserimento.
• Per uno storage di metadati non è ammesso modificare record inesistenti mentre è lecito (ed anzi normale) che la chiave di un nuovo record venga generata dal peristor prescelto.
• Per uno storage di allegati si opera esattamente all'opposto: è ammesso aggiornare un allegato non esistente (quindi inserirlo) ma la chiave con la quale lo si genera dev'essere sempre esplicitata in quanto viene calcolata da eXtraWay.

Si vedano gli esempi per maggior dettaglio.

Di seguito un esempio “commentato” di file di configurazione.

<?xml version="1.0"?>
<config>
   <policies>
      <policy name="default">
         <!-- Politica di base, minimale.
              Si aggiorna solo quello che esiste, ma una chiave non dichiarata viene generata.
         -->
            <update_existing_only>true</update_existing_only>
            <generate_auto_key>true</generate_auto_key>	
      </policy>
 
      <policy name="db_mode_policy">
         <!-- Politica per Storage di METADATI.
              Si aggiorna solo quello che esiste, ma una chiave non dichiarata viene generata.
         -->
         <update_existing_only>true</update_existing_only>
         <generate_auto_key>true</generate_auto_key>	
      </policy>
 
      <policy name="media_mode_policy">
         <!-- Politica per Storage di ALLEGATI.
              Si opera in 'upsert' ma la chiave va sempre dichiarata.
         -->
         <update_existing_only>false</update_existing_only>
         <generate_auto_key>false</generate_auto_key>	
      </policy>
 
      <policy name="lmdb_cache_policy">
         <!-- Politica per CACHE.
              Si opera in 'upsert' ma la chiave va sempre dichiarata.
         -->
         <update_existing_only>false</update_existing_only>
         <generate_auto_key>false</generate_auto_key>	
      </policy>
   </policies>
 
   <persistors>
      <!-- Persistor per la CACHE. Usa la 'lmdb_cache_policy' -->
      <persistor name="eXtraWayUsers_persistor" class="xw::strg::persistor_lmdb" policy="lmdb_cache_policy">>
         <path>/var/lib/3di.it/usersData</path>
      </persistor>
 
      <!-- Persistor per Record. Usa una polcy adatta e registra i record su mongo.
           Il nome della collection viene imposto da eXtraWay
      -->
      <persistor name="dcwData" class="xw::strg::persistor_mongo" policy="db_mode_policy">
         <host>localhost</host> <!-- Url di connessione in modalità MongoDB -->
         <dbname>dcwRecords</dbname>
         <!--
            Vedasi la documentazione MongoDB https://docs.mongodb.com/manual/reference/write-concern/
         -->
         <write_concern w="1" j="true" wtimeout="0" />
      </persistor>
      <!-- Persistor per Allegati. Usa una polcy adatta e registra i record su mongo.
           Il nome della collection è lo stesso usato dallo Storage Server ed idem il nome del DB
      -->
      <persistor name="dcwMedia" class="xw::strg::persistor_mongo" policy="media_mode_policy">
         <host>localhost</host> <!-- Url di connessione in modalità MongoDB -->
         <dbname>content_storage</dbname>
         <!--
            Vedasi la documentazione MongoDB https://docs.mongodb.com/manual/reference/write-concern/
         -->
         <write_concern w="1" j="true" wtimeout="0" />
      </persistor>
   </persistors>
 
   <caches>
      <cache id="usersData" persistor="eXtraWayUsers_persistor" expiry_secs="1800"/>
   </caches>
 
   <storages>
      <storage id="dcwData" persistor="dcwData"/>
      <storage id="dcwMedia" persistor="dcwMedia"/>
    </storages>
</config>

Al fine di far uso dell'uno o dell'altro tipo di Storage, i file di configurazione dell'archivio eXtraWay deve essere modificato prevedendo quanto segue:

Uso dello storage per METADATI eXtraWAy EE 2.0.0 e superiori

<storage id="dcwData"/>

Uso dello storage per ALLEGATI eXtraWAy EE 1.6.0 e superiori

<mediaStorage id="dcwMedia" parkInStorage="false" keepTextLocally="true"/> <!-- default values -->

In particolare, questa configurazione ci dice, oltre all'identificatore dello storage che si intende utilizzare e che è configurato nel file storage.conf.xml anche alcune impostazioni che intendiamo dare ad esso.
Nello specifico abbiamo:

• parkInStorage: Il server eXtraWay opera solitamente in questo modo. Quando gli viene dato un nuovo allegato lo colloca in una zona detta area di parcheggio. Assegna al file un ID univoco e lo torna al richiedente il quale lo associa ad un documento che poi salva. Al momento del salvataggio del documento il server eXtraWay sposta il file dall'area di parcheggio nella sua collocazione definitiva su disco, ma se il record non viene salvato l'allegato ricevuto rimane in area di parcheggio ed è potenzialmente cancellabile.
  Utilizzando uno Storage per gli allegati il comportamento sarà il seguente:
  • Valore true: Il nuovo allegato viene inviato immediatamente allo Storage Server anche se poi non verrà associato ad alcun documento. In questo modo si possono generare dei file inutili nello Storage Server, si rende più complesso il processo di calcolo dell'impronta solitamente utilizzato dalle applicazioni eXtraWay ma si guadagna in performance durante il salvataggio del documento.
  • Valore false: Il nuovo allegato trova posto, come sempre, in area di parcheggio e viene spostato nello Storage Server solo all'atto dell'effettivo salvataggio di un documento che lo referenzia. Il calcolo dell'impronta “vecchio stile” e la possibilità di cancellare allegati non assegnati va a discapito delle prestazioni al momento del salvataggio del record.
• keepTextLocally: Un valore true indica al server eXtraWay di non inviare allo Storage Server i file di tipo testuale assoggettati ad indicizzazione e che li conservi invece secondo le modalità canoniche, vale a dire su file system in cartelle numerate. In questo modo, in caso di necessità di rigenerare gli indici, essi possono essere calcolati anche con Storage Server indisponibile.