L'organisation financière virtualise SAP et migre en toute transparence son système hérité

Le projet

Une organisation financière se lançait dans une mise à niveau technologique, impliquant SAP comme son principal partenaire technologique de remplacement pour migrer hors de ses systèmes backend hérités. Voulant tirer parti de la plate-forme Middleware existante pour passer en toute transparence de l'ancien au nouveau sans entraver l'expérience client, l'organisation a recherché une solution qui pourrait lui donner confiance dans les changements apportés au sein de son système Middleware.

L'approche

L'un des principaux risques techniques consistait à s'assurer que la logique de mappage et de transformation dans le système middleware était correcte une fois la migration effectuée. Après avoir examiné les options, il a été déterminé que l'approche la plus rentable et la plus fiable consistait à supprimer la dépendance entre le middleware et les systèmes backend en virtualisant SAP. Cela fournirait un moyen de créer la logique de commutation dans son composant Middleware avant que les interfaces SAP ne soient disponibles, ainsi que de pouvoir répéter les tests sans les frais généraux de configuration et de démontage des données.

Le prochain défi de l'organisation était de justifier l'investissement pour passer d'une approche de test manuel (au niveau de la couche de service) à une approche automatisée sans fonctionnalité de bout en bout. Le retour sur investissement était une mesure simple que les parties prenantes pouvaient comprendre et à laquelle s'identifier : l'évitement des coûts liés aux défauts. S'ils pouvaient trouver 3 défauts par opération lors de la phase de développement, cela éviterait un coût de résolution des défauts plus important lors de la phase d'intégration du système. A l'issue de la phase de développement, ils avaient dépassé le ROI de 68%.

Avant le projet de mise à niveau, le processus de test manuel existant de l'équipe était en mesure de suivre le rythme des mises à jour des applications. Cependant, une fois le projet entièrement cadré, il est devenu clair que le processus manuel existant ne serait pas suffisant, compte tenu du temps nécessaire pour configurer les données dans SAP, en attendant la mise à disposition de SAP, ainsi que le nombre d'itérations logicielles attendues. .

Les Résultats

Virtualisation

L'avantage le plus évident de la virtualisation des services était que l'équipe pouvait commencer à développer et à tester le comportement anticipé des nouveaux systèmes backend avant que ces systèmes ne soient réellement déployés.

Avantages supplémentaires inclus :

• Ils n'avaient plus à attendre pour obtenir les données de test nécessaires à chaque test ou pour que les données de test soient reconfigurées à l'état souhaité (par exemple, rouvrir un compte qu'un test ferme afin qu'il soit prêt pour le prochain test automatisé).
• Ils pouvaient facilement imiter un large éventail de conditions de réponse du système principal (variations de données, conditions de défaillance, variations de performances), ce qui les aidait à détecter des problèmes complexes avant le déploiement.
• Étant donné que les réponses virtualisées étaient validées et cohérentes, l'équipe savait que tout problème détecté avec les messages de réponse provenait en fait d'un problème avec l'application en cours de test, et non d'une mise à jour, d'une reconfiguration ou d'un échec du système principal.
• L'équipe a commencé à créer des tests automatisés pour chaque opération SAP alors que le code middleware associé était en cours de modification. Les tests ont été définis avec Parasoft SOAtest, qui travaille aux côtés Parasoft Virtualiser dans l' Plateforme de test continu Parasoft.
• Les backends auxquels l'application testée communiquait, mais ne faisaient pas partie du périmètre de test, ont été virtualisés pour toujours donner une réponse réussie. Cela a rendu les tests plus fiables (car ces backends étaient parfois indisponibles ou avaient des problèmes d'authentification avec nos données) et capables de se concentrer sur le test de l'objectif du test.
• Étant donné que la virtualisation obligeait l'équipe à reproduire le comportement du back-end, cela les a obligés à approfondir le fonctionnement du back-end.
• Dans l'un des systèmes les plus complexes, ils ont travaillé avec le développeur Middleware et les développeurs SAP pour déterminer comment le mappage se déroulerait et ont pu simuler une réponse des développeurs SAP dans Virtualize pour aider le développeur à créer correctement le code Middleware. .

Test de la boîte blanche

Du point de vue du développement, il ne suffisait pas de simplement valider les demandes et les réponses étaient renvoyées comme prévu, mais les orchestrations internes, le flux de travail et la sortie en aval étaient corrects. L'équipe a intégré la surveillance des événements de Parasoft au système middleware pour inspecter chaque flux de messages et s'assurer que les résultats étaient conformes aux attentes.

Résultat

À la fin de la livraison, l'équipe a accumulé une suite de tests automatisés qui pouvait être exécutée après chaque nouvelle version de middleware. Le nombre de backends virtualisés s'élève à 8.