Migration OSB/SOA Suite 12c dans le contexte d'un client

L’agilité du Système d’Information (SI) est un grand facteur de réussite pour accompagner l’innovation, la modernisation et améliorer l’efficacité opérationnelle d’une entreprise.
La SOA Suite d’Oracle prône être un outil permettant d’amener le SI vers cette fameuse agilité. Mais qu’en est-il en pratique ? Est-il possible de migrer de version simplement ? La SOA Suite 12c est disponible depuis déjà quelques temps, et nous allons détailler ici un cas concret de migration : son contexte, ses impératifs, sa méthode…

Contexte

Dans un contexte client, le choix de la plateforme d’intégration Oracle SOA Suite a été fait pour devenir l’épine dorsale des échanges :

  • Remplacement de connexions point à point de technologies hétérogènes
  • Amélioration de l’exploitabilité (suivi / monitoring)
  • Robustesse et performances
  • Urbanisation du SI

L’architecture SOA mise en place englobe :

  • Oracle Service Bus (OSB) pour les flux simples sans suivi particulier
  • Composant BPEL (SOA-Suite) pour les flux complexe nécessitant un suivi particulier

Les échanges en place sont synchrones et asynchrones, avec des connections vers des technologies diverses (http, web-service soap, web-service rest, jdbc…).

Pourquoi migrer

Alors que la 12c arrivait, la mise en place de la plateforme SOA a été réalisée en version 11g, ceci afin de respecter un calendrier fonctionnel préétabli. Cependant, la volonté a été de ne pas prendre de retard sur les versions : la 12c était prometteuse, que ce soit vis-à-vis de sa stabilité ou de ses nouveautés.
Une migration a donc été enclenchée à peine la 11g en production. L’objectif est clair : c’est une migration technique. L’impact pour les clients / producteurs de services doit être minimal voire nul !

Méthode de migration

Il existe donc déjà un environnement de 11g en production avec des services tournant quotidiennement. La qualité de service ne doit pas être impactée. Le challenge est donc de pouvoir déployer la nouvelle version en 12c sans perturber les services existants, dans des délais courts et un SI complexe.
Pour cela, il a été décidé de mettre en place une cohabitation 11g / 12c pendant toute la période de migration.
2 instances existent donc :

  • Une 11g : services en place, services déjà en cours de développement en v11
  • Une 12c : nouveaux services, migration iso-fonctionnelle au fil de l’eau des anciens développements v11.

Concernant la « transparence » pour les clients, nous nous sommes appuyés sur le serveur HTTP frontal (Oracle HTTP Server – OHS) à notre plateforme pour rediriger nos clients lors d’une migration d’un service : les appels sont filtrés par rapport au pattern de l’URL demandée, et redirigés selon leur état de migration vers la 11g ou la 12c.
Côté client, aucun changement d’URL pendant la migration. De ce fait, la bascule peut être faite progressivement flux par flux grâce à ces filtres, tout en offrant un retour arrière rapide (suppression filtre) en cas de problème sur une migration.
Seul impact rencontré : les liaisons pour les files JMS, qui ont nécessité une simple coordination avec une évolution applicative pour effectuer concrètement la bascule 11g vers 12c.

Conclusion

La bascule vers la 12c a finalement été :

  • Progressive (service par service)
  • Transparente pour les clients (99%)
  • Sécurisée (retour arrière possible)

En conclusion, cette migration a été réalisée sans perturber les services existant en production. Les développements 11g ont pu être migrés facilement en 12c, sans surprises majeures. Une méthode basée sur des principes simples qui s’est révélé une réussite !
 

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *