Funzionamento di XTEND 

Il dizionario

Il dizionario contiene la definizione di tutte le schede di parametrizzazione XTEND.

E' costituito da un insieme di file XML (uno per funzione XTEND) che vengono memorizzati sul server della soluzione X3 nella directory:
X3SOL/dossiers/X3_PUB/X3FOLDER/X_TEND/X_GEN/SITE.

Validazione

Quando lo sviluppatore valida una scheda, viene attivatoun programma di generazione dal dizionario per produrre un file xml.

La validazione genera un nuovo dizionario XML dei parametri XTEND.

Il nuovo dizionario è preso automaticamente in considerazione su reload/F5 della pagina HTML nel browser solo se è contrassegnata l'opzione della scheda di parametrizzazione del sito, funzione Siti Web(GESAYS)'Tecnico\Verifica aggiornamenti\Dizionario web'

Altrimenti bisogna forzare il ricaricamento del dizionario con la url:
'http://hostname:port/xtend/svc/SolutionX3/DossierX3/SiteXtend/admin/reposit/reload'

Dopo aver modificato i parametri X3:

Si consiglia di validare tutto il sito mediante la funzione al fine di ricostruire il dizionario del server XTEND mediante la funzione 'Validazione sito Web(AYTFCYGEN)'.

Vericare attentamente che il sito XTEND sia pubblicato, ovvero che il campo 'Pubblica sito' della scheda 'Sito web' sia contrassegnato.

Accesso ai file X3

Tecnicamente il server XTEND accede ai file X3 mediante il server HTTP (Apache) che è installato di default sulla macchina che ospita il server X3 principale.

La directory root è la directory X3_PUB della soluzione.

L'individuazione degli aggiornamenti si effettua con la lettura del 'TimeStamp' (data ultima modifica) del file.

Il server XTEND legge i file XML e costituisce un database in memoria per ottimizzare l'accesso ai parametri.

Durante il caricamento, XTEND controlla la coerenza del dizionario e genera una eccezione in caso di errore.

In caso di errore di lettura del dizionario
  • Verificare che gli utenti anonimi possano accedere alla directory X3_PUB
    L'url http://hostX3/Adonix_X3SOL/X3FOLDER/X_TEND/X_GEN/XTENDSITE/deve restituire l'elenco dei file xml
  • Sotto UNIX verificare i diritti di accesso dell'utente
Ottimizzazione

Di default il dizionario ed i menù locali sono memorizzati sul server X3.

I parametri console xtend.server.reposit.local=off e xtend.server.menux3.local=off permettono di definire una ubicazione dei file in locale del server X3WEB (ottimizzazione).

In questo caso bisogna copiare le directory dizionario e/o menù locali sotto \WebData\LOCAL\X3SOLUTION\X3_PUB\.

WebData è la directory 'Data' définita durante l'installazione del server X3WEB.

Elaborazione dell'HTML

Lettura

Di default le pagine e tutte le risorse del progetto HTML vengono memorizzate sul server X3 nella directory:
/X3SOL/dossiers/X3_PUB/X3FOLDER/X_TEND/X_HTML/ASAMPLE/LANG/ (dove LANG è il codice lingua del sito).

Lo sviluppatore deve provvedere a 'caricare' le pagine HTML sul server X3 prima di testarle nel proprio browser.

Sotto unix bisogna verificare che tutti i file della directory HTML abbiamo come minimo le autorizzazioni in 'lettura' per tutti gli utenti.

Il processo di lettura delle pagine e di individuazione delle modifiche è identico a quella del dizionario.

Un parametro del sito XTEND permette di attivare/disattivare le verifiche degli aggiornamenti.

Se la verifica è disattivata bisogna utilizzare la url di ricaricamento del dizionario per forzare il server XTEND a prendere in considerazione le modifiche delle pagine.

Parsing

Una pagina web è un file che contiene i tag HTML nei quali lo sviluppatore ha aggiunto i token XTEND.

Dopo il caricamento della pagina, il server XTEND legge il contenuto ed interpreta l'HTML ed i token (parsing) per costituire una rappresentazione in memoria della pagina sotto forma di una struttura di oggetti (DOM).

Ogni oggetto rappresenta un token ed implementa un metodo di calcolo dell'HTML (computeHtml).

La struttura dei token è visibile nella traccia XTEND:
++ corrisponde al livello - CXtdHtmBuild* è la classe dell'oggetto

+CXtdHtmBuildDom - XTEND
++CXtdHtmBuildNodeHtml - HTML
++CXtdHtmBuildTagHead - <HEAD
+++CXtdHtmBuildTagBase - <BASE
++CXtdHtmBuildAdxScriptLibrary - ALIBJS
++CXtdHtmBuildTagHeadEnd - </HEAD
++CXtdHtmBuildTagBody - <BODY
++CXtdHtmBuildTagForm - <FORM
++CXtdHtmBuildAdxTagAnchor - AHOME
++CXtdHtmBuildAdxTagAnchor - AABOUT
++CXtdHtmBuildAdxCND - ADISPUSERLOGGEDIN
+++CXtdHtmBuildAdxTagAnchor - AUSERACCOUNT
+++CXtdHtmBuildAdxTagAnchor - ADLKLOGOUT
++CXtdHtmBuildAdxCND - ADISPUSERLOGGEDIN
+++CXtdHtmBuildAdxTagAnchor - ALOGIN
...

Il parser HTML del server XTEND è compatibile con la versione HTML 4.01 (DTD HTML 4.01 Transitional).

L'unico limite che impone XTEND per il design HTML è quello di utilizzare un solo formulario HTML che contenga tutto il corpo (body) della pagina HTML.
<body><form> Contenuto del body </form></body>

Costruzione

Per calcolare in modo dinamico il contenuto della pagina HTML, il server XTEND effettua le seguenti operazioni:

1. Inizializza i blocchi

Per le interfacce di tipo Accesso dati:

  • Costituisce la richiesta (selezione) in funzione dei parametri
  • Chiama il web service mediante l'interfaccia associata all'entità del blocco
  • Crea le entità 'Accesso dati' in memoria

Per le interfacce di tipo Azione:

  • Legge le entità già presenti in memoria
2. Legge in maniera ricorrente tutti gli oggetti della struttura (DOM) è richiama il metodo computeHtml

Se il token è un campo:

  • Il metodo calcola il valore del campo

Se il token è un link dinamico:

  • Il metodo calcola l'url (tag <a></a>) o il JavaScript (tag <input type="button")

Se il token è un blocco:

  • Il metodo effettua una iterazione su tutte le entità e richiama il metodo di calcolo dei token figli

Se il token è un blocco condizionato:

  • Il metodo valuta l'espressione booleena (criteri) e richiama o meno il metodo di calcolo dei token figli
3. Il risultato globale è la somma dell'HTML prodotto da tutti i token

Il metodo di calcolo dell'HTML dipende dal tipo di token e dal tag HTML in cui è inserito.

Generazione dell'html

L'HTML calcolato è funzione del tipo di token e del tag HTML in cui è inserito.

Token campo nei tag <td>,<div>, <span>, <p>...

Sostituisce il contenuto del tag con il valore del campo

<td adx="myField"></td> ---> <td>Valore</td>

Token campo in un tag <select>

Seleziona l'opzione che corrisponde al valore del campo generando l'attributo selected

Esempio se il valore di myField è FR l'opzione value="FR" viene selezionata (attribut selected)

<select adx="myField">
    <option value="AT">Austria</option>      
    <option value="FR">Francia</opzione>
</select>
<!--GENERA-->
<select adx="myField">
    <option value="AT">Austria</option>        
    <option selected value="FR">Francia</option>
</select>

Token campo in un tag <img>

Genera l'URL che permette al browser di leggere l'immagine

<img adx="COUNTRYFLAG">
<!--GENERA-->
<img src="/xtend/data/exp(expires,index)/remote/SOL/FLDR/X_TEND/X_HTML/SITE/FRA/FLAGS/BE.gif"/>

Token link dinamico in un tag <a>

Se il token non ha un'azione associata (metodo GET) calcola l'attributo href del tag
Altrimenti (metodo POST) elabora il tag come un bottone (qui in basso)

<a adx="MyDynLink">Logout</a>
<!--GENERA URL'-->
<a href="http://host:port/xtend/page?DLK=MyDynLink&SOL=SOL...">Logout</a>

Token link dinamico in un tag <input type="button">

Calcola la funzione JavaScript xtdDoDlk e la inserisce nell'attributo 'onClick'

I parametri sono contestuali e sono elaborati mediante la libreria XTEND

<input type="button" adx="MyDLK" value="Crea">
<!--GENERA L'ATTRIBUTO ONCLICK'-->
<input type="button"
   onclick="xtdDoDlk(this,'MyDLK',null,null,null,0,null,event,true,'',false,null,true);"
   value="Crea"/> 

Funzione xtdDoDlk

Questa funzione è generata da XTEND nell'attributo onClick per i link dinamici che hanno una azione o una selezione associata.

Attiva il processo JavaScript XTEND di elaborazione delle azioni utente.

Permette anche di trovare il contesto di dati (aCtxTag,aLineIdx) del link dinamico in particolare per i token generati nelle righe dei blocchi.

function xtdDoDlk(aElmt,aDlk,aProtocol,aBlkId,aCtxTag,aLineIdx,aUrlAdd,aEvent,aSubmit,
                  aAutoId,aForceAcceptReload,aForceSelBlock,aCheckWebFields)
{/*
 aElmt: Oggetto JavaScript su cui l'utente ha cliccato
 aDlk: Codice del link dinamico cliccato
 aProtocol: Se !=null forza il protocollo (https,http) per questo link
 aBlkId: Codice del blocco di riferimento se adx='MyBlocRefence.MyLink'
 aCtxTag: Identificativo del contesto di dati (se azione con parametri di tipo campi XTEND)
 aLineIdx: Indice della riga se il token è posizionato in un blocco {{multi}}
 aUrlAdd: Contiene il valore del parametro HTML xanchor adx="MyLink:xanchor=#section"
 aEvent: Contiene l'oggetto evento JavaScript
 aSubmit: True per sottomettere il formulario
 aAutoId: Id generato da XTEND se adx="MyLink:xautoid"
 aForceAcceptReload:True per accettare il reload (F5)
 aForceSelBlock:Id del blocco che elabora la richiesta se != AMAIN
 aCheckWebFields:True per controllare i campi web
*/
}  

Il contesto di dati della pagina è memorizzato nella pagina stessa in un tag span nascosto.
Contiene tutti i valori dei campi (tipo 'Token campo') utilizzati in parametro delle azioni dei link dinamici della pagina.
Questo metodo permette di gestire molto efficacemente il poter tornare indietro mediante la funzione 'Back' del browser.

<span id="xtdctx" style="display: none; clear: both;">
    XML che contiene il contesto della pagina
</span>

Il contesto di dati server

Per comprendere il funzionamento XTEND, è necessario dettagliare il meccanismo di risoluzione del valore di un campo da parte del server XTEND.

Il server XTEND preserva un contesto di dati che gestisce in una sequenza (o stack) di blocchi di dati (entità).

Questo contesto di dati è costituito:

  • Da una parte statica, indipendente della pagina
      • Costituita dai dati della sessione utente cioè le entità di tipo 'sessione' e dalle entità di tipo 'azione'
  • Da una parte dinamica, dipendente dei token blocchi inseriti nella pagina
      • Constituita dalle entità di tipo 'accesso dati' create durante l'elaborazione dei token blocchi
Gestione del contesto

Stato iniziale

Quando la costruzione della pagina si avvia, il contesto di dati contiene solo i dati della sessione.

Elaborazione dei blocchi

Quando il server XTEND elabora un blocco, effettua una iterazione su tutte le entità selezionate.
Per ogni entità effettua la seguente elaborazione:

1. Impila (push) il dato (entità) nel contesto dei dati
-->L'entità è posizionata sulla cima della pila (top) e sarà elaborata per prima durante la risoluzione del valore di un campo.

2. Chiama il metodo di costruzione dell'HTML dei token figli
-->Questo meccanismo è ricorrente e permette di mettere in pila i blocchi.

3. Estrae dalla pila l'entità
-->Dopo aver elaborato tutti i token figli il server estrae l'entità dalla pila prima di elaborare quella successiva

L'entità che è in cima alla pila è indirizzata dal blocco ACURRENT.
Per esempio un criterio di selezione 'CODE=ACURRENT.CODE' in un link dinamico indica che bisogna selezionare l'elemento delle riga corrente

Risoluzione

Il principio di risoluzione del valore di un campo consiste nel:

1. scorrere la pila delle entità dall'alto (top) verso il basso (bottom)

2. fermarsi quando l'entità letta contiene un campo con lo stesso nome

Se è stato trovato un campo, XTEND restituirà il valore di questo campo, viceversa restituirà un valore nullo.

L'esempio qui in basso mostra lo stato della pila con un blocco di 'fondo' mono-record (BLOCMONO) due blocchi multi-record connessi (BLOCMULTI1, BLOCMULTI2).

Il primo blocco multi è posizionato sulla 2° riga ed il 2° blocco (BLOC2) è posizionato sulla 3° riga.

<!adx="BLOCMONO">
    <!adx="BLOCMULTI1">
        <!adx="BLOCMULTI2">
            <span adx="MyField">
        <!adx="BLOCMULTI2">
    <!adx="BLOCMULTI1">
<!adx="BLOCMONO">

Pila

Ordine

ASESSION

3 - Bottom

ENTITA_BLOCMONO

2

ENTITA_BLOCMULTI1_RIGA2

1

ENTITA_BLOCMULTI2_RIGA3

0 - Top

Per risolvere il valore del campo MyField il server XTEND verificherà la presenza del campo MyField nelle entità secondo l'ordine qui in basso:

1. ENTITA_BLOCMULTI2_RIGA3

2. ENTITA_BLOCMULTI1_RIGA2

3. ENTITA_BLOCMONO

4. ASESSION

Il principio di risoluzione del valore è lo stesso per:

  • I token campi
  • I parametri/criteri di tipo 'Token campo' (Blocco.Campo) utilizzati:
      • Nei criteri di selezione dei blocchi e link dinamici
      • nei parametri delle azioni web
      • Nei criteri delle formule dei blocchi condizionati

Per calcolare il valore di un campo per una entità data bisogna utilizzare le seguenti sintassi:

  • ASESSION.MyField
      • Legge il valore nel contesto sessione
  • MyBlock.MyField
      • Se MyBlock è un blocco mono-record legge il valore del campo per questo blocco
      • Se MyBlock è un blocco mutli-record legge il valore del campo per la riga selezionata
  • MyBlock(i).MyField
      • Legge il valore del campo per la iesima riga del blocco (i inizia da 1)
Risoluzione nel contesto sessione

Il contesto sessione è costituito dai vari blocchi di dati qui in basso.

La risoluzione del valore di un campo è effettuata secondo l'ordine di presentazione dei blocchi nell'elenco.

1. AUSERINF - Informazioni utente autenticato

2. AUSERVAR - Variabili utente

    • Contiene campi creati mediante le funzioni JavaScript xtdAjaxSetUserVar e xtdSetUserVar
    • Utilizzato per salvare i dati client sul server

3. ASITE - Documento sito

    • Accesso ai valori dei campi 'Parametri liberi' della scheda del sito
    • <span adx="ASESSION.MyFreeField"></span> visualizza il valore del parametro libero di codice MyFreeField

4. AMESS - Messaggi utente

    • Contiene i messaggi restituiti da X3

5. AUSERCRIT - Criteri utente

    • I criteri di selezione sono salvati e ripristinati mediante il parametro HTML xcrit
    • <input type="text" adx="MyCriteria:xcrit">

6. ASYSVAR - Variabili sistema

    • Contiene solo il campo ATODAY

7. ACONST - Token campo di tipo costante

L'elaborazione di una richiesta HTTP

Le richieste http

Nell'architettura X3WEB che ospita il server XTEND si hanno 3 livelli applicativi:

1. il server frontale Apache HTTP che elabora le richieste HTTP

2. il server Apache Tomcat che ospita le 'applicazioni web'

3. l'applicazione web XTEND

Le richieste http a destinazione dell'applicazione web XTEND sono identificate dall'URI che inizia con /xtend/*.

Il 'path' dell'applicazione web XTEND è parametrizzabile mediante la console tramite i parametri avanzati:
xtend.server.virtualpath.context=xtend

L'applicazione web sa elaborare un determinato numero di richieste (servlets) identificate dal 2° parametro dell'URI /xtend/servlet/:

  • /xtend/page/* gestisce la costruzione della pagina HTML
  • /xtend/data/* gestisce l'accesso ai dati file (immagini, flash, file pdf...) su X3 oppure in locale
  • /xtend/admin/* gestisce le richieste di amministrazione utili per lo sviluppatore
  • /xtend/svc/* gestisce le richieste di amministrazione utili per lo sviluppatore (traccia, gestione cache, reload...)
Metodo GET o POST

Il protocollo HTTP propone diversi metodi o istruzioni che specificano il tipo di azione che effettua la richiesta.

Il server XTEND risponde solo ai metodi GET e POST che hanno il seguente significato:

Un link dinamico usa di default il metodo POST se gli è associata una selezione o una azione.
Questo metodo sottomette (submit) il form HTML <form></form> della pagina mediante la chiamata della funzione JavaScript xtdDoDlk.
Questa funzione calcola i parametri del link dinamico (xml) e li invia in un campo input hidden.
Il server riceve tutte le informazioni di cui ha bisogno per elaborare l'azione o la selezione associata al link dinamico su cui ha cliccato (dati dei campi del formulario e del contesto calcolato dal client).

Un link dinamico può utilizzare il metodo GET se effettua solo una connessione su una pagina o se non ci sono parametri di azione o di selezione da calcolare.
Questo metodo non sottomette il form HTML ma connette il browser su una URL che contiene solo i parametri del database (link, soluzione, dossier, sito, lingua).

Solo il metodo GET è compatibile con i motori di ricerca (web crawlers).

Utilizzo di un 'reverse proxy'

Per ragioni di sicurezza, l'utente del web può passare da un reverse proxy per accedere alle applicazioni di server interni.

L'utilizzo di un reverse proxy permette anche di nascondere agli utenti l'indirizzo reale di un server e facilita la manutenzione di un sito.

In caso di arresto di un server si potrà reindirizzare temporaneamente le richieste su un altro server in modo trasparente per il client.

Per definire un 'reverse proxy' con alias proxyxtend nel server Apache del server X3WEB hostproxy che "rendirizza" le richieste XTEND su hostxtend si utilizza la seguente configurazione.

File Apache2.2\conf\httpd.conf

Creare un 'virtual host' sulla porta 80

<VirtualHost _default_:80>
    <Location "/proxyxtend/">
         ProxyPass                                "http://hostxtend:28980/"
         ProxyPassReverse                     "http://hostxtend:28980/"
         ProxyPassReverseCookieDomain "hostxtend"   "hostproxy"
         ProxyPassReverseCookiePath       "/xtend"       "/proxyxtend/xtend"
    </Location>
</VirtualHost>

File Apache2.2\conf\extra\httpd-ssl.conf

<VirtualHost _default_:443>
...
    ProxyRequests Off
    SSLProxyEngine on
    ProxyPreserveHost On
    <Location "/proxyxtend/">
         ProxyPass                                "https://hostxtend:28943/"
         ProxyPassReverse                     "https://hostxtend:28943/"
         ProxyPassReverseCookieDomain "hostxtend"   "hostproxy"
         ProxyPassReverseCookiePath       "/xtend"      "/proxyxtend/xtend"
         SSLRequireSSL
    </Location>
...
</VirtualHost>  

Configurazione XTEND

Quando il server Apache hostproxy riceve la url http://hostproxy/proxyxtend/xtend/page/*.
Il si comporterà come un mandatario ed effettuerà per il client la richiesta http://hostxtend/xtend/page/* sul serveur XTEND.

Il server XTEND che calcolerà la pagina HTML da restituire al client deve prendere in considerazione il reverse proxy per generare URL che siano corrette per il client finale (il browser).

Nel nostro caso, XTEND deve generare le URL in /proxyxtend/xtend/*.
Deve obbligatoriamente tenere conto della presenza del reverse proxy per calcolare le URL.

Il metodo utilizzato da XTEND è il seguente:

-1- Dichiarazione dei reverse proxie

Dichiarazione delle porte http e https dei 'reverse proxie' mediante la console di amministrazione e modificando i seguenti parametri avanzati:

# Configurazione reverse proxie
xtend.server.gensetup.proxies.hosts=      hostproxy1   hostproxy2
xtend.server.gensetup.proxies.portshttp=  80           80
xtend.server.gensetup.proxies.portshttps= 443          443

-2- Lettura del 'Referer' HTTP

L'header HTTP Referer contiene la url che è stata utilizzata dal client per raggiungere il server

Il server XTEND analizza questa URL e ne deduce la presenza di un reverse proxy se /xtend/ è prefissato da un valore (esempio /proxyxtend/xtend/).

La configurazione precedente permette di gestire i cambi di protocollo http->https o viceversa. Il server XTEND deve obbligatoriamente conoscere le porte http et https del reverse proxy.

Per funzionare correttamente con un reverse proxy il server XTEND deve conoscere obbligatoriamente il 'Referer' http e le porte http e https del (primo) reverse proxy.

Il parametro di configurazione xtend.server.gensetup.http.askreferer=on/off (on di default) permette di attivare o disattivare questo meccanismo.

L'header http 'Referer' non è sempre presente, in particolare quando si inserisce l'indirizzo nella barra di indirizzi del navigatore.

Se l'header http 'Referer' non è presente nella richiesta, il server XTEND invia verso il navigatore un formulario vuoto con risposta automatica (trasparente per l'utente) che nella maggior parte dei casi restituisce il 'Referer'.

Se il tentativo fallisce e se il 'Referer' non è inviato, il server XTEND non potrà prendere in considerazione la presenza di un reverse proxy.

La sessione

Il protocollo di comunicazione tra il browser web ed il server HTTP è il protocollo HTTP che è "senza stato".
Il server HTTP non conserva nessuna traccia del client dopo elaborazione della richiesta.
Tutto si svolge come se la connessione tra il client ed il server fosse interrotta dopo ogni richiesta.

Il modo di funzionamento è completamente diverso dalla modalità client/server (client X3) che mantiene una connessione attiva tra il server X3 durante tutta la durata della sessione.

Per sviluppare applicazioni web è necessario fare il link tra varie richieste per associarle ad uno stesso client.
Questo link è effettuato tramite l'utilizzo dei cookies HTTP.

Un cookie è creato per iniziativa del server quando quest'ultimo invia al client una istruzione 'set cookie' nella testata HTTP.
Il cookie è in seguito restituito dal client nella testata HTTP di tutte le richieste con destinazione questo server.

Istruzione
Set-Cookie: JSESSIONID=3C9B3EF39FB53069ACB02B6ADA5551A1; Path=/xtend
Path permette di filtrare i cookie a destinazione del server
Nel nostro caso JSESSIONID verrà inviato in tutte le richieste la cui URL inizia con /xtend/ (http://host:port/xtend/....)

L'identificazione tramite cookie (e quindi il funzionamento dell'applicazione web) funziona solo se il browser autorizza i cookie di tipo sessione (non memorizzati).
E' normalmente il set up di default dei browser web

La nozione di 'client' varia a seconda dei browser e dipende dalla maniera in cui questi gestiscono i cookie.

  • Per FireFox i cookie sono condivisi tra le istanze dei browser.
    Se ci si connette ad uno stesso sito XTEND sulla stessa postazione con due browser FireFox essi condivideranno la stessa sessione XTEND.
    I browser sono visti lato server come un solo client.
  • Per IE6 i cookie non sono condivisi tra le istanze dei browser.
    Se ci si connette ad uno stesso sito XTEND sulla stessa postazione con due browser IE6 essi avranno ognuno una sessione.
    I browser sono visti lato server come due client diversi.
  • I folder nell'ambito di uno stesso browser condividono gli stessi cookie e sono visti come un solo client.
Sessione TOMCAT

La sessione utente che permette di associare un contesto di dati specifico ad ogni client è gestito dal server TOMCAT mediante la nozione di servlet.

Per identificare le richieste e reindirizzarle verso la sessione utente corretta il server TOMCAT gestisce una sessione cookie specifica col codice JSESSIONID.

Cookie gestito dal server TOMCAT
Set-Cookie: JSESSIONID=3C9B3EF39FB53069ACB02B6ADA5551A1; Path=/xtend
JSESSIONID è l'identificativo della sessione TOMCAT

Il cookie JSESSIONID non è persistente, cioè non rimane quando si chiude il browser.
L'utente perde la sessione e quindi il contesto di dati se chiude il suo browser.

La sessione è conservata in memoria nel corso di una durata parametrizzabile mediante il parametro di configurazione console:
xtend.server.gensetup.http.session.timeout
Questo parametro indica la durata di inattività, in minuti, tollerata dal server TOMCAT per una sessione utente.
Se non viene individuata nessuna attività (richiesta ricevuta) durante questo periodo, la sessione è cancellata ed il contesto dei dati è perso.

Meccanismo di riconnessione

Il server XTEND gestisce il proprio identificativo di sessione mediante il cookie XADXID.
Questo cookie è persistente, vale a dire che viene salvato dal browser (se autorizzato).

Quando l'utente apre il suo browser e si connette al server XTEND, il cookie XADXID è inviato nella richiesta (se esiste) ed il server tenta di ritrovare la sessione (TOMCAT) dell'utente per riconnetterla.

Cookie gestiti dal server XTEND
Set-Cookie XADXID=123332746651556912893670; Expires=Sat, 30-Jan-2010 14:57:46 GMT; Path=/xtend

Il parametro di configurazione consolextend.server.gensetup.http.cookie.sess.persist=on (on di default) permette di attivare/disattivare la gestione della riconnessione in seguito alla chiusura del browser.

La pagina di riconnessione del sito (facoltativa) permette di informare l'utente che la sua sessione è stata ripristinata.

Funzionamento senza i cookie

XTEND propone una modalità di funzionamento senza cookie che trasmette l'identificatore di sessione JSESSIONID nella URL.

Questa modalità può essere attivata, sia:

  • Dall'utente mediante l'azione web ASESSSWITCHCOOKIES o il link dinamico ADLKSWITCHCOOKIES
  • Di default per tutte le sessioni mediante il parametro di configurazione console
    xtend.server.gensetup.http.cookie.disabled=on - off di default.

La modalità senza cookie aumenta la dimensione delle URL aggiungendo un parametro supplementare
http://ecfdalbopro:28980/xtend/page;jsessionid=E04AEF0615702B3C7E52107ED6C17D8A?DLK=DLKTESTMAPPING...

Questa modalità non permette l'utilizzo di link verso altri siti web in quanto l'id session non è trasmesso e la sessione utente è persa.

Elaborazione server

Questo paragrafo descrive il processo di elaborazione delle richieste HTTP dal server XTEND.

Apache HTTP server

1. Ricevimento della richiesta HTTP

    • Gestisce il protocollo protetto HTTPS

2. Filtra la richiesta in funzione dell'URL

  • Solo le URL che iniziano con '/xtend/*' sono elaborate da XTEND
    Parametro console xtend.server.virtualpath.context
  • E' il file httpd.conf che contiene la configurazione del server Apache
    Questo file è generato durante la configurazione del server X3WEB

3. Trasferisce la richiesta su 'Apache TOMCAT server' via il mod_jk
mod_jk : 'modulo Jakarta' che è il nome del progetto di software liberi da cui è derivato il progetto TOMCAT

JkMount xtend/portal* ajp13
JkMount xtend/page* ajp13
JkMount xtend/err/* ajp13
JkMount xtend/ajax/* ajp13
JkMount xtend/x3rsrc/* ajp13
JkMount xtend/htmrsrc/* ajp13
JkMount xtend/x_protect/* ajp13
JkMount xtend/data/* ajp13
JkMount xtend/svc/* ajp13
JkMount xtend/*.jsp ajp13

Apache TOMCAT server

1. Crea un job (thread) per l'elaborazione della richiesta

2. Ritrova il servizio (oggetto servlet) identificato dall'URL

    • /xtend/page/* per l'elaborazione delle pagine HTML

3. Ritrova la sessione con il cookie JSESSIONID

    • Crea una nuova sessione se non trovata

4. Richiama metodo doPost o doGet del servizio

    • Un parametro httpRequest contiene i dati della richiesta http e la sessione utente
    • L'elaborazione della web application XTEND inizia qui
Web application XTEND

1. Inizializzazione

1. Se nuova sessione TOMCAT

    • Elaborazione riconnessione mediante il cookie XADXID
    • Richiesta http referer (presa in considerazione dei 'reverses proxies')

2. Se redirezionamento (cambio di protocollo...)

    • Elaborazione della URL di redirezionamento 

3. Lettura dei parametri XTEND

    • Metodo GET: Parametri dell'URL
    • Metodo PUT: Parametri XML nel campo XTDXML del formulario HTML
      Parametri: link dinamico cliccato, pagina richiesta, parametri dell'azione...

2. Apertura sessione

1. Messa in attesa se sessione in corso di utilizzo da un'altra richiesta

    • Parametro console xtend.session.wait.timeout 

2. Posizionamento del contesto sul sito XTEND

    • Il codice SolutionX3/DossierX3/SiteXtend è passato nel parametro di ogni richiesta
    • Se nessun parametro o sito inesistente sarà il sito di default ad essere scelto
    • Parametri console xtend.server.gensetup.defsite.x3sol,x3fldr,xtdSite 

3. Verifica degli aggiornamenti del dizionario XTEND

    • Parametri tecnici del sito "Verifica aggiornamento"

3. Controlli

1. Controllo del protocollo

    • Se il protocollo (http o https) della richiesta non è quello definito per la pagina
      • Invio di una redirection al client (Http status=302) per 'switchare' di protocollo 

2. Se utente firmato: controllo durata di inattività della sessione XTEND

    • Parametro 'Timeout session(mn)' della scheda sito

3. Se la pagina è protetta
Parametro 'Accesso protetto' della scheda pagina 

1. Controllo dei diritti di accesso dell'utente

    • Controllo in funzione del profilo se utente firmato

2. Se l'utente non ha diritti di accesso.

    • Reindirizzamento sulla pagina di login definita nella scheda sito
    • Salvataggio del contesto (pagina destinazione, azione) per ripristino dopo login

4. Elaborazione dell'azione web se una azione è associata al link dinamico

  • L'azione può modificare la pagina di destinazione
  • Per esempio se si verifica un errore si rimane sulla pagina corrente e si visualizza il messaggio X3

5. Visualizzazione della pagina

1. Verifica degli aggiornamenti della pagina

          • Parametri tecnici del sito "Verifica aggiornamento"

2. Inizializzazione dei token blocco (richieste)

          • Chiamata dei web service di tipo Accesso dato

3. Calcolo dell'HTML

          • Analisi della struttura dei token
          • Chiamata del metodo computeHtml

6. Invio della risposta al browser