Fonctionnement d'XTEND 

Le dictionnaire

Le dictionnaire contient la définition de toutes les fiches de paramétrage XTEND.

Il est constitué d'un ensemble de fichiers XML (un par fonction XTEND) qui sont stockés sur le serveur de la solutionX3 dans le répertoire :
X3SOL/dossiers/X3_PUB/X3FOLDER/X_TEND/X_GEN/SITE.

Validation

Lorsque le développeur valide une fiche, un traitement de génération du dictionnaire est activé pour produire le fichier xml.

La validation génère une nouveau dictionnaire XML des paramètres XTEND.

Le nouveau dictionnaire n'est pris en compte automatiquement sur reload/F5 de la page HTML dans le navigateur que si l'option de la fiche de paramétrage du site, fonction Sites Web(GESAYS)'Technique\Vérifier mises à jour\Dictionnaire web' est cochée.

Sinon il faut forcer le rechargement du dictionnaire avec l'url :
'http://hostname:port/xtend/svc/SolutionX3/DossierX3/SiteXtend/admin/reposit/reload'

Après modification des paramètres X3 :

Il est conseillé de valider l'intégralité du site via la fonction afin de reconstruire le dictionnaire du serveur XTEND via la fonction Validation site Web(AYTFCYGEN).

Bien vérifier que le site XTEND est publié, c'est à dire le champ 'Publié le site' de la fiche 'Site web' est coché.

Accès aux fichiers X3

Techniquement le serveur XTEND accède aux fichiers X3 via le serveur HTTP (Apache) qui est installé par défaut sur la machine qui héberge le serveur X3 principal.

Le répertoire racine est le répertoire X3_PUB de la solution.

La détection des mise à jour se fait sur lecture du 'TimeStamp' (date de dernière modification) du ficher.

Le serveur XTEND lit les fichiers XML et constitue une base de données en mémoire pour optimiser l'accès aux paramètres.

Lors du chargement, XTEND contrôle la cohérence du dictionnaire et génère une exception en cas d'erreur.

En cas d'erreur de lecture du dictionnaire
  • Vérifier que les utilisateur anonymes peuvent accéder au répertoire X3_PUB
    L'url http://hostX3/Adonix_X3SOL/X3FOLDER/X_TEND/X_GEN/XTENDSITE/doit renvoyer la liste des fichiers xml
  • Sous UNIX vérifiez les droits d'accès de l'utilisateur
Optimisation

Par défaut le dictionnaire et les menus locaux sont stockés sur le serveur X3.

Les paramètres console xtend.server.reposit.local=off et xtend.server.menux3.local=off permettent de définir une localisation des fichier en local du serveur X3WEB (optimisation).

Dans cas il faut copier les répertoires dictionnaire et/ou menu locaux sous \WebData\LOCAL\X3SOLUTION\X3_PUB\.

WebData est le répertoire 'Data' défini lors de l'installation du serveur X3WEB.

Traitement du HTML

Lecture

Par défaut les pages et toutes les ressources du projet HTML sont stockées sur le serveur X3 dans le répertoire:
/X3SOL/dossiers/X3_PUB/X3FOLDER/X_TEND/X_HTML/ASAMPLE/LANG/ (LANG étant le code langue du site).

Le développeur doit penser à 'uploader' les pages HTML sur le serveur X3 avant de les tester dans son navigateur.

Sous unix il faut bien vérifier que tous les fichiers du répertoire HTML ont les droits minimum en 'lecture' pour tous les utilisateurs.

Le processus de lecture des pages et de détection des modifications est identique à celui du dictionnaire.

Un paramètre du site XTEND permet d'activer/désactiver les vérifications des mises à jour.

Si la vérification est désactivée il faut utiliser l'url de rechargement du dictionnaire pour forcer le serveur XTEND à prendre en compte les modifications des pages.

Parsing

Une page web est un fichier texte qui contient des balises HTML dans lequelles le développeur a ajouté les tokens XTEND.

Après chargement de la page, le serveur XTEND lit le contenu et interprète le HTML et les tokens (parsing) pour constituer une représentation en mémoire de la page sous la forme d'un arborescente d'objets (DOM).

Chaque objet représente un token et implémente une méthode de calcule du HTML (computeHtml).

L'arborescence des tokens est visible dans la trace XTEND:
++ correspond au niveau - CXtdHtmBuild* est la classe de l'objet

+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
...

Le parser HTML du serveur XTEND est compatible avec la version HTML 4.01 (DTD HTML 4.01 Transitional).

La seule contrainte qu'impose XTEND pour le design HTML est de n'utiliser qu'un seul formulaire HTML qui encapsule tout le corps (body) de la page HTML.
<body><form> Contenu du body </form></body>

Construction

Pour calculer dynamiquement le contenu de la page HTML, le serveur XTEND effectue les opération suivantes:

1. Initialise les blocs

Pour les interfaces de type Accès données:

  • Constitue la requête (sélection) en fonction des paramètres
  • Appel le web service via l'interface associé à l'entité du bloc
  • Crée les entités 'Accès données' en mémoire

Pour les interfaces de type Action:

  • Lit les entités déjà présentes en mémoire
2. Parcourt récursivement tous les objets de l'arborescence (DOM) et appelle la méthode computeHtml

Si le token est un champ:

  • La méthode calcule la valeur du champ

Si le token est un lien dynamique:

  • La méthode calcule l'url (tag <a></a>) ou le JavaScript (tag <imput type="button")

Si le token est un bloc:

  • La méthode effectue une itérations sur toutes les entités et appelle la méthode de calcul des tokens fils 

Si le token est un bloc conditionné:

  • La méthode évalue l'expression booléenne (critères) et appel ou non la méthode de calcul des tokens fils
3. Le résultat global est la somme du HTML produit par tous les tokens.

La méthode de calcul du HTML dépend du type de token et du tag HTML dans lequel est il est inséré.

Génération du html

Le HTML calculé est fonction du type de token et du tag HTML dans lequel il est inséré.

Token champ dans les tags <td>,<div>, <span>, <p>...

Remplace le contenu du tag par la valeur du champ

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

Token champ dans un tag <select>

Sélectionne l'option qui correspond à la valeur du champ en générant l'attribut selected

Exemple si la valeur de myField est FR l'option value="FR" et sélectionnée (attribut selected)

<select adx="myField">
    <option value="AT">Austria</option>      
    <option value="FR">France</option>
</select>
<!--GENERE-->
<select adx="myField">
    <option value="AT">Austria</option>        
    <option selected value="FR">France</option>
</select>

Token champ dans un tag <img>

Génère l'URL qui permet au navigateur de lire l'image

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

Token lien dynamique dans un tag <a>

Si le token n'a pas d'action associée (méthode GET) calcule l'attribut href du tag
Sinon (méthode POST) traite le tag comme un bouton (ci-dessous)

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

Token lien dynamique dans un tag <input type="button">

Calcule la fonction JavaScript xtdDoDlk et l'insère dans l'attribut 'onClick'

Les paramètres sont contextuels et sont traités par la librarie XTEND

<input type="button" adx="MyDLK" value="Créer">
<!--GENERE L'ATTRIBUT ONCLICK'-->
<input type="button"
   onclick="xtdDoDlk(this,'MyDLK',null,null,null,0,null,event,true,'',false,null,true);"
   value="Créer"/> 

Fonction xtdDoDlk

Cette fonction est générée par XTEND dans l'atribut onClick pour les liens dynamiques qui ont une action ou une sélection associée.

Elle déclenche le processus JavaScript XTEND de traitement des actions utilisateur.

Elle permet aussi de retrouver le contexte de données (aCtxTag,aLineIdx) du lien dynamique en particulier pour les tokens générés dans les lignes des blocs.

function xtdDoDlk(aElmt,aDlk,aProtocol,aBlkId,aCtxTag,aLineIdx,aUrlAdd,aEvent,aSubmit,
                  aAutoId,aForceAcceptReload,aForceSelBlock,aCheckWebFields)
{/*
 aElmt: Object JavaScript sur lequel l'utilisateur a cliqué
 aDlk: Code du lien dynamique cliqué
 aProtocol: Si !=null force le protocole (https,http) pour ce lien
 aBlkId: Code du bloc de référence si adx='MyBlocRefence.MyLink'
 aCtxTag: Identifiant du contexte de donnée (si action avec paramètres de type champs XTEND)
 aLineIdx: Index de la ligne si le token est placé dans un bloc {{multi}}
 aUrlAdd: Contient la valeur du paramètres HTML xanchor adx="MyLink:xanchor=#section"
 aEvent: Contient l'objet événement JavaScript
 aSubmit: True pour soumettre le formulaire
 aAutoId: Id généré par XTEND si adx="MyLink:xautoid"
 aForceAcceptReload:True pour accepter le reload (F5)
 aForceSelBlock:Id du bloc qui traite la requête si != AMAIN
 aCheckWebFields:True pour contôler les champs web
*/
}  

Le contexte de données de la page est stocké dans la page elle même dans un tag span masqué.
Il contient toutes les valeurs des champs (type 'Token champ') utilisés en paramètre des actions des lien dynamiques de la page.
Cette méthode permet de gérer très efficacement le retour arrière via la fonction 'Back' du navigateur.

<span id="xtdctx" style="display: none; clear: both;">
    XML qui contient le contexte de la page
</span>

Le contexte de données serveur

Pour bien comprendre le fonctionnement XTEND il est nécessaire de détailler le mécanisme de résolution de la valeur d'un champ par le serveur XTEND.

Le serveur XTEND maintient un contexte de données qui est géré dans une pile (ou stack) de blocs de données (entités).

Ce contexte de données est constitué:

  • D'une partie statique, indépendante de la page
      • Constituée des données la session utilisateur c'est à dire des entités de type 'session' et des entités de type 'action'
  • D'une partie dynamique, dépendante des tokens blocs insérés dans la page
      • Constituée des entités de type 'accès données' créées lors du traitement des tokens blocs
Gestion du contexte

Etat initial

Lorsque la construction de la page démarre, le contexte de données ne contient que les données de la session.

Traitement des blocs

Lorsque le serveur XTEND traite un bloc, il effectue une itération sur toutes les entités sélectionnées.
Pour chaque entité il effectue le traitement suivant:

1. Empile (push) la donnée (entité) dans le contexte de données
-->L'entité est positionnée au sommet de la pile (top) et sera traitée en premier lors de la résolution de la valeur d'un champ

2. Appelle la méthode de construction du HTML des tokens fils
-->Ce mécanisme est récursif et permet d'empiler les blocs

3. Dépile l'entité
-->Après avoir traité tous les tokens fils le serveur dépile l'entité avant de traiter la suivante

L'entité qui est au sommet de la pile est adressée par le bloc ACURRENT.
Par exemple un critère de sélection 'CODE=ACURRENT.CODE' dans un lien dynamique indique qu'il faut sélectionner l'élément de la ligne courante

Résolution

Le principe de résolution de la valeur d'un champ consiste à :

1. parcourir la pile des entités du haut (top) vers le bas (bottom)

2. s'arrêter lorsque l'entité lue contient un champ de même nom

Si un champ a été trouvé XTEND renverra la valeur de ce champ sinon il renverra une valeur vide.

L'exemple ci dessous montre l'état de la pile avec un bloc de 'fond' mono-enregistrement (BLOCMONO) deux blocs multi-enregistrements imbriqués (BLOCMULTI1, BLOCMULTI2).

Le premier bloc multi est positionné sur la 2eme ligne et le deuxième bloc (BLOC2) est positionné sur la 3eme ligne.

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

Pile

Ordre

 ASESSION

3 - Bottom

ENTITE_BLOCMONO

2

ENTITE_BLOCMULTI1_LIGNE2

1

ENTITE_BLOCMULTI2_LIGNE3

0 - Top

Pour résoudre la valeur du champ MyField le serveur XTEND va vérifier la présence du champ MyField dans les entités suivant l'ordre ci-dessous:

1. ENTITE_BLOCMULTI2_LIGNE3

2. ENTITE_BLOCMULTI1_LIGNE2

3. ENTITE_BLOCMONO

4. ASESSION

Le principe de résolution de la valeur est le même pour :

  • Les tokens champs
  • Les paramètres/critères de type 'Token champ' (MonBloc.MonChamp) utilisés dans :
      • Les critères de sélection des blocs et liens dynamiques
      • Les paramètres des actions web
      • Les critères des formules des blocs conditionnés

Pour calculer la valeur d'un champ pour une entité donnée il faut utiliser les syntaxes suivantes :

  • ASESSION.MyField
      • Lit la valeur dans le contexte session
  • MyBlock.MyField
      • Si MyBlock est un bloc mono-enregistrement lit la valeur du champ pour ce bloc
      • Si MyBlock est un bloc multi-enregistrement lit la valeur du champ pour la ligne sélectionnée
  • MyBlock(i).MyField
      • Lit la valeur du champ pour pour la ieme ligne du bloc (i commence à 1)
Résolution dans le contexte session

Le contexte session est constitué des différents blocs de données ci-dessous.

La résolution de la valeur d'un champ est effectuée suivant l'ordre de présentation des blocs dans la liste.

1. AUSERINF - Informations utilisateur signé

2. AUSERVAR - Variables utilisateur

    • Contient des champs créés via les fonctions JavaScript xtdAjaxSetUserVar et xtdSetUserVar
    • Utilisé pour sauvegarder des données client sur le serveur

3. ASITE - Document site

    • Accès aux valeurs des champs 'Paramètres libre' de la fiche du site
    • <span adx="ASESSION.MyFreeField"></span> affiche la valeur du paramètre libre de code MyFreeField

4. AMESS - Messages utilisateur

    • Contient les messages renvoyés par X3

5. AUSERCRIT - Critères utilisateur

    • Les critères de sélections sont sauvegardés et restaurés via le paramètre HTML xcrit
    • <input type="text" adx="MyCriteria:xcrit">

6. ASYSVAR - Variables systèmes

    • Contient uniquement le champ ATODAY

7. ACONST - Tokens champ de type constantes

Le traitement d'une requête HTTP

Les requête http

Dans l'architecture X3WEB qui héberge le serveur XTEND nous avons 3 couches applicatives:

1. le serveur frontal Apache HTTP qui traite les requêtes HTTP

2. le serveur Apache Tomcat qui héberge les 'applications web'

3. l'application web XTEND

Les requêtes http à destination de l'application web XTEND sont identifiée par l'URI qui commence par /xtend/*.

Le 'path' de l'application web XTEND est paramétrable via la console via le paramètre avancé:
xtend.server.virtualpath.context=xtend

L'application web sait traiter un certain nombre de requêtes (servlets) identifiées par le 2eme paramètre de l'URI /xtend/servlet/ :

  • /xtend/page/* gère la construction de la page HTML
  • /xtend/data/* gère l'accès aux données fichiers (images, fklash, fichier pdf...) sur X3 ou en local
  • /xtend/admin/* gère les requêtes d'administration utiles pour le développeur
  • /xtend/svc/* gère les requêtes d'administration utiles pour le développeur (trace, gestion cache, reload...)
Méthode GET ou POST

Le protocole HTTP propose différentes méthodes ou commandes qui spécifient le type d'action qu'effectue la requête.

Le serveur XTEND ne répond qu'au méthodes GET et POST qui ont la signification suivante:

Un lien dynamique utilise par défaut la méthode POST si une sélection ou une action lui est associée.
Cette méthode soumet (submit) le formulaire HTML <form></form> de la page via l'appel de la fonction JavaScript xtdDoDlk.
Cette fonction calcule les paramètres du lien dynamique (xml) et les envoie dans un champ input hidden.
Le serveur reçoit toutes les informations dont il a besoin pour traiter l'action ou la sélection associée au lien dynamique sur lequel il a cliqué (données des champs du formulaire et contexte calculé par le client).

Un lien dynamique peut utiliser la méthode GET si il effectue seulement un débranchement vers une page ou si il n'a pas de paramètre d'action ou de sélection à calculer.
Cette méthode ne soumet pas le formulaire HTML mais débranche le navigateur vers une URL qui ne contient que les paramètres de base (lien, solution, dossier, site, langue).

Seule la méthode GET est compatible avec les moteurs de recherche (web crawlers).

Utilisation d'un 'reverse proxy'

Pour des raisons de sécurité, l'utilisateur du web peut passer par l'intermédiaire d'un reverse proxy pour accéder aux applications de serveurs internes.

L'utilisation d'un reverse proxy permet aussi de masquer aux utilisateur l'adresse réelle d'un serveur et facilite la maintenance d'un site.

En cas d'arrêt d'un serveur on pourra rediriger temporairement les requêtes vers un autre serveur de façon transparente pour le client.

Pour définir un 'reverse proxy' d'alias proxyxtend dans le serveur Apache du serveur X3WEB hostproxy qui "redirige" les requêtes XTEND vers hostxtend on utilise la configuration suivante.

Fichier Apache2.2\conf\httpd.conf

Créer un 'virtual host' sur le port 80

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

Fichier 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>  

Configuration XTEND

Lorsque le serveur Apache hostproxy reçoit l'url http://hostproxy/proxyxtend/xtend/page/*.
Il va se comporter comme un mandataire et effectuer pour le client la requête http://hostxtend/xtend/page/* vers le serveur XTEND.

Le serveur XTEND qui va calculer la page HTML à renvoyer vers le client doit prendre en compte le reverse proxy pour générer des URL'S qui soient correctes pour le client final (le navigateur).

Dans notre cas, XTEND doit génére des URL's en /proxyxtend/xtend/*.
Il doit donc impérativement tenir compte de la présence du reverse proxy pour calculer l'URL.

La méthode utilisée par XTEND est la suivante:

-1- Déclaration des reverse proxies

Déclaration des ports http et https des 'reverse proxies' via la console d'administration en modifiant les paramètres avancés suivants:

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

-2- Lecture du 'Referer' HTTP

Le header HTTP Referer contient l'url qui a été utilisée par le client pour joindre le serveur.

Le serveur XTEND analyse cette URL et en déduit la présence d'un reverse proxy si /xtend/ est préfixée par une valeur (exemple /proxyxtend/xtend/).

La configuration précédente permet de gérer les changement de protocole http->https ou inversement. Le serveur XTEND doit obligatoirement connaître les ports http et https du reverse proxy.

Pour fonctionner correctement avec un reverseproxy le serveur XTEND doit donc obligatoirement connaitre le 'Referer' http et les ports http et https du (premier) reverse proxy.

La paramètre de configuration xtend.server.gensetup.http.askreferer=on/off (on par défaut) permet d'activer ou désactiver ce mécanisme.

Le header http 'Referer' n'est pas toujours présent, en particulier lorsqu'on saisit l'adresse dans la barre dresse du navigateur.

Si le header http 'Referer' n'est pas présent dans la requête, le serveur XTEND envoie vers le navigateur un formulaire vide avec réponse automatique (transparent pour l'utilisateur) qui dans la plupart des cas renvoie le 'Referer'.

Si la tentative échoue et que le 'Referer' n'est pas renvoyé, le serveur XTEND ne pourra pas prendre en compte la présence d'un reverse proxy.

La session

Le protocole de communication entre le navigateur web et le serveur HTTP est le protocole HTTP qui est "sans état".
Le serveur HTTP ne conserve aucune trace du client après traitement de la requête.
Tout se passe comme si la connexion entre le client et le serveur était coupée après chaque requête.

Le mode de fonctionnement est complètement différent du mode client/serveur (client X3) qui maintient une connexion active avec le serveur X3 pendant toute la durée de la session.

Pour développer des applications web nous avons besoins de faire le lien entre différentes requêtes pour les associer à un même client.
Ce lien est effectué via l'utilisation des cookies HTTP.

Un cookie est créé à l'initiative du serveur lorsque celui-ci envoie au client un instruction 'set cookie' dans l'entête HTTP.
Le cookie est ensuite renvoyé par le client dans l'entête HTTP de toutes les requêtes à destination de ce serveur.

Instruction
Set-Cookie: JSESSIONID=3C9B3EF39FB53069ACB02B6ADA5551A1; Path=/xtend
Path permet de filter les cookies à destination du serveur
Dans notre cas JSESSIONID sera renvoyé dans toutes les requêtes dont l'URI commence /xtend/ (http://host:port/xtend/....)

L'identification par cookie (et donc le fonctionnement de l'application web) ne fonctionne que si le navigateur autorise les cookies de type session (non sauvegardés).
C'est généralement le réglage par défaut des navigateurs web

La notion de 'client' diffère suivant les navigateurs et dépend de la manière dont ils gèrent les cookies.

  • Pour FireFox les cookies sont partagés entre les instances des navigateurs.
    Si on se connecte à un même site XTEND sur le même poste avec deux navigateurs FireFox il partageront la même session XTEND.
    Les navigateurs sont vus côté serveur comme un seul client.
  • Pour IE6 les cookies ne sont pas partagés entre les instances des navigateurs.
    Si on se connecte à un même site XTEND sur le même poste avec deux navigateurs IE6 ils auront chacun une session.
    Les navigateurs sont vus côté serveur comme deux clients différents.
  • Les onglets au sein d'un même navigateur partagent les mêmes cookies et sont vus comme un seul client.
Session TOMCAT

La session utilisateur qui permet d'associer un contexte de données spécifique à chaque client est gérée par le serveur TOMCAT via la notion de servlet.

Pour identifier les requêtes et les rediriger vers la bonne session utilisateur le serveur TOMCAT gère un cookie session spécifique de code JSESSIONID.

Cookie géré par le serveur TOMCAT
Set-Cookie: JSESSIONID=3C9B3EF39FB53069ACB02B6ADA5551A1; Path=/xtend
JSESSIONID est l'identifiant de session TOMCAT

Le cookie JSESSIONID n'est pas persistant c'est à dire qu'il n'est pas conservé lorsqu'on ferme le navigateur.
L'utilisateur perd donc sa session et donc son contexte de données si il ferme son navigateur.

La session est conservée en mémoire pendant une durée paramétrable via le paramètre de configuration console :
xtend.server.gensetup.http.session.timeout
Ce paramètre indique la durée d'inactivité, en minutes, tolérée par le serveur TOMCAT pour une session utilisateur.
Si aucune activitée (requête reçue) n'est détectée pendant cette période, la session est supprimée et le contexte de données est perdu.

Mecanisme de reconnexion

Le serveur XTEND gère son propre indentifiant de session via le cookie XADXID.
Ce cookie est persistant c'est à dire qu'il est sauvegardé par le navigateur (si autorisé).

Lorsque l'utilisateur ouvre son navigateur et se connecte au serveur XTEND, le cookie XADXID est envoyé dans la requête (si il existe) et le serveur essaie de retrouver la session (TOMCAT) de l'utilisateur pour le reconnecter.

Cookies gérés par le serveur XTEND
Set-Cookie XADXID=123332746651556912893670; Expires=Sat, 30-Jan-2010 14:57:46 GMT; Path=/xtend

Le paramètre de configuration console xtend.server.gensetup.http.cookie.sess.persist=on (on par défaut) permet d'activer/désactiver la gestion de la reconnexion suite à la fermeture du navigateur.

La page de reconnexion du site (facultative) permet d'informer l'utilisateur que sa session a été restaurée.

Fonctionnement sans les cookies

XTEND propose un mode de fonctionnement sans cookies qui propage l'identificateur de session JSESSIONID dans l'URL.

Ce mode peut être soit activé:

  • Par l'utilisateur via l'action web ASESSSWITCHCOOKIES ou le lien dynamique ADLKSWITCHCOOKIES
  • Par défaut pour toutes les sessions via le paramètre de configuration console
    xtend.server.gensetup.http.cookie.disabled=on - off par défaut.

Le mode sans cookies augmente la taille des URL'S en ajoutant un paramètre supplémentaire:
http://ecfdalbopro:28980/xtend/page;jsessionid=E04AEF0615702B3C7E52107ED6C17D8A?DLK=DLKTESTMAPPING...

Ce mode ne permet pas l'utilisation de liens vers d'autre sites web car l'id session n'est pas propagé et la session utilisateur est perdue.

Traitement serveur

Ce paragraphe décrit le processus de traitement des requêtes HTTP par le serveur XTEND.

Apache HTTP server

1. Réception de la requête HTTP

    • Gère le protocole sécurisé HTTPS

2. Filtre la requête en fonction de l'URI

  • Seul les URI'S qui commencent par '/xtend/*' sont traitées par XTEND
    Paramètre console xtend.server.virtualpath.context
  • C'est le fichier httpd.conf qui contient la configuration du serveur Apache
    Ce fichier est généré lors de la configuration du serveur X3WEB

3. Transfert la requête vers 'Apache TOMCAT server' via le mod_jk
mod_jk : 'module Jakarta' qui est le nom du projet de logiciels libres duquel est issu le projet 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. Crée une tâche (thread) pour le traitement de la requête

2. Retrouve le service (objet servlet) identifiée par l'URI

    • /xtend/page/* pour le traitement des page HTML

3. Retrouve la session avec le cookie JSESSIONID

    • Crée une nouvelle session si non trouvée

4. Appelle méthode doPost ou doGet du service

    • Un paramètre httpRequest contient les données de la requête http et la session utilisateur
    • Le traitement de la web application XTEND commence ici
Web application XTEND

1. Initialisation

1. Si nouvelle session TOMCAT

    • Traitement reconnexion via le cookie XADXID
    • Demande http referer (prise en compte des 'reverses proxies')

2. Si redirection (chagement de protocole...)

    • Traitement de la redirection d'URL

3. Lectures des paramètres XTEND

    • Méthode GET : Paramètres de l'URL
    • Méthode PUT : Paramètres XML dans le champ XTDXML du formulaire HTML
      Paramètres : lien dynamique cliqué, page demandée, paramètres de l'action...

2. Ouverture session

1. Mise en attente si session en cours d'utilisation par une autre requête

    • Paramètre console xtend.session.wait.timeout 

2. Positionnement du contexte sur le site XTEND

    • Le code SolutionX3/DossierX3/SiteXtend est passé en paramètre de chaque requête
    • Si pas de paramètre ou site inexistant c'est le site par défaut qui est choisit
    • Paramètres console xtend.server.gensetup.defsite.x3sol,x3fldr,xtdSite 

3. Vérification des mises à jour du dictionnaire XTEND

    • Paramètres techniques du site 'Vérifier mise à jour'

3. Contrôles

1. Contrôle du protocole

    • Si le protocole (http ou https) de la requête n'est pas celui défini pour la page
      • Envoie d'une redirection au client (Http status=302) pour 'switcher' de protocole 

2. Si utilisateur signé : contrôle durée d'inactivité de la session XTEND

    • Paramètre 'Timeout session(mn)' de la fiche site

3. Si la page si page est protégée
Paramètre 'Accès protégé' de la fiche page 

1. Contrôle des droits d'accès de l'utilisateur

    • Contrôle en fonction du profil si utilisateur signé

2. Si l'utilisateur n'a pas les droits d'accès

    • Redirection vers la page de login définie dans la fiche site
    • Sauvegarde du contexte (page destination, action) pour restauration après login

4. Traitement de l'action web si une action est associée au lien dynamique

  • L'action peut modifier la page de destination
  • Par exemple si une erreur se produit on reste sur la page courante et on affiche le message X3

5. Affichage de la page

1. Vérification des mises à jour de la page

          • Paramètres techniques du site 'Vérifier mise à jour'

2. Initialisation des tokens bloc (requêtes)

          • Appel des web service type Accès donnée

3. Calcul du HTML

          • Parcours de l'arborescence des tokens
          • Appel de la méthode computeHtml

6. Envoie de la réponse au navigateur