Portail / Sujets autour de la programmation / Programmation C/C++ sous Linux / Serveur d'application avec Qt 6 / Concepts généraux(Sommaire)

Historisation du dialogue.

Mise à jour du 10/06/2024.

Nous avons vu à propos de la fabrication des classes de gestionnaires de ressources, qu'il est possible de doter le serveur d'un journal global. Il est également possible de doter chaque application de son propre système d'historisation. Un tel système permet un suivi chronologique des évènemesnt qui affectent soit le fonctionnement du serveur, soit celui d'une application.

Historisation du dialogue.

Au-delà des traces de compte rendu d'exécutions fonctionnelles et de celles traçant les difficultés rencontrées, il est important de pouvoir suivre, a minima, la chronologie du dialogue constituant une session. Pour cela, il nous faut pouvoir suivre l'arrivée d'une requête ("entrée") ainsi que la réponse ("sortie") qui lui est faite. C'est le serveur qui reçoit en premier la requête HTTP. On pourrait donc penser que c'est lui qui doit archiver la trace de la requête. La requête est ensuite transmise via la fonction callback de la règle de routage à l'application puis au service concerné. Comme la réponse du service est fournie à la fonction callback, le serveur peut aussi tracer la réponse. L'intérêt est que les traces de suivi de session seront alors inscrites dans le même journal.

Il est également possible d'assurer le suivi des traces du couple (requête, réponse) via le service. La question est donc de savoir si c'est le serveur ou le service qui doivent enregistrer les traces de passage en "entrée" et en "sortie". Or si on ne les inscrit pas dans le service, il sera délicat de comprendre les traces émises entre ces deux états.

Toutefois on a vu lors de la présentation du contexte applicatif que le serveur (plus précisément la fonction callback associée à la règle de routage) effectue un certain nombre de contrôles. Cela signifie que toutes les requêtes n'aboutissent pas nécessairement à un service. Pour suivre toutes les traces, il faut donc tracer les requêtes et les réponses :

1. par le service lorsque ce dernier est invoqué via son application web par le seveur ;
2. par le serveur lorsque ce dernier détecte une anomalie qui interdit la prise en compte de la requête par une application web.

Mécanisme transparent de suivi du dialogue.

Comme l'enregistrement des traces d'arrivée de requête et de départ de la réponse est systématique, il serait bon que le développeur n'ait pas à s'en préoccuper. C'est le rôle des méthodes traceInput() et traceOutput() de la classe IService. Ces méthodes sont automatiquement invoquées par la fonction callback