Il y a quelques mois, l'équipe de recherche de Berger Levrault a publié un article sur les résultat d'une expérience permettant à une application JAVA de fonctionner avec une application Visual Basic 6. Ces travaux ont montré qu'il était possible d'utiliser des composants métier développés en Visual Basic 6 à partir de JAVA et même de "faire tourner" une application entière sans avoir à utiliser son interface graphique.
La même équipe est heureuse d'annoncer que la même approche a été reproduite avec succès mais cette fois avec le langage PowerBuilder dans sa version 12.5. Même si ce langage est très différent du VB6, les problématiques liées à PowerBuilder sont les mêmes, notamment en termes de fonctionnement : pas de programmation web possible, pas de séparation fonctionnelle claire du code et enfin opacité du travail réel du compilateur.

PowerBuilder est un environnement de développement intégré détenu par SAP depuis l'acquisition de Sybase en 2010. Le 5 juillet 2016, SAP et Appeon ont conclu un accord selon lequel Appeon serait responsable du développement, des ventes et du support de PowerBuilder. Au fil des années, PowerBuilder a été mis à jour avec de nouvelles normes. En 2010, une mise à jour majeure de PowerBuilder a été publiée pour assurer le support de Microsoft .NET Framework. Le support officiel des versions 12.5.1 et antérieures a pris fin en avril 2013. PowerBuilder 12.5.2 a pris fin le 31 août 2015.

PowerBuilder possède un objet natif de gestion de données appelé DataWindow, qui peut être utilisé pour créer, modifier et visualiser les données de la base de données. Cet objet donne au programmeur plusieurs outils pour spécifier et contrôler l'apparence et le comportement de l'interface utilisateur, et fournit également un accès facile au contenu de la base de données.

PowerBuilder est un langage de programmation orienté objet. Presque tous les objets visuels et non visuels supportent l'héritage, le polymorphisme et l'encapsulation. Le programmeur peut utiliser un cadre de code commun tel que PowerBuilder Foundation Classes, également connu sous le nom de PFC, pour hériter des objets d'un code préexistant et en tirer parti. Les applications PowerBuilder sont généralement compilées en p-code, qui est ensuite interprété par le moteur d'exécution PowerBuilder. Bien qu'il soit possible de compiler en code machine, une application d'entreprise typique ne s'exécute pas beaucoup plus rapidement, sauf pour les calculs intensifs du CPU. La principale raison pour laquelle la compilation en code machine n'a pas été utilisée est due à de nombreuses erreurs dans PowerBuilder, notamment dans la génération du code machine.
L'extensibilité du langage est plutôt limitée pour les anciennes versions de PowerBuilder. Powerbuilder fournit pour pallier à cela une extension C ++ appelée PBNI (PowerBuilder Native Interface). Le développement d'une solution incluant du code C ++ externe nécessite non seulement des développeurs C ++ compétents, mais aussi un expert PowerBuilder pour guider le développeur à travers la myriade de subtilités du langage et de la machine virtuelle. PowerBuilder.
L'héritage et les fonctionnalités orientées objet sont limités à certains types d'objets (fenêtres, objets utilisateur et menus). En particulier, il n'est pas possible d'hériter d'une DataWindow.

L'interopérabilité, une question de code natif.

La façon d'échanger entre deux langages informatiques consiste à réduire leur composition au niveau le plus bas possible, en langage machine, c'est-à-dire en binaire, puis à remonter au besoin vers l'un ou l'autre langage.

Dans notre cas, l'extension PowerBuilder "PBNI" (PowerBuilder Native Interface), inspirée de la Java Native Interface, aura apporté une partie de la solution. En effet, cette extension, fournie nativement depuis PowerBuilder 11, permet d'"embarquer" la machine virtuelle PowerBuilder (PBVM) dans une application C ++. Avec pour effet immédiat d'être compilé en ... langage machine !

En faisant de cette application C ++ une Dynamic-Link Library (DLL) classique, nous résolvons le second problème, qui est d'exposer les fonctions de nos objets powerbuilder. En effet, la DLL C ++ accède à l'application Powerbuilder et aux objets qui la composent, puis la DLL elle-même expose des fonctions représentant l'accès à l'ensemble de l'application Powerbuilder, et nous utilisons ces fonctions pour accéder depuis java aux résultats des appels de fonctions correspondant aux requêtes du client WEB. Cette passerelle est fournie par JNA (Java Native Access), une surcouche de JNI (Java Native Interface).

• La dernière question est celle de l'architecture cible, du côté de JAVA. En effet, plusieurs optiques sont possibles :
  Représenter complètement ce qu'est une application Powerbuilder du côté Java permet d'envisager de programmer de nouvelles fonctionnalités en utilisant des objets et des méthodes de Powerbuilder dans des classes java. Cela implique également d'"alourdir" le code cible avec un volume important de code qui doit disparaître une fois la migration terminée.
• Représenter uniquement ce qui est unique à une application Powerbuilder par rapport à une autre application PowerBuilder, cette fois-ci du côté C ++ DLL offre la garantie de fluidité et de rapidité d'exécution, cependant cela implique une opacité importante pour les développeurs et une difficulté significative à coder de nouvelles fonctionnalités du côté JAVA. Dans ce contexte, Java n'accède qu'aux fonctions (points d'entrée) de l'application et non aux objets qui la composent.

Les deux options garantissent le même résultat d'accès, que ce soit à l'exécution d'une application (avec son contexte) ou aux objets métier qui la composent.

JNA est construit et testé sur macOS, Microsoft Windows, FreeBSD / OpenBSD, Solaris, GNU avec Linux, AIX, Windows Mobile, et Android. Il est également possible de modifier et de recompiler les configurations de construction natives pour le faire fonctionner sur la plupart des autres plateformes qui exécutent Java. Avec Java et Java Native Access, nous pouvons remplacer le "Main" d'un programme VB (Context) par une application Java qui utilise l'objet COM (Dll) comme code logique d'entreprise.

Cette approche a été testée et validée sur un outil de la suite Santé des solutions Berger Levraut, elle a montré la possibilité d'envisager une migration technologique itérative et la possibilité de coder de nouvelles fonctionnalités dans un autre langage. En effet, cette approche garantit des mises en production régulières et testées. De plus, elle permet la mise en œuvre immédiate de pratiques " modernes " telles que le " Test Driven Management (TDD) " puisque les langages cibles peuvent mettre en œuvre dès le début de notre processus de migration les frameworks les plus performants dans ces domaines.

Conclusion

Après Visual Basic 6, l'équipe Migration et Architecture de Berger Levrault démontre à nouveau, mais cette fois avec PowerBuilder, que les langages et frameworks de programmation les plus anciens, non maintenus et sans support de la part de leurs éditeurs ; ne nécessitent pas nécessairement un processus de migration avec une réécriture totale des applications.
Le département Migration et Architecture de la Direction de la Recherche, de l'Innovation et de la Technologie de Berger Levrault casse ici l'idée que l'on peut avoir d'une migration avec tout un laps de temps avec une réécriture complète de l'application dans un nouveau langage, et où celle-ci ne peut être déployée que lorsqu'elle est presque entièrement recodée.

En proposant une approche technique et architecturale centrée sur les besoins transversaux des clients, des équipes de développement et de l'entreprise, BL démontre une fois de plus sa capacité à proposer des solutions innovantes et efficaces.