Discussion :

[droliprane]

Bonjour à tous,

j'ai mis en place un module de supervision des utilisateurs connectés sur mon appli de gpao.
aujourd'hui que l'appli est vraiment utilisée (une vingtaine d'utilisateurs), je me rends compte que ça ne fonctionne pas correctement.

Voici comment je m'y prends :

J'ai une table logg dans ma base SQL Server qui contient les champs suivants :
- log_session_id, int champs auto (identifiant de session)
- log_uid, int (identifiant de l'utilisateur)
- log_ip_address (IP du poste client)
- log_start (debut de session)
- log_last_update (dernière activité)
- log_end (fin de la session suite à déconnexion ou à purge)

Quand un utilisateur ouvre une session sur la gpao, alors j'exécute la procédure declareSession() :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
 
tic est une DateHeure = DateHeureSys()
 
// création de l'entrée dans la table logg
HRAZ(logg)
logg.log_start = tic
logg.log_last_refresh = tic
logg.log_uid = FEN_START.uid
logg.log_ip_address = ip_client  // je passe sur la façon dont j'obtient l'ip, ce n'est pas ce qui nous intéresse
HAjoute(logg)
FEN_START.sid = logg.log_session_id

Ensuite, j'exécute toutes les 2 minutes (par un timer) la procédure updateSession() qui contient un appel à la procédure stockée du même nom sur mon serveur SQL :

appel via le timer :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
updateSession()
SI Timer("updateSession", 100*60*2) = 0 ALORS
	Erreur("Création du timer impossible")
FIN

la procédure WinDev updateSession() :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
ProcedureStockee est une Source de Données
Sql est une chaîne = "EXECUTE [GPAO].[dbo].[updateSession] @sid=" + sid + ", @interval=5;"
//trace(Sql)
SI PAS HExécuteRequêteSQL(ProcedureStockee,Cnx,hRequêteSansCorrection,Sql) ALORS
	Erreur("Erreur d'initialisation de la requête"+RC+HErreurInfo() + RC + RC + Sql)
	RETOUR
FIN
HLibèreRequête(ProcedureStockee)

Enfin, la procédure stockée SQL Server, qui va updater l'entrée de la table logg qui concerne la session en cours, et purger les entrées trop vieilles (si log_end est null et log_last_refresh est plus vieux que 5 minutes) :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
ALTER PROCEDURE [dbo].[updateSession]
-- Add the parameters for the stored procedure here
	@sid int,
	@interval int
AS
BEGIN
	-- SET NOCOUNT ON added to prevent extra result sets from
	-- interfering with SELECT statements.
	SET NOCOUNT ON;
 
	-- d'abord on update la session en cours @sid
	UPDATE logg SET log_last_refresh = SYSDATETIME() WHERE log_session_id = @sid
 
	-- ensuite on purge les vieilles sessions (appli plantée, session mal fermée)
	UPDATE logg SET log_end = SYSDATETIME() WHERE log_end is null AND datediff(s, log_last_refresh, SYSDATETIME())/60 >= @interval
 
END

Quand je test moi-même, en regardant évoluer log_last_refresh toutes les 2 minutes, j'ai l'impression que tout fonctionne bien. Pourtant il y a des utiisateurs connectés pour lesquels log_end a été renseigné et donc ils sont considérés comme déconnectés. Voyez-vous dans mes programmes ce qui pourrait être la cause de ça ? A priori c'est un problème d'update qui ne se fait pas et donc log_last_refresh n'évolue plus et devient trop vieux, donc un des nombreux appels à updateSession (de la part d'autres utilisateurs) fini par mettre un terme à la ligne de logg en renseignant log_end.

D'avance merci pour toute piste qui m'aidera à faire fonctionner ce module

[tatayo]

Bonjour,
Dixit l'aide en ligne:
Conseil : Dans la majorité des cas, utilisez la fonction TimerSys.
En effet, la fonction Timer consomme plus de ressources que la fonction TimerSys et ne fonctionne que lorsque des fenêtres WinDev sont en cours (le timer s'arrête si une boîte de message est affichée).

Donc il faudrait essayer avec TimerSys().

Tatayo.

[R&B]

Dixit notre expérience, les timer, sys ou pas sont a proscrire si l'application est susceptible d'atteindre 100% CPU car dans ce cas, le timer est simplement pas exécuté.
Solution : passer par les processus dédiés (un exe, API createprocess) ou un thread ! C'est pas la même programmation mais au moins même à 100% CPU, le processus s'exécute.

[droliprane]

ok je vais déjà tester avec un timerSys et j'arrête le timer au début de ma procédure et je le relance à la fin.
résultats des tests demain matin, je ne peux faire des mises à jour que le soir

sinon pour le thread je veux bien, mais donc je fais un thread secondaire qui va lancer un timer dedans ?

j'avais aussi pensé à une petite appli connexe qui serait lancée à l'ouverture de ma gpao, un process caché, au sein duquel se feraient les updates de session, toutes les X minutes

enfin il y a aussi le paramétrage de la procédure au niveau de WinDev, qui permet de programmer une répétition, de lancer dans un thread, etc... je me demande ce que ça vaut

vous feriez comment ?

[R&B]

Attention, n'empilez pas thread et timer car c'est faire deux fois la même chose !

Vu la confusion, il vous faut étudier sérieusement les thread avant de vous lancer... Ce n'est que lorsque vous afficherez un beau "hello world il est xx:yy:zz" avec les heures minutes secondes que vous pourrez passer au stade suivant. Notez que la programmation des processus (thread) n'est pas simple, ni leur déboggage.

[droliprane]

Oh je ne fais pas vraiment de confusion, après c'est sur qu'au niveau de l'utilisation/partage du contexte mémoire il doit y avoir des différences importantes

Mais j'ai quand même dépassé le stade de l'affichage de l'heure

Je vois bien les deux techniques, ce que je n'ai pas, c'est l'expérience pour dire si dans telle ou telle situation il vaut mieux utiliser l'un plutôt que l'autre.

Finalement, dans mon cas, j'ai opté pour un thread avec un threadpause, comme ça je ne me repose plus sur un timer, dont la fiabilité ne semble pas être aussi éprouvé qu'un thread

Aussi, maintenant le client s'annonce toutes les minutes, et donc la purge des vieux logs se fait sur la base de 70 secondes

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
ProcedureStockee est une Source de Données
Sql est une chaîne = "EXECUTE [GPAO].[dbo].[updateSession] @sid=" + FEN_START.sid + ", @interval=70;"
 
TANTQUE Vrai
 
	SI PAS HExécuteRequêteSQL(ProcedureStockee,Cnx,hRequêteSansCorrection,Sql) ALORS
		//Erreur("Erreur d'initialisation de la requête"+RC+HErreurInfo() + RC + RC + Sql)
		RETOUR
	FIN
	HLibèreRequête(ProcedureStockee)
 
	ThreadPause (60 * 100) // endort le Thread 60 secondes
 
FIN

En local c'est nickel avec plusieurs sessions, dont certaines que je ferme à l'arrache depuis le gestionnaire de processus pour simuler un plantage ou une coupure réseau

Demain test en prod, je vous redirai ce qu'il en est.

La prochaine étape sera de faire un système de kill session, pour quand un utilisateur a laissé sa session TSE ouverte et que je veux faire une mise à jour.
Je pense mettre un booleen dans un champ de la table logg, et faire que ma procédure stockée (exécutée toutes les minutes) renvoie ce même booléen de kill session, et fermer l'appli en fonction de ça (avec un message d'explication).
Donc entre le moment où j'aurai demandé la fermeture d'une session donnée, et se fermeture effective, il se passera dans le pire des cas 60 secondes.


Merci à vous

[droliprane]

Bon c'est pas mal du tout, le système fonctionne bien mieux avec un thread secondaire et une pause de 60 secondes

Du coup j'ai étendu ce système pour les updates de mon appli, avec un autre thread qui vérifie toutes les 10 minutes si une mise à jour est dispo sur un ftp

Ca fonctionne également très bien, le seul soucis est que à la fermeture de mon appli, ça met plus de temps qu'avant.

Je suppose que ça vient des 2 threads secondaires qui tournent en permanence et qui mettent un peu de temps à se fermer, car c'est la seule chose qui a changé par rapport à hier.

Faut-il que je mette une condition d'arrêt dans la boucle TANTQUE Vrai de mes threads ? Et si le thread est sur l'instruction threadPause, comment lui indiquer qu'il doit s'interrompre tout de suite ?

Merci à vous, on touche au but

[JG_33]

Bonjour,

Dans le code de fermeture du projet vous pouvez utiliser la fonction ThreadArrête .
La doc pcsoft nous dit :
L'utilisation de cette fonction est fortement déconseillée car elle arrête violemment le thread en pleine activité. Elle peut provoquer des problèmes graves (écriture de fichier incomplète, perte de mémoire, section critique non libérée, ...).

Suite à des blocages et des messages d'erreur Windows en fermeture de projet, le support technique m'avait suggéré d'utiliser cette fonction. Depuis le projet se ferme correctement.
Je confirme qu'en dehors de la fermeture du projet, la fonction fait des bulles...

Cordialement

[Lo²]

Bonjour à tous,

Juste comme cela, est-ce que vous connaissiez ceci ?
http://doc.pcsoft.fr/fr-FR/?2028059&...stallee_reseau

[R&B]

En complément de JG_33 et de ce que j'indiquais sur les threads en début de conversation (de la bonne compréhension de cette programmation), peut être pourriez vous préférer un signal dont le traitement permettra de sortir de la boucle proprement.
Autre avantage : permettre une terminaison au moment voulu (fin de programme ou action programmée).

Concernant WDAdmin, il sert une logique qu'il faut appliquer de préférence de A a Z : installateur WDSetup, gestion des utilisateur (Groupware) etc...

[droliprane]

Bonjour à tous,

Juste comme cela, est-ce que vous connaissiez ceci ?
http://doc.pcsoft.fr/fr-FR/?2028059&...stallee_reseau

Purée c'est à 95% ce que j'ai fait, sans savoir que ça existait

Et sans la prétention que ce soit aussi performant (je peux terminer des sessions proprement avec +ou- 60 secondes de délai) , mais en tout cas ça fait le boulot, et c'est intégré dans mon appli

Et je vais gérer aussi un paramètre général de mise sous maintenance logicielle de l'appli qui interdira toute reconnexion tant que je n'aurai pas repassé ce booléen dans l'état normal de production

Ce qui me permettra de faire mes mises à jours dans la base de données, et aussi de déployer le nouvel exécutable dans le repository de mises à jour


Et merci JG_33, j'ai fais des threadArrête sur mon événement de fermeture et c'est tout bon, ça ferme dans la seconde, merci

[Lo²]

...
Concernant WDAdmin, il sert une logique qu'il faut appliquer de préférence de A a Z : installateur WDSetup, gestion des utilisateur (Groupware) etc...

Pas d'accord, dans le sens où je l'ai mis en application uniquement lors des installations réseaux de mes applis et ça le limitait à cela (pas de groupware, etc)

[R&B]

Merci Lo²... m'en vais étudier tout cela de plus près.

[fffttt]

Purée c'est à 95% ce que j'ai fait, sans savoir que ça existait

Et sans la prétention que ce soit aussi performant (je peux terminer des sessions proprement avec +ou- 60 secondes de délai) , mais en tout cas ça fait le boulot, et c'est intégré dans mon appli

Et je vais gérer aussi un paramètre général de mise sous maintenance logicielle de l'appli qui interdira toute reconnexion tant que je n'aurai pas repassé ce booléen dans l'état normal de production

Ce qui me permettra de faire mes mises à jours dans la base de données, et aussi de déployer le nouvel exécutable dans le repository de mises à jour


Et merci JG_33, j'ai fais des threadArrête sur mon événement de fermeture et c'est tout bon, ça ferme dans la seconde, merci

bonjour

Le seul inconvénient est que le nom d'utilisateur est celui de la connexion à la base de données.
Et si dans l'init de l'appli, vous faites la connexion à la base avec par ex le compte admin.
Vous verrez dans le suivi, x admin (sur des ordinateurs différents).
Et si vos noms de PC sont des numéros (ou tout autre truc pas parlant), vous ne savez pas de qui il s'agit.

[droliprane]

Bonjour

Ben non je loggue le userid de l'appli (et donc son nom prénom dans la fiche utilisateur), la version du client, l'adresse IP de la machine, le nom de la machine

Avec tout ça si j'arrive pas à déterminer de qui il s'agit, c'est que je suis mauvais

[infhaddar]

Bonjour à tous,

j'ai mis en place un module de supervision des utilisateurs connectés sur mon appli de gpao.
aujourd'hui que l'appli est vraiment utilisée (une vingtaine d'utilisateurs), je me rends compte que ça ne fonctionne pas correctement.

Voici comment je m'y prends :

J'ai une table logg dans ma base SQL Server qui contient les champs suivants :
- log_session_id, int champs auto (identifiant de session)
- log_uid, int (identifiant de l'utilisateur)
- log_ip_address (IP du poste client)
- log_start (debut de session)
- log_last_update (dernière activité)
- log_end (fin de la session suite à déconnexion ou à purge)

Quand un utilisateur ouvre une session sur la gpao, alors j'exécute la procédure declareSession() :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
 
tic est une DateHeure = DateHeureSys()
 
// création de l'entrée dans la table logg
HRAZ(logg)
logg.log_start = tic
logg.log_last_refresh = tic
logg.log_uid = FEN_START.uid
logg.log_ip_address = ip_client  // je passe sur la façon dont j'obtient l'ip, ce n'est pas ce qui nous intéresse
HAjoute(logg)
FEN_START.sid = logg.log_session_id

Ensuite, j'exécute toutes les 2 minutes (par un timer) la procédure updateSession() qui contient un appel à la procédure stockée du même nom sur mon serveur SQL :

appel via le timer :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
updateSession()
SI Timer("updateSession", 100*60*2) = 0 ALORS
	Erreur("Création du timer impossible")
FIN

la procédure WinDev updateSession() :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
ProcedureStockee est une Source de Données
Sql est une chaîne = "EXECUTE [GPAO].[dbo].[updateSession] @sid=" + sid + ", @interval=5;"
//trace(Sql)
SI PAS HExécuteRequêteSQL(ProcedureStockee,Cnx,hRequêteSansCorrection,Sql) ALORS
	Erreur("Erreur d'initialisation de la requête"+RC+HErreurInfo() + RC + RC + Sql)
	RETOUR
FIN
HLibèreRequête(ProcedureStockee)

Enfin, la procédure stockée SQL Server, qui va updater l'entrée de la table logg qui concerne la session en cours, et purger les entrées trop vieilles (si log_end est null et log_last_refresh est plus vieux que 5 minutes) :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
ALTER PROCEDURE [dbo].[updateSession]
-- Add the parameters for the stored procedure here
	@sid int,
	@interval int
AS
BEGIN
	-- SET NOCOUNT ON added to prevent extra result sets from
	-- interfering with SELECT statements.
	SET NOCOUNT ON;
 
	-- d'abord on update la session en cours @sid
	UPDATE logg SET log_last_refresh = SYSDATETIME() WHERE log_session_id = @sid
 
	-- ensuite on purge les vieilles sessions (appli plantée, session mal fermée)
	UPDATE logg SET log_end = SYSDATETIME() WHERE log_end is null AND datediff(s, log_last_refresh, SYSDATETIME())/60 >= @interval
 
END

Quand je test moi-même, en regardant évoluer log_last_refresh toutes les 2 minutes, j'ai l'impression que tout fonctionne bien. Pourtant il y a des utiisateurs connectés pour lesquels log_end a été renseigné et donc ils sont considérés comme déconnectés. Voyez-vous dans mes programmes ce qui pourrait être la cause de ça ? A priori c'est un problème d'update qui ne se fait pas et donc log_last_refresh n'évolue plus et devient trop vieux, donc un des nombreux appels à updateSession (de la part d'autres utilisateurs) fini par mettre un terme à la ligne de logg en renseignant log_end.

D'avance merci pour toute piste qui m'aidera à faire fonctionner ce module

Esseyez avec le code suivant au lieu de "HExécuteRequêteSQL" :

example:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
 
SI PAS SQLExec(command,"req") ALORS
		   SQLInfoGene("req")      
      	   Erreur(SQL.MesErreur)
	       RepriseSaisie(tab_auto)
	FIN

[droliprane]

Pour info, j'ai modifié le principe de gestion de mes sessions de cette façon :

j'ai maintenant un champs supplémentaire log_kill dans ma table logg, que je peux mettre à 1 depuis un module admin de mon ihm et qui flag les sessions que je veux fermer de force (par exemple quand je fais une maintenance).

Ensuite toutes les 70 secondes l'ihm exécute une procédure stockée sql server depuis, dans laquelle je passe en argument l'identifiant de la session courante, et cette procédure va purger les sessions plus vieilles qu'un certain temps (moi je mets 60 secondes) et en même me dire si ma propre session doit se fermer.

Voici la procédure en question :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
ALTER PROCEDURE [dbo].[updateSession]
-- Add the parameters for the stored procedure here
	@sid int,
	@interval int
AS
BEGIN
	SET NOCOUNT ON;
 
	DECLARE @kill int
 
	SELECT @kill = log_kill FROM logg WHERE log_session_id = @sid
 
	IF @kill = 1
		-- si je suis une session qui doit être fermée, je mets juste log_end
		UPDATE logg SET log_end = SYSDATETIME() WHERE log_session_id = @sid
	ELSE
		-- sinon je réactualise log_last_refresh, et je mets null dans log_end
		UPDATE logg SET log_last_refresh = SYSDATETIME(), log_end = null WHERE log_session_id = @sid
 
 
	-- dans tous les cas, on purge les vieilles sessions (appli plantée, session mal fermée)
	UPDATE logg SET log_end = SYSDATETIME() WHERE log_end is null AND datediff(s, log_last_refresh, SYSDATETIME()) >= @interval
 
END

Au retour de la procédure je teste la valeur kill et si kill = 1 alors j'informe l'utilisateur de la nécessité de fermer sa session, et je mets une tempo de 5s avant de fermer l'ihm.

Ailleurs dans mon appli j'ai un booléen de maintenance qui interdit toute connexion à l'appli aux utilisateurs non root tant que ce booléen n'est pas repassé dans l'état normal.

Avec ce système, chaque occurrence de l'appli fait le ménage toutes les 70 secondes dans les sessions qui ont pu s'interrompre anormalement (crash, coupure réseau, etc...) et en même temps je peux déclencher une opération de maintenance en déconnectant de force les utilisateurs en leur envoyant un signal de déconnexion (update log_kill = 1 where log_session_id = xxx) et je suis certain que au plus tard 70s après, l'appli n'a plus d'utilisateurs connectés.