Services
Formation virtuelle IBM i
Découvrirez comment démarrer avec Watson sur IBM i aujourd'hui
En savoir plusSoutien technique
Les applications critiques d’IBM i (AS/400, iSeries) sont utilisées depuis des décennies et ont désespérément besoin d’aide à mesure que les entreprises se développent et que leurs besoins évoluent. Attendre signifie se retrouver avec une dette technique où les services des TI disent : "Nous y reviendrons plus tard".
Nous constatons régulièrement le besoin de redimensionner les champs de base de données à mesure que les entreprises se développent de manière organique ou via des acquisitions. S’il est réalisé manuellement, le redimensionnement des champs constitue souvent un projet de longue haleine, qui peut prendre des années. C’est pourquoi les entreprises évitent de s’y attaquer jusqu’à ce qu’elles n’aient plus d’autre choix.
Dans de nombreux cas, un projet de redimensionnement est assorti d’une date limite, car il est lié à la croissance de l’entreprise. Soudainement, le logiciel sur lequel vous avez compté pour vous donner un avantage concurrentiel n’est plus en mesure de soutenir cette croissance.
À première vue, le redimensionnement des champs dans les applications de générateur automatique de programmes (GAP) semble simple. En réalité, il s’agit d’un processus complexe qui peut entraîner toutes sortes de problèmes. Lorsque vous réalisez manuellement un projet de redimensionnement de champ dans des applications qui ont été créées et gérées pendant des décennies (souvent par plusieurs programmeurs), vous allez rencontrer des obstacles et introduire des erreurs humaines.
Un projet d’une telle ampleur pourrait paralyser les opérations.
Un client avec lequel je travaillais possédait 92 emplacements et son champ d’emplacements pouvait en compter un maximum de 99. Il devait passer à trois ou quatre chiffres pour soutenir sa croissance, tout en gérant les aspects quotidiens de l’application. C’est pourquoi il est important de chercher des moyens de réduire au minimum le temps et les efforts nécessaires.
Mener à bien un projet de redimensionnement de champ ne se fait pas en criant lapin. Les applications IBM i sont souvent le résultat d’un mélange de différents styles de programmation, et vous ne savez pas toujours ce que vous allez rencontrer lorsque vous commencez à creuser dans le code.
Même le programmeur le plus patient peut s’asseoir et revoir manuellement le code, découvrant ainsi les secrets cachés et les squelettes dans le placard. C’est un processus fastidieux et laborieux. Cependant, la fatigue du projet s’installe inévitablement et le programmeur s’ennuie. C’est la meilleure façon d’introduire des erreurs.
Trois éléments sont nécessaires à la réussite d’un projet de redimensionnement de champ. La première est la compréhension de l’application. Vous devez découvrir les renseignements qui déterminent les défis auxquels vous pourriez être confronté. Vous devez être en mesure de savoir où ces données sont transmises d’un programme à un autre en tant que paramètre. Vous pourriez rencontrer quelque chose comme des champs intelligents. Cette pratique est apparue parce que les programmeurs hésitaient à modifier un fichier.
Cela conduit à la subdivision d’un champ. Vous pourriez logiquement dire : « Ce champ contient trois valeurs. Je vais écrire mes programmes autour d’elles pour interpréter ces trois valeurs qui sont stockées dans le même champ. » Le redimensionnement de ce champ constitue un véritable casse-tête.
Vous devez déterminer quels sont ces champs et où ils se trouvent, ainsi que tout effet en cascade dans votre code. Il se peut que des données numériques stockées dans un champ alpha ne correspondent pas aux données stockées dans un autre champ parce qu’elles sont numériques.
La deuxième chose dont vous avez besoin est un ensemble complet de plans d’essai. Votre plan d’essai vous permettra de déterminer si vous avez mis à l’essai tout ce que vous devez mettre à l’essai. Pouvez-vous limiter vos essais aux éléments que vous avez réellement modifiés? Les essais de régression représentent un autre élément à prendre en compte, car il ne faut pas introduire de nouveaux comportements.
La troisième clé de la réussite est l’automatisation. Lorsque vous effectuez une modification, vous pouvez être amené à recompiler des centaines, voire des milliers d’objets dans l’ensemble de votre application. L’automatisation du processus le rendra plus efficace tout en réduisant les risques et le nombre d’heures humaines de travail nécessaires. L’automatisation vous permet de vous concentrer sur les éléments qui nécessitent une attention particulière.
L’analyse préliminaire de MEDHOST prévoyait que seuls 200 fichiers devraient être modifiés. Après la comparaison avec notre solution automatisée, X-Analysis, nous avons trouvé 1 600 fichiers qui nécessitaient des modifications. Pouvez-vous imaginer qu’il manque 1 400 fichiers dans votre projet de redimensionnement?
« Sur la base de l’ampleur et de la profondeur du projet, je ne peux pas imaginer le nombre d’heures humaines nécessaires pour faire ce que X-Resize peut faire en quelques heures sans que cela n’entraîne un risque d’erreur humaine. C’est vraiment incroyable. »
Cliff Dowell – Ingénieur logiciel principal, MEDHOST
Un autre client possédait une application relativement nouvelle et avait utilisé un dictionnaire de données pour faciliter les changements. Il a pu utiliser X-Analysis pour automatiser 95 % de l’effort, ce qui ne lui a laissé que 5 % de l’effort manuel.
New Penn est une société de transport nord-américaine qui souhaitait étendre son champ de numéros de clients pour soutenir sa croissance. L’estimation initiale du projet pour un travail manuel s’élevait à 13 ou 14 années-personnes et à plus d’un million de dollars. Lorsqu’elle a comparé cela au temps et aux efforts nécessaires à l’utilisation de X-Analysis, son estimation du projet a été ramenée à environ six mois et à une réduction des coûts de 90 %.
Vous devez connaître votre application. Vous devez savoir comment les choses interagissent. En fonction de la taille de votre application et du champ, le changement peut être petit ou important.
Vous devez également savoir ce qu’il faut rechercher. Quelles sont les zones de votre code qui vont poser des problèmes lorsque vous réaliserez un projet de redimensionnement? Le fait de les connaître vous aidera à comprendre la portée du projet et à vous préparer en matière de coûts et d’efforts.
Soyez organisé. S’il s’agit d’un effort important, je suggérerais de le réaliser en plusieurs livraisons, en le divisant en éléments plus petits pour des essais plus rapides. Les premiers changements à mettre à l’essai sont les objets qui ont simplement besoin d’être recompilés. Vous pourriez commencer par les exécuter, puis travailler sur les éléments qui nécessitent un effort manuel.
Enfin, les essais sont essentiels à la réussite d’un projet de redimensionnement. Les essais doivent être suffisants – ni trop, ni trop peu. C’est pourquoi je vous conseille de prendre le temps de comprendre vos plans d’essai et de les comparer au code que vous avez modifié afin de réduire la quantité d’essais à effectuer.
Mes collègues Robert Arce et Stephen Flaherty organisent une séance d’information le 12 avril au cours de laquelle ils discuteront plus en détail du redimensionnement des champs et présenteront la solution automatisée de redimensionnement de Fresche, X-Resize. Vous pouvez vous inscrire ici.
