Datumsmigration im Jitterbit App Builder

Übersicht

Die Datumsmigrationsfunktion des App Builders unterstützt die Migration von Daten von einer Zeitzone in eine andere.

Warnung

Die Datenmigration ist ein sehr leistungsstarkes Tool, kann aber auch gefährlich sein, da sie alle ausgewählten DateTime Spalten in Ihrer Datenquelle. Vorsicht und gründliche Tests sind dringend zu empfehlen.

Empfehlungen

Die Datenmigration wird Entwicklern empfohlen, die Daten konvertieren möchten. DateTime Spalten von einer Zeitzone in eine andere.

Die ideale Zeitzone für Ihre Datenquelle ist zwar umstritten, es empfiehlt sich jedoch, Server und Datenquellen so zu konfigurieren, dass sie alle dieselbe Zeitzone verwenden. UTC ist wahrscheinlich die beste Wahl, da sich jede andere Zeitzone bei einem Standortwechsel des Servers ändern kann. Beachten Sie außerdem, dass Amazon-Instanzen standardmäßig auf UTC eingestellt sind.

Beachten Sie außerdem, dass die Konfiguration der Zeitzone Ihres Datenbankservers auf die Zeitzone Ihrer Datenquelle sicherstellt, dass Aufrufe von 'Now()' gibt den erwarteten Wert zurück. Now()Gibt die aktuelle Uhrzeit gemäß der Datenbankzeitzone zurück.

Durch die Synchronisierung aller Zeitzonen Ihrer Datenquellen vermeiden Sie die mühsame Konvertierung DateTime Daten von einer Zeitzone in eine andere. Dies geschieht derzeit nicht automatisch, könnte aber in einer zukünftigen Version implementiert werden.

Einschränkungen und Vorbehalte

Obwohl DateTime Spalten migriert werden, müssen möglicherweise auch andere Aspekte Ihrer App Builder Anwendung geändert werden, darunter:

• Fest codiert DateTime Werte in Regeln werden nicht angepasst. Wenn Ihre Regeln enthalten where oder select Klauseln mit fest codierten Datumsangaben müssen Sie manuell an die neue erwartete Zeitzone anpassen.
• Alle Spalten, die DateAdd oder ähnliche Funktionen zum manuellen Anpassen von Zeitzonen bleiben ebenfalls unverändert. Entwickler müssen diese manuell beheben.
• MS SQL Server Versionen vor 2016 unterstützen nicht die AT TIME ZONEFunktion. Daher wird die Datumsmigration mit einem Zeitzonen-Offset durchgeführt, der aus den Quell- und Zielzeitzonen zum aktuellen Zeitpunkt berechnet wird. Dies kann zu Problemen mit Zeitzonen führen, die Sommerzeit verwenden.
• Datumsmigrationen werden in einer einzigen Transaktion ausgeführt, wenn Ihre App/Datenquelle über ein LP aktualisiert wird. Je nach zu migrierender Datenmenge kann es zu einem Timeout der Transaktion kommen. In diesem Fall sollte ein längerer CommandTimeOut In Ihrer Verbindungsdatei können Sie Zeitüberschreitungen vermeiden.

Konfigurieren der Datumsmigration

Führen Sie die folgenden Schritte aus, um eine Datumsmigration durchzuführen:

• Navigieren Sie zu IDE > Zusätzliche Einstellungen > Datumsmigration
• Klicken Sie im Bereich „Datumsmigrationen“ auf + Migration
• Wählen Sie eine Datenquelle
• Wählen Sie eine Quellzeitzone. Diese Einstellung ist für Datenquellen mit einem Wert ungleich Null bereits voreingestellt. Time Zone.
• Wählen Sie eine Zielzeitzone
• Klicken Sie auf Speichern

Anschließend sollte das rechte Fenster mit allen DateTime Spalten in der ausgewählten Datenquelle. Hier können Sie die Einstellungen für die Datumsmigration für einzelne Spalten konfigurieren.

Wenn für Ihre Datenquelle keine Zeitzone festgelegt ist, wird Folgendes angezeigt: DateTime Spalten verwenden die Zeitzone des App Builder Anwendungsservers als Source Time Zone. Auditdaten werden in der Zeitzone des Anwendungsservers geschrieben, wenn für die Datenquelle keine Zeitzone konfiguriert ist. Beachten Sie außerdem, dass App Builder die AddedOn Und ChangedOn Spaltennutzungstypen, um zu bestimmen, ob eine Spalte als Audit-Daten gilt.

Sobald Sie die einzelnen Spalten angepasst haben, können Sie mit den folgenden Schritten fortfahren:

• Klicken Sie auf demselben Bildschirm wie oben im Bereich „Datumsmigration“ auf die Schaltfläche „Migrieren“.

Dadurch wird ein Hintergrundjob ausgeführt, um alle konfigurierten Spalten zu migrieren. Die Datumsmigration wird in einer einzigen Transaktion ausgeführt und sperrt dabei Tabellen. Stellen Sie sicher, dass der Datenverkehr auf Ihrem Server minimal oder gar nicht vorhanden ist, um Systemabstürze zu vermeiden.

Für jede migrierte Tabelle werden außerdem Schritte zum Änderungsmanagement hinzugefügt.

Nach der Migration der Daten ändert sich der Status der Datumsmigration in Complete.

Bei einem Fehler wird die Datenmigrationstransaktion zurückgesetzt. Weitere Protokollinformationen finden Sie im Verlauf des Hintergrundjobs.