Configuration du délai d'attente basé sur l'activité.

Parfois, des requêtes sont envoyées au Transaction server sans transmettre le cookie WC_USERACTIVITY. Voici quelques exemples de requêtes REST utilisant des requêtes WCToken, Management Center for HCL Commerce et des requêtes de service Web. Dans ce cas, comme le délai d'attente basé sur les cookies ne peut pas être appliqué, le délai d'attente de session doit être activé. La configuration de session basée sur l'activité est stockée dans le fichier de configuration HCL Commerce.

Procédure

  1. Ouvrez le fichier de configuration .
  2. Recherchez et configurez l'élément <ExpiryManagement> en fonction de vos besoins métier. 
    <ExpiryManagement  
		ExpiryMgmtChannelId=”-4, -6” 
		InactivityTimeout="15" Threshold="15"  
	enable="true"/>
    Où :
    ExpiryMgmtChannelId
    Fait référence au ID du canal (table BUSCHN) où le délai d'attente de l'activité est appliqué. Plusieurs valeurs peuvent être spécifiées comme le montre l'exemple.
    Valeurs admises :
    • -4, utilisé pour les cas suivants :
      • Requêtes REST utilisant WCTokens lorsque le cookie WC_USERACTIVITY n'est pas présent.
      • Requêtes Management Center
      • Requêtes de service Web.
    • -6 fait référence aux requêtes de périphérique mobile.
    • -1 fait référence aux requêtes de canal Web et aux requêtes basées sur REST. Il n'est pas recommandé de l'utiliser. Le délai d'attente basé sur les cookies est recommandé pour ces requêtes.
    InactivityTimeout
    Utilisé en combinaison avec Threshold, InactiityTimeout définit la durée minimale entre les mises à jour de base de données lors de l'extension des sessions.

    L'heure de dernier accès est définie pour la première fois dans la base de données lorsque l'utilisateur se connecte. La session reste active dans la valeur de temps définie par ce paramètre, en minutes. Dans l'exemple de configuration, cette valeur est définie sur 15 minutes. Dans ce cas, toutes les requêtes envoyées au serveur dans les 15 minutes suivant l'heure de dernier accès de l'activité seront prises en compte dans la session. Aucune mise à jour n'est apportée à l'heure de dernier accès.

    Seuil
    Si une requête intervient après l'heure définie par InactivityTimeout, mais dans la période définie par ce paramètre, l'heure de dernier accès de l'activité sera réinitialisée à l'heure actuelle dans la base de données. A ce stade, la session reste active et les deux temporisateurs sont effectivement réinitialisés.

    Dans l'exemple de configuration, le délai de seuil est de 15 minutes. Par conséquent, l'activité reste active pendant 30 (15 + 15) minutes. Si une requête arrive plus de 30 minutes après l'heure de dernier accès, la session est considérée comme arrivée à expiration et l'activité est définie sur l'état expiré.

    L'utilisation combinée d'InactivityTimeout et de Threshold permet de réduire le nombre de mises à jour apportées à la base de données pour les sessions actives. Par exemple, si la valeur du délai d'attente total doit être de 60 minutes, une option consiste à conserver la valeur InactivityTimeout à 15 minutes et la valeur Threshold à 45 minutes. Dans ce cas, toutes les requêtes qui arrivent après 15 minutes, mais avant 60 minutes, entraînent mise à jour de l'heure de dernier accès à l'heure actuelle, en maintenant la session active pendant au moins 60 minutes supplémentaires.

Résultats

Le délai d'attente de session basé sur l'activité s'applique désormais sur les canaux configurés pour votre site.