Etape Appliquer

L'étape Appliquer est celle où les enregistrements sont ajoutés ou mis à jour dans l'environnement cible. À l'instar de l'étape de comparaison, l'étape Appliquer est en fait constituée de plusieurs étapes visant à gérer de manière aussi fluide et optimale que possible les forts volumes et les dépendances entre les enregistrements.

Remarque :
Pour plus d'informations sur la rationalisation des différentes étapes dans le processus, voir Exécuter des traitements batch.

Avant d'expliquer les étapes d'application en détail, les points suivants mettent en évidence les types de données qui peuvent être incluses dans un jeu de données.

  1. Les enregistrements qui n'ont pas de clé étrangère, et donc aucune dépendance sur d'autres enregistrements. Exemples : Message, Profil d'affichage.

  2. Les enregistrements qui ont des clés étrangères qui peuvent déjà se trouver dans la cible. Exemples : Algorithmes dont le type est existant, rôles de tâche pour des types de tâche existants.

  3. Les enregistrements qui ont des clés étrangères qui sont de nouveaux enregistrements, mais qui font également partie de la migration. L'assistant de configuration de contenu (CMA) a détecté la relation lors de l'exportation et a regroupé les objets dans une même transaction. Exemple : Type d'algorithme basé sur un script pour lequel le script est également dans la migration.

  4. Les enregistrements qui ont des clés étrangères qui sont de nouveaux enregistrements, mais qui font également partie de la migration. L'assistant de configuration de contenu (CMA) n'a pas détecté la relation. Ceci peut se produire si la clé étrangère référencée est comprise dans une colonne XML ou une colonne de paramètre et que le plan de migration ne contenait pas d'instruction définissant explicitement la relation. Exemple : Une zone qui référence un script de visibilité.

  5. Les enregistrements qui contiennent des références circulaires où les deux enregistrements sont nouveaux et font partie de la migration. L'assistant de configuration de contenu (CMA) a détecté la relation lors de l'exportation et a regroupé les objets dans une même transaction. Exemple : Script plug-in pour un emplacement de plug-in d'objet métier. Le script référence l'objet métier et l'objet métier référence un algorithme du type d'algorithme du script. Autre exemple : le même enregistrement est tenu à jour par plusieurs objets de maintenance et existe donc dans plusieurs objets de migration.

Pour gérer les données en haut volume, la première étape du processus d'application consiste à exécuter la logique d'application au niveau de l'objet de migration par l'intermédiaire d'un traitement batch multithread. Suite à cela, tous les enregistrements des catégories 1 et 2 ci-dessus doivent être appliqués avec succès.

En ce qui concerne les enregistrements des catégories 3 et 4 ci-dessus, si un enregistrement comportant une clé étrangère est ajouté ou mis à jour avant son enregistrement associé, la validation échoue. Toutefois, si l'enregistrement associé est ajouté en premier, suivi de l'enregistrement y faisant référence, la validation réussit. L'outil gère ces dépendances comme suit :

  • La dépendance entre les entités principales et de transaction est généralement hiérarchique et, dans la plupart des cas, simple. L'outil exploite ces connaissances pour orchestrer le traitement des objets de manière optimale en suivant leur ordre de dépendance autant que possible. Notez que la relation entre les entités peut être complexe et que cette approche n'élimine pas toutes les erreurs liées à l'ordre de traitement, mais les réduit considérablement.

  • La dépendance entre les entités de configuration étant plus complexe et étroitement liée, les objets de migration ne sont pas triés. Autrement dit, le processus en mode batch multithread peut ne pas traiter les enregistrements dans l'ordre souhaité.

  • Pour surmonter le problème potentiel des erreurs liées à l'ordre de traitement, l'étape Appliquer comporte une fonctionnalité spéciale, décrite en détail ci-dessous.

Pour les enregistrements de la catégorie 5 ci-dessus, la référence circulaire empêche le processus d'application au niveau de l'objet d'ajouter ou de mettre à jour ces enregistrements. Toutefois, le processus d'application au niveau de la transaction couvre ces enregistrements. Cette procédure est décrite en détail ci-dessous.

Appliquer les objets

Une fois que le jeu de données est à l'état Appliquer les objets, le processus Moniteur d'objet de migration - Appliquer (F1-MGOAP) s'exécute pour tenter d'appliquer les objets.

Remarque :

Lorsque vous utilisez des processus en mode batch distincts pour les données métier, le processus Moniteur d'objet de migration (données métier) - Appliquer (F1-MGOAB) fonctionne de la même manière pour appliquer des objets métier de migration.

En conjonction avec l'algorithme Appliquer, le processus en arrière-plan offre une fonctionnalité spéciale assurant le succès de l'application des enregistrements des catégories 3 et 4 (ci-dessus) au cours de cette étape :

  • Le fonctionnement spécial du processus Moniteur d'objet de migration - Appliquer re-sélectionne continuellement des enregistrements à l'état Approuvé, jusqu'à ce qu'il ne reste plus d'enregistrements admissibles à traiter.

  • Lorsqu'une erreur est reçue dans l'algorithme Appliquer les objets, celui-ci incrémente un "nombre d'itérations" sur l'enregistrement de l'objet de migration. Si le nombre d'itérations ne dépasse pas une limite maximum (notée dans l'algorithme), l'objet demeure à l'état Approuvé et est admissible pour être de nouveau sélectionné en vue de son traitement. Si le nombre d'itérations dépasse le maximum défini dans l'algorithme, l'enregistrement passe alors à l'état Erreur d'application.

Remarque :
Lorsque vous soumettez ce traitement batch Appliquer, veillez à affecter au nombre de threads une valeur qui ne dépasse pas le nombre de threads pris en charge par le processus de pool de threads. Sinon, les threads en excédent attendront que le nombre de threads pris en charge ait été finalisé.

Le diagramme suivant représente la partie du cycle de vie de l'objet de migration concernant l'état Appliquer.

Cycle de vie d'application d'un objet de migration

Après la finalisation du processus de surveillance Appliquer, les objets sont généralement à l'état Appliqué ou à l'état Erreur d'application. Les enregistrements à l'état Erreur d'application le sont pour l'une des deux raisons suivantes.

  • Ils font partie de la catégorie 5 décrite ci-dessus, pour laquelle les enregistrements présentent une référence circulaire avec un autre enregistrement. Pour ce scénario, l'étape Appliquer les transactions décrite ci-dessous devrait être en mesure d'appliquer les enregistrements.

  • Il existe une autre erreur, qui n'est pas relative aux enregistrements de la migration en cours. Dans ce cas, une intervention manuelle peut être requise. Pour plus d'informations, voir la section Résoudre les erreurs ci-dessous.

Comme illustré dans le diagramme, l'algorithme Appliquer les objets peut également détecter une raison pour laquelle l'objet ne peut pas être appliqué. Ceci peut être le cas lorsque l'objet de l'environnement cible a été mis à jour depuis l'étape de comparaison, le code SQL capturé à ce moment n'étant alors plus applicable. Si cela se produit, le fichier d'origine peut de nouveau être importé suite à l'application complète de la migration en cours, et de nouvelles comparaisons peuvent être générées et appliquées.

Appliquer les transactions

Dans l'idéal, après l'étape Appliquer les objets, tous les objets ont pour état Appliqué ou Erreur d'application du fait de la situation de "référence circulaire". La plupart du temps, l'étape suivante consiste alors à passer la responsabilité aux transactions. Les transactions de migration peuvent alors tenter d'appliquer leurs objets en masse.

Pour assurer que plusieurs processus en arrière-plan ne tentent pas de sélectionner des objets de migration pour exécuter l'étape Appliquer, les transactions ne sont admissibles pour l'étape d'application des objets que si le jeu de données est à l'état Appliquer les transactions.

Cycle de vie d'application d'un jeu de données de migration

Un algorithme de surveillance (exécuté par le processus en mode batch de surveillance de jeu de données) de l'état Appliquer les objets vérifie que plus aucun objet de migration n'est encore à l'état Approuvé ou que le nombre d'enregistrements à l'état Erreur d'application ne dépasse pas la limite configurée. Si c'est le cas, il fait passer automatiquement l'enregistrement à l'état Appliquer les transactions.

Si le nombre d'objets à l'état Erreur d'application dépasse la limite configurée, l'algorithme de surveillance ne fait pas passer automatiquement l'enregistrement à l'état suivant. Dans ce cas, l'utilisateur doit décider si les erreurs en grand nombre peuvent être résolues ou faire passer manuellement à l'état Appliquer les transactions (malgré le grand nombre d'erreurs). La section Résoudre les erreurs ci-dessous décrit les autres procédures que l'utilisateur peut suivre en cas d'erreur.

Une fois que le jeu de données est à l'état Appliquer les transactions, le processus Moniteur de transaction de migration - Appliquer (F1-MGTAP) s'exécute. Il tente d'appliquer les objets de la transaction. Si aucun objet de migration n'est en erreur, la transaction de migration passe simplement à l'état Appliqué. Si l'un des objets de migration est à l'état Erreur d'application, le processus en arrière-plan et l'algorithme Appliquer disposent d'une fonctionnalité spéciale leur permettant de tenter de surmonter les dépendances des objets ayant migré :

  • L'algorithme Appliquer sélectionne tous les objets de migration en erreur et exécute tout leur code SQL, puis valide tous les enregistrements. Si des objets de la transaction contiennent des références circulaires, ils doivent réussir la validation à cette étape.

  • Comme il peut rester des dépendances entre les transactions, une procédure de gestion des erreurs similaire à celle décrite à l'étape Appliquer les objets ci-dessus est suivie ici. Lorsqu'une erreur est reçue dans l'algorithme pour n'importe lequel des objets de la transaction, celui-ci incrémente un nombre d'itérations dans l'enregistrement de l'objet de migration. Si le nombre d'itérations ne dépasse pas une limite maximum (notée dans l'algorithme), la transaction demeure à l'état Prêt pour application et est admissible pour être de nouveau sélectionné en vue de son traitement. Si le nombre d'itérations dépasse la valeur maximum, l'enregistrement passe alors à l'état Erreur d'application. Notez que si l'un des objets de la transaction est en erreur, aucun des objets n'est alors appliqué. Ils restent tous en erreur.

  • Le fonctionnement spécial du processus Moniteur de transaction de migration - Appliquer re-sélectionne continuellement des enregistrements à l'état Prêt pour application, jusqu'à ce qu'il ne reste plus d'enregistrements admissibles à traiter.

Remarque :
Lorsque vous soumettez ce traitement batch Appliquer, veillez à affecter au nombre de threads une valeur qui ne dépasse pas le nombre de threads pris en charge par le processus de pool de threads. Sinon, les threads en excédent attendront que le nombre de threads pris en charge ait été finalisé, ce qui élimine les avantages du traitement par itération.

Le diagramme suivant représente la partie du cycle de vie de la transaction de migration concernant l'état Appliquer. Il illustre les points abordés ci-dessus.

Cycle de vie d'application d'une transaction de migration

Si, à la fin du processus Appliquer au niveau de la transaction, il reste des transactions en erreur (et donc toujours des objets en erreur), un utilisateur doit vérifier les erreurs et déterminer comment les corriger. Pour plus d'informations, voir la section Résoudre les erreurs ci-dessous.

Résoudre les erreurs

Comme indiqué dans les sections précédentes, des erreurs peuvent être reçues après l'exécution du processus Appliquer les objets. Si le nombre d'enregistrements en erreur est inférieur à une certaine limite (et que le traitement batch de surveillance de jeu de données est soumis pour exécuter les algorithmes de surveillance), le système fait passer automatiquement le jeu de données à l'état Appliquer les transactions. Si le traitement batch de surveillance n'est pas exécuté ou que le nombre d'objets en erreur dépasse une certaine limite, un utilisateur doit prendre une décision après avoir examiné les erreurs dans la zone Objets en erreur du portail Importation de jeu de données de migration.

  • Si des erreurs semblent liées aux dépendances, l'utilisateur peut décider de laisser les transactions appliquer leurs objets et faire passer le jeu de données à l'étape Appliquer les transactions, décrit ci-dessus.

  • Si les erreurs semblent liées à un problème externe pouvant être résolu manuellement, l'utilisateur peut opter pour corriger le problème et exécuter à nouveau l'étape Appliquer les objets.

  • L'utilisateur peut également décider de rejeter un ou plusieurs objets, afin de les retirer de la migration.

Si des erreurs sont toujours présentes après l'étape Appliquer les transactions, un utilisateur doit vérifier les enregistrements et déterminer comment continuer. Les erreurs sont visibles dans la zone Transactions en erreur du portail Importation de jeu de données de migration.

  • L'utilisateur peut décider de rejeter un ou plusieurs objets, afin de les retirer de la migration.

  • L'utilisateur peut résoudre manuellement un problème externe à la migration, puis décider d'effectuer l'une des opérations suivantes :

    • Exécuter à nouveau l'étape Appliquer les objets. Cette action est recommandée si un grand nombre d'objets demeurent en erreur et qu'un nombre peu élevé de dépendances est attendu. Les avantages d'une exécution multithread de l'étape Appliquer les objets assurent l'efficacité d'exécution du processus.

    • Exécuter à nouveau l'étape Appliquer les transactions.

Comme les objets et les transactions sont à l'état Erreur d'application, pour tenter à nouveau l'étape Appliquer après la correction manuelle d'une erreur, le système doit repasser les enregistrements à l'état qui leur permet d'être sélectionnés par le processus Appliquer approprié. Pour les objets de migration, les enregistrements doivent repasser à l'état Approuvé. Pour les objets de migration, les enregistrements doivent repasser à l'état Prêt pour approbation. Les points suivants décrivent la logique de nouvelles tentatives pour les objets de migration.

  • Si un utilisateur décide de réessayer les objets (à l'aide d'un bouton d'action dans la page Importation de jeu de données de migration), le jeu de données passe à l'état Réessayer les objets. A ce stade, le moniteur d'objet de migration doit être exécuté.

  • Le moniteur de l'état Erreur d'application des objets détecte que le jeu de données est à l'état Réessayer les objets, ce qui déclenche le retour à l'état Approuvé.

  • L'étape suivante consiste à faire passer le jeu de données de Réessayer les objets à Appliquer les objets. Ce passage peut être effectué manuellement ou par exécution du processus de surveillance Importation de jeu de données de migration.

  • Les objets sont maintenant admissibles pour sélection par le processus d'application au niveau des objets.

Il existe une logique analogue pour les transactions de migration.

  • Si un utilisateur décide de réessayer les transactions (à l'aide d'un bouton d'action dans la page Importation de jeu de données de migration), le jeu de données passe à l'état Réessayer les transactions. A ce stade, le moniteur de transaction de migration doit être exécuté.

  • Le moniteur de l'état Erreur d'application des transactions détecte que le jeu de données est à l'état Réessayer les transactions, ce qui déclenche le retour à l'état Prêt pour application.

  • L'étape suivante consiste à faire passer le jeu de données de Réessayer les transactions à Appliquer les transactions. Ce passage peut être effectué manuellement ou par exécution du processus de surveillance Importation de jeu de données de migration.

  • Les transactions sont maintenant admissibles pour sélection par le processus d'application au niveau des transactions.

La logique de nouvelles tentatives peut également intervenir lors du passage entre Appliquer les objets et Appliquer les transactions, selon que des erreurs sont ou non présentes. Le scénario ci-dessous illustre ce point.

  • Après l'étape Appliquer les objets, des objets sont à l'état Erreur d'application. Le jeu de données passe à Appliquer les transactions et l'étape Appliquer est exécutée au niveau transaction.

  • Après l'étape Appliquer les transactions, des transactions sont à l'état Erreur d'application.

  • L'utilisateur choisit d'essayer d'appliquer à nouveau les objets (en cliquant sur Réessayer les objets). A partir de là, les étapes décrites plus haut pour Réessayer les objets sont exécutées.

  • Après l'application des objets, l'utilisateur peut choisir de réessayer les objets (après avoir corrigé les erreurs, le cas échéant).

  • A un certain stade, l'utilisateur passe à nouveau à Appliquer les transactions. Si des transactions sont à l'état Erreur d'application, le système fait passer automatiquement le jeu de données à Réessayer les transactions et les étapes décrites plus haut pour Réessayer les transactions sont exécutées.

Finaliser l'étape Appliquer

Lorsque tous les objets de migration d'une transaction de migration sont dans un état final (Appliqué, Rejeté ou Application impossible), la transaction de migration passe alors à l'état Appliqué. Une fois que toutes les transactions de migration ont l'état Appliqué, l'enregistrement du jeu de données de migration passe à l'état Finalisé et l'importation est finalisée.

Remarque :
Pour vérifier le cycle de vie complet de chaque enregistrement, sélectionnez l'onglet Objet métier - Récapitulatif dans les métadonnées d'application des objets métier standard Importation de jeu de données de migration (F1-MigrObjectImport), Transaction de migration (F1-MigrTransactionImport) et Objet de migration (F1-MigrObjectImport).