|
|
|
|
|
|
|
|
- Présentation
- Principe
- Mise en oeuvre
- Exemple utilisé
- Tâches parallèles pour effectuer le traitement long
- Appeler la fonction DemandeMiseAJourUI
- Événement "Demande de mise à jour de l'affichage"
- Timer navigateur
- Désactiver le timer
- Autre approche possible
Page en mode Session : Remplir les champs après un traitement long
Dans une application Web, il peut arriver de devoir exécuter des traitements longs (par exemple, pour la mise à jour de compteurs métier dans un tableau de bord applicatif). Cette page explique comment réaliser de tels traitements : - sans bloquer l'interface utilisateur,
- en actualisant automatiquement les données affichées quand de nouvelles valeurs sont disponibles.
Pour remplir des champs avec les résultats d'un traitement long sans bloquer le navigateur, une solution fiable et relativement simple à mettre en oeuvre consiste à : - Utiliser des threads sécurisés ou des tâches parallèles pour préparer les résultats dans des variables globales,
- Appeler la fonction WLangage DemandeMiseÀJourUI depuis les threads ou les tâches parallèles lorsque des résultats sont disponibles,
- Coder les modifications des champs dans l'événement "Demande de mise à jour de l'affichage",
- Mettre en place un timer navigateur qui appelle une procédure serveur AJAX asynchrone de rafraîchissement avec actualisation des champs, par exemple toutes les 10 secondes ou toutes les minutes,
- Activer/désactiver le timer selon les besoins pour éviter les appels AJAX inutiles.
Exemple utilisé Pour appliquer les différentes étapes, nous allons considérer l'exemple suivant : - une page contenant un champ Tableau de bord
- le calcul des nouvelles valeurs des compteurs est réalisé dans une procédure locale ActualiseKPI.
- le déclenchement de la mise à jour du tableau de bord est effectué dans le code du champ Bouton "Actualiser (asynchrone)".
Tâches parallèles pour effectuer le traitement long Dans le code serveur du champ Bouton, l'exécution de la procédure ActualiseKPI est lancée dans une tâche parallèle. Il est ainsi possible de conserver une UI réactive, sans blocage. Par exemple :
gTacheParallèleMiseAJour est une TâcheParallèle
gTacheParallèleMiseAJour = TâcheParallèleExécute(ActualiseKPI, ())
Dans ce code, une référence à la tâche parallèle est conservée dans la variable globale gTacheParallèleMiseAJour. Pour éviter de lancer plusieurs tâches de recalcul en même temps, le code du champ Bouton vérifie la propriété Etat de la variable TâcheParallèle.
SI gTacheParallèleMiseAJour.Etat = tpeExécutionEnCours ALORS
ToastAffiche("Requête déjà en cours", toastCourt, cvHaut, chCentre, VertPastel)
SINON
gTacheParallèleMiseAJour = TâcheParallèleExécute(ActualiseKPI, ())
FIN
Dans le code navigateur du champ Bouton, un timer est également lancé toutes les secondes, pour exécuter une procédure navigateur (nous l'appellerons MiseAJourAffichage_Navigateur).
gnTimerActualisation = Timer(MiseAJourAffichage_Navigateur, 1 s)
Remarque : Dans cet exemple, le procédure du timer est appelée toutes les secondes. Il n'est pas forcément nécessaire d'exécuter la procédure du timer aussi fréquemment. Il faut adapter la fréquence de mise à jour voulue. Appeler la fonction DemandeMiseAJourUI Le code de la procédure ActualiseKPI effectue le recalcul des compteurs du tableau de bord du site. Quand les variables (serveur, globales à la page) sont à jour, la procédure ActualiseKPI appelle la fonction WLangage DemandeMiseAJourUI. Cette fonction permet au WLangage d'exécuter l'événement "Demande de mise à jour de l'affichage de la page" dès que possible. La procédure se termine, ce qui met fin à la tâche parallèle. La propriété Etat de la tâche parallèle correspond alors à la constante tpeTerminée. Événement "Demande de mise à jour de l'affichage" L'événement "Demande de mise à jour de l'affichage" contient le code de mise à jour des champs. Par exemple, dans notre exemple :
ZR_KPI[gnLigneCAJour].ATT_NomKPI = ChaîneConstruit(gsCAJour, gnCAJour)
ZR_KPI[gnLigneNbCommandes].ATT_NomKPI = ChaîneConstruit(gsNbCommandes, gnCommandes)
Timer navigateur Pendant ce temps, le timer navigateur (procédure MiseAJourAffichage_Navigateur dans notre exemple) exécute régulièrement la procédure serveur MiseAJourAffichage_Serveur. L'exécution de cette procédure s'effectue via un appel AJAX asynchrone, toujours pour ne pas bloquer l'UI. La fonction AjaxExécuteAsynchrone est appelée en précisant la constante ajaxActualiseChamps.
AJAXExécuteAsynchrone(ajaxActualiseChamps + ajaxSynchroniseVariablesServeur, ...
MiseAJourAffichage_Serveur, ApresMiseAJourAffichage_Navigateur)
L'emploi de cette constante permet au code serveur de mettre à jour les champs de la page. L'appel serveur va ainsi automatiquement provoquer la mise à jour de l'UI. La procédure MiseAJourAffichage_Serveur renvoie uniquement la valeur de gTacheParallèleMiseAJour.Etat. La fonction AjaxExécuteAsynchrone appelle automatiquement une procédure navigateur lors du retour de l'appel serveur.
Dans l'exemple, il s'agit de la procédure AprèsMiseAJourAffichage_Navigateur. Désactiver le timer La procédure AprèsMiseAJourAffichage_Navigateur reçoit en paramètres : - la valeur renvoyée par la procédure serveur, ici gTacheParallèleMiseAJour.Etat. Ainsi, si la tâche parallèle est dans l'état terminé (constante tpeTerminée), le timer est arrêté pour ne pas déclencher inutilement des appels au serveur.
- un identifiant permettant de connaître la procédure serveur concernée. Cet identifiant est utile si plusieurs appels AJAX ont lieu en parallèle.
PROCÉDURE ApresMiseAJourAffichage_Navigateur(sTacheEtat est une chaîne, nIdentifiant est un entier)
Autre approche possible Lorsque le traitement est long et nécessite une forte charge de travail du serveur, il peut être intéressant de déporter ce traitement. Il suffit alors d'utiliser une tâche planifiée WEBDEV qui effectuera le traitement long à intervalle régulier et qui stockera les résultats dans la base de données. Le site aura juste à afficher les résultats stockés. |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|