Datenerhaltung beim Klonen von Zielinstanzen

Sie können Datenerhaltungsfunktionen verwenden, um Daten in der Zielinstanz vor dem Überschreiben zu schützen. Wenn Sie anwenderdefinierte Anwendungen haben, müssen Sie auch nicht veröffentlichte Anwendungsinhalte manuell beibehalten.

Datenerhaltungsfunktionen

Manchmal ist es erforderlich, einige Daten in einer Instanz zu erhalten, die geklont werden soll. Beispiel: Wenn das Ziel ein MID-Server ist, dürfen Sie die MID-Server-Tabelle [ecc_agent] nicht überschreiben. Konservierte Daten werden vor Beginn des Klonvorgangs in der Zielinstanz gespeichert und nach dem Klonvorgang in der Zielinstanz wiederhergestellt.

Warnung:

Sie müssen Datenerhaltungsfunktionen in der Quellinstanz definieren. Wenn Sie sie in der Zielinstanz definieren, werden die Daten nicht beibehalten.

Datenerhaltungsfunktionen speichern normalerweise Systemeinstellungen und -designs, z. B.:

• Instanzspezifische Authentifizierungseinstellungen
• Lesezeichen [sys_ui_bookmark]
• Letzte Auswahl [sys_ui_recent_selection]
• Benutzereinstellung [sys_user_preference]

Hinweis:

Ein Klon unterstützt das Beibehalten von Daten aus einer Datenbankansicht nicht.

Verwenden Sie keine Datenerhaltungsfunktionen zum Übertragen großer Datensätze, z. B. von Benutzergruppen. Wenn Sie Tabellendaten wie Benutzer, Gruppen und Rollen beibehalten müssen, sollten Sie die Datensätze in eine Datei exportieren und nach dem Klonen importieren.

Datenerhaltungsfunktionen für Multi-SSO

Das System erstellt automatisch die erforderlichen Datenerhaltungselemente für das Klonen, wenn Sie die Integration mit Single Sign-on für mehrere Anbieter aktivieren.

Name	Tabelle	Bedingungen
Zertifikat	X.509-Zertifikate [sys_certificate]	Keine
Eigenschaften der Core-Instanz	Systemeigenschaft [sys_properties]	[ODER] [Name] [ist einer von] [glide.authenticate.external, glide.authenticate.external.logout_redirect] [ODER] [Name] [beginnt mit] [com.snc.integration.saml_esig] [ODER] [Name] [ist einer von] [glide.smtp.port, glide.smtp.auth, glide.smtp.encryption] [ODER] [Name] [beginnt mit] [glide.authenticate.multisso] [ODER] [Name] [ist] [glide.authenticate.sso.redirect.idp] Hinweis: Die Eigenschaften glide.smtp.port, glide.smtp.authund glide.smtp.encryption sind veraltet.
Digest-Eigenschaften	Digest-Eigenschaften [digest_properties]	Keine
Identity Provider	Identitätsanbieter [sso_properties]	Keine
Eigenschaften von SAML2 Update1	Eigenschaften von SAML2 Update1 [saml2_update1_properties]	Keine

Hinweis:

Obwohl Sie diese Datenerhaltungsfunktionen ändern können, wird empfohlen, dies nicht zu tun. Die Tabellen „Digest-Eigenschaften“ [digest_properties], „Identitätsanbieter“ [sso_properties] und „SAML2 Update1-Eigenschaften“ [saml2_update1_properties] sind erforderlich, damit Single Sign-on (SSO) aus mehreren Quellen ordnungsgemäß funktioniert. Wenn Single Sign-on für mehrere Quellen in der Zielinstanz deaktiviert ist, können Sie alle drei Datenerhaltungsfunktionen bedenkenlos entfernen. Entfernen Sie sie gleichzeitig, da das System den Klon mit einer Fehlermeldung beendet, wenn Sie versuchen, zu klonen, während eine oder zwei dieser Tabellen beibehalten werden.

Datenerhaltungsfunktionen für SAML

Durch das Beibehalten von SAML-SSO-bezogenen Einstellungen kann verhindert werden, dass die Zielinstanz die falschen Aussteller- und Zielgruppenparameter verwendet, wenn Authentifizierungsanforderungen an Ihren IdP gesendet werden. Um SAML-Einstellungen beizubehalten, erstellen Sie Datenerhaltungsfunktionen für die folgenden Tabellen:

• Systemeigenschaft [sys_properties]: zum Beibehalten von SAML-Eigenschaften.
• X.509-Zertifikate [sys_certificate]:, um SAML-Zertifikate beizubehalten.
• Benutzer [sys_user]:, um SAML-Benutzer beizubehalten.

Sie müssen auch Eigenschaften und Benutzer beibehalten, die an SAML beteiligt sind.

Aufbewahrung von nicht veröffentlichten Anwendungen

Sie können keine Datenerhaltungsfunktionen verwenden, um unveröffentlichte Anwendungen zu speichern. Stattdessen müssen Anwendungsentwickler entscheiden, wie unveröffentlichte Anwendungen beibehaltenwerden sollen.

Der Klonvorgang behält für Anwendungen in der Entwicklung keine Versionsunterschiede bei. Stattdessen kopiert der Systemklon nur die auf der Quellinstanz installierte Anwendungsversion auf die Zielinstanz. Wenn die Zielinstanz über eine Entwicklungsversion derselben Anwendung verfügte, kann die Anwendung nach dem Klon bearbeitet werden. Es handelt sich jedoch um die Version, die auf der Quellinstanz installiert war. Wenn die Anwendung auf der Quellinstanz nicht vorhanden war, löscht der Klonvorgang die Anwendung von der Zielinstanz.

Erstellen Sie einen Datenerhaltungsmodul

Datenerhaltungsfunktionen verwalten angegebene Daten in einer Zielinstanz.

Vorbereitungen

Erforderliche Rolle: clone_admin oder admin

Warum und wann dieser Vorgang ausgeführt wird

Manchmal ist es wünschenswert, bestimmte Daten in einer Zielinstanz beizubehalten. Beispielsweise können Sie bei Verwendung eines MID-Servers vermeiden, dass die MID-Server-Tabelle [ecc_agent] überschrieben wird. Konservierte Daten werden vor dem Klonen in einer dynamisch generierten Liste in der Zielinstanz gespeichert und nach Abschluss des Klonens in der Zielinstanz wiederhergestellt. Sie definieren Datenerhaltungsfunktionen in der Quellinstanz.

Datenerhaltungsfunktionen sollen in erster Linie Systemeinstellungen und -designs beibehalten, z. B. instanzspezifische Authentifizierungseinstellungen. Verwenden Sie keine Datenerhaltungsfunktionen zum Übertragen großer Datensätze, z. B. von Benutzergruppen. Wenn Sie Tabellendaten wie Benutzer, Gruppen und Rollen beibehalten müssen, sollten Sie die Datensätze in eine Datei exportieren und nach Abschluss des Klonvorgangs importieren.

Überlegen Sie, ob die Daten in den folgenden Tabellen erhalten bleiben sollen.

• Lesezeichen [sys_ui_bookmark]
• Letzte Auswahl [sys_ui_recent_selection]
• Benutzereinstellung [sys_user_preference]

Wenn Sie eine Datenerhaltungsfunktion für eine Tabelle festlegen, in der die Quellinstanz mehr Datensätze als die Zielinstanz enthält, enthalten die in der Zielinstanz gespeicherten Daten auch die zusätzlichen Datensätze aus der Quellinstanz.

Angenommen, der Datenerhaltungsmodul ist bereits vorhanden.

• In der Quellinstanz enthält die Tabelle „sys_temp“ 100 Datensätze.
• In der Zielinstanz enthält die Tabelle „sys_temp“ 20 Datensätze.

Nach dem Klon enthält die Tabelle „sys_temp“ in der Zielinstanz 100 Datensätze.

• Die 20 Datensätze in der Zieltabelle „sys_temp“ werden erfolgreich beibehalten (gemäß der Spezifikation des Datenerhaltungsmoduls). Diese Datensätze waren Teil der 100 Datensätze in der Quelltabelle „sys_temp“.
• Die Quelltabelle „sys_temp“ überträgt die verbleibenden 80 Datensätze in die Zieltabelle „sys_temp“.

Um dieses Problem zu beheben und nur die Datensätze in der Zieltabelle beizubehalten, erstellen Sie einen Ausschlusstabellen-Datensatz für die Zieltabelle und legen zusätzlich die Datenerhaltungsfunktion in der Quelltabelle fest.

Wichtig:

Konfigurieren Sie die beibehaltenen Elemente in der Quellinstanz.

Prozedur

1. Navigieren Sie in der Quellinstanz zu Systemklon > Daten erhalten.
2. Klicken Sie auf Neu.
3. Geben Sie die Tabellenbezeichnung als Nameein, z. B. Anwendereinstellung für die Tabelle [sys_user_preference].
   Die Datenerhaltungsfunktion muss einen Tabellennamen haben, oder sie kann nicht übermittelt werden.
4. Wählen Sie die zu speichernde Tabelle aus.
   Für den Datenerhaltungssatz muss eine Tabelle ausgewählt sein, sonst kann er nicht übermittelt werden.
5. Aktivieren Sie das Kontrollkästchen Thema, wenn die zu speichernden Daten eine UI-Eigenschaft sind.
6. Definieren Sie die Daten, die mit dem Bedingungsgenerator konserviert werden sollen.
   Sie können Bedingungen verwenden, um bestimmte Datensätze zu definieren, die Sie während eines Klonvorgangs beibehalten möchten. Um beispielsweise nur bestimmte Systemeigenschaften beizubehalten, können Sie für jeden Eigenschaftsnamen, den Sie beibehalten möchten, Bedingungen hinzufügen.

   Hinweis:

   Die Bedingung für die Übereinstimmung mit regulären Ausdrücken [Reguläre Ausdrücke abgleichen] wird nicht mehr unterstützt.

   

   Warnung:

   Wenn das Klonen aus der Sicherung aus irgendeinem Grund fehlschlägt, findet ein Failover des Klonvorgangs zur Legacy-Klon-Engine statt. Die Legacy-Klon-Engine kann keine Daten aus erweiterten Tabellen, Beziehungen, Hierarchien zwischen Tabellen und Dot-Walking-Abfragen erhalten. In solchen Fällen möchten Sie möglicherweise einen Systemklon neu planen oder Daten manuell übertragen.
7. Klicken Sie auf Absenden.
   Wenn Sie den Datenerhaltungssatz später löschen möchten, dürfen Sie die folgenden Datenerhaltungsdatensätze nicht ändern oder löschen:

   • Eigenschaften der Core-Instanz
   • Semaphore
   • E-Mail-Accounts

   Hinweis:

   DB-Ansichten können nicht beibehalten werden.

   Beibehaltene Elemente dürfen nicht leer sein, und Anwender können den Klon nicht übermitteln, wenn Beibehaltene Elemente leer sind.

Erhält die SAML-Eigenschaften

Wenn eine Klonzielinstanz ihre vorhandene SAML-Integration beibehalten soll, müssen Sie die Datenerhaltungsfunktion „Core-Instanzeigenschaften“ so bearbeiten, dass sie die SAML-Eigenschaften enthält.

Vorbereitungen

Erforderliche Rolle: Administrator

Prozedur

1. Navigieren zu Alle > Systemklon > Daten erhalten.
2. Wählen Sie Core-Instanzeigenschaftenaus.
3. Fügen Sie die folgenden Bedingungenhinzu.
   • [ODER] [Name] [ist einer von] [glide.authenticate.external, glide.authenticate.external.logout_redirect, glide.authenticate.failed_requirement_redirect]
   • [ODER] [Name] [beginnt mit] [glide.authenticate.sso.saml2]
   • [ODER] [Name] [beginnt mit] [com.snc.integration.saml_esig]

   

   Hinweis:

   Stellen Sie sicher, dass das Kontrollkästchen Design deaktiviert ist, damit diese Eigenschaften beibehalten werden, unabhängig davon, ob Sie das Instanzdesign beibehalten.
4. Klicken Sie auf Aktualisieren.

Behalten Sie während eines Systemklons Anwendungen und Anpassungen in der Entwicklung bei

Speichern Sie manuell eine Kopie jeder Anwendung und Anpassung, die Sie derzeit in der Entwicklung haben, bevor Sie die Anwendungsversion in die Zielinstanz (Entwicklungsinstanz) klonen können.

Vorbereitungen

Stellen Sie sicher, dass Sie Schreibzugriff auf den Anwendungsdatensatz haben.

Stellen Sie sicher, dass Sie Zugriff auf ein Quellcodeverwaltungs-Repository haben.

Erforderliche Rolle: Administrator

Warum und wann dieser Vorgang ausgeführt wird

Beim Klonen werden Versionsunterschiede für Anwendungen und App-Anpassungen in der Entwicklung nicht beibehalten. Stattdessen klont das System nur die Kopien der Versionen von Anwendungen und App-Anpassungen, die in der Quellinstanz installiert sind, in die Zielinstanz. Wenn die Zielinstanz über eine Entwicklungsversion derselben Anwendung verfügte, kann die Anwendung nach dem Klon bearbeitet werden, weist jedoch die Version auf, die in der Quellinstanz installiert wurde. Wenn die Anwendung auf der Quellinstanz nicht vorhanden war, löscht der Klonvorgang die Anwendung von der Zielinstanz.

Prozedur

1. Um die Anwendung in der Klonzielinstanz beizubehalten, führen Sie eine der folgenden Aktionen aus:

   Tabelle : 1. Versionsunterschiede zwischen Instanzen

   Anwendungsversionsstatus	Auszuführende Aktion
   Die Anwendungsversion der Klonzielinstanz unterscheidet sich von der Quellinstanzversion.	Exportieren Sie jede Anwendung aus der Klonzielinstanz. Die Auswahlmöglichkeiten umfassen: Verknüpfen Sie jede Anwendung mit einem Quellcodeverwaltungs-Repository. Hinweis: Wenn die Anwendung bereits mit einem Quellcodeverwaltungs-Repository verknüpft ist, führen Sie ein Commit für die neueste Version aus. Veröffentlichen Sie jede Anwendung in einem Update Set.
   Die Anwendung ist nur in der Klonzielinstanz verfügbar.
   Die Anwendungsversion der Klonzielinstanz stimmt mit der Quellinstanz überein.	Keine. Der Systemklonprozess kopiert diese Anwendungsversion während des Klonvorgangs in die Zielinstanz.

2. Systemklon der Quellinstanz für die Zielinstanz anfordern.
   Klonen Sie beispielsweise Ihre Produktionsinstanz über Ihre Entwicklungsinstanz.
3. Melden Sie sich nach Abschluss des Klonvorgangs bei der Klonzielinstanz an.
4. Hinweis:

   Wenn die Quellcodeverwaltung verknüpft ist, ruft die Plattform nach dem Klonen automatisch Anwendungen und angepasste Anwendungen ab. Wenn dies über „glide.source_control.post_clone_import_enabled“ deaktiviert ist, müssen Sie manuell abrufen, indem Sie wie folgt vorgehen.
   Wenn Sie jede Anwendung in einem Quellcodeverwaltungs-Repository gespeichert haben, verwenden Sie eine der folgenden Aktionen, um sie aus dem Quellcodeverwaltungs-Repository abzurufen:
   Hinweis:

   Informationen dazu, was Sie nach der Anwendungsanpassung nach dem Klonen erwarten können, finden Sie unter Ergebnisse nach dem Klonen von Anwendungsanpassungen.

   Tabelle : 2. Anwendungen aus einem Quellcodeverwaltungs-Repository abrufen

   Anwendungsinstallationsstatus	Für Klonziel auszuführende Aktion
   Die Anwendung und die Anpassung wurden zuvor in der Quellinstanz installiert.	Anwenden von Remote-Changes aus dem Quellcodeverwaltungs-Repository.
   Die Anwendung wurde nie auf der Quellinstanz installiert.	Löschen Sie die Repository-Konfiguration (sys_repo_config), und importieren Sie die Anpassung aus dem Quellcodeverwaltungs-Repository.

   Tabelle : 3. Remote-Changes nach dem Klonen

   Feld	Beschreibung
   glide.source_control.post_clone_import_enabled	Um die Automatisierung des Anwendens von Remote-Changes zu deaktivieren, legen Sie die Option auf Falschfest. Der Standardwert ist true.
   glide.source_control.post_clone_import_delay_time_sec	Geben Sie einen Wert an, um eine Verzögerungszeit anzugeben, die die Verarbeitung der Warteschlange verzögert. Der Standardwert ist 0.
   glide.source_control.post_clone_import_pause_refresh_time_sec	Um ein Intervall anzugeben, in dem der Auftrag zum Aktualisieren des Repositorys nicht ausgeführt wird, geben Sie einen Wert an. Der Standardwert beträgt drei Stunden (10800).

5. Wenn Sie jede Anwendung in einem Update Set gespeichert haben, führen Sie eine der folgenden Aktionen aus, um sie aus dem Update Set abzurufen:

   Tabelle : 4. Anwendungen aus einem Update Set abrufen

   Anwendungsinstallationsstatus	Für Klonziel auszuführende Aktion
   Die Anwendung wurde zuvor auf der Quellinstanz installiert.	Löschen Sie die Anwendungsversion, die aus der Quellinstanz geklont wurde. Laden Sie den Update Set, der die aktuelle Anwendungsversion enthält.
   Die Anwendung wurde nie auf der Quellinstanz installiert.	Laden Sie den Update Set, der die aktuelle Anwendungsversion enthält.

Ergebnisse

Die zuvor in der Entwicklung befindlichen Anwendungen stehen für die weitere Entwicklung auf der Klonzielinstanz zur Verfügung.

Anwendung „Marketing Events“ erhalten

Angenommen, Ihr Unternehmen hat zuvor Version 1.0 einer benutzerdefinierten Anwendung namens „Marketing Events“ erstellt. Sie haben bereits Version 1.0 der Anwendung „Marketing Events“ im Anwendungs-Repository veröffentlicht und auf Ihrer Produktionsinstanz installiert.

Im Laufe der Zeit haben Benutzer Verbesserungsanforderungen für die Anwendung übermittelt, und Sie möchten Version 2.0 der Anwendung „Marketing Events“ auf einer Nicht-Produktionsinstanz entwickeln, um auf diese Anforderungen zu reagieren. Als die Entwicklung kurz vor dem Abschluss steht, möchten Sie Ihre Nicht-Produktionsinstanz auf die neueste Produktionsversion aktualisieren, um umfangreiche Tests durchzuführen.

Da Sie zuvor eine Quellcodeverwaltungsintegration für die Entwicklung von Version 1.0 der Anwendung „Marketing Events“ verwendet haben, haben Sie die Anwendung „Marketing Events“ bereits mit einem Quellcodeverwaltungs-Repository verknüpft. Sie führen ein Commit für Version 2.0 der Anwendung „Marketing Events“ an das Quellcodeverwaltungs-Repository durch.

Sie planen einen Klon der Produktionsinstanz über die Entwicklungsinstanz. Nach der Fertigstellung melden Sie sich bei der Entwicklungsinstanz an und stellen fest, dass sie über Version 1.0 der Anwendung „Marketing Events“ verfügt, da diese Version auf der Quellinstanz installiert war.

Da die Anwendung bereits in der Quellinstanz installiert wurde, wenden Sie die Remote-Changes aus dem Quellcodeverwaltungs-Repository an, um die aktuelle Anwendungsversion zu erhalten. Die Entwicklungsinstanz weist jetzt Version 2.0 der Anwendung „Marketing Events“ auf und ist für die weitere Entwicklung und zum Testen verfügbar.