Nous maintenons un système qui contient plus d'un million de lignes de code COBOL. Est-ce que quelqu'un a des suggestions sur la façon de migrer vers une interface graphique (probablement basée sur Windows) sans perdre toute la logique métier que nous avons écrite en COBOL? Et oui, une partie de la logique métier est enterrée dans l'interface utilisateur actuelle.Migration vers une interface graphique sans perdre la logique métier écrite en COBOL
Ecrire un screen scraper est probablement votre meilleur pari. Certains des principaux systèmes ERP l'ont fait pendant des années au cours d'une transition entre les applications basées sur le serveur et les applications à trois niveaux. Un que j'ai travaillé avec avait des tas de fonctionnalités intéressantes telles que des listes déroulantes pour les champs régulièrement utilisés, les pop-ups de date et même les langages de macro basés sur le client basé sur l'entrée de grattage.
Ce n'était pas génial, mais cela a bien fonctionné pour les clients et fait en sorte que les applications fonctionnent toujours de manière fiable.
Il y a beaucoup de façons différentes de mettre cela ensemble, mais si vous y mettez un peu de réflexion, vous pouvez probablement utiliser java ou .net pour créer une application basée sur le bureau et avec un peu d'effort.
Si elle était moi je chercherais en quelque chose comme ceci:
Il devrait être assez facile à envelopper votre COBOL avec une interface qui expose la fonctionnalité (si elle est pas déjà écrit que façon), puis l'appeler à partir d'une application .NET.
Il nous a fallu environ 15 ans pour descendre de notre ordinateur central, parce que nous n'avons pas fait quelque chose comme ça.
Microfocus fournit un outil appelé Enterprise Server qui permet à COBOL d'interagir avec les services Web. Si vous avez un programme COBOL A et un autre programme COBOL B et A appelle B via la section interface, l'outil vous permet d'exposer la section d'interface de B en tant que service Web.
Pour le programme A, vous générez ensuite un proxy client et A peut maintenant appeler B via un service Web.
Bien sûr, parce que B dispose maintenant d'un service Web, tout autre type de programme (ligne de commande, application Windows, Java, ASP, etc.) peut désormais l'appeler. En utilisant cette approche, vous pouvez "grignoter sur les bords" pour déplacer l'interface graphique vers une approche moderne basée sur un navigateur utilisant quelque chose comme ASP tout en utilisant le moteur métier COBOL.
Et une fois que vous avez un ensemble de services Web décent, ceux-ci peuvent être utilisés pour tout nouveau développement qui offre un moyen de s'éloigner de COBOL à plus long terme.
Vous pouvez utiliser un ESB pour exposer les services hérités principaux, puis coder votre interface graphique pour appeler les services via l'ESB.
Ensuite, vous pouvez commencer à remplacer les services existants par des implémentations sur votre nouvelle plate-forme.
L'interface utilisateur graphique ne doit pas être consciente de la coupure de l'implémentation du service dorsal, tant que l'interface avec le service ne change pas - des modifications mineures peuvent être cachées à l'interface graphique par l'ESB.
La logique métier qui réside dans la couche d'interface utilisateur héritée devra être refactorisée en extrayant la logique métier et en l'exposant en tant que nouveaux services sur la nouvelle plate-forme à consommer par la nouvelle interface via l'ESB. En ce qui concerne le choix de la plate-forme pour la nouvelle interface graphique, pourquoi ne pas envisager une interface Web plutôt qu'une plate-forme Windows native, alors au moins les mises à jour de l'interface utilisateur devront seulement être appliquées au serveur Web plutôt que devoir déployer des modifications sur chaque poste de travail individuel.