Les améliorations possibles à apporter dans iTex
Cette page est utilisée principalement pour stocker des variables Javascript dont les valeurs dépendent du serveur. C'est le cas par exemple des query id, indispensables pour appeler une query via l'interface de case. Ce fichier a grossi depuis le début du projet et prend plusieurs centaines de millisecondes à être calculé, pour des valeurs qui ne changent pas entre deux livraisons. Il existe deux axes d'amélioration :
-
Cacher fichier sur le serveur pour le rendre statique, avec rafraîchissement automatique toutes les heures. Ça devrait pouvoir se faire facilement avec un paramétrage de Apache http.
-
modifier la procédure de livraison pour calculer la page statistiquement en fonction du serveur. Ceci est plus complexe car du développement spécifique est nécessaire et cette procédure est écrite en python.
-
créer une autre servlet
Mise en place : facile Gain : 100 à 300 millisecondes à chaque ouverture de mission
Arbre de recherche des prototypes
L’algorithme se base sur les casefolders de case360, EJB, etc. alors que se sont des données statiques. Réécrire en java pure.
Mise en place : moyenne à longue. déjà faite en partie (il faut retrouver le code)
Gain : plusieurs centaines de millisecondes à chaque passage de workflow, modification de la mission, etc.
Captures en Java
A l’aide du WatcherService de Java 7, il est facile d’écrire un programme de capture.
Mise en place : moyenne car administration, reprise sur erreur, etc.
Gain : Quelques secondes sur les captures. Maîtrise du code. Meilleure répartition de charge des captures. Contrôle des activation des captures lors des livraisons.
Dashboard
C’est la page la plus longue à s’afficher. Elle mérite le maximum d’effort. Requête SQL
Supprimer la liaison avec la table des événements en ajoutant la date de dernier événement dans une table spécifique.
Mise en place : facile grâce à la création d’évènement déjà centralisée
Gain : plusieurs secondes à l’affichage/rafraîchissement du dashboard.
Countdown
Déplacer le countdown dans la même table spécifique
Mise en place : facile
Gain : aucun
Invalider le countdown plutôt que de le recalculer et ne le calculer qu’à l’affichage du dashboard. Voir si le countdown n’est utlisé que sur le dashboard. Optimiser ce calcul car il semble qu’il soit calculé pour tous les cas possibles avant que l’un des résultat ne soit effectivement choisi.
Mise en place : facile
Gain : quelques millisecondes à chaque traitement modifiant le coundown. Mais quelques millisecondes en plus à l’affichage du dashboard.
Filtres JS
Travailler avec des listes triées.
Mise en place : moyenne. déjà fait en partie sur le poste DDQ. Attentions aux effet de bord dans les filtres sauvegardés.
Gain énorme !
Filtres enregistrés
Il existe des bugs qui ralentissent l’utilisation de cette fonctionnalité :
A l’enregistrement d’un filtre, tous les critères sont désélectionnés. L’utilisateur doit sélectionner son filtre dans la liste provoquant un recalcul.
Mise en place : simple
Gain : plusieurs secondes
A la suppression d’un filtre, il apparaît toujours dans la liste.
Si les critères sélectionnés sont ceux d’un filtre, celui-ci est activé et tous les filtres sont recalculés.