Molteplici sono gli aspetti che differenziano il server eXtraWay nella sua Enterprise Edition rispetto alla precedente versione Legacy e Community. Di seguito, cercando di dare un po' d'ordine, le informazioni utili per una prima installazione.

• Installazione base eXtraWay Enterprise Edition.
• Verificare le impostazioni del file xwee.ini e xwee.conf.xml
• Insallare il Log Service come servizio.
  • Windows: xwls-0mq -install
  • Linux: da definire, va eseguito ./xwls-0mq &
• Predisporre una cartella con copia di un archivio della version 25 del server eXtraWay Standard
• Rimuovere il contenuto della cartella <nomearchivio>.lazy
• Rimuovere il file <nomearchivio>.profile.xml
• Aprire l'archivio con eXtraWay Enterprise Edition
  • A questo punto devono essere state create due nuove cartelle: <nomearchivio>.refs e <nomearchivio>.title
  • Rimuovere i file <nomearchivio>.ref, <nomearchivio>.vcb, <nomearchivio>.tit e <nomearchivio>.tip
• Prendere visione del file xw.log. In esso si troveranno indicazioni inerenti le chiavi primarie e seriali non corrette. Nella fattispecie si avranno i seguenti messaggi
  • Primary key must be single: XML,Identificativo della chiave
  • Invalid 'non single' serial key: XML,Identificativo della chiave
• Per tali campi si devono compiere interventi nel file <nomearchivio>.conf.xml al fine di porre il server eXtraWay Enterprise in condizione di operare nel migliore dei modi.
  • Nota per DocWay: Gli interventi nei file xdocwaydoc.conf.xml e acl.conf.xml sono relativamente semplici ad eccezione del caso di /aoo/interoperabilita/@cod_aoo e @cod_amm per i quali si deve provvedere a rimuovere questi campi dal test di univocità, impostare le chiavi in modo che sia possibile effettuare una verifica per adiacenza o concatenazione ed effettuare tale test con un trigger autoritativo.
• Chiudere la connessione col server e riaprire l'archivio fino a quando non verranno più rilevati comportamenti non corretti nella configurazione.
• Reindicizzare l'archivio
• Rifare i Titoli.

Per fare il setup di una postazione si deve.

• Scaricare da CVS xw.3rdp.core
• .
• .
• .
• .
• Predisporre la cartella di installazione (c:\3di.it\extraway\xwee ovvero /opt/3di.it/extraway/xwee)
• Creare in tale cartella altre cartelle quali:
  • bin
  • conf
  • db
  • lib
  • logs
  • script¹⁾
  • tmp²⁾ _{(Linux Only)}.
  • wd
• Configurare il server collocando nella cartella conf i file richiesti.
  Essi sono:
  • xwee.ini³⁾
  • xwee.conf.xml, la configurazione principale di eXtraWay Server Enterprise Edition.
  • xwwd.conf.xml, file di configurazione del processo di Watch Doc per mezzo del quale vengono compiute operazioni batch sugli archivi. Esse sono principalmente riferite ad importazioni di record, ma non solo e/o non necessariamente. Potremmo definirlo facoltativo, ma di fatto è una necessità.
  • log.conf.xml, configurazione di tutte le funzionalità di Logging del server.
    Esiste un capitolo apposito che tratta di quest'argomento. Potremmo definirlo facoltativo, ma di fatto è una necessità.
  • jobs.conf.xml, configurazione di batch jobs da eseguire a scadenze temporali ben precise. Facoltativo.

Oltre a questi file di configurazione trovano collocazione in questa cartella file con estensione .stp, in particolare il file italian.stp che rappresenta la stop list di default per le ricerche nei campi testuali.

Il Server e gli altri moduli della Piattaforma percepiscono e reagiscono all'esistenza di alcune variabili ambientali.

Come per le altre versioni del Server eXtraWay i file di configurazione dei moduli binari si trovano nella cartella conf parallela a quella degli eseguibili.

Questi due file prendono le mosse da altri file esistenti nell'ambito standard. Si è cercato di fare “pulizia” delle voci di configurazione, unificare quanto poteva essere unificato e così via. L'obiettivo, a tendere, è quello di avere un solo file di configurazione. Per il momento il file xwee.ini rimane per la sola dichiarazione della registrazione del server e per l'elenco degli archivi a sua disposizione mentre al file xwee.conf.xml spetta il compito di fornire tutte le impostazioni. Di seguito un esempio del file.

<?xml version="1.0" encoding="utf-8"?>
<xwee>
   <conf_manager>
      <refresh_interval_ms>500</refresh_interval_ms>
      <changed_event_dispatch_kind>deepasync</changed_event_dispatch_kind>
   </conf_manager> 
   <plugins>
      <plugin clp="libxwlua.clp" required="true"/>
      <plugin clp="replicactx.clp" required="false"/>
   </plugins> 
   <master fork_wait_time_sec="30"/>
   <temporary_files dir="c:\temp" share="c:\temp">
      <booster slots="60000" slot_size="4096"/>
      <cleaner test_interval_min="10"
               file_max_age_min="60"
               file_min_age_min="5"
               file_min_free_space_ave="2"/>
   </temporary_files>
   <disk min_space_left = "20000000000"/>
   <indexing maximum_parallel_instances="4">
      <memory limit_mb="800"/>
   </indexing>
   <xreg allow_collision="true" allow_undeclared_ip="true"/>
   <debug benchmark="true"/>
   <scripting>
      <change check_time_sec="600"/>
   </scriptingxwee>

Nel dettaglio abbiamo:

Il file xwee.ini somiglia molto a quello della precedente versione ma vengono cambiate alcune denominazioni.

[eXtraWay EE]
SerialNo=02602611200
Config=69920-540021024 175775858-807014914
User=Roberto Tirabassi
Company=3D Informatica
 
[Archives]
test=c:\xwee\db\test\test.stat
acl=C:\xwee\db\dcw\acl\acl.stat
xdocwaydoc=C:\xwee\db\dcw\xdocwaydoc\xdocwaydoc.stat

La sezione eXtraWay EE viene utilizzata per salvare i parametri della registrazione, grazie alla quale il server è abilitato ad utilizzare archivi di grandi dimensioni e/o comunque a fare operazioni modificanti.
La sezione Archives elenca gli accoppiamenti tra nome logico e nome fisico dell'archivio.
Si ricorda in proposito che un archivio il cui nome logico non appaia in quest'elenco viene cercato automaticamente dal server componendo il seguente percorso…

<directory di installazione>/db/<nome logico>/<nome logico>.stat

…dove la directory di installazione è quella in cui si trovano tutte le directory principali (bin, conf, logs, wd etc. etc.)

La configurazione delle operazioni ripetibili

La configurazione delle operazioni ripetibili si effettua per mezzo del file jobs.conf.xml collocato nella cartella conf ove si trovano tutti i file di configurazione.
Di seguito un esempio del suo contenuto.

<?xml version="1.0" encoding="iso-8859-1"?>
<!-- DOCTYPE xwwd_cfg SYSTEM "http://www.3di.it/extraway/jobs_20131015.dtd" -->
<jobs_cfg>
   <!-- Jobs that are done once, on the server Master start -->
   <job arc="sestra" when="once" val="" label="The job that is done at start">
      <cmd stored=".stored.doAgent">
         <parm1>UNO</parm1>
      </cmd>
   </job>
   <!-- Jobs that are done every day at a specific time
      The 'val' value is "HHMM:xxxxxxx" or "HHMM:*" or "HHMM"
      Where HH is the hour of the day, MM is the minute in that hour
      The following part, if present, maps the day of the week where 0 is sunday, 1 is monday
      and so on up to 6 that is saturday.
      A value '1' means "in that day", while any other value menas "jump that day". 
      Wild card '*' means every day of the week and not declared days are "on".
      Sample: Every day "1111111", "*", "111" (the last 4 days ar on since obmitted)
      Sample: "1000001" means during weekend, "0111110" means, during working week
      Sample: "0000011" and "00000" both means on friday and saturday
      The hour can be.
      Skipped, means midnight
      1 single digit: at that hour, between 0 and 9, minutes 00.
      2 digits: at that hour, between 0 and 23
      4 or more digits: at the hour (first 2 digits) and minutes (last 2 digits)
      Behaviour on 3 digit form is undefinded
      So "1:*" is everyday of the week ad 1am
   -->
   <job arc="niterfront" when="at" val="1200:*" label="every day at 12:00">
      <cmd stored=".stored.doTimeJob">
         <parm1>UNO</parm1>
      </cmd>
   </job>
   <!-- Jobs that are done repeatedly each time unit
      The 'val' value is a number that "can be" followed by a letter.
      For no letter or letter [m|M] the units are minutes.
      For letter [h|H] the units are hours
      For letter [d|D] the units are days
      For letter [w|W] the units are weeks
   -->
   <job arc="niterfront" when="every" val="10m" label="each 10 minutes">
      <cmd stored=".stored.doCycleJob">
         <parm1>UNO</parm1>
      </cmd>
   </job>
</jobs_cfg>

Seppure l'esempio è autoesplicativo, elenchiamo i casi e la loro configurazione.

Ogni attività viene correlata ad un archivio, eventualmente fittizio o non utilizzato dal procedimento e finalizzato esclusivamente a dare l'avvio all'attività. Può inoltre disporre di una label che verrà usata nei logs per dare evidenza dell'avvio delle operazioni richieste e pianificate.

All'interno della configurazione dell'azione, poi, la richiesta da svolgere.
Attualmente è possibile evocare un Plug-In o una Stored Procedure con i parametri desiderati, in futuro si potranno svolgere anche altre tipologie di azioni.

La configurazione delle autenticazioni ed autorizzazioni

L'autenticazione e quindi la facoltà di accedere al sistema eXtraWay sono processi normalmente regolati sul fronte applicativo. Nel tempo applicativa è stato anche l'amministrazione dei diritti di cui l'utente gode, ma queste due condizioni possono altresì essere regolate direttamente dal server.
Per quanto concerne l'autenticazione, si può far ricorso ad un apposito provider la cui configurazione è attualmente molto elemenare.

<?xml version="1.0"?>
<config>
   <auth_provider class="xw::secty::authProviderDummy"/>
</config>

In sostanza, il file di configurazione inerente l'autenticazione si limita ad indicare quale classe vada caricata da apposito plug-in del server per regolare tali accessi. In condizioni standard, l'accesso è sempre garantito a qualsiasi utente.
In seguito entra in gioco il processo di autorizzazione, vale a dire l'accoppiamento a ciascun utente di una batteria di diritti fruibili per ciascuna risorsa. Il concetto di risorsa è volutamente ampio e si estende potenzialmente un po' a qualsiasi aspetto della piattaforma eXtraWay. In prima istanza diremo che la principale tipologia di risorsa è l'archivio (o Data Base).

Ciascuna risorsa è responsabile delle impostazioni della propria autorizzazione, per le risorse archivio ecco un esempio di configurazione.

<!-- DOCTYPE xway_cfg SYSTEM "http://www.3di.it/extraway/xway_20070219.dtd" -->
<xway_cfg cfg_ver="001.000.001">
   ...
   <acl_provider class="xw::secty::aclProviderLcps" url="http://www.foo.bar:8080/services/User"/>
   ...
</xway_cfg>
 
In questo esempio il file di configurazione di un archivio è corredato dalle impostazioni necessarie per identificare un ''acl_provider'' che indica la casse del plug-in da utilizzare. La configurazione è poi corredata ad impostazioni proprie che variano da //provider// a //provider//.
 
In assenza di un specifico ACL provider, alla risorsa vengono garantiti i diritti standard.
 
==== storage.conf.xml ====
** La configurazione delle risorse di storage **
 
Queste risorse sono utilizzate in primo luogo per effettuare cache di informazioni utili e condivise tra le diverse istanze di server eXtraWay EE.\\ Come gli altri, anche questo file si colloca nella cartella ''conf''.\\ 
Di seguito un esempio del suo contenuto.\\ 
 
<code xml>
<?xml version="1.0" encoding="iso-8859-1"?>
<config>
   <caches> <!-- Configurazione di tutte le cache -->
      <cache id="usersData" persistor_class="xw::strg::persistor_lmdb" expiry_secs="1800" persistor_init="C:/ProgramData/3di.it/usersData"/>
   </caches>
</config>

Vediamo quali sono le principali voci di configurazione.

A seconda del persistor sono inoltre possibili altri parametri di configurazione che dipendono direttamente da lui e verranno indicati separatamenteo.

Il Server Enterprise può essere configurato per replicare un archivio su una o più destinazioni. Questo può prestarsi a diversi scopi, dal Disaster Recovery alla pubblicazione di una porzione di archivio da un Back Office ad un Front Office e cose simili, dipendentemente dalle modalità con le quali viene effettuata la replica.

In quali condizioni il Server eXtraWay Enterprise decide di replicare un archivio?
L'operazione non viene effettuata su tutti gli archivi ma solo su quelli per i quali viene impostata una particolare configurazione:

   ...
   <profile type="arc.replica" value="on"/>
   ...

Una volta poste le basi perché la replica venga compiuta, essa in cosa consiste?
Quando un archivio è opportunamente configurato, il server tiene traccia di tutte le operazioni considerate “modificanti”, quindi inserimenti, modifiche, cancellazioni ed applicazione di nuovi allegati. Ciascuna di tali operazioni contribuisce alla creazione di una sequenza di comandi che viene conservata perché possa essere consumata da un apposito servizio che, sulla base del file di configurazione di seguito descritto, decide verso quali destinazioni replicare i contenuti ed in che modo farlo.

Il servizio⁸⁾ di replica utilizza il file di configurazione xweereplica.conf.xml, collocato come tutti gli altri file di configurazione nella cartella conf.

<?xml version="1.0"?>
<config>
	<sinks>
		<!-- Spreaders Sinks -->
		<sink name="dcwsud-Sink" class="xw::replica::xwSink" destination="xw://hwadmin@10.17.61.65:5859/xequisud"/>
		<sink name="xdocwaydoc-Sink" class="xw::replica::xwSink" destination="xw://hwadmin@10.17.61.65:5859/dcwcopy"/>
		<sink name="acl-Sink" class="xw::replica::sinkDummy"/>
		<sink name="test-Sink" class="xw::replica::xwSink" destination="xw://hwadmin@10.17.61.65:5859/test"/>
	</sinks>
 
 
	<spreaders>
      <!-- Replica Spreaders -->
      <spreader name="xdocwaydoc">
			<source name="c:\xwee\db\dcw\xdocwaydoc\xdocwaydoc"/>
			<sink name="xdocwaydoc-Sink"/>
      </spreader>
      <spreader name="dcwsud">
			<source name="C:\xwee\db\dcw-equi\xdocwaydoc-equisud\xdocwaydoc"/>
			<sink name="dcwsud-Sink"/>
      </spreader>
		<spreader name="acl" >
			<source name="c:\xwee\db\dcw\acl\acl.stat"/>
			<sink name="acl-Sink"/>
		</spreader> 
		<spreader name="test" >
			<source name="c:\xwee\db\test\test.stat"/>
			<sink name="test-Sink"/>
		</spreader> 
 
	</spreaders>	
 
   <replicas>
      <!--
      <spreader name="xdocwaydoc"/>
      <spreader name="acl"/>
      -->
      <spreader name="test"/>
      <spreader name="dcwsud"/>
   </replicas>
</config>

Nel dettaglio abbiamo:

Il processo di replica distribuisce su una o più destinazioni le operazioni modificanti. Per identificare una destinazione si fa uso di una URL avente la seguente composizione:

protocol://[user[:pwd@]]host[:port]/extra data

• Componenti obbligatorie
  • protocol: Protocollo di comunicazione. Di fatto identifica la tipologia di strumento con il quale dialogare.
    Ne sono stati previsti diversi e l'elenco può crescere.
    Attualmente sono implementati solo quelli verso altri server eXtraWay:
    • xwee: Comunicazione verso un altro Server eXtraWay Enterprise
    • xw⁹⁾: Comunicazione verso un Server eXtraWay Standard
    • mysql, sqlite, oracle: valori previsti ma attualmente non implementati
  • host: Dal punto di vista squisitamente teorico anche questo valore potrebbe essere omesso sottintendendo lo stesso host ove è collocato il servizio di replica, ma renderebbe incompleta la URL.
• Componenti normalmente presenti
  • extra data: Informazioni supplementari sfruttate dal Propagatore applicato ad un determinato protocollo per potersi connettere alla destinazione richiesta.
• Componenti facoltative
  • port: Porta socket cui connettere il protocollo indicato qualora non fosse equivalente allo standard.
  • user: Utente con il quale effettuare la connessione qualora necessario o differente dal default.
  • pwd: Password¹⁰⁾ utilizzata dall'utente di cui al punto precedente qualora necessaria per effettuare il collegamento.

Documentazione in allestimento