Conservation des données sur les instances cibles de clonage

Rversion finale: Washingtondc

Mis à jour 1 févr. 2024

11 minutes de lecture

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 MID Server, vous ne devez pas remplacer la table 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 des 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 utilisateur [sys_user_preference]

Remarque :

Un clone ne prend pas en charge la conservation des données 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 les données de table, telles que les utilisateurs, les groupes et les rôles, envisagez d’exporter les enregistrements vers 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.auth, et glide.smtp.encryption sont obsolètes.
Propriétés Digest	Propriétés de synthèse [digest_properties]	Aucun
Fournisseurs d'identité	Fournisseurs d’identité [sso_properties]	Aucun
Propriétés de 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 Digest [digest_properties], Fournisseurs d’identité [sso_properties] et Propriétés SAML2 Update1 [saml2_update1_properties] sont requises pour que l’authentification unique (SSO) à plusieurs sources fonctionne correctement. Si l’authentification unique (SSO) à plusieurs sources 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 une ou deux de ces tables étant conservées.

Conservateurs de données pour SAML

La préservation des paramètres liés à l’authentification unique SAML peut empêcher l’instance cible d’utiliser les paramètres d’émetteur et d’audience incorrects lors des demandes d’authentification adressées à 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 préserver les certificats SAML.
Utilisateur [sys_user] : pour préserver 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 souhaitent conserver les applications non publiées.

Le processus de clonage ne conserve pas les différences de version pour les applications en cours de 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 dispose d’une version de développement de la même application, celle-ci est modifiable après le clone, quelle que soit la version installée sur l’instance source. Si l’application était manquante dans 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

Il est parfois souhaitable de conserver certaines données sur une instance cible. Par exemple, lorsque vous utilisez un MID Server, vous pouvez éviter de remplacer la table [ecc_agent] du MID Server. Les données conservées sont stockées dans une liste générée dynamiquement sur l’instance cible avant le clone, puis 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 thèmes 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 les utilisateurs, les groupes et les rôles, envisagez d’exporter les enregistrements vers un fichier et de l’importer une fois le clone terminé.

Déterminez s’il faut conserver les données dans les tables suivantes.

Signet [sys_ui_bookmark]
Sélection récente [sys_ui_recent_selection]
Préférence utilisateur [sys_user_preference]

Si vous définissez un conservateur de données sur une table où l’instance source possède 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 soit déjà en place.

Dans l’instance source, la table sys_temp contient 100 enregistrements.
Dans l’instance cible, la table de 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 de 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 de sys_temp source.
La table de sys_temp source apporte les 80 enregistrements restants à la table de sys_temp cible.

Pour résoudre ce problème et préserver 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

Sur l’instance source, accédez à Clone système > Conserver les données.
Cliquez sur Nouveau.
Saisissez l’étiquette de table en tant que nom, par exemple, Préférence utilisateur pour la table [sys_user_preference].
Le conservateur de données doit avoir un nom de table, sinon il ne peut pas être envoyé.
Sélectionnez la table à conserver.
Une table doit être sélectionnée pour le conservateur de données, sinon elle ne pourra pas être envoyée.
Cochez la case Thème si les données en cours de conservation sont une propriété de l’interface utilisateur.
Définissez les données à conserver à l’aide du créateur de condition .
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 certaines propriétés système, vous pouvez ajouter des conditions pour chaque nom de propriété que vous souhaitez conserver.
Remarque :
La condition de correspondance des expressions régulières [match 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 de clone hérité. Le moteur de 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 remontée pas à pas. Dans ce cas, vous pouvez replanifier un clone système ou transférer manuellement des données.
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 :
Impossible de conserver les vues de base de donné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 de clone conserve son intégration SAML existante, vous devez modifier le conservateur de données des propriétés principales de l’instance pour inclure les propriétés SAML.

Avant de commencer

Rôle requis : admin

Procédure

Accédez à la Tous > Clone système > Conserver les données.
Sélectionnez les propriétés de l’instance principale.
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 d’instance.
Cliquez sur Mettre à jour.

Préserver les applications et les personnalisations en cours de développement lors d’un clone système

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

Avant de commencer

Assurez-vous de disposer d’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 conserve pas les différences de version pour les applications et les personnalisations d’applications en cours de développement. Au lieu de cela, le système clone uniquement sur l’instance cible les copies des versions d’application et de personnalisation d’application installées sur l’instance source. Si l’instance cible disposait d’une version de développement de la même application, celle-ci est modifiable après le clone, mais se trouve à la version installée sur l’instance source. Si l’application était manquante dans l’instance source, le processus de clonage supprime l’application de l’instance cible.

Procédure

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 d’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 possibles sont les suivants : Liez 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-y 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 d’application sur l’instance cible pendant le clone.

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.
Une fois le processus de clone terminé, connectez-vous à l’instance cible du clone.

Si vous avez enregistré chaque application dans un référentiel de contrôle de source, effectuez l’une des actions suivantes pour les récupérer à partir du référentiel de contrôle de source :

Tableau 2. Récupérer les applications à partir d’un référentiel de contrôle de source
État d’installation de l’application	Action à effectuer sur la cible du clone
L’application a été installée précédemment 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.	Importez l’application à 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 le clonage pour les personnalisations d’applications.

Pour la personnalisation de l’application, utilisez l’une de ces actions pour les récupérer à partir du référentiel de contrôle de source.

Tableau 3. Récupérer les applications à partir d’un référentiel de contrôle de source
État d’installation de l’application et de la personnalisation	Action à effectuer sur la cible du clone
L’application et la personnalisation ont été préalablement installées sur l’instance source.	Appliquez les modifications à distance à partir du référentiel de contrôle de source.
L’application a été installée précédemment sur l’instance source, mais pas la personnalisation.	Appliquez les modifications à distance à partir du référentiel de contrôle de source.
L’application de base 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.

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 les applications à partir d’un ensemble de mises à jour
État d’installation de l’application	Action à effectuer sur la cible du clone
L’application a été installée précédemment sur l’instance source.	Supprimez la version de l’application qui a été clonée à partir de l’instance source. 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.

Après un clone, vous pouvez appliquer les modifications distantes suivantes :

Tableau 5. Modifications à distance après clonage
Champ	Description
glide.source_control.post_clone_import_enabled	Pour désactiver l’application de l’automatisation des changements à distance, définissez sur Faux. La valeur par défaut est True.
glide.source_control.post_clone_import_delay_time_sec	Pour fournir un délai qui retarde le traitement de la file d’attente, indiquez 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écutera pas, indiquez une valeur. La valeur par défaut est de trois heures (10800).

Résultats

Les applications précédemment en cours de 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 Marketing Events. Vous avez déjà publié la version 1.0 de l’application Marketing Events dans le référentiel d’applications et l’avez installée sur votre instance de production.

Au fil du temps, des 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 Marketing Events sur une instance de non-production pour répondre à ces demandes. Alors que 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 Marketing Events, vous avez déjà lié l’application Marketing Events à un référentiel de contrôle de source. Vous validez la version 2.0 de l’application Marketing Events 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 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 Marketing Events et est disponible pour un développement et des tests ultérieurs.