Remarque complémentaire concernant les importations
Les points suivants fournissent des commentaires divers relatifs à l'importation de migration.
- L'assistant de configuration de contenu (CMA) repose sur le fait que les contraintes d'intégrité référentielle de la base de données ne sont pas en place et que les instructions SQL peuvent être exécutées dans n'importe quel ordre au sein de la transaction. Une solution d'archivage nécessitant des contraintes d'intégrité référentielle (telle qu'Information Lifecycle Management) ne serait pas possible sur ces données. Etant donné que les migrations de l'assistant de configuration de contenu (CMA) sont constituées de données administratives et non de données transactionnelles, ceci doit constituer une exception raisonnable.
- La validation effectuée passe uniquement par le service de validation de page. Les algorithmes de validation d'objet métier ne sont pas exécutés. La validation de page ne procède pas à la validation de l'objet métier par rapport au schéma (par exemple les champs obligatoires, les tailles de champ, etc.).
-
Si plusieurs requêtes de migration sont exportées en même temps, du côté importation, vous devez traiter l'importation, la vérification et l'application d'un jeu de fichiers/de données complet avant de passer au jeu suivant. En effet, si des objets sont inclus dans plusieurs fichiers, deux jeux d'insertion seront générés, mais seul le premier réussira. Le second entraînera le passage de l'objet à l'état Application impossible. Au lieu de cela, si vous attendez que le premier fichier soit terminé avant d'importer le deuxième, ce deuxième jeu de données ne générera aucun SQL pour l'objet, puisqu'il a déjà été inséré. C'est une question d'efficacité : si vous importez tout d'abord tous les fichiers, puis tentez de tous les appliquer, vous devrez identifier l'objet dupliqué comme une erreur, puis marquer l'objet comme rejeté avant d'appliquer la transaction. Cela peut également être évité en utilisant une requête de migration de type Groupe afin d'inclure tous les objets dans un même fichier plutôt que dans plusieurs fichiers.
-
Le système fournit un algorithme permettant de purger les objets de migration "inchangés" pour un jeu de données donné. Celui-ci peut être rattaché en tant qu'algorithme de sortie d'objet métier sur l'état Prêt pour comparaison pour l'objet métier Importation de jeu de données de migration (F1-MigrDataSetImport).
Les points suivants fournissent des commentaires divers relatifs à l'importation d'un jeu de données métier en mode en masse.
-
Le nombre d'entités incluses dans chaque objet de migration est capturé dans l'enregistrement de l'objet de migration.
-
L'étape de comparaison génère uniquement des instructions SQL pour les entités nouvelles ou modifiées. Aucune instruction SQL n'est générée pour les entités inchangées.
-
La recherche d'objets de migration en fonction des entités qu'ils contiennent n'est prise en charge que pour les entités qui ont été déterminées nouvelles ou modifiées. Autrement dit, ce type de recherche par entités incluses n'est possible qu'après l'étape de comparaison.
