Vérifier la disponibilité de la mise à niveau et corriger les problèmes de vérification préalable

Voir votre statut de vérification préalable

Pour voir le statut de votre vérification préalable ou pour l'exécuter à nouveau, procédez comme suit :

Dans le volet de navigation, cliquez sur Paramètres, puis sur Mettre à niveau.

Vous pouvez voir quand la dernière vérification préalable s'est terminée au-dessus du tableau de vérification de l'état de préparation.

Le tableau de vérification de la disponibilité affiche les informations suivantes sur le statut des éléments de vérification préalable.

colonne	Description
Condition d'admissibilité	Condition qui doit être remplie pour être prête pour la mise à niveau. Certaines conditions incluent des liens vers la documentation associée.
Responsable	Qui est responsable de la gestion de la condition.
Date d'échéance	Date à laquelle la condition doit être satisfaite.
Statut d'admissibilité	Statut de la condition, y compris les explications pour les conditions qui n'ont pas été remplies. Développez Plus de détails... pour voir des informations supplémentaires sur l'échec de la condition. Pour copier les détails dans le presse-papiers, cliquez sur .

S'il y a des vérifications préalables qui n'ont pas réussi, effectuez les tâches associées pour corriger les problèmes.
Pour réexécuter la vérification préalable, cliquez sur Vérifier de nouveau.
La vérification préalable prend environ une heure.

Note

Si Oracle a tenté de mettre à niveau votre instance, vous voyez les détails de cette tentative dans le sommaire de la mise à niveau directement sous le tableau de vérification de la disponibilité.

Sommaire des vérifications préalables

Ce tableau résume les vérifications préalables et les tâches associées pour chaque zone. Les détails de chaque tâche sont liés dans le tableau et présentés dans la section suivante.

Secteur	Tâches
Agent de connectivité	Version Java de l'agent Connectivité d'agent pour Oracle Integration 3 - L'agent de connectivité doit être en cours d'exécution Connectivité d'agent pour Oracle Integration 3 - Mettre à jour vos paramètres de liste d'autorisation Identificateur AgentGroup non pris en charge
Instances	URL du point d'extrémité personnalisé Action d'ID instance Limite de courriel quotidienne Portées personnalisées dans IDCS Autres défaillances
B2B pour Oracle Integration	B2B Période de conservation
Intégrations	Réponse différée (asynchrone) Certificats d'identité Nom d'application en double d'acheminement de base Lecture de plusieurs fichiers Intégrations de publication/d'abonnement Action d'authentification de base de l'API DT vers OAuth
Adaptateurs	Adaptateurs personnalisés Adaptateur Oracle Utilities Adaptateurs non pris en charge Types REST non pris en charge
Visual Builder	URL du point d'extrémité personnalisé VBCS
Automatisation des processus	Automatisation des processus Vérifications préalables d'automatisation de processus

Vérifications préalables de l'agent de connectivité

Condition d'admissibilité	Responsable type	Applicable à la région du gouvernement	Tâches à terminer
Version Java de l'agent	Équipe des opérations de développement	Oui	Assurez-vous que vos agents de connectivité utilisent JDK 17 et PKCS12 KeyStore. Développez Plus de détails pour voir les agents de connectivité qui doivent être révisés. Pour copier les détails dans le presse-papiers, cliquez sur . Vous pouvez également voir la section Statut de l'agent de connectivité pour voir le statut de tous les agents de connectivité de votre instance. Pour tout agent de connectivité qui n'utilise pas déjà JDK 17, installez JDK 17 sur le serveur qui héberge l'agent. Pour tout agent qui utilise toujours JKS KeyStore, convertissez KeyStore en PKCS12 KeyStore. Vous pouvez effectuer la conversion de l'une des deux façons suivantes : Automatiquement, lors de la mise à niveau : Votre JKS KeyStore sera automatiquement converti en PKCS12 KeyStore lors de la mise à niveau. Manuellement, avant la mise à niveau : Vous pouvez convertir JKS KeyStore en PKCS12 KeyStore manuellement, avant la mise à niveau, en suivant les étapes ci-dessous. Note La conversion de JKS KeyStore en PKCS12 KeyStore n'a aucune incidence sur votre agent de connectivité Oracle Integration Génération 2 et n'entre en vigueur qu'après la mise à niveau vers Oracle Integration 3. Si vous voulez convertir manuellement votre JKS KeyStore en PKCS12 KeyStore, effectuez les étapes suivantes avant de procéder à la mise à niveau. Ces tâches vous obligent à arrêter brièvement, puis à redémarrer l'agent de connectivité. Choisissez donc une heure à laquelle l'agent de connectivité n'est pas utilisé. Sur le serveur qui héberge l'agent de connectivité, créez une sauvegarde du fichier `keystore.jks`, qui se trouve dans le dossier suivant : `Agent_Install_Location/agenthome/agent/cert` Déplacez le fichier de sauvegarde vers un autre dossier. Convertissez JKS KeyStore en PKCS12 KeyStore en exécutant la commande suivante à partir de la ligne de commande : `keytool -importkeystore -srckeystore keystore.jks -destkeystore keystore.p12 -srcstoretype JKS -deststoretype PKCS12 -deststorepass changeit -srcstorepass changeit` Arrêtez l'agent de connectivité. Supprimez le fichier `keystore.jks` à l'emplacement suivant : `Agent_Install_Location/agenthome/agent/cert` Démarrez l'agent de connectivité.
Connectivité d'agent pour Oracle Integration 3 - L'agent de connectivité doit être en cours d'exécution	Équipe des opérations de développement	Oui	Votre agent de connectivité doit être opérationnel avant le début de la mise à niveau. Développez Plus de détails pour voir les agents de connectivité qui doivent être révisés. Pour copier les détails dans le presse-papiers, cliquez sur . Vous pouvez également voir la colonne Statut de l'agent dans la section Statut de l'agent de connectivité pour voir le statut de tous les agents de connectivité de votre instance, en indiquant si chaque agent est hors ligne (non disponible). Les agents qui ne sont pas accessibles pendant la mise à niveau ou qui ne répondent pas aux exigences de mise à niveau ne seront pas mis à niveau, auquel cas vous devrez effectuer des étapes post-mise à niveau pour rétablir la connectivité.
Connectivité d'agent pour Oracle Integration 3 - Mettre à jour vos paramètres de liste d'autorisation	Équipe des opérations de développement	Oui	Vous devez mettre à jour vos paramètres de liste d'autorisation pour vos agents de connectivité avant la mise à niveau. Développez Plus de détails pour voir les agents de connectivité qui doivent être révisés. Pour copier les détails dans le presse-papiers, cliquez sur . Vous pouvez également voir la colonne Statut de la liste d'autorisation dans la section Statut de l'agent de connectivité pour voir le statut de tous les agents de connectivité de votre instance, en indiquant si la liste d'autorisation a été mise à jour de manière appropriée. À l'approche de votre fenêtre de mise à niveau, effectuez les tâches préalables à la mise à niveau suivantes : Ajoutez l'adresse IP d'Oracle Cloud Infrastructure Identity and Access Management (IAM) à la liste d'autorisation. Ajoutez les adresses IP de conception et d'exécution pour Oracle Integration à la liste d'autorisation. Définissez la propriété Cache du serveur mandataire pour que les URL Oracle Integration s'actualisent aussi fréquemment que possible. Les agents qui ne sont pas accessibles pendant la mise à niveau ou qui ne répondent pas aux exigences de mise à niveau ne seront pas mis à niveau, auquel cas vous devrez effectuer des étapes post-mise à niveau pour rétablir la connectivité.
Identificateur AgentGroup non pris en charge	Équipe des opérations de développement	Oui	Si l'un de vos groupes d'agents a un espace dans leurs identificateurs, ils ne seront pas migrés vers Oracle Integration 3. Si vous avez toujours besoin des groupes d'agents, vous devrez les recréer après la mise à niveau.

Vérifications préalables d'instance

Condition d'admissibilité	Responsable type	Applicable à la région du gouvernement	Tâches à terminer
URL du point d'extrémité personnalisé	Administrateur	Oui	Selon la façon dont votre point d'extrémité personnalisé est configuré avant la migration, vous effectuerez différentes étapes et le processus de mise à niveau traitera le point d'extrémité personnalisé différemment. Développez Plus de détails pour déterminer comment procéder à la mise à niveau. Si vous utilisez Visual Builder : Pour poursuivre la mise à niveau, effectuez les tâches préalables à la mise à niveau du générateur visuel. Lors de la mise à niveau, le processus de mise à niveau configure votre point d'extrémité personnalisé et tous les autres points d'extrémité personnalisés dans Visual Builder. Si vous n'utilisez pas Visual Builder et que vous avez d'autres points d'extrémité personnalisés, supprimez-les de votre instance Oracle Integration Génération 2. Oracle Integration 3 ne prend actuellement pas en charge d'autres points d'extrémité personnalisés. Si vous n'utilisez pas Visual Builder et que votre point d'extrémité personnalisé utilise SSL : Pour procéder à la mise à niveau, configurez un équilibreur de charge devant votre instance Oracle Integration Génération 2 et supprimez le certificat SSL. Lors de la mise à niveau, le processus de mise à niveau configure votre point d'extrémité personnalisé dans Oracle Integration 3. Après la mise à niveau, l'accès en temps d'exécution à vos intégrations continuera de fonctionner comme pour Oracle Integration Génération 2. Pour tous les autres points d'accès, tels que la conception et l'automatisation des processus, vous accédez toujours au point d'extrémité personnalisé, mais le point d'extrémité personnalisé est redirigé vers l'URL appropriée. Si aucune de ces situations ne s'applique et que cette vérification préalable a réussi, le processus de mise à niveau configure votre point d'extrémité personnalisé dans Oracle Integration 3, et le point d'extrémité personnalisé fonctionnera comme décrit dans le point précédent pour le scénario SSL.
Action d'ID instance	Administrateur	Oui	L'ID instance d'intégration générée par le système qui est affiché dans la page Instances et dans le flux de données d'activités d'une instance d'intégration est passé d'une valeur numérique à une valeur alphanumérique dans Oracle Integration 3. Le type de données de la valeur est inchangé; il reste un type de données de chaîne. La modification d'une valeur alphanumérique peut avoir une incidence sur tous les systèmes que vous utilisez et dont l'instance d'intégration est une valeur numérique. Par exemple, si vous analysez l'ID instance d'intégration à partir d'une API REST et stockez l'ID instance d'intégration dans une base de données en tant que champ numérique, vous devrez mettre à jour le champ de base de données. Si vous avez des intégrations qui utilisent des instances d'intégration, la vérification préalable affiche un avertissement. Développez Plus de détails pour voir les intégrations qui doivent être révisées. Pour copier les détails dans le presse-papiers, cliquez sur . Si vous avez besoin de temps supplémentaire pour effectuer les mises à jour requises pour cette modification, vous pouvez conserver temporairement l'ID instance d'intégration sous forme numérique (six mois après la mise à niveau). Voir FlowId Prise en charge de la conversion. Assurez-vous de noter les intégrations qui sont touchées par la copie des détails comme décrit ci-dessus. Note : Cette vérification préalable vérifie simplement l'existence d'intégrations qui utilisent des ID instance, et non l'exactitude des ID instance. L'avertissement restera affiché après la mise à jour des intégrations, mais n'aura aucune incidence sur la mise à niveau.
Limite de courriel quotidienne	Administrateur	Oui	Oracle Integration 3 peut envoyer une limite de 10 000 courriels dans une fenêtre continue de 24 heures, comme décrit dans Limites de service. Si votre déploiement doit envoyer plus que cela, vous pouvez utiliser votre location de client. Voir Configurer les courriels d'avis.
Portées personnalisées dans IDCS	Administrateur	Non	Oracle Integration 3 ajoute une étendue par défaut (`/ic/api/ , urn:opc:resource:consumer::all`) à Oracle Identity Cloud Service (IDCS) lors de la création de l'instance. Il ne prend en charge aucune autre étendue personnalisée ajoutée à IDCS. Si vous avez créé des étendues personnalisées dans IDCS, vous devez les supprimer.
Autres défaillances	Varies	Oui	S'il y a d'autres problèmes qui bloqueront la mise à niveau qui n'ont pas de vérifications préalables spécifiques, ils seront inclus dans d'autres échecs. Développez Plus de détails pour voir les problèmes qui nécessitent une action. Pour copier les détails dans le presse-papiers, cliquez sur .

B2B pour les vérifications préalables d'Oracle Integration

Condition d'admissibilité	Responsable type	Applicable à la région du gouvernement	Tâches à terminer
B2B Période de conservation	Administrateur	Non	Bien que vous n'ayez rien à faire pour corriger ce statut de vérification préalable, sachez que les éditions Standard et Enterprise d'Oracle Integration 3 prennent en charge 32 jours de conservation des données par défaut. Pendant la mise à niveau, seules les données conservées des 32 derniers jours seront migrées. Développez Plus de détails pour voir le nombre de jours de données conservées dont vous disposez actuellement. Pour copier les détails dans le presse-papiers, cliquez sur . Après la mise à niveau vers Oracle Integration 3, vous aurez la possibilité d'augmenter la période de conservation des données si vous le souhaitez; ou de mettre à niveau vers l'édition Healthcare, qui prend en charge 184 jours de conservation des données.

Vérifications préalables des intégrations

Condition d'admissibilité	Responsable type	Applicable à la région du gouvernement	Tâches à terminer
Réponse différée (asynchrone)	Équipe de développement	Oui	Le modèle de réponse différée (asynchrone) était précédemment pris en charge dans les adaptateurs suivants : Oracle CX Sales et adaptateur de service B2B Adaptateur Oracle ERP Cloud Adaptateur Oracle HCM Cloud Adaptateur Oracle Fusion Field Service adaptateur Salesforce Adaptateur ServiceNow Si vous avez des intégrations utilisant une réponse retardée (asynchrone) avec l'un de ces adaptateurs, réusinez-les en créant deux connexions d'appel pour obtenir des fonctionnalités similaires : Créez un appel simple pour les rappels réussis. Créez un appel supplémentaire pour les rappels en échec dans le programme de traitement des erreurs afin de détecter l'erreur correcte. Développez Plus de détails pour voir quelles intégrations doivent être révisées. Pour copier les détails dans le presse-papiers, cliquez sur .
Certificats d'identité	Équipe de développement	Oui	Les certificats d'identité établissent l'identité du client lors de la communication SSL bidirectionnelle. Les connexions basées sur l'adaptateur AS2 et l'adaptateur REST peuvent utiliser des certificats d'identité. Développez Plus de détails pour voir les noms des certificats d'identité et les connexions qui les utilisent. Pour copier les détails dans le presse-papiers, cliquez sur . Si vous avez des certificats d'identité, après la mise à niveau, vous devrez charger de nouveaux certificats d'identité, comme décrit dans Garantir la connectivité :
Nom d'application en double d'acheminement de base	Équipe de développement	Oui	Si votre instance contient des intégrations de routage de base qui ont les mêmes noms de point d'extrémité source et cible, procédez comme suit : Modifiez votre intégration de routage de base, supprimez le point d'extrémité cible et ajoutez-le de nouveau sous un autre nom. Enregistrez votre intégration. Développez Plus de détails pour voir les intégrations qui doivent être révisées. Pour copier les détails dans le presse-papiers, cliquez sur .
Lecture de plusieurs fichiers	Équipe de développement	Oui	L'opération de lecture de plusieurs fichiers était obsolète dans Oracle Integration Génération 2. Si vous avez des intégrations qui incluent une opération de lecture de plusieurs fichiers, retravaillez les intégrations afin qu'elles n'utilisent pas ce modèle. Par exemple, utilisez une opération listFile pour lister les fichiers et utilisez une action for-each pour lire chaque fichier individuellement. Développez Plus de détails pour voir les intégrations qui doivent être révisées. Pour copier les détails dans le presse-papiers, cliquez sur .
Intégrations de publication/d'abonnement	Équipe de développement	Oui	Si votre instance comprend des intégrations qui publient des messages ou s'abonnent à des messages d'Oracle Integration, sachez que les intégrations de publication/abonnement (ou pub/abonnement) doivent être converties en orchestrations axées sur les événements. Les intégrations seront traitées différemment selon leur configuration : Les intégrations de publication/abonnement qui utilisent des fichiers joints ne peuvent pas être converties automatiquement pour le moment. Si vous voulez poursuivre la mise à niveau, vous pouvez supprimer ces intégrations ou ignorer les échecs de vérification préalable. Après la mise à niveau, vous pouvez les recréer, en poussant l'attachement dans le serveur FTP ou le stockage d'objets de votre location et en transmettant la référence au flux d'abonnés. Voir Définir le filtrage d'abonnement basé sur un en-tête dans Utilisation d'intégrations dans Oracle Integration 3. Toutes les autres intégrations de publication/sous-intégrations actives sont converties automatiquement lors de la mise à niveau. Les intégrations de publication/abonnement à l'état provisoire ne peuvent pas être migrées et seront vides après la mise à niveau. Si vous avez mappé des données dans le flux d'abonnés, les mappages sont convertis le plus précisément possible. Toutefois, après la mise à niveau, vous devez vérifier les mappages et les corriger si nécessaire. Si vous voyez l'erreur Seuls les abonnés sont présents, aucun éditeur, vous avez des abonnés orphelins qui doivent être supprimés avant la mise à niveau. Développez Plus de détails pour voir les intégrations qui ne peuvent pas être converties automatiquement. Pour copier les détails dans le presse-papiers, cliquez sur . Note : Vous pouvez profiter de cette occasion pour supprimer tout flux de publication provisoire.
Action d'authentification de base de l'API DT vers OAuth	Équipe de développement	Oui	Si votre instance inclut des intégrations qui accèdent aux API de développeur à l'aide d'une connexion REST avec l'authentification de base, vous devez les modifier pour utiliser OAuth. Dans Oracle Integration Génération 2, vous pouvez utiliser l'authentification de base pour utiliser l'API REST d'Oracle Integration et l'API REST de serveur de fichiers. Dans Oracle Integration 3, vous devez utiliser OAuth. Vous devez mettre à jour les clients, scripts, intégrations et commandes qui utilisent l'API de développement pour Oracle Integration 3 ou l'API de développement pour serveur de fichiers pour se connecter à l'aide de OAuth. Pour plus d'informations sur la prise en charge des méthodes d'authentification, voir Quand l'authentification de base est-elle prise en charge dans Oracle Integration 3 dans Provisionnement et administration d'Oracle Integration 3. Pour plus de détails sur l'utilisation de OAuth, voir Sécurité, authentification et autorisation dans API de développement pour Oracle Integration 3 ou Sécurité, authentification et autorisation dans API de développement pour le serveur de fichiers dans Oracle Integration 3.

Vérifications préalables des adaptateurs

Condition d'admissibilité	Responsable type	Applicable à la région du gouvernement	Tâches à terminer
Adaptateurs personnalisés	Équipe de développement	Non	Si votre instance comprend des intégrations qui utilisent un adaptateur personnalisé, il n'est pas encore possible de mettre à niveau l'instance. Attendez qu'Oracle lance les mises à niveau pour cette fonction. Développez Plus de détails pour voir les adaptateurs personnalisés que vous utilisez. Pour copier les détails dans le presse-papiers, cliquez sur .
Adaptateur Oracle Utilities	Équipe de développement	Oui	Swagger 2.0 n'est plus pris en charge par l'adaptateur Oracle Utilities. S'il existe une intégration à l'aide du catalogue REST Swagger 2.0, l'exécution n'est pas touchée. Toutefois, si vous tentez de modifier la connexion lors de la conception, de la tester à nouveau, d'actualiser les métadonnées, d'actualiser les artefacts ou de la réactiver, l'intégration échoue. Vous devez mettre à jour le catalogue pour utiliser la définition OpenAPI 3.x. Développez Plus de détails pour voir les intégrations qui doivent être révisées. Pour copier les détails dans le presse-papiers, cliquez sur . See Using Swagger 2.0 REST catalog with Oracle Utilities Adapter version 24.04.0 or higher.
Adaptateurs non pris en charge	Équipe de développement	Oui	Si votre instance comprend une intégration qui utilise l'un des adaptateurs suivants, qui ne sont pas pris en charge dans Oracle Integration 3, remplacez les adaptateurs par l'adaptateur REST : Adaptateur Automation Anywhere Adaptateur Evernote Adaptateur Oracle Messaging Cloud Service Adaptateur Oracle Monetization Cloud Adaptateur Oracle Taleo Business Edition (TBE) Adaptateur d'automatisation des processus par la robotique UiPath Note : Les capacités d'automatisation robotisée des processus (RPA) sont disponibles dans Oracle Integration 3. Voir En savoir plus sur les robots et Créer un robot dans Utilisation de robots dans Oracle Integration 3. Développez Plus de détails pour voir les adaptateurs non pris en charge que vous utilisez. Pour copier les détails dans le presse-papiers, cliquez sur .
Types REST non pris en charge	Équipe de développement	Oui	Les types de connexion suivants sont obsolètes et ne sont pas pris en charge dans une connexion d'adaptateur REST. Remplacez ces types de connexion par des types de connexion différents. Voir Configurer les propriétés de connexion pour appeler des connexions dans Utilisation de l'adaptateur REST avec Oracle Integration pour 3. URL de catalogue de métadonnées URL de définition de la spécification Swagger URL de définition RAML Développez Plus de détails pour voir les types REST non pris en charge que vous utilisez. Pour copier les détails dans le presse-papiers, cliquez sur . Les développeurs dotés d'une API REST qui est décrite à l'aide de RAML ou du catalogue de métadonnées Oracle doivent effectuer l'action suivante : Consultez votre fournisseur de services REST et demandez une définition de Swagger (si disponible). Oracle Fusion Applications doit avoir une option Swagger disponible. Il s'agit d'une directive pour toutes les applications Oracle Fusion Applications. Si aucune autre spécification n'est disponible, utilisez le modèle de base de l'adaptateur REST en sélectionnant URL de base d'API REST comme URL de connexion et en définissant la demande d'API cible à l'aide de l'assistant de configuration de point d'extrémité d'adaptateur. Une autre option consiste à convertir la RAML en spécification OpenAPI à utiliser avec la connexion de l'adaptateur REST. Pour assurer une prise en charge plus robuste et complète des spécifications Swagger/OpenAPI, l'adaptateur REST comprend une option unifiée permettant de spécifier toutes les spécifications OpenAPI dans un seul champ. Cette option remplace également l'option permettant de fournir une URL de définition Swagger, qui n'est plus disponible.

Vérifications préalables pour Visual Builder

Condition d'admissibilité	Responsable type	Applicable à la région du gouvernement	Tâches à terminer
URL du point d'extrémité personnalisé	Administrateur	Non	Cette opération a également été traitée dans les vérifications préalables d'instance, mais elle est répétée ici car elle s'applique à Visual Builder. Si vous disposez d'un point d'extrémité personnalisé et que vous utilisez Visual Builder : Pour poursuivre la mise à niveau, effectuez les tâches préalables à la mise à niveau du générateur visuel. Lors de la mise à niveau, le processus de mise à niveau configure votre point d'extrémité personnalisé et tous les autres points d'extrémité personnalisés dans Visual Builder.
VBCS	Administrateur	Non	Si vous utilisez Visual Builder avec votre propre instance de base de données Oracle (BYODB), Autonomous Transaction Processing (ATP) doit être en cours d'exécution pendant la mise à niveau. Pour une mise à niveau en douceur, effectuez les tâches décrites dans Préparer Visual Builder pour la mise à niveau dans Administration d'Oracle Visual Builder dans Oracle Integration 3. Le fait de ne pas effectuer les tâches spécifiées avant la mise à niveau peut entraîner une interruption immédiate et des problèmes de connectivité après la mise à niveau. Pour résoudre ces problèmes après la mise à niveau, vous devrez peut-être effectuer des tâches supplémentaires et soumettre une demande de service sur My Oracle Support.

Condition d'admissibilité

Responsable type

Applicable à la région du gouvernement

Tâches à terminer

URL du point d'extrémité personnalisé

Administrateur

Non

Cette opération a également été traitée dans les vérifications préalables d'instance, mais elle est répétée ici car elle s'applique à Visual Builder.

Si vous disposez d'un point d'extrémité personnalisé et que vous utilisez Visual Builder :

Pour poursuivre la mise à niveau, effectuez les tâches préalables à la mise à niveau du générateur visuel.
Lors de la mise à niveau, le processus de mise à niveau configure votre point d'extrémité personnalisé et tous les autres points d'extrémité personnalisés dans Visual Builder.

VBCS

Administrateur

Non

Si vous utilisez Visual Builder avec votre propre instance de base de données Oracle (BYODB), Autonomous Transaction Processing (ATP) doit être en cours d'exécution pendant la mise à niveau.

Pour une mise à niveau en douceur, effectuez les tâches décrites dans Préparer Visual Builder pour la mise à niveau dans Administration d'Oracle Visual Builder dans Oracle Integration 3.

Le fait de ne pas effectuer les tâches spécifiées avant la mise à niveau peut entraîner une interruption immédiate et des problèmes de connectivité après la mise à niveau. Pour résoudre ces problèmes après la mise à niveau, vous devrez peut-être effectuer des tâches supplémentaires et soumettre une demande de service sur My Oracle Support.

Vérifications préalables pour l'automatisation des processus

Condition d'admissibilité	Responsable type	Applicable à la région du gouvernement	Tâches à terminer
Automatisation des processus	Administrateur	Non	Différences fonctionnelles Il existe plusieurs différences entre les processus dans Oracle Integration Génération 2 et Automatisation des processus dans Oracle Integration 3. Voir FAQ sur les processus. Selon la façon dont vous utilisez Process dans Oracle Integration Génération 2, vous utiliserez une autre option pour la mise à niveau ou la migration. Voir Options de mise à niveau du processus.
Automatisation des processus/applications de traitement	Administrateur	Non	Transactions d'exécution Si vous avez des instances de processus qui sont activement utilisées dans Oracle Integration Génération 2, vous verrez cette vérification préalable d'avertissement. Lors de la mise à niveau progressive, vos intégrations et les applications Visual Builder seront mises à niveau vers Oracle Integration 3. Toutefois, le processus continuera de fonctionner sur Oracle Integration Génération 2 après la mise à niveau. Pour plus de détails sur la mise à niveau progressive pour le processus, voir Mise à niveau progressive pour le processus. Note : Vous ne pouvez pas désactiver la mise à niveau progressive pour le processus. Vous ne verrez cette vérification préalable d'avertissement que si vous avez des instances de processus qui ne sont pas activement utilisées. Votre instance sera mise à niveau sans l'automatisation des processus. Les transactions d'exécution (terminées ou en cours) seront perdues. Avant la mise à niveau, exportez les applications de processus de conception que vous souhaitez conserver à partir d'Oracle Integration Génération 2. Si vous ne voulez pas les conserver, vous n'avez rien à faire. Développez Plus de détails pour voir des informations supplémentaires. Pour conserver la vérification, voir cette section qui décrit comment enregistrer les données d'exécution à partir du processus Oracle Integration Génération 2. Note Les données de conception sont conservées pendant une période de six mois après la mise à niveau. Lors de la mise à niveau, le processus ne sera pas activé sur Oracle Integration 3 et les applications de processus ne seront pas migrées. Après la mise à niveau, vous n'avez rien à faire. Toutefois, si vous souhaitez utiliser Process, vous pouvez l'activer et réimporter vos applications de conception. Si vous n'avez pas exporté vos applications de processus de conception avant la mise à niveau et si vous en avez besoin après la mise à niveau, soumettez une demande de service sur My Oracle Support. Pour plus d'informations sur l'activation du processus, voir Activer l'automatisation des processus avec Oracle Integration 3.
Oracle Content Management	Administrateur	Non	Oracle Content Management Si le processus est intégré à Oracle Content Management (OCM), vous devez mettre à jour les paramètres d'intégration d'OCM pour utiliser le nouveau nom d'hôte. Sinon, vous rencontrerez des problèmes. Développez Plus de détails... pour obtenir le nouveau nom d'hôte.
Visual Builder	Administrateur	Non	Visual Builder Si vous avez des applications Visual Builder appelant Process, effectuez les étapes de pré-mise à niveau de la mise à niveau progressive pour mettre à jour les applications Visual Builder.
Processus	Administrateur	Non	Si vous avez des processus appelant une intégration à un déclencheur REST qui est configuré uniquement avec la politique de sécurité OAuth ou Authentification de base, vous devrez la mettre à jour pour utiliser OAuth et Authentification de base afin d'éviter les échecs après la mise à niveau progressive.
Processus	Administrateur	Nombre	Les appels de processus dynamique utilisant l'activité d'intégration ne fonctionneront pas après la mise à niveau progressive. Vous devrez donc mettre à jour vos processus dynamiques pour utiliser une connexion d'activité de service pour appeler vos intégrations. Si vous ne le faites pas avant la mise à niveau progressive, vous pourriez subir une interruption de service après la mise à niveau.
Processus	Administrateur	Nombre	Si des intégrations appellent des processus Oracle Integration Génération 2 à l'aide d'une connexion SOAP (URL WSDL) ou d'une connexion REST, vous devez les mettre à jour pour utiliser la politique de sécurité Authentification de base afin d'éviter les échecs post-mise à niveau après la mise à niveau progressive.

Corriger une instance dont la vérification de la disponibilité a échoué

Si votre mise à niveau a été programmée et que votre instance n'est plus prête pour celle-ci, corrigez les conclusions afin que celle-ci se termine avec succès.

Dans Oracle Integration, ouvrez la page Mettre à niveau en effectuant l'une des étapes suivantes :
- Dans le volet de navigation, cliquez sur Paramètres, puis sur Mettre à niveau.
- Cliquez sur Annonces , puis sur le lien dans l'avis.
La page Mettre à niveau s'affiche.
Vérifiez les conditions qui ont échoué et prenez les mesures nécessaires. Voir Vérifier la disponibilité de la mise à niveau et corriger les problèmes de vérification préalable pour connaître les étapes à suivre.
Après avoir résolu tous les problèmes, vérifiez de nouveau l'instance.
1. Cliquez sur Vérifier à nouveau.
  La vérification prend environ une heure. Vous pouvez voir quand la dernière vérification s'est terminée au-dessus du tableau de vérification de l'état de préparation.
2. Continuez d'apporter des corrections jusqu'à ce que la vérification réussisse.
  Si vous ne savez pas comment corriger un problème, entrez une demande de service sur My Oracle Support.

Documentation sur Oracle Cloud Infrastructure