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.
Les limites peuvent être exprimées selon une combinaison des critères suivants :
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.
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 :
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].
Tables utilisées
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).
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 ». |
|
|
Pour supprimer automatiquement les sessions web inutiles, utilisez le traitement différé UPSHE1. |
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 :
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.
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.
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
| 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'.
| 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.