Migrer d’un environnement transactionnel propriétaire  vers Java EE

Cette partie aborde l’aspect pratique du portage d’une application d’une plateforme transactionnelle XATMI vers la solution Bull LiberTP. Le déroulement du projet que nous présentons ici se base sur des cas réels avec des applications comptant plusieurs millions de lignes écrites en COBOL ou en C.

Un projet en quatre étapes

Etape 1 : Etablir les objectifs du projet

But : Définir le périmètre de la migration, inventorier les parties prenantes et négocier leurs attentes.

Déroulement et rôles : L’équipe projet est constituée et définit concrètement les attentes du projet, par exemple selon les impératifs de pérennité, baisse du coût total, nouveaux besoins ou simplification d’architecture. Selon ces attentes, les départements de l’entreprise impliqués pourront varier. Ainsi, si les objectifs du projet sont exprimées en termes de compétitivité sur le marché ou d’attente des utilisateurs, les directions opérationnelles joueront un rôle majeur.

Délivrable : Un plan projet est établi selon le résultat de ces investigations, et approuvé par les parties prenantes. Parallèlement, un inventaire des modules techniques est établi (exécutables, code source, serveurs, fichiers de configuration, liste de services – sans oublier les parties clientes sur les PCs), ainsi qu’une liste des fonctions et adhérences.

Durée typique : deux semaines à un mois.

Critères de succès : Les buts du projet doivent être reliés à des objectifs stratégiques de l’entreprise. Par exemple : gagner en agilité commerciale, réduire les coûts de fonctionnement, faciliter les échanges avec fournisseurs et revendeurs. Le projet doit être constitué d’une série d’étapes planifiées dont le résultat attendu sera visible et chiffré.

Etape 2 : Audit et proof-of-concept  – POC

But : S’assurer de la faisabilité technique, déterminer les adhérences avec d’autres modules, tester l’administration quotidienne du résultat final et évaluer le coût du projet complet.

Déroulement et rôles : L’application initiale est exécutée telle quelle sur le nouveau moteur Bull LiberTP dans un mode de compatibilité. Ce test peut se faire dans les locaux de l’entreprise, sur ses plateformes, avec ses données (réelles, anonymisées ou simulées) et dans son environnement. Il peut aussi se faire dans les locaux du fournisseur ou de ses partenaires.

On peut généralement se contenter de tester un sous-ensemble significatif des modules de l’application globale. Mais dans certains cas, l’application à porter est difficilement fractionnable et il faut alors tester une partie importante de l’applicatif. Cela nécessite une étude particulière au cas par cas.

L’entreprise fournit les scénarios de test car elle connaît le mieux son application et les exigences de ses utilisateurs. Le prestataire migre le fichier de configuration initiale vers Bull LiberTP, effectue un « link » des binaires avec les librairies LiberTP. L’application est déployée sur le nouveau serveur d’applications. La partie cliente est également traitée selon les environnements utilisés.

Un fichier de configuration décrit la structure modulaire d’une application utilisant un moniteur transactionnel tel que Bull LiberTP ou Oracle Tuxedo. Ainsi, des groupes de serveurs sont définis, chaque serveur hébergeant des services qui accèdent à des bases de données. Une politique de routage interservices y est définie et les groupes de serveurs sont placés dans des machines physiques ou virtuelles. Dans un projet de portage, ce fichier de configuration est migré de façon automatisée.

Délivrable : Le résultat du POC est un rapport de faisabilité établi par le prestataire et le client. A l’issue du POC, l’entreprise constate que son application est opérationnelle sur Bull LiberTP.

Durée typique : une à deux semaines.

Critères de succès : L’objectif de cette intervention est de garantir la faisabilité technique du projet. Il est donc très important de bien préparer le POC, en mettant l’ensemble des éléments demandés à la disposition du prestataire. Il faut tirer parti de cette phase pour effectuer un transfert de compétences et évaluer financièrement le portage complet.

Etape 3 : Portage et adaptation du code source

But : Le fournisseur porte le code source pour le nouvel environnement. Le code COBOL reste en COBOL (et le code C reste en C). Mais dans ce code,  des appels de  fonctions  de l’ancien environnement sont modifiés vers leur équivalent sous Bull LiberTP.

La structure modulaire du code source reste la même, et les appels de fonctions créées par l’entreprise sont inchangés. Pour les développeurs spécialisés en logique métier, l’impact de cette opération est minime ou nul. Les modules applicatifs peuvent également tourner à l’identique avec des outils de compatibilité (« wrappers »).

Déroulement et rôles : L’implication de l’entreprise est minimale dans cette phase – elle doit cependant nommer un interlocuteur familier avec la structure du code. Cet interlocuteur répondra aux questions du prestataire effectuant le travail de portage.

Délivrable : A l’issue de cette phase, l’entreprise réceptionne une application adaptée au nouvel environnement transactionnel. Fonctions, architecture et modularité sont équivalentes à celles de le l’application tournant sur l’environnement précédent. Les développeurs COBOL ou C sont immédiatement opérationnels (s’ils ne traitent que la logique métier) ou reçoivent une formation sur les particularités de l’environnement.

Durée typique : quelques semaines.

Critères de succès : Fournir tous les éléments requis au prestataire : code source et exécutables notamment. Tirer parti de cette phase pour organiser la formation des programmeurs et administrateurs.

Etape 4 : Tests fonctionnels et de performance

But : S’assurer de l’équivalence fonctionnelle de l’application à l’issue du portage. Evaluer les performances en exploitation réelle et les optimiser si nécessaire.

• L’objectif principal des tests fonctionnels est de garantir que l’application apportera les mêmes fonctions à l’issue du portage. L’objectif secondaire est de tester les procédures d’évolution du code et d’administration quotidienne, pour s’assurer que les opérations courantes restent possibles.
• Les tests de performance reviennent à s’assurer que la réactivité de l’application sera similaire ou supérieure (du point de vue de l’utilisateur final), tout en lui dédiant des ressources équivalentes.

Notons que les tests de performance sont particulièrement importants pour un éditeur de logiciels. Il serait en effet délicat d’exiger de son client des investissements matériels supplémentaires, sous prétexte que le « runtime » transactionnel embarqué a changé.

Déroulement et rôles : L’entreprise installe sur son environnement de développement et testsl’application portée. Elle effectue les tests de non-régression et de montée en charge.

L’entreprise peut utiliser pour cela les tests habituels qu’elle exécute lors de l’introduction de nouvelles fonctions. Dans certains cas, ces tests automatisés font appel à des fonctions de l’environnement propriétaire – il faudra donc les adapter.

Délivrable : L’application portée sur Bull LiberTP est prête à être mise en production.

Durée typique : un à deux mois.

Critères de succès : Tirer parti de l’expérience du prestataire, lequel peut orienter les tests et connaît les opportunités d’optimisation. Anticiper cette phase en développant de nouveaux jeux de tests, notamment pour les essais en charge. Les programmeurs, parfois sceptiques devant un changement d’architecture, doivent participer activement lors de cette phase.

Après le portage : les étapes suivantes

A la fin du projet de portage, l’entreprise obtient une application fonctionnellement équivalente, mais tournant désormais sur un environnement Java EE. Elle peut alors envisager l’ajout de fonctionnalités rendues possibles par la nouvelle base technologique. Nous en décrivons ci-dessous quelques exemples.

Passage sur client léger

Pourquoi : De nombreuses applications propriétaires fonctionnent en mode client-serveur : une partie cliente fonctionnant sur Windows (par exemple sous Visual Basic) accède la partie serveur. Ce mode de fonctionnement n’est pas adapté aux usages sur tablette ou smartphone.

Description : Ce projet rapatrie la logique métier contenue dans les clients sous Windows pour la faire s’exécuter comme application web dans le serveur Java EE.

Changement de base de donnée

Pourquoi : Certains moniteurs transactionnels propriétaires ne sont  pas conçus pour exploiter nativement des bases de données ouvertes telles que PostgreSQL.

Description : Dans ce projet, les données sont migrées vers PostgreSQL. Cela implique de répliquer le schéma de données, les données elles-mêmes et les configurations. La difficulté du projet dépend des adaptations spécifiques, telles les procédures stockées. Bull a développé des outils et services pour faciliter cette migration.

Développements de nouveaux modules en Java

Pourquoi : A la fin du portage, le code COBOL (ou C) tourne sur Java EE. Il est alors possible d’envisager de développer les nouvelles fonctions en Java, voire de porter graduellement des modules COBOL (ou C) vers Java.

Description : Les développeurs COBOL (ou C) sont formés sur Java – ou des développeurs Java de l’entreprise sont recrutés sur l’application. Ils reçoivent une formation sur les particularités de l’environnement Java EE. Il est d’ailleurs une bonne idée de demander au prestataire de portage  de fournir des exemples de code Java adapté à Bull LiberTP.