Migrer et synchroniser les données existantes avec le cadre de CSDM travail

  • Rversion finale: Yokohama
  • Mis à jour 30 janv. 2025
  • 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 : admin

    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 peut-être pas. Consultez la documentation de votre produit pour en savoir plus sur les tables peu familières.
    • Vous pouvez continuer à utiliser des tables personnalisées ou non conformes CMDB . Si vous le faites, cependant, vous risquez de ne pas profiter pleinement de vos produits.
    • Assurez-vous d’utiliser les outils de migration décrits à la section Assistance dans le processus de synchronisation du CSDM cycle de vie.
    Gérez les attributs que vous utilisez. Rationalisez vos attributs personnalisés. Utilisez les instructions suivantes pour décider si vous avez vraiment besoin de conserver toutes les personnalisations :
    • Préféré : 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.
    • Refonte : l’attribut personnalisé possède un attribut ou une système-de-base aptitude qui peut être migré.
    • Pas nécessaire : la personnalisation n’est plus nécessaire. Supprimez les attributs que vous n’utilisez pas ou rarement. Envisagez de supprimer des attributs s’il existe une meilleure façon de traiter un cas d’utilisation.
    Tenez compte des 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 (disponible sur la communauté ServiceNow).
    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 ce que vous voulez migrer et établissez 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 emplacement sécurisé. Ayez un plan d’urgence en cas de problème.
    2. Mappez les attributs.
      Identifiez la table où 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éplacer 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, et bien plus encore, qui ont besoin des données de vos tables non conformes.

      Le déplacement de CI vers une nouvelle table ne déplace pas automatiquement les rapports, les 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 ServiceNow Communitydu fichier .

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

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

    5. Migrez les données.
      Remarque :
      Assurez-vous d’avoir une sauvegarde valide et récente. Faites une autre sauvegarde si nécessaire. Lors de la migration, vous perdez tous les attributs personnalisés ou système-de-base qui ne se trouvent pas dans la même hiérarchie de table.
      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 par quelques CI et augmentez le nombre lorsque vous vous sentez à l’aise.
    6. Corrigez les dépendances de votre table :
      1. Modifiez les rapports pour utiliser la nouvelle table.
      2. Migrez les règles métier et les scripts selon vos besoins.
      3. Mettez à jour les références de table selon vos besoins.
    7. Rechargez les données dans les nouveaux attributs à l’aide de la copie de sauvegarde que vous avez effectuée précédemment.
    8. Validez toutes les données et dépendances.

    Résultats

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