Conservation des données lors du clonage d’instances cibles

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 stockées sur l’instance cible avant le début du clonage et sont restaurées sur l’instance cible après le clonage.

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]	Néant
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]	Néant
Fournisseurs d'identité	Fournisseurs d’identité [sso_properties]	Néant
Propriétés SAML2 Update1	Propriétés SAML2 Update1 [saml2_update1_properties]	Néant

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 ou 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. Cliquez sur 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.

   

   Avertissement :

   Si le clone de la copie de sauvegarde échoue pour une raison quelconque, le processus de clonage bascule vers le moteur clone hérité. Le moteur clone hérité ne peut pas conserver les données des tables étendues, des relations, des hiérarchies entre les tables et des requêtes de type « remontée pas à pas ». Dans de tels cas, vous souhaiterez peut-être replanifier un clone système ou transférer manuellement des données.
7. Cliquez sur Envoyer.
   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 Tout > 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]

   

   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

Assurez-vous d’avoir un accès en écriture à l’enregistrement d’application.

Assurez-vous d’avoir accès à un référentiel de contrôle de source.

Rôle requis : admin

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édait une version de développement de la même application, l’application est modifiable après le clone, mais dispose de 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.

Procédure

1. Pour conserver l’application sur l’instance cible du clone, effectuez l’une des actions suivantes :

   Tableau 1. Différences de version entre les instances

   État de la version de l’application	Mesure à prendre
   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. Les choix sont les suivants : Reliez 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. Publiez 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 l’instance source.	Aucun. Le processus de clone système copie cette version de l’application sur l’instance cible pendant le 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 2. 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 déjà été 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 3. Changements distants après le clone

   Champ	Description
   glide.source_control.post_clone_import_enabled	Pour désactiver l’automatisation de l’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 fournir 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 4. 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 déjà été installée sur l’instance source.	Supprimez la version d’application qui a été clonée à partir de l’instance source. Chargez l’ensemble de mises à jour qui contient la version actuelle de l’application.
   L’application n’a jamais été installée sur l’instance source.	Chargez l’ensemble de mises à jour qui contient 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.

Conserver l’application Événements marketing

Supposons que votre entreprise ait précédemment créé la version 1.0 d’une application personnalisée appelée Événements marketing. 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. À mesure que le développement touche à sa fin, vous souhaitez mettre à jour votre instance de non-production vers la dernière copie de production pour 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 programmez 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 est disponible pour un développement et des tests ultérieurs.