Configuration de migration fournie par le framework

Cette rubrique contient des informations spéciales relatives aux objets de migration fournis dans le produit en vue de leur utilisation par l'assistant de configuration de contenu (CMA). Des objets supplémentaires peuvent être fournis par votre installation spécifique. Les informations spéciales concernant ces objets sont fournies séparément dans la documentation de chaque produit.

Les points suivants fournissent des informations relatives aux requêtes de migration fournies par le framework. Accédez à la page de la requête de migration dans l'application pour afficher les détails de tous les objets fournis.

  • Plusieurs requêtes de migration de base sont fournies afin de permettre un regroupement logique des tables système et administratives. Par exemple, il existe une requête de migration pour la configuration du système Framework F1-SystemConfig incluant la majorité des objets de configuration du système. Une autre requête est fournie pour les objets de configuration liés à l'assistant de configuration de contenu (CMA).

  • Le système fournit une requête de migration de type Groupe F1–FrameworkConfig (Configuration Framework), incluant plusieurs autres requêtes de migration. L'idée est que cette requête de migration inclue tous les objets standard inclus dans une migration globale. Votre installation spécifique peut inclure cette requête de migration dans sa propre requête de migration de type Groupe afin de prendre en charge une migration globale de toutes les tables administratives du framework et de l'installation. Une implémentation peut choisir de créer une requête de migration de type Groupe personnalisée. Dans ce cas, vous pouvez consulter les différentes requêtes de migration fournies par base pour voir si elles peuvent être incluses en tant que composants dans la requête de migration personnalisée. Les nouveaux plans de migration ajoutés à la requête de migration de base dans les versions futures sont ensuite automatiquement inclus dans les migrations futures.

  • Il existe plusieurs requêtes de migration liées à la sécurité, incluant différentes combinaisons de plans de migration afin de prendre en charge différents besoins métier liés à la migration de la sécurité. Notez que la requête de migration de sécurité incluse dans la requête de migration de groupe mentionnée ci-dessus est celle qui n'inclut pas les utilisateurs. Si votre implémentation souhaite copier des utilisateurs dans un environnement cible, voir la section Importer des données référençant un utilisateur pour plus d'informations.

Remarque :
Consultez la documentation sur l'assistant de configuration de contenu (CMA) de votre produit spécifique pour connaître ses recommandations sur les requêtes de migration à utiliser pour une migration complète des tables administratives du framework et du produit.

Les points suivants fournissent des informations relatives aux plans de migration fournis par le framework. Accédez à la page du plan de migration dans l'application pour afficher les détails de tous les objets fournis.

  • Les champs et les types de caractéristique ne sont pas migrés avec un objet (tel qu'un objet métier ou une zone de données), sauf si cela est spécifiquement indiqué.

  • Le service applicatif utilisé par un objet est seulement inclus à la migration s'il est détenu par CM.

  • L'objet Contrôle de batch peut éventuellement référencer un utilisateur (pour les batchs "minutés"). Pour plus d'informations sur la copie de l'utilisateur, voir Importer des données référençant un utilisateur. Notez également que lors de l'exécution d'un traitement batch, des informations de cliché sont capturées dans le contrôle de batch. De telles mises à jour incrémentent le numéro de version. Si un enregistrement de contrôle de batch fait partie de la migration et que l'étape de comparaison a détecté une modification du contrôle de batch, l'étape Appliquer sort en erreur pour ce contrôle de batch si un traitement batch est soumis entre les étapes de comparaison et d'application.

    Remarque :
    Les contrôles de batch de l'assistant de migration de contenu (CMA) qui font partie de l'étape d'importation sont en cours d'exécution et, de ce fait, le système n'inclut pas ces enregistrements dans une migration. Si votre implémentation modifie les paramètres par défaut de ces contrôles de batch, il est recommandé d'effectuer manuellement les mêmes modifications dans la région cible.

  • Les plans de migration standard des objets de maintenance et des objets métier contiennent des instructions permettant de copier les types d'option qui utilisent des références de clé étrangère pour faire référence à d'autres objets. Notez que les données stockées dans les options ne sont pas valides et que leur définition n'est pas requise dans le cas de migrations globales. En revanche, il est utile d'inclure des instructions subordonnées pour les références de clé étrangère dans les migrations ciblées, afin d'assurer que les données associées soient incluses dans la migration. Si vous ajoutez d'autres types d'option d'objet de maintenance ou d'objet métier qui utilisent des clés étrangères et souhaitez prendre en charge des migrations ciblées, créez respectivement des plans et des requêtes de migration personnalisés pour les objets métier et les objets de maintenance, afin d'inclure ces objets référencés dans le plan de migration. Notez qu'il n'est pas nécessaire de dupliquer les instructions des plans de migration standard. Vous pouvez définir des plans de migration supplémentaires ne contenant que ces types d'option personnalisés supplémentaires. Lorsque vous soumettez une requête de migration ou des objets de maintenance ou des objets métier, vous devez inclure les plans de migration standard et les plans de migration personnalisés dans la requête.

  • Pour les scripts, les objets et les zones basés sur un schéma, les plans de migration fournis par l'installation permettent migrer, par l'intermédiaire de contraintes, certaines des données standard qui leur sont associées. Toutefois, les données spécifiées par d'autres formats (par exemple par l'intermédiaire des étapes Modifier les données dans les scripts, de schémas référencés pour les objets basés sur un schéma ou de mnémoniques de données dans les paramètres de zone, etc.) ne sont pas identifiées et combinées dans la même transaction. La fonctionnalité de traitement itératif pour l'étape d'importation doit résoudre tous les problèmes de temporisation pouvant entraîner des erreurs de validation pour ces types d'objet.

  • Il existe deux plans de migration pour les scripts. Le plan de migration F1-ScriptOnly fait uniquement migrer le script et son service applicatif (à condition que le service applicatif soit détenu par CM). Le plan de migration F1-Script inclut la plupart des objets associés, mais ne fait pas migrer les objets référencés dans les étapes Modifier les données. Il ne déplace pas l'objet de maintenance Fonction. Il peut être inclus dans une requête de migration ciblée personnalisée appropriée, avec laquelle des scripts et des données associées doivent faire l'objet de la migration.

  • Si votre implémentation comporte un paramètre Configuration Mutualisation de paramètres pour l'entrée F1_​​DBCONINFO qui sera incluse dans une requête de migration, veillez à ce que l'utilisateur de l'importation de la région cible dispose des droits d'accès appropriés sur cette entrée (mode d'accès Administrateur pour le service applicatif Configuration Mutualisation de paramètres (CILTWSDP)).

  • Les documents joints communs dans l'objet de maintenance Document joint peuvent être considérés comme des données administratives à inclure dans la migration. Cet objet de maintenance ayant une clé générée par le système, comme indiqué dans Données administratives avec des clés primaires générées par le système, il utilise une clé logique constituée du nom de fichier et de la date de création pour déterminer si l'enregistrement existe dans l'environnement cible. En outre, cet objet de maintenance contient des données administratives (documents joints communs) et des données non administratives (documents joints détenus). Pour réduire le risque de "collision" de clé, les nouveaux documents joints communs reçoivent une clé générée au milieu de laquelle est inséré un zéro alors que les documents joints détenus reçoivent une clé générée sans zéro au milieu.

  • L'objet de maintenance Menu a une clé définie par l'utilisateur ; cependant, les lignes et les options qu'il comporte ont des clés générées par le système. Pour éviter qu'une ligne ou une option de menu ne soit remplacée à tort, l'objet de maintenance Menu vérifie que le nom de menu de la ligne est le même dans la source et dans la cible, et il vérifie que la ligne de menu de l'option de menu est la même dans la source et dans la cible ; si ce n'est pas le cas, une erreur est émise dans l'étape de comparaison.

  • Pour les messages système, le produit fournit trois plans de migration différents.

    • Catégorie de message et ses messages (F1-MessageCategory). Ce plan de migration est inclus dans la requête de migration F1-SystemConfig.

    • Catégorie de message (F1-MessageCategoryOnly). Ce plan de migration est fourni pour prendre en charge une migration ciblée lorsque l'implémentation a créé une catégorie de message personnalisée et veut la déplacer sans déplacer tous les messages qu'elle contient.

    • Message (F1-Message). Ce plan de migration est fourni pour prendre en charge une migration ciblée où seuls des messages spécifiques d'une catégorie de message doivent être migrés.

  • Pour les valeurs de consultation, l'installation fournit deux plans de migration différents.

    • Champ de consultation et ses valeurs (F1-Lookup). Ce plan de migration est inclus dans la requête de migration F1-SystemConfig.

    • Valeur de consultation (F1-LookupValue). Ce plan de migration est fourni pour prendre en charge une migration ciblée où seules des valeurs de consultation spécifiques d'un champ de consultation doivent être migrés.

  • Pour certains objets de données système, aucune information des enregistrements livrés de base ne peut être modifiée par une implémentation. Pour ces enregistrements, les requêtes de migration livrées de base comportent des critères de sélection qui sélectionnent uniquement les enregistrements détenus par CM (en effet, les enregistrements de base existent forcément dans la région cible, si les deux régions ont la même version). C'est le cas par exemple du type d'algorithme. La requête de migration F1-SystemConfig inclut uniquement les types d'algorithme détenus par CM. Cependant, beaucoup d'objets de données système acceptent des modifications personnalisées d'un ou plusieurs champs ; par exemple, une implémentation peut remplacer le texte ou certains paramètres de l'objet Zone. D'autres objets de données système acceptent des ajouts personnalisés à des ensembles. Par exemple, une implémentation peut ajouter des algorithmes ou des options à un objet de maintenance. Pour les plans de migration liés à ces objets de données système, tous les enregistrements sont inclus dans les requêtes de migration livrées de base afin de permettre la migration de n'importe quelle configuration personnalisée. Ceci implique que, au cours de l'étape Importer/Comparer, de nombreux objets livrés de base qui ne sont pas personnalisés sont marqués comme inchangés.

  • Un grand nombre des objets de maintenance associés à l'intégration contenant des références à des données spécifiques, tels que les émetteurs de message. Ces données doivent être migrées avec une extrême prudence. Lorsque c'est approprié, envisagez d'utiliser la substitution d'URI. Pour plus d'informations, voir Référencer des URI.