Gérer une session web côté client avec XMLRAD

Dans une architecture web il est souvent nécessaire de vouloir transmettre ou d'avoir accès dans de nombreuses pages à certaines données. Pour ce faire, on peut utiliser par exemple les cookies, les paramètres HTTP ou les sessions. Chacune de ces techniques a ses avantages et ses inconvénients.

Nous allons décrire dans cet article les différentes techniques et l'intérêt des sessions par rapport aux autres et comment les utiliser dans XMLRAD.

La première technique qui vient à l'esprit pour toujours avoir une donnée précise à chaque requête c'est le cookie. Il permet de stocker des informations sur le poste client pour un domaine et un chemin particuliers. À chaque requête, le cookie avec ses informations est transmis avec la requête HTTP. On peut alors les récupérer pour les traiter côté serveur. L'inconvénient c'est que la quantité de données est limitée à 4ko.

Les paramètres HTTP sont une alternative souvent peu utilisée dans ce cadre, mais qui présente néanmoins des avantages. On les utilise surtout de façon unique pour une requête en particulier. Or, ils peuvent très bien servir pour transmettre des valeurs en permanence au serveur pour peu qu'ils soient retransmis à la page suivante via des paramètres dans l'URL ou des champs cachés pour les formulaires. L'inconvénient c'est que si l'on doit transmettre des dizaines de paramètres ou bien si l'on doit en rajouter un il faut le faire pour chaque page. L'avantage c'est que l'on est typiquement dans l'architecture web HTTP sans état côté serveur : c’est la requête qui emporte avec elle tout son contexte d'exécution.

Lorsque l'on parle de session, c'est la plupart du temps pour évoquer un stockage de valeurs côté serveur lié à une session de l'utilisateur. Pour pouvoir utiliser cette session, il faut l'identifier. Il faut donc que l'identificateur de la session soit toujours transmis avec la requête, et ce, soit par cookie soit par paramètre HTTP. Avec cette technique on va pouvoir transmettre beaucoup plus d'informations avec seulement l'identifiant de la session retransmis à chaque requête. Cependant, on a ici un stockage d'état côté serveur. Or l'utilisateur peut avoir plusieurs navigateurs ouverts sur la même application et utilisant donc des chemins de navigation différents. La gestion de la session doit donc prendre en compte ce facteur-là pour déterminer dans quel contexte d'exécution on se situe, ce qui complexifie son utilisation.

XMLRAD utilise un compromis entre les paramètres HTTP et les sessions. Tous les paramètres qui font partie de la session sont encodés dans un seul paramètre HTTP. Il faut juste s'assurer qu'il soit transmis à chaque page.

Chaque requête qui est traitée par l"application XMLRAD a une partie Session dans laquelle on peut insérer des valeurs. Lors de la génération du document XML de sortie (OutputDoc) un nœud XMLC_RequestSession est ajouté dans la section XMLC_Params avec tous les paramètres encodés. Un autre nœud XMLC_RequestSession est ajouté contenant tous les paramètres sous forme XML pour être directement exploitable avec du XSL.

<document>
  <XMLC_Params>
  ...
  <XMLC_RequestSession>
    3C584D4C435F5265717565737453657373696F6E3E3C4D79506172616D3E4D7956616C75653C2F4D79506172616D3E3C2F584D4C435F5265717565737453657373696F6E3E0D0A
  </XMLC_RequestSession>
  ...
  </XMLC_Params>
  <organizationS EOF="0" StartingRow="0" LastRow="9" ExactPaging="1" RowCount="14" PageCount="2" PageID="organization_4164891187866" CurrentPage="1" MaxRows="10" RecordName="organization">
    <organization>
      <ORG_ID>101</ORG_ID>
      <ORG_NAME>e-delos.com</ORG_NAME>
    </organization>
    <organization>
    ...
    </organization>
  </organizationS>
  ...
  <XMLC_RequestSession>
    <MyParam>MyValue</MyParam>
  </XMLC_RequestSession>
</document>

Pour que la session soit transmise à la prochaine requête il suffit que le contenu de XMLC_RequestSession de la section XMLC_Params soit transmis en tant que paramètre HTTP donc soit en paramètre d'URL soit en champ caché de formulaire :

<a href="{/document/Aliases/TrainingDLL}FormORGANIZATION?ORG_ID=101&XMLC_RequestSession={/document/XMLC_Params/XMLC_RequestSession}">link</a>
...
<form name="MainForm" action="{/document/Aliases/TrainingDLL}FormORGANIZATION">
    <input type="hidden" name="XMLC_RequestSession" value="{/document/XMLC_Params/XMLC_RequestSession}"/>
    ...
</form>

Ainsi, le paramètre XMLC_RequestSession est géré spécifiquement par le framework pour être décodé et pour remplir la session de la requête suivante. Le contenu de la session est en même temps copié dans le Context pour être directement accessible. Le cycle peut alors continuer pour la prochaine requête.

Nous allons montrer, sur le projet MyDemo que vous avez pu créer en suivant l'article XMLRAD: premier pas, comment utiliser les sessions XMLRAD.

Dans votre XMLService ListORGANIZATION, nous allons rajouter une instruction Assign dans le XMLGram. Nous la nommons Session.

Même si une instruction Assign existe déjà pour les Params, il est préférable de séparer ce qui est pour ajouter des paramètres dans l'OutpuDoc et la gestion de la session.

Comme destination nous choisissons Session et le nom du paramètre MyParam. Nous n'allons pas spécifier de source, mais mettre directement en constante dans la colonne Value avec la valeur MyValue.

La session XMLC_RequestSession est donc automatiquement calculée dans les XMLC_Params. Pour transmettre la session à la page suivante il nous faut rajouter un paramètre HTTP XMLC_RequestSession contenant la valeur de l'OutputDoc. Nous allons donc dans le XSL de ListORGANIZATION pour rajouter sur lien le paramètre XMLC_RequestSession.

<a href="{/document/Aliases/TrainingDLL}FormORGANIZATION?ORG_ID={ORG_ID}&XMLC_RequestSession={/document/XMLC_Params/XMLC_RequestSession}">link</a>

La session ainsi transmise au XMLService FormORGANIZATION va être décodée, copiée dans le Context et ajoutée dans l'OutputDoc. Dans le XSL de FormORGANIZATION on va donc pouvoir l'exploiter pour l'afficher.

<xsl:value-of select="/document/XMLC_RequestSession/MyParam"/>

Une fois le passage du XMLC_RequestSession mis en place, il suffit de rajouter des champs dans la session à n'importe quel moment grâce à l'instruction Assign et sans limitation. La maintenance de la session est ainsi facilitée.

Nous avons vu les différentes techniques qui permettent de stocker de l'information accessible de page en page : Cookies, paramètres HTTP et sessions avec leurs avantages et leurs inconvénients. Puis nous avons étudié ce que propose XMLRAD en termes de session.

Les sessions XMLRAD ont l'avantage d'avoir un stockage côté client et donc sans état côté serveur tout en étant non limitées sur la quantité d'informations stockées dans la session.