TermiNA
Dans le cadre d’un portage Ada que nous avons réalisé pour un de nos clients, et en accord avec ce dernier, nous avons reconsidéré la façon dont l’application originelle en mode console gérait les traces et les logs.
Le système de traces et de logs souffrait des limitations suivantes :
- Pas de hiérarchisation (exemple : Normal, Debug, Success, Warning, Error).
- Manque d’homogénéité.
- Pas de colorisation en ce qui concerne les traces sur la console
(exemple :
). - Absence de filtrage (politique du tout ou rien).
- Traces et logs localisés sur la machine → pas de déport possible.
- Pas de datation.
- Pas de possibilité de connaitre systématiquement l’origine d’une trace.
- Absence de configuration des traces et des logs.
- Incapacité de voir ce qui s’est passé si la console de sortie s’achève inopinément.
- …
En conséquence, le composant TermiNA (Terminal Net Ada) a été développé en Ada$_{2022}$ en s’appuyant entre autres sur les composants GNATCOLL Terminal et Traces.
Architecture de la solution¶
Le composant TermiNA est constitué d’une partie serveur et d’un nombre indéterminé de clients.
Le code est en full Ada$_{2022}$ et il n’est pas assujetti à une plateforme ou à un type de terminal.
L’application Ada proprement dite doit utiliser l’API de TermiNA offrant par exemple les services suivants :
- Sorties de caractères et de chaînes de caractères (en mode serveur).
- Fonctions de formatage pour sorties flottantes.
- Barre de progression.
- Informations sur le terminal.
- Utilitaires de formatages des chaines de caractères.
- Utilitaires pour l’affichage des tracebacks d’exceptions.
- Utilitaires de dump mémoire.
- …
Les clients sont des instances multiples d’une même application de ~80 lignes de code Ada$_{2022}$ s’appuyant aussi sur TermiNA.
La partie serveur et les clients sont hautement configurables au travers d’un fichier de configuration et/ou d’options en ligne de commande permettant :
- De définir le type de messages que l’on souhaite afficher dans les terminaux.
- De définir le type de messages que l’on souhaite afficher dans les logs.
- L’activation/désactivation de la colorisation.
- L’adresse des différents clients.
- L’activation/désactivation des logs.
- La profondeur d’historisation des fichiers de logs.
- …
La figure suivante schématise cette architecture client/serveur.
Exemple¶
Le code Ada$_{2022}$ suivant montre l’utilisation d’une nouvelle forme d’agrégat et la généralisation de l’attribut ‘Image à tous les types avec possibilité de redéfinition de celui-ci :
L’exécution de ce code en mode console sera « éphémère » sur le terminal et génèrera le fichier de log suivant :
Maintenant, lançons notre client sur une machine distante ou pas, car cela importe peu :
Et relançons à nouveau notre application « éphémère » …
Cette fois, nous aurons sur notre client :
Et la machine cliente hébergera exactement le même fichier de log.
Conclusion¶
La gestion des sorties consoles (terminal) et logs est souvent à tort négligée. Pourtant, comme pour l’environnement de développement, cela permet toujours de gagner à terme beaucoup de temps (aussi bien dans les phases de développement que lors de l’exploitation opérationnelle des applicatifs).
TermiNA permet d’apporter une solution simple, portable et pérenne aux problématiques précédemment citées.
Comments