Demander un clone

  • Rversion finale: Zurich
  • Mis à jour 31 juil. 2025
  • 23 minutes de lecture
  • Demandez à un clone de copier des données d’une instance de production vers une instance de non-production ou de copier des données entre des instances de non-production.

    Avant de commencer

    Rôle requis : clone_admin

    Remarque :
    Si l’objectif de l’instance source est DART (Data Access for Responsible Training), le clone n’est pas activé et un message d’erreur s’affiche.

    Procédure

    1. Accédez à la Tous > Console d'administrateur de clones > Accueil du clone.
    2. Sélectionnez Demander un clone.
    3. Remplissez les champs du formulaire.
      Tableau 1. Cloner le formulaire de demande
      Champ Description
      Instance source La base de données d’origine à partir de laquelle les données sont copiées.
      Instance cible Le nouvel emplacement vers lequel les données sont copiées.
      Remarque :
      Vous pouvez ajouter une instance ou sélectionner une instance existante sans quitter la page.
      Profil clone

      Appliquez un profil de clone que vous avez créé précédemment. Toutes les exclusions, conservateurs et scripts que vous avez ajoutés au profil sont appliqués à la demande de clone.

      Remarque :
      Si la case par défaut est cochée sur le profil clone, la demande de clone charge ce profil chaque fois que vous ouvrez la page de demande de clone (console d’administration de clone v.1.0.18 ou ultérieure).
      Heure de début planifiée du clone L’heure de début pour commencer le clonage de votre instance.
      E-mail à l’achèvement E-mail devant être notifié de l’achèvement du clone.
      Adresse e-mail externe E-mails externes dans lesquels vous souhaitez que les notifications de clonage soient envoyées pendant le processus de clonage.
    4. Sélectionnez les options suivantes que vous souhaitez configurer pour votre clone.
      Remarque :
      Des paramètres supplémentaires peuvent être configurés pour votre demande de clone, cependant, certaines options peuvent augmenter considérablement le temps d’achèvement de votre clone.
      Tableau 2. Options de clone
      Champ Description
      Exclure les tables spécifiées dans la liste d'exclusion Empêche le clonage d’enregistrements à partir de tables sur l’instance source répertoriées sous Clone d'instance > Tables d'exclusion. Si une table figure sur la liste d’exclusion, le clone exclut les enregistrements de la table ainsi que les enregistrements des tables enfants.

      Lors de l’exclusion des tables, leur schéma de table et leur hiérarchie seront toujours clonés sur votre instance cible. Par conséquent, votre instance cible aura des tables vides mais utilisables après le clone.

      Remarque :
      Les exclusions de tables prêtes à l’emploi ServiceNow sont toujours exclues et ne sont pas affectées par ce paramètre. Il s’agit notamment de tables contenant l’audit, l’utilisation des licences, la journalisation et les notifications.

      Vous pouvez choisir de désactiver ce paramètre si vous avez besoin des données de vos tables exclues.

      Le moteur clone hérité ne prend pas en charge cette option.

      Le paramètre par défaut indique que les tables spécifiées dans la liste d’exclusion sont exclues d’un clone.

      Exclure les données d'audit et de journal Empêche le clonage des enregistrements d’audit et de journal à partir de l’instance source. Cela crée des tables d’audit et de journal vides mais utilisables sur l’instance cible.
      Remarque :
      Si vous excluez les données d’audit et de journal de votre clone, le flux d’activité pour les enregistrements ne correspondra pas à l’instance source. Cela est dû au fait que le flux d’activité s’appuie sur la table d’audit pour générer l’historique.

      Le paramètre par défaut indique que les données d’audit et de journal sont exclues d’un clone.

      Exclure les données de pièce jointe Empêche le clonage de certains fichiers comme
      • Fichiers vidéo
      • Fichiers image
      • Autres fichiers binaires volumineux
      dans la table sys_attachment.
      Remarque :
      Les pièces jointes prêtes à l’emploi ServiceNow et les autres fichiers pertinents pour le système (par exemple, les images d’éléments de catalogue, les images de thème et les icônes) ne sont pas concernés par ce paramètre.
      Les pièces jointes prêtes à l’emploi ServiceNow et autres fichiers pertinents pour le système suivants ne sont pas affectés par ce paramètre et ne sont pas exclus d’un clone :
      • Valeurs de nom de table commençant par ZZ_.
      • Noms de tables : sys_certificate, sc_cat_item, sys_upgrade_manifest, ecc_agent_jar, ecc_agent_mib, sys_store_app ou invisible.sys_store_app.

      Le paramètre par défaut consiste à exclure les données de pièce jointe.

      Conserver le thème Préserve le thème et les éléments CSS sur l’instance cible. Par conséquent, votre instance cible conservera son thème, son apparence après un clone.

      Le paramètre par défaut consiste à conserver le thème sur l’instance cible.

      Verrouiller les paramètres pour cette demande de clone Si vous utilisez un profil clone, cette option verrouille les paramètres et les options au moment de la demande de clone. Toute modification ultérieure du profil de clone, quel que soit le moment où le clone s’exécute, n’affecte pas la demande de clone.

      Cette option n’est pas sélectionnée par défaut.

      Quantité de données copiées à partir de tables spécifiques Limite le nombre de jours de données historiques pour la table de tâches et ses tables enfants (par exemple, les tables Incident, Problème et Changement) à 90 jours.

      Pour réduire le temps de clonage, envisagez d’exclure complètement les tables volumineuses. Lors de l’exclusion des tables, votre instance cible aura le même schéma de table et la même hiérarchie (c’est-à-dire des tables utilisables vides) que l’instance source.

      Le paramètre par défaut consiste à cloner toutes les données de la table de tâches et de ses tables enfants vers l’instance cible.

      Conserver les Ensembles de mises à jour en cours Conserve les 90 derniers jours des ensembles de mises à jour en cours dans le périmètre de l’application global. Cette option vous permet de conserver les ensembles de mises à jour globaux en cours créés au cours des 90 derniers jours sur votre instance cible.
      Remarque :
      Cette option ne conserve pas vos ensembles de mises à jour inclus dans le périmètre en cours. Les ensembles de mises à jour datant de plus de 90 jours ne seront pas enregistrés. Il est recommandé d’examiner et de valider vos ensembles de mises à jour avant le clonage. La valeur par défaut ne doit pas conserver les ensembles de mises à jour.
      Fréquence de clone Cette option vous permet de planifier des clones récurrents de votre instance source vers votre instance cible. Il vous permet de définir la fréquence de clonage et le nombre maximal d’occurrences. Par défaut, la fréquence de clonage est définie sur Aucune. Pour plus d’informations sur la planification du clonage, consultez Planifier des clones récurrents.
    5. Sélectionnez Continuer.
    6. Passez en revue le résumé de votre demande de clone, puis sélectionnez Confirmer et soumettre la demande de clone.

    Demander un clone (interface utilisateur héritée)

    Demandez à un clone de copier des données d’une instance de production vers une instance de non-production ou de copier des données entre des instances de non-production.

    Avant de commencer

    Rôle requis : clone_admin

    À compter de la version australienne, les demandes de clone ne sont plus déployées, améliorées ou prises en charge sur la page héritée.

    Remarque :
    Les demandes lancées via la page héritée clone_instance.do ne s’affichent pas sur la nouvelle page d’accueil de la console de clone. Cependant, ils peuvent toujours être trouvés sur la page d’historique des clones hérités clone_instance_list.do.
    Configurez votre instance cible avant de demander votre clone. Procédez comme suit :
    • Accédez au Configurations > Cloner des instances.
    • Sélectionnez Nouveau.
    • Remplissez le formulaire Nouvelle instance de clone.
    Configurez un profil de clone. Procédez comme suit :
    • Accédez à la Configurations > Profils de clones.
    • Remplissez le formulaire Nouveau profil de clone.
      Remarque :
      Vous pouvez créer plusieurs profils de clone et utiliser un modèle de clone réutilisable. Les profils de clone vous permettent de sélectionner les exclusions et les conservateurs corrects pour votre clone.

    Pourquoi et quand exécuter cette tâche

    Utilise ServiceNow AI Platform les données de la copie de sauvegarde quotidienne la plus récente de l’instance source lors du clonage. Les copies de sauvegarde utilisées pour le clonage datent de 36 heures maximum. Le clone d’instance commence la préparation initiale, y compris la sélection de la dernière copie de sauvegarde à utiliser, uniquement à la date et à l’heure de début planifiées du traitement.

    Procédure

    1. Connectez-vous à l’instance que vous souhaitez cloner.
      Cette instance devient l’instance source de la demande de clone.
    2. Configurez un enregistrement pour chaque instance cible sur laquelle vous souhaitez recevoir des Cible du clone (inscription et authentification) données de clone.
    3. Vérifiez la liste des tables exclues du clonage et ajoutez ou supprimez des tables à exclure de l’instance cible.
    4. Vérifiez la liste des tables et des propriétés système que vous souhaitez enregistrer sur l’instance cible avec ce qui suit.

      Vous pouvez utiliser des conservateurs de données. Vous pouvez également créer ou modifier des conservateurs de données, selon vos besoins.

    5. Conservez toutes les applications non publiées sur l’instance cible.
    6. Accédez à la Clone d'instance > Demander un clone.
    7. Facultatif : Spécifiez un profil de clone prédéfini.
      Un profil de clone stocke les options cibles et de clone. Le profil de clone remplit automatiquement votre demande de clone avec les paramètres de profil que vous avez sélectionnés. Consultez les profils de clone pour connaître les demandes de clone.
    8. Dans le champ Instance cible , sélectionnez l’instance cible à laquelle vous souhaitez recevoir les données clonées.
      Créez une demande de clone distincte pour chaque instance cible sur laquelle vous souhaitez recevoir des données de clone.
    9. Dans le champ Heure de début planifiée du clone , sélectionnez l’heure à laquelle vous souhaitez que le clonage commence.
      Vous pouvez planifier plusieurs demandes de clone pour la même instance source. Par exemple, créez une demande de clone pour copier les données vers l’instance de non-production A et une autre demande de clone pour copier les données vers l’instance de non-production B. Le moteur de planification détermine si plusieurs demandes de clone sur la même instance source peuvent se produire simultanément ou si elles doivent se produire séquentiellement. Si votre instance source est très volumineuse, nous vous recommandons le chaînage de clones, reportez-vous à la section chaînage de clones sur Exploration du clone d’instance.
      Le système vérifie l’heure de début planifiée et accepte la valeur date-heure que vous avez sélectionnée ou suggère une valeur date-heure disponible. Le processus de validation évite les conflits de planification avec d’autres automatisations utilisant la même instance cible.
    10. Dans le champ E-mail une fois terminé , saisissez votre adresse e-mail afin de pouvoir recevoir des alertes une fois le clonage terminé, annulé ou présentant une erreur.
    11. Cliquez sur la pointe de flèche Options pour qu’elle tourne vers le bas.
    12. Renseignez vos options.
    13. Sélectionnez Soumettre.
      Si la demande de clone ne rencontre aucun problème, le système affiche le modal Authentifier la cible.
    14. Dans les champs Nom d’utilisateur et Mot de passe , entrez le nom d’utilisateur et le mot de passe d’un compte administrateur sur l’instance cible, puis cliquez sur Authentifier.
    15. Examinez les paramètres du clone et cliquez sur OK.
      Un e-mail est envoyé à l’adresse fournie une fois le clone terminé, annulé ou présentant une erreur.

    Que faire ensuite

    Vous pouvez :

    Cible du clone (inscription et authentification)

    Un enregistrement cible de clone spécifie l’URL d’instance et les informations d’identification utilisées pour le clonage.

    Avant de commencer

    • Fournissez les informations d’identification de l’instance cible pour un utilisateur disposant du rôle administrateur. Utilisez un compte d’utilisateur local, et non un compte d’utilisateur LDAP ou SSO. Les informations d’identification de l’instance cible doivent exister dans la table Utilisateur [sys_user] en tant qu’enregistrement utilisateur ou dans le cadre d’une intégration LDAP. Les demandes de clone ne peuvent pas rediriger les demandes d’authentification vers un fournisseur d’identité d’authentification unique.
    • Vérifiez que la propriété glide.db.clone.allow_clone_target système est définie sur True. Par défaut, cette propriété est activée sur les instances dont le nom se termine par Dev, Test, Stage, UAT ou QA.
    • Si l’instance cible utilise l’authentification basée sur la plage IP, elle doit activer la plage IP 10.0.0.0/10.255.255.255 pour communiquer sur un réseau local.
    • Rôle requis : clone_admin

    Procédure

    1. Accédez à la Tous > Clone système > Cibles du clone.
    2. Sélectionnez Nouveau.
    3. Entrez l’URL de l’instance de réception (cible).

      Le système valide que l’instance active les cibles du clone et que le clonage haute disponibilité est actif. Les instances de production et de démonstration échouent à ces contrôles de validation.

      Figure 1. Cible du clone non valide
      Message d’erreur de la cible du clone
    4. Entrez les informations d’identification d’authentification de base d’un compte d’utilisateur disposant du rôle administrateur sur l’instance cible.
      Cible du clone
      Remarque :
      Pour cloner plusieurs cibles à partir d’une source, vous devez émettre des demandes de clone distinctes pour chaque cible.
      Le système valide que les informations d’identification de l’utilisateur disposent d’un accès clone_admin et SOAP à l’instance cible.
    5. Sélectionnez Soumettre.
      Le système vérifie la connectivité et valide les informations d’identification de l’utilisateur par rapport à l’instance cible.

    Conservation des données des instances cibles lors des clonages

    Vous pouvez utiliser des conservateurs de données pour protéger les données de l’instance cible contre le remplacement. Si vous avez des applications personnalisées, vous devez également conserver manuellement le contenu d’application non publié.

    Conservateurs de données

    Parfois, il est nécessaire de conserver certaines données sur une instance ciblée pour le clonage. Par exemple, si la cible est un serveur MID, vous ne devez pas remplacer la table de serveur MID [ecc_agent]. Les données conservées sont réappliquées à l’instance cible une fois les exclusions terminées.
    Avertissement :
    Vous devez définir les conservateurs de données sur l’instance source. Leur définition sur l’instance cible ne préserve pas les données.
    Les conservateurs de données préservent généralement les paramètres et thèmes système, tels que :
    • Paramètres d’authentification spécifiques à l’instance
    • Signet [sys_ui_bookmark]
    • Sélection récente [sys_ui_recent_selection]
    • Préférence d’utilisateur [sys_user_preference]
    Remarque :
    Un clone ne prend pas en charge la conservation des données à partir d’une vue de base de données.

    N’utilisez pas de conservateurs de données pour transférer de grands ensembles de données, tels que des groupes d’utilisateurs. Si vous devez conserver des données de table, telles que des utilisateurs, des groupes et des rôles, envisagez d’exporter les enregistrements dans un fichier et de les importer après le clonage.

    Conservateurs de données pour l’authentification unique (SSO) à fournisseurs multiples

    Le système crée automatiquement les conservateurs de données nécessaires au clonage lorsque vous activez l’intégration de l’authentification unique de plusieurs fournisseurs.
    Nom Table Conditions
    Certificat Certificats X.509 [sys_certificate] Aucun
    Propriétés de l’instance principale Propriété système [sys_properties]
    • [OU] [Nom] [est l’un des] [glide.authenticate.external, glide.authenticate.external.logout_redirect]
    • [OU] [Nom] [commence par] [com.snc.integration.saml_esig]
    • [OU] [Nom] [est l’un des] [glide.smtp.port, glide.smtp.auth, glide.smtp.encryption]
    • [OU] [Nom] [commence par] [glide.authenticate.multisso]
    • [OU] [Nom] [est] [glide.authenticate.sso.redirect.idp]
    Remarque :
    Les propriétés glide.smtp.port, glide.smtp.authet glide.smtp.encryption sont déconseillées.
    Propriétés Digest Propriétés Digest [digest_properties] Aucun
    Fournisseurs d'identité Fournisseurs d’identité [sso_properties] Aucun
    Propriétés SAML2 Update1 Propriétés SAML2 Update1 [saml2_update1_properties] Aucun
    Remarque :
    Bien que vous puissiez modifier ces conservateurs de données, il est recommandé de ne pas le faire. Les tables Propriétés de synthèse [digest_properties], Fournisseurs d’identité [sso_properties] et Propriétés SAML2 Update1 [saml2_update1_properties] sont requises pour que l’authentification unique (SSO) source multiple fonctionne correctement. Si l’authentification unique à sources multiples est désactivée sur l’instance cible, vous pouvez supprimer les trois conservateurs de données en toute sécurité. Supprimez-les en même temps, car le système arrête le clone avec un message d’erreur lorsque vous tentez de cloner avec une ou deux de ces tables conservées.

    Conservateurs de données pour SAML

    La conservation des paramètres liés à l’authentification unique SAML peut empêcher l’instance cible d’utiliser les mauvais paramètres d’émetteur et d’audience lors des demandes d’authentification auprès de votre fournisseur d’identité. Pour conserver les paramètres SAML, créez des conservateurs de données pour les tables suivantes :

    • Propriété système [sys_properties] : pour préserver les propriétés SAML.
    • Certificats X.509 [sys_certificate] : pour conserver les certificats SAML.
    • Utilisateur [sys_user] : pour conserver les utilisateurs SAML.

    Vous devez également préserver les propriétés et les utilisateurs impliqués dans SAML.

    Conservation des applications non publiées

    Vous ne pouvez pas utiliser de conservateurs de données pour enregistrer des applications non publiées. Au lieu de cela, les développeurs d’applications doivent choisir comment ils veulent conserver les applications non publiées.

    Le processus de clonage ne préserve pas les différences de version pour les applications en développement. Au lieu de cela, le clone système copie uniquement la version de l’application installée sur l’instance source sur l’instance cible. Si l’instance cible possédait une version de développement de la même application, l’application sera modifiable après le clone, mais elle ne sera pas à la version installée sur l’instance source. Si l’application était absente de l’instance source, le processus de clonage supprime l’application de l’instance cible.

    Créer un conservateur de données

    Les conservateurs de données conservent les données spécifiées sur une instance cible.

    Avant de commencer
    Rôle requis : clone_admin
    Pourquoi et quand exécuter cette tâche

    Parfois, il est souhaitable de conserver certaines données sur une instance cible. Par exemple, lors de l’utilisation d’un serveur MID, vous pouvez éviter de remplacer la table de serveur MID [ecc_agent]. Les données conservées sont stockées dans une liste générée dynamiquement sur l’instance cible avant le clone et restaurées sur l’instance cible une fois le clone terminé. Vous définissez les conservateurs de données sur l’instance source.

    Les conservateurs de données sont principalement destinés à préserver les paramètres et les thèmes du système, tels que les paramètres d’authentification spécifiques à l’instance. N’utilisez pas de conservateurs de données pour transférer de grands ensembles de données, tels que des groupes d’utilisateurs. Si vous devez conserver des données de table telles que des utilisateurs, des groupes et des rôles, envisagez d’exporter les enregistrements dans un fichier et de les importer une fois le clone terminé.

    Déterminez s’il est nécessaire de conserver les données dans les tables suivantes.
    • Signet [sys_ui_bookmark]
    • Sélection récente [sys_ui_recent_selection]
    • Préférence d’utilisateur [sys_user_preference]

    Si vous définissez un conservateur de données sur une table où l’instance source a plus d’enregistrements que l’instance cible, les données conservées sur l’instance cible incluent également les enregistrements supplémentaires de l’instance source.

    Par exemple, supposons que le conservateur de données est déjà en place.
    • Dans l’instance source, la table sys_temp contient 100 enregistrements.
    • Dans l’instance cible, la table sys_temp contient 20 enregistrements.
    Après le clone, la table sys_temp de l’instance cible contient 100 enregistrements.
    • Les 20 enregistrements de la table sys_temp cible sont conservés avec succès (selon les spécifications du conservateur de données). Ces enregistrements faisaient partie des 100 enregistrements de la table sys_temp source.
    • La table sys_temp source apporte les 80 enregistrements restants à la table sys_temp cible.

    Pour résoudre ce problème et conserver uniquement les enregistrements de la table cible, créez un enregistrement de table d’exclusion pour la table cible, en plus de définir le conservateur de données sur la table source.

    Important :
    Configurez les conservateurs sur l’instance source.
    Procédure
    1. Sur l’instance source, accédez à Clone système > Conserver les données.
    2. Sélectionnez Nouveau.
    3. Entrez l’étiquette de la table comme nom, par exemple, Préférence utilisateur pour la table [sys_user_preference].
      Le conservateur de données doit avoir un nom de table ou il ne peut pas être soumis.
    4. Sélectionnez la table à conserver.
      Le conservateur de données doit avoir une table sélectionnée, sinon il ne peut pas être soumis.
    5. Cochez la case Thème si les données conservées sont une propriété de l’interface utilisateur.
    6. Définissez les données à conserver à l’aide du Créateur de conditions .
      Vous pouvez utiliser des conditions pour définir des enregistrements particuliers que vous souhaitez conserver lors d’un clone. Par exemple, pour ne conserver que des propriétés système particulières, vous pouvez ajouter des conditions pour chaque nom de propriété que vous souhaitez conserver.
      Remarque :
      La condition pour faire correspondre les expressions régulières [correspondance regex] n’est plus prise en charge.
      Conservateur de données avec conditions
    7. Sélectionnez Soumettre.
      Si vous souhaitez supprimer le conservateur de données ultérieurement, veillez à ne pas modifier ou supprimer les enregistrements de conservation de données suivants :
      • Propriétés de l’instance principale
      • Sémaphores
      • Comptes de messagerie
      Remarque :
      Les vues de base de données ne peuvent pas être conservées.

      Les conservateurs ne peuvent pas être vides, et les utilisateurs ne seront pas en mesure de soumettre le clone si les conservateurs sont vides.

    Conserver les propriétés SAML

    Si vous souhaitez qu’une instance cible clone conserve son intégration SAML existante, vous devez modifier le conservateur de données des propriétés de l’instance principale pour inclure les propriétés SAML.

    Avant de commencer
    Rôle requis : admin
    Procédure
    1. Accédez à la Tous > Clone système > Conserver les données.
    2. Sélectionnez les propriétés de l’instance principale.
    3. Ajoutez les conditions suivantes.
      • [OU] [Nom] [est l’un des] [glide.authenticate.external, glide.authenticate.external.logout_redirect, glide.authenticate.failed_requirement_redirect]
      • [OU] [Nom] [commence par] [glide.authenticate.sso.saml2]
      • [OU] [Nom] [commence par] [com.snc.integration.saml_esig]
      Préservation des propriétés système SAML
      Remarque :
      Assurez-vous que la case Thème est décochée afin que ces propriétés soient préservées, que vous conserviez ou non le thème de l’instance.
    4. Cliquez sur Mettre à jour.

    Conserver les applications et les personnalisations en développement lors d’un clone système

    Conservez manuellement une copie de chaque application et personnalisation en cours de développement avant de pouvoir cloner la version de l’application vers l’instance cible (de développement).

    Avant de commencer

    Rôle requis : admin

    Vérifiez que vous disposez d’un accès en écriture à l’enregistrement de l’application et d’un référentiel de contrôle de source.

    Pourquoi et quand exécuter cette tâche
    Le processus de clonage ne préserve pas les différences de version pour les applications et les personnalisations d’application en développement. Au lieu de cela, le système clone uniquement les copies des versions d’application et de personnalisation d’application installées sur l’instance source sur l’instance cible. Si l’instance cible possède une version de développement de la même application, l’application est modifiable après le clone, mais se trouve à la version qui a été installée sur l’instance source. Si l’application était absente de l’instance source, le processus de clonage la supprime de l’instance cible.
    Procédure
    1. Pour conserver l’application sur l’instance cible du clone, effectuez l’une des actions suivantes :
      Tableau 3. Différences de version entre les instances
      État de la version d’application Action à effectuer
      La version de l’application sur l’instance cible du clone est différente de la version de l’instance source. Exportez chaque application à partir de l’instance cible du clone. Vous avez le choix entre :
      • Lier chaque application à un référentiel de contrôle de source.
        Remarque :
        Si l’application est déjà liée à un référentiel de contrôle de source, validez la dernière version dans celui-ci.
      • Publier chaque application dans un ensemble de mises à jour.
      L’application n’est disponible que sur l’instance cible du clone.
      La version de l’application sur l’instance cible du clone est la même que celle de l’instance source. Aucun. Le processus de clone système copie cette version de l’application sur l’instance cible lors du clonage.
    2. Demandez un clone système de l’instance source vers l’instance cible.
      Par exemple, clonez votre instance de production sur votre instance de développement.
    3. Une fois le processus de clonage terminé, connectez-vous à l’instance cible du clone.
    4. Remarque :
      Si le contrôle de source est lié, après le clonage, la plateforme récupère automatiquement les applications et les applications personnalisées. Si cette option est désactivée via glide.source_control.post_clone_import_enabled, vous devrez récupérer manuellement en procédant comme suit.
      Si vous avez enregistré chaque application dans un référentiel de contrôle de source, utilisez l’une des actions suivantes pour les récupérer à partir du référentiel de contrôle de source :
      Remarque :
      Pour savoir à quoi s’attendre après la personnalisation de l’application après le clonage, consultez Résultats après clonage pour les personnalisations d’application.
      Tableau 4. Récupérer des applications à partir d’un référentiel de contrôle de source
      État d’installation de l’application Action à entreprendre sur la cible du clone
      L’application et la personnalisation ont été précédemment installées sur l’instance source. Appliquez les modifications à distance à partir du référentiel de contrôle de source.
      L’application n’a jamais été installée sur l’instance source. Supprimez la configuration du référentiel (sys_repo_config) et importez la personnalisation à partir du référentiel de contrôle de source.
      Tableau 5. Changements distants après le clone
      Champ Description
      glide.source_control.post_clone_import_enabled Pour désactiver l’automatisation d’application des changements distants, définissez sur Faux. La valeur par défaut est Vrai.
      glide.source_control. post_clone_import_delay_time_sec Pour fournir un délai, qui retardera le traitement de la file d’attente, fournissez une valeur. La valeur par défaut est zéro.
      glide.source_control. post_clone_import_pause_refresh_time_sec Pour indiquer un intervalle pendant lequel la tâche d’actualisation du référentiel ne s’exécute pas, fournissez une valeur. La valeur par défaut est de trois heures (10800).
    5. Si vous avez enregistré chaque application dans un ensemble de mises à jour, effectuez l’une des actions suivantes pour les récupérer à partir de l’ensemble de mises à jour :
      Tableau 6. Récupérer des applications à partir d’un ensemble de mises à jour
      État d’installation de l’application Action à entreprendre sur la cible du clone
      L’application a précédemment été installée sur l’instance source.
      1. Supprimez la version d’application qui a été clonée à partir de l’instance source.
      2. Chargez l’ensemble de mises à jour contenant la version actuelle de l’application.
      L’application n’a jamais été installée sur l’instance source. Chargez l’ensemble de mises à jour contenant la version actuelle de l’application.
    Résultats
    Les applications précédemment en développement sont disponibles pour un développement ultérieur sur l’instance cible du clone.
    Préservez l’application Événements marketing

    Supposons que votre société ait précédemment créé la version 1.0 d’une application personnalisée appelée Marketing Events. Vous avez déjà publié la version 1.0 de l’application Événements marketing dans le référentiel d’applications et l’avez installée sur votre instance de production.

    Au fil du temps, les utilisateurs ont soumis des demandes d’amélioration pour l’application, et vous décidez de développer la version 2.0 de l’application Événements marketing sur une instance de non-production pour répondre à ces demandes. Lorsque le développement touche à sa fin, vous souhaitez mettre à jour votre instance de non-production vers la dernière copie de production pour effectuer des tests complets.

    Étant donné que vous avez précédemment utilisé une intégration de contrôle de source pour développer la version 1.0 de l’application Événements marketing, vous avez déjà lié l’application Événements marketing à un référentiel de contrôle de source. Vous validez la version 2.0 de l’application Événements marketing dans le référentiel de contrôle de source.

    Vous planifiez un clone de l’instance de production sur l’instance de développement. Une fois l’opération terminée, vous vous connectez à l’instance de développement et vous constatez qu’elle dispose de la version 1.0 de l’application Événements marketing, car il s’agit de la version installée sur l’instance source.

    Étant donné que l’application a déjà été installée sur l’instance source, vous appliquez les modifications distantes à partir du référentiel de contrôle de source pour recevoir la dernière version de l’application. L’instance de développement dispose désormais de la version 2.0 de l’application Événements marketing et peut être développée et testée.

    Profils de clones pour les demandes de clone

    Un profil de clone vous permet de stocker des options cibles et de clone prédéfinies. Le profil de clone remplit automatiquement votre demande de clone avec les paramètres de profil que vous avez sélectionnés.

    Profils de clones

    Accédez à la Clone système > Profils clones pour afficher vos profils de clone. Avec un profil de clone, vous pouvez :
    • Créer un profil avec des paramètres d’instance et d’option cibles spécifiques, des tables à exclure, des données à conserver et des scripts de nettoyage à exécuter
    • Créer une demande de clone directement à partir du profil de clone
    • Appliquer le profil de clone à une demande de clone
    • Vous pouvez cloner un profil pour créer un profil avec les mêmes autorisations et paramètres qu’un profil existant.
    Vous pouvez créer, modifier et supprimer des profils de clone à partir de la vue Profil de clone . Le profil système est un profil de clone en lecture seule que vous ne pouvez pas supprimer. Il affiche une liste prédéfinie d’exclusions de tables, de conservateurs de données et de scripts de nettoyage. Cette liste est basée sur les modules d’extension que contient votre instance.
    Profil de clone

    Pour définir un nouveau profil de clone comme profil par défaut utilisé lorsque vous demandez un clone, sélectionnez l’option Définir par défaut . Vérifiez qu’il s’agit du profil de clone correct que vous souhaitez utiliser pour le scénario de clone que vous demandez.

    Si vous créez un nouveau script de conservation, d’exclusion ou de nettoyage, il n’est pas automatiquement ajouté à vos profils de clone. Pour ajouter un script de conservation, d’exclusion ou de nettoyage, ouvrez le profil de clone, sélectionnez Actions supplémentaires > Configurer > Mise en pageet déplacez le nouveau conservateur vers la liste sélectionnée.

    Bien que facultative, l’utilisation de profils clones est suggérée. Si vous laissez le champ de profil de clone vide lors de la planification d’un clone, le système utilise toutes les tables, conservateurs de données et scripts de nettoyage exclus configurés sous Clone système > Définition de clone.