Espace technique		Accueil Espace technique IsiNews
	IsiNews S'abonner gratuitement Archives		IsiNews Novembre 2007 Migrer une application WinDev 5.5 vers WinDev 10 ou 11 : ce qu’il est bon de savoir avant de commencer, les pièges à éviter. Si la migration d’une application de WinDev 7,5 vers une version supérieure (8, 9, 10 et 11) ne pose pas de problème particulier (une simple recompilation suffit), il n’en n’est pas de même pour la migration d’une application WinDev 5.5 en 7.5. En effet, la version 7.5 a marqué une rupture importante avec les versions précédentes de WinDev. La version 7.5 est en réalité une refonte complète de l’environnement de développement qui s’est notamment ouvert aux bases de données standards du marché grâce à l’ajout d’un moteur SQL. La migration en version 7.5 est par conséquent une étape transitoire mais incontournable pour faire évoluer une application 5.5 en version 8 (ou supérieure). Cette opération peut s’avérer délicate si l’on ne prend pas le soin de s’entourer d’un certain nombre de précautions et de respecter certaines règles. Nous avons choisi dans le cadre de cette lettre technique de donner la parole à Romain, qui donne des éléments de réponse aux questions fréquemment soulevées par les développeurs chargés de migrer du code en WinDev 7.5. Romain est chef de projet au sein d’ISIMEDIA rattaché à notre agence parisienne. Romain a supervisé avec succès et à plusieurs reprises, des travaux de migration. Retour d’expérience : Romain Date d’entrée: Novembre 2006 Poste occupé: Chef de projet, rattaché à l’agence parisienne Clients suivis: Ministère de la justice, Société des Eaux du Nord Existe-t-il des précautions particulières à prendre avant de réaliser d’une migration ? Faire le choix de migrer une application en version 5.5 implique que l’application soit saine du point de vue de son architecture. L’application doit être stable mais aussi pérenne : la structure de la base et la qualité des codes sources doivent permettre l’ajout dans le futur, de nouvelles fonctionnalités dans de bonnes conditions, si l’application est appelée à évoluer. La présence d’anomalies en version 5.5 compliquera également la tâche du développeur lors de la recette de la migration. L’application doit donc être épurée de toute anomalie. Il faut également, même si cela semble évident, s’assurer que l’on dispose des compétences fonctionnelles suffisantes pour pouvoir valider l’application migrée. Enfin, il faut, si l’application s’appuie sur une base Hyper File, étudier dans le détail l’analyse et plus particulièrement la structure des fichiers ; En effet, l’utilisation de clés composées ajoutera du travail en aval et potentiellement en amont de la migration. C'est-à-dire ? La manipulation des clefs composées (d’éléments simples ou d’éléments composés) ne se fait pas de la même manière en W-Langage 5.5 et en W-Langage en 7.5. Toutes les portions de code qui manipulent des clefs devront être reprises manuellement. Concernant le portage des données de ces clefs composées, il faut distinguer deux cas : 1) les données des clés composées de clés simples sont portées sans problème 2) les données des clés composées de clés composées ne supportent pas un portage direct (il faudra modifier l’analyse avant migration de manière à supprimer les clés composées de clés composées) Quelle démarche préconisez-vous pour migrer une application WinDev 5.5 en WinDev (9, 10 ou 11) ? Il est préférable, pour les raisons que je viens d’évoquer, de migrer les données en même temps que le code. Pour le code, nous préconisons : - D'ouvrir le projet 5.5 avec la version 7.5 de WinDev, de compiler et de sauvegarder sans toucher au code. - D’ouvrir le projet sauvegardé en version 7.5 avec la version cible (WinDev 9, 10 ou 11). La retouche du code sera réalisée dans cet environnement. Je conseillerai donc de retoucher le code directement en version 9 ou dans une version supérieure et non pas d’effectuer les corrections en version 7.5 puis de migrer à nouveau. Pour quelles raisons ? Lors de l’ouverture d’un code migré, WinDev génère une liste d’erreurs et d’alertes dont le nombre est généralement proportionnel à la taille du projet. On distinguera 2 types de messages (d’erreurs et d’alertes) : - Les messages qui signalent des problèmes provoqués par la migration - Les messages liés à des erreurs résiduelles (principalement dues à la présence de code mort non appelé). Pour cette deuxième catégorie de message, les fonctions de recherche avancées disponibles à partir de la version 9 permettront d’identifier le code mort qu’il ne sera pas nécessaire de corriger (cela évitera au développeur de mettre à niveau du code qui n’est plus appelé). De plus, depuis la version 11, des outils de rétro modélisation des liens entre les procédures et fonctions permettent une analyse très fine de l’organisation du projet. Il devient alors beaucoup plus facile de maitriser l’impact des modifications effectuées sur le code. Vous parliez des problèmes provoqués par la migration. Pouvez-vous en citer quelques uns ? Sans être exhaustif, les problèmes couramment rencontrés sont les suivants : - La logique de gestion des variables globales et des variables locales a été modifiée à partir de la version 7.5 ; Après migration, certaines variables se retrouvent inconnues ou inaccessibles (certaines déclarations sautent) et il convient de les re-déclarer dans le projet (soit en local, soit en global). en procédant à une analyse fine du code afin d’identifier la portée de chacune. - Certaines fonctions du W-langage sont signalées comme obsolètes et conservées pour compatibilité. Il convient de les remplacer par des fonctions plus récentes. C’est le cas notamment, des fonctions HCréeVue et HInfoGene Quels conseils donneriez-vous pour faciliter le travail de mise à niveau du code ? Je préconiserai d’effectuer une sauvegarde des 3 versions (5.5, 7.5, et version cible) des codes sources et des données (si l’application s’appuie sur une base Hyper File) afin de pouvoir vérifier le code et le comportement de l’application dans chacune de ces versions, lors de la phase parfois délicate du débogage. Pourquoi conserver une version du code intermédiaire 7.5 ? C’est un principe de précaution. Même si nous ne l’avons jamais constaté, cette précaution permet de s’assurer que seul le portage de la version 5.5 vers la version 7.5 a eu des conséquences sur le code. Existe-t-il un gain immédiat, une fois l’application migrée ? Du point de vue des temps d’exécution, il est très peu probable qu’une simple migration améliore significativement les performances ; le gain sera d’autant plus faible si les données sont manipulées avec les fonctions HFiltre et HCréeVue. Une simple migration ne remplacera pas ces fonctions (compatibles jusqu’en version 11), peu performantes en terme de temps de réponse lorsqu’elles sont utilisées pour effectuer une interrogation complexe de données. Un remplacement de ces fonctions par des accès SQL et éventuellement l’utilisation de la version client serveur d’HyperFile pourront être envisagés pour améliorer les performances. Le gain obtenu sera d’autant plus important que la version de WinDev cible utilisée sera récente, le moteur SQL étant en constante progression depuis la version 7.5. Du point de vue de l’ergonomie et du confort d’utilisation, c’est la même chose. Il faudra reprendre l’interface à postériori pour pouvoir exploiter les possibilités graphiques proposées par les dernières versions de WinDev (qualité des gabarits, gestion de l’agrandissement…) La migration est par conséquent une étape incontournable si l’on souhaite faire évoluer une application pour tirer profit des avancées (majeures) des dernières versions de WinDev (d’autant plus que la version 5.5 de WinDev n’est plus supportée par l’éditeur). Dans une démarche qui vise à optimiser et améliorer une application existante, la migration doit donc être considérée comme une étape nécessaire mais pas suffisante. Haut de page S'abonner gratuitement Télécharger l’IsiNews au format Pdf
			Mentions légales