Migration OIC Gen2 vers OIC Gen3 : une success story avec Club Med

Depuis août 2022, la version Gen3 d’Oracle Integration Cloud (OIC) est disponible, offrant de nouvelles fonctionnalités et améliorations de performance. La migration d’Oracle Integration Cloud (OIC) Gen2 vers Gen3 est une étape cruciale pour les entreprises utilisant cette plateforme. Encouragée par Oracle, elle deviendra bientôt obligatoire.

Cet article vous guide à travers les principales étapes de cette migration, l’expérience réussie de Club Med, leader mondial des vacances tout compris, dans sa transition vers OIC Gen3.

Étape 0 : Définir une politique de migration OIC Gen2 vers Gen3

Oracle prévoit de migrer toutes les instances en même temps, production et non-production. Cependant, dans le cas de Club Med, nous avons opté pour une approche personnalisée :

• Intégrations externes : Toutes les intégrations sont appelées depuis l’extérieur via un orchestrateur central qui gère les différents flux multi-applications de Club Med.

• API Gateway : Nécessité de tester l’API Gateway, car la documentation de la Gen3 est insuffisante.

• Continuité des services en production : Éviter tout risque d’interruption de plus de 24 heures en production.

• Besoins spécifiques de développement : Transition rapide de l’instance de développement vers Gen3 pour bénéficier de la ségrégation des accès par projet.

Étape 1: Remplir les conditions d’éligibilité à la migration

Pour assurer au mieux le succès de la migration Oracle Integration Cloud Gen2 vers Gen3, une liste de prérequis est mise à disposition par Oracle. Cette liste indique les impacts de la migration à différents niveaux (instance, intégration, adaptateur, agent de connectivité etc.) et les actions à mener pour que celle-ci puisse se faire.

Une page de vérification automatisée est aussi mise à votre disposition par Oracle directement sur chacune de vos instances OIC (accessible via Settings > Upgrade). Oracle effectue automatiquement des tests pour vérifier l’éligibilité de chacune de vos instances selon les domaines de prérequis et vous notifie via un tableau des alertes bloquantes.

L’ensemble de ces prérequis mais aussi les actions associées pour leur correction est accessible sur la documentation d’Oracle.

Nous recommandons de passer en revue la totalité de ces prérequis pour avoir une vision des changements même si selon l’automatic check décrit plus haut, ils ne vous concernent pas.

Voici un exemple d’alerte que vous aurez sur cette console : les agents de connectivité doivent être opérationnels et tourner pendant l’upgrade. Ils doivent également utiliser JDK 17 et PKCS12 KeyStore. Une liste des adaptateurs non supportés en Gen3 est également mise à disposition.

Étape 2 : Programmation et préparation de la migration d’OIC

Après avoir validé l’ensemble des actions requises et pris connaissance des changements de fonctionnement après la migration, vous pouvez vérifier si votre instance est prête à être migrée depuis la même section « Upgrade » dans la rubrique « Settings » d’OIC.

Planification de la migration d’Oracle Integration Cloud

L’information détaillant votre date d’upgrade sera disponible sur OIC sur cette même rubrique mais aussi via un bandeau présent sur l’accueil. Il se matérialisera sous la forme d’un compte à rebours. Un mail contenant la plage horaire sur laquelle se déroulera la migration sera aussi envoyé, par Oracle aux administrateurs de l’instance. Attention, cette dernière méthode de notification n’est pas la plus optimale. Nous vous recommandons de suivre les informations disponibles sur l’instance.

Si toutefois vous recevez des informations contradictoires, créez rapidement une SR au support Oracle pour lever toute ambiguïté. Joignez-y une capture d’écran de votre instance ainsi que l’email reçu. Ils sauront être réactifs et corriger le non-alignement.

La date d’upgrade définie par Oracle est modifiable si elle est à plus de 3 jours ouvrés de la date actuelle. Attention, prévoyez large. Les délais pour avoir un nouveau créneau peuvent aller jusqu’à un mois.

Activités d’administration de plateforme

Une fois la planification de la migration effectuée, des éléments de paramétrages de celle-ci sont à revoir. Par exemple, si votre instance dispose de connexions qui utilisent des certificats d’identité, vous devez cocher l’option « Ignore identity certificates during upgrade eligibility check ». Ils devront être réimportés après la migration.

Ces paramètres permettent notamment de définir la procédure à suivre selon différents cas de figure d’échecs (échec d’activation des intégrations, de programmations des intégrations etc).

Par ailleurs, les adresses IP de l’instance après migration seront également visibles deux semaines avant la date programmée, pour mettre à jour les listes d’autorisation.

Il est à noter que les données d’activités des instances d’intégrations sur Oracle Integration Cloud Gen2 ne sont pas migrées vers la Gen3. Pour les conserver après la migration, il est possible de capturer le flux d’activités des intégrations depuis la console OIC ou via les API de monitoring.

Nous recommandons comme nous l’avons effectué avec Club Med de créer un backup de votre instance sur un bucket pré-créé.

Indisponibilité

Il est également important de souligner qu’une période d’indisponibilité est à prévoir pendant la migration. Ainsi, tout appel à une intégration (asynchrone ou synchrone) pendant cet intervalle sera rejeté. Il faudra considérer la console éteinte. Le traitement de requêtes entrantes reprendra une fois la migration intégralement terminée. Pour les intégrations programmées, les intégrations prévues dans le futur reprendront leur lancement comme paramétrées au préalable sur Oracle Integration Cloud Gen2 avant la migration.

Communication

Après avoir reçu la confirmation de la migration, il est conseillé d’avertir toutes les personnes impactées (utilisateurs, développeurs etc.) et de leur communiquer a minima les informations suivantes :

• La date et plage horaire de la migration pendant laquelle l’instance sera indisponible. Prévoyez de la contingence pour pouvoir effectuer un lot de sanity checks sur les intégrations types que vous avez sur votre instance. La plage horaire est généralement de 2h, prévoyez au minimum une demi-journée.

• Limiter les développements 2 jours avant la date prévue : il est préférable de ne plus créer, modifier et activer d’intégrations avant la migration pour limiter les chances d’annulation de l’upgrade.

Étape 3 : Migration OIC Gen2 vers Gen3

La limitation d’apports de modifications est nécessaire pour assurer la conservation de toutes les conditions requises à la migration. En effet, de nouveaux développements peuvent être sources d’échecs de prérequis précédemment validés. Des erreurs sur les instances lancées peuvent empêcher la migration mais il est possible de spécifier la poursuite de la migration dans ce cas au moment de sa programmation.

Il est également demandé de s’assurer de la fin de toutes les instances en cours d’exécution et de se déconnecter de l’instance avant le début de la migration.

Une fois la migration terminée, Oracle envoie un mail aux administrateurs pour les en informer.

Étape 4 : Les actions post-upgrade

Après la migration, certaines vérifications et actions sont à effectuer pour valider le succès de celle-ci. Dans un premier temps, il est important de tester l’accès à la nouvelle instance OIC Gen3. L’URL de la Gen2 redirige vers la nouvelle URL de l’instance Gen3. Il est aussi conseillé de s’assurer que l’ensemble des intégrations devant être activées le sont bien.

Si une règle Oracle Cloud Infrastructure Identity and Access Management (IAM) était définie pour accéder à l’instance Gen2 sur la base d’un ID (Oracle Cloud ID (OCID)) qui identifie de manière unique une instance, il est nécessaire de mettre à jour cette information. Le nouvel OCID est disponible sur la console d’Oracle Cloud Infrastructure.

En cas d’utilisation de Visual Builder sur la Gen2, il est également attendu de créer une nouvelle règle IAM pour permettre au groupe administrateur d’OIC de gérer l’instance de Visual Builder.

Si vous disposez de connexions qui se basent sur des certificats d’identité, comme évoqué précédemment, ces derniers ne sont pas migrés et vous devez donc fournir de nouveaux certificats. Après avoir testé les connexions concernées, vous devez réactiver toutes les intégrations qui les utilisent.

Par ailleurs, les informations de connexion (adresse IP et port) au serveur SFTP d’OIC changent. Vous pouvez les récupérer dans la rubrique suivante : Settings > File Server > Settings.

Bien que les valeurs liées à l’instance de la Gen2 soient valides pendant 4 mois après la migration, il est recommandé de mettre à jour les clients SFTP et les connexions au SFTP OIC.

Après avoir passé avec succès toutes ces étapes, vous pourrez utiliser la nouvelle instance OIC Gen3 !

Points d’attention

La bascule vers OIC Gen3 engendre quelques changements qui sont à prendre en considération car ils sont susceptibles de provoquer des erreurs de fonctionnements.

Notre méthodologie par étapes a permis de mettre en lumière et corriger plus sereinement ces erreurs. En voici quelques-uns…

L’instance ID n’est plus un nombre

Sur OIC Gen3, l’instance ID n’est plus un nombre mais une chaîne de caractères. Ce point peut être source d’erreurs de conversion si les valeurs prises par cette meta-data sont stockées en base de données en tant que nombres (type NUMBER). Pour y remédier, il sera donc nécessaire de modifier le type des colonnes stockant cette valeur en VARCHAR.

Ce changement est également problématique pour les REST API développées qui renverraient en réponse l’instance ID en tant que nombre. En effet, une intégration dont le trigger REST est configurée avec un retour comme sur l’image de gauche provoquera une erreur car l’instance ID ne pourra pas être analysée correctement. Pour résoudre ce problème, il suffit de modifier l’échantillon de retour en englobant la valeur de l’instance ID par des guillemets comme le montre l’image de droite :

Changement de méthode d’authentification pour les appels aux APIs REST d’Oracle Integration

Sur Oracle Integration Cloud Gen3, il n’est plus possible d’utiliser une autre méthode d’authentification qu’OAuth2 pour appeler les REST APIs d’Oracle Integration. De ce fait, si vos intégrations contiennent des nœuds qui invoquent des REST APIs d’Oracle, une erreur sera renvoyée si la connexion utilisée pour réaliser cet appel est configurée avec la méthode Basic Authentication ou une autre méthode qu’OAuth.

Certains changements sont à effectuer. Tout d’abord, sur Oracle Identity Cloud Service, vous devez enregistrer une application de type « Trusted Application » à travers laquelle il sera possible d’appeler les REST APIs d’Oracle. Le type d’authentification à définir pour celle-ci est « Client Credentials ». Il faudra également lui attribuer un ou plusieurs rôles OIC (ServiceAdministrator, ServiceDeveloper etc.). Pour créer cette application et la configurer, vous devez disposer d’identifiants d’administrateur de domaine d’identité ou d’administrateur application.

Les connexions utilisées pour ces appels doivent ensuite être modifiées. Notamment la politique de sécurité doit être changée pour correspondre à OAuth (OAuth Client Credentials) et l’access token URI, le Client ID, le Client Secret et le scope doivent être renseignés. Ces informations proviennent de l’application créée. OIC s’occupe ensuite de manière autonome de gérer les demandes d’access token à chaque invocation d’une API REST Oracle.

Impossibilité de migrer une intégration modifiée sur la Gen3 en Gen2

Si une intégration est modifiée c’est-à-dire qu’un élément a été ajouté ou modifié, ou bien qu’une intégration est créée sur OIC Gen3, il n’est pas possible de l’importer sur une instance de la version précédente (OIC Gen2). Cette caractéristique est importante lorsque vous ne migrez pas l’environnement de production en même temps que les environnements de « non-production ».

De plus, généralement l’environnement de développement est migré avant celui de test et de ce fait, si vous disposez de développements en cours et que des livraisons sont réalisées régulièrement, cet aspect est à prendre en compte.

Il est cependant possible de migrer des intégrations créées ou modifiées sur l’instance OIC Gen2 vers OIC Gen3.

Aussi, pour contourner ce problème, il y aurait deux options :

• L’ajout d’une instance de développement, l’ancienne et principale sur la version OIC Gen3 et une nouvelle sur la version OIC Gen2. Cette dernière serait à décommissionner après utilisation. Attention, si vous choisissez cette option, il faudra revoir vos processus de livraison.

• Si vous disposez d’une deuxième instance de non-production utilisée pour les UAT par exemple, vous pourrez effectuer votre upgrade sur celle-ci, puis celle de production et enfin celle de développement.

En choisissant l’une ou l’autre des options, vous pourrez effectuer vos développements sur la version OIC Gen2 et livrer vos intégrations développées sur cette version dans vos environnements d’UAT (Gen3) puis de production (Gen3).

Bien que pouvant être présentée comme complexe, cette migration peut être réalisée avec succès grâce à une préparation rigoureuse et une bonne communication.

Notre expérience avec Club Med montre qu’avec une approche personnalisée et un support adéquat, les avantages de la version Gen3 d’OIC peuvent être pleinement exploités.