Le contrôle des licences

Généralités

Introduction

Le contrôle des licences vous permet de refacturer à votre réseau tout ou partie des licences que vous avez achetées à ACE. C’est une fonctionnalité intéressante, par exemple, pour un groupe de distribution qui dispose d’un réseau de points de vente franchisés ou adhérents,magasins ou succursales à qui il souhaite refacturer un droit d’utilisation du système d’information.

Ce type de contrôle permet en outre de limiter le nombre d’utilisateurs actifs et donc de prévenir toute saturation du système mis en place.

Le contrôle se base à la fois sur des limites à ne pas dépasser et sur le nombre d’utilisateurs actifs.

Principes

Les limites peuvent être exprimées selon une combinaison des critères suivants :

  • Nombre de sessions du système d’exploitation : cela représente un utilisateur conectéà un ordinateur. Elle est matérialisée par un cookie présent sur le poste client et a une durée de vie paramétrable au niveau du fichier de configuration (attribut « application/properties/@sessionControlActive » dansle fichier « configuration.xml » permet d'activer la fonctionnalité),
  • Nombre de sessions http : la session http est initialisée lors de la première requête au serveur. Elle reste active tant que l’utilisateur n’a pas effectué volontairement une action de déconnexion ou après le timeout défini au niveau du module web.
  • Module web : le module web est un élément d’une application J2EE. Il permet de définir des applications indépendantes qui pourraient être déployées sur des serveurs différents. Il est représenté par un chemin de base sur l’URL.
  • Entité : l’entité est un des éléments de la structure opérationnelle du client. Dans le cas d’un réseau de distribution, chaque point de vente peut être identifié comme une entité.
  • Utilisateur : l’utilisateur est identifié par un code d’accès et un mot de passe. En fonction de ses habilitations, il doit pouvoir se connecter sur une ou plusieurs entités.
  • Adresse IP des postes clients.

L’application est composée de deux modules web indépendants : un module intranet (btoe) et un module extranet (btob) destiné aux clients des franchisés.

Aspects techniques

Chaque magasin possède un droit d’accès à l’application, un droit exprimé en connexions simultanées, pour chaque WebModule (atelier, btoe, …).

La solution de comptabiliser dynamiquement les sessions actives offre les avantages suivants :

  • le nombre de postes fixes utilisés dans les magasins n’est pas limité (de type « licence flottante »),
  • les problèmes d’utilisation des adresses IP sont évités (partage de connexions internet, routage NAT , TSE ),
  • aucune installation manuelle sur les postes clients (utilisation d’un cookie ) n’est nécessaire.

Une session OS est active lorsqu’au moins une session « http » appartenant à un utilisateur authentifié lui est associée sur le serveur.

La valeur de la clé de licence exprime le nombre maximum de sessions OS actives simultanément pour un couple [magasin, WebModule].

  • Il peut y avoir plusieurs sessions http pour une session OS .
  • Il peut y avoir plusieurs sessions OS pour une adresse IP.

Tables utilisées

  • UT_SESSION : sessions HTTP avec date et heure de la dernière requête pour chaque session,
  • UT_UUID : Identifiants web,
  • UT_SLIMIT : Limites utilisateurs.

Exemple :

Deux ordinateurs et deux utilisateurs exploitant un même WebModule dans un magasin donné.

Si la licence est limitée à 2 pour ce magasin et ce WebModule, l’utilisateur « User2 » ne pourra pas se connecter depuis la « Session3 » tant que quelqu’un d’autre ne sera pas déconnecté sur une des sessions A à C (déconnexion volontaire ou fin de session imposée par un time out).

Fonctionnalités

Définition des limites utilisateur

Le contrôle des licences s’appuie sur le mécanisme des sessions logiques associées aux utilisateurs.

Ces sessions sont identifiées de manière unique par un identifiant web généré automatiquement (table UT_UUID).

Cet identifiant unique est stocké dans un cookie auquel est associé une durée de validité. Les cookies sont stockés sur l’ordinateur du client, dans des contextes distincts lorsqu’il y a différents utilisateurs pour un même système.

Les sessions « actives » sont comptabilisées pour les couples [magasin, WebModule]. Elles sont limitées aux maxima spécifiés par l’administrateur.

Pour définir les limites utilisateurs, utilisez le portail I_TIESOC_F et l’onglet « Limites Utilisateur ».

Purge des sessions web

Pour supprimer automatiquement les sessions web inutiles, utilisez le traitement différé UPSHE1.

Algorithme

Lorsqu’un utilisateur se connecte dans une nouvelle session HTTP, le contrôle des licences valide sa demande.

Cette validation se déroule en trois étapes :

Prendre en compte les lignes de paramétrage

L’ordre de priorité fixé est le suivant, classé par ordre de priorité décroissant :

Ordre de priorité Entity Uti ip
1 O O O
2 O O *
3 * O O
4 O * O
5 * O *
6 * * O
7 O * *
8 * * *

O : valeur précise. Exemple 172.0.0.1 pour IP

* : valeur non précisée : * dans la table.

Nota : Le webmodule étant toujours renseigné, il n'entre pas en ligne de compte dans le classement.

On prend en compte la ligne la plus prioritaire.

Si cette ligne est partagée, on prend aussi en compte les autres lignes de paramétrage partagées sélectionnées.

Comptabiliser les sessions OS

Les sessions OS en cours d'utilisation pour une ligne de paramétrage sont comptées de la façon suivante.

Il s’agit du nombre de sessions OS associées à au moins une session http valide pour les caractéristiques définies dans la ligne de paramétrage (webmodule, entity, uti, ip ayant des valeurs autres que '*').

La création d'une nouvelle session OS est autorisée quand chaque ligne de paramétrage sélectionnée autorise l'utilisation d'une nouvelle session OS.

Cette autorisation est donnée si la somme des sessions OS en cours pour les critères est strictement inférieure à la valeur du SOS de la ligne de paramétrage.

Comptabiliser les sessions http

Si une nouvelle session OS est autorisée, il faut maintenant valider la demande de session http.

Le nombre de sessions http en cours correspond à la somme des SH ou SHA des sessions OS sélectionnées pour les critères donnés exceptées les sessions OS qui correspondent à des lignes de paramétrage non partagées.

Exemples

  • Avec partage
Table ut_slimit
module entity Uti Ip Sh Sha Sos Partage
1 btoe 1 GUEST 172.16.11.27 1 0 1 O
2 btoe 1 GUEST * 2 0 1 O

Les deux lignes de paramétrage sont partagées.

La demande d'un utilisateur qui se connecte avec l'ip 172.16.11.27 doit être validée par les contrôleurs des deux lignes de paramétrage.

La demande d'un utilisateur qui se connecte avec l'ip 172.16.11.28 doit être validée par le contrôleur de la seconde ligne de paramétrage.

Comme les deux lignes se partagent les mêmes sessions http, la ligne 2 prend en compte les sessions de la ligne 1.

Nombre de sessions http en cours = somme des SH des sessions OS pour webmodule='btoe' et entity='1' et uti='GUEST'.

  • Sans partage
Table ut_slimit
module entity Uti Ip Sh Sha Sos Partage
1 btoe 1 GUEST 172.16.11.27 1 0 1 N
2 btoe 1 GUEST * 2 0 1 N

Les deux lignes de paramétrage ne sont pas partagées.

La demande d'un utilisateur qui se connecte avec l'ip 172.16.11.27 doit être validée par le contrôleur de la ligne de paramétrage 1 uniquement.

La demande d'un utilisateur qui se connecte avec l'ip 172.16.11.28 doit être validée par le contrôleur de la seconde ligne de paramétrage.

Comme les deux lignes ne se partagent pas les mêmes sessions http, la ligne 2 ne prend pas en compte les sessions de la ligne 1.

Nombre de sessions http en cours = somme des SH des sessions OS pour webmodule='btoe' et entity='1' et uti='GUEST' sauf pour ip=172.16.11.27.