Migrer les données existantes vers le cadre de CSDM travail

  • Rversion finale: Xanadu
  • Mis à jour 1 août 2024
  • 3 minutes de lecture
  • Vous effectuez plusieurs tâches pour vous assurer que vos données d’application existantes migrent correctement vers les tables requises dans le CMDB.

    Avant de commencer

    Rôle requis : administrateur

    Pourquoi et quand exécuter cette tâche

    Gardez à l’esprit les points suivants :
    • Certaines CSDM tables ont été introduites récemment, vous ne les connaissez donc peut-être pas. Consultez la documentation de votre ServiceNow produit pour en savoir plus sur les tables.
    • Vous pouvez continuer à utiliser des tables personnalisées ou non conformes CMDB . Cependant, si vous le faites, vous risquez de ne pas profiter pleinement de vos ServiceNow produits.
    • Assurez-vous d’utiliser les outils de migration décrits à la section CSDM Outils de migration.
    Gérez les attributs que vous utilisez. Rationalisez vos attributs personnalisés. Utilisez les instructions suivantes pour décider si vous devez vraiment conserver toutes les personnalisations :
    • Bonne pratique : l’attribut personnalisé n’a pas d’attribut connexe, système-de-base mais vous devez l’utiliser.
    • Conserver : l’attribut personnalisé n’a pas d’attribut connexe, système-de-base mais il est requis pour un cas d’utilisation unique.
    • Refactoriser : l’attribut personnalisé possède un attribut ou une système-de-base aptitude qui peut être migrée.
    • Pas nécessaire : la personnalisation n’est plus nécessaire. Supprimez les attributs que vous n’utilisez pas ou que vous n’utilisez que rarement. Envisagez de supprimer les attributs s’il existe un meilleur moyen de traiter un cas d’utilisation.
    Considérez les dépendances connexes. Le déplacement d’éléments de configuration (CI) vers une nouvelle table ne déplace pas automatiquement les dépendances associées. Pour identifier les dépendances connexes, utilisez les scripts décrits dans Migration vers CSDM identifiant les dépendances de table (disponibles sur ServiceNow Community).
    Important :
    Le script ne déplace pas vos données ni leurs dépendances. Il identifie uniquement les dépendances. Vous refactorisez les données et les dépendances dans le cadre de la migration.

    Après avoir exécuté les scripts et évalué les données, vous aurez une meilleure idée de l’effort requis pour migrer vos données. Décidez si vous avez besoin de tous les rapports, règles et scripts référencés. Décidez ensuite de ce que vous souhaitez migrer et élaborez un plan de migration.

    Figure 1. Workflow de migration
    Étapes du workflow de migration.

    Procédure

    1. Sauvegardez vos données.
      Exportez vos données (avec tous les attributs) vers Excel et conservez le fichier dans un endroit sûr. Ayez un plan d’urgence en cas de problème.
    2. Mappez les attributs.
      Identifiez la table vers laquelle les données doivent aller. Assurez-vous que la table de destination possède les attributs requis système-de-base . Rationalisez vos attributs personnalisés. Décidez des personnalisations que vous conserverez.
    3. Déplacez les CI des classes existantes vers CMDB les classes.
      Remarque :
      N’oubliez pas les tables non conformes et leurs dépendances. Vous pouvez avoir des centaines de rapports, de règles métier, de scripts, de références de table, etc., qui ont besoin des données de vos tables non conformes.

      Le déplacement de CI vers une nouvelle table n’entraîne pas automatiquement le déplacement des rapports, des règles métier, etc. Comme décrit dans les étapes suivantes, le script correctif identifie les dépendances que vous devez refactoriser. Vous pouvez télécharger le script correctif à partir du ServiceNow Communityfichier .

    4. Refactoriser les attributs.
      Solidifier le modèle de données et préparer les données pour la migration.

      Assurez-vous d’avoir terminé les tâches liées au mappage d’attribut décrites dans les étapes précédentes. Suivez les instructions et refactorisez vos données si nécessaire.

    5. Migrez les données.
      Remarque :
      Assurez-vous que vous disposez d’une sauvegarde valide et récente. Faites une autre sauvegarde si nécessaire. Au cours de la migration, vous perdez tous les attributs personnalisés ou système-de-base personnalisés qui ne se trouvent pas dans la même hiérarchie de tables.
      Gardez ces points à l’esprit au fur et à mesure que vous avancez :
      • Migrez vos CI vers la nouvelle classe pour déplacer le CI et tous ses objets, incidents et changements connexes vers la nouvelle table.
      • Commencez avec quelques CI et augmentez le nombre lorsque vous vous sentez à l’aise.
    6. Corrigez les dépendances de table :
      1. Modifiez les rapports pour utiliser la nouvelle table.
      2. Migrez les règles métier et les scripts selon les besoins.
      3. Mettez à jour les références de table selon les besoins.
    7. Rechargez les données dans les nouveaux attributs à l’aide de la sauvegarde que vous avez effectuée précédemment.
    8. Validez toutes les données et dépendances.

    Résultats

    Vous avez migré avec succès votre application vers le CSDM cadre de travail et vos données se trouvent aux emplacements requis CMDB .