Adam Ambrosino
Page d'administration de services windows

UnicampRewritten

Contexte

La société Apps2Com, aujourd’hui disparue, proposait des services informatiques dont certains ont été installés chez nos clients. Les applications étaient toutes installées sur un Windows Server sous machine virtuelle, la VM Apps2Com.

Après des erreurs de certificats, les clients se sont retrouvés en panne. L’application ne disposant pas de documentation sur sa configuration, nous avons été contraint d’appeler des ex-employés de la société Apps2Com pour demander de l’aide.

Pour ne plus se retrouver dans l’embarras, il a fallu redévelopper la solution avec documentation.

C’est ainsi qu’est venu le projet UnicampRewritten, mené au sein d’Aberia pour remplacer ce service non maintenu. C’est un simple WebService qui récupère des paramètres dans une URL pour les insérer en base de données. Ce service pourtant simple est crucial pour certains clients, et le redéveloppement de la solution était donc une urgence.

Mise en œuvre

Premièrement, j’ai utilisé l’outil DotNetPeek pour désassembler la solution existante et l’analyser. Le projet utilisait le système de web services intégré à DotNet Framework, j’ai dont pris soins de me documenter sur cette technologie pour réécrire le service.

Ensuite, j’ai analysé le code désassemblé pour en comprendre les fonctionnalités, ce qui m’a aidé à les séparer et ranger en fichiers distincts. De là, j’ai factorisé des bouts de code redondants afin de rendre la maintenance plus simple. Dans le même but, et également pour simplifier la configuration du logiciel, j’ai remplacé des constantes “magiques” (chaîne de caractère ou nombre laissé sans explication) par des variables de configuration.

Pour rendre plus simple l’observation du logiciel et son comportement, j’ai ajouté des envois d’événements dans le “journal de bord Windows Server”. Cela nous permet, à moi comme à mes collègues administrateurs systèmes, de déboguer plus facilement et de pouvoir identifier les problèmes plus rapidement.

Après avoir testé et validé le logiciel, j’ai pris soins de créer un installateur avec NSIS pour faciliter l’installation et l’utilisation du programme. Le script NSIS va utiliser des commandes Batch et Visual Basic 6 (à ne pas confondre avec VB.Net) pour automatiser des tâches comme la création d’un service lancé au démarrage du serveur.

Enfin, j’ai documenté le projet, ce qui devrait nous éviter de nous retrouver dans la même situation qui a donné lieu à ce projet.

Résultats

Le projet final est installé chez nos clients. La VM Apps2Com n’est plus utilisée sur nos infrastructures, ce qui a réduit le besoin de ressources des clients en plus de garantir le fonctionnement de la solution.

Il est possible qu’une prochaine réécriture soit faîte pour s’accorder à des technologies non dépréciées, mais c’est difficile à dire étant donné le besoin de rétro compatibilité. Le plus probable est que le projet reste stable pendant un certain nombre d’années, jusqu’à ce qu’un autre service demande une réécriture.

Enfin, sur une note personnelle, ce projet m’a permis de m’améliorer dans la rétro ingénierie et de découvrir de nouvelles technologies. Je ne vois pas d’amélioration possible tenant compte du besoin de compatibilité avec l’existant. Certes, je pourrais rendre les chemins plus propres ; je pourrais demander un JSON au lieu d’une vingtaine d’informations dans l’URL ; je pourrais traduire les champs au lieu de rester sur du “franglais” ; je pourrais passer sur le Framework ASP.NET au lieu d’utiliser les webservices de .NET Framework. Mais toutes ces choses vont à l’encontre du besoin de rétro compatibilité, et ne peuvent donc pas être implémentées.

Acteurs principaux

Compétences