Conservation des données sur le clonage d’instances cibles

Rversion finale: Xanadu

Mis à jour 1 août 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 Serveur MID, vous ne devez pas écraser la table du 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. Les définir sur l’instance cible ne préserve pas les données.

Les conservateurs de données conservent 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 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 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 déconseillées.
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 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 de mise à jour SAML2 1 [saml2_update1_properties] sont requises pour que plusieurs sources d’authentification unique (SSO) fonctionnent correctement. Si l’authentification unique à 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 alors qu’une ou deux de ces tables sont 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 des paramètres d’émetteur et d’audience incorrects lorsqu’elle envoie des demandes d’authentification à votre fournisseur d’identité. Pour préserver 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 la façon dont ils souhaitent conserver les applications non publiées.

Le processus de clonage ne préserve 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 d’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, l’application est modifiable après le clone, mais elle se trouve à n’importe quelle 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 gèrent 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 du 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 des 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écidez 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 contient 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.

Supposons, par exemple, 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 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 la spécification 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 plus des 80 enregistrements restants à la table de 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

Sur l’instance source, accédez à Clone système > Conserver les données.
Cliquez sur Nouveau.
Saisissez l’étiquette de 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, sinon il ne peut pas être soumis.
Sélectionnez la table à conserver.
Le conservateur de données doit avoir une table sélectionnée, sinon elle ne peut pas être soumise.
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 Générateur 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 certaines propriétés système, vous pouvez ajouter des conditions pour chaque nom de propriété que vous souhaitez conserver.
Remarque :
La condition permettant de faire correspondre 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 clonage hérité. Le moteur de clonage 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 de tels 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 suivants du conservateur de données :
- 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 du 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 : administrateur

Procédure

Accédez à la Tout > 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 que vous avez actuellement en développement avant de pouvoir cloner la version de l’application sur 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 : administrateur

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’application en cours de 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 dispose d’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 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 sont les suivants : En la liant à 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 de 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 l’instance source.	Aucun. Le processus de clone système copie cette version d’application sur l’instance cible au cours du 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 clonage terminé, connectez-vous à l’instance cible du clone.

Remarque :

Si le contrôle de source est lié, puis post-clone, 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 effectuer une récupération manuelle 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 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 é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 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. Modifications à distance après clonage
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 True.
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écutera pas, fournissez une valeur. La valeur par défaut est de trois heures (10800).

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 été installée précédemment 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 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 É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, des utilisateurs ont soumis des demandes d’amélioration de 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 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 était déjà 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.